If You're a Website Owner

1. Try updating your themes and plugins, as the issue may already have been resolved by the developers.
2. If the problem persists, report the issue to the plugin or theme authors so they can address it in a future update.
3. To identify the plugin or theme causing the error, look for the text domain mentioned in the error message. For example, in the following message, blahblah is the text domain:

Translation loading for the blahblah domain.

If You're a Plugin / Theme Author

Check your textdomain registration code and make sure the function is set to init hook or later. By textdomain registration code I mean the load_textdomain ^[1], load_plugin_textdomain ^[2], or load_theme_textdomain ^[3] functions.

For example the following code is wrong and should get fixed.

add_action('plugins_loaded', function()
{
    load_plugin_textdomain('your-textdomain', false, '/path/to/your/plugin/languages/');
});

The following code is the correct one:

add_action('init', function()
{
    load_plugin_textdomain('your-textdomain', false, '/path/to/your/plugin/languages/');
});

Use of the get_plugin_data Function

If you are using the get_plugin_data ^[4] function before the WordPress init hook, you must pass false as the third parameter or adjust your code logic to ensure it runs after the init hook.

For more information you can check the https://make.wordpress.org/core/2024/10/21/i18n-improvements-6-7/ URL.

I found a solution that helped me trace the function that was generating an error. Here is the method I used.

The basic idea is to temporarily modify the WordPress core file responsible for loading text domains to log a full function backtrace whenever your specific text domain is called. This will show you exactly what part of your theme or plugin is responsible.

This should only be done for temporary debugging on a development or staging environment. Remember to remove the code after you are done.

1. Open the file wp-includes/l10n.php.

2. Find the function _load_textdomain_just_in_time (it's around line 1350 in recent WordPress versions).

3. Add the following code at the beginning of the function or anywhere before the _doing_it_wrong() function call. Make sure to add your own textdomain "[textdomain]" to the text domain you are debugging.

   if ($domain == "[texdomain]") {
   
       // Start output buffering to capture the backtrace string
       ob_start();
   
       // The DEBUG_BACKTRACE_IGNORE_ARGS option prevents dumping
       // potentially large argument values, keeping the log concise.
       debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS);
   
       // Get the captured backtrace content and clean the buffer
       $trace = ob_get_clean();
   
       // Format the final log message
       $log_message = "ERROR: Early textdomain call for '" . $domain . "'\n";
       $log_message .= "Stack Trace:\n" . $trace . "\n";
       $log_message .= "--------------------------------------------------\n";
   
       // Write the message to the server's error log.
       // The location of this log file depends on your server's PHP configuration.
       error_log($log_message);  }
   
   
   

After uploading that code, I refreshed my page. The stack trace in my PHP error log pointed me to the exact string that was generating the error.

The problem was that the line below was being loaded in the theme customizer, which was happening way too early. As a temporary fix to stop the error, I removed the translation function:

//'footer_text' => __('All rights reserved.', '[textdomain]' ),
'footer_text' => 'All rights reserved.',

I manage a lot of websites. Basically, after Wordpres 6.7 update, a few websites which had 'WP_DEBUG' as true, started to show errors about _load_textdomain_just_in_time.

It is happening with a lot of plugins.

Lots of plugins are seeing this error NOT caused by incorrect text domain loading, but by other WordPress functions.

My plugin was using 'get_plugin_data' and getting was this error. I am still seeing it for other WP functions.

I replaced 'get_plugin_data' with

$plugin_data = get_file_data(ABSPATH . 'wp-content/plugins/bbpress/bbpress.php', array('Version' => 'Version'), false);

as a workaround.

But major plugins such as woocommerce (8 million installations)and really simple security (4 million installations) are seeing issues, and I gather it has been raised for a WP fix, rather than forcing plugin authors to work round it.

https://developer.woocommerce.com/2024/11/11/developer-advisory-translation-loading-changes-in-wordpress-6-7/

To fix this issue in your plugin use the following code:

add_action('init', function(){
    $mo = 'YOURTEXTDOMAIN-'. determine_locale() . '.mo';
    $path = plugin_dir_path(__FILE__) . 'languages/' .$mo ;
    load_textdomain( 'YOURTEXTDOMAIN', $path  );
});
;

Please note the path should point to the full path of the file.

So you may need to modify it if your .mo file located in a different directory.

The warning is basically saying that a WordPress translation function, e.g. __() or _e() was called way too early. The warning was non-existent prior version 6.7, that is why a lot of plugins and themes triggered it.

If you are a website owner, update all your themes and plugins. Chances are that the developers have already fixed the issue. If you are plugin or theme author or maintaining a custom codebase, you need to make sure the translation functions do not run before the init or after_setup_theme hooks.

For further reading, I have written a detailed guide on how to fix it: How to Fix Function _load_textdomain_just_in_time was called incorrectly ^[1]

What worked for me in similar situation:

1. Go to File Editor, rename wp-content/plugins folder to whatever
   
2. This allowed me to log in at /wp-admin
   
3. Go to updates and reinstall wordpress even if it is most recent
   
4. Go to plugins page, it will show you plugins are missing files
   
5. Then go back to file editor, rename folder back to "plugins"
   
6. Update all plugins
   
   

error should disappear