We want to improve how some labels are rewritten for the R&R feature using gettext, to avoid performance issues.
Summary
This PR can be summarized in the following changelog entry:
Improves the impact of the plugin on the performance of the site by avoiding useless calls on the gettext filter.
Relevant technical choices:
*
Test instructions
Test instructions for the acceptance test before the PR gets merged
This PR can be acceptance tested by following these steps:
We should check that the labels are still rewritten, and that the number to the affecting methods is much lower.
Regression test
install the Classic Editor plugin
Choose a published post and create a R&R copy of that
while editing the R&R copy in the Classic Editor, check that the button says "Republish" and the field where you set the date says "Republish on:" (the wrong margin is being fixed in #254)
change the date to a future date and check that the button now says "Schedule republish"
save as draft and on reload check that the button is still "Schedule republish"
check the same for pages and custom post types.
Check that we hook only in the edit screen
install Query Monitor
in QM, open Languages > Hooks in use:
visit different pages in the backend and see that Yoast\W\D\U\Classic_Editor->change_republish_strings_classic_editor() and Yoast\W\D\U\Classic_Editor->change_schedule_strings_classic_editor() are hooked only on the edit post/page screens
Check the performance improvement
this is not easy to check because it's visible in environments with plenty of content, but a possible way could be:
set breakpoints on Yoast\W\D\U\Classic_Editor->change_republish_strings_classic_editor() and Yoast\W\D\U\Classic_Editor->change_schedule_strings_classic_editor()
see that you hit the breakpoints only in the edit screen
see that when you hit the breakpoints, you bail out early when the text domain/context or the strings are not the expected ones, so no call to get_post() is done in that case.
Another idea:
install the Code Profiler plugin
Run checks for Dashboard and for Posts screen as admin with and without this patch, and see that the times change clearly (e.g. 0.043s vs 0.126s on the Posts page, and 0.022s vs 0.08s on the Dashboard)
Test instructions for QA when the code is in the RC
[x] QA should use the same steps as above.
QA can test this PR by following these steps:
Impact check
This PR affects the following parts of the plugin, which may require extra testing:
*
UI changes
[ ] This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.
Documentation
[ ] I have written documentation for this change.
Quality assurance
[x] I have tested this code to the best of my abilities
[x] I have added unittests to verify the code works as intended
pls78
commented
2 years ago
Context
gettext, to avoid performance issues.Summary
This PR can be summarized in the following changelog entry:
gettextfilter.Relevant technical choices:
*
Test instructions
Test instructions for the acceptance test before the PR gets merged
This PR can be acceptance tested by following these steps:
We should check that the labels are still rewritten, and that the number to the affecting methods is much lower.
Regression test
Check that we hook only in the edit screen
Yoast\W\D\U\Classic_Editor->change_republish_strings_classic_editor()andYoast\W\D\U\Classic_Editor->change_schedule_strings_classic_editor()are hooked only on the edit post/page screensCheck the performance improvement
this is not easy to check because it's visible in environments with plenty of content, but a possible way could be:
Yoast\W\D\U\Classic_Editor->change_republish_strings_classic_editor()andYoast\W\D\U\Classic_Editor->change_schedule_strings_classic_editor()get_post()is done in that case.Another idea:
Test instructions for QA when the code is in the RC
QA can test this PR by following these steps:
Impact check
This PR affects the following parts of the plugin, which may require extra testing:
*
UI changes
Documentation
Quality assurance
Fixes #185 DUPP-52