Edits made in Kirby panel not saving/persisting

[texnixe]

I feel you, it is annoying to have to put additional work into something like this.

On the other hand, we put the requirements there so that everybody can make sure in advance that the target server supports those requirements…

I don’t know why this decision was made but I’m sure there was a good reason for it.

[farmerpaul]

Hmm… tried a hack, replacing all of Kirby’s PATCH requests with PUT both in the PHP and in the JS. While this allowed Kirby to continue to work fine on my localhost, it didn’t solve the issue on Netfirms. Requests appeared to succeed as before, but changes weren’t saved, just the same way as with the PATCH requests. Presumably the host has also prohibited PUT requests – is that common?

[texnixe]

@farmerpaul

Presumably the host has also prohibited PUT requests – is that common?

The only real alternative to using PATCH would be sending POST requests.

While we have seen multiple issues with providers that had PATCH requests originally disabled, most were solved without users having to switch providers, because customer support either enabled those requests or it was possible via .htaccess settings.

[farmerpaul]

I’ve tried adjusting .htaccess in a couple different suggested ways, with no effect or it produced an error due to lack of Apache module support.

Replacing the PATCH requests with POST wouldn’t work because Kirby often already uses POST requests with different functionality, typically to add content as opposed to updating content. So it’s not exactly a practical substitute.

The host has escalated the issue now and I’m hoping they will see the logic in supporting PATCH requests.

[texnixe]

@farmerpaul

Replacing the PATCH requests with POST wouldn’t work because Kirby often already uses POST requests with different functionality

I didn’t mean to say you should try to do that, but it would have been the alternative for Kirby, because with everything else you would run into the same issues as with PATCH.

[lukasbestle]

@farmerpaul

Can you guys reword that “gdlib” requirement in the Kirby requirements section and refer to it instead as “GD extension”, which is how it is referred to by the majority of users, as well as on the phpinfo() output?

Done

@farmerpaul

So, the agent has finally determined that the server does not support PATCH requests after all, even though they return an HTTP 200 response (this might be good for you to know in future; I guess there’s a way to prohibit those requests in Apache while fooling you into thinking they’re still successful?).

OMG, that’s evil. How can they break the web in that way?

We are planning to build a self-check for this issue and it will hopefully also detect the HTTP 200 variant of this issue as the response body will likely be empty or an error message in your case (the actual request won’t be sent to the backend).

@farmerpaul

@texnixe I’m curious why Kirby requires PATCH support as an essential part of functioning, when the support for PATCH is so inconsistent across web hosts (necessitating an explicit note about it on the requirements page)? Shouldn’t there be a fallback using PUT?

PUT is idempotent and PATCH isn’t. Or phrased differently: A PUT request always leads to the same result, even if repeated. So a weird cache or reverse proxy might try to be clever with PUT and resend failed requests automatically. In some cases this will work, but in some cases it won’t. That would lead to another huge pile of weird bugs that are impossible to debug.

Also: Many providers that block PATCH also block PUT (and often even DELETE). So there would be no real point to switch over to PUT.

As @texnixe wrote, the only way would be to use the commonly supported POST. But that would make our API’s URL structure much more complex and sometimes it’s even not possible without weird hacks.

So I think the best thing we can do to mitigate this is the self-check to make it much easier to detect such issues early.