Robin S

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!

I wouldn't have known if it wasn't for @flydev's topic. Interestingly it seems that not everyone is happy about free private repos on GitHub: https://arstechnica.com/gadgets/2019/01/free-github-accounts-now-offer-private-repos/

The single/multiple value type determines the type of value returned by the field. The number of pages the user can assign in Page Edit is determined by the input field type. So it's possible to use a single page selection input type (e.g. select) with a multiple page value type. But regardless we all agree that the issue should be fixed for the single page value type.

Ah, yes, you're right. So no need for a new issue, but maybe @Manuel might like to add a link to this topic in the issue discussion to hopefully bring the issue back to Ryan's attention. ?

But they do. Not as directly as I first suggested, but there is a kind of circularity within the pages you are loading... As soon as your loaded pages form a circularity the out of memory occurs. This kind of problem seems to happen particularly when a "single page" value type is defined in the field settings. I expect that if you change the field setting to "multiple pages" then the error won't occur. To be clear, I think that it ought to be possible to load pages like this using a single page field without any error occurring. I encourage you to make a report in the PW issues repo: https://github.com/processwire/processwire-issues/issues add a comment to the existing issue: https://github.com/processwire/processwire-issues/issues/572

And page 1017 references page 1018, right? It's a circular reference issue that seems to happen when two pages that reference each other are both loaded into memory. Probably connected to this issue: https://github.com/processwire/processwire-issues/issues/572

Looks like that code needs a change to account for "single" Page Reference fields: // Get all pages where page_field_a is not empty $pgs = $pages->find("page_field_a.count>0"); // Get derefAsPage property of page_field_b to distinguish multiple/single page fields $deref = $fields->get('page_field_b')->derefAsPage; foreach($pgs as $p) { // For this page, get the pages selected in page_field_a $selected_pages = $p->page_field_a; // Standardise $selected_pages to PageArray in case of "single" field if($selected_pages instanceof Page) $selected_pages = $selected_pages->and(); foreach($selected_pages as $selected_page) { // Add this page to page_field_b on the selected page $selected_page->of(false); if($deref) { $selected_page->page_field_b = $p; } else { $selected_page->page_field_b->add($p); } $selected_page->save(); } } I don't fully understand what you're asking here, but in general you can switch "page_field_a" and "page_field_b" and run the code again if you need to. Of course make a DB backup before running any bulk API action in case something unexpected happens.

No particular reason as far as I remember - probably I was just trying different things and stopped as soon as I found a way to get the job done. Usually in PW there are several different way to achieve any goal.

There's a bit more more work needed before my module could be released publicly but I'll put it on my "to do" list. Yes, but in my use cases that's a good thing. This approach only suits certain types of search needs, where you want to implement a broad text search across most/all content. In my cases I want the search to match as many pages as possible, so I do things like explode the search phrase on space characters and then match each term with the %= LIKE operator so I'm catching part words too and without regard to the order of terms: $search_terms = $sanitizer->selectorValue($input->get->search); $search_terms = preg_replace("/\s+/", " ", $search_terms); // replace multiple spaces with single space $terms = explode(' ', $search_terms); foreach($terms as $term) { $selector .= "index%=$term, "; } //... And I want the excerpt to be Google-like in that it deals with the page's text content as a whole rather than caring about what fields were used behind the scenes.

File Info A textformatter module for ProcessWire. The module can add information to local Pagefile links in two ways: As extra markup before, within or after the link As data attributes on the link (handy if you want to use a Javascript tooltip library, for instance) Screenshots Module config Example of output Installation Install the File Info module. Add the textformatter to one or more CKEditor fields. Configuration Add markup action (and general) Select "Add markup to links" Select the Pagefile attributes that will be retrieved. The attribute "filesizeStrCustom" is similar to the core "filesizeStr" attribute but allows for setting a custom number of decimal places. If you select the "modified" or "created" attributes then you can define a date format for the value. Enter a class string to add to the links if needed. Define the markup that will be added to the links. Surround Pagefile attribute names in {brackets}. Attributes must be selected in the "Pagefile attributes" section in order to be available in the added markup. If you want include a space character at the start or end of the markup then you'll need >= PW 3.0.128. Select where the markup should be added: prepended or appended within the link, before the link, or after the link. Add data attributes action Select "Add data attributes to links" Select the Pagefile attributes that will be retrieved. These attributes will be added to the file links as data attributes. Attributes with camelcase names will be converted to data attribute names that are all lowercase, i.e. filesizeStrCustom becomes data-filesizestrcustom. Hook If you want to customise or add to the attributes that are retrieved from the Pagefile you can hook TextformatterFileInfo::getFileAttributes(). For example: $wire->addHookAfter('TextformatterFileInfo::getFileAttributes', function(HookEvent $event) { $pagefile = $event->arguments(0); $page = $event->arguments(1); $field = $event->arguments(2); $attributes = $event->return; // Add a new attribute $attributes['sizeNote'] = $pagefile->filesize > 10000000 ? 'This file is pretty big' : 'This file is not so big'; $event->return = $attributes; }); https://github.com/Toutouwai/TextformatterFileInfo https://modules.processwire.com/modules/textformatter-file-info/

As per the last comment in the linked thread, my approach is to use a Pages::saveReady hook save all text content on each page to a hidden "index" field in the template. Then there is just a single field to search and pull excerpts from. I have a module that I'll get around to releasing one of these days, but the basic idea is that in the saveReady hook you loop over all fields in the page, get the text content from the field depending on field type (e.g. strip markup from CKEditor fields, get descriptions from an images field, loop over subfields in a Repeater/PageTable, etc) and save that to the index field.

The TfaTotp module is not a core module so it won't be covered in the core docs. The base Tfa class is in the API docs here: https://processwire.com/api/ref/tfa/ There's no tutorial AFAIK but you can refer to the implementation in ProcessLogin and there is a basic usage example given in the comments for Tfa.php: * USAGE * ~~~~~~ * $tfa = new Tfa(); * * if($tfa->success()) { * $session->redirect('after/login/url/'); * * } else if($tfa->active()) { * echo $tfa->render(); * * } else if($input->post('submit_login')) { * $name = $input->post('name'); * $pass = $input->post('pass'); * $tfa->start($name, $pass); * * // the start() method performs a redirect if TFA is active for the user * // place your regular code to login user here, which will be used if TFA is not active for the user * * } else { * // render login form * } Also see the introductory blog post for info about how the TFA selection field is added to the user template: https://processwire.com/blog/posts/processwire-3.0.109-adds-two-factor-authentication/

@ngrmm, you can do this by not defining a parent for selectable pages in the field settings (just define a template) and add the following in /site/ready.php: $wire->addHookBefore('InputfieldPage::renderAddable', null, 'setAddParent'); $wire->addHookBefore('InputfieldPage::processInputAddPages', null, 'setAddParent'); function setAddParent(HookEvent $event) { $inputfield = $event->object; // Only for this one Page Reference field if($inputfield->hasField != 'tags') return; // Only for ProcessPageEdit if($event->wire('process') != 'ProcessPageEdit') return; // Set the ID of the parent page that new pages should be added under $inputfield->parent_id = 1234; }