psy

Thank you for investigating @wbmnfktr 🙂 I had tried re-saving in different formats without success. It was only when I made one image bigger and it uploaded that I realised the file size was triggering the issue. @netcarver's suggestion of a ModSecurity issue with the web host was 100% and nothing to do with PW.

@netcarver Using PW 3.0.210 and nothing special in .htaccess other than ProCache directives, https only and <IfModule mod_mime.c> AddType image/webp .webp </IfModule> Strange that it only happens on small images. No problem at all on larger image file sizes. I changed the default image quality from 90% to 100% in case that made the file invalid but no difference. All PHP image processing modules seem OK. As for ModSecurity, yes it's on a shared host that has ModSecurity. That's been a nightmare on many occasions for other things. I have the web host on speed dial. Good call to check that one.

There are many forum topics and suggested solutions to problems uploading images in PW admin. I've read all I can find but none address the problem I'm experiencing. It's consistent and repeatable. I have an image field in my template (duh!) and I can successfully upload any images with an approved image file type that has a file size over 10kb. Any images (png or jpg in this case) with file size of <10kb fail with the following error: I have even taken one of the small images, given it a bigger canvas in Photoshop, converted to PNG/JPG and successfully uploaded it. I could also hack it and make all my images bigger then use the api/image variations to reduce them on frontend output but that's not the point and a lot of unnecessary effort and wasted disk storage. Suggestions on how to fix the underlying problem most welcome. TIA Solved Thanks @netcarver for suggesting it may be a ModSecurity issue. Nailed it. Web host whitelisted my IP from their (obscure) rule and the uploads worked perfectly 🙂

Nothing in this post since 2020 then a client got this today... Similar to above comments, I'm convinced it's just a nasty extortion threat and should be ignored. Form is in Formbuilder iframe and full of all ProcessWire & FB sanity checks. Site is functional and no obvious hacks. Told client that if it was real, they should feel privileged to be the first ever recognised PW hack victim. Also feeling a bit chuffed that this little, local Aussie site was found on the global hacker network.

OMG solved! 🤞 When I was digging into wire/core/WireHTTP I think the file got corrupted, maybe during an upload to my dev server (yes, still staging) Replaced it with a new copy and site is working again @netcarver truly appreciate your help and patience.

@netcarver I tried that on the frontend and it worked but now every time it has to wire a new page, or in admin perform some http task, it fails. My error logs are filling up fast

@ryan any ideas? Nothing that involves https works, eg admin 'Save' functions, frontend redirects.

Have uninstalled: TracyDebugger LoginRegisterPro (not used anyway) Very few other modules in use and still the error, admin & fe 😞

@netcarver Thanks for your input. Site doesn't use any hooks Searched Google, forum but not repo. Will do so now. There was an old post that was vaguely similar but didn't have an answer. See link below Turning off the error may hide the error message but, you're right, it will totally obscute the real issue.

I've been working on a a new site for weeks. $session did it's normal, wonderful stuff until today when it didn't - boom!!! $session now occasionally holds vars from one page to another. The killer is $session->location or $session->redirect. Before redirecting, the page crashes with: I went back to basics with the default theme: Using ProcessWire 3.0.212 dev PHP v8.1 (tried 7.4 & 8.0 too) Error occurs in Chrome & Firefox Editing modules, eg turning TracyDebugger on/off also triggers the problem Error occurs in front and back end. Often, clicking on a link to a different page clears the error but $session still screwy. Have no idea why PW suddenly stopped correctly wiring $session. Is this a bug? Am I doing something wrong? Help & ideas on how to fix gratefully accepted. Solved: Upload a fresh copy of WireHTTP to my server. Previous version may have been corrupted in transit.

Solved! Instead of re-using the same $http object I'd used for multiple previous GET requests, I created a new one, ie $postHttp. Postman had "no-cache" as a header.. Thanks again for the tip @netcarver

Thanks for the tips netcarver. Will compare the headers 🙂 I had "Content-Type" then looked into WireHTTP.php where it's listed everywhere in lowercase, eg: <?php public function post($url, $data = array(), array $options = array()) { if(!isset($this->headers['content-type'])) $this->setHeader('content-type', 'application/x-www-form-urlencoded; charset=utf-8'); return $this->send($url, $data, 'POST', $options); }

I'm trying to post json data to an endpoint with: <?php $http = new WireHttp(); $http->setHeaders([ 'X-Auth-Token' => 'XXXXXX', 'Accept'=> 'application/json', 'content-type' => 'application/json' ]); $myEndPoint = "https://myendpoint.com/api"; $params = [ 'parent_id' => 0, 'name' => "My Name", 'is_visible' => false ]; $paramsJSON = json_encode($params); $http->setData($paramsJSON); $response = $http->post($myEndPoint); if($http->getError()) { echo "HTTP request failed: " . $http->getError(); $this->die; } //..... } It fails every time no matter how I present the $params with: HTTP request failed: 400 Bad Request:. It works successfully when I post through Postman app. The endpoint & headers are correct and used successfully elsewhere with $http->get Help to fix much appreciated.

Have you set up your local URL's on the Home page 'Settings' tab, url fields ? It's usual to use the ISO Language (not Country) codes, eg 'de' for 'German'.

An alternative approach using native PW is to make your titles the shorter version and use a field, eg 'headline' for the lengthy version. In your templates use: <h1><?=$page->get('headline|title')?></h1> This will output the headline if it's available and if not, the title. You can then also use the shorter version in front end menus, etc. In the admin page list, it will default to the shorter 'title' field. If you need the front end page URL to be the longer version for SEO, you could add a hook in templates/ready.php, eg (untested): <?php $wire->addHookBefore('Pages::saved', function(HookEvent $event) { $page = $event->arguments(0); // ensure it meets the requirements if (empty($page->headline) || $page->template !== 'your-template-name') return; // regenerate the page url from the headline field $page->url = wire('sanitizer')->pageName('headline'); // Populate back arguments $event->arguments(0, $page); }); And another way.... In your template, Advanced tab, under "List of fields to display in the Admin Page List", simply enter {name-of-your-shorter-field}