Robin S

I know, and I can't reproduce any problem, so more of a step by step guide to reproducing the issue on a clean PW installation would be helpful.

$wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $field = $event->object; if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); //... BTW, it would be better to hook a more specific inputfield render rather than just Inputfield::render. So something like InputfieldPageTable::render or whatever inputfield type you are targeting.

@Tom., members of the PW community might be able to help with your issue if you can isolate the conditions that cause it and list steps for reproducing the issue. In the GitHub issue under "Steps to reproduce the issue" you just say... ...which really does not make for a useful bug report.

It is a public method of the FieldtypePage class. See the description of the arguments in the DocBlock. Not sure. It works for me. But if you're not going to be changing the conditions for selectable pages often then you can just check the template and date in the foreach instead. There is no performance reason to not use a foreach. It's not like a $pages->find() selector where the database is involved. When you do anything with the value of a Page Reference field the entire PageArray (aka WireArray) is loaded (more about that here) and methods like find() or filter() are just foreaching the WireArray internally anyway.

As a general issue... It's a tricky one, how pages that are already selected in a Page Reference field should be handled if they no longer meet the requirements for selectable pages for that field. When getting the value of the Page Reference field via the API, I think the value should be validated through the isValidPage() method when it is "woken up" from the database. Currently the field value is validated on sleep but not on wakeup. Validating on wakeup would solve the situation where the value of the field when accessed from the API is different to the apparent value when viewing the field in Page Edit. But wouldn't solve the fact that the database value still includes an invalid page and so could give unwanted matches in $pages->find() for example. Or if that is not desirable for some reason then I think there should be some improvement to how invalid items are handled in the inputfield. Currently they are hidden in the inputfield, but that means that if you just view the page in Page Edit but do not save then you get a false impression of what the value of the field is. Maybe if invalid items were shown in the inputfield but highlighted in a warning colour, and then those items removed when the page is saved. Would be good to hear what others think about how invalid selected pages should be handled. For your specific issue... If you are foreaching the pages in your template, you could check the template and date of each item to determine if it should be output or not. Edit: you could actually use FieldtypePage::isValidPage() to validate each page in the Page Reference field value in your template, e.g. /* @var FieldtypePage $field */ $field = $fields->home_whatson; foreach($page->home_whatson as $item) { if($modules->FieldtypePage->isValidPage($item, $field, $page)) { // output $item } }

Thanks for the updates! Seeing as the profile editor is getting some improvements, could you look at adding FieldsetTab support? Related topics: https://processwire.com/talk/topic/16125-tabs-on-profile-edit-page/ https://processwire.com/talk/topic/16253-user-profile-tabs-markup-regions-the-lack-of-tuts/

To hide pages from ProcessPageList for non-superusers (doesn't apply for superusers) you can hook Page::listable(). $page->listable() bool Returns true if the page is listable by the current user, false if not. Can also be used as property: $page->listable So to hide pages that the user cannot edit you can add this to /site/ready.php: $wire->addHookAfter('Page::listable', function(HookEvent $event) { $page = $event->object; if(!$page->editable) $event->return = false; });

If you can control the naming of the images then that is an easy solution. Otherwise you need to do natural sorting of the files array. Something like: $files_array = $item->sequenz_files->getArray(); natsort($files_array); // Now foreach $files_array // And if you need the files as a Pagefiles object for some reason $pagefiles = new Pagefiles($item); $pagefiles->import($files_array); // Now foreach $pagefiles

Easiest way that works for inputfields both inside and outside of repeaters is to match the name of the field associated with the inputfield: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $inputfield = $event->object; if($inputfield->hasField == 'YOUR_FIELD_NAME') { //...

Does anyone know if it's possible to do something to "tell" PhpStorm how PW uses a template file and what variables are in scope there? For the purposes of code completion and to avoid erroneous undeclared variable warnings. Currently I manually list all API variables and variables declared in the auto-prepended _init.php inside a DocBlock at the top of every template file. This works but gets pretty tiresome, especially when you need to make a change globally. What would be cool is if PhpStorm could "know" that all API variables are available in every template file and that _init.php is prepended and so all the variables declared there are in scope. Anyone know a way to achieve this? BTW, for API variables the Functions API is a no-go for me because I dislike all the string concatenation that goes with it.

Okay, I've narrowed down the problem. It occurs whenever an image or file is uploaded and then the page is immediately saved via the hotkey. It seems to be related to the "Choose File" button having focus after a image/file is uploaded - like the first click() just shifts the focus but does not trigger a submit. What fixed it for me was, at the end of aos_triggerSave() where the button click is triggered, first focus the button: aos_saveButton.focus().click();

Or use a "saving" indicator that does not cover/lock the screen but just overlays a small part of it.

Hi @tpr, I've been having intermittent problems when using the save hotkey. I get the overlay but the form is not submitted. It's been happening on remote sites and on localhost, but I'm not sure exactly what version of AOS I first noticed the issue with. There are no errors in the browser console when the issue occurs. Browser is Chrome on Windows. Tricky one to debug because it only happens intermittently - just thought I'd mention it in case others have been experiencing it too. I'm wondering if the behaviour of the save hotkey could be a little less restricting so if an issue like this does occur the interface is not locked and the save button is still accessible. Currently I have to use my browser dev tools to remove the height and width from the added pseudo-element and allow pointer events.

The inputfield could be approached a similar way to Profields Table, which does support large amounts of data through limiting and pagination. It was the introduction of pagination within Table that prompted my GitHub request. But although an inputfield solution is important it is the API side that is of greater importance. Currently you cannot do anything with the value of a Page Reference field without loading all the pages into memory. So if you have a Page Reference field with 2000 items and you do... $item = $page->my_page_reference->first(); ...or... $item = $page->my_page_reference->findOne("name=foo"); ...then boom, you have 2000 pages loaded to memory. It's not like $pages->find() or $page->children() where you can be selective or limit what is loaded. Compare with $page->children(): parent-child is one kind of basic relationship between pages. Page Reference is the other kind of basic relationship between pages. Both of these relationships should be able to scale up, but currently only parent-child does. This discussion probably warrants it's own topic.

Matching by tempate name in a PageReference field is working for me: $items = $pages->find("test_page_reference.template.name=basic-page"); Could it be that you have no template named "events-detail" or no pages using that template selected? Incidentally, how did you dump the selector to get the selector string that PW converts to? Looks like a useful debugging trick.

Thanks, good to know.

Does that cause a problem though if you are doing a numerical comparison on the version? For example, in the "requires" item of getModuleInfo() or in the upgrade() method?

I think you should be able do this... $result = $pages->find("template=listing, (field1=data, field2=data), (children.field1=data, children.field2=data)"); ...but it's giving me buggy results when using child fields in the selector (works as expected for name and ID). Will do some more testing later and look at filing a GitHub issue. Alternatively consider including the variation pages in a field within the listing page (i.e. Repeater, PageTable or Page Reference field) so you can match their containing page in the selector.

Did you push this yet? Not seeing any new commit in the repo. I think there might be some other issue with the module regarding the modules directory, because the directory is showing v0.0.3 but SelectizeImageTags.info.php is v0.0.7. Maybe the getModuleInfo() in the main module file is still being read despite being commented out? Absolutely - the key/value tags is a big benefit and was about to recommend it to someone because of this when I struck the install issue. I just thought there was some discussion about the module being impacted by the core changes, but I might be misremembering or those things are now resolved.

The PDF thing isn't the main issue - that just happened to be the source of the website content in my example. The crux of it is: you have a website which consists of HTML and Javascript and images. Mobile devices have all the technology built in to render and browse this content. So why should it be so difficult to bundle those files up into some distributable format and view it offline on the device? If someone brings a tool to market that does this they can make a stack o' cash.

An example would be if you want to use a Page Reference field to store "likes", where each user that has liked a page is added to the field. For a large site with thousands of users this becomes a problem. There would be plenty of other examples for sites with very large numbers of pages. Pages (in the broad sense of being some grouped data) are of course central to the PW philosophy. And Page Reference fields are the primary way to make connections between pages. So it's important that this be able to scale up for PW to be seen as a credible candidate for large projects.

Hi @Macrura I'm not able to install SelectizeImageTags in PW 3.0.83. Edit: I can install it if I download and manually copy the directory to /site/modules/ This came up a while back... ...were you able to get to the bottom of what was causing it? Also, if I am able to install the module is it still working given the changes to image tagging in the core? I remember you discussing this with Ryan when the core changes were made and just wondering where things stand.

The selectable pages for a Page Reference field can come from anywhere in the tree - this could be hugely nested and several levels of parents may not be included in the selectable pages. So I don't think it would be possible to reliably and accurately display the tree structure for a list of checkboxes. Pagination is not supported in any type of Page Reference inputfield or in the value that is returned by a Page Reference field. It would be fantastic if it was, because the current state of affairs limits the extent to which Page Reference fields can scale up. It's one of the big limiting factors for PW in my opinion. There is an open GitHub request that you could add support to if you like. The way you are using the Page Reference field is not typical I think so perhaps not likely to become supported in the core. More typical would be to use a Page Reference field on the website pages to select a call-to-action page. You could possibly add Connect Page Fields to have the relationship work both ways and get an overview from the call-to-action page. Note also that you can use a custom label format for your inputfield to include the name of the parent page(s) if you want to get a sense of how nested the selectable pages are. Using a hook to set the label would give you greater control. Lastly, it's not outside the realm of possibility to create your own custom inputfield, using InputfieldCheckboxes as a starting point.

Sounds amazing! It would be good to get some guidance/opinions on what is the optimal way to prepare release notes. I'd rather not have to duplicate the same information in release notes, tags, changelog and detailed commit notes, but don't really want to be "told off" by the module for not doing it either.

DPS looks interesting and I will check that out. Though it still seems like work will be duplicated if the client also needs to deliver the content via a website. That is a great suggestion! I had completely overlooked EPUB format. I don't know a lot but an EPUB is essentially HTML right? So potentially quite easy to go from static HTML files (could even grab them from ProCache?) to EPUB. I think Calibre can do it but there are perhaps more professional tools. This also looks promising: https://epub.press/