Soma

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!

what is the inputfield selctable pages defined with? $field->attr("value", $field->getSelectablePages(new NullPage)); should work?

It what I wrote at first its an array not a single image so you need to get it with first(). Sorry am on mobile here. Maybe someone else care to explain.

Ah youre in module so no ouputformat so an file.field is always a wirearray. Hence the Pageimages error and not Pageimage.

"Pageimages::getThumb" PageImages is an array, but you need to get one image object $image->first()->getThumb() Or just change you image field to 1 max image ------ Also $this->pages->find("section_img!=''") maybe rather: $this->pages->find("section_img.count>0") since image field is an array, it's not a text

The place for that would be in the PaymentModule of your choice. https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentInvoice.module This is just a basic example module and you would add what you need after the order save, or just create your own invoice module. I'm not sure what you mean with in template level, but that makes the least sense to me.

if you have the intro-pages have a distinct template you could do something like if($page->parent->is("template=intro-page")){ // or $page->parent->is("intro-page") $children = $page->siblings->prepend($page->parent); } else { $children = $page->children->prepend($page); } Or if you know the level you could do for example: switch($page->parents->count){ case 1: $children = $page->children->prepend($page); break; case 2: $children = $page->siblings->prepend($page->parent); break; }

Just remove the "advimage" from the plugins... and remove the height and width attribute from img in the "valid_elements" in the TinyMCE advanced config, and be happy

They're needed for the.image resize to be working with scaling it in editor. If image has no with or height it won't work.