[Resolved] Re-used fields in custom post fields don't show up when editing posts

[Author]

Posts

[kaleeR-3]

When using a field in multiple custom post field groups (so when its added over "Add New Field" -> "Choose form previously created fields" for example) it won't show up when editing the associated post, only the completely unique fields show. As soon as you re-use that unique field it disappears from all posts, when you delete it so it's unique again it appears again.

When making the field non-unique and unique again, the data doesn't disappear - so I assume this is some kind of frontend bug?

Attached are two images how it looks with the "Deus Ex: Human Revolution Game" field being unique, and then when I add it to another custom post field group it disappears.

[Mateus Getulio]

Hello there,

Thanks for your contact!

That is strange, I have just tested the same behavior and the reused custom field worked well in my local copy. Therefore, it makes me believe that we might be facing an interaction issue with a third-party functionality. In this case:

- Deactivate all the plugins that are not related to Toolset
- Switch for a moment to a WordPress default theme like Twenty Twenty-one
- If the issue is gone, activate one by one to see with which one there is an interaction issue

Could you please tell me the results of this investigation?

We're looking forward to your reply. Thank you.

Regards,
Mateus.

[kaleeR-3]

Hello,

I've deactivated all plugins and switched to Twenty Twenty-one, but the issue persists.

We are using WordPress 6.2.2 and Toolset Types 3.4.19 by the way, if that matters.

Best regards

[Mateus Getulio]

Hello there,

Thanks for your reply.

I would like to request temporary access (wp-admin and FTP) to your site to take better look at the issue. You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it.

Our Debugging Procedures

I will be checking various settings in the backend to see if the issue can be resolved. Although I won't be making changes that affect the live site, it is still good practice to backup the site before providing us access. In the event that we do need to debug the site further, I will duplicate the site and work in a separate, local development environment to avoid affecting the live site.

Privacy and Security Policy

We have strict policies regarding privacy and access to your information. Please see:
https://toolset.com/privacy-policy-and-gdpr-compliance/#data-shared-with-our-support
**IMPORTANT**

- Please make a backup of site files and database before providing us access.
- If you do not see the wp-admin/FTP fields this means your post & website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box. The private box looks like this: hidden link

Please, let me know if you need any additional details. Have a nice day.

[Mateus Getulio]

Hey there,

Thanks for providing the website credentials.

It seems that we have a conflict of conditions, causing this issue. More precisely, the conditions:

- Additional condition(s):
Deus Ex: Human Revolution Category = Quest Items

and

- Additional condition(s):
Deus Ex: Human Revolution Category = Weapons

You cannot have both at the same time, otherwise the fields originated from one group and re-used in the other one, won't be visible in the first one (as soon as you add it in the second one). Please consider remove it, and if needed, create new field groups for these conditions.

You can check that I replicated this behavior in the following Sandbox: hidden link, and when I removed one of the problematic conditions, the 'Game' select field could be re-used without problems.

Kindly let me know if it's clear and solves the question. Thank you.

Best,
Mateus.

[kaleeR-3]

Hello,

So If I understand it correctly even removing those conditions doesn't solve the issue. See the attached screenshot, the "Game" field is missing from "Deus Ex: Human Revolution Quest Items" even though the two conditions you mentioned are removed (screen is from the sandbox you linked).

Correct me if I'm wrong here, but since the data is still accessible (for example when inserting it via shortcode into the block editor), I assume that Toolset only displays the first occurence of the "Game" field in Weapons, since it's re-used in Quest Items. I'd speculate that this is exactly what happens when you add the conditionals back, so it's hidden from Quest Items but not from Weapons, since Weapons is the first "global" occurence.

In my opinion it makes zero sense to have re-usable fields in the first place if that is the intended case. If it's a bug it would need a fix. At least when filtering the fields down via conditions like the ones you mentioned, Toolset should figure out that not all groups are being displayed, and display the re-used "Game" field correctly.

If this is indeed intended, this would mean we would need to create thousands (literally, since we cover a lot of games with a lot of content) of custom unique fields, like "Deus Ex: Human Revolution Weapons Game", and not only is this not great from a usability standpoint, but it also begs the question why fields are re-usable in the first place then.

Please let me know if I understood anything wrong or if theres another, intended way to achieve this.

Best regards

[Mateus Getulio]

Hello there,

Thanks for your reply.

I have double-checked the issue, but so far I haven't been able to find a fix. I asked my colleagues to take a look to see if there's any way to workaround this situation.

I'll come back here as soon as one of them answers me (which shouldn't take long). Thank you in advance for your patience!

Regards,
Mateus.

[Mateus Getulio]

Hello there,

Thanks for your patience.

Let's start with a more simple example to understand the heart of the problem:

We have two custom field groups assigned to some post type, and both field groups include the same custom field, without any other display conditions than the post type. If you edit a corresponding post, both field groups would be included in the post editor, and so the same custom field could be included for the post being edited twice, which cannot happen. Therefore, while generating the page, Types will drop the field from one of the field groups to prevent that from happening. That happens on the server in PHP.

Now, the other display conditions that subsequently get added—in particular, include each field group in the editor or not depending on the value of some other custom field—are implemented in the browser via JavaScript. That's so the UI can update to include/exclude the field group based on the selection of the other field, without having to reload the page.

Now it enters the conflict, because the PHP that rendered the post editor in the first place already dropped the shared custom field from one of the field groups to prevent the possibility of it being added to the same post twice.

Although the additional conditions added via JavaScript mean that the field wouldn't appear twice on the post edit screen, it's hard to know that would be the case ahead of time when the page is being rendered, so it will always be the case that where a field might appear twice on the same page Types will make sure it only gets added to the page once, in which case the JavaScript display conditions for the field groups won't make it re-appear from where it is missing.

Having said that, doing specifically that isn't possible, I'm afraid, and it is not something that can be readily changed.

As an alternative, try to not share the 'game field' across custom field groups, instead have it in a custom field group of its own, with the relevant conditions for whether to include it assigned to that field group.

I hope that this explanation is clear now. Thanks for your understanding.

[kaleeR-3]

Alright thank you for the explanation and your effort, we'll try and use a workaround.