Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect handling of warnings for empty required WYSIWYG fields #5360

Open
jaycollier opened this issue Apr 25, 2019 · 11 comments

Comments

Projects
None yet
3 participants
@jaycollier
Copy link

commented Apr 25, 2019

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 bot added the Type: Bug label Apr 25, 2019

@issue-label-bot

This comment has been minimized.

Copy link

commented Apr 25, 2019

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

This comment has been minimized.

Copy link

commented May 20, 2019

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

This comment has been minimized.

Copy link
Author

commented May 20, 2019

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

I haven't heard back yet.

@SamWandi1

This comment has been minimized.

Copy link

commented May 20, 2019

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

This comment has been minimized.

Copy link

commented May 20, 2019

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

This comment has been minimized.

Copy link
Author

commented May 20, 2019

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

@jaycollier

This comment has been minimized.

Copy link
Author

commented Jun 7, 2019

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

This comment has been minimized.

Copy link
Author

commented Jun 10, 2019

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

@pglewis

This comment has been minimized.

Copy link
Collaborator

commented Jun 10, 2019

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

This comment has been minimized.

Copy link
Author

commented Jun 10, 2019

Thanks for the cross-reference!

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

@pglewis

This comment has been minimized.

Copy link
Collaborator

commented Jun 10, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.