Friendly alias paths are nice because they let us group web pages into virtual directories. For example, we can tell the user that he will find
pages about physics under http://www.example.com/physics/,
pages about algebra under http://www.example.com/algebra,
and so on.
We also have another goal: As a web site gets revised, pages will get outdated. These pages should no longer appear in the current menus, but THEIR URLS SHOULD NOT BECOME INVALID. Instead, anybody accessing one of the outdated pages should see something useful; for example, the same outdated content with a statement that’s it’s no longer current; or some information suggesting where updated content can be found; or, at worst, an automatic redirection to a related page. This keeps the web tightly connected and users don’t get frustrated chasing old links.
But when we revise the web site, we don’t want to see the outdated pages in MODx’s manager’s menu tree in the original place, as this will clutter up the menu tree. Over a period of time, outdated pages may well outnumber current pages, so we definitely want to move the outdated pages out of the original location on the manager menu tree. We want to see the outdated pages in a different branch of the tree. e.g., under
www.example.com/physics/outdated
and not under:
www.example.com/physics
So we now have conflicting goals:
The person following an old link goes to www.example.com/physics and gets the outdated content or some reasonable replacement for it.
Our menu tree shows the outdated page under www.example.com/physics/outdated, not under www.example.com/physics.
I do not know how to resolve these conflicting goals. Any suggestions?
Rahul
P.S. I used some zero-width joiners, i.e., numeric code #8220;, to prevent conversion of the URLs into links.
Hmm... looks like a challenging task. My first guess would be to write a plug-in that would run when a PageNotFound event happens. You could then check if it is located in the /outdated directory and use $modx->sendRedirect to show it.
Actually, this shouldn’t be so hard to do. You can just move the document to the outdated folder and create a weblink with the same alias to put in its original location which will automatically forward to the document in the new location. As for it not showing up in the menu, just uncheck the show in menu option on the weblink and menu snippets like Wayfinder will ignore it.
Hmm, you’re right. I didn’t read that part of his post carefully. In that case, you’re right that he can use a plugin that runs on the PageNotFound event. I think I would just check whether the parent folder is one that would contain documents that may have been moved and if so forward to the same URL with "outdated/" inserted into it. If that page is not found it will then be forwarded to the 404 page. Alternatively the plugin could check that the alias exists in the outdated folder and forward to it only then (one less forward when the alias doesn’t exist).
It seemds to me that to become a "heavy-duty" CMS, MODx should have some built-in provision for handling outdated pages gracefully.
Here, perhaps, is one solution the MODx implementors might consider.
- Permit slashes in aliases.
So now, suppose we have a page at:
http://www.example.com/physics/sun-rotates-around-earth
After Copernicus and Galeleo send complaining emails to us (just play along with me for a minute), we add a new page called:
http://www.example.com/physics/earth-rotates-around-sun
And we revise the sun-rotates-around-earth page to say that it contains outdated information, and check a "preserve URL" box, and we move this page into a new location on our manager’s LHS menu where it will be out of the way as we continue to update our web site. And MODx, when moving the page, preserves its old URL by changing the alias field to reflect the original FULL PATH of the web page, containing slashes. So now, the web page is in a new place on the manager menu, but its URL remains unchanged.
We could also manually adjust the alias for any page to any path, which could contain slashes. This will give us great flexiblity in deciding where the page is maintained versus where it occurs in the web site.
Since aliases are handled by a combination of PHP string transformations and databse lookups, the above should be feasible.
On an enterprise scale, something like this is pretty much essential for a CMS, I think.
Programs like Wayfinder would need to be able to recognize the location of pages by looking at their aliases. But this is all string manipulation.
Rahul
Something like that is probably doable, although if the only problem with the current system is clutter in the Manager there are probably other ways also.
For example, you could move the page and create a forwarding weblink in the old directory that doesn’t appear in menus (as described earlier). Then you could just add a back-end Manager switch to the document tree display to determine what’s shown and what’s hidden (something like the existing sort button). So you could hide all weblinks, or all documents that are not shown in menus, or you could categorize those forwarding pages and hide that category. This would get you the same results without muddying the folder/container structure, which may be a usability issue for other people.
As an aside, you can already do what you need to do now using .htaccess rewrites for the old pages. That’s what I do for legacy pages whose URLs need to keep working but which I don’t want to have to look at in the Manager. Another option that works is to create simple PHP forwarding pages with the aliases you want to forward and upload them to the server.
