Do you think it would a neat idea to provide a custom editor admin? All custom editor urls would be managed in this UI admin screen - with a reference or name.
As I copy down the CMS to lower stages, for example from PROD to DEV, the custom editor URLs would differ for an internal environment. I am having to edit each one of my schemas and update all fields using custom editor URLs. It’s a bit tedious.
I would like to just reference a name ${editor1} or a linked reference.
When I change a single editor, all the schemas using the same editor would use the URL referenced in a single place.
I have 8 custom editors, which live in it’s own .net core project.
These editors use a custom editor web API to perform a variety of tasks, like auth with Cloudinary, queries to solr etc.
It’s easier to host them as a tested application as they exist as field.html, field,js, field.css, + other relevant js files. These custom errors, also take a variety of queryparams to control their context etc.
It would be just great to be able to say add a list of them to a special section in Squidex applicationProperties.Production.json, and then reference them in the project at runtime using some interpolation type syntax.
We have a country - and itinerary lookup, which need to query a SOLR search repo.
This custom editor url gets used often and it would be nice to use add the url only once some place.
In the case of a Cloudinary editor for attaching image & video assets to fields, we use custom editor often enough.
Just wondering if you see the benefit of around this use-case with custom editors. They are a powerful piece of your offering, and I am just hoping around other ways to manage the editor setup.
I totally see the value. But I think the effort to make it work properly is relatively big. AppSettings.json or the configuration system is useless for the cloud so it needs to be a custom solution, something like patterns.
If you are motivated you could provide a PR by more or less cloning the pattern system.
I think we should replace the whole pattern thing with a UI-setting approach. Just one big object model / document which holds everything like patterns and so on. It is overly complicated right now to add more things.
I think I will also move a few app settings to this screen, e.g.
/*
* Hide the today and now button.
*/
"hideDateButtons": false,
/*
* Hide the Local/UTC button
*/
"hideDateTimeModeButton": false,
/*
* True to disable scheduled content status changed, for example when you have your own scheduling system.
*/
"disableScheduledChanges": false,
