Skip Navigation

[Escalated to 2nd Tier] cred-delete-post acting weird on RFG views

This support ticket is created 3 years, 3 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
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)


If you have a view with RFGs and a [cred-delete-post action='trash' onsuccess='self']Delete this Walkaround[/cred-delete-post] shortcode in it to delete the RFG, then pressing the link will not trash, or delete, the RFG at all (in the backend).

It will do some cumbersome magic to make the RFG disappear from the front end though.

But that is not good. When you have 10k posts and each post has 40 RFG, then you start to wonder why some of your RFG show perfectly fine in the backend of the post, but never show up in your views.
You will debug this issue for some hours, and with a sudden holy intervention you will think that maybe, just maybe, it is because the RFGs where actually trashed by cred, but not trashed in reality (which is not possible anyway), and also no visual feedback of any sort is added to the back end respective RFG to let you know "hey, this RFG is actually kind of trashed, you should delete it for good)

Delete for good, because there is NO option or method at ALL to re-publish that RFG!
Even re-saving the RFG/Post with edits will not bring it back to the front end.
Of course, the backend will not hint you about this, all looks fine, just, why then the RFG is not showing in the front end? Ih, I almost went devilish, debugging this.

The solution is, for now, to NOT trash with CRED link but to DELETE. Then, at least, the RFG will be gone for good also in the backend and not drive anyone nuts

For the future, I suggest CRED does either not permit RFG TRASHING (Because it is not possible anyway), or, to fix this UX issue with some sort of backend feedback on the specific trashed RFGs, so admins know what is going on.

Appreciate it...


Hi Beda,

Thank you for contacting us and I'd be happy to assist.

I've performed some tests on my website with a view that shows the Repeating Field Group items and noticed that the "cred-delete-post" shortcode does nothing if only used with the "trash" action:

[cred-delete-post action='trash' onsuccess='self']Trash[/cred-delete-post]

Only when I also include the shortcode with the "delete" action, the trash link works:

[cred-delete-post action='delete' onsuccess='self']Delete[/cred-delete-post]

The relevant's post's status is changed in the database, it is no longer visible in the view on the front-end, but it stays available on the parent post's edit screen.

Just as you suggested, we have an internal ticket to improve this, so that the RFG items can't be trashed and are only deletable. I don't have a time estimate to share at the moment, but I've added your voice to the matter and appreciate you brought this forward.



I think you confused the 2 things.

I've performed some tests on my website with a view that shows the Repeating Field Group items and noticed that the "cred-delete-post" shortcode does nothing if only used with the "trash" action:

No, this is not what happens.
When you choose TRASH, then things disappear from the View, but they stay in the backend post edit screen, as if nothing would have happened, and nothin will bring these RFGs back to life again. This is exactly because likely a post status of "trashed" is set, but the RFG list in the backend is still listing those. Front end won't show them anymore.

Only when I also include the shortcode with the "delete" action, the trash link works:
The relevant's post's status is changed in the database, it is no longer visible in the view on the front-end, but it stays available on the parent post's edit screen.

No, this is not what happens when you choose DELETE.
This is actually exactly what happens when you choose TRASH, and is the actual problem I describe.
When choosing DELETE, as the word says, the RFG is actually properly deleted, as it should be, that part works fine.

I have an online demonstration of this for you if you need it that shows the precise happenings.

will properly remove the RFG, and also it will not appear anymore int the Post Edit Screen. Good!

Will remove the RFG from the View lists, but keep it in the Post Edit Screen without further visual feedback. Not Good!

Please enable private reply data if you need the example - however it should be simply happening on other installs as well, I cannot imagine that "nothing happens" when clearly, on the online site I saw this issue, "something happens" 🙂

Or, if it is just a mix up of the statements, just ignore 🙂


Thanks for writing back and I apologize that my message caused some confusion.

I only shared my observation that the trash link doesn't work for me, in absence of a delete link.

Or to say it differently, the behavior of the trash link and the delete link from an RFG view is the same as you observed, however, the trash link would only do 'something' if the view also has a delete link.

I hope this makes it more clear 🙂


The robot:
Dear Beda,

This is the support cleanup robot, making sure that nothing is left behind or forgotten. I see that you have an open support thread that’s been waiting for feedback for 3 days now.

cred-delete-post acting weird on RFG views
Can you visit this support thread and let us know if it’s resolved for you, or if you still need help?

I am moving to the next thread, but I’ll be back to this one in 3 days. If you don’t add a message, we’ll assume that the problem is resolved and close this thread.

Nope. This, and other problems are not resolved.
Acknowledging a problem doesn’t solve it neither.
And this is the main reason these problems are out there and will stay out there forever, because of a ticket is “solved” of course “no client asks for it”

Please keep this ticket open if you plan to fix it
If you plan to not fix this _it’s also fine_, but then please *inform* us - “dear client, we will not resolve this issue”.

Then We can communicate this downstream to our clients and they can take decisions where to spend their money.
Makes sense, right?

Everything else is “turning the problem under a carpet of nice phrases”
This may work with one time clients but it doesn’t work with people who literally put their hand in a fire for your product like us freelancers and developers who _recommend_ toolset and promote it.

Thank you very much for understanding this and considering it the next time when “resolving” an issue


Hi Beda,

I'm sorry it was a mistake on my part that I've set the incorrect status of this ticket in my last reply.

But in my defense, I was hoping for a reply from you about the difference in the test results. Nevertheless, you're right and I should've set the status to "escalated".

I'm doing that now and will keep you updated through this ticket about the issue at hand.



Hi Waqar - and sorry to reply again, I know it will re-open your ticket to a must-reply status.

About, we might see slightly different results - however I think we both know what the issue is:
- the trash link trashes indeed the RFG but since RFGs in the backend have nothing to reflect this status we never see any "effect" of it. This is the issue.
- delete link indeed deletes the RFG. This is fine.

As for my last reply, let me clarify that I did not mean you are making a mistake - I know you are doing an excellent job just like anyone else in Toolset.

I observe however this "lets close things" behaviour in other tickets and it really gets me.
I have no issues with "No, we won't fix it."
That is a statement and a decision, and with it, people can make their own decisions.

What I can not live with is stumbling over 3 years old tickets where someone promised "next release will include it, please close this ticket as fixed now" and the client then marks the ticket as "My issue is fixed".
Of course the issue never was fixed and never will be fixed, and when we now re-comment on the ticket we get a statement like "Developers have other priorities".
This within 3 years time to add a CRED Relationships Forms API (just to make an example of the latest such case).

And I want to avoid that this happens - at least to the tickets I open.
Lets be honest to each other and say when things won't get done, and do them when we say we do them.

I've worked with a bunch of other plugins the past year, and I must say, usually it takes a week to fix a bug for them.
It's not that they have no clients or are so little plugins or services, no - big players like WP Grid Builder, BlocsApp, SiteGround or else services.
They care about the problems found and either fix them asap (the fastest was less than 1 hour after report!), or they say "no, sorry, this is not within our plans, please feel free to not use our software, goodbye".
And that is when the reported issue is really more of a "could be/I wish for" report than an actual bug or error or UX issue.

Of course, I do neither want to enter in a discussion about why and how's of companies act differently, nor I do want to tell you how its done, or tell you guys that someone else is better, etc.
I just want to explain to you that it is not the standard to wait for 3 Years to then hear the exact opposed answer as to what was stated in the begin 3 years ago.

It is also not the standard that plugins prioritise new features over fixing broken things.

I can say that because meanwhile I've seen a few such services and plugins in action, both in features and support.
While most of those services are not as wast as Toolset is, at least (and sorry fort this "at least") the service/feature offered works almost perfectly fine, and if not, they get fixed.
This builds trust and avoids frustration. It also builds a name. People will say "This plugin is almost perfect and the Author fixes broken things as soon he can, if there really is a broken thing".

Imagine, in the entire time of using WP Grid Builder (which is basically something like Views) I opened 38 tickets, which is relatively a lot for such an easy to use Plugin.
One of them was a bug. One!
It got fixed in 48 minutes (literally).

The other issues where all wrongly assumed bugs or how-to's and I was doing it wrong or was not looking deep enough (not just by opinion but the author actually showed me how to do it right).
Moreover that guy is practically developing, supporting and marketing his product alone.
Imagine what happens when he starts to employ 50 persons that are like him.
What happens when he starts developing Forms, and other addons.

I am just saying that it is definitely possible to deliver quality services which may be a little more restrictive and do not try to cover the entire world's needs at once, but also don't fall apart in each and every single feature you touch - which is what happens with Toolset are often than not, no matter how small the issues are, many (most) of the Toolset features have some special-snowflake-quirk - yes there are millions of features - but honestly, what is it good for if you need to workaround in each of them to achieve the goal?

Just to make a few examples, like we discussed lately, Forms Fields holding inputs inside a label; HTML Comments not printed; Relationship Forms without an API; Views Maps disappearing if no results are found; Toolset Types Post Type order in menu not really working; Etc, etc etc.
Yes, all small, tiny issues that you can say "do not really stop you to work with the product" and that is true, but it is often something that kind of stops your entire show, and not because of a massive technical limitation but because of silly things, where it just seems that the most complicated, most impossible and hard way was chosen to do things, instead of choosing the simplest, perhaps less :fancy: but more stable option in implementation of features.

Let me not start with Blocks, with its jumping of blocks, block settings losing assignment, corrupted blocks after you left the site for 5 days and come back to edit it, incomplete data availability such as user and term meta, extremely complex and confusing GUI of Views, extreme resource hunger, totally unusable Conditional Block ,and much more.
Note that this is not just a hater-opinion, I actually would love to give Blocks all chances it deserves, and I am not alone with this opinion and experience (I follow social media and see many people with the same experiences of a complete headache when using Blocks). And what triggers me the most with these issues is that you don't need to develop some moon-landing-software to actually see those issues, it is enough to simply create a simple blog to see them - and yet in the videos I see for Blocks training all these quirks are not happening. Blocks are not jumping constantly, no "Please wait - loading" message when waiting for a View of 10 Posts to load in the editor, and so forth. One questions if the plugin used is maybe another software or the videos are not videos of a real world. And again, this is not just me saying it, it's just that most people will not spend 45 minutes in front of a screen to do nothing else but report an issue and perhaps few more to your forum. This might be because it actually costs money (for us) and if one reads the forum he/she'll know that it is likely pointless reporting something that is not literally crashing the world, because it ain't going to be fixed anytime soon anyway- if it ever gets the attention one thinks it deserves. This impression will then lead to the behaviour of "Let me workaround it somehow and wait, maybe they'll fix it one day".

Well, that said, and as others have said, Toolset is a great tool, and the team behind it is composed of great minds. This is not a trial or an attack, it is just the facts we developers and freelancers find ourselves in when working with Toolset and in more than one case it was the reason why clients moved entire websites away from Toolset towards other plugins and more often than not, custom code (which ain't that bad for me of course, it means more work).

Cheers, and please try to not misunderstand me. I'm not trying to correct you or whatever else it might appear. It is plain and simple fact sharing and showing you my point of view.



Hi Beda,

Thank you for speaking your heart out and sharing not only the thorough feedback back also the background of what led you to share it in the first place.

I'll make sure it reaches the concerns and for the handling of RFG deletion/trashing, I'll keep you updated through this ticket.