Different menu (Wayfinder) for different contexts

Hi folks,

I made a site with two contexts, because I need a different menu for some resources (blog, subsite, etc.). The default context is accessible via http://domain.tld, the other via http://domain.tld/subdir.

I added site_url and base_url in the second context settings. This is the Wayfinder snippet for the second context:

[[Wayfinder?
&startId=`6`
&level=`2`
&contexts=`services`
&scheme=`full`
&outerTpl=`Wayfinder.outerTpl`
&innerTpl=`Wayfinder.innerTpl`
&parentRowTpl=`Wayfinder.parentRowTpl`
&innerRowTpl=`Wayfinder.innerRowTpl`
&rowTpl=`Wayfinder.rowTpl`
]]

But the menu of the second context is blank. Also the site_name is still that of context one. I created a different site_name for the second context.

What am I missing here?

You'll also need to make a site_name setting in the Context settings.

Do you have a plugin or some other way of switching the context? The index.php has

so you need to explicitly switch the context.

No plugin or script. I did add a site_name.

It just doesn't show the settings of the second context. The URL's of the second context are correct: http://domain.tld/subdir/resource.html

Wish there was a more elaborate explanation or manual on contexts. Most howto's in MODx are way too brief.

If you don't have some way of changing the context, then MODX by default initiates the "web" context and that's what it's working with. Specifying the context to use in the Wayfinder snippet will indeed cause it to build the links from the given context, but when you try to load the page MODX is still working in the default "web" context - it's in the index.php file. You have to have a snippet or a plugin to switch the context.

http://chsmedien.com/blog/2014/01/new-context-routing-plugin-for-modx

Ok, thanks for the explanation. I thought contexts had these features themselves.

I installed the XRouting extra, but it doesn't work. I have these settings:

Context 1 (web):
http_host- /
base_url- domain.tld

Context 2 (subdir):
http_host- /subdir/
base_url- domain.tld/subdir
site_start- 6
site_url- http://domain.tld/subdir/
site_name- Subdir

BTW I did not activate friendly URL's yet, because I'm working on a test-subdir and the host won't let me add a htaccess in that subdir (and I'm not allowed to work in the root). Could that cause the issue? [ed. note: handjes last edited this post 11 years, 7 months ago.]

Context 2 should be your context, not 'web'. Or was that just a typo?

I don't know about friendly URLs and XRouter, but I would have serious questions about "not allowed to work in the root" and not being able to add a .htaccess file. Unless, of course, you're not using Apache as the web server.

Question. Is this truly a subdirectory installation, or is it a subdomain? How do you access the main 'web' context, or the Manager for that matter? domain.com/subdir/... or subdir.domain.com/... ?

Typo . Fixed it above.

Don't worry about the htaccess. It's just I dont want to mess up the current live site. Yes, it's Apache.

It is a subdir installation. Actually, the entire site is in http://domain.tld/new-modx-site/. Context 2 is in http://domain.tld/new-modx-site/subdir.

Ok, I set up a context in one of my localhost installations, "localhost/revo233/testing/". After some initial fumbling, the XRouter plugin worked perfectly.

'web' context settings (taken from actual setting tag output, e.g. [[++http_host]]):
http_host: localhost
site_url: http://localhost/revo233/
base_url: /revo233/
site_start: 1

'testing' context settings:
http_host: localhost
base_url: /revo233/testing/
site_start: 24

Then in System Settings I changed "link_tag_scheme" to "abs", and in my pdoMenu snippet I added the &scheme=`abs` property to get the menus generated correctly.

And no, it can't work without Friendly URLs being enabled.

Ok, glad to hear. Where did the 'link_tag_scheme' come from? Mine was set to '-1'.

I completely forgot to mention that I'm working on a test environment with IP forwarding in my hosts file. So I'm actually not working on the actuel server that the domain currently 'belongs' to. Maybe that's causing the problem with the redirecting?