Soma

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.

Yeah for fields that are objects/arrays you need to turn off outputformatting. I don't really get/see why one would want or have to do this... and wonder if I miss something. If you copy all those fields content to another page including its url at runtime, why not take the page as you have it already? The url can't be overwritten like this as it is a method and not a property. You would need to hook into Page::path to modify a pages url.

Just use a page field and create pages for the options. Those pages can be edited or added and then build the select. Simple and effective.

Looks like apeisa shop isn't multilanguage compatible. I have forked the module long time ago and added/fixed some multilanguage related stuff, I remember, just so it works for me and my project(s). But I'm not really supporting it, so you are on your own kinda. There's also a dev branch.

You didn't even scratch on the surface yet... It's possible, just if it makes sense or there's isn't any drawbacks is a different question. If you want you can overwrite and change almost everything. And if not, there's maybe just a hook needed to add to core. There's many different approaches as always in PW. Fo example you could set all templates to have "main" as alternative template foreach($this->templates as $tpl){ if($tpl->name != "admin") $tpl->altFilename = "main"; } Depends really where you put this code. Most sense would make inside a autoload module like the HelloWorld.module. But then you have ALL templates always use main.php. You can't change it unless you add more logic to this script. After all I've come away from the "delegate" approach I've posted here, and use the one Ryan proposed. Including the main.php at the end of a template file makes things easier when you want to add stuff per template. Some more flexibility after all.

I think it's because the non default languages aren't set active on the admin/shop/orders/ parent page.

To check if a user is logged in you check with if($user->isLoggedin()) ...

The root url $config->urls->root (including subfolders or if none it returns "/") So $session->redirect($config->urls->root . "profile/");

Therese already One I zhought by owzim?

Ah yes there's no support for subfields, only the page field will replaced with url. But you could custom replace a placeholder with a hook. For example name the placeholder something like "color" can be anything. Then add a hook like $nav = $modules->MarkupSimpleNavigation; $nav->addHookBefore("getItemString", null, function($event){ $tpl = $event->arguments("tpl"); $page = $event->arguments("page"); // maybe some condition do whatever you need if($page->catColor){ $tpl = str_replace('{mycolor}', $page->catColor->title, $tpl); // replace the placeholder $event->setArgument('tpl', $tpl); // send back the tpl argument } }); // then render as usual using the {mycolor} echo $nav->render(array( 'item_tpl' => '<a class="{mycolor}" href="{url}" title="Link to: {title}">{title}</a>', )); The method getItemString() is just the method that runs a parser to replace the placeholders with real values, so we hook into it before.

PHP also works in the browser.

What about catColor.title ?

It's ok, bu there's a official cheatsheet thread from back then https://processwire.com/talk/topic/681-processwire-cheatsheet/ I'm not sure why fieldgroups isn't in the docs. Ryan had some reasons I guess, I just converted his PW docs to a cheatsheet back then. fieldgroups are basicly templates and are hidden as it's only needed for more advanced development and don't play a big role on the "front-end" usage of the API. * The existance of Fieldgroups is hidden at the ProcessWire web admin level * as it appears that fields are attached directly to Templates. However, they * are separated in the API in case want want to have fieldgroups used by * multiple templates in the future (like ProcessWire 1.x). After all I'm not against adding it if Ryan thinks also it should be there. Thanks for bringing this up.

I tried with a cache field and I get an error: TemplateFile: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'pw.field_searchindex' doesn't exist<pre>#0 /Applications/MAMP/htdocs/pw.ch/wire/modules/Fieldtype/FieldtypeCache.module(108): PDOStatement->execute() #1 /Applications/MAMP/htdocs/pw.ch/wire/modules/Fieldtype/FieldtypeCache.module(168): FieldtypeCache->getNumPagesCached(Object(Field)) #2 [internal function]: FieldtypeCache->___getConfigInputfields(Object(Field)) #3 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(359): call_user_func_array(Array, Array) #4 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(317): Wire->runHooks('getConfigInputf...', Array) #5 /Applications/MAMP/htdocs/pw.ch/wire/core/Fieldtype.php(182): Wire->__call('getConfigInputf...', Array) #6 /Applications/MAMP/htdocs/pw.ch/wire/core/Fieldtype.php(182): FieldtypeCache->getConfigInputfields(Object(Field)) #7 [internal function]: Fieldtype->___exportConfigData(Object(Field), Array) #8 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(359): call_user_func_array(Array, Array) #9 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(317): Wire->runHooks('exportConfigDat...', Array) #10 /Applications/MAMP/htdocs/pw.ch/wire/core/Field.php(180): Wire->__call('exportConfigDat...', Array) #11 /Applications/MAMP/htdocs/pw.ch/wire/core/Field.php(180): FieldtypeCache->exportConfigData(Object(Field), Array) #12 /Applications/MAMP/htdocs/pw.ch/wire/core/Field.php(217): Field->getExportData() #13 /Applications/MAMP/htdocs/pw.ch/wire/modules/Process/ProcessField/ProcessFieldExportImport.php(188): Field->setImportData(Array) #14 [internal function]: ProcessFieldExportImport->___buildImport() #15 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(359): call_user_func_array(Array, Array) #16 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(317): Wire->runHooks('buildImport', Array) #17 /Applications/MAMP/htdocs/pw.ch/wire/modules/Process/ProcessField/ProcessField.module(1008): Wire->__call('buildImport', Array) #18 /Applications/MAMP/htdocs/pw.ch/wire/modules/Process/ProcessField/ProcessField.module(1008): ProcessFieldExportImport->buildImport() #19 [internal function]: ProcessField->___executeImport() #20 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(359): call_user_func_array(Array, Array) #21 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(317): Wire->runHooks('executeImport', Array) #22 /Applications/MAMP/htdocs/pw.ch/wire/core/ProcessController.php(201): Wire->__call('executeImport', Array) #23 /Applications/MAMP/htdocs/pw.ch/wire/core/ProcessController.php(201): ProcessField->executeImport() #24 [internal function]: ProcessController->___execute() #25 /Applications/MAMP/htdocs/pw.ch/wire/core/Wire.php(359): call_user_func_array(Array, Array) #26 ...

I was working on a new fieldtype the last couple days and seen the export method and was wondering "what the hell is that?" Looks awesome!