Bjarne Oldrup

As the original poster of this issue, which turned out to be very widespread by the way, I can report that I’m no longer able to reproduce this warning using WP 6.7.1 with WP_DEBUG enabled.

I tried to

• switch the language of site
• switch the language of the user
• enabled and disabled Firelight Lightbox several times
• enabled and disabled PolyLang several times.

So the warning is gone on my site, but I acknowledge that others may experience differently.

Thank you again for a great plugin, much appreciated ??

Nice! Thank you so much ??

Hey! No apologies necessary. If any, it is on me. I’ve done further testing, and here’s what I’ve learned:

• The uninstallation of Activity Log throws errors regarding missing tables and whatnot.
• The uninstallation completed, though.
• A fresh install still throws the errors mentioned earlier.
• The second uninstallation attempt also throws database errors.
• I attempted to provoke these errors on a different site, but couldn’t.

So, concluding so far, there is probably not quite right in my database. The site is old and has been migrated several times. It’s a testing ground for betas and release candidates. Maybe it’s time to start over on a fresh installation.

Thank you for taking your time to look into this. ??

Hi again, sorry for the late reply.

I just tested, and yes, it when updraft is the only plugin enabled.

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the updraftplus 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 in WordPress for more information. (This message was added in version 6.7.0.) in /home/mkjqekzy/public_html/wp-includes/functions.php on line 6087

A week ago, this post regarding the core changes and the warning was posted.:

Internationalization improvements in 6.7

Happens to around of one quarter of the plugins installed, though, so it might be my installation that isn’t feeling that well. I’ll try and see if I can reproduce this on a fresh installation.

It’s probably nothing, but I noticed on the second screenshot. The URL in the browser says HTTPS (with s), but the url in the block editor page settings, says HTTP (without s).

Not sure if it affects EDAC, but inconsistencies like this, can cause weird issues but are easy to fix.

Thank you for confirming Steve, and no worries about the response time, really.

Will check the next update, for sure.

Bjarne

Oh, thank you, Steve. I missed the list when skimming the article.

All the best to you and your team.
Bjarne

Oh, that is totally reasonable numbers, thank you for clearing that up. I’ll give it a spin on my most visited sites then, and keep an eye on performance while at it.

Btw, in terms of the performance of the tracking script – I found that 1) iawp/search loads in less than 200ms on all the sites I tested (WP 6.6, PHP 8.2) – and – 2) it’s deferred / loaded late at the end along with other unimportant scripts and favicons. As it should be. I still have a comfy speed index in Lighthouse of 1.3 sec on a slow 4g throttled mobile. I’s fine, on my stack, at least.

Update installed and fix confirmed. Thank you, guys! You’re the best ??

Oh, by the way, Webaim WAVE detects the empty link as expected.

https://wave.webaim.org/report#/https://test.oldrup.dev/accessibilitychecker/

Hmm

Oh wow, that is some serious diagnostics you’ve done there. Thank you.

No, I cannot say how I got here, but this is a VERY old website I keep updating early, specifically to locate and iron out any issues regarding new WordPress and PHP releases.

So. Yes, I can definitely try and disable every all file types, click save, and enable them again.

And yes, it appears to solve the issue. On the test site, there are 4 different kinds of embeds; single images, galleries, YouTube videos (got Ricked?), and a PDF.

https://oldrup.net/easy-fancybox/

And I’m pleased to report, that after the suggested settings refresh, they all work perfectly fine.

To return the thorough diagnostics, I also checked with all 3 free light box scrips, Fancy Box Legacy, Reloaded and V2. All good. ?

Tested with WP 6.6 RC1, PHP 8.3, debug and error console enabled.

Thanks again!
Bjarne

Perfect! Thank you again!

Here’s the experimental code that works for me. I disable Glossary for the posts in general, and enable it for those in the category with the slug “has_glossary” that I’ve created.

add_filter( 'glossary_is_page_to_parse', 'inject_glossary_tax' , 9999 );

function inject_glossary_tax( $bool ) {
    if ( has_category('has_glossary') ) {
        return true;
    }

    return $bool;
}

That way, the editor can enable the Glossary simply by categorising the new post accordingly. That is in line with their existing workflow.

Sweet! Very useful ??

Ah. I somehow missed that the glossary term excerpt was a pro feature. Kind of you to make it available in the community version as well. ?? Will still go pro, though — this is a paid project.

Fix confirmed! Tooltip now only shows excerpt. Thank you for the quick support – it is much appreciated.

Fix confirmed! Thank you again for a super flexible and solid plugin. It’s much appreciated.

That Zooey theme looks absolutely gorgeous, surely a lot of work has gone into that. Done, shame the plug. I look forward to testing it properly. Really appreciate the focus on accessibility! Nice work ??????