Maybe it's my ignorance or is there really something wrong with bootstrap3 theme (menu build function) or latest GS updates? After changing page slug (I've tried it several times) a 404 is to be the result! Yes, I cleared history etc!
I simply changed /test/subtest into /test/subtest1 and page name from 'subtest' into 'Subtest1'.
** EDIT **
Have changed menu to get_i18n_navigation(get_page_slug(FALSE),0,1,I18N_SHOW_MENU,'nav');
Not picking up the page name changes is due bad menu build function of theme bootstrap3, but slug subtest1 is still not found? To be continued.
2014-02-13, 00:42:25 (This post was last modified: 2014-02-13, 01:27:30 by Rene.)
I've tried it several times but renaming a page slug results in Page Not Found!
Example:
- Create new page 'Feedback' & save page ( slug = feedback )
- Calling page (click menu item) is working ok (tested)
- Edit Page and rename slug to 'beoordeling' & save page
- Calling page (click menu item) results in 404 ( see http://test.dare-is.nl/beoordeling/ )
File: beoordeling.xml
Code:
<?xml version="1.0" encoding="UTF-8"?>
<item><pubDate>Wed, 12 Feb 2014 15:41:08 +0100</pubDate><title><![CDATA[Feedback]]></title><url><![CDATA[beoordeling]]></url><meta><![CDATA[]]></meta><metad><![CDATA[]]></metad><menu><![CDATA[Feedback]]></menu><menuStatus><![CDATA[Y]]></menuStatus><template><![CDATA[template.php]]></template><parent><![CDATA[]]></parent><content><![CDATA[<p>This is feedback</p>
]]></content><private><![CDATA[]]></private><author><![CDATA[admin]]></author><menuOrder><![CDATA[3]]></menuOrder></item>
I've changed in template theme Bootstrap3 function ...
- get_navigation_bootstrap(return_page_slug());
.. to ...
- get_i18n_navigation(get_page_slug(FALSE),0,1,I18N_SHOW_MENU,'nav');
But on first time when creating page everything is ok. After adjusting slug a 404 occurs.
(2014-02-13, 01:43:56)shawn_a Wrote: Yeah seems like changedata is not updating pagecache properly somehow, or a later commit broke it cause i know it was tested and working.
I feel an update coming
It can not be said often enough, you guys do a good job with this CMS
2014-02-13, 01:58:51 (This post was last modified: 2014-02-13, 02:04:19 by Rene.)
Uhh, I did not read your answer properly. No update needed
I've just tested it on a other domain (not on my server) and changing slug works. Thanks for figuring out my problem.
** EDIT **
But is on GS 3.2.3, so I do update to 3.3.1 and try it again
ok i18n base breaks the changedata-aftersave hook and prevents any code after it runs from executing because it does its own redirects on changedata-save.
This is probably part of its kludgy pages.php override, we need to provide proper avenues, to fix that, either with backend page override hooks, or a simple redirect hook. mvlcek suggestions welcome here.
You can patch this by adding this to i18n_base.php line 149 | 150
I suppose you could also just change the changedata-save to changedata-aftersave also.
This hook has been available since 3.1 i am surprised noone else had this issue, i guess no one is using it.
i18n_base can be updated to use new sitemap filters and probably remove all of this sitemap replacement hackery all togather.
2014-02-13, 18:20:53 (This post was last modified: 2014-02-13, 18:22:01 by Rene.)
I made the following change, works like a charm. Thx Shawn.
Had the impression that I first had to 'touch' (save again) the page (which gaves 404) first, but that could be me.
PHP Code:
function i18n_base_patch_page_save() { require_once(GSPLUGINPATH.'i18n_base/sitemap.class.php'); //I18nSitemap::executeOtherFunctions('changedata-save', 'i18n_base_patch_page_save'); I18nSitemap::executeOtherFunctions('changedata-aftersave', 'i18n_base_patch_page_save'); I18nSitemap::patchSaveFile(); }
Have an other issue about default language but I'll start a new thread for that.
(2014-02-13, 18:20:53)Rene Wrote: I made the following change, works like a charm. Thx Shawn.
Had the impression that I first had to 'touch' (save again) the page (which gaves 404) first, but that could be me.
PHP Code:
function i18n_base_patch_page_save() { require_once(GSPLUGINPATH.'i18n_base/sitemap.class.php'); //I18nSitemap::executeOtherFunctions('changedata-save', 'i18n_base_patch_page_save'); I18nSitemap::executeOtherFunctions('changedata-aftersave', 'i18n_base_patch_page_save'); I18nSitemap::patchSaveFile(); }
Have an other issue about default language but I'll start a new thread for that.
I had noticed this behaviour too. This patch fixes it indeed. Instead of replacing 'changedata-save' to 'changedata=aftersave' as you did I added Shawn's patch to the existing code as he initially suggested. Didn't need to first save the page again in any case.
2014-03-03, 04:09:28 (This post was last modified: 2014-03-03, 04:19:22 by mvlcek.)
Thanks for the bug report. It should always have been changedata-aftersave (but it seems nobody else used this trigger).
It is solved in I18N 3.2.6.
I decided to leave the patches in instead of using hook sitemap-aftersave, as doing so would have resulted in an additional reading of all page files to create the sitemap first and then recreate it with correct URLs.
Although the current hooks are much better then in old versions, I'm not quite happy yet.
(2014-03-03, 04:09:28)mvlcek Wrote: I decided to leave the patches in instead of using hook sitemap-aftersave, as doing so would have resulted in an additional reading of all page files to create the sitemap first and then recreate it with correct URLs.
Although the current hooks are much better then in old versions, I'm not quite happy yet.
(2014-03-03, 06:22:56)shawn_a Wrote: Yeah I don't understand that. What info is not in page cache or the XML object that you need to reload page files?
For the %parents% placeholder I need all parents. The other information (language) can be taken from the URL.
But for the filter to be useful for anything else, I suppose this information would need to come from the page files.
Still don't get it. to modify the site map you just need to modify the urls and add new entries for languages.
What else does a plugin need to do to sitemap? Just making sure I understand.
(2014-03-03, 07:09:26)shawn_a Wrote: Still don't get it. to modify the site map you just need to modify the urls and add new entries for languages.
What else does a plugin need to do to sitemap? Just making sure I understand.
Just some ideas:
e.g. other more detailed priority, other change frequency, additional URLs from custom fields or links in the content - I suppose search engines will scan links to PDF and probably other office documents, but you might add a special URL with e.g. an indexable PDF-version of a CAD file?
The I18N plugin uses multiple files and encodes the language in the URL. You could also add additional title and content fields in the page XML (e.g. <content lang="de">) and then would need to read the page file to know that this page file is in reality two language pages.
If you have a frontend user type plugin, you might have a field access=public/base member/gold member and want to include only the public pages in the site map.
Or you could include the base member pages in the sitemap and serve them (or a garbled version e.g. all sentences in random order) to specific search engines (so it is indexed) and then display a "Please become a member" page to visitors.