Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add core update hook to clear global styles stylesheet #2

Closed
wants to merge 2 commits into from

Conversation

ironprogrammer
Copy link
Owner

@ironprogrammer ironprogrammer commented Dec 9, 2022

Adds function to delete the global styles stylesheet transient on core update.

  • Guards against existing function to be proposed for 6.1.2.
  • Clears this transient after ALL core upgrades, mitigating stale inline CSS behind reports in Trac 56970.
  • Retains existing "run once" transient reset logic (hotfix) that still needs testing by the community. This is used if a site has already been updated to 6.1.1 and exhibits the issue described in the ticket.

Tested on upgrades from 5.9.5/6.0.3 to 6.1.1.

@ironprogrammer
Copy link
Owner Author

@azaozz and @anton-vlasenko, after some additional discussion with @costdev, I’ve created this PR, which updates the test plugin with a proposed “permanent” function that could ship with core.

The plugin now accounts for two things:

  1. Provides a 6.1.1 update hotfix to test whether resetting global styles fixes existing issues (original scope).
  2. Clears the cached global styles after core update via new hook on _core_updated_successfully.

@azaozz
Copy link

azaozz commented Dec 9, 2022

Hmm, why use this in core? Thinking the removal of the transient as in WordPress/wordpress-develop#3712 is a better solution. It's just hard to do the same from a plugin. (A transient that is updated every minute is a pretty bad idea. On sites without persistent caching this can write to the DB every minute (from the front-end) causing slow-downs and inefficient use of resources. On some low-powered hosting accounts that may even exceed the usage limits and "lock" the db and the site.)

Also, even if a function has to be added to core, think it is a bad idea to not follow the plugins rules and not prefix it. What purpose would be served by naming the plugin's function with the expected name for core and then having to use function_exists()?

@ironprogrammer
Copy link
Owner Author

Thanks for the feedback, @azaozz! We'll hold on this PR pending input on the original version (that doesn't clear the transient on every upgrade). I agree that as a long term solution, it would be better to go with the backports provided in WordPress/wordpress-develop#3712. Hopefully it resolves the issue for reporters 🤞🏻

@ironprogrammer
Copy link
Owner Author

Closing since the original cache invalidation approach in WordPress/wordpress-develop#3712 has been merged in r55148 (Trac 56910).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants