Edits made in Kirby panel not saving/persisting

[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.