Leaderboard

This version on the dev branch contains 26 commits (relative to 3.0.142) and is focused primarily in resolving reported issues, and we managed to cover 18 of them in this version. Thanks for the reports and help in our GitHub issues repo. This version represents about 2 weeks of work, and ProcessWire Weekly #284 has good coverage of those that occurred last week. More details about this week's updates can be also be found in the dev branch commit log. There are also some other minor additions and improvements in 3.0.143 as well. My favorite are the improvements to our logs system. It now collapses identical log entries that occur near each other. That means a single recurring log entry (like an error message) won't repeat indefinitely in the log and take up a lot of space. Now it just adds a counter to one log entry and updates the timestamp, rather than duplicating the entire log entry... Much more efficient. When you view a log in Setup > Logs, it identifies these collapsed log entries for you. In addition, the output in the "errors" and "exceptions" logs now have improved readability, isolating error messages and filenames from stack traces. Lastly, the ajax navigation in Setup > Logs now shows logs in newest-to-oldest (modification date) rather than alphabetical, which I find a lot more useful. The log at the top of the list is always the one most recently updated. For core updates in coming weeks, I'm primarily focused on preparing the current dev branch to merge to the master branch, as it's been awhile since the last merge and the master branch is itching for a new version. Most of you reading this already run on the dev branch, but there are many out there that also stick to the master branch, and with all the new stuff on the dev branch, I'd like to get our master up-to-date with this as well. Thanks for reading, have a great weekend!

Wouldn’t it be cool to have whole repeater items (or even repeater matrix items) language-specific. Some of my clients do have pages that are 90% identical in German and English, but there are some sections that should not appear in one or another language. I attached a concept screenshot. Would something like this be possible with some simple backend hooks and "hidden checkbox fields"? Or is it way more complicated?

@adrian, you were perfectly right, using the commit before the latest upgrade did fix the issue. Will post a report to Ryan to fix it.

Just grab the version before that commit, eg: https://github.com/processwire/processwire/tree/4b8b06af0f39828cec384c6bb8ad7997fc6d21fe Would you mind submitting an issue report about this so that Ryan can fix ASAP? PS - find and count methods only return published pages by default, so I am not sure why you actually need the status=published ?

@Robin S - the option is now available in the latest version. It feels a bit weird the way I have implemented it, but it's the quickest option for now.

Will try to use the earlier commit you've pointed me to and submit an issue report for Ryan.

Looks like Ryan just broke it in this commit: https://github.com/processwire/processwire/commit/6fcc0502b6d3c7c4aed2fc1b1842e513e6c5221c PS - it's coming from the "status=published" selector in your home.php template.

You're probably thinking about the Batch Child Editor module in "Lister mode".

Definitely would love to have such options. Language togglers could be hidden under same panel as 'change matrix type' panel.

One simple way to do this client side with normal fields would be to add an "Active languages" field to each Repeater Matrix type, and use that as a language activation switch. For example: Create a Page Reference field "active_languages" with the template "language" as selectable pages and the input field type set to checkboxes. Then add that field to each repeater matrix type. Finally, in the code that renders the matrix item, use something like this (code untested): // assuming the matrix field name is "sections" foreach ($page->sections as $section) { $if ($section->matches("active_language={$user->language->id}") { // render the field } } Now the editor can check which languages they want the section to be displayed in. Obviously you can also invert the logic and use the checkboxes to hide the section in a specific language. Of course, having this built in would simplify things a lot ?

Yeah, I am sure I can sort out the Pluralize issues. Of course the really simple solution here would be keep the field settings even with the create field checkbox unchecked - this way nothing else would need to be changed - you'd just use the field label as the way to generate all the other things. It would work well, but would be a strange / confusing interface.

I've definitely done that before as well, so you're not the only one ? You're right that it kinda makes the module name a bit weird, but then it's always been a bit of a mouthful anyway. The thing is I am not sure what would be the most logical way to support this - everything is pre-populated based on the field label and its plurality. I am thinking that there should be a "Create Field" checkbox in the field settings that is checked by default, but if you uncheck, the field settings are hidden and the form starts at the "Page Settings" fieldset where you need to manually enter the Parent Page Title and that is used to automatically populate the parent and child template field lables/names (rather than coming directly from the field label? Any thoughts?

Hi @adrian, This will probably sound like an odd request given the name of the module... What do you think about adding an option to not actually create a Page Reference field but only create the templates and pages (if any)? The smart template naming and template restriction features are so useful that I often execute the module and then just delete the Page Reference field because I don't need it. I'm not sure if you or anyone else ever do this, but if I'm not the only one maybe it would be a handy addition to the module?

All good. Did you know about: $page->images->first and $page->images->last I often use $pages->images->last when client uploads images and wants the last one to display. To get really specific, you can call the image within a Pageimages array by calling the image by its index. Pageimages derives from WireArray which allows you to call an item by its index https://processwire.com/api/ref/wire-array/eq/

By toggle off, I assume you mean "unpublish"? It's possible, but it's a real mess. However if you read through this: https://github.com/processwire/processwire-issues/issues/36 you'll be able to get it working.

Hi Kathleen! Welcome to the forums. For the blogposts pages content, you need to import the database from the server. But for the assets (files folder inside templates/assets/) there's a technique to get them using hooks like Ryan shows on his post: https://processwire.com/blog/posts/pw-3.0.137/

Last week I worked primarily on GitHub issues, and did some of that this week as well. Likely I'll be doing a lot of this in October. Thank you for all of your reports. While there's already a lot of commits on the dev branch, I'm going to wait till next week to bump the version, as I've got some stuff in progress that I want to get committed first (more on that below). Next week I'm releasing version 40 of FormBuilder that supports paginated forms, as well as forms within forms (not to mention some other minor additions). Basically, all the stuff that was covered in this video from a few weeks ago, plus a little more. I actually think it's ready right now, but as is often the case, I started writing instructions for using the new features today and thought of a couple minor tweaks that would be helpful along the way. So I'm going to apply those early next week, finish the instructions, test it all out again, and then release it... likely mid-week next week. For the ProcessWire core, one feature people have been asking for for quite awhile is the ability to specify custom fields with file and image fields. I've been working on that here quite a bit this week, and have the initial test cases working quite nicely! Unlike the Description and Tags fields that come as built-in options with file and image fields, the new option instead uses a subset of ProcessWire's Fieldtype and Inputfield modules to support this (note: it does not use pages like repeaters do). This gives you more flexibility in defining what you want and how you want it to look. Though there are some limitations of what kinds of fields you can use here, but I think you will like what it offers and how it works. For those that just need a description and/or tags, then of course those features will remain as they are. But for those that need something more for file/image fields, you are going to have a whole lot of new options in 3.0.142. Unless I run into any roadblocks in finishing development of this part, I'll have it ready by this time next week along with a blog post that outlines it in more detail.

Just stumbled across this older post and need to make an addition to @ryans post: You need to add: ... // make this to give MarkupPagerNav what it needs $a = new PageArray(); $a->setDuplicateChecking(false); // <-- add this line! ... just below the PageArray creation - otherwise this won't work, as you will always having only 1 item in the final PageArray.

Just for the records: There is a simpler solution now: $siblings = $page->siblings(false);

If it was me editing the pages, I could live with it, but for regular users is confusing. Not to mention paying customers .

Here you go. Images need to go into /site/templates/ImageSelect/[path/] and must be named [optionValue].jpg. For usage with FieldtypePage you need to add the module in the settings of InputfieldPage. For the newer options fieldtype it's available right away. Edit: My version might be more suited to the usecase of presenting layout options to the admins, rather than having a full blown thumbnail display. Archiv.zip