A solution for the Autonav "Home" menu problem.

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.
$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
<li><a href="<?php echo $home ?>"> <?php echo $homeName  ?></a> </li>

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.

View Replies:
goodnightfirefly replied on at Permalink Reply 1 Attachment
Take a look at JordanLev's recent article promoting GlobalAreas over hardcoded blocks [http://concrete5tricks.com/blog/dont-hardcode-blocks-use-a-global-a... ].

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.
NickKN replied on at Permalink Reply
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.
NickKN replied on at Permalink Reply
After research, I have cleaned up the code.
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.
TheRealSean replied on at Permalink Reply
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.

//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.
            $cLocalParentID = $ms->getCollectionID();
NickKN replied on at Permalink Reply
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.