Incorrect handling of warnings for empty required WYSIWYG fields

[jaycollier]

Describe the bug

On edit screen meta box with multiple required fields (including WYSIWYG), when neglecting to enter information into required custom fields, some warnings are displayed directly in the meta box next to the field name, highlighted in red, with text above reminding the user that “[Field name] is required.”

However, after neglecting to enter information into a required WYSIWYG field, no warning is shown. After clicking Update, an empty screen with the text “[Field name] is empty” with clickable "Back” text is displayed.

After clicking on the “Back” link, the user is returned to the form, but all of the fields are empty.

Why does the WYSIWYG field type behave differently than the other fields? Why are the fields emptied?

To Reproduce
Steps to reproduce the behavior:

1. Go to Edit Screen for Pods Custom Post Type with a required Custom WYSIWYG Field.
2. Enter information into all required fields, but leave required WYSIWYG field empty.
3. Click on Update or Publish
4. See error screen: “[Field name] is empty” with clickable "Back” text
5. Click on “Back”. All fields are now empty

Expected behavior
I expected I would see the same red warning I see on other empty required fields: “[Field name] is required” in red.

Pods Version

Pods version 2.7.12

WordPress Environment

WordPress Version: 5.1.1

PHP Version: 7.2.17

MySQL Version: 5.6.36

Server Software: Apache/2.4.39 (Unix) mod_hive/6.27 OpenSSL/1.0.1e-fips mod_fastcgi/2.4.6

Your User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Session Save Path: /tmp

Session Save Path Exists: Yes

Session Save Path Writeable: Yes

Session Max Lifetime: 1440

Opcode Cache:

• Apc: No
• Memcached: No
• OPcache: Yes
• Redis: No

Object Cache:

• APC: No
• APCu: No
• Memcache: No
• Memcached: Yes
• Redis: No

WPDB Prefix: mcht_

WP Multisite Mode: No

WP Memory Limit: 40M

Current Memory Usage: 34.660M

Current Memory Usage (real): 36.000M

Pods Network-Wide Activated: No

Pods Install Location: /[snip]/public_html/mcht/wp-content/plugins/pods/

Pods Tableless Mode Activated: No

Pods Light Mode Activated: No

Currently Active Theme: MCHT - Beaver Builder theme

Pods Package Export (helpful!)

Included as attachment
Pods Package Export.txt

[issue-label-bot]

Issue-Label Bot is automatically applying the label Type: Bug to this issue, with a confidence of 0.99. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[SamWandi1]

Hey, I'm having a similar issue where we have quite a long form on the front end that populates the fields in Pods custom post type and when the user submits without a required field filled in it goes back to the form and all the fields are blank requiring the user to fill it in again. Any luck with this one Jay?

[jaycollier]

Yes, that sounds like the exact problem I reported, and your description is more concise.

I haven't heard back yet.

[SamWandi1]

I've made a discovery but my lack of knowledge is a hindrance but perhaps it could be of use to you, When I try to submit the front end form from an admin account it refuses to submit and prompts the user that a required field is missing. The fields are still populated. Any other account type and I get the previously mentioned problem. I've promoted various test accounts to admin and on all admin accounts it work as I would like them (ie the page doesn't reload and the user just needs to fill in the missing fields). I'm currently editing the user roles to see if there are any permissions I could give to fix this as I don't want all our users with admin privileges for obvious reasons, will report back if I find anything.

[SamWandi1]

Hey, I've solved this problem for me, I don't know if this is of any use to you but I have a plug in called User Role Editor by Vladimir Garagulya, I went into this and edited the user's roles to grant permission for edit_posts (there's one that's edit_postss, its not this one). If you check that box and save it may work. Worked for me, thought I would share, if you see my previous comment it will show how I came to this. Hope it works for you!

[jaycollier]

Thanks for that tip! I'll check it out.

[jaycollier]

Hi, SamWandi. I checked this, and even I, as an administrator, having granted myself all permissions including edit_posts, continue to have the same problem. An empty WYSIWYG field doesn't give an error within the edit screen, but throws an error on the next screen. "Back" returns to an edit screen with no data.

This is a continuing and challenging bug, as it affects all of our authors who are creating custom posts with Pods-created custom fields.

[jaycollier]

In the meantime, I made WYSIWYG fields not required, so the bug doesn't appear. Not optimal, but it works for now.

[pglewis]

I believe #5367 and this one are duplicates. The bug should only manifest with the Gutenberg editor, some details in my comment here #5367 (comment)

This will definitely be fixed in 2.8. I'm unsure what to do to patch around it in 2.7.x, in the interim however.

[jaycollier]

Thanks for the cross-reference!

FYI: We are using the Classic Editor plugin, not Gutenberg (yet).

[pglewis]

FYI: We are using the Classic Editor plugin, not Gutenberg (yet).

Ah... it is a nuisance and still a bug with the classic editor, but with Gutenberg it will literally hang things.

[jaycollier]

I have just discovered this error-handling bug happens with invalid email addresses, too.

Invalid e-mail provided for Contact Email

Query Monitor provided this additional information:

Query Monitor
The message above was triggered by pods.

Call stack:

1. edit_post() - wp-admin/post.php:218
2. wp_update_post() - wp-admin/includes/post.php:405
3. wp_insert_post() - wp-includes/post.php:4028
4. do_action('save_post') - wp-includes/post.php:3951
5. PodsMeta->save_post() - wp-includes/class-wp-hook.php:288
6. Pods->save() - wp-content/plugins/pods/classes/PodsMeta.php:1383
7. PodsAPI->save_pod_item() - wp-content/plugins/pods/classes/Pods.php:3234
8. pods_error() - wp-content/plugins/pods/classes/PodsAPI.php:3681
9. wp_die() - wp-content/plugins/pods/includes/general.php:223

[sc0ttkclark]

Going to follow up with this on #5484