Facility to automatically determine alternative location from source filename.


There exists legacy sites that have been deployed for a while before being migrated to Guise Mummy. They may have many files in the format foobar.xhtml or foobar.html. With Guise Mummy these files may be deployed as foobar.html or even as foobar if clean URLs ("bare names") are configured from GUISE-52.

It is desirable that the new site deployed from Guise Mummy would have redirects to the old page names, as allows in GUISE-88. However it would be difficult to go through the entire site and add an mummy:altLocation property manually for each page.

Add a facility (perhaps using a mummy.autoAltLocation flag) to automatically add a mummy:altLocation to pages if their names change during mummification. This should be simple to implement (at least for files) after GUISE-125, as AbstractFileMummifier.loadDescription() now passes both the source and target files; the method can simply detect if the name changes and add a mummy:altLocation property if needed. Any existing mummy:altLocation property would be left as-is, allowing redirects to be overridden on a per-page basis.




Garret Wilson
March 31, 2020, 4:07 PM

This idea has come up several times, and on the face of it, it sounds like a great idea. There are a couple of problems, though. First is that many source files may actually have been moved to another directory during migration to Guise Mummy, and there is no way to know this; these files would need mummy:altLocation property overrides added manually. This is certainly possible but if a large portion of the site has been moved, then it somewhat defeats the purpose of the automatic facility.

The bigger problem is what to do going forward. This feature is mostly to migrate old pages from a legacy site; these pages have already been published, so they need redirects to their new locations. But new content will not have been published under other filenames, and therefore do not need redirects. Perhaps the argument could be made that it would still be useful to have redirects for these files, in case someone typed in foobar.html instead of simply foobar (with bare names); in this case it would be useful to redirect to the foobar version, even if the foobar.html version had never been published. Still, that's a lot of redirect rules to be published (for an AWS S3 website, for example), and if the source files are foobar.xhtml or foobar.md then that still wouldn't cover the case of redirecting from foobar.html, so the utility of this feature for new content is less obvious. (A facility that redirects from foobar.html, independent of the source filename, might be an interesting but separate feature.)

Thus the usefulness of this feature isn't as clear as it might seem at first.


Garret Wilson


Garret Wilson