Leaderboard

Sometimes you need to execute a slow task after some event occurs in the PW admin, and normally you have to wait for this task to finish before you can continue using the admin. This is because PHP is "blocking", meaning that while one thing is executing nothing else can execute. There are potentially lots of different kinds of tasks that could be slow, but just as an example suppose you want to generate resized variations of images on a page, and there are a lot of images. You might have a hook like this so that any non-existing variations are created when the page is saved: $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Create an image variation for each image foreach($page->images as $image) { $image->size(1200, 1200); } } }); When you save a gallery page in the PW admin, the admin will be unresponsive and will only load again after all the variations have been created. I wanted to find a way for slow tasks to be triggered by events in the PW admin and for the website editor not to have to wait for the task to finish before continuing with other work in the admin. Inspired by this StackOverflow answer I came up with the following solution that seems to work well. Using the image variations task above as an example... First we make use of the URL hooks feature to set up a URL that can trigger tasks to run when it is loaded: // A URL that will trigger tasks when loaded $wire->addHook('/run-task/', function($event) { $input = $event->wire()->input; // A simple check to avoid unauthorised access // You could implement more advanced checks if needed if($input->post('key') !== 'cTdPMBQ7x8b7') return false; // Allow the script to keep running even though we have set a short WireHttp timeout ignore_user_abort(true); // The "create variations" task if($input->post('task') === 'create-variations') { $page_id = (int) $input->post('page'); $p = $event->wire()->pages->get($page_id); // Create an image variation for each image foreach($p->images as $image) { $image->size(1200, 1200); } return true; } return false; }); Then in the Pages::saveReady hook we use WireHttp to load that URL and post parameters that define what task to run and anything else needed for the task (in this case the ID of the page that has been saved). $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Load the /run-task/ URL using WireHttp $http = new WireHttp(); // Set a short timeout so we don't have to wait until the script finishes // Timeout values shorter than 1 second can be tried once a core issue is fixed // https://github.com/processwire/processwire-issues/issues/1773 $http->setTimeout(1); $url = $event->wire()->config->urls->httpRoot . 'run-task/'; $data = [ 'key' => 'cTdPMBQ7x8b7', 'task' => 'create-variations', 'page' => $page->id, ]; $http->post($url, $data, ['use' => 'curl']); } }); By doing it this way the task runs in a separate request and the website editor doesn't have to wait for it to finish before they can continue working in the PW admin.

@teppo With great power comes great responsibility :-). So far I got the impression that PW is a great tool for devs to create websites of any kind with an excellent API. As even template files are PHP files by default any non proper usage of PHP commands in templates, modules or hooks can cause serious entry points for an attacker. Guess most critical vectors of attack in 2023 are still not proper sanitized user input used in queries - even PW queries - or inputs output on screen without proper sanitizing in first place (e.g. CSRF attacks, reading JS Cookies or directory traversal). So yes, eliminating attack vectors is always a good habit devs should care about.

Fair ? If PHP has write access to directories containing executable code, this opens a huge can of worms: a malicious or vulnerable module could allow attackers to write code and wreak serious havoc on the target system. Same thing could happen if there's a flaw in site code that allows attacker to write or download their own executable files. You could argue that a malicious or vulnerable module could cause similar problems anyway, but in my experience it is often easier to slip in code that writes code than code that does evil things. At the very least it's another attack vector. I'm aware that even the installer suggests that we allow PHP to write to the modules directory, but in my opinion that should not be done unless absolutely necessary. And I have yet to come across a situation where that would be the case ?

This week, work continued on our next main/master version with 8 issue fixes (see dev branch commit log). In addition, the WireHttp class was updated with new delete(), patch() and put() methods which correspond to http methods of the same name, These might be used by web services in addition to the more common GET and POST methods. In prior versions of WireHttp, you could still use delete, patch and put methods, but had to use WireHttp::send() with the $method argument set to one of them. Now that there are separate class methods for these http methods, it makes them a little simpler to use and more clear in code. It may be that you never need these methods, or it may also be that you use a web service that uses them extensively. The more web services I work with, the more I come across them, and figured it would be good for WireHttp to have more clear support for them. I know things slow down in the summer, but we haven't had many submissions to the sites directory lately. If you have launched any sites using ProcessWire in the last year or so, and haven't submitted them to our sites directory, please submit your websites to the directory when you can. We really enjoy seeing what what people are building in ProcessWire. Thanks and have a great weekend!

Yes. Current approach makes use of ProcessWire's database export feature and I'm not sure if it can do this (from what I can tell this is not really what it was meant to do; it was rather intended to store the dump "permanently"), so this might need to be a different command. Just like flydev mentioned above (native:restore). Personally I don't see much reason to use the ProcessWire db export method in this context, unless it does something special that mysqldump can't do (?). Various reasons for this. Resetting passwords is one, but I've also had to remove users matching specific conditions or temporarily disable their accounts, update categories for posts (e.g. a main category is removed and all posts that belonged to it need to be connected to a new one), automate some content modification for a number of pages matching specific criteria, etc. In WP it's not as easy to create "bootstrap scripts" as it is in PW, so WP-CLI is (in my opinion) often the easiest way to do any sort of bulk edit ? This is where differences between WP and PW matter. WP has a built-in cron task queue: the core maintains a list of registered tasks (some from core itself, others registered via hooks from theme(s) or plugins). Each task has a set recurrence (interval), a precalculated time for next run, and hook function to trigger when the task is due. WP-CLI can be used to trigger a specific task, run all tasks that are due now, etc. By default tasks are executed "lazily", similar to what ProcessWire does when using Lazy Cron, but typically you would not want to rely on that or slow down page views for regular users. Instead you'd set up a real cron job to run e.g. once per minute. That cron job then executes "wp cron event run --due-now --quiet". I don't say this often, but in this area WP is — in my opinion — ahead of PW. The cron setup makes a lot of sense, and it's really easy to keep track of active tasks ?

Dear all, just released v0.0.2 of my No Cookies Without Consent module. I basically added my Typescript and SASS source files and config files so other users can modify the minified Javascript/CSS code more easily themselves. Using Windows 10 and VS Code as my PW dev environment. The NPM modules used (typescript, sass, esbuild) can easily be installed as dev-dependencies via npm run install inside the module folder. Apart from that some code refactoring to avoid flickering of cookie consent on page reloads and some code clean up. I set the target of the transpiled JS file to es6 for better browser support (before it was set to ESNext). Have fun P.S.: The Github release section contains a ZIP-file containing just the ProcessWire module files without the DEV stuff included. The attached ZIP-file is the preferred installation option for end users, while cloning the git repo is the preferred option for devs wanting to adapt/modify the module code.

In wire shell no, but wirechief contain them and more, like pw:restore native:restore (mysqldump), duplicator:restore (working with packages), etc. My screenshot do not reflect the current version. Almost all commands contains subcommands depending on the arguments given. Too much to be listed here without spamming the thread. I dont use migrations everywhere and the cli tool allow, for example, to create templates, fields and assiging them in seconds, or installing pw and a specific profile from the terminal without writing any code, its time saver, like artisan. Keep in mind that the tools is born 8 years ago and abandoned since 4y.

Haha, turns out I only had to change one setting in RockShell to use colon instead of hyphen when loading the commands and it beautifully groups them into their namespaces ?

Thanks for elaborating! When you put it like that, it definitely seems like a lot ? In my case (using the core approach) the process boils down to this: Translate the word in admin Click the "view" link to display current CSV content Manually copy and paste the new string from the CSV content in admin to existing CSV file bundled with the module git add + commit Manual step is required to copy the data, and another manual step is required to update translations for a module on another site, but to me personally it doesn't feel like a very big deal. Additionally I would never allow PHP to write anything directly into the modules directory — in my opinion it is a very risky thing to do, so that option is out of the question ? Anyway, since the core has a system for bundling translations with modules, it would make sense to see how it could be improved so that perhaps we don't need "competing" solutions. From this thread alone I've picked a couple of ideas that would (in my opinion) make sense as core additions, and I'm planning to open requests or submit PRs for those.

Thx for your screenshot! Looks like we should maybe change the syntax for commands from dash (db-pull) to colon (db:pull) to get the grouping?

For those who was using wire shell in the past and will send PR to rockshell, there is some handy ideas.

Some time ago, I forked wire shell and renamed it WireChief to avoid the ads made on the defunct domain name. It was designed primarily to create pw/vite applications (the latter is about to be released). Also, I haven't looked at @bernhard’s RockShell, but maybe I'll switch to it.

A few screenshots to demonstrate:

Thanks for sharing! As always, your contribution to ProcessWire and its community rocks!

I get this error all the time on my development server. 9 out of 10 times I had simply forgotten to change config.php, and my site would try to access the database using my local config! Could it be that you've accidentally overwritten that file with your local version? I ended up implementing a switch in config.php that checks what domain we're on, and sets the config variables according to the current domain. Should it be an upgrade issue, you can get into some trouble when upgrading through the ProcessUpdate module because the JS files for AdminThemeUikit are missing! I had this issue a while back with a bunch of sites that were suddenly running on PHP8 due to a decision of the hosting provider, and some friendly people on this forum helped me update ProcessWire manually to get around this issue. You can find the topic here.

@orchardheightsdental Netcarver is right that you need to get a look at the /site/assets/logs/errors.txt log and see what the last entries are in it. If you don't have SSH access you can also grab it through FTP. My best guess is that your web host upgraded to PHP 8.1 or 8.2 and that you are running a much older version of ProcessWire. PHP 8.1/8.2 upgrades can sometimes break old versions and old sites. I can tell that you are running a pretty old version because it is missing the JS files for AdminThemeUikit, which was added more than 6 years ago. The good news is that the front-end of your site seems to be working. A major PHP upgrade on an old site would be more likely to break both the front and back end. Most likely an upgrade to a more recent PW version (like 3.0.210) would resolve the issue. Though it's also possible that the issue is coming from a 3rd party module that's installed, or something else, and that's what the errors.txt log would tell us.

Log in to your server via SSH and navigate to the site/assets/logs/ directory and look at the end of the errors.txt and exceptions.txt files. You should see information there about what could be happening on the server.