As a modern, open-source content management system, Neos is constantly evolving to meet the needs of its users. With the feature freeze deadline (2023-04-03) for the upcoming 8.3 release just around the corner, we want to hear from you about the features and improvements you’d like to see in the next version.
As members of the Neos community, your feedback is essential to the platform’s continued success. Whether you’re a developer, content creator, or user, your ideas and suggestions can help shape the future of Neos. We’re particularly interested in hearing about the most wanted and realistic (time wise) features that you believe will make the biggest impact for Neos users.
So, please take a few moments to share your thoughts and ideas with us. Your input is crucial to making Neos the best it can be. The deadline for submitting your feature requests is approaching fast, so don’t delay. We appreciate your participation in the Neos community and look forward to hearing from you!
I have often wondered which document tree expand and collapse behavior I would prefer as an editor. Since I’m using PHPStorm, I’m one hundred percent sure: its file tree navigation is my preferred one. I would love to see it in the Neos backend:
Entering the Neos backend for the first time displays the collapsed tree.
Expanding a node displays all its (collapsed) children.
Collapsing a node collapses all its descendants.
Exiting the Neos backend saves the tree in its state per editor and displays it in that state again when that editor is re-entered.
The editor can expand the entire tree with a new “Expand All” tree navigation icon.
The editor can collapse the entire tree with a new “Collapse All” tree navigation icon.
Switch to raw content mode and back on content node level.
It would be great to have a switch in the node controls that allows to render this node (incl children) in the new raw mode. That would be a nice unified way to make sliders etc. editable without hassle.
Also: this could be a better fallback in the backend for nodetypes that have no renderer yet. Much nicer than the error message we show currently.
I would like to be able to share a link to a non-live workspace with a third party. The third party would be able to browse the workspace like a regular visitor, as long as the link is valid.
(Just as an idea, would need more specification.)
For certain purposes there is a demand to store information permanently in a tree structure. This can be achieved by mapping Neos Folders to the CR’s Node path tree. A real example for this demand is the new media ui (by @sebobo).
Make Inspector property editors available in custom Neos Backend Modules
It would be awesome to simply be able to use some, or all, editors already available in the Content Module for those use cases as well. The ease/standardization of the integration itself but also the general possibilities of custom backend modules could be improved nicely with this. The UX for editors would be improved as well, as property editing UI elements would appear and behave in a standard way everywhere.
We use custom Backend Modules a lot, basically in every project where some external data needs to be imported and enriched with content later on by the editors. They are Node based in most cases ( maintaining Nodetypes in a separate tree in the CR). Editing those nodes in the Content Module is not always a desired solution, depending on the use case. In almost every case we have the need for more feature rich property editors within those custom backend modules. Currently we implement them as custom solution then. For example the CKEditor for RTE functionality on rich text fields, or a custom integration of the media browser for the integration of Images/Assets within the Media Management.
Content Dimensions / Node Variants: Visual guidance for Editors
In a project with a multi content dimension setup with configured fallbacks:
As an editor it is not so easy to see/understand the relation or difference between a shine through node and an actual adopted node immediatley while editing. Shine though can be in effect for the whole document node type or for individual nodes within the content.
In such a scenario, it would be helpful to have the information directly available in the in-place editor backend view in a standard way for example:
A Shine trough node could be somehow displayed with some opaqueness and/or tooltips/labels for example to indicate that this node is content from another dimension. The visual guidance can then disappear once the node is edited and thus had been adopted in the current content dimension. Or it keeps on informing about the connection ( being a node variant ) to the node in the other dimension. Additionally it could maybe further improved to indicate somehow, that once a node in dimension B is deleted, it will shine through again then from the other dimension A.
Currently editors need to know and understand the concepts in action - visual guidance of some sort, could assist the editor while editing content in connected dimensions.
There’s a great inspector plugin available offering some guidance and resolution of those node variant connections in the inspector, however this requires inspecting individual nodes. It may be also not self-explanatory enough for editors not to familiar with the node variants concept. The plugin may be a good technical starting point for a visual guide implementation in that area: https://github.com/Flowpack/Flowpack.NodeVariantSelector
it would be great if we could integrate something like the awesome FlatNav to the core, but with the option to edit/view nodes from a different CR root.
This would make it possible to manage core assets that are not necessarily document nodes of the current website (e.g. imported job offers, addresses, products, …)
There are some changes our editors have suggested for the dimensions menu:
If there is only one dimension, you have to click two times to open the actual dimensions list. The first and only dimension should either open on default when clicking the dimensions switcher or the whole secondary dropdown logic should be switched to only show the one list of the dimension
To check if a document already exists in a different language editors have to click through all dimensions right now. There could be some kind of “active”/“inactive” color coding in the dimensions dropdown to show if clicking on the link would create a new document.
Sometimes editors want to open a different dimension in a new tab. For that, they have to open a new tab by hand and then switch to the right dimension. It would be nice if they could use right click/center click to open the document (if it exists) in a new tab.
Hi as the title suggests, we are still new to the framework and some of the following ideas may already be possible or are being addressed. If so, a link or a push in the right direction would be very appreciated. So without further a dew:
Separation of YAML files for sites: We are running a multi site deployment, which are all using the same node types and also the settings are similar. However, every once in a while a site needs something special. Hence, we would like to add/override it in the site package. Yet, in the current implementation all sites are subject to this feature/override. It would be great if sites could have their own, isolated configuration context.
Drag and Drop to customize the with of the sidebars: We are huge fans of the overall layout and structure of the neos backend. However, we use large screens and hence have extra space (as our content is not as wide) for the sidebars. It would be nice we could adjust the width dynamically in the same manner as the height/proportion of the document and content tree
Validation of complex structures: We are aware of the validation in the inspector and also the validators of the flow framework and how to write them. Yet, these only cover single attributes by “default”. We often have the job to validate an entire document according to business policies which includes parsing of text in combination of set content classes and so on. Certainly there are several ways to approach this and this would need further work to get things specified.
Extended customization of the media module: The media module already provides nice features and being shipped out of the box, I feel a bit guilty of bringing this one up. Here, it would be great to have the ability to extend the main image model with additional fields (in our case especially license properties) to be able to manage these in a central place (maybe this is already possible, if so every hint is welcome). Another great feature would be batch processing of the meta fields of images. Often our editors upload several images, which are used for different systems/channels, but the caption or title is always the same.
Usability of the date time editor: It would be great if there could be an option to display a 24 hour format as well as being able to input the time directly via keyboard, instead of the several clicks currently needed
Wishing for things is of course easy, so if one of the above ideas sounds plausible to the rest of community we/I would be happy to participate in their implementation.
To use the Neos CMS as a documentation platform for an API, as is the case for example with https://docs.neos.io/, and to support one documentation subtree per API major version, as is the case for example in the reST documentation at https://neos.readthedocs.io, it would be helpful to provide the editor with a page comparison tool to easily migrate changes in the latest major version documentation subtree to an older one. The comparison tool should highlight the differences and allow a difference to be propagated in either direction. A perfect abstraction layer would have to be found in the Neos CMS to include this tool (as it could be more complex than comparing two text files), and ideally there is already a third-party Composer package for comparing text. For the visual representation I have the PHPStorm comparison tool in mind.
We want to express our gratitude to all of you who took the time to share your ideas for new features that you would like to see in the CMS as editors. We have received a lot of great suggestions and it’s clear that you are all passionate about making NeosCMS even better.
We would like to assure you that we are carefully reviewing all of the suggestions and considering how we can implement them in future versions of NeosCMS. However, we must also acknowledge that some of the ideas are more challenging to achieve than others.
Please know that even if we can’t immediately implement all of the ideas, we are committed to continuously improving NeosCMS and adding new features that will benefit our users. Your feedback is invaluable to us, and we appreciate your support and involvement in the NeosCMS community.
Thank you again for your contributions and for helping us make NeosCMS the best CMS it can be.
Feel free to add more feedbac
I would love to be able to Drag & Drop an asset on the page header (Document Node). Then I would want to define on my image property that this is the drag and drop target.
Same idea, on a download section (content node) I would like to drag pdfs and they are added to my resources property.
Drag & Drop for Node Creation
If I drag an asset between two content node types, I would love to define default node creations - if its one image, I want a Image NodeType, if it’s multiple an ImageGallery, if they are PDFs Downloads. You can see a good implemebtation of this in Squarespace.
Good Inline Editing Validation Handling
If I define a max length on an inline text propety, sometimes the error message is not shown. In all cases it’s just not saved, but I can change to another page and the content is lost.
There should definitely be a possibility like that, but I don’t think this should be part of the document tree area. I’d rather suggest e new backend module under “Management” to manage Nodes, like Sitegeist.Taxonomy, but generalised, using the functionality presented in GitHub - Flowpack/Flowpack.StructuredEditing: Structured Inline Editing for Neos CMS
This will definitely not be ready for 8.3, but for the meantime I created a little package myself, because the news documents in the document tree were one of the things that bothered me most in the backend.
at the moment it can’t do more than FlatNav, but I plan to add pagination and sorting soon, I guess these functionalities are harder to fit into the sidebar.
Currently I also use a custom view switch, but if it would be possible to switch to raw content mode (or custom edit modes) on node level, like suggested by @mficzel, the DocumentCollection can also be implemented using the core edit mode functionality.
Sometimes I like to add some functionality for backend editors (like manually syncronising content with an external source), currently I can add that to the document template and display it only in the backend. I can even do a little hack to make it look like native backend elements like I did above with the DocumentCollection.
But I wonder if it wouldn’t be possible to add a property to Neos.Neos:Page where developers could add backend functionality maybe to the secondaryToolbar.
Provide a way for placing Nodes inline, within text copy.
Possible use case:
Brand consistency management across a website
A user manages a collection of predefined Nodes with
URLs
common text passages
Brand and Product names
These can then be placed inline within text areas anywhere on the site
as actual Nodes, that consistently extend the Node tree and can be “walked to” programmatically.
I am thankful for our community brainstorming session for Neos 8.3. We gathered a list of potential features, even if some are too complex for the upcoming release.
After much discussion at the Neos Sprint, we have identified two quick wins for implementation in the upcoming release:
Improving the usability of the dimensions menu and the date time editors.
Additionally, we have identified two other potential features for Neos 8.3 (time permitting):
a shareable preview link feature
and the ability to drag and drop assets onto existing nodes.
We are excited to see these features come to life in Neos 8.3 and hope they will enhance the user experience for our community.
Thanks for all the fantastic ideas. The remaining points have been discussed and will be scheduled for 9.0 and later.
