I'm having issues previewing and updating posts within a custom post type (properties) after updating types. When clicking on either the preview or update button, nothing happens. I do see a warning in the developer console...
Found 2 elements with non-unique id #wpc-save-post:
<input name="wpcf-save" id="wpcf-save-post" value="Save" class="button" type="submit" disabled="">
Sparingly it will work here and there if I immediate delete browser cache, and can preview the post if choosing "open in a new window." The odd thing is that if I click on either buttons immediately while the post is loading in the backend the buttons work, so it seems like perhaps a custom field or repeatable group field is prohibiting any action from taking place once the post fully loads in the backend...and then the buttons do not work.
I've disabled all plugins and also switched to 2020 theme and the problem still persists. Any help would be greatly appreciated.
Thanks!
Hi, I'm taking a closer look at this issue now. You may notice some plugins on the staging site deactivated temporarily while I do some debugging. I'll restore everything to its original state and give you an update shortly.
Thanks Christian, much appreciated. The buttons seem to be working on all other post types as well, so it looks like its concentrated to just the custom post type.
Okay the problem seems to be caused by the two required radio fields in the Industrial Properties Field Group. If I temporarily deactivate the Industrial Properties Field Group in Toolset > Custom Fields > Post Fields, then I am able to preview and update this Property post successfully: hidden link
If I reactivate the Industrial Properties Field Group and uncheck the "required" checkbox in the field editor for both of these fields, again I am able to preview and update the Property post as expected. Post validation seems to be enforcing field requirement even if the field group is hidden by conditional display logic. Let me get some clarification about this behavior and the expectation in this scenario. It seems field requirement in a hidden field group should not be enforced, and form submission in this case should be allowed to proceed without warnings / errors. I'll give you an update as soon as I can.
Thanks Christian, I went ahead and removed those required custom fields on the Industrial Group and moved those required conditionals to a separate field group that shows up on all listings. This way it can still be required but not in a hidden group. I think this will solve the issue moving forward. But it would be good to know for the future if it's possible to have required fields in hidden groups. In the previous version of types it seemed to be allowed and didn't cause any issues.
Thanks again for your help!
Hi, thanks for the update. I'd like to reopen this thread because there seems to be an exception in your case - I was not able to reproduce the same scenario on my local test site. If a field is hidden with conditional display logic it should not be required to publish the post. If it's okay with you, I would like to create a clone of your site so I can present the problem to our developers and they can work on a solution. Please let me know if it's okay for me to do that, and I will get started.
Definitely, no problem Christian, anything to help take a closer look at the issue for the future. Thanks!
Okay I ran several more tests and it appears that the problem only occurs if you have the "Property Listings" template selected in the Industrial Property field group's conditional display settings. That template is part of your custom theme files - archive-properties.php. Is there any case where you are using this template other than in the Property archive pages? If not, then this would appear to be unnecessary in the conditional display settings. You should uncheck that checkbox anyway, then the hidden required fields are no longer an issue.
Thanks Christian, the conditional logic issue for this specific setup can be fixed by removing any required fields in hidden field groups. I removed the require fields and only have required fields show up in the main always visible field group. There are several different content templates that are used depending on the type of property, so the conditionals trigger those hidden field groups based on what type of property it is and then is styled by choosing the correlating content template. The checkbox being checked didn't cause an issue in the previous versions of types so thats why it wasn't fixed, but you are correct that unchecking that box will solve the main issue. Thanks again!
There are several different content templates that are used depending on the type of property, so the conditionals trigger those hidden field groups based on what type of property it is and then is styled by choosing the correlating content template
Yes I understand that, but there is no Content Template called "Property Listings", which was checked in the conditional display configurations for the Industrial Property field group. That template is not a Toolset Content Template, that is one of your PHP template files - archive-properties.php
This is what I'm trying to understand - why was that template checked in the conditional display dialog? As far as I can tell, there is no reason for it to be checked here, because it is not a Toolset Content Template. After you uncheck it, then you can add the required fields back to the Industrial Property field group if you'd like, and you will not be prevented from editing the post.
If you're satisfied with the current setup for the required/not required fields, then you can disregard and we can close the ticket - I just wanted to make sure you understood that it would be possible to have the required fields in their previous configuration if you uncheck "Property Listings", which shouldn't be checked anyway.
Christian, sorry for the confusion, you are correct on the content template. That must have been checked in error, as the content template selection is done manually depending on the listing type. So unchecking will solve that issue, it just wasn't creating any problems in the previous versions of types (saving and updating was still working), so thats why I didn't notice the issue until updating. Thanks again for your help!
Okay marking this one resolved per your comments. Thanks!
