Robin S

@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; }

Yeah, these view links are not helpful IMO. Related request: https://github.com/processwire/processwire-requests/issues/274 Edit: just noticed that you already thumbs-upped that. ?

Not with the module itself because to hide or show something in your template would require logic within the template file. But you could use a similar approach to that used in the module. In the template you would check if the user has the necessary role, or if a GET variable containing some password is present, and if so you show the extra content. I don't have any ideas regarding the limited editing though. I don't think you could (or should try to) override the PW admin access controls using just a query string. In the past if I needed to show a client the edit interface for a site before it was ready I just showed them a screenshot or a screencast.

Are you sure? Page Path History seems to correctly redirect pages after I move a page structure in Page List.

@ethanbeyer, no worries, just glad to help. ? It would be good to get to the bottom of what is causing ImageMagick to suddenly fail though. @netcarver linked to this article recently in another topic: https://alexvanderbist.com/posts/2018/fixing-imagick-error-unauthorized It deals with a new security policy relating to PDF conversion but I wonder if some other policy has been introduced that affects JPGs too. If so there might need to be a fix applied to ImageSizerEngineImagick. Maybe your host could shed some light on what policy is being triggered by your uploads? Or maybe @horst has heard something about an ImageMagick update that might be connected?

I don't think this has anything to do with the home page specifically - it's the 404 page, which gets markup from _main.php because I expect that file is auto-appended to the template. My suspicion is that some security policy on your server is interfering to block the normal PW behaviour, and the 404 is a side-effect. It looks like ModSecurity is not enabled though so perhaps something else. You could ask your hosting provider to check. Are you using ImageSizerEngineImagick by any chance? Does the issue resolve if you uninstall that to use the GD default?

So serve the original rather than a variation then. It's totally up to you and what you write in your template code - PW doesn't compel you to load anything on the front-end.

Your selector would go something like: $properties = $pages->find("template=property, pstatus=''|sold, sort=pstatus, sort=price"); This works because when you sort by the value of pstatus an empty value will sort before any other value. Which is fine in this case because you happen to want the pages with empty pstatus (available properties) to sort first. But you actually get more complete control of sort order if you create a status page for "available", make the pstatus field required, and set the default value of pstatus to "available". That way you can set the sort position of the "available" page to some other position than first if you happen to need to change to that at some time in the future. Then in your selector you can sort by the sort value of the status page selected in the pstatus field. So if you needed to find properties with statuses "available", "sold" and "paused" and the sort order of those status pages in the tree is "paused", "available", "sold" then your results would get that same sort order with this selector: $properties = $pages->find("template=property, pstatus=available|sold|paused, sort=pstatus.sort");

If you load an admin page in a modal or panel from the front-end then there's not really any special PW magic there - it's just an iframe. So you don't have to use a JqueryUI modal or panel just because the PW admin does - you can use any JS modal library that supports iframes. There are a bazillion out there so there's bound to be something that doesn't cause this scrolling issue you're describing. BTW I can confirm the tree panel scrolling issue on iPad - please do report it.

You don't need to migrate to a new hosting server just because the domain name for a site changes. Point the domain to your host and update $config->httpHosts in /site/config.php. Depending on the type of hosting you might need to adjust a setting there too, e.g. update the primary domain if it's a cPanel host.