This support ticket is created 7 years, 4 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.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I have a Cred Post form on the frontend that contains radio options. This form creates a custom post type. All the values are submitted correctly, however if you choose to edit the custom post in the wp-admin area and have chosen to display all of the form fields for the CRED form in the backend, everything will show what the stored value is, except for radio selections.
So, it will show what was submitted for a text field and it will dsplay the dropdown with whatever value was submitted as well. But when it comes to the options for the radio buttons they are all blank. If you happen to choose a radio selection once again while editing the custom post type from the backend, it will then keep that value selected if you leave and come back to edit again.
It should already display it while in edit mode, from the initial frontend CRED post form.
That's not quite the response I was looking for. Is this a known or documented issue? As many times toolset as well as other plugins "break" other things in wordpress sites, such as the instance specifically with toolset that I documented here:
I prefer to digest and troubleshoot the known information first before creating changes that could render my site and application useless to many users.
I am not able to provide site access however, I have sent the debug info. The field is a default radio Post Field. I have disabled any additional plugins before which does not seem to be the cause of this issue. Please do not post site url.
From the debug information you have provided, I can see everything is good expect the older version of Toolset plugins. I suggest you to take a complete backup of your site and update the Toolset plugins to its official latest release. Or you can download it from your account: https://toolset.com/account/downloads/
Also please also make sure you are using latest version of your theme.
Once you will update the Toolset plugins then I will be able to further debug this issue.
Thanks, you managed to create a lot more work for me. I upgraded CRED. As anticipated Toolset once again breaks all my css styles with their recent CRED changes.
It seems that toolsets "further development" decided to now distinguish CRED user forms with :
css - "form#cred_user_form" vs the initial "form#cred_form"
Additionally, the suffix once again changed from 0 to 1 on another of my prexisting CRED forms.
Once again, breaking any css style formatting sitewide that target CRED user forms. This is particularly troublesome as my forms have interactive jquery tabs.
CRED forms are now fully bootstrap compatible and I remember an issue related to form-control-class, may be the one you are referring to is related as well. Can we please re-summarize the bug so I can report it?
Please if you can provide step by step details to reproduce the issue that would be great, Screenshots will also help. At moment it is bit confusing that how to reproduce this issue.
And if its not reproducible, can you please share your site WP-admin login info OR Duplicator package as the problem is with older forms and old CRED version? I have enabled private fields for your next reply.
So, aside from the very troublesome issue that I have highlighted. After a lot of time and aggravation fixing my site CRED form styles (due to Toolsets Changes) once again the update to CRED 1.9 does not address my original issue.
Re-read my initial question. If you have a working demo showing otherwise, I would like to see.
Scenario:
1. Front end user CRED creates a custom post type
2. One ore more of the post types fields are radio options.
3. Fill out the form radio options and submit the new CPT entry.
4. Edit the newly submitted custom post type in the backend of wp.
5. Where all the CRED's submitted post fields are displayed for this CPT, the chosen radio option that was selected on submit, is empty. (All radios are empty)
6. While in backend CPT edit mode, if you once again choose a radio option and update the post, the option is now saved correctly, whereby if you leave that editing mode and return to edit that CPT again, the radio option is still checked.
7. The expected result would be that after the Frontend CRED submit, the radio that was selected would be displayed in the backend as soon as you edit that post and not blank.
Lastly, for the third and final time, I would prefer that a higher tier of support assist with this issue so that it can be properly addressed.
Thanks for providing the steps, just for a basic check I have also gone ahead and performed these steps on latest version just to see if this problem may occur in latest version too but its good there. I am now forwarding this to our 2nd tier support to take a look into this as you have asked.
Our 2nd tier support said that we don’t do backwards debugging (like in your case its CRED v1.8.7, Types v2.2.9).
- We have also tried to reproduce by following the above mentioned steps but not able to reproduce same issue in latest versions -- radio options stay selected in both frontend and backend.
- So now we need to proceed either with your site access where problem appears (WP and FTP login info) OR Duplicator package (using plugin: https://wordpress.org/plugins/duplicator/) so we can debug further, whichever of these you can provide. Please also provide links to pages where the CRED form has this issue (form name, radio field name, etc). Your next answer will be private which means only you and I have access to it.
=== Please backup your database and website ===
✙ I would additionally need your permission to de-activate and re-activate Plugins and the Theme, and to change configurations on the site. This is also a reason the backup is really important.
Well, it's not backwards debugging since as I mentioned in the reply that I updated to the newest versions of both. The reply where I mentioned that new updates once again break CRED styles since toolset changed both the suffix numbering and the class for User submitted forms.
However, it does indicate that (in my site at least), it is not working in as early as those versions in which I was previously using before now updating.
- At moment we are referring to the 1st issue - radio options not being kept selected.
- The 2nd issue - forms element ID suffix changed after CRED update, its a separate one. I think both these are not related and are separate issues, I would suggest to please report this in a separate ticket and use this link for reference. You can just mention that this bug was fixed but its still appearing when we update to latest version of CRED (you may assign the new ticket directly to Beda as he is well aware of element ID suffix bug): https://toolset.com/forums/topic/cred-update-to-1-8-7-changes-the-forms-element-id-suffix/
Now back to the Radio option selection issue, our test sites are private but I have made a video screencast for it as you can see the working demo here: hidden link
1. After updating CRED and Types, does this radio selection is not being saved still?
2. What happens if you create a New CRED form with updated versions, radio selection still gets lost? If this is the case here then we would still need site access (WP and FTP login info).
Yes, thanks for the video. Actually, Luo used to provide access to demo site many times before. In any event I have reviewed your video. I see that it is working on your end so I went back to create simple radio options and test again in the same form.
Here is what I noticed. Yes, the form works correctly to display the value in the backend for the new radio options, however, these are simple values such as 1,2,3,4,5. I am displaying custom field content for this radio in the form of an image. So that, whatever the user selects as the radio option gets returned on the frontend as an image.
I have attached 2 screenshots of the post fields radio options with the custom content as image urls.
In this particular setup, as explained, the radio option is not displayed in the backend of wordpress once the form is submitted even though proper selected value is correctly saved to the database.
Please let me know if there is a way to correct this.
Ok thanks for the screenshots, I am able to setup this same as you have shown in the screenshot. The html should not be added in the "Custom field content". It should only be added in the “Value to show” area.
And select the 2nd option there “Show one of these values” to display the images. Please see the settings in the attached screenshot and do it like this for your radio field values.
It will work fine then and radio options will be kept selected then. With your current field content setup it cannot store the field values and I have also seen same problem at my end when I setup field like yours, this is because it's not expected to be changed as html.
