Hi.
I have a noob question about contexts. I don’t have any reason to use them yet, just testing how they work on fresh installation. I created new context and created test document in it. And it is not shown when I try to view it (instead the default home page is shown). When I moved it to ‘web’ context, it is shown correctly. I don’t get what is the difference.
I thought I missed some context settings, but ‘web’ context also doesn’t have any.
Access permissions also are the same.
What am I missing?
1 Like
In the front end, you’re a member of the (anonymous) group. If you go to System (gear icon) -> Access Control Lists -> User Groups & Users tab, you can right-click on the (anonymous) group and select “Update User Group.”
Click on the “Permissions” tab.
You should see an ACL entry for the ‘web’ context. That gives members of the (anonymous) group access to that context. You need to click on the “New Context” button and create an ACL entry just like it for your new context. You may need to flush permissions and log out all users (on the Manage menu) before your changes take effect.
You may also want to create Context Settings for your context, which will override System Settings with the same key – settings such as site_start, error_page, etc.
FWIW, I try to avoid having multiple contexts unless there’s no alternative because it tends to complicate things (as you’ve noticed).
I love contexts, but yes you do need to configure them.
At minimum they need base_url, site_url, http_host, site_start, and error_page settings on the context. The combination of these determines your URL for the context and helps MODX serve it.
But just the settings is not enough. You also need to tell MODX when to switch contexts as it won’t do that out of the box. xRouting is a great extra for that. When you install that through the package manager, it uses the settings you already need to determine the URL, to handle context switching too.
There are different use cases where contexts are great to use. Multi lingual sites. Multiple independent sites managed by the same people. Subsites, for a blog/support/intranet/digital signage.
Maybe to break it down even more, MODX comes with the two main contexts web and mgr. Contexts are made to define certain areas of your site to be able to define user access to those specific areas via the different ACLs (User Groups, User Roles and Access Policies).
By default the web context refers to the front-end of your site, so usually everything your regular visitors will be able to see. As @bobray mentioned above, the ACLs for this context also define how much not logged in users (anonymous) are able to see.
The mgr context refers to the Manager, to the back-end of your site. Usually you don’t want any random visitors to change your settings so the standard setting for the Anonymous Group has no access to the context mgr. If you want to add any editors for your page though, you would assign them to this context and give them the needed access.
I have not come into the need of creating additional contexts yet, as MODX ACLs are very powerful and can therefore define very precisley who should be able to edit/view which resource. So I would suggest as well, that if you don’t really need additional contexts, then you’re probably better off working with the existing ones.
If not done already, you can check the Docs for more information:
https://docs.modx.com/revolution/2.x/administering-your-site/security/policies/acls#ACLs-ContextACL
Thank you for your answers.
I checked it, and my new custom context already had the same permissions as web context: Member - 9999, Load Only. I tried to flush permissions and log out all users as you said, and I see no difference.
I also added context settings site_start, error_page, base_url, site_url, http_host. Unfortunately without any improvement.
What I want eventually is a multilingual site. I read that the common way is to use Babel plug-in, which requires contexts. I’m new to Modx, and I first decided to understand what contexts are and how they work. Based on description, I understand that context is just a set of settings (new or overrided) applied when processing requests. But I just don’t see it works this way. I have default web context and created another one, which seem to be equivalent based on all their properties like context settings and permissions. But when I move document from one context to another (in Resources tab), the page is displayed in one case but not in another.
Is it a requirement to switch contexts using some plug-ins? If I create document in specific context at Resources tab, isn’t it should already be assigned to it by default?
Isn’t there some troubleshooting log to understand what is going wrong? I looked in Manage - Reports - Error Log, but there are no any errors.
What I actually see is that when I use View command on document from my custom context, it shows page specified in error_page setting from ‘web’ context. It is not even error_page from this custom context.
As I said, this is almost a fresh install. I don’t remember to change any significant settings. I can reinstall if needed. But probably I just don’t understand contexts correctly.
Say, if I have absolutely fresh installation, and just duplicate a ‘web’ context, and add a document to that new context at Resources tab, then should it be available using ‘View’ command?
First, make sure your other context resources are published.
Yes, there is a function $modx->switchContext(‘context_key’) which can be used in a plugin. If your users are logging in, you can avoid that by logging them in to all front-end contexts. You do that by adding this property in the Login snippet tag:
contexts=`web,othercontext`
Otherwise, you do need a plugin to switch contexts on some basis. The multi-language extras should do that for you once you’ve configured them. My sense is that Babel is not most people’s first choice for multi-language sites. Mark has mentioned XRouting, there is also migx-MultiLang and Mark’s ContextRouter.
I was able to make pages from another context accessible by using plugin that switches context.
This is just not very comprehensible. Visually documents are already located in that context in manager console. Still they don’t work until you use plugin to switch context from php code.
There are different ways of handling the frontend routing, from automatic based on browser language to based on a subfolder, to having a separate index.php on different virtual hosts. If MODX out of the box would route the contexts, I’m not sure we would have these different options today.
It’s definitely a little learning curve when you need third party extras to use core functionality, but the same is true for other parts of MODX… Menu generation for example. You can layout the menu through the resource tree, but you need a Wayfinder or pdoMenu to output it to the site.
If you’d like to get a multilingual site with different contexts up and running quickly, try the multiLangSetup extra. Install it on a blank new MODX site and it will automatically configure everything for you.