@Sottwell:
I have modified my development version to set the style sheet path dynamically. The fix will appear in the next update (1.0.2).
@MadeMyDay:
Thanks for the valuable documentation feedback. I rushed it a bit, so there’s bound to be lots of room for improvement. That said, I didn’t agree with either of your comments - but that’s almost certainly evidence that the documentation does need improving (or of some error).
With regards to point 1about which Wayfinder templates to use: If you use the server name method, then you need to make sure that the templates include the full URLs to your documents (including the server name). Therefore you need to use the templates in the "full" folder. If, on the other hand, you are not using the server name method, then you can get away with just using the templates in the "std" folder. These just output relative URLs from the site root, like Wayfinder does by default.
With regards to point 2 about Wayfinder needing to be run uncached: I’m not sure about that. I have it running with Wayfinder cached and my pages cacheable. I get the correct language content in all cases. Why do you think that Wayfinder needs to be run uncached?
With regards to the standard document pagetitle field on multilingual documents: For multilingual documents the standard document title becomes a text identifier for the document and all its language variants within the MODx backend. This identifier is visible in the MODx document tree. It needn’t be the same as the default language page title and some people might even prefer it to be a free text field rather than linked to the page title that appears on the front-end document output. I think the following is needed:
- The YAMS ManagerManager script should be updated to rename the default document pagetitle field to something like "Internal document name".
- The YAMS "Other Params" tab should be updated to include an option to synchronise the document title to be the same as the default language page title when the document is saved. I don’t think the ManagerManager mm_synch_fields function works with template variables, so I’ll do this with a plugin that works on the OnDocFormSave event like you suggested. I’ll just tweak an existing plugin I have that updates the alias when the document is saved.
I’ll stick this on my To Do list.
With regards to language dependent aliases: I have considered this but not in great depth until now. It was clearly not going to be as simple as the other multilingual document fields and I wasn’t even sure if I would be able to get those working at the time. I do understand the benefit of language dependent aliases from a SEO point of view.
Here is my analysis of how this all works based on experience and a quick browse of the source code: An HTTP Request for a page is made. This is handled by the server, which converts this into a request for the MODx index.php page with the file path and file name sent as the "q" query parameter. MODx parses the request (executeParser function in the document.parser.class.inc.php function) and looks up the document identifier of the document associated with that path and name dependent on the FURL settings. (It seems to use a lookup-table called documentListing, which maps to ids, but I looked in the document.parser.class.inc.php file and couldn’t find where it is initialised.) If the document identifier for the given path was not found, then the OnPageNotFound event is invoked and once that has completed the user is redirected to the error page specified in the MODx config, or the site start if it is not set.
So, if a user tries to access a page via an URL that contains a language dependent alias then for anything but the default langauge, the OnPageNotFound event would be called and the error/start page redirection would occur, since MODx doesn’t know to look in template variables. The obvious place for YAMS to plugin and change MODx behaviour is the OnPageNotFound event. YAMS could analyse the q query parameter by looking at template variable content tables in the database to figure out the id of the correct page. It would also have to ensure that the query param is consistent with FURL requirements (alias and path etc.), YAMS server name and root name modes and that the document identifier is for a multilingual document. If all that is achieved then it would have to call the sendForward function, supplying the correct document id and exit to continue parsing of the correct page.
So, I think it could work in principle... but it would need quite a bit of work and testing. I’d be glad to hear from anyone that thinks it isn’t possible, since that would save me time should I decide to go ahead and try to implement it.
☆ A M B ☆
