![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#9247 closed defect (bug) (fixed)
WP 6.7 throwing notices about 'buddypress' textdomain being loaded too early
| Reported by: | boonebgorges | Owned by: | imath |
|---|---|---|---|
| Priority: | normal | Milestone: | 14.3.0 |
| Component: | Core | Version: | |
| Severity: | normal | Keywords: | has-patch |
| Cc: |
Description
WP 6.7 will throw notices for plugins that load their textdomain before 'init'. See https://core.trac.wordpress.org/ticket/44937.
The 'buddypress' textdomain is first loaded (using WP's just-in-time textdomain loading) much earlier than init. Specifically, when component classes like BP_Core, BP_Members_Component, etc are initialized, their names are run through __(). See eg https://buddypress.trac.wordpress.org/browser/tags/14.2.1/src/bp-core/classes/class-bp-core.php?marks=31#L21 The backtrace here is:
require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, bp_loaded, do_action('bp_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, bp_setup_core, BP_Core->__construct
The practical upshot is that, with WP_DEBUG_DISPLAY turned on, WP throws a _doing_it_wrong() notice before the document begins to be printed. This causes browsers to do weird things, since content appears before the DOCTYPE declaration and the <html> opening tag.
More broadly, BP should probably try to adhere to the guidelines for the loading of translations. Unfortunately, there's probably not a simple fix. The attached patch shows what I had to do in order to get WP to stop throwing the notice. Namely, I had to (a) stop using localization when registering the theme packages, and (b) stop using localization when calling parent::start() in the component loaders. It'd be relatively straightforward to come up with a fix for (a) that involves registering the theme packages a bit later (or perhaps having the theme packages register their own localized names at some point later in the pageload). But the fix for (b) might require some new infrastructure or best-practices on BP_Component. For example, we might encourage the string passed in __construct() to be hardcoded, and then introduce some new internal method setup_component_name() or get_component_name() that's loaded at some appropriate point in the load order.
Attachments (1)
Change History (13)
#2
@
21 months ago
Sorry for not seeing #9240! But yes, I'm seeing the notices with the latest WP trunk.
#3
@
21 months ago
- Keywords has-patch added
- Milestone 15.0.0 → 14.3.0
Ouch, my bad! It's another notice! I see it too. I confirm your patch is fixing the issue. I believe it's safer to fix it in branch 14.0 too.
#4
@
21 months ago
So after digging a bit more into it: this name property is never used (or not used anymore). So we should probably use your fix for branch 14.0 & then deprecate this property in 15.0. I'm not sure we need to create a method to get this unused property.
This ticket was mentioned in PR #391 on buddypress/buddypress by @imath.
21 months ago
#5
Use "raw" name instead of "translatable" name for the BP_Component's & BP_Theme_Compat name properties.
Trac ticket: https://buddypress.trac.wordpress.org/ticket/9247
Hi @boonebgorges
I'm very surprised, I've closed this ticket #9240 thinking this notice disappeared, looks like WordPress has changed his mind again...
I'll test again. Thanks for your alert.