In theory …
Looking at just page links and subverting the posts side of WP to a “site section” as the blog, but using WP pages as a CMS, I’m seeing odd behaviour.
Whilst I have my permalinks set as domain/year/month/page_name and haven’t yet got around to working on that side of this particular site yet, the pages operate differently.
By default, WP sets the pages to work in a single language site like this –
domain/page_name
domain/parent_page_name/child_page_name
and so on.
This is for the URL and the page slug shown during the creation/editing in the admin editor.
In the data base it saves with two fields per post row – a parent post ID field and a page_name field. It also includes another field in the format domain/index.php?p=xyz where xyz in the numeric page_ID.
In WPML, for pages, the URL is extended to become –
domain/XX/page_name
domain/XX/parent_page_name/child_page_name
and so on, where XX is the two letter code for the language.
In the database, the parentpage ID is still numeric as is the index.php?p=xyz, but the page_name is recorded in the XX language, and on the editor page the page slug is taken from the additional language title to create that page_name slug in the XX language.
All that is how it should (and nominally does) work, but I’m having a problem with language encoding “stickiness”.
If I create a bunch of top level (parent level) pages in the XX secondary language, it all works fine.
If I then create child pages – after the first save of any one child page (manual or auto save), ALL the parent page and child page page_name fields in the secondary language in the database, switch to unicode (with something like %E2%b7 for each character in the page_name) and the slug in the editor updates to show the parent page part of the path as that unicode string, but with the current page part of the slug still in the secondary language.
When the page is published, the page_name database field then stays in unicode, and subsequent editing of that page flips both the parent and child page part of the permalink into unicode.
In the browser, it shows as the secondary language correctly in the address bar, but copying the URL from there to another program, causes it to paste as unicode (making it impossible to copy and paste urls when creating additional pages and posts).
If I go into the database and manually update each page_name field back to the correct language and characters, then save, that’s what shows in the editor page permalink, but I then get 404’s on the actual site.
What I think is happening here, is that –
With Sticky Links OFF, the page rewrite rules are working correctly and recording the page_name edits directly done within the database (dunno how, but they seem to) and doing so with Sticky Links off does not cause 404s. When the edits are complete, Sticky links can then be turned back on to “lock” them as long as those pages are never edited again.
With Sticky Links ON, editing the page_names directly in the database causes a loss of relationship between the associated pages in the two or more languages. This forces a need to re-edit or re-save from the editor page, for each published or draft page, which in turn then undoes all the corrective editing done directly in the database.
I’ve lost weeks over this and cannot figure out why or where this is happening – I’m not sure if it’s a character repertoire encoding issue between WordPress, the database, and the browser, or whether WPML is simply broken at some point when handling permalinks, slugs, and page saves/publishing.
Any clues or advice would be gratefully received at this stage, because I’m on the point of refunding the client, deleting his site, and abandoning any hope of building multi-lingual sites in WordPress.
My wife is ready to order a straightjacket for me – it’s driving me nuts and the WPML team have closed my support thread on it with a simple “wont fix”.
