adrian

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?

Agree with @Jonathan Lahijani - pagination for Repeaters is something I really need as well.

In case anyone else is having issues logging into a site at the moment: https://github.com/ryancramerdesign/ProcessWireUpgrade/issues/38

Thanks for merging all this so quickly @ryan - I feel like folks might also be interested in this benchmark table: https://github.com/processwire/processwire/pull/372#issuecomment-5841901625

@ryan Regarding the forum's 403 mentioned earlier: It's not a permissions problem on the forum — the request never reaches the forum software. What's happening 403 server: awselb/2.0 /talk/discover/unread/ 403 server: awselb/2.0 /talk/discover/ 403 server: awselb/2.0 /talk/discover/15/ 403 server: awselb/2.0 /talk/index.php?/discover/unread/ 200 server: Apache/2.4.68 /talk/ ← app responds normally 200 server: Apache/2.4.68 /talk/search/ , /talk/online/ 404 server: Apache/2.4.68 /talk/discoverxyz/ ← app responds normally The 403 comes back with server: awselb/2.0 and a bare nginx/WAF-style error page (<h1>403 Forbidden</h1> plus MSIE padding comments) — that's an AWS load balancer / WAF rule, not Invision Community. If it were an IPS permissions denial you'd get an Apache response with the themed "You do not have permission" page. The rule is matching the literal /discover/ segment anywhere in the request line: /talk/discover/unread (no trailing slash), /talk/discover/15/, and even /talk/index.php?/discover/unread/ in the query string are all blocked, while /talk/discoverxyz/ sails through to the app and 404s. It's not user-agent based either — curl, Chrome and Googlebot UAs all get the same 403, and it's independent of login state since cookies never get evaluated. IPS's Discover/activity streams (/discover/unread/, /discover/<id>/) are the most database-expensive pages on an IPS board and a magnet for crawlers hammering every stream permutation. Blocking /discover/ at the edge is a standard load-shedding move. So this is almost certainly an intentional (or over-broad) WAF rule added by whoever runs processwire.com's infrastructure — the collateral damage being that logged-in members lose the "unread content" feature entirely.

Just wanted to drop by after finally having a use for this. Just a great solution @Robin S - thanks again!

Thanks for the updates @monollonom - I am curious though. I am using: $p = $event->arguments[0]; in a FieldtypeQRCode::getQRText hook and it still seems to be working fine. Am I not understanding what the changes are supposed to have broken?

Thanks - Kontor actually sounds fantastic - I've been offering my team to build a replacement for Hubspot (I really hate all these SaaS tools that people want to use), but they won't see the light :) I am still a bit confused about Folio vs Verk, because I feel like Verk can already be used for everyday projects and tasks, etc and I worry about users needing to use one tool for personal and another for one for page-linked tasks etc, but that might just be me.

Hey @maximus - thanks as always. Can you please explain how this would integrate with Verk, or does it supersede it?

Thanks @Robin S - should hopefully be fixed in the latest version.

Any chance you have a browser plugin like Grammarly installed?

@Saugatdai - if I have the module correct, you're probable better off posting your issue over here: https://processwire.com/talk/forum/62-padloper/