#26746 closed enhancement (fixed)
Avoid translating several times post type and taxonomy default labels
Reported by: | Chouby | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 6.0 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Posts, Post Types | Keywords: | has-patch early commit add-to-field-guide |
Focuses: | performance | Cc: |
Description
get_taxonomy_labels and get_post_type_labels translate default labels each time register_post_type and register_taxonomy are called. This is useless and is a rather expensive process resulting in a performance loss.
Attachments (6)
Change History (36)
#2
@
11 years ago
- Component changed from Performance to Post Types
- Focuses performance added
- Milestone changed from Awaiting Review to 3.9
#3
@
11 years ago
- Keywords needs-patch added; has-patch removed
- Milestone changed from 3.9 to Future Release
#4
@
11 years ago
Yes you are right. It breaks translations. So we can't do that before the default textdomain is loaded. In the second patch, I propose to wait for the 'init' action. The benefit would not be so high for a default WordPress install, but could still be interesting for an install with lot of custom post types and taxonomies (provided that they are registered in an init action as recommended).
#5
@
11 years ago
- Keywords has-patch added; needs-patch removed
- Milestone changed from Future Release to 4.0
26746.2.patch works as expected for me. Refreshed, moving for 4.0 consideration.
#6
@
11 years ago
I think this can be pushed further. The current state without patch is regenerating labels on every call. The current patch will regenerate labels on every call until did_action('init')
state change.
Then why don't we generate labels once before and once after state change?
Also timing-wise locale is available tad earlier than init
at after_setup_theme
, makes sense to check for that one instead in case CPTs are already getting registered in third party code.
This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.
10 years ago
#12
@
3 years ago
The approach in 26746.3.patch still seems viable, though I'm wondering if it might affect any multilingual plugins. I guess we can try this while still in earlier stages of the release, and wait for community feedback.
Implementing the approach suggested in comment:6 also seems like a good idea.
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#16
@
3 years ago
- Keywords early added
- Milestone changed from 5.9 to Future Release
As per today's bug scrub and since tomorrow is WP 5.9 feature freeze, I'm moving this ticket to Future release
. Also adding early
workflow keyword since this enhancement needs to be properly checked to avoid backwards compatibility issues.
#17
@
3 years ago
The way proposed when the ticket was initiated can't work anymore due to the introduction of switch_to_locale()
since that time.
In this new patch, I introduce a new class to store the default labels once they are translated. The reset()
method can be called to reset the cache.
NB: I propose to decrease the priority of the functions hooked to change_locale
to make sure that the default labels will be resetted before plugins hook to this same action with the default priority (in case they need to register their own post types or taxonomies when the locale is switched).
I tested the patch against WP 5.9-alpha-52272. The number of calls to MO::translate_entry()
decreases from 2,296 to 1,207. Comparing cachegrind files, they show a total time divided by 12 for get_post_type_labels()
and by 4 for get_taxonomy_labels()
.
#18
@
3 years ago
- Keywords needs-refresh removed
This new patch uses the same approach as the previous one except that it uses the existing classes WP_Post_Type
and WP_Taxonomy
to store labels, rather than creating a new class.
#19
@
3 years ago
- Milestone changed from Future Release to 6.0
- Owner set to SergeyBiryukov
- Status changed from new to reviewing
This ticket was mentioned in PR #2404 on WordPress/wordpress-develop by audrasjb.
3 years ago
#20
Trac ticket: https://core.trac.wordpress.org/ticket/26746
#22
@
3 years ago
- Keywords needs-refresh needs-testing added
The current patch throws a fatal error. Investigating…
#23
@
3 years ago
- Keywords needs-refresh needs-testing removed
The above bug was a merge issue on my side, locally.
I can confirm the patch works fine on my side (it doesn't change anything, except it improves translation loading performance).
#24
@
3 years ago
I asked a question on the linked pull request about changing the priority of some default hooks. It's a minor back-compat break so it would be good to know why it's needed so the cost/benefit can be evaluated.
This ticket was mentioned in Slack in #core by chaion07. View the logs.
3 years ago
#27
@
3 years ago
- Keywords commit needs-dev-note added
Linked pull request looks good for commit.
I've added needs-dev-note
as I think it would be good to alert multilingual plugins. I don't think it needs to be a full dev note, just a mention in a grouped note for developer or i18n changes.
I'm all for performance improvements here but, as written, this will break translations. Right now core post types and taxonomies are loaded twice, and the first time is before translations are loaded. These would thus always be in English.
A lesser concern could be someone switching between languages (such as each language being a post type), but they're likely going to have their own strings/labels, so it's not as big of a deal and probably an edge case.