[IMPLEMENTED] Custom Editor URL Administration

Hi Sebastian,

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.

Thanks for your consideration.

You can just host the editor as asset and then use a relative URL.

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.

Many thanks for your reply! Hope you are well.

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.

Great - I would love to contribute. Let me look into this a bit more. I haven’t pulled the src in a while. Let me see what I can cobble up.


1 Like

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.

Btw: What do you mean with interpolation syntax?

I am about to replace the whole patterns screen with this:

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,
1 Like

This has been implemented, but not deployed yet.

1 Like

This topic was automatically closed after 2 days. New replies are no longer allowed.