You’re developing a new MODX site. You want your client to preview the site and give feedback, but the
site_status System Setting is
0 because it’s not ready for public consumption.
Like everything in MODX there’s several ways you could accomplish this:
- Create logins for the clients, and give them "view offline" permissions. This is the best method when it’s critically important to eliminate the possibility of someone stumbling onto the site—but it requires them to login, and you to setup Users and ACLs.
- You could configure server access rules. Old-school IT pros and Enterprise security types prefer this method, but no one else does.
- For non-critical situations where the above is overkill, you can run a Plugin to override the System Setting on a request variable. The result would be exactly like the privacy setting on a Google Doc: Anyone With the Link Can View.
This post is about the third, "quick n dirty" method.
UPDATE [19/Aug/2016]: Added making the Resource non-cacheable on preview, to help with some buggy behaviour.
Make a MODX Plugin and enable it for the Events ‘OnHandleRequest’ and ‘OnLoadWebDocument’.
For the Plugin code, do something like this:
Break It Down:
- If the MODX Context in the current request has the key ‘mgr’, the Plugin does nothing.
- The switch statement ensures that if the wrong event is enabled, the code will only run when/if the event is ‘OnHandleRequest’ or ‘OnLoadWebDocument’.
- If the request variable specified has exactly the value specified, override the
site_statusand set the Resource as not cacheable.
- In all other cases no code executes.
Note that we’re not saving the System Setting, nor retrieving it. We’re only temporarily overriding the MODX config, for this request. We’re also not saving the Resource’s
Further note that we’re not using the value of the request variable in any way—only checking that it matches. That’s important, because you don’t want to expose your codebase to untrusted user input.
When the site goes live, or client preview time is over, simply disable or delete the Plugin. You can make the required URL parameter a long hash so that the chances of someone accidentally finding it would be near zero.
It can’t be overstated that for complex sites, where some code might actually depend on that specific config value (I can’t think of any, but that doesn’t mean it can’t exist), or where privacy of the developing site is a must rather than a slight preference, this workaround is not appropriate at all. Be sure you know what you’re getting into before you override the config like this.
That said, when the situation calls for "quick n dirty", here it is, in all it’s hacky glory :D