[Resuelto] Intermediary post fields not saving WYSIWYG content

[Autor]

Mensajes

[joshM-4]

I have 2 CPTs (Charts and Setlists) with an Intermediary Post Type called Charts-Setlists. In the intermediary I have 2 number fields, 1 select field, and 1 wysiwyg field. Here's where the bug comes in (for me).

I start by creating a new Setlist and then connect existing songs to that setlist. I fill in the fields (Song Order, Song BPM) choose the song Key from the select field, and add song-specific notes via the WYSIWYG field. Once I've added the songs I want I save the Setlist. But, the setlist never saves the notes I added in the WYSIWYG field the first time I save it. I have to go back in, edit each of the song connections and update that intermediary wysiwyg field and save it again for them to actually save/write to the database.

Not sure how much a screenshot will help with this, but I've attached one anyway. I appreciate your time and help looking into it.

[Christian Cox]

Hello, that's unusual. I'm not able to replicate this in a similar scenario where I add a child post and connect it to an existing parent post. I've tried adding similar fields, and I've tried both the Text and Visual tab of the WYSIWYG editor, but in all cases the WYSIWYG content is stored successfully. Is it possible I have the parent and child post types backwards in my test? You should be able to determine which type is the child and which is the parent by editing this M2M relationship and checking the checkbox "I understand that changes to these settings may delete post associations in this Relationship" to edit the settings. In your case, is Charts the "parent" or "child" post type? Have you set custom slug and names in the Roles alias fields? If so, can you show a screenshot of the settings for me in your next reply?

We've also released a round of updates today, can you be sure Types is up-to-date (v. 3.4.4 is the latest)? Can you test while temporarily deactivating the Charts Pro plugin, or does that deactivate the Charts CPT as well?

Finally, can you try adding one more custom single line or number field to the relationship field group, at the end of the list of fields? Test this field in the same scenario and see if the value is stored successfully. If not, that could indicate a problem with a server-side setting called "max_input_vars", which might be too low to support all the values you need to store in a single submission. I can see in your debug information your max_input_vars value is 1000, which might be too low in this case. We could ask your server host to help increase that value to something like 2000 if possible to see if that resolves the issue. It shouldn't have any negative side effects to be concerned with.

Let me know what you find out and we can go from there.

[joshM-4]

Hi Christian, thank you for looking into this. Here are some answers and details to your questions.

1) I uploaded a screenshot of the many-to-many intermediary post type (charts-setlists) so you can see how it's set up—it's not traditional parent-child in this scenario, unless that is determined in a many-to-many relationship by which comes first.

2) I did not set custom slugs and/or names in the Roles alias fields.

3) I updated to Types 3.4.4 and it did not change the issue for me. The WYSIWYG content is still not being saved the first time around.

4) Charts Pro isn't a plugin, it's my Child Theme where I have custom functions and scripts running. All the CPTs are created through Types. With that said, I went ahead and deactivated my theme and used the default Twenty Twenty theme—it made no difference.

5) I added a single line field after the WYSIWYG field in the relationship field group, and tested the same scenario out with this addition. It is still not saving the WYSIWYG content the first time around.

6) I am testing this on my local server—so I updated the max_input_vars to 2000, then 5000. Neither made a difference.

I'm thinking at this point I need to push the site to a staging server where you can take a look at it?

[joshM-4]

Christian, in a random assortment of testing I think found something of relevance. Quite simply, the WYSIWYG field saves the first time if the CPT is set to use the Block editor, but does not save if set to use the Classic editor.

Please give it a try and see if you're able to replicate the issue in this scenario.

[Christian Cox]

Aha - good catch, I was using the Block Editor. I can replicate this now, it seems like a bug. Let me escalate to my 2nd tier support team for further investigation. For now, it sounds like you have already implemented the workaround, which is to resave that WYSIWYG value after linking the existing related post in the post relationship editor area. I'll let you know what I find out.

[Christian Cox]

Hi, I have an update about this issue. I have been informed by our developers that the fix for this issue will be included in the Types 3.4.7 release. This is not the next upcominig release of Types, but the following release, so I will keep you posted here as I receive more information about the plugin release schedule.

[Christian Cox]

Sorry for the miscommunication, the developers have now informed me the fix will be included in Types 3.4.6. This is the next scheduled release. I'll keep you posted on the schedule as I receive more information.

[Christian Cox]

Hello, the fix for this issue is included in today's releases of Types. If you have not yet been prompted to update in wp-admin, you can trigger the update by going to Plugins > Add New > Commercial tab, and click "Check for updates" in the Toolset installer area.