Edits made in Kirby panel not saving/persisting

Kirby 3 Questions 🤔
1

Hi there,

I just launched my first Kirby 3-based website, and everything’s been working really great up till now. Only thing is, soon as I migrated the site to our live host, which is running PHP 7.3 with all the required extensions, saving any edits made in the panel don’t persist. The UI feedback suggests that the save was successful, but upon viewing the site on the front-end or reloading the same edit screen in Kirby panel, none of the edits have been saved.

It worked fine on my local development environment and on another host where we have a staging environment.

If I edit the files under /content directly via FTP, that works fine – the files save fine and I can see the changes both on the frontend and in Kirby panel.

Here are the things I’ve tried to do to solve it:

  • I recursively gave all files under /content the permissions rwxrwxrwx (I know that’s not a secure set of permissions, but I just wanted to make sure it wasn’t a permissions issue).
  • I opened Chrome’s dev inspector to see if the PATCH request failed. There were no failed requests at all, and the POST and PATCH requests all returned successful 200 responses.
  • I checked for any PHP errors and haven’t found any.
  • I studied the output of phpinfo() to ensure all the required PHP extensions were enabled, and as far as I can tell that looks to be the case.

Here is a link to the phpinfo() output, if that’s of any help.

Any thoughts on what’s going on?

In a pinch we can still edit content via FTP, but it’s far from ideal. A lot of time was put into building the Kirby panel UI for this website with the hopes that the client would be able to make changes on their own.

2

Maybe an issue with server-side caching?

3

I’ll check with the host if that’s something that’s enabled, but I’m a bit skeptical, since after I’ve saved the changes in Kirby panel, no changes to the corresponding .txt file in FTP have occurred.

In addition, if I edit the .txt file under /content directly, the change is seen immediately on a browser refresh. Wouldn’t that also suggest there’s probably no server-side caching?

4

Can you successfully upload files and create new pages?

If you remove your accounts on the remote server and allow installing the Panel on the remote, does that work without errors? https://getkirby.com/docs/reference/system/options/panel#allow-the-panel-to-be-installed-on-a-remote-server

5

Hi @texnixe,

I’ve done some more tests and discovered that some things do work successfully:

  • creating a new draft page
  • uploading an image to a page
  • creating a new admin user

But no actions that involve editing existing content seem to work – content just reverts back to what it was before the edit once the page is reloaded.

The panel is already allowed on the remote using the setting 'panel.install' => true … isn’t that essential for being able to access the panel at all?

6

Check if PATCH, PUT and DELETE requests are enabled on the server.

You should actually see an error message in your browser console…

7

So I did take care to mention this in my initial message:

There are no failed AJAX requests logged whatsoever. They all return valid HTTP 200 responses.

There are no PUT or DELETE requests issued in the process of editing a page. The only relevant one seems to be PATCH.

If it’s helpful, here’s an example of the PATCH request and response from Chrome dev inspector, on a simple page where I’m trying to change the hero_heading to "test":

Request

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,it;q=0.8,fr;q=0.7
Connection: keep-alive
Content-Length: 168
content-type: application/json
Cookie: kirby_session=ef33cc538de3864b6ce6bb857695610e04487de1%2B1587830338.021f8027f392b59e29c0.aad9c59022a2345dfe5dd6370c90153c6db87126e2ed3e6b0849eae05fdb9b56
dnt: 1
Host: www.craftcontractingltd.com
Origin: https://www.craftcontractingltd.com
Referer: https://www.craftcontractingltd.com/panel/pages/test
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36
x-csrf: ad7a436c8ab60530f957d2164dbd7027c954845653c9c871c7b249b5778e1e55
x-requested-with: xmlhttprequest

{"hero_heading":"test","hero_text":"","hero_button":{"type":"url","value":null},"hero_image":[],"hero_caption":"","hero_style":"","blocks":[],"heading":"","caption":""}

Response

HTTP/1.1 200 OK
Date: Mon, 13 Apr 2020 15:23:04 GMT
Content-Type: application/json; charset=UTF-8
Content-Length: 299
Connection: keep-alive
Server: Apache/2
X-Powered-By: PHP/7.3.2
Vary: Accept-Encoding
Content-Encoding: gzip
Age: 0

{"code":200,"data":{"content":{"hero_heading":"","hero_text":"","hero_button":{"type":"url","value":null},"hero_image":[],"hero_caption":"","hero_style":"","blocks":[],"heading":"","caption":"","title":"Test"},"id":"test","num":null,"options":{"changeSlug":true,"changeStatus":true,"changeTemplate":false,"changeTitle":true,"create":true,"delete":true,"duplicate":true,"read":true,"preview":true,"sort":false,"update":true},"parent":null,"slug":"test","status":"draft","template":"about","title":"Test","url":"https:\/\/www.craftcontractingltd.com\/test"},"status":"ok","type":"model"}

As you can see, hero_heading is not getting updated between the request and response.

Anything else I can do to help solve this, please let me know.

8

Ah, sorry, I forgot to completely read it all again…

9

No, this setting should actually be disabled anyway. It is only necessary to enable this if you want to install the Panel on the remote, i.e. before a first user was created.

1 Like
10

Hi @texnixe,

I don’t see any suggestions for what to try next in your last couple replies, so I’m a bit unsure what to do. Has my issue been escalated to your dev team? I’m a PHP developer so if it helps, I guess I could try inserting debug statements throughout the Kirby source code to try and trace what’s happening? I just don’t want to waste too much time if you have a better idea of what I should do to troubleshoot this.

My client is getting antsy to be able to make changes on their own…

Thank you!

11

Hm, I have no idea what is the issue here but I’d assume this is some server-side configuration issue.

Maybe @lukasbestle has another idea?

Just out of interest: Have you tried to install a fresh Starterkit on the remote and verified that has the same issue?

12

I once had this kind of issue and it was caused by incorrect or duplicate language versions of the text files.

13

I haven’t seen this before either unfortunately. Here are two things you can verify/try:

  • Install a fresh Starterkit on the same server and check if that functions properly.
  • If yes, verify that the content .txt files and the directory structure look correct. I.e. as @Fleix wrote, if there are any duplicate files or if any files in your content or site directories contain uppercase letters (which may cause issues in filesystems that don’t ignore the case).
14

Hi @lukasbestle and @texnixe,

I’ve tried installing a fresh Starterkit on the remote, enabled panel.install to be able to create my first account and log in, then tried editing the sample content of the About page. I saved the page, it didn’t generate an error on save (as usual), but once again when reloading the page, it had reverted back to its original content. Same behaviour as always.

There are no upper/lowercase-different or language-specific .txt files anywhere underneath the content folder.

Do I have to start doing some research into a new web host for the client? This is such a drag…

Thanks for your help…
Paul

15

And the content is definitely not saved in the content file?

Which hosting provider are you on? Have you tried to contact them about the issue?

16

@texnixe, yes, the content is definitely not saved in the content file. I’ve confirmed that multiple times now. Editing the content files directly via FTP works perfectly, however.

We are hosted on Netfirms. I’ve just begun a support chat with them to find out if they can get to the bottom of this.

17

Quick update: The support agent is getting stuck on the fact that you refer to GD support in the Kirby requirements as “gdlib extension”, and he thinks “gdlib” is something separate from the GD extension. And he says the Netfirms PHP build doesn’t include the “gdlib” extension. But my phpinfo test confirms that “–with-gd” was enabled during configure, and lower down you see that “GD Support” is “enabled”. So I’m convinced that “gdlib” (as you word it on your requirements page) is supported by the version of PHP installed there.

I’m trying to convince him that image processing is not the issue here, and let’s forget about GD and focus on what’s the real issue here, which is the saving of edits. Am I on the right track in persuading him that it probably does not have to do with GD?

Update #2: He realized on his own that “gdlib” means the “GD extension” and agreed with me that it is indeed supported. It took him an extra 20 minutes to arrive at this. @texnixe I have a request to make life easier for tech support agents in the future: 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? (If you Google “gdlib php extension” you’ll see that none of the top 10 search results refer to the GD extension as “gdlib”.) This will help the less savvy tech support agents confirm that servers are indeed Kirby-compatible.

18

While this thing is indeed GD Library (short gdlib), we can of course add “GD extension” as additional information :upside_down_face:

19

Thanks, just a thought. I read “gdlib” as “GD library” myself, but of course I’m a developer and that’s quite intuitive to me. Tech support agents of web hosts aren’t necessarily quite as savvy.

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?). He’s suggesting I upgrade to a VPS.

@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? Seems the main benefit of PATCH over PUT is just reduced bandwidth, and backup using PUT would be a perfectly fine substitute. Most REST APIs don’t even seem to bother implementing PATCH (perhaps for good reason – spotty support across hosts).

20

@texnixe I’m basically begging the host to enable PATCH on their shared VPS environment, and they said they sadly cannot. So they’ll be losing a customer, and now I have to spend an extra several hours migrating the site to a new host, email accounts and everything. What a downright drag.