Title: errors in debug log Last modified: November 22, 2024 --- # errors in debug log * Resolved [fatherb](https://wordpress.org/support/users/fatherb/) * (@fatherb) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/) * Hi, I’m getting these errors in the debug log of a site with a critical error– seems to be blaming your plugin. * can you help please? * PHP Notice: Function _load_textdomain_just_in_time was called incorrectly . Translation loading for the wordpress-popular-posts domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/”>Debugging) in WordPress for more information. (This message was added in version 6.7.0.) Viewing 15 replies - 1 through 15 (of 15 total) * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18154015) * Hey [@fatherb](https://wordpress.org/support/users/fatherb/), * Thanks for the heads-up. I’ll look into that PHP notice as soon as I can. * However, that PHP notice is not what’s causing the fatal error on your site. It’s just a notice about something that should be corrected but that doesn’t have any negative impact (like a fatal error) on your site. * If you have details on the actual fatal error message (which should be listed in the error log as well) you can share it here and I’ll have a look for you. * Thread Starter [fatherb](https://wordpress.org/support/users/fatherb/) * (@fatherb) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18154100) * Thanks for the prompt reply – I have solved the critical error – it wasn’t to do with your plugin (sorry!). – it was an old php on the server – so have updated that and critical error gone. Still getting those errors about the textdomain thing though from your plugin – it’s not taking the site down though as you said. I found this – if it helps – [https://stackoverflow.com/questions/79198701/notice-function-load-textdomain-just-in-time-was-called-incorrectly](https://stackoverflow.com/questions/79198701/notice-function-load-textdomain-just-in-time-was-called-incorrectly) * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18154192) * Don’t worry, no harm done. Just wanted to help find the cause of the fatal error, glad you were able to sort it out! * And yes, I’ll investigate that textdomain notice ASAP. A couple of quick questions for you [@fatherb](https://wordpress.org/support/users/fatherb/): - Are you using the latest version of the plugin? If not, which version are you using? - WordPress version? * Thread Starter [fatherb](https://wordpress.org/support/users/fatherb/) * (@fatherb) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18155847) * Hi – WordPress 6.7.1 and PHP 8.1.30. * The popular posts plugin is on version 7.1.0  * Hope that helps. * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18157618) * Hey [@fatherb](https://wordpress.org/support/users/fatherb/), * So I looked into this and these are my findings: - WordPress 6.7.1 and WordPress Popular Posts being the only active plugin: no PHP notices. - Using WordPress Popular Posts with Polylang (a translation plugin) same results, no PHP notices. - Using WordPress Popular Posts with WPML Multilingual CMS version 4.6.6 (can’t try newer WPML versions as I no longer have a valid license key) I was able to reproduce that PHP notice. I also noticed that WordPress is reporting the exact same PHP notice for WPML as well, eg: _PHP Notice:  Function \_load\ _textdomain\_just\_in\_time was called incorrectly. Translation loading for the wpml-translation-management domain was triggered too early_. * I assume you’re using WPML on your site? If that’s not the case, then please: 1. Go to **Settings > WordPress Popular Posts** 2. Click on the **Debug** link at the top center of your screen 3. Copy the information you’ll see there and share it here so I can have a look * Thread Starter [fatherb](https://wordpress.org/support/users/fatherb/) * (@fatherb) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18165378) * Hi – WPML is not installed. * Information from debug in the plugin for you: * ```wp-block-code Plugin ConfigurationPerformance Nag: DismissedLog Limit: NoLog Views From: Visitors onlyData Caching: Yes, 1 minuteData Sampling: NoExternal object cache: YesWPP_CACHE_VIEWS: NoSystem InfoPHP version: 8.1.30PHP extensions: Core, date, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype, curl, hash, filter, ftp, gettext, json, iconv, SPL, pcntl, readline, Reflection, session, standard, mbstring, shmop, SimpleXML, tokenizer, xml, litespeed, i360, bcmath, dba, dom, enchant, fileinfo, gd, igbinary, imagick, imap, intl, ldap, exif, mcrypt, msgpack, mysqli, mysqlnd, odbc, PDO, pdo_mysql, PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, redis, snmp, soap, sockets, sodium, sysvmsg, sysvsem, sysvshm, tidy, timezonedb, xmlreader, xmlwriter, xsl, zip, ionCube Loader, Zend OPcache, SourceGuardianAVIF support: YesWebP support: YesDatabase version: 10.11.10-MariaDB-cll-lve-logInnoDB availability: DEFAULTWordPress version: 6.7.1Multisite: NoActive plugins: Blocks Animation: CSS Animations for Gutenberg Blocks 3.0.7, Enable Media Replace 4.1.5, Featured Image Admin Thumb 1.6, Forminator 1.36.3, GenerateBlocks 1.9.1, Getwid 2.0.13, Gmail SMTP 1.2.3.13, GP Premium 2.5.0, IndexNow 1.0.3, Keep ManageWP Worker Activated 1.0, LiteSpeed Cache 6.5.2, ManageWP - Worker 4.9.20, Max Mega Menu 3.4.1, Plugin Notes Plus 1.2.8, Popup Maker 1.20.2, Post Type Switcher 3.3.1, Simple Download Monitor 3.9.25, SQLite Object Cache 1.3.8, Strong Testimonials 3.2.0, Text Typing - Block 1.0.5, Wordfence Security 8.0.1, WordPress Popular Posts 7.1.0, Yoast Duplicate Post 4.5, Yoast SEO 23.9Theme: GeneratePress Child (0.1) ``` * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18165407) * Thanks! I’ll try installing some of your plugins (I know a couple in there that aren’t free ones so I’ll skip those) and see if I can reproduce the issue. I’ll leave a new comment once I know more. * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18170225) * **Update:** Unfortunately I wasn’t able to reproduce this issue at all. * I tested all of the plugins you listed -except for “GP Premium” and “Keep ManageWP Worker Activated” since they’re not available on the WordPress plugins repository- and: - Featured Image Admin Thumb throws “Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the `featured-image-admin- thumb-fiat` domain was triggered too early.”, even when WPP is not active. - SQLite Object Cache throws “Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the `sqlite-object-cache` domain was triggered too early.”, even when WPP is not active. - WordPress Popular Posts on its own didn’t throw this PHP warning at all. - Tested with the GeneratePress theme (didn’t create a child theme like you did though.) * Try following these [troubleshooting instructions](https://github.com/cabrerahector/wordpress-popular-posts/wiki/5.-FAQ#initial-troubleshooting), hopefully they’ll help you find out what’s causing this on your end. Please share your findings (if any) once you’re done [@fatherb](https://wordpress.org/support/users/fatherb/). * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18170236) * Another update: this seems to be a widespread issue caused by a recent change in WordPress: [https://core.trac.wordpress.org/ticket/62462](https://core.trac.wordpress.org/ticket/62462)( and here’s a [workaround](https://gist.github.com/kowsar89/ed30f2b7abc5d4784ba4b05503c70fe0) someone shared in that ticket, in case you’re interested.) * Looks like we’ll have to wait for the WP team to look into it. * Thread Starter [fatherb](https://wordpress.org/support/users/fatherb/) * (@fatherb) * [1 year, 6 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18173550) * Thanks for trying to investigate. I got in touch with the featured image admin thumb plugin people too and they were able to issue a fix for the textdomain errors their plugin was throwing. I’ll have a look at the workaround you posted too. * [Bence Szalai](https://wordpress.org/support/users/grapestain/) * (@grapestain) * [1 year, 5 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18178818) * [@hcabrera](https://wordpress.org/support/users/hcabrera/) Probably there’s not much to wait for. WordPress was addressing some other issues and as part of that they changed how the translations are loaded. So what worked before (using `__()` functions very early triggering an implicit call to `_load_textdomain_just_in_time()`) is no longer supported. It is not going to resolve itself. Other plugin authors are already updating their plugins to fix these warnings, changelogs for 4 out of 10 updates in the last month had fixes related to this. You need to move the plugin initialization to the `init` hook or reorganize the code to eliminate/ delay the early call to `__(` in `Widget.php` line `79`. I’ve monkey patched ` Bootstrap.php` for now to only make the container and call `$WordPressPopularPosts- >init();` on the `init` hook (with prio `0` so functions hooked to `init` in the plugin with default prio `10` can still fire), but an official fix would be nicer! - This reply was modified 1 year, 5 months ago by [Bence Szalai](https://wordpress.org/support/users/grapestain/). - This reply was modified 1 year, 5 months ago by [Bence Szalai](https://wordpress.org/support/users/grapestain/). - This reply was modified 1 year, 5 months ago by [Bence Szalai](https://wordpress.org/support/users/grapestain/). - This reply was modified 1 year, 5 months ago by [Bence Szalai](https://wordpress.org/support/users/grapestain/). * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 5 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18178943) * I seem to remember that there was a particular reason for me to pick _plugins\ _loaded_ as the hook to initialize the plugin [@grapestain](https://wordpress.org/support/users/grapestain/) but I honestly don’t remember what it was anymore. It’s been too long and I didn’t document it in the code. * Out of curiosity, is the `__(...)` call you’re talking about [this one](https://plugins.trac.wordpress.org/browser/wordpress-popular-posts/tags/7.1.0/src/Widget/Widget.php#L79) [@grapestain](https://wordpress.org/support/users/grapestain/) ? (There’s another Widget.php file in the plugin, I should have named it something else…) * In any case, at least some testing will be required to check whether switching from _plugins\_loaded_ into _init_ has any side effects (eg. breaking existing functionality) and since this PHP notice isn’t causing any actual issues like breaking sites nor impacting plugin’s functionality (just some debug.log spam, which shouldn’t be enabled on live sites in the first place) don’t expect this change anytime soon (I do have an update ready, planned to be released this week– just won’t include any plugin initialization changes for now.) * **Edit:** There’s also the fact, as stated above, that I can’t reproduce this PHP notice on a clean WP install (latest WordPress, and only WPP is enabled.) * **Edit 2:** And just minutes after my first edit, and thanks to a hint in your comments, I figured out how to reproduce it haha. I’ll look into it as soon as I can. - This reply was modified 1 year, 5 months ago by [Hector Cabrera](https://wordpress.org/support/users/hcabrera/). - This reply was modified 1 year, 5 months ago by [Hector Cabrera](https://wordpress.org/support/users/hcabrera/). * [Bence Szalai](https://wordpress.org/support/users/grapestain/) * (@grapestain) * [1 year, 5 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18179048) * Yes, that is the one. * To be honest it is quite strange that you cannot reproduce the warning, it is a core warning emitted here: [https://github.com/WordPress/WordPress/blob/master/wp-includes/l10n.php#L1369](https://github.com/WordPress/WordPress/blob/master/wp-includes/l10n.php#L1369) * The warning itself is a bit strange too because the warning is only emitted if the call happens before `after_setup_theme` but the message says there should be no such calls before `init`. (`after_setup_theme` happens before `init`). Maybe they will later tighten the criteria to `init` but they already put the message so if someone makes adjustments they will not have to do that again. Only speculation. * To be honest I don’t know if my workaround is really working well, I’m only using the plugin to collect and report stats but not the frontend UI parts, so it may break some things. I just wanted a quick dirty fix. * I think a proper fix would be instead of moving the whole plugin initialization as that really risks breaking other things just simply move the `Widget` initialization to the `init` hook. It still requires some refactorings as your Container class does a fairly linear initialization, but afaics the only reason `Widget` is initialized early because it is passed to `WordPressPopularPosts`, and the only reason it is passed is to be able to handle the loading of all services with a single ` $WordPressPopularPosts->init()` call in `Bootstrap.php`. If you remove [this]( [https://plugins.trac.wordpress.org/browser/wordpress-popular-posts/tags/7.1.0/src/Container/WordPressPopularPostsConfiguration.php#L56-L65](https://plugins.trac.wordpress.org/browser/wordpress-popular-posts/tags/7.1.0/src/Container/WordPressPopularPostsConfiguration.php#L56-L65)) whole call from `WordPressPopularPostsConfiguration.php` and as a dependency of `WordPressPopularPosts` and instead you can add this to `Bootstrap.php` i think that would work and leave everything else the same as now except for the Widget: * ```wp-block-code add_action('init', function() use ($container) { $container['widget'] = $container->service(function(Container $container) { return new Widget( $container['widget_options'], $container['admin_options'], $container['output'], $container['image'], $container['translate'], $container['themer'] ); }); $container['widget']->hooks();}); ``` * (I only used the closure for simplicity, if you want to support older PHP version probably you want to use a proper named callback.) * Sidenote: since `$container['widget']` is not used anywhere else it is not necessary to add it to the container at all. * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 5 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18179143) * > If you remove this whole call (…) * I was actually planning to [remove all classic widget related code](https://github.com/cabrerahector/wordpress-popular-posts/issues/381) in a future release lol Maybe this is a good opportunity to do so? Or I might just remove all I18N calls from the classic widget if that fixes the PHP notice, and then remove it completely at a later date as I originally planned. I guess I’ll poke around a bit and see what happens. * Plugin Author [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * (@hcabrera) * [1 year, 5 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18181405) * Quick update [@fatherb](https://wordpress.org/support/users/fatherb/) [@grapestain](https://wordpress.org/support/users/grapestain/): * As Bence pointed out, the PHP warning is indeed coming from [/src/Widget/Widget.php](https://plugins.trac.wordpress.org/browser/wordpress-popular-posts/tags/7.1.0/src/Widget/Widget.php), [line 79](https://plugins.trac.wordpress.org/browser/wordpress-popular-posts/tags/7.1.0/src/Widget/Widget.php#L79). * Changing this: * ```wp-block-code 'description' => __('The most Popular Posts on your blog.', 'wordpress-popular-posts') ``` * into: * ```wp-block-code 'description' => 'The most Popular Posts on your blog.' ``` * makes the notice go away completely (or at least I don’t see it anymore in debug. log). No other changes are needed. * Since it’s such a small change I’ll include it on the next release. Viewing 15 replies - 1 through 15 (of 15 total) The topic ‘errors in debug log’ is closed to new replies. * ![](https://ps.w.org/wordpress-popular-posts/assets/icon-256x256.png?rev=1232659) * [WP Popular Posts](https://wordpress.org/plugins/wordpress-popular-posts/) * [Frequently Asked Questions](https://wordpress.org/plugins/wordpress-popular-posts/#faq) * [Support Threads](https://wordpress.org/support/plugin/wordpress-popular-posts/) * [Active Topics](https://wordpress.org/support/plugin/wordpress-popular-posts/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/wordpress-popular-posts/unresolved/) * [Reviews](https://wordpress.org/support/plugin/wordpress-popular-posts/reviews/) * 15 replies * 3 participants * Last reply from: [Hector Cabrera](https://wordpress.org/support/users/hcabrera/) * Last activity: [1 year, 5 months ago](https://wordpress.org/support/topic/errors-in-debug-log-14/#post-18181405) * Status: resolved