Shared/global schema

Feature Requests
#1

While this is similar to [IMPLEMENTED] Schema content part / mix-ins / inheritance / snippets, it is not the same …

Let me outline our use case to easily give an idea of what gap the feature would fill: We manage a lot of static sites and are migrating to Squidex as the content backend for their generation. We use a Wordpress/Gutenberg style block system for the content. In the schema we have a page type, it has a collection field for components and we have a bunch of different components defined for things like images, carousels, markdown, cards etc etc.

Since we reuse the components across sites we also need the same - or a subset of the same - components and generally we would have identical page templates as well - with SEO fields etc.

Each site is it’s own project in Squidex and while you can copy the schema for a single type at a time in the editor, or use the cli to clone a template project etc, it would be great if they all shared some part of the schema. That way all the sites will stay up to date if we update or add components etc.

I’m guessing it wouldn’t be that much work to show the types from a schema with a predetermined name as well as the project local types while editing? Less sure as to how the data is stored and how much that logic relies on all types being in the same namespace as everything else …

As a workaround right now we have cloned the templates repo and pointed our instance to that clone. We can have a template project in Squidex that we keep up to date with all the components etc, use the cli to sync it as it changes, and update the repo with the changes. That way we can easily create a new project using the up to dat template. But this still doesn’t solve the issue of keeping the types up to date in existing projects - not without some extensive scripting using the cli at least. This approach also copies the exact same data across hundreds of sites, which won’t make anything faster in the long run :slightly_smiling_face:

#2

I would normally be happy to open a PR for this from our side. But we don’t work in .NET or Microsofts stack at all, so unfortunately I don’t have the technical skills this time.

#3

It is actually relatively complicated. I am not sure how to solve these 2 problems:

  1. How to reference a shared schema?
  2. How to solve security?

I think the easiest way would be to do it the following way:

  1. You have to assign all apps to a team.
  2. You have to mark the schemas as shared.
  3. You have to make the app as shared in the team. (Not sure about that).

You might run into issues with duplicate schema names that are not easy to detect.

As a workaround you could deploy a small container that makes the sync and trigger that via a rule.

#5

I’m guessing you can’t have name conflicts in schemas for the same app today? So if I have an app that contains the shared schemas, or have the possibility to mark an individual schema from an app as public, you would expect it to check for conflicts at the creation point and refuse if any conflict exist.

If we assume I can mark any random schema as public and that the structure would be that there exists a hidden app (if a parent app for schemas is needed) that holds the shared schemas. When I mark a schema as public the system would have to check if that name is globally unique, if it isn’t it would throw an error and I would have to rename (or recreate, since we can’t rename) the schema and try again. If it is free it could be moved to the hidden public apps schemas and removed in the current app.

When listing schemas you would include the public ones along with the ones created for a specific app and that would basically be it. Since the name is unique you could just reference the schema on name. As for security you could have permissions to allow users to make schemas public and edit/delete public schemas. I assume similar restrictions apply for schemas in a single app?

I fully admit that I don’t know the current data structure :smile: But if you highlight any misconceptions in my proposal I’m happy to iterate. Or we can find another way to collaborate, if you think that the feature itself would be beneficial to the product…

#6

Please do not use the current thread to collect all kind of issues. If you want something else to discuss, create a new topic.

#7

Sorry. I have moved that question to a separate support request. Any thoughts on my reply on the actual feature request?

#8

Sounds reasonable and I will work on that as soon as I have time.