Soma

I already know the problem/answer just by reading post titles like this one in this forum. This problem has come up and answered 1001 times at least. I even got in a heated discussion with a co-worker about this, where he just don't get outputformatting, even after explaining him multiple times again and again. He even insisted on that in his particular case it doesn't work even though it should have...

Ok, no need to use SQL here. Also not sure why you're foreach($languages as $language)? You can uncache the user and load it again via API, so it will load it fresh with language stored on user page. try{ $u = $session->login($username, $pass); if($u && $u->id){ $pages->uncache($user); // make sure it doesn't get user from cache $langID = $users->get($u->id)->language->id; // now load the user page $profileUrl = $pages->get(1003)->localUrl($langID); $session->redirect($profileUrl); } else { $loginError = "Login failed"; } } catch(Exception $e){ $loginError = $e->getMessage(); } I posted it in various login threads already, because all example login code posted in the forums has some flaws in that it doesn't catch errors when login failed multiple times (login throttle). To catch that you need to use a try catch method like in my example.

The language is set by what url you view a page.

But PLZ don't post that code in here inline, it's crazy

What about the two times in your code where you do $u->save(), doesn't that save something in DB? Don't think you'll find the issue (apart from that it's something already fixed), as it's quite a complex issue. But if you read the bug report you'll maybe understand, that saving the user will set the language to default for various reasons how the system is built. Maybe you're able to just use the pre 2.5 dev (very stable), or try work around it by setting the user language before saving, but doubt it will work as the issue is on saving a page (users are pages) on front-end using multilanguage.

Just to clarify, PW doesn't save something on it's own unless you do. And it has nothing to do with Twitter Bootstrap of course... So as we see it's in your code that does save the user. Unfortunately PW2.4 there was a bug (linked above) that seems to be the issue here.

I once drove on my bicycle down a road while having a bag hanging on the front handle bar. The bag got into the front wheel and in the split of a second, me and my bicycle made a complete 360 turn and landed right on the wheels again continue driving! I had a shock and couldn't believe what just happened.

And why do you use a bootstrap to login? In a bootstrap there's no language/page context.

There's no reference, it's a normal page. The only reference is the pagetable field itself. Ring a bell? $thepage = $pages->get("template=basic-page, mypagetable=$page");

Maybe define it on the init and not ready. Bootstrap doesn't trigger ready as its not web context.

Not sure where this should be addressed, but Spex uses the $config->styles $config->scripts to collect those assets. But to work with AIOM it needs to be relative to /templates/ folder . But if I want custom modules that for examples adds it's own css to the $config->styles->add() and the path to that will be in the module folder /site/modules/MyModule/MyModule.css it doesn't work. Also from time to time third party modules don't happend to have a check if on backend or frontend, and the populate the $config->scripts even on front-end, which results in an error in AIOM. Wouldn't it be better to have a custom $config->siteScripts $config->siteStyles filearray (same as PW backend) to populate assets? This would be to avoid conflicts.

Cool when you Put that sitep live, I'll fill up your site with millions of pages.

I'm confused as to why you need *= . This should just work fine $pages->get("/places")->children("tags=foodID, tags!=accomodationID")

This negative selector is for textfields. Also *= is for textfields. Maybe you are lucky and "!tags.title*=accomodation" works. Page fields work with ID's "tags=1233|1232" To search for a title within the selected pages you'd use a subfield selector "tags.title=abc"

No, "current" class on lists works as usual. For one page websites, this of course doesn't work, cause you're not on a page it could make "current".

There's no real support for placeholder parsing in the list_tpl, only on the item_tpl. The list_tpl has the %s that will get replaced with a class="..." string. There's a hookable method that is only for the css class string to hook into and add custom classes. So it's practically possible to use that with a little trick to add a string and would look like this: $menu = $modules->MarkupSimpleNavigation; $menu->addHookAfter("getListClass", null, function($event){ $class = $event->arguments("class"); $child = $event->arguments("page"); $event->return = $class . '" data-attr="' . $child->title; // closing " will get added later }); echo $menu->render($options);

Committed an little update and upped version to 1.3.3. - added support for PageArray as the third argument. So instead of the root page you give it an PageArray. https://github.com/somatonic/MarkupSimpleNavigation/blob/master/README.md#build-a-menu-using-a-pagearray-instead-of-a-single-root-page So you can do now something like this to build the top level menu entries, where "navigation_entries" would be a page field for selecting pages. $entries = $pages->get("/")->navigation_entries; echo $treeMenu->render(null, null, $entries); Or this would also be possible $menu = $modules->MarkupSimpleNavigation; // get a PageArray from a simple search $entries = $pages->find("template=basic-page"); $options = array("max_levels" => 1); echo $menu->render($options, null, $entries); @sparrow In your case you could now simply do use your "Top_Navigation" as the third argument. $menu = $modules->MarkupSimpleNavigation; $options = array("max_levels" => 1); echo $menu->render($options, null, $pages->get(1)->Top_Navigation);

There's no real support for this currently. But you could with a little trick, and use each selected page as root, and set some options to not have an outer template wrapper. Also a selector to not render children of 1th level for each root. $menu = $modules->MarkupSimpleNavigation; $output = ''; foreach($pages->get("/")->select_pages as $root) { $output .= $menu->render(array( "outer_tpl" => "||", "show_root" => true, "selector" => "template=basic-page, parent!=$root" ), null, $root); } echo "<ul>$output</ul>";

If it only is a single image field there's no need for foreach, no?

With that method you posted, and the first argument is the product page. echo $modules->get("ShoppingCart")->renderAddToCart($product);

Look at the module and the method https://github.com/apeisa/Shop-for-ProcessWire/blob/master/ShoppingCart.module#L78 See? There's options to set the "page" as the first argument.

I reuse fields as much as possible and try to avoid having too many fields. I have a "firstname" field that could be used on different templates. I don't prefix fields. PW is designed to reuse fields. I wonder how many fields you have and why you need to prefix them. I think people tend to create new fields for every template and context, which could lead to 100s of fields. Remember there's template context for fields in PW, you can customize labels and some setting from within the template if you click on a field name.

You could take a textarea field, and take that to enter option one per line and use that to populate the select.