Robin S

Here is a hook method for /site/ready.php that gets the pages that are selected in a given Page Reference field: /** * Get pages selected in a Page Reference field * Use optional argument $options for limiting 'template' and/or 'parent_id', and to 'include_unpublished'. * Usage: $selected_pages = $fields->my_page_field->getSelectedPages(['template' => 'basic_page']); * The number of times each page is selected is available in a custom "occurrunces" property on each selected page. */ $wire->addHookMethod('Field(type=FieldtypePage)::getSelectedPages', function(HookEvent $event) { /* @var Field $field */ $field = $event->object; $options = $event->arguments(0); $get_options = []; if(isset($options['template'])) $get_options['template'] = $this->wire('templates')->get($options['template']); if(isset($options['parent_id'])) $get_options['parent_id'] = (int) $options['parent_id']; $table = $field->getTable(); $query = $this->wire('database')->query("SELECT data FROM $table"); $ids = $query->fetchAll(\PDO::FETCH_COLUMN); $count_values = array_count_values($ids); $items = $this->wire('pages')->getById(array_keys($count_values), $get_options); foreach($items as $item) { if(empty($options['include_unpublished']) && $item->status > Page::statusUnpublished) { $items->remove($item); } else { $item->occurrences = $count_values[$item->id]; } } $event->return = $items; }); The following is an example of how you would get the category pages that are selected in your category field. The number of times each category is selected is available in the custom "occurrences" property if you need it. // Get the selected category pages $selected_categories = $fields->categories->getSelectedPages(); // Demo output foreach($selected_categories as $selected_category) { echo "<p>Category {$selected_category->title} is selected in {$selected_category->occurrences} page(s).</p>"; }

As per my previous reply and the module readme there are config options for dialog width and height. Or maybe I don't understand your question.

Sorry, I didn't understand the original issue properly before. You shouldn't have to activate the tooltip option for the append option to work for selects - I've fixed the logic in v0.1.2 so it should work as expected now.

Excellent tutorial, thanks! Just wondering: why do you write your own str_truncate and textToId functions instead of using core $sanitizer methods like truncate() and name()? (for the latter there are several different sanitizer methods that could be used to get an ID string)

I've added this to v0.1.1. There are data-info attributes on select options - maybe your browser dev tools don't display those attributes for some reason?

No, that isn't possible in this module - the dialog width and height in the module config applies globally to all Hanna tags.

I was going to write a tutorial but then I thought I might as well take the next step and turn it into a module: If @tpr wants to include the functionality in AOS and people would prefer that rather than a standalone module then I'm fine with that. ?

Thanks to @Macrura for the idea behind this module. Page Field Info Adds information about options in Page Reference fields. Supports InputfieldSelect and inputfields that extend InputfieldSelect: InputfieldSelect InputfieldRadios InputfieldSelectMultiple InputfieldCheckboxes InputfieldAsmSelect Requires ProcessWire >= 3.0.61 and AdminThemeUikit. Screenshots Field config Example of changes to inputfield Example of info field filled out in Page Edit Installation Install the Page Field Info module. Configuration In the Input tab of the settings for a Page Reference field... Tick the "Add info tooltips to options" checkbox to enable tooltips for the options in the field. Tooltips are not possible for Select or AsmSelect inputfield types so for those types you would want to tick the next option. Tick the "Append info about selected options" checkbox to append information about the selected options to the bottom of the inputfield. If the Page Reference field is a "multiple pages" field then the info for each selected option will be prefixed with the option label (so the user will know what option each line of info relates to). In the "Info field" dropdown select a text field that will contain information about the page, to be used in the tooltips and appended info. Of course this field should be in the template(s) of the selectable pages for the Page Reference field. Hook In most cases the "Info field" will supply the text for the tooltips and appended info, but for advanced usages you can hookPageFieldInfo::getPageInfo() to return the text. For example: $wire->addHookAfter('PageFieldInfo::getPageInfo', function(HookEvent $event) { $page = $event->arguments(0); // The page $inputfield = $event->arguments(1); // InputfieldPage $field = $event->arguments(2); // The Page Reference field $info = $event->return; // Text from the info field, if any // Set some custom text as the $event->return... }); https://github.com/Toutouwai/PageFieldInfo https://modules.processwire.com/modules/page-field-info/

A couple of things to check: That you are calling the endpoint URL with/without a trailing slash according to the template "Should page URLs end with a slash?" setting. If the site is multi-language that you are calling the endpoint URL with the language string in it, e.g. http://site/en/subscription-new/

It tells PW that there is more than one OR-group in the selector string. It's all about specifying what has to match in order for the whole selector string to match - remember that for every OR-group only one selector in the group has to match. So previously you were doing this... // Templates $selector = "(template=home|basic-page|product-category, status!=hidden), (template=news-item|product-page)"; // Fields $selector .= ", (title|headline|lead|body%=$q), (content_matrix.columns.body%=$q, content_matrix.columns.count>0)"; ...which we can represent as this... // Templates $selector = "(template selector 1), (template selector 2)"; // Fields $selector .= ", (field selector 1), (field selector 2)"; ...and it is the same thing as... // Templates $selector = "foo=(template selector 1), foo=(template selector 2)"; // Fields $selector .= ", foo=(field selector 1), foo=(field selector 2)"; ...which is saying "find any pages that match template selector 1 OR template selector 2 OR field selector 1 OR field selector 2". So this will match a lot of pages that you don't actually want to match. Whereas this... // Templates $selector = "foo=(template selector 1), foo=(template selector 2)"; // Fields $selector .= ", bar=(field selector 1), bar=(field selector 2)"; ...is saying "find any pages that match (template selector 1 OR template selector 2) AND (field selector 1 OR field selector 2)".

Hi @Rhen GWL and welcome to the PW forums. By any chance do you have the template setting "Should page URLs end with a slash?" set to "No"? There seems to be an issue with the default action of the comments form that will submit the form to the parent page if the current page has no trailing slash. I opened a GitHub issue here, and in the meantime until Ryan responds you can override the default form action in the $options array for renderForm(): echo $page->comments->renderForm(array('attrs' => array('action' => $page->url)));

There are predefined system permissions for this - you just have to install them: https://processwire.com/docs/user-access/permissions/#page-edit-created https://processwire.com/docs/user-access/permissions/#page-edit-trash-created

There are multiple pages existing in the example above, so yes it does work. I saw your post in the other thread - the problem is that you are using a single unnamed OR-group for all your selectors. Only one parenthesised selector in the OR-group has to match. So when you do... $selector = "(template=home|basic-page|product-category, status!=hidden), (template=news-item|product-page)"; ...this means that any unhidden page with the home, basic-page or product-category template and any page with the news-item or product-page template will match regardless of any other selectors you later add to the same OR-group. Have another look at the documentation for OR-groups and try giving names to the different OR-groups for template and field values.

@MilenKo, it's not possible to have a required field in the dialog because the dialog form is not submitted anywhere for ProcessWire validation - the field values are just captured via Javascript when the dialog is closed. You should check for empty field values in the code for your Hanna tag. Incidentally, this is true for any "required" field anywhere in PW because nothing is ever really required - the user can simply abandon the edit process if they want and leave unfilled required fields, so you always need to check that fields are actually populated before doing anything with their value.

Maybe you made a typo somewhere in your selector - the OR-group syntax is working for me:

Getting Page Reference field values in a Pages::added() hook is working here. The hook: $pages->addHookAfter('added', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'colour') { bd($page->countries->explode('title'), $page->title); } }); Page add code and dump result:

It's working here in Laragon, Windows. But won't this have the effect that if a visitor saves the image from their browser they will be saving a WEBP image with a JPG (PNG, GIF, etc) file extension? Might cause some confusion.

It's not quite that simple for a few reasons. Repeater pages are not directly accessible for non-superusers meaning that selector won't work for guests. So you'd need to specify "include=all", but then you'd also need to exclude any unpublished or "ready" repeater pages with "status!=unpublished". Also, the selector would match all repeater items from that field from all pages, when probably what is wanted is only items from one page. So then you'd need to match repeater pages under only one parent, maybe by building the name of the parent from "for-page-" plus the ID of the page you want the repeater items from. But the simplest way and only marginally less efficient is to match by the IDs of the repeater pages in the field value: $results = $pages->find("id=$page->feedback_repeat, include=all, limit=10");

A drawback to that approach is that users will not necessarily only add the field to templates that don't yet have any pages - they could add the field to templates that have many existing pages and then confusion results when they see that their pages don't have the checkbox checked by default. Ryan discussed this here: And a module can't get around this problem by itself because of what I mentioned in the readme: So some separate API script needs to be run as needed to populate the checked state on pages immediately after the field is added to a template. But certainly you could create a module around this approach and perhaps include an example script that users could refer to as a starting point if they feel confident using the API.

Sorry, there was a silly error in the code. I've updated it so please try again.

@Mikie, I updated the CSS fix for the Lister button. After looking more closely I see that it only seems that the button is moving to the right. What actually happens is that initially you see the button that appears below the lister results, but this is near the top of the page because the results are empty at first. Via JS the button is cloned to the top right and the lister results are loaded, moving the original button lower down the page. So a better fix is to hide the bottom button when the lister results div is empty. /* Hide Lister button links at bottom when results are empty */ #ProcessListerResults:empty + .InputfieldButtonLink { display:none; }

@Mikie, you will probably need to open separate issues for each concern in the Issues or Request repos in order for Ryan to notice - he doesn't tend to participate much in the general forums these days. In terms of which repo, I'd say that it belongs in the Issues repo if something is broken or not working as expected, and in the Request repo if it's about adding a new feature or improving something that already works. In each issue please describe exactly what the problem is and what a solution would look like. And if you are able to contribute code for a suggested fix that's great (but not essential). I have some possible fixes for some of the things you mentioned that you'd be welcome to include in any issue report if you want... The footer sits under whatever content makes up the page, so if new content is loaded into the page by AJAX or page elements change in height then it's expected that the footer will move. Are you suggesting that the footer should be sticky to the bottom of the viewport when the height of the page content is less than the viewport height? Personally I would prefer that, but it's perhaps a matter of opinion. Here is some CSS that could be used for a sticky footer: /* Sticky footer */ html { height:100%; } body:not(.modal) { display:flex; flex-direction:column; height:100%; } body:not(.modal) #main { flex:1 0 auto; width:100%; box-sizing:border-box; } body:not(.modal) footer { flex-shrink:0; } This FOUC with WireTabs was much worse with the older admin themes - I hardly notice it in AdminThemeUikit but it is there. A CSS fix: /* Prevent FOUC for WireTabs content */ .WireTabs + .Inputfields > .InputfieldWrapper { display:none; } The main FOUC relating to fields that bugs me is the delay in hiding inputfields with show-if conditions. I'd rather have show-if fields hidden by default and then shown when necessary. There's an open request about that, along with a roll-your-own fix for the meantime: https://github.com/processwire/processwire-requests/issues/179 I'm not sure what sort of change you want to see with regard to CKEditor fields or image fields. Some inputfields take a moment to initialise - I'd rather see the interface as soon as possible even if parts of it need to adjust slightly after loading than have the whole interface hidden until loading is complete (not sure if that's what you're suggesting). Generally speaking the behaviour of non-core modules is up to the author of those modules. But in the case of the Lister Pro button you mentioned this is due to the way the admin theme wraps and clones "head" buttons. A CSS fix: /* Hide Lister button links at bottom when results are empty */ #ProcessListerResults:empty + .InputfieldButtonLink { display:none; }

Testing against the template object with the == "equal" operator is okay because it means "equal to after type juggling". So the template object is converted to a string for the comparison, and thanks to Template::__toString() the the string value of a template object is its name. When a page is first created (via admin) the only populated fields are Title and Name. So Page Reference fields are no different to any other field - they are empty until they are populated and saved in Page Edit. Maybe you want to hook Pages::published instead?

Related: https://github.com/processwire/processwire-requests/issues/268

Hi Charles, I've enjoyed reading the PW Review website over the last couple of days. The interview with Ryan is illuminating, and the technical information and videos are thorough and clear. It's obvious that you've put a lot of time and effort into the site and it will be especially helpful to new PW users. Thanks! I have a bit of feedback about the appearance of the site. Please take or leave it as you see fit - nothing that follows had any significant impact on the readability of the site. 1. It would be nice to make the header a bit more visual - maybe use the PWR logo in the header to give the site some clearer branding? 2. A favicon would be a nice touch. 3. There seems to be a styling glitch that is pulling the main content to the left on some pages: I'm not sure what's causing it because I'm not very familiar with Uikit but maybe someone here who is a regular Uikit user will have some advice. 4. Some of the headings are not immediately recognisable as headings. I think this is because the lower-level headings like h5 and h6 are as small or smaller than the body text and use the same weight as the body text. My suggestion would be to use a bold weight for the smaller headings so they are more recognisable as such. One of your tutorials explains how you modified the Uikit CSS so some headings have different colours: IMHO this is not such a good idea because it makes it a harder for the reader to know what is a link/clickable and what is a heading because there isn't a consistent colour to identify headings. True story: the Page Clone article was one of the first pages I read on the site and I clicked the "Related Source Documentation" text because I thought it was a link. This is all minor stuff. I'm looking forward to reading more as you add new content to the site!