In the builder, the code element HTML will be returned via AJAX call and added to the DOM (Bricks canvas). The browser will not rerun any JavaScript added in that way. Hence, this is a normal behavior.
As the elements in the builder are meant to be used in the actual frontend, this shouldn’t cause any issues to the user.
Is there any reason you want to execute those frontend JavaScript inside the builder? Otherwise, a proper custom Bricks element + defining the JS function on $scripts property should be the way to go. I believe you are familiar with that
Yes, I was expecting it to be Bricks intended behaviour, but this doesn’t seems right to me, as I think most users would expect the code to execute when the “execute code” toggle is on, and especially when there is a “Run code (CMR + R)” button available, and javascript is not executed when the “run code” button is pressed.
The reason I want the code to execute in the editor is to be able to see my element in the editor as it will display on front end. And its appearance and/or behavior depends on code execution.
Of course, I could create a custom element, but this is overkill when I simply need a line of JS.
Appreciate your feedback.
After consulting with the team, we opted against running JavaScript in the builder due to its potential unpredictable side effects, which could impact both the functionality and performance of the builder.
Thanks, I appreciate you and the team taking time to discuss the topic internally.
I can live with this decision as there are workarounds, custom elements being one, but would take the opportunity to add this to the discussion:
In Bricks editor, we are in a dev environment, and we can expect glitches to happen when dealing with custom code.
When using a code block, the user did:
Intentionally accept code execution from Bricks settings.
Intentionally grant code execution rights to a user role.
Intentionally insert a code element.
Intentionally toggle the “execute code” settings on the code element itself.
And Intentionally insert some code, potentially buggy, or even malicious for sure, but this is the site developer doing it on purpose, not a potential external attack.
I think after doing all of this on purpose, the user know at least a little what they are doing and won’t blame Bricks if their custom code crashes the editor or creates performance issues.
I also think there is inconsistency in choosing not to execute javascript, but allowing php execution, as a user could do a lot of damage to the server and to the database with buggy or malicious php.
I understand the Bricks team made their decision about it, so I am not necessarily expecting it to change, but please consider these points for future decisions.