Setting default context for websockets

Enonic version: 7.5
OS: YourOS

Hey

We are working on replacing the Default project in the content studio with a new project SSB.

When I test this locally, with creating new project, importing content and deleting Default project, it seems that the website works fine.
But we have a dashboard that uses websockets that now dont display any content. When I run getContext I see that it is still using context com.enonic.cms.default and not com.enonic.cms.ssb

Is there any possibility to define in one place what should be the default context?

Hello!
Default project is required for app functionality so it is not allowed to be deleted. We will add possibility to define default project in future releases.

@carnord Is there any specific reason why you cannot import your data into com.enonic.cms.default and change its display name from “Default” to “SSB”? As @asl said, Content Studio relies on the presence of com.enonic.cms.default, so you cannot delete it.

Was recommended to create project by Enonic to get new functionality with roles and rights, and layers.

Default project will give you the layers functionality. You can create a layer under the default project which will inherit its data etc. Layers under the default project can also be protected with specific permissions.

The only difference between the default project and another project created in the root is access permissions. For the default project it’s the same as before - users with “Content Manager” roles will always have access to it. So if you don’t need any advanced permission setup for your project, then I suggest you use the default project.

We have a advanced permission setup , which is probably why we were recommended to create a new project.

Ok, then just leave the Default project empty. Don’t delete it. With your advanced permission setup properly configured a user will always be redirected to correct project after login, so the empty default project shouldn’t bother you too much.

The Dashboard you are talking about, is that a custom app? If you want to fetch data from custom repo you can set context using the context library: https://developer.enonic.com/docs/xp/stable/api/lib-context

Yes Dashboard is a custom app that shows content from content repo. I have been testing to set context and add "run(context, () => " in the websocket listners and it works. But we have a lot of listners and many places we have to set run(context) , so that’s why I was wondering if there was any way to change the default context in one place :slight_smile:

There is generally no such thing as the “default context”. The repo context is based on the fact that you are performing rendering in the context of a site, which is within a given repo. The reason content API still uses “default” repo as by default (haha) is for backward compatibility. This functionality will be deprecated whenever XP8 is released.

No, you can’t change the context in one place globally. I’d suggest you define a simple wrapper function, where the required context is already set, and call it instead. I mean something like this:

runInMyContext(callback) {
    const myContext = {
        repository: REPO_ID,
        branch: BRANCH,
        principals: USER_KEYS,
    };
    return contextLib.run(myContext , callback);
}
// ...
runInMyContext(doSomething());
3 Likes

Thanks for all the great answers. I got the answers i needed and much more :blush:.
Now we know how we can solve it in the code if we switch to using project and have a empty Default project.
I think we have to make an assessment whether we want to switch to a project now, or whether we should wait until a later version when more arrangements have been made to set a default project.
Was very good to clarify that we must not delete Default “project”, and that Layers will work in Default “project” :slight_smile:

1 Like

There will never be a default project in the future. In the future, the “Default” project will actually no longer exist. So don’t think you will gain anything by waiting.

The “Default” project is basically deprecated, but we could not remove it without breaking backward compatibility.