Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
This is really cool! I love the UX of the layout interface for the Section properties.
Is there a way to disable the CSS form field? Applying CSS directly in the the CMS for Portal Engine sites was something I found to be a big anti-pattern and a maintenance nightmare over the long term.
I could see how it might be beneficial for prototyping or smaller sites, but keeping code in source control is one of the best features of Kentico Xperience + MVC.
Sean, a good use of this Xpandable Sections is for landing/campaign page creations which more likely would have some custom CSS that's different from the rest of the website. Thus I made the suggestion to Yuriy to allow front end dev/marketers to add some custom CSS just for the page to use without getting help from back end dev to change the main CSS.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
It's primarily for analytics / marketing platform tags, but we've also been using this approach to add <script> and <style> blocks for landing pages/microsite pages when they need something custom and that isn't found elsewhere in the site.
There definitely are pros and cons to having this type of content in Page Builder components vs Content-only Pages in the Content Tree (re-use, organization/governance, and discoverability being the primary benefits of using Pages).
Enabling coding in the CMS is something that is very convenient 👍👍, but it makes me nervous. It always follows the trade-off of short term efficiencies at the cost of long term maintainability and I've worked with enough Portal Engine sites to know how that turns out.
I agree. But for a website, there are the general pages which follow the long term maintainability and should be bit more restricted. But there are short term pages that doesn't follow the same pattern. As developers, we should make those options available. Then educate the users well enough to make the right decision :)
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
Something I've learned over the course of many many Kentico builds - if it's possible for a user to do something, they will do it, even if they shouldn't. I like to make the options limited to lead them down a path of success 😁.
Scoping this Section to Editable Areas on specific Pages/Page Types (or User Roles) would help in limiting misuse.
Custom styles were an addition recommended by the Xperience Consulting lead, however I considered adding a role permission to show or hide that. In a future version that could be added!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is really cool! I love the UX of the layout interface for the Section properties.
Is there a way to disable the CSS form field? Applying CSS directly in the the CMS for Portal Engine sites was something I found to be a big anti-pattern and a maintenance nightmare over the long term.
I could see how it might be beneficial for prototyping or smaller sites, but keeping code in source control is one of the best features of Kentico Xperience + MVC.
Sean, a good use of this Xpandable Sections is for landing/campaign page creations which more likely would have some custom CSS that's different from the rest of the website. Thus I made the suggestion to Yuriy to allow front end dev/marketers to add some custom CSS just for the page to use without getting help from back end dev to change the main CSS.
That makes sense for that use-case!
I just published a post showing how Widgets could be used to add custom marketing tags to Pages dev.to/seangwright/kentico-xperien....
It's primarily for analytics / marketing platform tags, but we've also been using this approach to add
<script>and<style>blocks for landing pages/microsite pages when they need something custom and that isn't found elsewhere in the site.There definitely are pros and cons to having this type of content in Page Builder components vs Content-only Pages in the Content Tree (re-use, organization/governance, and discoverability being the primary benefits of using Pages).
Enabling coding in the CMS is something that is very convenient 👍👍, but it makes me nervous. It always follows the trade-off of short term efficiencies at the cost of long term maintainability and I've worked with enough Portal Engine sites to know how that turns out.
I agree. But for a website, there are the general pages which follow the long term maintainability and should be bit more restricted. But there are short term pages that doesn't follow the same pattern. As developers, we should make those options available. Then educate the users well enough to make the right decision :)
Good points 👍👍
Something I've learned over the course of many many Kentico builds - if it's possible for a user to do something, they will do it, even if they shouldn't. I like to make the options limited to lead them down a path of success 😁.
Scoping this Section to Editable Areas on specific Pages/Page Types (or User Roles) would help in limiting misuse.
Custom styles were an addition recommended by the Xperience Consulting lead, however I considered adding a role permission to show or hide that. In a future version that could be added!