Closed DahmaniAdame closed 1 year ago
The problem was easy to reproduce.
Like @DahmaniAdame we are not clearing the used css when a template item changes.
We will create a new method in the divi compatibility class which will take $post_id
as a parameter and subscribe to the et_save_post
event.
we will bail out if non of the custom post types match any of this _et_header_layout_id
or this _et_body_layout_id
or this _et_footer_layout_id
then get url to clear used css:
$url = get_permalink( $post_id );
$this->used_css->clear_url_usedcss( $url );
Add tests too
[S]
@engahmeds3ed Not sure if you're still working on it, if not, could you unassign and move it back to to do
?
I'm working on it
After a discussion with @jeawhanlee we agreed on the following:
As @DahmaniAdame mentioned in the issue, When saving the template, the action et_save_post
is fired so we can check the post type if it matches the template types so get the affected posts by making a raw query to get the posts with the meta key_POSTTYPE_id
then clear the used CSS and cache for them.
My concern here is that may be a resource consuming enhancement on the customer's side and our SaaS side for large sites so I was thinking of two approaches:
Any suggestions? or you see that over complicate it?
@engahmeds3ed why not do both? Sounds like we will be covering all possible scenarios if both approaches are combined while making sure the process will be under control for large websites.
@engahmeds3ed why not do both? Sounds like we will be covering all possible scenarios if both approaches are combined while making sure the process will be under control for large websites.
Good one, Yes we can do that and I believe that would work.
there is a missing part here, which is: the post ids mentioned in the last step before clearing used CSS are not real post ids they are the divi layouts' ids so with those ids we need to get their post meta with the key _et_use_on
which are multiple values in the following format:
and there are many variations in divi like here:
Thanks @DahmaniAdame for confirming that, seems like we have few approaches here that we need to take a decision about:-
The second approach will take more effort that the first one but it will make the process of saving templates more heavy and more CPU usage.
What do u think @wp-media/php I'm out of ideas
@DahmaniAdame What do you think about 3rd approach? It would be similar to what we'll be doing with Elementor, and applying that kind of pattern for different themes/builders would make a good UX while keeping the code easy to maintain.
We need to keep in mind that any breaking changes in the 3rd-party code might need reopening this issue if we go with handle all scenarios
way
@piotrbak @engahmeds3ed 2 will be maintenance intensive. Ideally, it should be 1. But it would be problematic in case the customer is editing the template and doing multiple saves. 3 sounds like a good middle ground. Let's go for it if there are no other options besides these to consider.
Okay, so, the Acceptance Criteria here will be:
WP Rocket: Your Divi template was updated. Clear the Used CSS if the layout, design or CSS styles were changed.
Clear Used CSS
, we'll purge the Used CSS and CacheDismiss
, the message will disappear@piotrbak I have two questions here:
Thanks @engahmeds3ed good point about the used css in the database. Let's go with proposed solution if used CSS is disabled.
For the notice, yes, I meant introducing a button, sorry for not being clear enough
Before submitting an issue please check that you’ve completed the following steps:
3.12.6.1
Describe the bug Divi has a template builder feature where the header, body, and footer can be set globally or under specific conditions.
If one of them is changed, we are not triggering the Used CSS clearing. This results in whatever was changed to have their style missing.
Divi stores them on specific post types:
All posts linked to a specific header, body, or footer will be documented on a customer field called, respectively,
_et_header_layout_id
,_et_body_layout_id
,_et_footer_layout_id
.We can track
et_save_post
, check if one of the specific post types is being saved, and then fire the following for any post with the corresponding custom field to have its Used CSS cleared, which should also clear the cache.et_save_post
takes the$post_id
as a parameter.The custom field to target can be built using:
With an SQL command that uses that specific custom field to get the matching posts to be processed.
To Reproduce Steps to reproduce the behavior:
Expected behavior We should clear the Used CSS when items from Divi's Theme Builder change.
Screenshots N/A
Additional context Ticket - https://secure.helpscout.net/conversation/2184716932/408393/
Backlog Grooming (for WP Media dev team use only)