A solution for the Autonav "Home" menu problem.
Permalink
The forum abounds with questions on the subject of how to get a classic Home / About/ Gizmos menu. If you try to go with selecting just the language tree, you can't get "Home" of the language to line up with the 1st child level as with a monolingual site. There is quite a substantial script in the wild, I tried it and it had the bizarre effect that if one clicks on the Site Title it goes to the site Root home page... (ie mysite/index.php, rather than ../index/en)
My next solution was to go with aliases for home pages on the same level as the other 1st child pages. This has the unwanted effect that, if you click on the site title link you get 404... it wants to go to Mysite/en but, I suppose, because the address of the alias' address is Mysite/en/home there is a conflict... This I gave up because it completely broke the language switcher.
Finally I found this post :http://www.concrete5.org/marketplace/addons/internationalization/su... - a hack which I applied in my header - but which still didn't have any effect on the autonav block.
So basically I created a custom autonav view and applied the same hack to it.
It ain't pretty - I tried constructing a query to the database, but SQL is not one of my limited skills, particularly going through the AODB layer that C uses - but it allows you to put this
under the opening <ul> of your menu.
And it has the virtue of working!
Any improvements, simplifications welcome...
Is it the case that you have to communicate the language context to all the blocks you use? While I was fooling around I put "echo $locale" in the autonav view - and it printed en_US... hence the hack.
My next solution was to go with aliases for home pages on the same level as the other 1st child pages. This has the unwanted effect that, if you click on the site title link you get 404... it wants to go to Mysite/en but, I suppose, because the address of the alias' address is Mysite/en/home there is a conflict... This I gave up because it completely broke the language switcher.
Finally I found this post :http://www.concrete5.org/marketplace/addons/internationalization/su... - a hack which I applied in my header - but which still didn't have any effect on the autonav block.
So basically I created a custom autonav view and applied the same hack to it.
$c = Page::getCurrentPage(); if( Package::getByHandle('multilingual') ) { $ms = MultilingualSection::getCurrentSection(); if (is_object($ms)) { $home = Loader::helper('navigation')->getLinkToCollection($ms, true); $lang = $ms->getLanguage(); $locale = $lang . "_" . $ms->getIcon(); $homeId = Page::getByPath('/'.$lang); //only works if you're using the 2 letter language code as handle for your section home page $homeName = $homeId->getCollectionName(); } }
It ain't pretty - I tried constructing a query to the database, but SQL is not one of my limited skills, particularly going through the AODB layer that C uses - but it allows you to put this
under the opening <ul> of your menu.
And it has the virtue of working!
Any improvements, simplifications welcome...
Is it the case that you have to communicate the language context to all the blocks you use? While I was fooling around I put "echo $locale" in the autonav view - and it printed en_US... hence the hack.
This is a shim for a view in a global area...
I lack the skill to internationalise the autonav controller, so this is a working compromise.
I will look at the external link solution.
I lack the skill to internationalise the autonav controller, so this is a working compromise.
I will look at the external link solution.
After research, I have cleaned up the code.
It reads like this :
It took me a while - a newbie fumbling around...
The locale and language are included in the code, but not used in this instance - it is there for interest and to show that it could be a "shim" for internationalising views fo various blocks.
It reads like this :
$c = Page::getCurrentPage(); $ms = MultilingualSection::getCurrentSection(); if (is_object($ms)) { //$lang = $ms->getLanguage(); //not useful here, but could be useful for multilingual views of file attributes //$locale = $ms->getLocale() ; //as above $homeID = $ms->getCollectionID() ; $homePage = Page::getByID($homeID) ; $homeName = $homePage->getCollectionName(); $nav = Loader::helper('navigation') ; $home = $nav->getLinkToCollection($homePage); }
It took me a while - a newbie fumbling around...
The locale and language are included in the code, but not used in this instance - it is there for interest and to show that it could be a "shim" for internationalising views fo various blocks.
note:// concrete5 version 5.7.3+
Thanks for the pointers I've taken what you have done and applied it to the page list block to filter pages by the locale.
For us this was posing a problem when we wanted to show related blocks based on topics, but don't want to see the foreign language versions.
Thanks for the pointers I've taken what you have done and applied it to the page list block to filter pages by the locale.
For us this was posing a problem when we wanted to show related blocks based on topics, but don't want to see the foreign language versions.
//I added the use case to get access to the MultilingualSection use Concrete\Core\Multilingual\Page\Section\Section as MultilingualSection; //then within the on_start function $ms = MultilingualSection::getCurrentSection(); //Get the current location and filter our page list by the locale. if(is_object($ms)){ $cLocalParentID = $ms->getCollectionID(); $this->list->filterByPath(Page::getByID($cLocalParentID)->getCollectionPath()); }
I've just seen this!
You've returned the complement - I'm trying to fumble my way to get up to speed with 5.7, so this helps to "translate" my code from 5.6.
You've returned the complement - I'm trying to fumble my way to get up to speed with 5.7, so this helps to "translate" my code from 5.6.
You can see in the comments a solution for this scenario (if I understand your situation correctly, its the same as mine).
Try an External Link instead of an alias, the picture attached shows the sitemap layout and configuration a bit better than words can.