Leaderboard

The core dev branch commits this week continue to work on feature requests, and the plan is that the version in progress (3.0.173) is and will be focused entirely on added feature requests. While a few requested small features have been committed to the dev branch this week, there are also still two more in progress that aren't quite ready to commit, so those will likely be in next week's commits. Once they are in place, we'll also bump the version to 3.0.173. Following that, I'd like to have 3.0.174 focused on resolutions from the processwire-issues repo, and 3.0.175 focus on PRs. That's the plan for now anyway. It might be a good rotation to keep going. In the next couple of weeks I'm also likely to wrap up the client project that's kept me pretty busy recently, though it's all been ProcessWire-related and fun work thankfully. If you've also been busy building new sites in ProcessWire any time recently, please add them to our sites directory if you get a chance. I hope you all have had a great week and likewise have a great weekend!

@thetuningspoon After save actions don't participate in a delete action. But I can add a hook for that purpose: ProcessPageEdit::redirectAfterDelete(). I'll have it in there in 3.0.173 and you can hook before that method to perform your own redirect before the page editor does.

If you have the Apache module, I suppose the most efficient way is X-Sendfile. IIRC it would look something like this, but I’ve never done it because it’s not available on my shared hosting: header('X-Sendfile: ' . realpath($file->url);

This week I've been developing a client site, but also working through some of the feature requests. I'm going through them in order of "thumbs-up" on GitHub and trying to focus more on those that I can get through reasonably quickly. For a summary of what's been added, be sure to see the dev branch commit log. There's still a few more I'd like to add before bumping the version to 3.0.173, so will save that for next week. One of the requests was for the ability to add custom after-save actions in the Page editor. These are the "Save + Exit", "Save + Add New", etc., dropdown actions that you see on the Save button in the page editor. This is something that's already supported, but not formally documented. So I wanted to quickly go through a couple examples of how to do that here, as it is kind of useful and fun. Let's start with a "hello world" example to keep it simple, then we'll move on to a more practical example. Say we want a "Save + Say Hello" dropdown action in our page editor Save button. We need one hook to add the action, and another to process it. These hooks could go in your /site/ready.php file or your /site/templates/admin.php file, or in a module. First we'll want to hook ProcessPageEdit::getSubmitActions() to add our custom "hello" action: $wire->addHookAfter('ProcessPageEdit::getSubmitActions', function($event) { $actions = $event->return; // array of actions indexed by name $page = $event->object->getPage(); // page being edited // add a new action that says hello after saving page $actions['hello'] = [ 'value' => 'hello', // value for action that you will check 'icon' => 'hand-spock-o', // icon to show in action, excluding the 'fa-' part 'label' => '%s + Say Hello', // the '%' is replaced with 'Save' or 'Publish' 'class' => '', // optional class if you need different styling for button/link ]; $event->return = $actions; }); To process our action, we'll need to add a hook to ProcessPageEdit::processSubmitAction(): $wire->addHookAfter('ProcessPageEdit::processSubmitAction', function($event) { $action = $event->arguments(0); // action name, i.e. 'hello' $page = $process->getPage(); // Page that was edited/saved if($action === 'hello') { $notice = new NoticeWarning("Hello! You edited page $page->path"); $notice->icon = 'hand-spock-o'; $event->notices->add($notice); } }); That's all there is to it. That part where I created the $notice above could just as easily been $this->warning("Hello!..."); but I wanted to add a custom icon to it, which is why I created the Notice manually. Many of the built-in after-save actions perform a redirect to another location, such as adding another page, exiting back to the page list, viewing the page on the front-end, etc. If you have a need to perform a redirect after the save, use the $event->object->setRedirectUrl($url); method. This is preferable to calling $session->redirect(); yourself, as it is handled by the page editor after it has finished everything it needs to do. What if you just want to remove one of the existing actions? For instance, maybe you want to remove the "Save + Add New" action. That action has the name "add", so we can remove it like this: $wire->addHookAfter('ProcessPageEdit::getSubmitActions', function($event) { $actions = $event->return; // array of actions, indexed by name unset($actions['add']); $event->return = $actions; }); If there's another you'd like to remove, I'd recommend using TracyDebugger and bd($actions); so you can see and identify all the actions that are present from your hook. Now let's get to a more practical example. Let's say that you are using ProCache and you want to add a save action to automatically prime the cache after performing the save. By "prime the cache" I mean have it perform a page-view on the front-end that makes it save a new cache file for the page. Here's how you could do that: $wire->addHookAfter('ProcessPageEdit::getSubmitActions', function($event) { $actions = $event->return; // array $page = $event->object->getPage(); // page being edited $procache = $event->wire('procache'); if(!$procache) return; // if procache not installed, do not add action if(!$page->isPublic()) return; // page not public is also not cacheable if(!$page->viewable()) return; // page not viewable has no template file if(!$procache->isPageCacheable($page)) return; // page not setup for cacheing $actions['cache'] = [ 'value' => 'cache', 'icon' => 'fighter-jet', 'label' => '%s + Cache', // Save + Cache 'class' => '', ]; $event->return = $actions; }); …and our hook to process the action: $wire->addHookAfter('ProcessPageEdit::processSubmitAction', function($event) { $action = $event->arguments(0); // action name, i.e. 'cache' $page = $process->getPage(); // Page that was edited/saved if($action === 'cache') { $http = new WireHttp(); $response = $http->get($page->httpUrl); if($response) { $size = wireBytesStr(strlen($response)); $event->message("Cache primed for page $page->path ($size)", "nogroup"); } else { $this->warning("Error caching page: " . $http->getError()); } } }); Note that we don't have to clear the cache file here because that's something that ProCache has already done prior to our hook above being called. Thanks for reading and have a great weekend!

FieldtypeSelectFile & InputfieldSelectFile Inputfield Select File is an Inputfield & Fieldtype to select a single file or folder and stores the name and / or use the selected file as page template. The last option enables the editor to use multiple views for a page, depending on the selected template. Settings The folder containing the files and/or folders.A relative path relative to the /site/templates/ folder. Hide file extensions Hide files Hide folders Natural Sort (Select options)Sort files and folders in natural ordering (PHP >= 5.4.0) Change Page Template Just before the Page::loaded event the selected file is set as template file for the page. This setting can only be applied once per a page and folders are exluded from the select inputfield. Note that a page with no associated template file will render with the selected file. When to use ? Let editors select a file and base your own logic upon this. With the change page template setting you're able to use the selected file as template file. This could reduce the amount of normal templates needed and let editors choose how the page get rendered. There are plenty of use cases for this Inputfield. In the examples I call the field selected_file. // let the editor choose a CSS file $config->styles->append($config->urls->templates . "styles/" . $page->selected_file); /** * advanced usage example * * You need multiple ways to render your markup. Let the site editor choose which * file the page need to render. * */ $tpl = new TemplateFile($config->paths->templates . "includes/" . $page->selected_file); $tpl->set('current', $page); $markup = $tpl->render(); (It could be a real good companion with InputfieldSelector) Download at GitHub Modules directory

Hi, I am aware that this is a very broad description of a problem - but that's because I could not narrow it down so far. I just wanted to see if others have made that exprience or if this is even a known issue. On a regular basis, when logged into Processwire, the CMS and the front-end becomes nonresponsive. What happens is usually: User works for a while logged into the CMS and has another tab open, where she previews changes At some point, during a refresh/load of a new page IN THE CMS, the site is in an endles loading loop. When this happens, reloading the page, klicks on menu items, nothing responds. Closing the tab and and reopening in the same browser again results in endless loading loop (and eventual time out). When this happens, the front-end also cannot be loaded anymore in that browser. It's noteworthy that: Opening the site in another browser works Logging into Processwire in another browser works This happens regularly across various setups: Different browsers (Chrome, Firefox - haven't seen on Safari yet, because that's usually the last one I use to keep edition after Chrome and Firefox are 'locked') Different servers Different PHP versions (most installs are on 7.2.) Different versions of PW. I had it on 3.0.128 up to 3.0.165 now. Having site in debug mode or not Having cache activate or not Common to the installations is usually: Tracey Debugger RepeaterMatrix Rockmigrations Has anybody experience this? I haven't had any complaints from the clients yet - but that doesn't mean it does not happen to them. Internally this does happen regularly. Almost during every longer work session. Thanks for any insight. Adrian

I've looked at quite a few other CMS/CMFs and most of them fall down in some respect compared to ProcessWire, whether it be documentation, community, or ease of use. That doesn't make ProcessWire perfect, and given the diversity of usage scenarios there will always be things that could be done differently. The admin certainly can be a mixed blessing. It's so easy to use, that it's tempting to rely on it at least to start with, but then when you need to maintain changes, it can get complicated. I think what could be quite nice, if it's possible, would be to have the ability to enable change tracking for templates and fields, when they're modified via the admin. It's already possible to export and import field and template definitions as JSON, so combine this with the ability to track what's changed, and something like @bernhard's migrations module, and it could be easier to combine the ease of using ProcessWire admin to make changes, and the need to be able to roll out changes from development to production sites.

Hi @bernhard. Prompted by your comments here , I decided to give this module a go as it looks very useful. One thing I find rather confusing is that you seem to have changed the suggested methodology and it's not entirely clear to me what is now the suggested best practice for using the module. From what I can see, you are suggesting that users construct their own module (along the lines of your example). Installing this will then run the migration and uninstalling it will do a downgrade. For further migrations, it seems that you are suggesting just adding to this module, not creating a new module. Your previous approach seems to have been more version-based. I am trying to understand how that works in practice. I currently have 2 migrations that I want to carry out. The dev system reflects the end state of both. I want to do it in 2 stages so that I can throroughly test the first migration before applying the second (although I think there is no dependency, it is better to do them in the same order as on the dev system). My plan is therefore to create the first migration module, back up the dev database, load the live database to the dev system, install the migration module to this, then test. If that is OK, then, if I understand correctly, I should amend the migration module to include the second migration and refresh the modules to run it. I would then test again. Now, what if there is a problem with this second migration and I want to reverse it? Uninstalling the module would presumably undo both migrations (unless I change the uninstall method to be only partial, which seems inconsistent). Sure, in the dev system, I could just revert to a backup, but that would not be a solution if the problems happened in the live environment as (unknown) data will also have been updated - in that case I would need to just be able to reverse the last migration. So should I put the second migration in a separate module? In which case, this starts to look more like your initial approach (except that the use of the migrate() method allows for a more declarative style). Am I clear in explaining my confusion? If so, can you de-confuse me? By way of background, here is my first migration plan (as a set of human instructions), to give you an idea about what I am trying to do: 1. Add new fields to templates: a. Property -> operator b. Property -> website2 (new field req’d) c. BookingForm -> propertyPage d. home -> taxYear, dayMonth, month & website2 (with descriptions) 2. Amend home template for a. description of operator (& webmaster?) & website (now allowed) b. re-use of summary field as restricted access field with description/instructions (and resize) c. re-order fields as per dev system 3. Change title of home to “System” 4. Add/amend hanna codes for a. ManagementMember b. Operator 5. Edit cheque payment method to = that on the dev system 6. Add images and files pages to home 7. Change title of home 8. Re-purpose comparison field as “mailHeaders” and add to StandardMails template 9. Remove bodyTop field from StandardMails template – change body to 10 rows, summary to 3, footer to 2, update descriptions & notes in the template and update instructions in the page I think I can see that there are methods for most of that in your module, but I'm not sure about the hanna codes. The php in all my hanna codes is identical (as it just passes data to a separate script), but obviously attributes etc. are different. I don't think RockMigrations handles these, but they have convenient export/import features so that's not too much of an issue. The second migration is 1. Use findPages to detect all pages with BookingStatus in a body field (i.e bodyTop etc. as well as body – any field that can take a hanna code) – approx. 15 pages. Make appropriate changes. 2. Change the refNumber for cancelled statuses (2 pages). I can probably turn these human instructions into php (although it may be quicker just to do it in the admin, but then I definitely do not have a quick 'downgrade option!).

@psy So, just to make sure, that everything works well on the PHP side: You can make a request via Postman to the same url that you are trying to access via Javascript? And you get back the expected JSON-data? Unfortunately, I don't know much about NextJS and React. I am actually an Angular or Vanilla Javascript developer. In an Angular environment I would use Angular's httpClient to make an api-call: const params = new HttpHeaders({ 'x-api-key': environment.api_key }); this.httpClient.get('https://my-test-domain.com/api/page/1042').subscribe( response => console.log("Api-Response: ", response) ); I assume that React has a similar helper class as well. This makes a call to the page-route in my router-definition, which you can see here: https://github.com/Sebiworld/musical-fabrik.de/blob/master/site/api/Routes.php . It will return the ajax-results for the ProcessWire page with id 1042 in this case. I prefer to use the httpClient (if available) instead of the fetch function, which you are using in your code-example above. Mainly because I found the fetch function very cumbersome to use when dealing with more complex parameter data. But for a vanilla-js project I needed to use it, so I wrote a helper class that is way more usable: https://github.com/Sebiworld/musical-fabrik.de/blob/master/site/templates/src/js/classes/AjaxCall.js Here is how you can make an api-call: const ajaxCall = new AjaxCall({ method: 'GET', path: '/api/page/1042', headers: { 'X-API-KEY': 'oiasnduz3498gfsubasd' } }); ajaxCall.fetch().then(function(response){ console.log('Api-response: ', response); }).catch(function(response){ console.log('Api-error: ', response); }); I hope that helps you out ?

I figured, I will post the update: Turns out the culprit is Tracey Debugger. Once turned off, this phenomenon does not happen anymore. Luckily we only need it during installation and development of new modules really. All editors are now working with Tracey off and the problem has disappeared.

The following are a few links for you to check out: Wiremail Wiremail Class: https://processwire.com/api/ref/wire-mail/ Wiremail Related Modules https://processwire.com/modules/category/email/

The page path is in the title attribute, so you can hover on results to see the path in the browser tooltip: PW doesn't make it easy to manipulate the markup of admin search results. You could try the hook below in /site/ready.php to append the root parent title to the result title: $wire->addHookBefore('ProcessPageSearchLive::execute', function(HookEvent $event) { $event->wire()->addHookAfter('FieldtypePageTitle::wakeupValue', function(HookEvent $event) { $page = $event->arguments(0); // Limit by template or some other property of $page if($page->template == 'basic_page' && !$page->get_original_title) { $root_parent = $page->rootParent; // Set custom page property to avoid affecting root parent title $root_parent->get_original_title = true; // Append root parent title $event->return .= " (Root parent: {$root_parent->title})"; } }); });

Unpoly 2 is promised to be released soon: http://triskweline.de/unpoly2-slides/#1 Powered with Bootstrap 5 it might be a game changer for me. I have never been a fan of Bootstrap but version 5 impressed me so far. With the (optional) integration I can't wait to see what sort of productivity boost is possible for me by building upon both.

I hope I don't bother anybody asking that over and over again ? Have you tried RockMigrations?

@ryan - what do you think about having a referencesRaw() page method. If you're outputting a long list of pages referenced to another page, often all you need are the title and url field values. As an example, I am outputting a list of publications for a staff member. I believe this would really speed things up. Thanks for considering.

@benbyf Did this project ever go ahead? I'd be happy to pay the usual $140-150 dev licence fee for such a module. ProcessWire seriously lacking any kind of membership solution.

thx! it's working now calling the function like this. Cool! $CssClasses = $modules->get('InputfieldPageGrid')->getCssClasses();