ryan

Fridays are always the days when I'm full-time on ProcessWire. Other days I may be doing client work, or ProcessWire, just depending on the week. This week it's been mostly client work. And I just learned that I'll have to be out of the office tomorrow (Friday) for a family commitment. So I'm writing this weekly update today instead, and just sent out Teppo's great ProcessWire Weekly newsletter with ProMailer today (usually it gets sent Friday). Because of this change in schedule, I don't have much new to report just yet. Instead, I wanted to start talking a little about future plans, so here's a few ideas. I think we should get another main/master version out, perhaps by September. Following that, I thought we should focus on ProcessWire 3.1, or maybe it's time for version 4. What would be in this next major version of PW? For starters, we'll finally drop support for older PHP versions and start taking advantage of all that's been added new newer PHP versions (8+). This will involve lots of updates to the ProcessWire core code base, while remaining 100% API compatible with PW 3.x. I thought that would be a good starting point into our next major version at least. In addition, we'll likely be trimming some things out of the core and into separate non-core modules, such as FileCompiler, CKEditor, the two legacy admin themes, and a few rarely used Textformatter modules. Most likely we'll also have an overhaul of this website and some nice improvements to our primary (Uikit) admin theme to accompany the next major version as well. There will be plenty more too, but this is what I've been thinking about so far. Your feedback is welcome. Thanks for reading and have a great weekend!

@7Studio You might be able to do that with the new PageListCustomChildren module.

@kaz You probably don't want to change those salt values, they should match between your dev and live site. It's something that you should never change, as PW sets it up at install time and it should stay there for the life of the site. It sounds like you are using MAMP and if this is a local dev environment (I thought we were talking about the live server before) then I think MAMP by default uses this DB connection information: $config->dbHost = 'localhost'; $config->dbUser = 'root'; $config->dbPass = 'root'; $config->dbName = 'your_database_name'; If that's what your MAMP uses (which I think is the default) you could use those as-is except that you'd update the last line (dbName) .

@kaz Those salt values are generally going to be the same between your dev and live sites, unless you went in and manually changed them, and there would be no reason to do so. The error message you are seeing is saying that you don't have the right database connection information. It looks like you still have the database connection information from your localhost development site, and it's going to be different for your live site. Note the database login/pass is completely unrelated to those salt values, so you don't need to worry about those. You need to correct these entries below in your /site/config.php file to match those of your live server: $config->dbHost = 'database.host.name'; $config->dbName = 'database_name'; $config->dbUser = 'database_user'; $config->dbPass = 'database-user-password'; Replace all of the "database..." values above with the actual ones from your server.

@MarkE If it's a Process module (i.e. extends the Process class) then that's a module designed to be an application in the admin, and that module is only executed when clicked on in the navigation (assuming the user has permission for it). It sounds like you also need a module that has the "autoload" enabled, meaning that it either loads every time PW boots, or under some autoload condition that you define. Process modules aren't meant to be "autoload" modules. Process modules are interactive applications, creating and processing forms in the admin. Autoload modules hook into ProcessWire and adjust runtime behavior. These are very different responsibilities, so you want 2 modules: one Process module and one autoload module. For instance, there's FormBuilder and ProcessFormBuilder, UserActivity and ProcessUserActivity, ProCache and ProcessProCache, etc. If you absolutely had to have it all in a Process module, you could, but you'd have to do your own permission check in the execute() method(s), and your module would appear in the admin navigation even for people that didn't have access to it. It's cleaner to do it with two modules, and one can install/uninstall the other just by using the "installs" property in your module info for one of them, and "requires" for the other.

@monollonom Oops! Thanks for letting me know, fixed and re-posted

This week there were several commits to the core, mostly for resolving pending issue reports. In addition, this week I've posted a new version of the "Page Edit Children" module in the ProFields download thread. Below is the changelog for this new version: Added support for adding new children that can be fully edited right away (without having to save first). This is similar to how it already worked for the clone action. It makes it a lot quicker and easier to build out child pages, and you can add+edit as many as you want before hitting "Save". In addition, you can now drag/drop the "Add New" fieldset to the place where you want to add the new child page. This enables you to easily insert new pages anywhere you want, rather than only adding them at the bottom of the list. Added support for new child actions: Lock/Unlock and Hide/Unhide. These accompany the existing Publish/Unpublish and Clone actions. You can now configure what actions you want to be available via setting in the module configuration. For instance, maybe you don't need Hide/Unhide or Lock/Unlock, so you can simply turn them off. Action status is now more obvious, as the "on" states of actions (like unpublished, locked, hidden) now appears in red, making it much more obvious when a child page has one of these states. Added new configuration option that lets you choose whether the sort handle for each item should be on the left side of each child, or on the right side (with the other actions). You probably want it on the left side, unless you are using custom page icons (defined with templates) and you want them to appear. In v1 the sort handles were always on the right. Added support for an optional headline that appears above the child pages. Added support for customizing the "Add new" label in the module settings. If you want to change the icons that are used for actions, you can now do so by hooking the new actionIcons() hookable method. Added a confirmation dialog for the Clone action. This helps make it easier to recover if you accidentally click the clone action. There were also various other minor updates, including minor fixes and optimizations. This version is available for download now in the ProFields thread. This is still considered a development version so be sure to test thoroughly before using in any production environments. For version 3 (or nearby), I am hoping to add support for one of the feature requests: editing both children and grandchildren on the same screen. The screenshot below d emonstrates a few of things mentioned in the changelog above. Thanks for reading and have a great weekend!

@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' ]);