Problems with Front End Editor still not fixed

Hello! There should be an easy fix to this if JoomShaper Dev will automate the insert of:

#addonId

if I remember it right in the Custom CSS. I just found that in one of their pre-built layouts. If you prepend #addonId to any selector you create in each of the addon that you have custom css, it will add the wrapper element add which has serial number.

I my opinion, that shouldn't be added manually and should be added automatically to save time.

Jackson

Hello,

Sure, I know that this should be fixed easily and asap, but it's a problem that has persisted for a long time.

In the website's front end you get the #addonid, in the front end editor of SP Page Builder it's not generated this way and this causes messed up layouts, that's why I insist that the front end editor should have the exact front end reflected, especially in version 4 where they gave up on the back end editor.

Hi Chris,

Yeah! That was my first reaction too when I started developing our website with v4 beta. Where on earth is the backend editor :D I got use to it as a go to editor when something is messed up in the frontend editor and I cannot find or edit it.

To be fair with Joomshaper Dev Team, the added the layer menu where you can see all the layers so I guess that's the work around.

It does need a learning curve using v4 editor and get use to it, it took me several subversions. What I don't get use to still is "the fix to the reproted issue" not getting fixed in the next release :D

Thanks,
Jackson

The same problems have been encountered since Joomla 4 was introduced. And bug fixes are coming out all the time and it's getting annoying. That's why I didn't upgrade my sites to version J4 and SP4.

This issue here has not been fixed: https://archive.joomshaper.com/forums/front-end-editor-is-grabbing-all-inline-css-from-a-certain-class I encounter the same issue on both Sp Page Builder Pro 3.x and 4.x. In my opinion, the front end editor must reflect the front end of the website exactly, otherwise it's useless.

Hi Chris.

In my opinion, it is pointless to fix it. The CSS field inside the addon should not be used for production. This is very polluting the code making it not valid. The entire code placed in this field goes inside the page, in body which is very bad for performance and validity. This is intended only for trying on CSS code inside the editor. After you wrote a suitable code there, transfer it to custom.css file using your unique class (CSS Class field).

Hi Pavel,

This is your opinion and I respect it. But if it's intended for trying css, why do you have the addon options like font size, font weight etc available? They also go in the inline css.
So if those options can go inline, I think it's alright for the rest of the code to go there too. The point is, as a developer, I want all the css to be in one place.
It's confusing to ask customers in the text addon for example, to change the font size, line-height in the addon options and then go to the custom.css file to change letter spacing or text shadow, don't you agree?

Also you have the option to enable production mode in Sp Page Builder, which can export all your css in an external file, so it is not pointless at all, it actually helps you to not create thousands of useless custom classes and you have all your css in each place. When a customer is purchasing your template, he does not need it all, he removes what is not needed, thus the css of the addons too. When you have everything in a custom.css file, all the css of the removed addons remains there, it will take a lot of work to find and remove it.

But this is not even the point. My point is the frontend editor should reflect exactly the frontend of the website, especially if you don't have a backend editor. I cannot make changes in a frontend editor and then have to refresh the website to check if they applied correctly.

Hi Chris.

But if it's intended for trying css, why do you have the addon options like font size, font weight etc available? They also go in the inline css.

You are mistaken. Inline code in <body></body> and inline code in <head></head> not the same things. Everything that is configured via Addon's options goes to <head></head> (or to external file if production mode is ON) but not to <body></body>.

Any code added to the CSS Addon's field goes to <body></body>. If production mode is ON this code not goes to external file. It's stay in <body></body> in any case, and it's bad.

But, if you want to use this field and avoid problems about which you wrote above, just use your class

Actually, you are mistaken, both the css from the custom css field and the available option fileds go into the head:
https://screencast-o-matic.com/watch/c3QF2NVOwaU

And as I said, they both are exported to an external file once production mode is enabled: https://screencast-o-matic.com/watch/c3QF29VOwaJ

I know about adding a custom css class to an addon, I am using if for some time, but as I said before, this is a workaround, not a solution.
That custom css field of the addon should be exactly so you cannot fill your css with thousands of useless class names .

I am not trying to avoid problems here, the conclusion is the same as in the previous post: the frontend editor should reflect exactly the frontend of the website, especially if you don't have a backend editor. I cannot make changes in a frontend editor and then have to refresh the website to check if they applied correctly. - and this can be easily solved if they apply to the custom css field of the addon the same principle as to the addon options, specifically adding the #uniqueid to the classes of the custom css field as well, not only to those from the addon options.

Actually, you are mistaken, both the css from the custom css field and the available option fileds go into the head: https://screencast-o-matic.com/watch/c3QF2NVOwaU

Hi Chris.

Well. So this was fixed. It used to be as I described. I did not check this in the current version. Apparently I missed one of changelogs.

Thank you for indicating it.

I agree with you in all other respects.