Would it help you if we introduce a toggle in the plugin settings menu where you can disable the “settings” tab for the block at all? Can understand, that you don’t want to make the client mess up with the paddings 
Here is a quick overview what we just shipped with the next update of the plugin and theme. The theme is a demonstration what the Content Editor can do. This update includes heavy support for forms as well, you can quickly create basic forms directly handled by the plugin, or you can utilize the new Tailor User Form Submission feature by inserting a Tailor form into the content.
The users who already bought the plugin might give us some feedback which of the following features might be the most useful for the next update:
- Meloncart integration
- Native companion app for iOS and Android (we have this internally, and clients love it)
- A/B testing utilizing the block visibility settings
- A tailwind-based theme (next to Dawn theme which uses Bootstrap 5)
- More focus on AI-integration (open for ideas)
Our todays changelog:
Breaking
- Twig filter
|contentrenamed to|rc_blocks
Features
- OFFLINE.Mall integration: product and category blocks, shop scaffold, styled Dawn shop pages
- Tailor submission forms (October 4.4+), Dawn appointment demo
- Tailor Entry List block
- RainLab.Pages 3.x support
- Map tiles: cache limit, region restriction
- Settings pages with tabs and cards; API switch moved to API Tokens
- Keyboard-first editor, distinct block icons
- Switches to hide the inspector’s Settings and SEO tabs
- CSS class presets
- AI: model picker, GPT-5.6 Terra defaults, image quality, timeout tuning
Fixes
- October 4.1–4.3 compatibility
- Security: submission uploads private, settings actions permission-checked, REST throttling per token
- Render caches keyed by origin, site, currency and customer group
- Editor: styled dialogs, undo/redo, unsaved badge, version restore of reordered blocks
- AI: full-field translation, site-aware links, readable errors
- Site copies get their slug (data update for existing copies)
- Local captcha, PDF block, accessibility and frontend performance
- Dawn: Turbo, JSON-LD, error pages, print styles, layout and contrast fixes
Hello
Tried to update :
during update :
In Plugin.php line 36:
Class "Renick\Content\Classes\Integrations\IntegrationManager" not found
Best regards
1 Like
Yes, got this bug report from another user as well. Seems some issues with case-sensitive file systems. Already rolling out a fix 
Sorry for that
for me as well… tried, purchased, and died at plugin.php at line 36, because, probably something like autoload not working correctly? or?
Please try again, the fix is rolled out now There was an issue with folder names containing capitalized letters 
install process is ok now. i guess. this ‘case-sensitive’ is likely linux based os servers
1 Like
Yes, but our e2e tests and projects run on linux/ linux containers, so wonder why it slipped through during the review. Multiple test instances were created. But now I’ve test cases for this, so shouldn’t happen again
Another options that would be great is an option to remove all default blocks. I want to have a great control over each block I want to provide to my customer so I want to define my own list
Also, I read that in the doc :
BlockManagerdiscovers definitions from three sources. On handle collision, the plugin definition wins (then theme, then event) — themes change presentation via partial overrides, never the content contract.
I don’t understant the choice to make the plugin definition wins over theme. 100% of the time, if you redefine something in the theme, it should wins against plugins. That’s the October phylosophy, the same that allow you to redefine default partials etc…
What I would expect in a perfect world is an option to disable all default blocks provided by the plugin. And the possibility to define my own list in content-blocks folder. And If I want to name my block like one in the plugin, mine wins (because I don’t want to prefix all my blocks with an arbirary prefix just to avoid naming conflict).
Would it be possible ?
The definition of the standard blocks shouldn’t be altered by the theme, because these blocks should be compatible between installations all the time. This enables content to be portable between sites, so for example our SEO people can prepare landing page templates.
The standard blocks are needed and wisely chosen for any use-case not bound to a theme. Or content which gets shared across themes. We also have a native framework for rendering these blocks natively in an app.
I agree that your use-case might be difference. The plugin is built to be extensible, I plan to expose some event you can listen to and de-register the standard blocks. An api for registering your blocks programmatically already exists. In the ui we can add a way to disable blocks from within the plugin settings.
The definition of the standard blocks shouldn’t be altered by the theme, because these blocks should be compatible between installations all the time. This enables content to be portable between sites, so for example our SEO people can prepare landing page templates.
I’m not sure to understand that choice because compatibility is strongly dependant of the theme. I work with tailwind, swiper… I can’t say that actually, the plugin is “portable” between sites. But that’s not a problem as I can create my own blocks. If I just have to prefix them to avoid naming conflict, it’s OK.
However, it would be useful, at least, to add a setting that disable all plugin blocks without being obliged to fill the “allowBlocks” property each time you use contenteditor field. It would allow to completely define my list of blocks, without having to inherit default blocks I dont want.
Best regards,
Another issue I found. How can I control the order of blocks category.
For example, text is at the end of the list whereas this is the most used block, it’s annoying to scroll down each time you want to add a title or a text, it would be great to be able to control that order
Another issue, the icon: parameter in block .yaml definition file is useless. It’ does not change the block icon that is inherited from the group
Edit
Another issue found (maybe a github repo would be a better place to make this kind of report)
checkboxlist is not a valid field type in your plugin, so there are no way to stock an array of checked options which can be quite limitating.
Edit 2
Another improvement would be to add balloon-selector as available field type. It provide better ux than dropdown to choose between small list of things, like Yes - No or Icon position front or back
Edit 3
Repeaters have a terrible display in dark mode
Edit 4
It would be great to have an option that remove bootstrap from being loaded for the editor. I use tailwind instead and I have some bootstrap reset that pollutate my styles (for example margin bottom on <figure> tag). If the plan of the plugin is to be flexible and let themers free, all external dependencies should be disablable.
Edit 5
(Sorry cannot post anymore cause can’t chain more than 3 post, so I edit this one, but a github repo would be far better)
I just noticed that tailor-list and tailor-submission-form block types are not customizable as there is no .yaml file. I can understand you need some php in order to retrieve the blueprint list, but you could do it be defining a “tailor” field type that would handle the logic to retrieve tailor blueprints instead of hardcoding the whole right panel
Edit 6
The richeditor field type don’t work when defined on the theme level, it just looks like the textarea
Thanks
1 Like
We have taken some notes and will consider some improvements based on your feedback. Thank you for sharing 
As I think it’s hard to make all use cases possible without blowing up the complexity, we are implementing more APIs at the moment, where plugins can hook up.
1 Like