Skip Navigation

[Resolved] Posts sometimes won't save

This support ticket is created 5 years, 10 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

Tagged: 

This topic contains 7 replies, has 2 voices.

Last updated by Beda 5 years, 8 months ago.

Assisted by: Beda.

Author
Posts
#1214848

Hi, I noticed a very strange problem that seems to be related to repeating field groups.

I can get into a certain condition where the Save Draft, Preview, and Publish buttons will not work. If I remove all the repeating field group records, it will start working again.

I noticed that when I went to remove some repeating field records, it gave me a popup error about a "System Error" (hidden link)

My best guess is that some repeating field rows are corrupt and are preventing the post from saving. There is no JS error, and this has happened only twice in about 200 posts.

Have you guys heard about this one?

~Ben

#1214895

Never heard about this, but what it sounds like could be that you have many (many!) RFG's (Repeatable Field Groups) on those posts. Or in those RFG's, many other fields?
Or, does the post you save feature a View, that has as well many(!) posts to list?

The message you mention is from Toolset Types.
We do some checks in the code and if things fail we produce it.
Basically, the code checks if there is some post to delete and if not, then that message is shown.

You have to understand that an RFG is technically a post.
So, if the code tries to delete an RFG it tries in fact to delete a post, and in this case, cannot find it.
This can mean that the RFG is already deleted, or the code gets an ID of a post that does not exist.
This could happen due to another language but English being the default on your site (There are some issues with that)
One last cause can be if you manipulate the DOM with some custom code while deleting that RFG.

From the description you give me I think it is rather due to internet disconnection issues.
Given this is an AJAX call, it might be that when the call starts, you immediately after for some cause fall of connection even for a second, get an empty response and hence the error.

If you have a reliable way to replicate this please let me know (even it requires few trial and fails)

#1214921

Hi Ben,

It's happening on a few more posts now. Same symptom, frozen Draft/Preview/Publish buttons.

I guess I should mention I've been a professional WordPress plugin programmer since 1.x and I do have an understanding of Toolset's internals 🙂 I think you might be right about Internet connection issues. I have several people working (each on separate posts) in the system at once, and there are intermittent connectivity issues for sure.

Here's an idea if you guys are interested - I think we have the tiger by the tail on what looks like a very elusive bug in Toolset. My site is not yet live, so if one of your engineers would like to connect via SFTP, the WordPress admin, and phpMyAdmin to do some troubleshooting, I think you have a pretty good chance at figuring out what is going wrong.

My site is not plugin-heavy in the first place, but even when disabling all plugins the problem still persists. I think this is likely a case of dirty or corrupted data somehow making it into Toolset junction records.

~Ben

#1214922

Shoot, I think I see what it is. If I have nested repeating field groups with required fields, the save button is disabled. But there is no visual queue to indicate why saving is prevented.

hidden link

hidden link

#1214923

Sorry one last note. When the nested repeater group field is open, pressing Publish will jump down to the problem. When the group is closed, Publish just appears frozen.

I think that's it, that's the bug.

#1216819

The reason hence must be "I have several people working (each on separate posts) in the system at once,"

See, if you have many people editing that post, and one removes the RFG "xy", now you edit it shortly after or simultaneously without refreshing the data, the removed RFG still figures for you as existing.
Trying to remove it though will refresh the data and fail to remove it, resulting in the error.

That, at least about the error you mention here:
https://toolset.com/forums/topic/posts-sometimes-wont-save/#post-1214848
(I noticed that when I went to remove some repeating field records, it gave me a popup error about a "System Error" )

The issue here (https://toolset.com/forums/topic/posts-sometimes-wont-save/#post-1214922) is the issue about "I can get into a certain condition where the Save Draft, Preview, and Publish buttons will not work"

We have 2 issues here, and the first for me is clear, it's due to someone else removing the RFG and the other party trying straight after to remove it.

The second issue (I can get into a certain condition where the Save Draft, Preview, and Publish buttons will not work) is as you stated due to the required fields, which give you no feedback if collapsed. We have had similar problems with "normal" fields in past and improved that, it seems, the Developers missed the collapsed case.
I can replicate this easily and escalated this as a usability issue. We should warn about the requirement (or any failure, that is) even if the group is collapsed. The error is there, BTW (see string within the group), it's just not scrolling to the field and does not expand it, instead, clicking save just "does nothing".
If we look at "simple fields groups" we see that it does correctly interrupt saving, scroll to the field and even expand, if the group is collapsed.

Thank you for the information you gave, it helped a lot

#1232082

This will be fixed in Types 3.3 which is planned to be the next release.

#1240826

Types 3.3 is now released and will fix this problem.

Thank you for your continued patience, and if you stumble over any issue please do not hesitate to open a new ticket.