Leaderboard

The spec for http 1.1 (rfc 7231) only specifies the behaviour of the location header for http 201 and 3xx. I'm not sure it's a good idea to depend on undocumented behaviour of not setting a proper 3xx status code. Especially as this seems to happen even when explicitly calling: $session->redirect($url, 302); This not setting a http status code is waiting to cause people trouble. One isn't always dealing with browsers, which are usually quite forgiving.

@ryan Now I'm worried that you have some kind of psychic x-men power or something! Seriously though, that's great news and shows I should actually read the code for the new version of the function before I type up a reply here.

@psy - I am not certain at this stage, but see this comment and the two before it: https://processwire.com/talk/topic/12208-tracy-debugger/page/76/?tab=comments#comment-178165 Seems like it wasn't due to Tracy in that case - any chance it might actually be something else for you too?

This week ProcessWire version 3.0.166 is released on the dev branch. In this post we’ll cover all that’s new relative to the previous version, 3.0.165. Plus we’ll check out the latest new versions of ProCache and FormBuilder— https://processwire.com/blog/posts/pw-3.0.166/

@netcarver You'll be glad to know that's exactly what changed with the redirect method in 3.0.166— The optional 2nd argument is now an http status code, enabling you to send any redirect status that you want, so long as it's somewhere in between 300 and 399. So if you wanted to send a 303 "see other" redirect, then you would do it like this: $session->redirect('http://domain.com/path', 303); The method of course also still accepts true or false to mean 301 and 302, and the default is still 301. The new location() method sends only a "Location: url" header without an http status code, which browsers interpret as a temporary redirect.

@ryan looks like a nice set of improvements, thank you. With regard to the new location() method, I can understand the move away from the second parameter in the existing redirect() call as it is a little confusing. Although this isn't in the spirit of the move to simplify, if I wanted to do a 303 redirect would I have to manually set the location header using sendHeader() and then return a 303 via sendStatusHeader()? I wonder if the existing redirect() call be changed to accept either the existing bool or an int for the second parameter? In the case of an int, maybe one of the 300 (301/302/303/307/308) codes could explicitly be passed and used as the return code. That would certainly make its use more explicit and more intuitive than the existing none/true/false as the second parameter. Regardless, excellent work as usual.

@gebeer – Thanks ? This hasn't been addressed in v1, as the plan was to carry the behaviour into v2 (sorry it's taken so long…) by way of the separate module. I picked up the project again recently and was giving it some thought. I might just include the 404 logger in JL v2, but am still 50/50 on it. @teppo @adrian – You know, I should have truncated that alongside truncation of the request_uri. Going to see if I can squeeze this in over the weekend while I work on v2’s frontend.

If you don't need the PW API to process the form, you can place your script in root. action="<?=$config->paths->root . 'myscript.php'?>" Although, as already mentioned, I'd suggest to create a PW page + dedicated template for such stuff. Together with URL segments, you can place all your form processing logic in one single file (or even include() each sep. form processing logic, in case there's many of them). Well, actually URL segments aren't really needed, you can just as well include a hidden field in your form, or add a ?form=support to your action URL. Many ways to skin a cat ?

It doesn't have to be, but it's certainly best practice. You can point your form directly to a PHP script, but you will have to bootstrap ProcessWire manually if you want to use the API. The PHP script also can't be in the template directory, as direct access to that is blocked by ProcessWire for security reasons – see my answer here. How best to add custom logic to your forms depends on how your form is built: FormBuilder? Use a hook to adjust how it processes the form, Custom form? You can put your logic in the same page template where you build your form. As zoeck mentioned, use the $input API to check if the form has been submitted and handle the inputs there.