ryan

This week I'm releasing the ProcessWire Fieldtype/Inputfield module "Functional Fields" as open source in the modules directory. This was originally built in 2017 for ProFields, but hasn't required much in terms of support resources, so I thought I should release this newest version (v4) publicly. While this module is completely different from other Fieldtypes, I think it's quite useful and fulfills some needs better than other Field options. Give it a try and please let me know what you think. For an introduction to Functional Fields, please revisit this blog post which covers all the details: https://processwire.com/blog/posts/functional-fields/ Functional Fields is available for download in the modules directory here: https://processwire.com/modules/fieldtype-functional/ Thanks and have a great weekend!

@kuba Thanks for letting me know. Somehow I missed that during testing, but upon investigation it looks like I was using some old school configuration ideas in there that didn't make sense anymore. I was never able to observe the issue myself, but I bet it was related to that, combined with the other updates I made last week. I've gone through and refactored the whole configuration processes of the module up to modern standards so that it should work correctly now. I just tested it thoroughly in both single and multi-language mode again. Please let me know if you run into any other issues with it.

@bernhardTwo things I can spot here: 1. You are calling renderReady() from a hook after Inputfield::render. That is too late. What @adrian mentioned about hooking Inputfield::renderReadyHook() instead would likely enable you to do what you want to do. 2. Your renderReady() method has if(!$grid) return; and you would need to change that to if(!$grid) return parent::renderReady($parent, $renderValueMode);

This week the core dev branch version remains at 3.0.239 but relative to last week, it contains several optimizations and improvements. Details can be found in the dev branch commit log. I've also moved two Textformatter modules out of ProFields and into GitHub and the modules directory. These include: Auto Links This Textformatter module automatically links your specified phrases/words to your specified URLs. This is a potential SEO and accessibility tool for creating automatic contextual links with little effort. If there are pages that you commonly link to in your site from your textarea/rich text fields, then this Textformatter can save you some effort, automatically linking to those URLs. Text Blocks This Textformatter module enables you to assign a name to any block/region of text in a Textarea field. They are defined by typing start_name where you want the block to start, and stop_name where you want the block to stop. The block(s) of text can then be shown in any other Textarea field at runtime (site-wide) simply by typing the block name on its own line in the format show_name. Note that the word "name" in all of these examples would be whatever you've decided to name the block. Both modules have been updated just for public release with a new version. Both are considered Stable, as they have both been running without incident for several years. These modules were moved from ProFields to the public modules directory for three reasons. First is that they don't consume hardly any support resources, so they don't need to be commercially supported modules anymore. Second is that I'd like to keep ProFields focused more on field related modules (Fieldtype, Inputfield, and related) rather than Textformatter modules. Though admittedly the TextBlocks module does blur the line a bit, as it promotes potential greater reusability with existing Textarea/TinyMCE/CKEditor fields. Third is that there's already a lot in ProFields and I wanted to make room for new modules, such as the recently added PageEditChildren, which is part of ProFields at least in the short term. The FunctionalFields module may come out of ProFields well, as it hasn't required much in terms of support resources recently, though it is a useful Fieldtype/Inputfield module that is very much in keeping with the theme of ProFields, so I'm still debating on that one. Thanks for reading and have a great weekend!

@kuba Most likely this week.

This week on the dev branch are a few updates to the core including the following: Support for Inputfield header icon actions defined in PHP. If you recall, a couple weeks ago we released header actions for Inputfields via the JS Inputfield API. Robin S requested that the same be available from the PHP Inputfield API, and now it is. More details can be found in the phpdoc for the Inputfield::addHeaderAction() method here. New link action was added to Inputfield header actions. This was also added by request and it's another type of header action that simply links to a URL. It can optionally be opened in a modal window. The $database API variable has been updated with a new $database->reset() method which resets the database connection. This is potentially useful after a "MySQL server has gone away" type error, to re-establish the connection. The $database->execute() method also now uses it to attempt to reestablish the connection (for a few tries) when appropriate. Though I've not yet been able to test this one with an actual lost connection. There were various other minor updates, optimizations and fixes this week as well. In addition to the above core updates, we've got a new version of the UserActivity module (v8) posted in the ProDevTools support board. This version adds support for the PageEditChildren module and can properly identify which child pages are being edited alongside the parent. Previous versions only identify the page open in the page editor, and not the children open in PageEditChildren. Thanks for reading, have a great weekend!

@gmclelland Thanks, I actually don't have that module installed, I think it was removed when the site was rebuilt a few years back. I try and run a minimal module set and had uninstalled everything that wasn't used throughout the site. I've removed one example and updated the other on that page.

@Leftfield I might have missed something, why wouldn't it meet the conditions for listing? Otherwise, whenever you are ready, just let me know, and remove the "delete" status, and we can publish it in the directory. Thanks!

@Leftfield I've seen this in the pending modules list in the directory for the last couple of weeks, but it says that the status is "Deleted", so I've left it, thinking maybe you were going to create a new listing for it. I just wanted to check if you really wanted it deleted, or is it okay for me to approve it so it appears in the directory?

This week we've bumped the ProcessWire dev branch version to 3.0.239. Relative to the previous version, this includes 15 commits. This version is required if you decide to test out the new PageEditChildren module, which has also been released in the ProFields board today. I'm not sure it'll remain in the ProFields set of modules, as it's not even a field. But after spending multiple days updating ProFields modules to be compatible with it (also posted today), I thought it was best to keep them together for the short term. It's easier for me to support that way at least. Longer term, it may even become a core module. There's also a couple other modules in ProFields right now that I'm planning to move into the modules directory and GitHub. These most likely include TextBlocks, AutoLinks, and potentially FunctionalFields. These modules have not required much in terms of support resources in awhile, so may not need to be part of ProFields any longer. Thanks for reading and have a great weekend!

@jploch Ah okay, sorry I misunderstood, I thought you were referring to something for the module. Yes maybe next/prev sibling buttons would be a good addition. I've not used that before, I'll have to check out Bernhard's module that adds them.

@adrian I understand that much, but I can't figure out how that fits into the PageEditChildren output, where next/prev children are already present and visible.

@jploch The next/previous children pages are actually all present already, so a next/prev is a matter of moving your mouse 40 pixels down or up. But it's possible I still don't understand what you mean in this particular context. I'll try to get a beta of this module ready shortly, and once you've had a look at it let me know if the next/prev that you are thinking of still applies.

@Robin S I was thinking that since a JS callback is necessary to make it do anything, it was simplest just to keep it all JS, contained to one definition. At least for the case that prompted adding this feature (PageEditChildren module). But for cases like what you are describing, what you say makes a lot of sense. I will add an $inputfield->addHeaderAction([ ... ]); that does the same thing, maybe like these examples? // click action $inputfield->addHeaderAction([ 'icon' => 'hand-stop-o', 'overIcon' => 'hand-peace-o', 'tooltip' => 'Hello world', 'event' => 'myEvent' ]); // toggle action $inputfield->addHeaderAction([ 'onIcon' => 'toggle-on', 'onEvent' => 'MyOnEvent', 'onTooltip' => 'Click to toggle off', 'offIcon' => 'toggle-off', 'offEvent' => 'MyOffEvent', 'offTooltip' => 'Click to toggle on', ]); // link action $inputfield->addHeaderAction([ 'icon' => 'fa-link', 'href' => 'https://processwire.com/api/ref/', 'tooltip' => 'API reference', 'target' => '_blank', // or 'modal' or omit for '_self' ]);

@jploch Are you talking about pagination, like if there were too many children to show at once?

I've been continuing to work on the PageEditChildren module that I wrote about here last week. This week a "Clone" feature was added. You can click the Clone action and it'll create a copy of the page below the one you cloned, and then make it immediately editable before you even have to save. This Clone action is an example of an Inputfield header action, and it accompanies the Move, Pub/Unpub and Trash actions for each page in PageEditChildren. I thought this ability to add Inputfield actions seemed useful beyond just this module, so the ability has been added directly into ProcessWire's core Inputfields JS API. If you grab the current dev branch of ProcessWire, you can test it out if you'd like. You can paste these examples in your web browser's Javascript console. But in actual web development, you'd likely put these in a separate JS file that is added to your page editor with a hook. Open the page editor to any page, then open your Javascript console in your web browser, and then paste this in: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', callback: function() { ProcessWire.alert('Hello World!'); } }); That should add a hand icon to your "Title" field header, and if you click it, it'll pop-up a dialog box that says "Hello World". Let's say you wanted it to show a different icon when you hover it, and also to show tooltip text via a title attribute. You can add the 'overIcon' to specify what icon to show on mouseover, and 'tooltip' to specify the tooltip text: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', overIcon: 'fa-hand-peace-o', tooltip: 'Hello world', callback: function() { ProcessWire.alert('Hello World!'); } }); Above are examples of 'click' actions. We also support toggle or "on/off" actions: Inputfields.addHeaderAction('title', { onIcon: 'fa-toggle-on', onTooltip: 'Click to toggle off', onCallback: function() { ProcessWire.alert('You toggled on'); }, offIcon: 'fa-toggle-off', offTooltip: 'Click to toggle on', offCallback: function() { ProcessWire.alert('You toggled off'); } }); Toggle actions like this are primarily what is used by the PageEditChildren module to handle the Published vs Unpublished state, and Trash on/off state. Whereas "Clone" is an example of a Click action. Our callback functions in the examples above are very simple alerts, but of course you could make it do anything you want in those callbacks. Also added this week to the Inputfield JS API was an update to the Inputfields.label() function that now allows you to set the label for an Inputfield (previously it could only get the label). This is a bit of a contrived example, but since we were talking about header actions above, let's demonstrate the label() function within a header action. This example adds an action that lets you edit the Inputfield label: Inputfields.addHeaderAction('title', { icon: 'smile-o', callback: function($f) { ProcessWire.prompt('Enter new label', 'Label', function(val) { if(val) Inputfields.label($f, val); }); } }); By the way, there's a lot more to the Inputfields JS API, and it's all documented directly in ProcessWire's inputfields.js file. I'll be bumping the core dev version next week to hopefully accompany the first version of the PageEditChildren module. Thanks for reading and have a great weekend!

@MarkE There's definitely a lot of potential for this to evolve over time. Another example is that it can edit any pages this way, not just children. For that reason, I put in a hook: ___getChildren($page) so that anyone can override what are the "children" for the page. If there is hierarchy, such as there would be if the selector "parent_id=$page" were changed to "has_parent=$page", then I agree the way repeaters do hierarchy could work here too. But I figure the best bet is to keep it simple, focused and straightforward at first to get to a stable version 1, and then start evolving it to do more after that, if there's interest.

@Jonathan Lahijani If you edit your child page template and temporarily enable $config->advanced = true; you can click on the "System" tab and check the box to have it show the "name" field on the content tab, which should do the trick.

With the current project that I'm working on, there's eventually going to be an enormous amount of data to edit within it (in ProcessWire), and so I've been looking for ways to optimize and facilitate the editing experience. The goal is to save the people editing as much time as possible, and reduce the number of steps necessary to make common edits. This is what motivated the recent Table field updates. The is also what motivated a new module I'm working on called PageEditChildren. The PageEditChildren module takes the existing "Children" tab in ProcessWire's page editor and replaces it with a new one that lets you edit all of the child pages inline, directly from the parent page. For specific cases, such as the one shown in this video (below), this provides a more convenient way to edit multiple pages at once. It can significantly reduce the amount of back-and-forth between the page editor and the page list, or multiple page editors, keeping it all in one page editor session. Likely you would use this module to replace the "Children" tab on just some (not all) pages. Specifically, pages where the relationship between parent and children is one where they are often edited as a group. This is a fairly common use case in ProcessWire, and one where this module can save you a lot of time. From an editing standpoint, it has a lot in common with repeaters. Other modules that have some crossover are PageTable (core) when configured to create/edit children pages, and BatchChildEditor. Both use page editors in modal windows to accomplish editing children, a different approach than PageEditChildren, which keeps it all part of the single page editor. Though BatchChildEditor can edit title and status (hidden/unpublished) inline, and supports CSV export/import options, among other useful tools. All of these modules are worth consideration when there is a need to optimize the editing experience between parent and children. This is just an early preview of PageEditChildren, so I'm going to work on the module and test it out a bit more before releasing it. But it could be ready to share as soon as next week. Supporting file/image and repeater fields in this module required some minor core improvements, which are in this week's core updates. I'm interested to hear your thoughts on whether this would be useful in your sites as well? More next week. Thanks for reading and have a great weekend!

@adrian I hadn't thought of that in awhile, is it something you have come up with a need for? It would probably be fairly simple for me to add.

This week we have another update to the ProFields table field. A couple of weeks ago I wrote a blog post about Table v28 and the new actions features that it added. I've been working with Table a lot for my current client project, and have found these new features very useful. But I'm doing a lot of data entry in Table and found I still wanted more. Specifically, I wanted to be able to apply some of the actions directly on the row I was working in (rather than having to select it and then scroll down to the actions). Kind of like how one can click the Trash icon on any row to delete the row... I wanted to be able to apply other actions in the same way (Add, Clone, Copy, Paste). And Table v29 (released today) does exactly that. Another desire I had is for the for row-level actions to be just really simple, with not too much to look at... something folks could use rapidly without having a lot to read. This leaves several powerful and verbose features for the actions menu you saw earlier (the one that appears under the Table). Below is a video that outlines these new row-level actions. It's actually the same video from before, but I added to it for the version 29 features. So I'll try to post a link that starts at the timecode of the new stuff. But if you haven't seen this video before, you may want to rewind to the beginning. Below is the full CHANGELOG for this version: Expanded actions support so you can also execute actions directly on individual rows, which is often more convenient than selecting rows and then applying actions. Hold down the SHIFT key before clicking the row actions select and it will convert any actions that usually append rows to instead prepend rows. This works with the the Add, Clone and Paste actions when clicked at the individual row-level. It also works with the Select action for selecting multiple rows at once. The Select action is there in part for people that may not realize you can already click the sort arrows to select the row. Removed the Vex dialogs when copying or pasting and replaced them with other visual cues to indicate successful copy and/or paste. Added a new config option for disabling the DELETE (trash) icon on individual rows when individual row actions are enabled. This is because the row actions already include a delete action, so the trash icon can be redundant for some who might prefer the additional space. For all non-page selection column types, a new "Settings" option was added (named “formattedValueType”) to indicate how the value should be represented when accessed from a formatted page. Previously the API value was always the selection value. Now you can specify that it should include both the value and label (in your choice of array), or just the label rather than the value. Table v29 beta is available for download now in the ProFields download thread. More core updates are likely for next week. Thanks for reading and have a great weekend!

This week we have ProcessWire 3.0.238 on the dev branch. This version contains 17 commits containing new features (some via feature requests) as well as issue fixes. Recent updates have been nicely covered in ProcessWire weekly issues #517 and #518. Also added this week are the following: Improvements to ProcessPageClone, which now supports some new options such as the ability to configure it to always use the full clone form (a requested feature), and an option to specify whether cloned children should be unpublished or not. New $datetime->strtodate($date, $format) method that accepts any PHP recognized date string and reformats it using the given format. It also supports date strings that PHP doesn't recognize if you give it a 3rd argument ($options array) with an `inputFormat`. The existing $datetime->strtotime() method now supports an `inputFormat` option as well. The Inputfield class now has new methods: $inputfield->setLanguageValue($language, $value) and $inputfield->getLanguageValue($language), added by the LanguageSupport module. Previously there were no dedicated methods for this, so you had to manage them with custom keys containing language IDs if you wanted to programmatically use an Inputfield in multi-language mode. The ProcessWire.alert() JS method has been updated with an auto-close option (`expire` argument) that automatically closes the alert box after a specified number of seconds. InputfieldDatetime has been updated with 7 new interactively configurable settings for the jQuery UI date picker. See the screenshot below for an example of a few. Plus, its API has been updated with the ability for you to specify or override any jQuery UI datepicker option, either from PHP or JS, as requested by Toutouwai/Robin S. See the new datepickerOptions() method and phpdoc for details. Next week we've also got some more updates to InputfieldTable that take the newly added actions even further and make them easier to use. Thanks for reading and have a great weekend!

This week we have some updates for the ProFields table field (FieldtypeTable). These updates are primarily focused on adding new tools for the editor to facilitate input and management of content in a table field. All the details can be found in the new blog post with an accompanying screencast video— https://processwire.com/blog/posts/table-field-with-actions-support/

@TomPich I wouldn't recommend caching a field value like that, as I don't think you'll get any performance benefit since the amount of work for PW to do is the same either way there. What I'd recommend doing instead is caching the resulting output, which also means only loading the repeaterConsultants when it will be used to generate that cached markup. Whatever markup you generate, use that as your cache value, for example: echo $cache->get('consultants', 'hourly', function() use($pages) { $out = ''; $consultants = $pages->get(1027)->repeaterConsultants; foreach ($consultants as $consultant) { $out .= "<li>$consultant->consultantName</li>"; } return "<ul>$out</ul>" ; });

@iank I had a look at this and it seems like it can happen if you omit homepage language segments, and are also using the PagePathHistory module. What happens is that PagePathHistory provides a shortcut for finding the page, leaving no language segments for PagePathHistory to detect the language. I don't think PagePathHistory supported multi-language URLs until 3.0.186, so maybe that's when the issue started. Though the entire URL-to-page mapping system has been rewritten since 3.0.165 via the new PagesPathFinder class, so who knows. I think maybe it's not been reported before because just about everyone is using language segments on the homepage, and I always recommend doing so, but didn't intend to require it. I've attempted a fix on the dev branch, it's just one line of code, so maybe it'll work just to modify your copy too. Do you find this fixes it there? https://github.com/processwire/processwire/commit/9e6b89cf9331fccb8f41ae0b1785e21c8c5d62f0