MODX 3 Feature Request - Allow an alternative to context key 'web' on install.

[muzzwood]

Feature request

Summary

MODX 2 currently relies on initialising the initial context with a key of web.
MODX 3 should allow renaming this.
I propose MODX 3 keep web as the default (for extras that rely on it) but optionally allow setting it to something else during install.

Why is it needed?

• Multi-lingual sites would be much easier to manage if the language code matches the context key for one.
• For multiple domain installations it would allow for meaningful keys.
  (There are potentially many more reasons but these are most relevant to me at least)

Suggested solution(s)

The ultimate solution would be to give contexts an id number as the primary key instead of a context key to be consistent with everything else, but I'm not sure how that'd be possible without breaking backwards compatibility completely. Perhaps also keep the context key field for the interim with an index on it, yet switch to the pk of id?

The second best solution would be to allow context keys to be changeable at any time however that presents a problem of how to initialise a context in the first place allowing MODX to load. (Actually, id numbers as pk would be better here because you could just $modx->initialize(1);)

The other solution would only allow the one-time change on install. Where if the default of web is changed in setup, the installer would modify the initialization code accordingly. After this, it couldn't be changed.

If this is something that was looked at before and put in the too hard basket, feel free to close this. Otherwise, what are people's thoughts on this?

[Mark-H]

The second best solution would be to allow context keys to be changeable at any time however that presents a problem of how to initialise a context in the first place allowing MODX to load. (Actually, id numbers as pk would be better here because you could just $modx->initialize(1);)

How about just changing the name of the context, which is the visible part that's visible to the user? Is there a particular reason that's not sufficient for a multi lingual site?

[muzzwood]

It's more for the developer than the user.

I used to have a function on my service classes for getting language keys and context keys and then mapping them. Nearly every db query would need me to join a table to a language table and then relate that to a resource on the correct context for that language.

These days I tend to create one context per language and just leave the web context sitting there without resources. (I've yet to find a way to reliably hide it due to the dynamically generated element ids - although having context groups in the future should remedy this)
Developing for multiple languages is a lot more enjoyable if the language key matches the context key I reckon.

[JoshuaLuckers]

I agree that it would be nice if we could rename the web context however I strongly believe it would cause more issues and problems then we can anticipate right now.

I propose to make hiding contexts possible (or less visible).

[theuros]

Not a bad idea, but I solve this issue by simply leave default web context for testing purposes or to hold js and css resources. For all other languages I create a appropriate named context.