Leaderboard

This week we’ve got version 3.0.147 out on the dev branch. Relative to version 3.0.146, most of the new commits (about 13 of them) are focused on resolving reports submitted at GitHub. I love refactoring existing code and adding optimizations and improvements to the core (and then writing about them in the blog). But right now I’m trying really hard not to! I’d like to have a new master version out before the new year, so the focus is on making sure the core is as absolutely stable as possible. Any time I refactor or add something new (or even sometimes when fixing something or another), there’s a chance of introducing new bugs, and it needs thorough testing on the dev branch, so right now the goal is that everything is thoroughly tested and stable before merging to the master branch. As a result, I’m trying to keep my hands off the core as much as possible, other than fixing obvious things that aren’t likely to introduce new code that needs testing. Please consider 3.0.147 release candidate 1 (RC1) for the next master. Thanks for all of your help and testing. Hopefully by (or before) 3.0.150, we’ll be ready for a merge to master. One way I try and take a break from modifying too much in the core before a master version release is to focus on other modules instead. That’s why last week I wrote about the new UserActivity module, and why next week I’ll be posting all the details for a new LoginRegisterPro module — one that I’ve been working on-and-off for more than a year, but have recently given it a lot of attention in getting it ready for release. I’ll save most of the details on LoginRegisterPro for next week, except to say that it provides an all-in-one solution for front-end login, account registration, profile editing and more. You might be wondering how that’s different from the LoginRegister module I built and released awhile back. That LoginRegister module was built for a very specific purpose and client, largely as a proof-of-concept. But there was a lot more interest in it than I ever expected, and several people suggested that there was a need that would be better served by the quality and support of a Pro module. The result is LoginRegisterPro, which is a full reimagining of that from the ground up. It does everything LoginRegister didn’t, in addition to everything it did. It goes much further in terms of security, reliability and customizability, and I look forward to telling you more about it. I may have it ready to release as soon as next week, but just wanted to make sure all the documentation was complete (and there is quite a lot of it so far). A couple other things I’m looking forward to working on here in the next month or so are the 2020 core roadmap and [finally] the new modules.processwire.com site. Thanks for reading and have a great weekend!

LoginRegisterPro <-- Great News!!

I fork long running processes to the background. You don't need PCNTL functions for this. In an import module which takes some minutes to run, I have a file "importworker.php" <?php namespace ProcessWire; include(__DIR__ . "/../../../index.php"); // bootstrapping PW error_reporting(2); // setting error reporting // ini_set('max_execution_time', 300); // 300 seconds = 5 minutes wire('log')->save('productimport', "starting import: " . date('Y-m-d H:i:s')); $importModule = wire('modules')->get("ProcessImportProducts"); $importModule->importController('start'); wire('log')->save('productimport', "Import finished: " . date('Y-m-d H:i:s')); Then there is a method for forking the heavy work into the background public function startImportWorker() { $path = $this->config->paths->siteModules . "{$this->className}/"; $command = "php {$path}importworker.php"; $outputFile = "{$path}output.txt"; $pid = shell_exec(sprintf("%s > $outputFile 2>&1 & echo $!", $command)); return; } All output of the importworker script is piped to output.txt. So I can see what happens when the process is running in the background. Some methods in my module echo stuff so I can see it in output.txt. Also for longer running loops in my module, I use the ini_set('max_execution_time', 300) method to prolong execution time. And I unset variables along the way to take care of memory issues. With some ajaxy JS, I get the contents of output.txt and show them inside a div#status in my module, so the user knows that there is sth going on. var ProcessImportProducts = { init: function() { $('#startimport').on('click', function(e){ e.preventDefault(); $.get($(this).data('href'), function( data ) { // console.log(data); ProcessImportProducts.pollResults(0); }); }); }, pollResults: function(timestamp) { var statusUrl = '?getstatus=1'; var statusText = $('#status'); // var loader = $('.loader').clone(); if(!timestamp) statusText.html(''); $.ajax( { type: 'GET', dataType: 'json', url: statusUrl, success: function(data){ // console.log(data); // if file has changed append data to statusText if(timestamp != data.timestamp ) statusText.html(data.message).append('<div class="loader"></div>'); // call the function again, this time with the timestamp we just got from server var timeout = setTimeout(function() { ProcessImportProducts.pollResults(data.timestamp); }, 1000); if(data.timestamp == 0) { clearTimeout(timeout); $('.loader').addClass('hide'); } // scroll to bottom of status div statusText.scrollTop(statusText.prop("scrollHeight")); } } ); } }; $(document).ready(function() { ProcessImportProducts.init(); }); EDIT: heres the part of my ___execute() function, that returns the status stuff for the JS if($this->config->ajax) { if($this->input->start == 1){ $this->startImportWorker(); echo 1; return; } if($this->input->getstatus == 1) $this->returnStatus(); } else { // module output to screen } Here's a good read about running processes in the background: https://medium.com/async-php/multi-process-php-94a4e5a4be05 Hope that helps.

It would be, but as we all know, life is not as straightforward like that ? There are issues Ryan solves pretty fast after being reported, there are others that take more time and there are some which seem to take forever... and the worst category is in which he is only marginally interested. Also, what we might provide as a "fix" via a PR can easily turn out to be just a workaround and there is no point in submitting such a PR. For example, in all of my use-cases PageTable without an "add new" bottom at the TOP of the table is a UX nightmare, so I have a JS hack to clone the button from the bottom to the top. In my point of view I "fixed" this is issue, but in reality it is just a hack which would be a good fit for this module, I think. Maybe we should call this module PwQuickFixes which might better reflect its intended purpose: temporary workarounds until they get properly fixed. We just need stats to see how many of us is using a particular quick fix, and another way to make our voice heard is to add a kind nudge by asking the user to go to the related Github issue in order to make her/his voice heard too.

Hello all, sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: a predefined folder in site/templates/ and/or a page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully. UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version. Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Read on for features and use cases. Features Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ? If you want to let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site (e.g. icons, but not limited to that). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Installation and setup instructions can be found on github. Here's how the input field looks like in the page editor: If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance. Thanks to all who contributed their feedback and suggestions which made this module what it is now.

Thanks @gebeer - this looks really useful! I wonder whether it would be useful to have an "Upload Image" option so that site editors can easily add images to this global directory so they don't need to resort to FTP or engaging their developer to add new images. I suppose the alternative would be to create a "Global Images" page in the page tree and point this module to the /assets/files/xxxx/ directory for this page - maybe that's actually the better approach? Anyway, I can definitely see using this quite often!

I really like this idea and almost see it as more important than fixes that this module might contain. This is something Bernhard could implement pretty easily - whenever the module's settings are saved, it could ping a server of his with a list of which fixes are enabled. The catch of course is that some users may not want these stats tracked. Perhaps there could be an option to allow / deny tracking? It would also be great if it didn't capture any site details. Any thoughts on this @bernhard ? It would be great to show Ryan how many people some of these issues affect.

The database will be the bottleneck. Use InnoDB and transactions. Find all items with the text "transaction" on this page: https://processwire.com/api/ref/wire-database-p-d-o/ https://processwire.com/blog/posts/using-innodb-with-processwire/ For an example of how they are used, find "transaction" in this: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module.php (BCE includes the copied supportsTransaction function, so it will work with older PW versions as well)

The gist of that thread was: Create a standalone script and bootstrap PW. (temporarily at least) switch tables to InnoDB. -> not sure about that use $pages->uncacheAll() + gc_collect_cycles() in each loop https://processwire.com/talk/topic/14487-creating-thousands-of-pages-via-the-api/?do=findComment&comment=187826

That would be a masterpiece of course! As @szabesz already wrote... sometimes you want to take care of some fixes you need and aren't available at time. Therefore the idea of naming this module PWQuickFixes seems to be pretty accurate.

PwQuickFixes This module is intended to serve as a collection of ProcessWire fixes that can easily be enabled via checkboxes in the module's config. It is NOT intended to be a replacement for github issue reports or pull requests! The idea is that we have a place where we can put fixes for issues that are not yet fixed in the core until they get properly fixed there. It is also not my intention to put pressure on Ryan to fix issues quicker. The idea is that we have a place where we can share our fixes across projects and across users and maybe get a better feeling on the "impact" of different issues. The module could also make it easier for Ryan to test issue reports and the solutions provided by the community: Intended Workflow Identify an issue Create the related files in the fixes folder of this module Create a PR so that I can merge the fix and everybody can use/test/improve it Create an issue in the official PW issues repo and link the fix in your description Usage Just add your fixes in the fixes folder and activate them in the config of this module (via checkbox). See the Foo example module how to add JS and CSS. https://github.com/BernhardBaumrock/PwQuickFixes

I just implemented it here: The only changes I had to make to the module were to set the root path higher than the default site/templates/ so that I could point it to /site/assets/files/xxxx and it works brilliantly! BTW, this is what the Global Images page looks like:

I think this could be handled automatically. If this module created a unique identifier for each installation then with each module settings save the ping would update the stats for this install by passing that identifier along with the fixes that are enabled / disabled. Make sense?

You get access to the ListerPro forum, where you can download the latest version. Maybe message @ryan per DM so he can grant you access.

Ok got it - this works! $ogImg = $page->single_image->first()->httpUrl; So as you said @gebeer it's something to do with the images being stored in an array, but no idea why looping through them manually wasn't working!

Why in a hook and why saving the image to another field and so on? Why not just checking it in the template and outputting different values for OG/SEO?

I think, the problem is with $page->single_image being of type Pageimages, not Pageimage. Inside hooks the $page object's output formatting is turned off. This means that even for image fields that are defined to hold only 1 image, the field is of type Pageimages, which is an array. You can confirm this by doing var_dump($page->single_image) (or better using Tracydebugger bd($page->single_image)). So to get to the actual image, you need to loop over the Pageimages array like foreach($page->single_image as $image) { // your logic goes in here }

Didn't @bernhard write something similar about how to be efficient in creating thousands of pages a few days/weeks back? Those weren' files but at least performance wasn't the problem if I remember correctly.

Hi Peter, take a look a at this thread :

Maybe it is art, but you know what would be logical and efficient ? ..... fixing issues via PRs ?

In you home template, you could do something like: <?php $newsArticles = $pages->find('template=your_news_templates'); foreach ($newsArticles as $newsArticle) { echo "<a href=\"" . $newsArticle->url . "\">" . $newsArticle->title . "</a>"; } ?> This would output each article's title (as well as a url to the article). Obviously you can change the markup to whatever you would need.

Maybe not related but in the past I always stumbled across two things: code in templates needed a $page->save whenever I changed something in an image field while in a module/hook it wasn't necessary or caused strange errors another thing was that I always had to foreach() through the image field I try to find an old module I built... images were a huge deal in it.

I have to admit that it doesn't look that bad for 7 years without a proper cleaning. I'm quite impressed actually. There is only dust and one bit of whatever... maybe paper. That's not a coder keyboard. Never! Where are all the chips bits, spilled soda and coffee stains and whatsoever? ?

Although the PW backend is really intuitive, ever so often my clients need some assistance. Be it they are not so tech savvy or they are not working in the backend often. For those cases it is nice to make some help videos available to editors. This is what this module does. ProcessHelpVideos Module A Process module to display help videos for the ProcessWire CMS. It can be used to make help videos (screencasts) available to content editors. This module adds a 'Help Videos" section to the ProcessWire backend. The help videos are accessible through an automatically created page in the Admin page tree. You can add your help videos as pages in the page tree. The module adds a hidden page to the page tree that acts as parent page for the help video pages. All necessary fields and templates will be installed automatically. If there are already a CKEditor field and/or a file field for mp4 files installed in the system, the module will use those. Otherwise it will create the necessary fields. Also the necessary templates for the parent help videos page and it's children are created on module install. The module installs a permission process-helpvideos. Every user role that should have access to the help video section, needs this permission. I use the help video approach on quite a few production sites. It is stable so far and well received by site owners/editors. Up until now I installed required fields, templates and pages manually and then added the module. Now I added all this logic to the install method of the module and it should be ready to share. The module and further description on how to use it is available on github: https://github.com/gebeer/ProcessHelpVideos If you like to give it a try, I am happy to receive your comments/suggestions here.

ProcessWire 3.0.146 contains about 22 commits (relative to 3.0.145) and these commits are largely focused on resolving reports from the processwire-issues repository. However, there have also been several improvements and related additions. One of these additions was a foundational upgrade that adds support for Fieldtype modules to use a custom class for Field objects. This will open more possibilities for improved Field/Fieldtype-specific APIs. Several have asked for improvements in the APIs of Repeaters and other fields, so this is a step that begins the lay the tracks for moving in that direction. Traditionally the API calls for working with Fields and Fieldtypes have not been nearly as simple as those that work with Pages, so this will be an upgrade that narrows and eventually eliminates that gap, longer term. On the core side, I currently plan on using this to improve the API for Repeaters, Comments and Options fields, and perhaps others. Outside of the core, ProFields will eventually take advantage of custom Field objects as well. As usual, none of this will break any existing code, but it will add simplicity for those that work with Field/Fieldtype APIs in ProcessWire. As for other changes in 3.0.146, I think last week’s ProcessWire Weekly did a great job of covering them, so if you are interested be sure to check that out. Next week is partially a holiday week here in the US, so I’ll be on a little bit of a reduced schedule, but will still be working on the core. I’m also releasing a new module into the ProDevTools set of modules next week, so I’ll tell you more about that one in next week’s blog or forum post. Thanks for reading and have a great weekend!

Whoa, just got bit by this as well. Couple of my sites (on an Ubuntu server) were using SessionHandlerDB, so this happened: > select count(*) from sessions; +----------+ | count(*) | +----------+ | 1561416 | +----------+ 1.5 million rows in the sessions table – "whoops". Should probably add sensible session.gc_probability number for these sites ?

I like this solution: $events1 = $pages->find("template=event, date>=today"); $events2 = $pages->find("template=event, date<=today, date_end>=today"); $events = $pages->find("id=$events1|$events2, sort=date, limit=15"); // now you can paginate $events

$numApproved = 0; $numPending = 0; $numSpam = 0; foreach($page->comments as $comment) { if($comment->isApproved()) $numApproved++; else if($comment->status == Comment::statusPending) $numPending++; else if($comment->status == Comment::statusSpam) $numSpam++; } echo "<p>$numApproved approved comments.</p>"; echo "<p>$numPending comments awaiting moderation.</p>"; echo "<p>$numSpam spam comments.</p>";