Sam Dorman of the League of Young Voters just tickled my funnybone with a really nice idea for how to elegantly handle external redirects in Plone. I think this would be really easy to roll up into a nice user-friendly product that would have tremendous, wide-ranging re-usability. I’d love your thoughts on it.
Lots of online activism campaigns (like the League!) use generic content management tools like Plone for their main website and supplement it with more specialized online advocacy tools like Democracy In Action. It’s a winning combination that takes advantage of inexpensive, easy to use, best-of-breed tools.
The problem is that you can wind up with some messy URLs. For example, Democracy In Action URLs can look like this:
Ugh. Not very user friendly to stick into an email, a tweet or a blog post. What Sam really wants is to have a redirect URL like this:
That will automatically redirect you to the DIA page, with someVariable appended.
“Why not just do this with Apache rewrite rules?” I can hear you asking. Because Sam’s not an apache administrator, and doesn’t know how to write a regular expression (and neither do I). We want these to be manageable by people with Plone-user skills, not server-admin skills!
As Sam was telling me his story, a little vision appeared in my mind’s eye.
I imagine an “external redirects” control panel in Plone, where you would be find a screen that would let you add lightweight “redirects” that would have the following attributes:
- Redirect name (the “someAction” in the example above)
- Redirect destination (the external URL you’re redirecting to. Variables to be allowed with things like $1, $2)
- Enabled/disabled checkbox
I’d see this as a DataGridWidget or something similarly quick and easy. A site could have quite a few redirects to manage on a single screen, we’d need to use KSS well to avoid too many page reloads.
Plone’s current “Link” object supports some very basic external redirection, and we could extend that as described at PLIP 126, but I’m not convinced that this is a very ideal approach. The use case I’m trying to cover is about “placeless” adminstration of lots of links, not administering one-by-one links that are scattered within the content hierarchy. Also, implementing this functionality with full-fledged content objects creates some problems with viewing vs. editing mode, which I think can be avoided with a centralized, approach based on a utility tha could be overriden or extended.
The other concern that would have to be addressed with this approach is namespace collision. I think that could be avoided by doing a quick catalog search to make sure your proposed actionName doesn’t conflict with an existing content object (KSS validators to the rescue!). We might be able to entirely avoid namespace collision by letting you define a subdomain in the control panel (e.g. go.mydomain.org), and if possible push that into VHM.
We’d probably need to sanitize variables so that this doesn’t allow any weird injection attacks.