Macrura

maybe the selector engine is figuring it out based on whether it is an integer and then looking at the page name (if you are using page reference)

you'd need to first change the brand selector to band.name, so it would look like brand.name=adidas|nike i don't think the trailing pipe will affect anything, but you can remove it before you add the comma, using a rtrim. Alternately you can use the new selector array syntax; The skyscrapers profile is probably really old and doesn't represent the latest and greatest advances and breakthroughs that the api has to offer. I would recommend to study this blog post: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#building-a-selector-string-with-user-input-example

ok sure - i will try and make this short and as relevant to this topic as possible, but ultimately this does relate to the age old discussion of how to implement configurable pages that has many topics and long discussions on the forum, so this problem/solution is somewhat based on researching and trying every option and arriving at this as the currently best option for creating turnkey websites: The problem: You want to implement a user interface that allows site editors to create and update page sections; in some cases these page sections may be orderable and in other cases you might want to restrict the ability of the editors to change the order. You may also want the user to be able to change from one type of section to another similar type of section with ease and not having to have some complex instructions for how to do that. One example might be a callout - perhaps there are 3-4 different types of callouts, one is a full width, and another is a split box. Another option might be a hero section where options include static image, video, or slider. The user should be able to switch the type of section type without having to create a whole new section and copy their content and prefs to the new section. They should not be required to go to the settings tab and change the template and have to go through that process. Based on these requirements, any interface that asks the user to specify the section type (template) prior to adding the new section will not work - this means no repeaters, and no page tables that use multiple templates. The solution i use is to let users add a new section to the page table, and on the section template, they can select the type of section to use (a field). The 'section type' field is a page reference (single select), which pulls the options from a hidden branch of the page tree. The sections for any page are output by checking for the existence of a corresponding php file (where the selected option's page name corresponds to the file name of the php file) in a directory in the templates folder. Each section's php file renders the section, and is a completely self contained file that includes all of the necessary code to render the section. I use a theme engine that also allows any section to inject dependencies into the header or footer, and set/modify other theme options/variables. Based on your outlined fields, you have mostly common field requirements between your sections: Title [title] Subtitle [subtitle] Multiple background images [images] Links [links table or repeater] Title for area [title] Paragraph of text [body] Background image [images - use first one] Bullet points [body] Image [images - use first one] Links [links table or repeater] List of feature with a title/description for each [features repeater] Image [images - use first one] Text [body] Link [links table or repeater - use first one] News section title [title] Title [title] Description [body] Link/link text [links table or repeater - use first one] Description [body] List of images/links [possibly repeater, or images extra with url field?] The micro contexts system would simply allow you to change the field labels, descriptions, notes, order, visibility and required based on the page reference selection for the section type...

yes, thanks for the clarification - ultimately this module should be improved to allow for showing help topics on their own pages, and a better help overview page where the contents are all listed under categories... i probably can't work on that till July, but i do expect at some point to make this module better and as you say link to specific help topics.. for now though you can use the hash feature that was coded by @justb3a :

This code can be placed into any generic site utilities module and you can add the hook in the init(); you can for example take the hello world module and clone it, rename to SiteUtilities, and then you can throw all of your custom stuff in there, instead of doing independent modules for everything.. $this->pages->addHookBefore('save', $this, 'addImageDataAttributes'); public function addImageDataAttributes($event) { $page = $event->arguments[0]; $ta_field = 'body'; // change to your editor field that holds the images $img_field = 'images'; // change to the name of the images field if(!$page->$img_field || !$page->$ta_field) return; $html = $page->$ta_field; if (strpos($html,'<img') === false) return; //return early if no images are embedded in html $dom = new \DOMDocument(); $dom->loadHTML(mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8')); $images = $dom->getElementsByTagName('img'); if(!$images->length) return; // not needed? $imgCount = 0; foreach ($images as $image) { $img_url = $image->getAttribute('src'); $path_parts = pathinfo($img_url); $imgName = $path_parts['basename']; $sysImage = $page->$img_field->get("name={$imgName}"); $width = $sysImage->width; $height = $sysImage->height; $image->setAttribute('data-width', $width); $image->setAttribute('data-height', $height); $imgCount++; } if(!$imgCount) return; $page->of(false); $page->$ta_field = preg_replace('/^<!DOCTYPE.+?>/', '', str_replace( array('<html>', '</html>', '<body>', '</body>'), array('', '', '', ''), $dom->saveHTML())); $page->save($ta_field); $this->message("image links updated with data attributes."); } This has been tested and works, but it will only retain the data attributes if your CK editor settings allow it..

i like it a lot – i think anyone who has a firm grasp on this can really thrive in PW in so many ways...

ditto, i was basically implying that the code may be adjustable or tweakable within interceptor, to add your data attributes; the import external images shows how to grab any image tag using dom parser; i can take a look and see how hard it would be to add data attributes to the resultant image since the mod already switches out the href; come to think of it, most of the code for that came from Adrian's wordpress migrator, so there could be something in there also

I have used that technique (as described here: https://processwire-recipes.com/recipes/use-different-sets-of-template-files/ ) for developing a whole new frontend while the site was live and then replaced the whole templates directory when the new one was done...

@cjx2240 here's my 2cents: - for those configurable pages, i use a pagetable, in combination with the Micro Contexts module... this allows me to have 1 template for all of those items but to hide/show fields and change their order, descriptions, labels, notes and even conditional hide/show based on the 'type' of widget (e.g. section). this is working really well for me because on 'turn-key' site, you never know how many custom sections you will need to build, and it would be a drag to have to keep creating new templates; in this system you just need to add each section as an option (e.g. page reference for the section type) and then load the corresponding file using some code like this: if(count($page->sections_pt)) { $sections = ''; foreach($page->sections_pt as $section) { if(file_exists('./partials/sections/section-' . $section->widget_type->name . '.php')) { $viewBag['widget'] = $section; $sections .= "\n" . wireRenderFile('./partials/sections/section-' . $section->widget_type->name, $viewBag); } } $content = $sections; }

@bernhard - sure, let me know what context this applies to - for example if you are viewing the help tab, or help modal on the page editor, or showing the help topic in the process module? I haven't worked with panels yet, so if you have any further details on how and when that comes into play, let me know how to replicate the issue etc..

i keep everything for the front end in the templates folder, since a lot of modules and such use the templates directory as the assumed location of the fonts, js, css files... i tried a long time ago to keep some things outside of templates, but it didn't really help and was somewhat annoying to deal with... i can't see any reason why templates folder can't hold everything, plus then you can use alternate template folder setup for testing and development (like templates-dev)... and have a completely separate independent copy of all those things

I think if you make a textformatter is should not be that hard to grab the images and add your data attributes; maybe look at image interceptor and/or the external images modules, and see if you can get the tags by regex or using dom parser...

usually you just need save the new field first, then get the field and do the extra stuff to it, i think that's how i did a page select in the admin help module, IIRC

I have the same issue, if the image is too large, just forever spinner...

not really a solution, but i use the limit page table module to prevent users from trashing items in page tables, and use the extra actions (hide, unpub); so basically the users can't trash pagetable pages – if they don't want those pages anymore then they can unpub;

Since Polymer is a front end library, there is no restriction by ProcessWire in terms of how you build your front end, therefore if i'm not mistaken you can use it.

@fredmv i would recommend contacting Ryan again to request access to the ProCache forum. If you have your receipt email from the shop, you may be able to reply to that, in case the PM doesn't work. Note that Ryan is only typically addressing the pro module forums on Sundays.

Hi @zenboy - welcome to the forums! Since this post pertains to the Profields, you do need to post this issue under that board (Profields, Repeater Matrix).

The latest version of Admin Help module allows you to add a field to any help doc called help_header, which is then prepended to the edit form, for the template that this is enabled for. I use this for exactly the purpose you describe here, as well as putting a lot of instructions at the top of the page edit for certain template/page types; does help a lot and cuts down on support calls.. Alternately you can achieve this with a custom hook/function in your ready.php, for example hook into ProcessPageEdit::buildForm, and then prepend some markup depending if the conditions are met

i've been using the enhanced icon select in my selectize template and field tags module, which has served well for the past year; http://modules.processwire.com/modules/selectize-template-field-tags/ but your module looks like possible improvement..thanks!

have you tried setting the get var programmatically in the module (e.g. $input->get->id = $this->user->id)?

@MaryMatlow what version of PHP are you using? You do need to be on 5.4+

can you provide screenshots of your templates folder, and the screen showing where you entered the alternate template file name. other considerations, are you using delayed output, do you have _main.php... also pls. post the debug message, url etc..

We have 2 sites running no problem on BlueHost. Have you checked the permissions on the files?

Micro Contexts (aka field value contexts) Change any context-enabled setting in your page editor/template based on the value of a page reference field. Why use this? Say you have a template that is controlling some generic part of your website, like a section on the homepage, a widget, or an item in a media library. If you are using the various fields on this template in different ways depending on an option (page select) such as 'widget_type', 'media_type', etc, you can hot-switch the template context based on the field's value. Why not use template, like just change the template? Unfortunately, most of my clients would probably break down in tears if i tried to explain what a template is, or how to change it. This also allows you to have better more relevant labels, descriptions and notes based on any page ref field value on your template, as well as be able to show/hide fields based on that value, or even move fields around to make some more prominent or visible. How to use this 1.) Create a new template: 1a) Use the following name structure: mc-[field_name]-[field_value]-[any_memo_here] where [field_name] is the field that will control the micro context, and the [field_value] is the required value (page id) that the controller field must equal/have in order to trigger the virtual template context. The last part of the template name should be used for the page name, or some memo to make it easier to know from the templates list what field value will trigger the micro context, since the template name does require the ID value of the field, not the name. 1b) Make sure to specify the template you are contextualizing under "Duplicate fields used by another template" before clicking save! 1c) Edit your field settings for this template, for when your fieldname=value as specified in the template name (labels, descriptions, notes, visibility, field order etc.) 2.) Place this code in your ready.php file: wire()->addHookAfter('ProcessPageEdit::loadPage', null, function (HookEvent $e) { $page = $e->return; $mcPlates = $this->wire('templates')->find("name^=mc-"); if(!count($mcPlates)) return; foreach($mcPlates as $mcPlate) { $nameParts = explode('-', $mcPlate->name); // expected format: mc-[field_name]-[page-id]-[anything-you-want-here] $mc_field = $nameParts[1]; // the field controlling the micro context $mc_value = $nameParts[2]; // page id has to be the 3rd part of the template name $controllerField = $page->fields->get($mc_field); //if we find a matching controller field from the template name... if($controllerField) { $f_value = $page->get($controllerField->name); $proceed = false; if( ($f_value instanceof PageArray) || ($f_value instanceof Page) ) $proceed = true; // this only works with page reference fields. if(!$proceed) continue; // the page corresponding to the required value (page id) specified in the mc template name, to change micro context $mc_page = wire('pages')->get((int) $mc_value); // if the value specified in the mc template name matches the current value of the page reference field, change the // fieldgroup context $proceed = false; if( $f_value instanceof PageArray && $f_value->has($mc_page) ) $proceed = true; if( $f_value instanceof Page && $f_value == $mc_page ) $proceed = true; if($proceed) { $tName = $mcPlate->name; $mc_template = wire('templates')->find("name=$tName")->first(); if($mc_template) { $mc_fieldgroup = $mc_template->fieldgroup; $page->template->fieldgroup = $mc_fieldgroup; } } } } }); Caveats This probably needs more work to be fully usable, and may need more bullet proofing in terms of checking for valid template name, etc. You can only have this work with 1 page reference field per template. This has been tested and is being used on at least 2 live sites, but caution should be used, and the functionality should be tested before using on a live site. Screenshots: 1) a default widget with no field value context enabled fields 2.) A field value context enabled edit page for the 'Widget Type', the template controlling this is now 'mc-widget_type-1054-text', but the template of the page stays as 'widget'; only the fieldgroup context is changed when the page is loaded to get the contextual settings: 3.) the context for when the page reference field called 'widget_type' has the value of 1150, which is a video widget type (template name is 'mc-widget_type-1150-video'). Convenient Module edition coming soon!