Robin S

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).

@ryan, the new site search is great - such an improvement over the previous version. After searching I find myself trying to use the keyboard (arrow keys, enter) to highlight and select results, like I can in the PW admin search. Would it be possible to add this feature to the processwire.com search?

@bramwolf, you can adapt the approach suggested here, which avoids having to duplicate anything other than the template files: So you would: set domain 2 to point to the server that hosts the website at domain 1 allow domain 2 as an alias in the hosting configuration (see the alias options in cPanel, Plesk, etc) in /site/config.php check which domain is being accessed and set the templates path/url accordingly

I've never tried using the PW admin on Android before, but I just now tested it in Chrome on an Android tablet. It was not possible to "click" (i.e. touch or access via trackpad pointer) thumbnails in the square grid or proportional grid views of an images field. Therefore it was not possible to access the description field, crop links, etc, from these views. It was possible to switch to list view and access the description field, etc, from this view. However, the Actions dropdown (not sure if this is the same thing you meant by "Imageick" tools) was not clickable. So it seems there are some usability issues in the PW admin for Android. I tested the same things in Chrome on iOS and no issues there. I suggest opening a GitHub issue to get Ryan's attention. Edit: scratch all that. After updating the Chrome app all those things are working fine for me now. So that might be the same for you if you're running an older version of the Chrome app.

@ryan, could you please confirm: ProcessWire will no longer have a wordmark logo and will instead use only the graphic from the previous logo together with the word "ProcessWire" set in whatever brand font is decided on? If that's the case then the selection of brand font is even more important, and personally I don't think we should be considering any open-source/free/system font as candidates for the brand font. The problems being... 1. Free/system fonts are so ubiquitous that it's difficult to build up any association between the brand and the font when countless other brands and messages are associated with it. 2. Free/system fonts are widely used by ma-and-pa brands and amateur designers, and used for a multitude of non-designed purposes (e.g. quick paper signage like "toilet out of order", etc). This means they are often used carelessly in ugly settings, and the fonts become subconsciously tainted by association in the minds of the audience. I don't think we should risk that taint getting attached to the ProcessWire brand, even if only subconsciously. 3. In the case of a system font stack, an additional problem is that San Francisco, Segoe UI, Roboto and Helvetica Neue are all completely different designs with different "moods". Setting the brand logo in any one of a number of different fonts depending on device is tantamount to saying "we don't really care what typeface defines our logo and brand". It's true that problems 1 and 2 can apply to commercial fonts also, but in practice the barrier of having to pay for the font means that most users of the font are professionals (reducing the odds that the font is seen in ugly settings) and the font is less likely to be available to the creators of paper signs, etc.

As far as I know, it's not possible to use a repeater field in a Process module. A repeater is necessarily a combination of fieldtype and inputfield whereas a Process module can only contain inputfields.

Thanks for adding the font/colour variations to the preview Ryan. I think the typefaces without italic styles need to be taken off the table as body font candidates (unless we're never going to use italicised type on the site). It's just too great a typographic sin to have the browser slant the roman styles and it will make us look like amateurs. That would rule out the following from the list: Encode Khula Mada Palanquin Hind M / Hind S (the latin characters are the same in those faces - the difference is in the Tamil characters) Cairo Saira Heebo Can we get Work Sans added to the list? I think it's one of the classiest typefaces available as open-source and it has the distinction of being less familiar/thrashed/played-out than the usual suspects like Montserrat, Lato, Open Sans, etc. Note that italic styles do exist for Work Sans, they just haven't been merged into Google Fonts yet.

Could we maybe deal with this with an optional high-contrast mode? I know accessibility is important but aesthetics, depth and some degree of subtlety are also important. If we insist that all text everywhere has a contrast ratio of 7:1 to cater to the most visually impaired visitors then we give up things like using reduced opacity to differentiate primary/active text versus secondary/deactivated text, and must largely abandon the brand colour as a background. Also its arguable that a high-contrast design is harsher on the eye to the majority of visitors who are not visually impaired. This issue is improved by setting a max-width for the layout. Personally I'd rather see an increased text size for wider viewports than having the main text column floating in the middle, with looks off to me. And if we change to a different font that is less condensed and has a bit more letterspacing built into it then we can achieve a comfortable line length without compromising the aesthetics. Here is my Work Sans variation with the font-size bumped up a little - line length is at a comfortable 100 characters, matching @teppo's suggestion. The main content column could have a slightly reduced max-width on wide viewports if we wanted to bring the line length down a little further. https://sitemod.robin.nz/render/?url=https%3A%2F%2Fprocesswire.com%2Fnewsite%2Fstore%2Fpro-fields%2Frepeater-matrix%2F&amp;css=https%3A%2F%2Fsitemod.robin.nz%2Fnew-pw%2Fmod-2.css

I tested it too, and the problem occurs when the paragraph is longer than the truncate length, causing there to be no closing </p> tag present in the truncated string. There is an option for the fixUnclosedTags() method used by truncate, to close instead of remove unclosed tags... * Fix/close unclosed tags: * ------------------------ * When the remove option is false, it will attempt to close unclosed tags rather than * remove them. It doesn't know exactly where they should be closed, so it appends the * close tags to the end of the string. ...but the truncate method calls fixUnclosedTags() with remove = true and doesn't provide a way to do otherwise. I guess you could use WireTextTools::fixUnclosedTags() before calling $sanitizer->truncate but it would be nice to have the option built into the truncate method. Maybe an oversight by Ryan? Edit: request opened here: https://github.com/processwire/processwire-requests/issues/253 @bibsch, because your truncate length is short and will only contain a single paragraph you can achieve your objective by adding <p> tags around your truncated text: echo '<p>' . $sanitizer->truncate($child->body, 200) . '</p>';