r4nd99y

I can confirm the fix works for me – there was a WP_Theme->__toString() call in the check for if the site is using Divi theme and this caused loading of theme translations too early.

@seaforth Then your issue lies elsewhere, probably.

The gap is gone:

View post on imgur.com

Site title seems to be higher, but only on the WooCommerce -> PDF Invoices preview page, when I open the actual PDF file from Edit order -> PDF Invoice then it’s fine. May be a quirk with WP Playground as it does say “Your server does not meet the requirements for PDF Invoices & Packing Slips for WooCommerce.”.

after_setup_theme did the trick, thanks!

Also found out that the reason the {locale}.mo name format didn’t work was because I used __DIR__ and not get_template_directory() and because I’m on Windows the directory separators were different and the str_starts_with in l10n.php didn’t match.

Did a test with WC and it seems to be working as well, I guess when there’s an issue it’s probably going to be something using a string too early somewhere and nothing to do with Loco.

Thank you very much for your help, I’ll leave you with this unrelated error that you maybe want to look at:

Warning: Undefined array key "" in C:\...\wp-content\plugins\loco-translate\src\fs\FileFinder.php on line 413

Fatal error: Uncaught Error: Call to a member function add() on null in C:\...\wp-content\plugins\loco-translate\src\fs\FileFinder.php:413 
Stack trace: 
#0 C:\...\wp-content\plugins\loco-translate\src\fs\FileFinder.php(383): Loco_fs_FileFinder->add(Object(Loco_fs_File)) 
#1 C:\...\wp-content\plugins\loco-translate\src\fs\FileFinder.php(458): Loco_fs_FileFinder->read() 
#2 C:\...\wp-content\plugins\loco-translate\src\fs\FileFinder.php(179): Loco_fs_FileFinder->next() 
#3 C:\...\wp-content\plugins\loco-translate\src\fs\FileFinder.php(190): Loco_fs_FileFinder->export() 
#4 C:\...\wp-content\plugins\loco-translate\src\package\Project.php(714): Loco_fs_FileFinder->exportGroups() 
#5 C:\...\wp-content\plugins\loco-translate\src\package\Project.php(843): Loco_package_Project->findLocaleFiles('po') 
#6 C:\...\wp-content\plugins\loco-translate\src\package\Bundle.php(711): Loco_package_Project->getLastUpdated() 
#7 C:\...\wp-content\plugins\loco-translate\src\admin\list\BaseController.php(26): Loco_package_Bundle->getLastUpdated() 
#8 C:\...\wp-content\plugins\loco-translate\src\admin\list\BaseController.php(36): Loco_admin_list_BaseController->bundleParam(Object(Loco_package_Plugin)) 
#9 C:\...\wp-content\plugins\loco-translate\src\admin\list\PluginsController.php(17): Loco_admin_list_BaseController->addBundle(Object(Loco_package_Plugin)) 
#10 C:\...\wp-content\plugins\loco-translate\src\mvc\AdminRouter.php(246): Loco_admin_list_PluginsController->render() 
#11 C:\...\wp-includes\class-wp-hook.php(324): Loco_mvc_AdminRouter->renderPage('') 
#12 C:\...\wp-includes\class-wp-hook.php(348): WP_Hook->apply_filters('', Array) 
#13 C:\...\wp-includes\plugin.php(517): WP_Hook->do_action(Array) #14 C:\...\wp-admin\admin.php(259): do_action('loco-translate_...') 
#15 {main} thrown in C:\...\wp-content\plugins\loco-translate\src\fs\FileFinder.php on line 413

This happens when I go to Loco Translate -> Plugins while I have a symlinked plugin. When I uncomment this then it works:

/*if( '' === $ext || ! array_key_exists($ext,$this->exts) ){
    throw new LogicException('Should have filtered out '.$file->basename().' when grouping by *.{'.implode(',',array_keys($this->exts)).'}' );
}*/

I use this command as admin in cmd to symlink some plugins from a central location to various WP installations:

mklink /j "C:\...\wp-content\plugins\my-plugin" "C:\...\my-plugin"

The plugin folders themselves also typically contain symlinks by pnpm and composer, which may also contribute to it.

I’m not familiar with your term “waterfall”.

On second thought, me neither, not sure why I thought that was the term for it.

Firstly though, the naming {locale}.mo etc.. (without text domain) is correct for the author location.

Interesting, so what is the reason that it’s not working when I don’t have Loco active and I just do (wp-content/themes/twentytwentyfive/functions.php):

add_action('init', function() {
	load_theme_textdomain('twentytwentyfive', __DIR__ . '/');
});

while having the files:

• wp-content/themes/twentytwentyfive/functions.php
• wp-content/themes/twentytwentyfive/twentytwentyfive.pot
• wp-content/themes/twentytwentyfive/{locale}.mo
• wp-content/themes/twentytwentyfive/{locale}.po
• wp-content/themes/twentytwentyfive/{locale}.l10n.php

The style.css has Text Domain: twentytwentyfive.
Does the fact that it’s a wp.org theme that I’m testing with have any impact? I temporarily removed wp-content/languages in case it had any downloaded tt5 translations, but no difference.
Would shipping both naming formats just in case be a bad idea?

The fact that merging (author + custom) works fine for plugins makes me optimistic.

You have confirmed that? I thought I had the same issue with WC – when I used Loco to override 1 string then the other translations from wp.org stopped working. Haven’t tested it in isolation though, so it could have been something else.

We don’t collect any information

What matters is that you can.

adding information in our readme

If you think that constitutes “explicit and authorized consent” then go for it.

My thought process was that if I was able to revoke this consent the notices would finally stop.

considering the DISABLE_NAG_NOTICES constant

Glad to hear it!

Still dismissing multiple messages on multiple sites per day. Time to stop speculating as to what the cause is and push an update that disables the clearly malfunctioning messages.

Consider respecting DISABLE_NAG_NOTICES constant which would solve this issue.

https://developer.www.ads-software.com/plugins/wordpress-org/detailed-plugin-guidelines/#7-plugins-may-not-track-users-without-their-consent

In the interest of protecting user privacy, plugins may not contact external servers without explicit and authorized consent.

https://plugin.smashballoon.com/notifications.json, where’s the consent setting for this then?

Have had to dismiss this notice so many times already. Clearly not working as intended.

Can confirm it’s working, cheers!

It means it must init itself earlier than all of them.

Init yes, but when do you need to determine whether to render a top level menu or a submenu item? Ideally not significantly earlier than admin_menu hook.

Is it not possible to fix it though?

hcap_settings_init_args

Trying to hook that filter from child theme is already too late.

Looks like it works now, thanks!

Yeah I got 2 basic test sites, one is regular, one is multisite.

On the regular site it touches the dashicons file for example: <style data-phast-original-src="https://wp.d/wp-includes/css/dashicons.css?ver=5.6.1" data-phast-params='{"ref":"ZGoDrksgSeI"}'>...</style>

But on the multisite site it leaves it as is: <link rel='stylesheet' id='dashicons-css' href='https://wpmu.d/site2/wp-includes/css/dashicons.min.css?ver=5.6.1' type='text/css' media='all' />

But on both sites there is <!-- [Phast] Document optimized in nms --> appended to end so some other optimizations are done. Only difference I can think of is that one is multisite and other isn’t.

As I said, I also tried in apache multisite and it doesn’t have a cdn.

Any way to make the plugin let you know when it can’t do something instead of failing silently?

your stylesheets ren’t loading from the same domain. PhastPress doesn’t support this.

In this case it was the same domain, just with an added subdomain.
But also, it seems phast has taken a stylesheet straight from cloudflare cdn and inlined it, so it seems it can do it.

Perfect, thanks!