ryan

@heldercervantes did you swap in a fresh copy of that file, or is that the same one that's bee there awhile? I grabbed that file mentioned from the site (RockFrontend.min.js) and un-minified it, and I'm guessing it's a false positive because I don't see any obvious monkey business in it. No references to other scripts or host names, no encoded strings, no obfuscated code, nothing that looks malware-ish to me. It is doing some iframe stuff, swapping of iframe src attributes and such, and it could that this is something that some malware does, but I think it's most likely legit here as it's using the same naming conventions in attributes as the rest of the code (i.e. starting with "rf.." for rock front-end). Anyone have any ideas why it detected it as malware? Even if I try to access the file in my browser, it gets blocked (since it's blacklisted), so I had to use wget to grab the file. Edit: I see you edited your message and that it's not the original file that got flagged. It'd be interesting to see what was in the older version. If it had malware in it, you'd want to check where it came from... like did it get modified by something after getting to your server, and if in a shared environment, are the file permissions too open?

This week a need came up in a client project. The client's team wanted to be able to navigate to their tours (pages) in the admin page-list by different criteria (operator, brand, boat, etc.). You can do this in Lister already (filtering by page references), but the client was looking for some predefined navigation paths in the main page list, as they thought this would be a helpful and time saving optimization, as they spend a lot of time in ProcessWire. They don't always know the exact tour at first, so starting from an operator, brand or boat helps them get to where they want to go more quickly. Once implemented, I thought it was actually quite useful for a lot of situations so decided to develop it into a module on my own time, and that's now available for download in the modules directory. I've published a new blog post that describes it more and covers all the details— https://processwire.com/blog/posts/page-list-custom-children-module/

All of this week’s dev branch core commits are from today, though some were worked on throughout the week. There's a mix of issue fixes and worthwhile new features. The InputfieldTextTags now can handle a couple more situations than it could before, such as single-Page selection mode and numeric-only tags, when used as an input type for Page fields. Another worthwhile addition is that ProcessWire now compares the PHP time to the database time once per superuser session and alerts you when they differ. It also provides some instruction on how to fix that situation. This prevents you from getting strange page modification times like "3 hours from now" when you just saved, and similar cases, for when the DB time happens to differ from the PHP time. (Thanks to @bernhard for the suggestion). This week's update is a day early because I've got to pick up my daughter from camp tomorrow and it's a couple of states away, so I'll be on the road tomorrow rather than at the computer. I hope you have a great weekend!

The core dev branch version has been bumped up to 3.0.240 this week. As always, see @teppo's excellent ProcessWire Weekly for details on what has been added recently. More can also be found in the commit log. This week adds the ability to hook into ProcessWire's admin live search to add your own custom results. This is useful for modules or for your own hooks placed in /site/templates/admin.php. Previously, only modules implementing the SearchableModule interface could manipulate the admin search engine results. Now there's another even simpler way to do it. We'll focus on examples placed in /site/templates/admin.php, but they could also go in /site/ready.php, /site/init.php or in an autoload module's init() or ready() method. The following is a simple example for when one types "today" into the search engine, it returns search results of pages that were modified today. $wire->addHook('ProcessPageSearchLive::findCustom', function(HookEvent $event) { $data = $event->arguments(0); // array $search = $event->object; // ProcesPageSearchLive $group = 'Pages modified today'; // description of this type of search if($data['q'] === 'today') { $items = $event->wire()->pages->find("modified>=today, include=unpublished"); foreach($items as $item) { $search->addResult($group, $item->title, $item->editUrl); } } }); The point of that example is just to demonstrate something simple. In reality, that example isn't that useful because you can already type "modified>=today" to get the same results in the search engine. So let's look at a potentially more useful example. There have recently been requests for better "id" search support in the search engine. In this next example, we add support for "id=123" searches, where it will match templates, fields or pages having id "123" (or whatever ID you specify). Further, it will also support it if you just type "123" on its own. Here's how we might accomplish that below. We'll limit this particular type of search to the superuser since this hook doesn't have any access control checking. if($user->isSuperuser()) { $wire->addHook('ProcessPageSearchLive::findCustom', function(HookEvent $e) { $search = $e->object; /** @var ProcessPageSearchLive $search */ $data = $e->arguments(0); /** @var array $data Search data */ $type = $data['type']; // what to search $q = $data['q']; // search query text // support search of "id=123" or just "123" // skip search if not an "id" search, or query is not a number if(($type != 'id' && !empty($type)) || !ctype_digit($q)) return; // reduce default search operator "%=" to just "=" (if used) $operator = trim($data['operator'], '%'); // search for id in templates, fields and pages foreach(['templates', 'fields', 'pages' ] as $apiVarName) { $apiVar = $e->wire($apiVarName); // get API var $selector = "id$operator$q"; // selector i.e. id=123 or id<10, etc. // some additional considerations for page ID searches if($apiVarName === 'pages') { // PW already handles "id=123" for pages, so skip that kind if($type === 'id' && $operator === '=') continue; // add more to selector for page searches $selector .= ", include=all, limit=$data[limit], start=$data[start]"; } // find by selector $items = $apiVar->find($selector); // tell ProcessPageSearch which results we found foreach($items as $item) { $title = $item->get('title|label|name'); $url = $item->editUrl(); $search->addResult($apiVarName, $title, $url); } // optionally return false to tell it to stop searching after this hook // which would prevent the default behavior of the search engine // $e->return = false; } }); } As you may (or not) know, the search engine displays help if you type the word "help". Help for the search engine usually consists of example searches and descriptions of what those examples do. If we want to add some help for our example above, we could add this to to the top of our hook above, perhaps right after the $data = $e->arguments(0); line: if(!empty($data['help'])) { return $search->addHelp('ID Search Help', [ 'id=1234' => 'Find templates, fields, pages with id 1234', '1234' => 'Same as above but “id=” is optional', ]); } That's the gist of it. These are fairly basic examples but hopefully communicate enough to show that you can add any kind of results you want into the search engine. Right now it's pretty simple and enables anyone with a ProcessWire site to add custom results into the admin live search. But if you find your needs go beyond this, the SearchableModule interface does support more options too. It's also worth using TracyDebugger to examine the $data array that the hook receives, as there are several other things in there you may find useful as well. Thanks for reading and have a great weekend!

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!