Support » Plugin: WP Performance Pack » Gettext seems not to work with 4.9.1

Gettext seems not to work with 4.9.1

  • januzi_pl

    (@januzi_pl)


    3 years, 1 month ago

    Hi

    The plugin was being used with success for quite some time, but I’ve noticed a higher load on the server. I’ve ran xdebug and the graph shows POMO, MO->, etc (earlier the graph wasn’t containing this functions/classes so I’m pretty sure that the plugin was doing its job). So clearly the plugin doesn’t override the default mechanism. I’ve checked options and they are enabled (new reader + gettext). The mo.* files are being created, but not in /wp-content/languages/wppp/ but in /wp-content/wppp/ (if that makes any difference).

    Is there a way to bring gettext back?

    Both wp and plugin are updated.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Bjoern

    (@greencp)

    3 years, 1 month ago

    Gettext still works fine on my installations after the update to 4.9.1. You should find either WPPP_MO_dynamic->translate or WPPP_Natvie_Gettext->translate in your XDebug graph.

    For debugging install the plugin Debug Bar (its linked in WPPP settings), enable WPPP debugging and check the debug infos.

    Please also try to re-save WPPP settings. Maybe the settings got corrupted.

    • This reply was modified 3 years, 1 month ago by Bjoern.
    januzi_pl

    (@januzi_pl)

    3 years, 1 month ago

    Debug Bar shows everything as on and it’s showing mo files that are being used. As for xdebug, there are no sign of translate methods, only 418 requests to the wppp_autoloader and 1-4 requests to constructors, inits, etc.
    I’ve deleted the plugin, removed its settings from wp_options and installed again. Nothing has changed.

    Where in the source code should I add something like exit( "aaa" ); to check if the script is calling the right function?

    Plugin Author Bjoern

    (@greencp)

    3 years, 1 month ago

    If you see no translate methods in xdebug surely not all calls are displayed. I’m using webgrind and in webgrind you can select how many “percent of runtime” you want to display. Try to increase the “resolution” of the displayed calls. Somewhere there have to be calls to translate. that you don’t see any in default settings could be good (as in native gettext is being used) or bad (default wordpress translate calls are fast. it’s the loading of the mo files that takes way too much time).

    You can add something line exit into wppp_load_textdomain_override in \wp-performance-pack\modules\l10n_improvements\class.wppp_l10n_improvements_base.php. This function has to be called if WPPP uses mo_dynamic or native gettext.

    And I forgot to mention it in my first reply: WPPP uses wp-content/wppp/[…] since version 2.0, so it’s normal for the mo files to be saved there.

    • This reply was modified 3 years, 1 month ago by Bjoern.
    agentdesign

    (@agentdesign)

    3 years ago

    Same issue here, gettext not working with WPPP but a test php file on the server confirms it is present and correct:

    
<?php
// Set language to German
putenv('LC_ALL=de_DE');
setlocale(LC_ALL, 'de_DE');

// Specify location of translation tables
bindtextdomain("myPHPApp", "./locale");

// Choose domain
textdomain("myPHPApp");

// Translation is looking for in ./locale/de_DE/LC_MESSAGES/myPHPApp.mo now

// Print a test message
echo gettext("Welcome to My PHP Application");

// Or use the alias _() for gettext()
echo _("Have a nice day");
?>
    agentdesign

    (@agentdesign)

    3 years ago

    Seems to be fixed for us now, no idea how though?

    Andrew Nevins

    (@anevins)

    WCLDN 2018 Contributor | Volunteer support

    3 years ago

    @agentdesign, You may not be facing the same problem as the original poster. It’s always good and polite to open a new thread even if your problem looks exactly the same as someone else’s: https://wordpress.org/support/plugin/wp-performance-pack/#new-post

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Gettext seems not to work with 4.9.1’ is closed to new replies.

Views