We have just started to look at the scope of XP8, a release that will introduce breaking changes for the platform. Our goal is to minimise the number of features and changes in xp8, in order to make the transition as smooth as possible. However, on popular demand - we now reach out to you! (the community) with a simple question:
What are your top 3 desired changes/improvements/features for XP8.
NB! Non-breaking changes/features may be introduced both before and after XP8 - as such, your input is highly valued
NB! There is currently no timeline or planned release-date for XP8.
1. Schedule publishing of changes for already published content
2. Support for quick edits in content studio where you can edit certain content fields without loading the entire preview, similar to Wordpress quick edit. I guess the fields would require some form of annotation.
3. Support some form of advanced search (like NoQL), so I can do _path contains “/this/path/”, and sharing of those searches with others, for instance by using URL query parameteres
(The two first ones comes from CRM and marketing in our company, and the last one is just me )
Not likely all of these are actually breaking, but here’s my three in reversed order:
First take on data migration logic, like oldField -> newField and oldItemSet.field -> newItemSet.something, even system for moving fields between different content types, parts, and so on. Changing data modell would store some value in the node layer, this can be used to write upgrade modells for each version. Each version history entry is tied to a specific modell version and upgrading the modell would flag version history in a way so you cannot keep rolling back to older versions of the app (unless it could figure out/understand how to downgrade).
GraalVM (bye bye old ES5 and Nashorn), maybe even native Typescript controllers (with typing)
Possibility to deprecate parts/layouts and specific fields (don’t think that would break anything though).
This becomes a problem, when XP expects my controller function to be named delete, and I’m using JavaScript module syntax instead of CommonJS syntax.
(There is a workaround for this by naming the function something e.g del and doing export del as delete, but it dirty, and unintuitive for beginners.)
Solution: Let the delete controller be named something different
I’m working with SvelteKit at the moment and they have decided naming the DELETE controller del.
It can be a problem – when using JavaScript module syntax – that both the GET controller and the function in contentLib for retreiving content is named get().
The workaround is pretty simple, the developer can do import { get as getOne } from "/lib/xp/content" to name the imported function something else.
But… The two get() functions are used alot together. It’s maybe the most used pattern in XP-development. A get() controller, that returns page based data retreived by using get() from contentLib.
Possible solution 1: Rename
Rename contentLib.get to something different. It can e.g. be getOne or getContent (but then I would suggest renaming portalLib.getContent() to portalLib.getCurrentContent())
Possible solution 2: Alias
Keep the contentLib.get() function, but also create an alias like contentLib.getOne() that can be used by developers that want to avoid this collision.
Bonus: Other get() functions
There are more get() functions in XP, like in contextLib, projectLib, staticLib and taskLib that can use the same renaming.
The problem is that my IDE will suggest to me which library to import a function I typed from. And if I select an XP library, it will spit out a broken path with the wildcard in front like this:
import { modify } from "*/lib/xp/content"
And that kids, is why you shouldn’t do hacks!
Solution: Stop using absolute paths in XP8
Use another mechanism to resolve paths in XP8. I don’t know which, but moving away from Nashord will probably provide some good possibilities.
Add read only config for input types, or config, which allows to change input by some specific user/role.
Add possibility to allow different parts for different templates.
Enable exports.patch. Seems like it is not allowed to have patch endpoints atm.
Progressive JPEG support for portal.imageUrl
Better logic for custom URLs. When creating API using Enonic all routes stored in site.xml. Maybe add a possibility to store routes in different files and import them.
This is already in our backlog, closing in on the top of the list :-). May require XP8
Interesting idea, a solution might be to support editing of meta-fields like path, displayname and similar. I guess doing this from the detail panel would be the least intrusive approach? This would not require XP8 anyway.
Improved search in Content Studio is already in our backlog, and does not require XP8
Yes, “patching” is something we are definetly looking at - hope we will be able to fix it for XP8, or a later release. It does require changes to the storage core.
Graal is definetly on our list, we have a working prototype - now dealing with multithreading
Makes sense indeed. Added this one to the backlog (Does not require XP8)
Good idea, might be some pitfalls but we’re adding this to the backlog - no ETA. Does not require XP8.
This is a bit unclear - could you explain a bit more what you need? There is currently filtering for parts based on content types at least.
Good catch, we’ll fix this shortly. Does not require XP8
That would be nice indeed, adding to the backlog - Does not require XP8
Hi. You can use the routing library to simplify this, so for instance you would then create a sigle mapping: /api, and everything inside is handled by your router: Router Library - Enonic Developer Portal
I don’t think any of the options in the documentation can help me.
My problem is very specific to enonic-types, and being able to add types to the different library packages (like /lib/xp/content). Unfortunately my problems are passed on to anyone using enonic-types.
I think the only way to get the IDEs working correctly with library imports, is chainging the import path to have the same “shape” as node imports.
That doesn’t mean moving everything to npm, maybe some aliasing when resolving paths would do the trick.
But the shape of the path should be something like one of these:
import { query } from "lib/xp/content"; // unlikely to work from anywhere?
// or
import { query } from "lib-xp-content"; // like a package in npm
// or
import { query } from "@enonic/lib-content"; // like a namespaced package
I have found another issue regearding this.
And that is if I copy code from one file to another, the import of functions will be copied too, but it will be changed to be */lib/xp/content, and then the developer will need to remember to manually change it, or it will fail at runtime.
Parting thoughts:
Creating TypeScript-types for paths that start with a "/ " has been challenging. It took me over a year to hack it.
So since XP8 is in the planning, I was hoping you would consider changing the way we reference libraries so that developers can get better IDE support.
Dependencies for content used in macros. Now we can see dependencies for files and linked content only. Would also like to see if a content element is used across several other content elements when used in a macro.
Schedule publishing of changes for already published content.
Automatic updated URLs when changing title on a page, with automatic forwarding from old to new URLs.
We need more possibilities to style and manipulate the rich text areas. In its easiest way it could be a drop down on each component (table, heading and so on) where I can select between predefined styles.
Ideally I would like more options to how it is presented too. F.ex. Difi requires links to files to also include file type and file size next to the link. A way where we can manipulate what output we get from a Link without doing string manipulation on the output would be very welcome. I know the Difis requirements are obsolete right now, but it is still good practice and a lot of customers are asking for these things.
Sorry for being unclear about point #2 - I mean when adding some part into a region on a layout or a page, add some config, which can allow/restrict usage of some parts for this region.
)
