AI OnAI Off
HTML in Editorial Block
I would say it is bad practice for the reasons you mension; easily to break.
One solution is to create templates or plugins in TinyMCE that inserts blocks of html with dummy content, that can be edited.
Also blocks in episerver can be utilized in TinyMCE, if that is an alternative.
Jun 01, 2021 11:26
Working in agencies I ALWAYS try to keep the HTML / CSS / JS and anything developmental related out of the CMS. The aim of the CMS is to create a flexibly tapestry of pages and blocks with the markup you need and if there's changes to front end code it should be implemented and tested (such as WebVitals scores, accessiblity, performance, SEO) before it's lanuched.
You can create a CI/CD pipeline to rapidly deploy to an environment if needs be.
That being said a half way house that's good is David's virtual template system https://www.david-tec.com/2018/07/virtual-template-system-for-episerver-relaunched/ which gives the ability to edit templates live in the CMS. This can be restricted so only allowed users edit it, although as mentioned I would always edit on non production and test impact of changes before doing on production.
Jun 02, 2021 13:57
fuji
- Jun 02, 2021 16:34
"The aim of the CMS is to create a flexibly tapestry of pages and blocks with the markup you need..."
What if editor needs slightly different or very different markup, let's say for a new landing page - are you creating new page type for that?
***
My idea is to have minimum amount of page types, mainly with content areas for blocks. Those blocks can be narrowed using Display As options (https://github.com/valdisiljuconoks/EPiBootstrapArea) as well as may have properties like "string BgColor", "string Color", maybe "string BorderRadius" in case of "ButtonBlock" and so on... Therefore editor can create different markups (differently looking pages) using same page type... does this make sense?
What if editor needs slightly different or very different markup, let's say for a new landing page - are you creating new page type for that?
***
My idea is to have minimum amount of page types, mainly with content areas for blocks. Those blocks can be narrowed using Display As options (https://github.com/valdisiljuconoks/EPiBootstrapArea) as well as may have properties like "string BgColor", "string Color", maybe "string BorderRadius" in case of "ButtonBlock" and so on... Therefore editor can create different markups (differently looking pages) using same page type... does this make sense?
Scott Reed
- Jun 07, 2021 8:12
Yes, I have built theming options many times in to the site settings, pages and blocks although I would usually expose these via an Enum and a fixed set of theming options and have some validation. I work in full service agencies and as well as creating flexible modular systems making sure the design are adhered to is often a primary goal. If you're creating web safe designs they are usually created to be accessible which means specific colours and contrasts and you want control over background and foreground style application. I would usually build a CMS site to be flexible but also with a certain level of protection so users can do bad things, else you'll else up with sites that look like MySpace lol.
Therefore for me it's usually a combination of theming and layout options created at these 3 levels but with validation and logic to also make sure it's done correctly. Any new styles, themes and layouts need design, UX/CX before being built if you're making a commercial website as you want the user experience to be good and easy to use.
However that being said if you don't care about any of that adding fields for style control will work, it's just not anything I would do personally. Also a note that I have a module https://world.episerver.com/blogs/scott-reed/dates/2018/4/controlling-episerver-display-options-via-a-custom-attribute/ that is also good to use in tandem with things like the bootstrap area that allows you to specifically restrict the display options per block which is useful is creating lots of different display options.
Therefore for me it's usually a combination of theming and layout options created at these 3 levels but with validation and logic to also make sure it's done correctly. Any new styles, themes and layouts need design, UX/CX before being built if you're making a commercial website as you want the user experience to be good and easy to use.
However that being said if you don't care about any of that adding fields for style control will work, it's just not anything I would do personally. Also a note that I have a module https://world.episerver.com/blogs/scott-reed/dates/2018/4/controlling-episerver-display-options-via-a-custom-attribute/ that is also good to use in tandem with things like the bootstrap area that allows you to specifically restrict the display options per block which is useful is creating lots of different display options.
fuji
- Jun 09, 2021 9:37
Thank you for sharing details around how you handle all this. I'm re-reading it so could come up with best approach for me.
Hi all,
I have a general question - is it bad to use extensive amount of custom HTML code inside Editorial Block? Because like that we can create almost any kind of layout/look/block, just by using Editorial Block... But then it happens to have containers, rows, cols and so on, which is easely breakable when actual content/text/images are being edited not through "Source Code" mode.
Also, how do you structure your web page content - do you create everything using page properties or is it few content areas with adjustable blocks? What is the best way to maintain unified look, adjustments flexibility, development speed but also to keep editing easy for editors?
Thank you!