Support » Plugin: Events Manager » Bug: get_option(‘dbem_version’) < 5.821 always true – setlocale

  • In em-install.php you are testing the dbem_version with statements like

    if( get_option('dbem_version') != '' && get_option('dbem_version') < 5.821 ){
      // do something here
    }

    With our locale settings get_option('dbem_version') returns 5,96 (note the comma) so the condition evaluates as

    if( 5,96 != '' && 5,96 < 5.821 ){
      // do something here
    }

    5,96 < 5.821 is always true, so em_migrate_datetime_timezones() never seems to be complete. And the GDPR message (v 5.93) and Google’s new pricing (v 5.95) are shown over and over again.

    I temporarily edited the code and replaced get_option('dbem_version') in the conditions with a hard coded 5.96 (with a decimal point), but in the next update this will be overwritten once again. Please rectify.

Viewing 12 replies - 1 through 12 (of 12 total)
  • For other people that encountered this problem:

    we found out this using the plugin Query Monitor
    https://wordpress.org/plugins/query-monitor/

    Using Query Monitor we saw that at each load of a backend page the table postmeta was being filled with data for each event. Not knowing this, the table had grown to about 200 MB, making the website slower.

    Using WP-Optimize we were able to delete orphaned postmeta data, but the table kept growing.

    My colleague JanEhrhardt found the source of the problem, but when the team of EM (hopefully) fixes this, you may have to look at the table postmeta and see if you need to delete orphaned data.

    • This reply was modified 11 months, 2 weeks ago by tammo59.

    Could you explain how wp_postmeta influences values saved in wp_options??
    Also, changing a decimal dot to a comma, hardly seems to be related.

    I recall you having problems with not being able to learn users the difference between a dot and a comma (technically). I have written a work-around snippet for that for you. Perhaps you should just disable that, as that does change a dot to a comma.

    Having orphaned entries, has often to with deleting entries. That is not restricted to EM. You should clean u your database regularly anyway. 😉

    @tammo59, your response seems to imply that orphaned meta changes saved values… Highly unlikely!!

    That is not what I meant to say. Due to the wrong outcome of the statement as described by Jan, the script em_migrate_datetime_timezones() kept running, filling the postmeta with values from all my events. And again, and again….

    Yes, it could relate to that script snippet. Very likely, because no other users have complained. We’ll look into that!

    Thanks for noticing,

    Tammo

    I believe the comma/dot thing was solved already in the core software of EM, wasn’t it?

    Due to the wrong outcome of the statement as described by Jan, the script em_migrate_datetime_timezones() kept running,

    That does sound more “aannemelijk” 😉

    it could relate to that script snippet.

    Blond, but have a strong memory! LOL.

    I believe the comma/dot thing was solved already in the core software of EM, wasn’t it?

    The changelog says it did. Try and find out, I’d say. Hehehe 😛

    We disabled the script snippet and the bug is still there. Not surprisingly, because the snippet only worked for wspsc_print_formatted_price.

    PHP’s localeconv() returns [decimal_point] => ,. The same accounts for $wp_locale->number_format['decimal_point']: a comma as well. Locale: ‘nl_NL’, Centos 6, PHP 7.1.32, ICU version 58.2.

    No, I’ll PM you about details

    • This reply was modified 11 months, 2 weeks ago by tammo59.

    @duisterdenhaag Tammo mailed me about the custom function stonehenge_em_save_decimal_as_dot, but that is unrelated as well: only applies to ticket prices.

    The bug still persists.

    See https://www.power-amersfoort.nl/setlocale.php for the locale settings on the server.

    Source:

    <?php
    setlocale(LC_ALL, 'nl_NL');
    echo "<pre>".print_r(localeconv(),true)."</pre>";
    ?>

    Output:

    Array
    (
        [decimal_point] => ,
        [thousands_sep] => 
        [int_curr_symbol] => EUR 
        [currency_symbol] => EUR
        [mon_decimal_point] => ,
        [mon_thousands_sep] =>  
        [positive_sign] => 
        [negative_sign] => -
        [int_frac_digits] => 2
        [frac_digits] => 2
        [p_cs_precedes] => 1
        [p_sep_by_space] => 1
        [n_cs_precedes] => 1
        [n_sep_by_space] => 1
        [p_sign_posn] => 1
        [n_sign_posn] => 2
        [grouping] => Array
            (
            )
    
        [mon_grouping] => Array
            (
                [0] => 3
                [1] => 3
            )
    
    )

    Found your post today.

    I’ve open another in october (here it is https://wordpress.org/support/topic/wrong-version-in-db-causes-slow-down/) and did not get any serious answer.

    I know that the problem is related to the locale but, In order to have the correct date format, I need to change the locale in my theme using
    setlocale( LC_ALL, ‘fr_FR’ );

    Today, I’ve installed the latest release and got the same result. Then I changed the dbem_version entry in options table ..

    So maybe some workaround could be (not tested)

    // get current
    $currentLocale = setlocale(LC_ALL, 0);
    // push to US
    setlocale(LC_ALL, 'us_US');
    // save dbem_version id DB
    // then rollback locale
    seltocale(LC_ALL,$currentLocal);
Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Bug: get_option(‘dbem_version’) < 5.821 always true – setlocale’ is closed to new replies.