Hi,
We’ve recently upgraded a clients website to the newer version of WordPress along with all of it’s plugins, including Page Builder. Unfortunately it looks as if the level of CSS selectors has been lowered within panels to the child element and this is causing significant issues with the layout of the website. Obviously I’m only performing this on the clients local version so no huge rush to fix it, but ideally I need to figure out if:
Is there a way to revert to the old ID/class selector structure whilst keeping the plugins new version?
(I’m unsure if it helps but I’ve tried to the “Legacy layout” option in settings and set it to “always” but with no luck)
Please see the below screenshot for what I mean. The ID “hero” uses to appear on the parent selector which now contains an auto-generated ID of “pg-50-0”. Surely updating the CSS selector level structure is extremely bad practice in updating a plugin?
Any help would be appreciated, thanks.
Hi again,
Here is a GitHub open issue that seems to be relative to the issue as well – here
As mentioned by AlexGStapleton –
“You should be able to accomplish that setup by setting the row layout to full width. To clarify, the full width row layout is a row with a content container. This allows you to set a full width background and still have the content centered like in your desired screenshot.”
Yes, the full-width stretched layout does allow to get around this. However there are other CSS rules and styles that were specifically derived from the ID/class being in the previous parent position. I understand the solution, however it seems more of a hack-around. I appreciate the complexity of migrating away but with such a drastic change I’m surprised there has been no apparent consideration regarding those who have built an entire website around the prior versions functionality.
At the very least, it would be nice to have an option that can revert to the previous versions functionality. I’m now left with three options with the most recent update –
1) Investigate every single class/ID occurrence that has issues with this and transfer all styling where needed to work with the new version. Additionally I will have to update our client documentation in order for them to properly understand what has changed and how to cope with the new version going forward (I’m sure the client will love this).
2) Create a JS hack-around to push certain ID’s on the page to the parental selector. I will test this out, but am skeptical what issues could arise from this moving forward from a development and user-admin point of view.
3) Revert back to the old version of Page Builder and lose out on all the cool new features which of course is not ideal given the client has expressed interest in the newer version and site vulnerability checks will certainly not favour outdated plugins.
I can’t say that any of these options are ideal and I honestly find it surprising that there doesn’t seem to have been that much consideration from a development perspective.
Additionally from browsing the above link I did come across AlexGStapleton’s snippet for transfering classes back to up to the old way of working – here
However this does not seem to work for me, nor does it work for ID’s (I guess that’s fairly obvious though looking at the code). I guess my next step will be to port this snippet to work for the ID’s as opposed to classes and hope that resolves my issues.
Anyway, any input would be greatly appreciated!
Thanks,
Hi,
Can I please at least get confirmation that the auto-generated ID’s serve no functional purpose?
Thanks,
Hi Corby,
I tried to avoid saying this previously, but unfortunately, this change was sadly unavoidable. I can assure you that this change wasn’t made without looking at all available options and there sadly wasn’t alternative. It had to be done and this change was the change that affected the fewest number of people (this change, while really bad for you, will only affect a small portion of our user base while the issue it resolved affected hundreds of thousands of websites). I’m sorry that this change was made, but it sadly had to be done.
They’re actually very important to the layout and structure of pages which is why this change was made. All page builder row styling uses the generated ids.
I would strongly recommend going with either 1 or 3 – 1 being the recommended option. 2 isn’t something we would recommend.
Hi,
Thank you @Alex S for your reply and I appreciate your understanding of my situation! Regrettably I went with option 2 initially and then realised that this caused a few headaches. Since then however we did a work-around using option 3 that ports the previously used ID to the parent level as a class with a prefix and adjusted the SASS file accordingly.
For future reference in case any one else has this issue, here is a little filter to add to your functions that will help with this –
function siteorigin_add_class_to_row( $row_classes, $row ) { if( isset( $row['style']['id'] ) ) { $row_classes[] = 'PREFIX-' . strtolower($row['style']['id']); } return $row_classes; } add_filter('siteorigin_panels_row_classes', 'siteorigin_add_class_to_row', 10, 2 );Just rememeber to replace ‘PREFIX-‘ with whatever you wish the class to be prefixed with (if you don’t just remove it!).
Thanks,