Closed chrisaligent closed 4 years ago
It would be great to eventually merge this with @anyt 's code for inserting Oro Widgets (such as the Contact Us form demo he managed to hack together).
This bundle is no longer needed as Oro have taken over development of GrapesJS, it is included as part of Oro 4.1:
https://oroinc.com/b2b-ecommerce/blog/updates-to-orocommerce-4-1-rc
It's going to take me a few days to submit a PR for this, but for now I've extracted the changes I made during the Hackathon to get GrapesJS working in the Landing Pages Editor.
Caveats
Required Components
Screenshots
Code Changes
vendor/oro/platform/src/Oro/Bundle/UIBundle/Resources/views/Default/index.html.twig This file required the CSS/JS assets to be injected, but in the real world it should be pushed into the correct script block (like any other Bundle assets).
As far as I can tell these assets are only needed in the backend/admin area, except for the
grapes.min.css
file to render the frontend content. NOTE: On the last line is agrapesjs-preset-webpage.min.js
file, you'll need to download this from the demo repo linked above and drop it into yourpublic/js
directory for nowvendor/symfony/symfony/src/Symfony/Bridge/Twig/Resources/views/Form/form_div_layout.html.twig This is where the bulk of the code is (currently). We are replacing the default Symfony Textarea widget:
with GrapesJS:
This code can easily be refactored, but this was the minimum code needed to get the demo working during the Hackathon. During the Hackathon I would manually copy the CSS from the "Edit" button back into the Twig source for the postCSS Textarea (where there is currently a Comment). I would also manually store the HTML and CSS into the database table, as a single value so that the frontend render could be tested. Realistically this may need to be stored as a separate DB column.
I was not able to use the "JSON" storage option that was discussed on the day, I couldn't find any way to implement this which made sense to me (based on rushing through the documentation). It didn't seem necessary to me, as the GrapesJS Editor was perfectly capable of re-rendering/editing existing content as long as the HTML and CSS were passed back to it as separate values (using
setComponents()
andsetStyle()
respectively).