adrian

Glad it's helping @Robin S

@Robin S — TracyDebugger 5.1.10 adds a Run in CLI checkbox to the Console for long scripts. It works the same way as AdminActions' CLI mode: bd() dumps are shown with the result, and Cancel and Stream results still work.

Hi @Robin S — thanks for the details. AdminActions 1.1.0 and TracyDebugger 5.1.9 should take care of all three things. The 2-minute limit: there's a new Execution mode setting in the AdminActions module config. Set it to CLI and each action is started in its own PHP CLI process, so LiteSpeed's 120s limit doesn't apply. It only needs proc_open(), so you don't need to enable exec(). The browser shows "Running in background…" and displays the result when it's done, and your actions don't need any changes. The PHP CLI binary is detected automatically. If detection picks the wrong one, set PHP CLI path. You can also set it per action with protected $executionMode = 'cli';. Tracy dumps: yes, they still work in CLI mode. bd() / bdb() dumps are shown with the action's result (under "Tracy bar dumps") instead of in the bar, and d() / db() work as usual. That part needs the new TracyDebugger 5.1.9. The one thing CLI mode can't do is keep changes an action makes to $session, because there's no browser session in a CLI process. There's also a batching option if you'd rather stay in the browser: check $this->timeUp() in your loop and return $this->continueWith(['i' => $i]); and the module runs the next batch in a fresh request automatically. That's your session workaround, built in. Details are in the README. The db() error: db() is actually Tracy's "dump big" shortcut, so it ran fine. But it printed its output into the background-run response, which broke the result. That's why you got a meaningless error and nothing in the logs. Anything an action prints (echo, d(), db()) is now shown with the result. Real exceptions and PHP errors, like an undefined function, are now shown with the file and line, and logged to both the PW exceptions log and Tracy's log. I'll look at a CLI option for the Tracy Console's long-running scripts next, since it has the same problem. Let me know how it goes on that host!

Hey @Robin S - thanks for trying that out. Does Litespeed make exec() or proc_open() available? If so I might be able to push the action to run via CLI and avoid the time limit. PS - can I assume you have the same issues with Tracy console's fairly recent background processing as well?

Hey @interrobang - looks cool. I am curious, could you provide some details about the pros and cons of this compared with https://processwire.com/modules/mystique/ and https://processwire.com/blog/posts/custom-fields-module/ At the moment, I am not sure if I would know which is the right solution for a particular setup. Thanks!

@ryan - I think this is a real problem. Part of the problem is that "dev" is not actually part of the version number from $config->version. Imagine a 3rd party module that says it requires 3.0.260 because of a feature that was added in 3.0.260 dev. It will install in 3.0.260 master, but won't have what it needs to run. This could result in fatal errors. Another possibility is that someone could actually end up going backwards when "upgrading" if they are coming from a dev version that has features that the new master doesn't have. It will also complicate bug reports. I think backports should add a fourth part to the version number, eg, instead of master 3.0.260, you'd version it 3.0.255.1 - so it's a new version of the current master. Basically, it's 3.0.255 plus some fixes.

Thanks for all the amazing fixes Ryan! I am curious though about the master version numbers - we've obviously already had a 3.0.260 (https://github.com/processwire/processwire/commit/ddd4ada40197cc45b1fd94a33dd2feea74b9562e) so isn't that potentially problematic that two PW installs with the same version number are completely different? Maybe there are limited practical issues with this, but I feel like it would be great to come up with a better solution moving forward, especially if backporting fixes to master becomes more commonplace.

Thanks @Robin S, glad the session fix is working. About the 120-second limit: a long action already keeps running after the browser connection drops (the module calls `ignore_user_abort(true)`). The browser then switches to polling for the result. At the moment, though, it only does that when the request fails with no response or with a 502 or 504. A 503 is treated as a real error, so you get the error message even if PHP is still working away on the server. Could you try a quick change in `ProcessAdminActions.js` at line 188? Change: if(xhr.status === 502 || xhr.status === 504) { to: if(xhr.status === 502 || xhr.status === 503 || xhr.status === 504 || xhr.status === 524) { Clear your browser cache, then run a long action. If the host only closes the connection and leaves PHP running, the status should switch to "Running in background…" after the 503 and show the result once the action finishes. If it just spins and never finishes, the host is killing the PHP process too, not only the connection. Is that host running LiteSpeed? 120 seconds is LiteSpeed's default connection timeout. If it is, adding this near the top of your `.htaccess` (after `RewriteEngine On`) should tell it not to abort or time out PHP: RewriteRule .* - [E=noabort:1,E=noconntimeout:1] Let me know how it goes. If the JS change works, I'll add it to the next version.

Hey @Robin S - I hate what I have turned into 😁, but it should be fixed now - here is Claude's explanation: Actions now run in the background via AJAX, so a long-running action can't hit a proxy or browser timeout. To stop the polling requests from being blocked by PHP's session lock, the module closed the session before calling executeAction(). Once the session is closed, PHP doesn't save anything else written to it. That's why you could read colour back straight away but it was gone on the next request. In 1.0.9 the module takes a snapshot of the session before closing it. After the action finishes, it reopens the session and writes back only what the action added, changed or removed. Anything the polling requests changed in the meantime is left alone. This also works when the action ends with a file download. Your TestSession action should now work as you expected. Let me know if it doesn't.

PW runs just fine with PHP 8.5. I honestly can't understand why everyone hasn't been running 8.5 since its release (or very shortly after). If you're on shared/managed hosting and they don't support new versions in a timely manner, find a new host, or take the time to learn how to manage things yourself - even if you have no experience, it's a no brainer now with AI agents to guide you step by step (or even do it for you). I run 8.5 everywhere and had all my servers patched within minutes of the release this morning. 8.6 is due next month and if you skip versions it just gets harder and harder to update. And, again, AI agents can easily scan your code and find things that need updating and fix them in no time.

@theoretic - I absolutely love the idea of removing all those huge layers of cruft from the PW core, but I'll say what I have said whenever someone releases a new AdminTheme - it won't get used unless it's the core theme. But given the way you've built it so that it only loads legacy components as needed by other modules, perhaps it really could become the new core theme. I haven't tested it yet, but if it works flawlessly in that regard, I'd love to get behind it.

Try upgrading to the latest PW dev version - I think this was likely fixed there a long time ago.

Hi @rushy, The `0x0` in the variation name tells you what's happening: something is calling `$image->size()` (or `width()`/`height()`) with width and height that both evaluate to 0. That includes `''`, `null`, and unset variables. ImageSizer has always refused a 0x0 resize, which gives the "GD FAILED Resize … (0x0)" log entry. GD and the image itself are fine. If PHP couldn't read the JPG, ImageSizer would throw "not a recognized image" before it got to the resize step. The variation name also has no `-ms` suffix, so it isn't coming from `maxSize()`. I'd look at the template for `/qui-suis-je/` (page 1021), or any partial or module it uses, for the code that resizes images. Something there gives a width and height that come out as 0 for the newly added images. For example, it might read them from a field or setting that's empty for new images, or from a variable that isn't set. A quick way to find it: $wire->addHookBefore('Pageimage::size', function($e) { if(!(int) $e->arguments(0) && !(int) $e->arguments(1)) { $e->log->save('image-0x0', $e->object->basename . "\n" . (new \Exception())->getTraceAsString()); } }); Put that in /site/ready.php, load the page, then check /site/assets/logs/image-0x0.txt for the calling file and line. The "filesize(): stat failed" warning is a small core issue. With $config->debug on, the image-sizer log line calls filesize() on the variation even when it was never created. It only shows up because the resize failed, so once the 0x0 call is fixed it'll go away too. Core fix, for @ryan, in Pageimage::___size(): - "({$width}x{$height}) " . Debug::timer($timer) . " secs $originalSize => " . filesize($filenameFinal) . " bytes " . + "({$width}x{$height}) " . Debug::timer($timer) . " secs $originalSize => " . (is_file($filenameFinal) ? filesize($filenameFinal) : 0) . " bytes " .

Just an FYI that the latest version of TracyDebugger includes support for SQLite and Postgres in AdminNeo.

@Jonathan Lahijani - do you have any thoughts about dragging/dropping items when paginated? Do we assume it's not needed beyond a certain number of items that triggers pagination, or do we just allow ordering within the current page?