Robin S

I agree the wording could be clearer here. If you look at the method code for Page::hasField() it is: return $this->template ? $this->template->fieldgroup->hasField($field) : false; So it's just an alias for Fieldgroup::hasField() where the fieldgroup is that used by the page's template. And the explanation for Fieldgroup::hasField() is: Not great English but you get the meaning. So if the given field name / field id / field object is not part of the page's fieldgroup then Page::hasField() will return false. @Henner7, if your intention is to check whether $item has an ID property and the property is not 0 (i.e. it is not a NullPage) then typically you would just check the "truthiness" of the ID property... if($item->id) { //... }

In the API documentation, for some reason all the methods under any of the Core Classes (e.g. Fieldgroup, Template) are trying to link to pages under the "Page" documentation - often linking to pages which don't exist. For example... Fieldgroup::getTemplates() links to: https://processwire.com/api/ref/page/get-templates/ Templates:getNumPages() links to: https://processwire.com/api/ref/page/get-num-pages/

@flydev, just trying this module for the first time today. Very nice! The subfolder exclusion options are coming in handy. Do you think the main Duplicator.module should automatically install ProcessDuplicator.module? Otherwise if you install by entering the Duplicator classname then the Process module doesn't get installed and it's not immediately obvious why the link from the config screen to the Package Manager results in an "Unrecognized path" error.

Yes. The Lister Pro class extends ProcessPageLister.

Check out the PLUs (Page Lister URLs) module. Or if you want to go the hook route try manipulating the defaultSelector property of the Lister: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { // Only for the initial load, not for subsequent user changes if($event->config->ajax) return; $lister = $event->object; // Do something here to identify if this is the lister you want to modify and return early if not // Then manipulate the defaultSelector property... // E.g. append to the existing defaultSelector $lister->defaultSelector .= ', your_field=your_value'; });

A page's ID is a property of the page but it's not a field that belongs to the page's template/fieldgroup. So $page->hasField() would not be expected to return true for 'id'.

True. Although the code suggested in the message would still resolve the issue so long as you haven't overwritten $page. If things go in the direction that I think Ryan has hinted at of the Functions API being the new default approach then maybe we'll see message references to API variables start switching over to the Functions API equivalents.

It's sort of breaking a cardinal rule in the first line though. If people overwrite core API variables then confusing error messages would be just the beginning of their troubles. ?

You wouldn't ever want to set a formatted value, but for a lot of cases there's no easy way for PW to detect if value X being set to field Y is formatted or not. Think of scenarios where the value being set to a field is some variable that has been built up earlier the dev's code. If the formatted value is a different type of data than the unformatted value (e.g. object vs string) then maybe PW could detect that but there are lots of cases where the formatted and unformatted values are both strings but with one or more textformatters applied to the formatted value. I think we need another nice verbose documentation page explaining output formatting because it's definitely not a simple thing to get one's head around. ?

I might have this wrong, but isn't the important thing that output formatting be off when you get and set values? It's not enough that it simply be off at the moment the page is saved. Doing the following doesn't solve the "problem" of output formatting... $page->foo = $page->bar . ' baz'; $page->of(false); $page->save(); ...and so likewise some feature that automatically turned off output formatting within the save() method wouldn't be a solution either. Output formatting has to be turned off earlier in the process of getting and setting values and PW can't automatically know when to do that, so it has be done manually by the developer. Edit: to clarify regarding getting values - output formatting only needs to be off if you are going use that value in a field you are setting.

Here is a more sophisticated version if you have a large number of siblings and don't want to include all of them in the pager navigation. <?php // Limit for number of sibling links $limit = 9; // Get the number of visible siblings $num_siblings = $page->parent->numChildren(true); // The default start value is zero $start = 0; // If the number of siblings is greater than the limit then we need to adjust the start value if($num_siblings > $limit) { // Get the halfway point of the limit $half_limit = floor($limit / 2); // Get the index of the current page relative to its siblings $index = $page->index(); // Adjust the start value to keep the current page within the sibling links if($index > $half_limit) $start = $index - $half_limit; if($num_siblings - $start < $limit) $start = $num_siblings - $limit; } $items = $page->siblings("start=$start, limit=$limit"); // Next page and previous page relative to current page $next_page = $page->next(); $prev_page = $page->prev(); ?> <?php if($items->count > 1): ?> <ul> <?php if($prev_page->id): ?> <li><a href="<?= $prev_page->url ?>">Previous</a></li> <?php endif; ?> <?php if($start > 0): ?> <li>&hellip;</li> <?php endif; ?> <?php foreach($items as $item): ?> <li class="<?= $page === $item ? 'current' : '' ?>"><a href="<?= $item->url ?>"><?= $item->index() + 1 ?></a></li> <?php endforeach; ?> <?php if($num_siblings > $start + $limit): ?> <li>&hellip;</li> <?php endif; ?> <?php if($next_page->id): ?> <li><a href="<?= $next_page->url ?>">Next</a></li> <?php endif; ?> </ul> <?php endif; ?>

That's not how MarkupPagerNav works. The MarkupPageNav module is useful when you want to stay on one page which is listing summaries from a PageArray of other pages. The pagination is for those summaries, so if with no limit applied a selector would return a PageArray of 20 pages and you wanted to show 4 summaries per page (limit=4) on some overview page then MarkupPagerNav would create 5 links. But you always stay on the overview page - the links in the pager don't take you to the individual pages that the summaries are for. So technically you could create a pager on the Table on Contents page, using a PageArray of child pages with a limit of 1, and then output the whole content of the child page in your foreach loop. But instead I think you want visitors to actually visit those child pages, not just stay on the Table of Contents page. So what you want is a normal menu for the pages in your PageArray. You can create this any way that you like to create menus in your site, but here is an example: <?php $items = $page->siblings(); $next_page = $page->next(); $prev_page = $page->prev(); ?> <!-- Add whatever classes or extra markup you need to this unordered list --> <?php if($items->count > 1): ?> <ul> <?php if($prev_page->id): ?> <li><a href="<?= $prev_page->url ?>">Previous</a></li> <?php endif; ?> <?php foreach($items as $key => $item): ?> <li class="<?= $page === $item ? 'current' : '' ?>"><a href="<?= $item->url ?>"><?= $key + 1 ?></a></li> <?php endforeach; ?> <?php if($next_page->id): ?> <li><a href="<?= $next_page->url ?>">Next</a></li> <?php endif; ?> </ul> <?php endif; ?>

A few more minor bits and pieces... The left-side-only border on the three columns under the home page code samples looks a little off: It would look better if the borders were only on the inside edges of the columns, like the three column example in the footer: I think others have already commented about the blog overview layout. I find this layout confusing to parse because the box alignment is stronger vertically than it is horizontally, which makes me scan the posts top to bottom when actually the order is left to right. Having equal box heights within each row would improve this somewhat but I think there will still be some confusion for readers trying to work out the order. Maybe we should consider an entirely different layout for this page? Also regarding the blue box style - the are some small issues with the little circles on the corners. Sometimes they are stacking behind a neighbouring box so the line goes through the circle instead of behind it. This can be seen in the screenshot above. And perhaps there should be a circle in every corner of each box (it doesn't matter if the circles are doubled-up where two boxes meet) because the visual logic of where the circles are missing doesn't make much sense in some places: Lastly, I spotted a couple of little issues in some code blocks. 1. LSEP character showing here: https://processwire.com/docs/start/templates/ 2. $ variable symbol sometimes gets wrong colour here: https://processwire.com/docs/selectors/

Check out Adrian's Page Field Select Creator if you haven't already. It makes setting up Page Reference fields just as fast as setting up Options fields.

Hi Matt, Your code looks like it should work okay so not sure why it isn't. But a few general observations... Making the connection between pages with the Listing template and pages with the PriceSpy template via only the title is not very robust. What if one of these pages needed to change title? You'd then have to do maintenance on all related pages or else the connection would break. I think it would be better to make the connection via Page Reference fields or possibly a parent-child relationship. Using a text field for prices is not ideal, and I think you should exclude the currency symbol from the field (I'm assuming the $ sign is in the field because I can't see it being added separately in your code). Better to use a decimal field type and prepend the currency symbol in your template. Then there would be fewer complications with sorting like you're experiencing now. It looks like you're using a templating language (is that Smarty?), but there is business logic in the template also which sort of defeats the most common reason for choosing to use a template language separate from PHP. If you're not bothered about enforcing a strict MVC pattern it would be simpler just to stick to plain PHP in your template files.

Absolutely this needs to be covered in the official documentation. It's foundational stuff and too important leave to a scattering of forum discussions. I'd hazard to say there are many here who have been working with PW for years and are not 100% clear on this stuff (myself included).

With the examples and documentation I think we should focus on illustrating things that a new user should use (depending on context) rather than all the things they could use. So we should take a best practices approach rather than trying to cover everything that technically will work. Please correct me if I'm wrong here, but I don't think there are any circumstances where the extra examples you gave would be advantageous over the four examples I suggested (again, which of the four would depend on context). So although it's common to see the form $this->pages in modules it's actually more optimal to use $this->wire('pages') because it's more efficient (no extra check needed for a class property named "pages") and cannot clash with class properties with the same name. (To be honest I personally do use $this->wire()->pages over $this->wire('pages') but that's just because it's easier to automate with macros in my IDE rather than for any other advantage).

Glad to hear it's (mostly) working. You can always open a GitHub issue if you think you have found a reproducible bug. But if it's something that occurs only on some devices and not others it might be a difficult one for Ryan to reproduce.

I have used these functions in the past for search excerpts: https://github.com/boyter/php-excerpt Together with this jQuery library for highlighting: http://bartaz.github.io/sandbox.js/jquery.highlight.html You might like to consider maintaining a hidden "index" field in your templates that merges the text content from other fields in a Page::saveReady hook. Then you use this field for searching/excerpting/highlighting.

Thanks! A little tricky on text fields because clicking the header focuses the input before you have a chance to copy the selection, but if you keep the mouse button down it's doable. Great tip!

Yeah, that's what I have been doing up until now when the irritation finally became too much. ?

A little solution that maybe helps someone... Often when I'm writing documentation for a site I want to get the label text from an inputfield header so I can paste it into the document. But the problem is that you cannot drag a selection around the header label in order to copy the text. So as a solution I used a bit of jQuery to get the label text when the inputfield header is Alt+clicked. $(function() { // If an InputfieldHeader is clicked... $(document).on('click', '.InputfieldHeader', function(event) { // And the Alt key is down... if(event.altKey) { // Get the header text, excluding that within the AdminOnSteroids field edit link var text = $(this).clone().find('.aos_EditField').remove().end().text(); // Copy the text to the clipboard copyToClipboard(text); } }); }); // Copy a string to the clipboard function copyToClipboard(string) { var $temp = $('<input type="text" value="' + string + '">'); $('body').append($temp); $temp.select(); document.execCommand('copy'); $temp.remove(); } I added this to the PW admin using the Asset Paths feature of the AdminOnSteroids module: The solution in action: Okay, so those are short labels and I could have just typed them out by hand. But some labels are longer, copy/pasting reduces the chance of typos, I'm lazy, time is money, etc.

Regarding the code samples on the home page, what if we had little tabs above each sample (or one set of tabs that switched all the samples) that allowed the visitor to switch approaches for the API variables? So for a code sample using $pages the tabs would switch between (essentially) equivalent ways of getting that variable: pages() $pages wire('pages') $this->wire('pages') If we want to promote the Functions API then that could be the default tab. There would be a brief statement explaining the reason for the different equivalent samples with a link to more detailed information. I haven't fully thought through the next part, but I wonder if this could be at least partially automated, either server-side or client-side, and applied to all code samples across the API documentation.

Hi @ryan, Could we get the current version numbers back on the master/dev download buttons?

Chrome is the same version as yours, Android 5.1, PW 3.0.112. I tested on a tablet - maybe it is different on a phone (I don't have an Android phone I can test on).