I am having a child view with filtering options, similar to a shop (parent) with products (child) and a search filter using Divi and the latest Toolset Betas
On Load of the page with the parent and child everything looks like expected until i use the search function. Then the 1st search result inherits the styling from the parent.
To set this up I created the child view with the unformated option.
After looking a bit deeper into this I noticed the following change in the classes -> Images
The first result receives the same classes like the parent: .et_pb_section_0
Now i wonder if I did something wrong or would this need attention on your side ?
I tried to set up such a similar structure locally but not using DIVI; instead of using Toolset only, and this does not happen.
It is rather strange that an HTML class is changed without you coding it into the editors.
Sounds like JS is adding that.
Does the issue also persist with a WordPress Default Theme and NO Plugins BUT the Toolset Plugins?
If not, could you then re-enable the Plugins one after the other, and check the issue each time you enable a plugin?
Please report me when the issue comes back
It might also be due to the Theme.
Please do reactivate your Theme only after you are sure the issue isn't coming from a 3rd Party Plugin.
I suggest as well to check if this is due to the page builder used.
If this does not happen within Views alone when you use HTML, it may due to the Builder that adds the classes on the fly.
We also would need to know what search update form you use (AJAX or full reload)
I believe to see that you use AJAX - correct?
Even so, locally this does not happen.
If this happens only with the Builder, I am not sure if we will be able to fix this as it sounds rather like an issue with the builder, but we will definitely look into that and find out why it happens.
In that case, I think the best is you would submit us a copy of that site so we can see it locally happen and narrow it down. https://toolset.com/faq/provide-supporters-copy-site/
Thanks for this fast reply and looking into this 🙂
Looks like it must be then Divi that enumerates the section new after receiving the results from the ajax submit.
I will open a ticket at elegant themes with this issue, as it might affect other users as well, sooner or later, while the Divi / Toolset Combo is becoming a nice solution for building responsive web-apps based on WordPress
In the meantime i could resolve this issue with adding my own classes to the affected sections and style them outside of Divi with manual written CSS.
It may be that the builder does that, but there may be a way to avoid it as well.
Please submit me the following data, so I can prepare a workspace and debug this problem.
If I succeed I can either let the guys from DIVI what happens, or I can file a task in our own workflow, in case we can or should fix the issue.
It seems to me this is an annoying and unexpected problem, that should be solved.
Data to submit:
- a copy of your site is the best: https://toolset.com/faq/provide-supporters-copy-site/
- if this is not possible, a Zipped up copy of the public HTML folder in your FTP (your WordPress install) and a ZIP of the Database Export of your website.
- in any case, the exact steps of where I can see the issue, and how I could replicate it in a minimal Install using those methods.
I can then deploy this and put my hands on the real case.
A private reply is activated so all information is submitted securely.
I could not replicate the site locally as it seems altered, it does not resolve the login response.
However having a look at this on your site, I see that both links (hidden link and hidden link) present et_pb_section_n, where n is an increasing number starting at 1.
This cannot be changed by CSS.
How did you fix this?
It seems to be all is as expected. The counter must be something from the builder that increase each loop iteration, good for targeted addressing of the DIV for example.
Indeed every loop increases the number, which works ok on a first page load as every section gets sequentially numbered.
But after using a filter option the loop results start off with zero instead of the initial number (which could be everything from 1 and higher, depending the page layout) and so inherits the styles of the previous sections.
So to avoid this at the present I did the following:
- in the Content Template I used the Divi Builder only for the rough positioning of the different fields
- all the styling options in Divi I left at their default value
- then assigned my own CSS classes to the elements to be customized in the Advanced tab in Divi
- Did write the CSS styling manually
This works ok, but then why I would need Divi at all to style the loop content?
The big quest imho is where and why the first section in the loop changes the number after filtering, instead of keeping the initial value of the first loop result and increment from there?
It is out of my scope to see what causes this - is it views or is it divi? But I think this is an issue that will affect all Toolset/Divi users and needs to be solved somehow so the styling of the loop content template could be done completely in Divi.
Beda asked me to take a look at this as he couldn't get your Duplicator to work and I have recently been looking at Divi styling issues.
I set up a Divi test site and was able to reproduce the problem.
On my test site I have a page which uses Divi page builder to design the page, and inserted a View with filter controls into a text module. The output of the View is also designed with the Divi page builder, fields inserted into a text module using Views shortcodes.
On the initial page load the page section where the View is inserted gets the class .et_pb_section_0, and the results of the View are each in their own section with class names .et_pb_section_1, .et_pb_section_2, .et_pb_section_3 etc.
If my View is set to update via a page reload then everything continues to work in the same way.
If my View is set to update via ajax then the problem appears, and the first View result has the class .et_pb_section_0.
So if I have custom styles for .et_pb_section_0 (or .et_pb_row_0 or .et_pb_text_0) that are supposed to target the section where the View is inserted, the first result of the View will now pick up these same styles.
That's enough for me to be able to escalate this to our developers for them to investigate whether it's possible for us to fix this from our side.
I'm just reviewing my escalated threads to see if I missed anything, and it seems I overlooked an update in the internal ticket for this.
The developers took a long hard look at this and concluded that it is not something we can fix, the system Divi uses to add incrementing class names is, shall we say, fragile, when it comes to interactions with Views (specifically, but not only, when using ajax).
In the meantime I found a most elegant solution to solve this issue for good in 3 easy steps.
Step 1 - I got Astra Pro
Step 2 - Rebuild the site from scratch to avoid any leftovers from Divi
Step 3 - Replace the old Divi based Site with the new Astra Site by using Duplicator or a similar tool
Another advantage I got out from this is that Bootstrap can be used again!
There are some Divi cleanup plugins and tutorials available but they fail at Toolset Content Templates created in Divi and some 3rd Party Divi Modules
A pity as I thought the usage of the Divi Builder for creating Toolset templates would make things a lot easier. At least it sounded like an interesting concept.
So after some practical experiences I can safely conclude that using Divi and Toolset together at the moment of writing is something that should be avoided if one wants to push a bit beyond the borders of the simple examples.
I'm glad you found a good solution, even if that meant stopping using Divi. It is a popular theme and therefore we have tried our best to work smoothly with it, but it does certain things in certain ways that mean some issues inevitably arise.
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
