Leaderboard

In preparation for the next master version, this week no new features were added, but just like last week, more than a dozen issue reports were resolved. Having focused largely on fixing various issues over the last month, I feel pretty confident that the current dev branch is significantly more solid than the 3.0.148 master version. It adds and improves a whole lot, and also fixes a lot. And to the best of my knowledge, there aren’t any new issues between 3.0.146 and 3.0.164 that haven’t already been fixed. Basically, I don’t think it makes any sense to keep all these updates exclusive to the dev branch any longer, so have merged it to master, today. Consider it a soft launch, as I haven’t made it an official tagged version yet. Maybe I’m shy, but wanted to wait till Monday before Git tagging it and making it official. The master branch has a different audience than the dev branch, and so there’s always that possibility that some new issue will appear that hasn’t on the dev branch, and wouldn’t have. So we’ll let it marinate on the master branch for the weekend before broadcasting it very far. By this time next week, I should have a blog post ready that covers all that’s new in this version, which is 226 commits ahead of the previous master (3.0.148), so there’s a lot to cover. I want to thank you all that have been helping to identify and report issues on GitHub as they come up. Having covered a lot of issue reports over the last month, I can see a lot of effort goes into preparing many of the reports. Your work is appreciated. This month I focused primarily on the reports that I thought were likely to make the most difference to the most people. I also focused on issues that I thought could be accommodated without introducing potentially new issues or new code to test. Of course, not every report could be covered, and there’s always more to do, so I’ll be getting back to it on the dev branch here soon. In addition, I’ve held off on some new things I’ve wanted to add for awhile (a feature freeze of sorts) in preparation for an end-of-month master version. I’m looking forward to outlining all that’s new in next week’s blog post. Until then, thanks for reading and if you get a chance to test out the new 3.0.164 version, please do and let me know how it goes (both master and dev branches are identical right now). I hope you have a great weekend!

Release 0.7.0 adds a few features and fixes an issue reported by @MoritzLost. Collection panel: Field names as column headers The collections panel now uses the field label as column header. No need to pass them in explicitly anymore. See the docs on column headers for details. Shortcuts panel: Add option to hide shortcut summaries Disable the summaries altogether by setting the summaries option to false. Shortcuts panel: Fix undefined-index error when destructuring shortcuts

The idea from @Ivan Gretsky of using template tags (which are on the Advanced tab of Edit Template) seems like a really good one. An approach to searching for tags on templates is here: Another possibility would be to prefix each relevant template name (e.g. "prefix-templatename") and then find using the "starts with" operator: $foundPages = $pages->find("template^=prefix"); But I think the tags approach would probably be better – more flexible, and organises things nicely on the Templates page in the admin.

There is no easy way I know of to do exactly what you're asking for. But as far as I understand the actual need is to find pages with selected templates. If you do not need to select the templates to be used in selector in admin, you should be able to hard-code the selector like this (see here for explanation): <?php $childChildren = $pages->find("template=template-a|template-b|template-c, sort=sort"); If you need to be able to select the templates in admin, you could add this module to some page, and then use it's value in a selector. Hope the module still works in current version of PW. There is an option to tag fields in admin and then use the tag instead of a list of fields in selectors. If the same thing worked for templates, that could be a good way to solve this task. But I did not find any docs on that, so you just might want give it a try first, and then fallback to the module if it's not possible.

Thanks, @ryan! Sometimes I think that ProcessWire is so mature and feature rich that only fixing the issues at hand can make it stand out even more than adding the new stuff (until the the stuff is added and I start thinking that I could not live without the features just added))) Thank you so much for keeping the right balance.

And also for a11y ?

Thanks, that was it. ? parent.parent didn't work but I did a find on the template instead.

With your code you’re only getting the children of /shop/products/’s FIRST child. Is that what you expect? If you want all grandchildren of /shop/products/, you could do something like $products = $pages->find('parent.parent.path=/shop/products/'); (Sorry if that’s not 100%, I just got up lol)

I haven’t read to deeply on this thread but just wanted to point out quickly that infinite scroll libraries lean towards leaving HTML page markup in place for seo reasons in that you most likely want those pages indexed like any other paginated content.

Probably worth mentioning that since this setting prevents ProcessWire from using unfamiliar hosts in output, it's actually pretty important: Let's say that your server was configured to serve your site with any host that a visitor happens to provide. (I've seen this happen, but admittedly it's a major configuration fumble.) Someone points some-weird-and-perhaps-malicious-domain.tld to your site, and then visits the site using said domain. This could be intentional, or even an accident (again this is something I've seen happen, as weird as it may sound.) Finally some code — your own, or perhaps code from a third party module, or even some core feature — asks ProcessWire for the full hostname, and makes use of it in output. Now, if the $config->httpHosts setting didn't exist, ProcessWire would have no way to know which domains are valid, and it would just have to trust that the domain specified by the user is indeed a valid one. Any output using this potentially malicious domain could then get cached, leading to various cache poisoning related issues: redirecting other visitors to this domain, or perhaps making the visitor or ProcessWire itself unknowingly send private data there, thus granting a third party access to it.

Hi Rudy - it's fixed in the latest version.

I would like to add tags to my templates "myTag" and use something like $pages->find("template.tags=myTag"); but no joy. Is this unsupported? I solved the issue in other way but would like to know if this is possible somehow.

This does work: $tmpls = $templates->find("tags=myTag"); $result = $pages->find(template=$tmpls");