# How to style existing and create custom grapejs blocks?
**URL:** https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003
**Category:** Product Support
**Created:** [May 13, 2023, 10:29pm UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003 "2023-05-13T22:29:52Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@peter\_k](https://forum.mautic.org/u/peter_k)
#### Post date: [May 13, 2023, 10:29pm UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/1 "2023-05-13T22:29:52Z")
**Your software**
My Mautic version is: 4.4.7
My PHP version is: 8.0
**Your problem**
My problem is: How do I style the existing grapejs builder blocks?
E.g. the `navbar`, `text section` or the `countdown` block?
Is it possible to create additional blocks? If so, how?
---
### Author:  [@dirk\_s](https://forum.mautic.org/u/dirk_s)
#### Post date: [May 14, 2023, 8:27pm UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/2 "2023-05-14T20:27:50Z")
So far we havn’t identified a way to load custom blocks provided e.g. via the theme. Similar problem as with the legacy builder… if you have a carefully crafted and tested mail template, addind elements from the blocks builder will probably break the code.
I never understood, why there is a way to alter blocks in GrapeJS - but only global through core files. Not dynamically through a loaded theme. Maybe a custom plugin is needed to achieve that?
Did someone else came up with a smarter solution?
---
### Author:  [@mzagmajster](https://forum.mautic.org/u/mzagmajster)
#### Post date: [May 14, 2023, 11:43pm UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/3 "2023-05-14T23:43:59Z")
Making a mechanism to dynamically inject JS into core JS files is a security risk.
With a good approach you can add custom blocks by modifying relatively small part of core JS files.
---
### Author:  [@peter\_k](https://forum.mautic.org/u/peter_k)
#### Post date: [May 15, 2023, 8:51am UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/4 "2023-05-15T08:51:01Z")
> [@mzagmajster](#):
>
> Making a mechanism to dynamically inject JS into core JS files is a security risk.
That is true. On the other hand, it lets GrapesJS to fall short of its capabilities. Why do the hard work of adding a great, flexible editor to the backend if you can’t extend it and add new blocks?
> [@mzagmajster](#):
>
> With a good approach you can add custom blocks by modifying relatively small part of core JS files.
What would a good approach look like? I’m wondering because, most of the time, you shouldn’t directly modify core files. I’m guessing that my changes could, or would, be overridden by a future update?
---
### Author:  [@mzagmajster](https://forum.mautic.org/u/mzagmajster)
#### Post date: [May 15, 2023, 11:31pm UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/5 "2023-05-15T23:31:56Z")
Its not that you cannot extend it, it just that since this is a third party tool that was brought into Mautic it does not follow exactly the same philosophy as the rest of the mautic codebase when it comes to extending.
And as said before whatever mechanism of dynamically extending the JS code would probably have to be recompiled in some way, as those mechanisms in production are unnecessary and might even be dangerous.
You can extend the GrapeJS following the docs: \< [Component Manager | GrapesJS](https://grapesjs.com/docs/modules/Components.html#update-component-type) \>.
I would consider putting custom block definition/declaration into separate custom file (something unique).
Then you just import this file into the main file (I think its called builder.service.js) and use the new (custom component/block) or whatever you created and register it with the GrapeJS.
When the update comes you just need to update builder.service.js (most of the time) with the imports and minimal modification (and recompile it of course).
Side note: Whatever mechanism of extending mautic would add here, I think we would not reach the plug-and-play state and you would still need to pay extra attention to it.
Regards, M.
---
### Author:  [@dirk\_s](https://forum.mautic.org/u/dirk_s)
#### Post date: [May 19, 2023, 9:41am UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/6 "2023-05-19T09:41:41Z")
Thank you very much for your insights @mzagmajster … Looks like some non trivial development, if one would also to make it dependent on the selected mail / page theme.
A side note: I always struggle to explain clients not to use the builder with their “handcrafted” mail templates, as it would break them. And always I earn misunderstanding (which I totally understand) and wonder how we can do it better. (Even the proposed way is adding extra to each maintenance operation when upgrading.)
---
### Author:  [@peter\_k](https://forum.mautic.org/u/peter_k)
#### Post date: [May 22, 2023, 8:59am UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/7 "2023-05-22T08:59:38Z")
What’s wrong with using the “handcrafted” templates (assuming they made it with MJML)?
---
### Author:  [@mzagmajster](https://forum.mautic.org/u/mzagmajster)
#### Post date: [May 22, 2023, 5:04pm UTC](https://forum.mautic.org/t/how-to-style-existing-and-create-custom-grapejs-blocks/28003/8 "2023-05-22T17:04:55Z")
If you make into reusable components, its easier for clients to do the email sending for themselves.