Failure to save change with latest version 2.4.3

Hi!

Thanks for your post and sorry for the trouble!

Can you clarify what and where exactly you saw this error message?

There was no change related to table saving between TablePress 2.4.2 and 2.4.3, so it would be strange that reverting helped here…

Also, note that TablePress 2.4.3 fixes a security issue in previous versions, so we should try getting that update to work for you.

Regards,
Tobias

Hi Tobias. First, let me tell you that I love your TablePress. I’m a librarian and my site combines blogging functions and archival on history, so I archive documented lists of links of videos and documents available on my site or on the web. TablePress was exactly the ticket when I developed my site almost three years ago now.

The error message showed up on the TablePress editing page of a table after clicking Save Changes.

I never had any problem using only basic functions of the free version. Yesterday morning I added an entry in a table and was able to save it as usual with no problem. Later in the day, I copied a snippet of text from a cell to another place on my site, and then added journaling info in the proper column in editing, which column is hidden so as not to display that column where the table can be seen on the site. It is when I tried to save the thus modified table that I received the 403 error message.

This 403 error message has happened a couple of times before with other extensions. After much searching on my part, deleting caches on my browser and on the server (most of my problems editing my site usually come from there) I asked support and the simple solution from their part was to neutralize a “modsecurity” rule (cPanel server). I lease a shared server, and I guess they probably use standard security rules across all the sites on a shared server. They had been upgrading security for many months, so I wasn’t surprised. My first thought this time around was that maybe they’d done some upgrade on the server and that reverted security rules to standard. Or maybe it was a php version upgrade or whatever. How would I know?

The way they go about it once I’ve signalled my problem is they do something and then ask me “Can you try now?” The previous times with “neutralizing a modsecurity rule”, it worked at the first pass. This time we tried three times to no avail. So I had the idea to roll back to the previous version of TablePress (using the Rollback WP extension) and that did it.

Hope this helps.

Best regards.

Guy

Hi,

Thanks for those details! An message like “403 Forbidden” as part of the error message when saving does indeed point to things like “mod_security” being configured too strictly. This has been the case in the past, whenever I heard about this error message from other users.

I would therefore argue that this is the case here as well. Now, it’s however surprising that the error is not happening with TablePress 2.4.2 according to your findings. I just don’t understand how that is possible — as nothing at all that is related to saving changes was modified between TablePress 2.4.2 and TablePress 2.4.3…

I would therefore suggest that you try updating to TablePress 2.4.3 again, to see if that really does trigger the problem again.

Best wishes,
Tobias

I uptated to version 2.4.3 and created a new row in the table with some content. Upon saving I got a 404 error code. I added some more content and then it saved successfuly !

That to me seems a caching thing. I know WP can lie kind of dormant if requests are not made to it. So getting a good result on the second try makes sense, to me at least. My site can remain unvisited for hours. I get 4 to 6 visits a day.

So getting a successful save yesterday with a rollback might be “coincidental”. Support doesn’t actually walks me through what they’re doing, especially this being about server security.

I erased the test row and saved successfuly again. I thus consider the issue resolved.

• This reply was modified 1 month, 1 week ago by guy51. Reason: Added info on site dormancy

Hi,

The 404 could actually point in the same direction: Empty rows in a table can look “weird” to security systems (because they then see an “empty array encoded in JSON format”).

But anyways: Yes, what matters is that everything works again and that you can save your tables ??

Best wishes,
Tobias

The test row wasn’t empty, there was content in the first cell, and then the second also. Just so you know.

Thank you for your prompt response and best whishes.

Guy

Hi,

ok, but several empty cells can still look “weird” in the internal data format. This is very nuanced, unfortunately, which sometimes makes this so tricky to deal with, when looking at security software. :-/

Best wishes,
Tobias