Tagged: meta-boxes, Priority
- This topic has 14 replies, 3 voices, and was last updated 5 years, 8 months ago by
Steve.
-
AuthorPosts
-
-
June 6, 2016 at 12:00 am #6592
mcmasterMemberPiklist 0.9.9.8: Been tearing my hair out trying to figure out why I couldn’t change certain field values in meta-boxes; finally narrowed down the case. The problem occurs when the post-type supports ‘custom-fields’ and the meta-box has low or no priority set. I can set a value and save, but then cannot change the value.
See behavior here: http://recordit.co/VIS0mcZ7OS
Simpleton post type:
$post_types['simpleton'] = array( 'labels' => piklist( 'post_type_labels', 'Simpleton' ), 'public' => true, 'rewrite' => false, 'has_archive' => false, 'menu_icon' => 'dashicons-smiley', 'supports' => array( 'title', 'custom-fields', ), );Meta boxes:
/* Title: Test with priority: high Post Type: post,simpleton Priority: high Order: 10 */ piklist( 'field', array( 'type' => 'text', 'field' => 'test_high', 'scope' => 'post_meta', 'label' => 'Enter text', ));/* Title: Test with priority: low Post Type: post,simpleton Priority: low Order: 10 */ piklist( 'field', array( 'type' => 'text', 'field' => 'test_low', 'scope' => 'post_meta', 'label' => 'Enter text', ));/* Title: Test with no priority set Post Type: post,simpleton Order: 10 */ piklist( 'field', array( 'type' => 'text', 'field' => 'test_nop', 'scope' => 'post_meta', 'label' => 'Enter text', ));If I remove ‘custom-fields’ from the post_type supports clause, all three fields can be set and reset with no problem.
I have a testbed available; let me know if you want the keys.
-
June 6, 2016 at 12:02 am #6593
mcmasterMemberp.s. I’m also curious about why the text input box is initially below the label and then jumps up beside it
-
June 6, 2016 at 11:22 am #6595
-
June 6, 2016 at 1:39 pm #6601
SteveKeymaster@mcmaster– This is normal WordPress behavior. If you want the custom-fields meta box and use custom fields you need the is_protected_meta filter.
The next version of Piklist will have this built in.
-
June 6, 2016 at 4:00 pm #6605
mcmasterMemberThanks for your help. But let me be clear. I’m not such a fool as to create a post type that supports custom-fields. The problem arose with type “post,” which includes custom-fields as default. It took a while to figure out that the problem was related to priority, but then I found that I didn’t have the same problem with my custom post types.
I created the “simpleton” post type so that I could isolate the problem. Once I saw that it was the interaction with custom-fields, I added the following to an init function:
remove_post_type_support( 'post', 'custom-fields' );I posted here as I thought it might be helpful to others.
-
June 6, 2016 at 4:50 pm #6606
JasonKeymasterInteresting, so, to be clear, low priority fields aren’t saving for the default post type? Are you using the latest trunk version of Piklist? I just tried to reproduce this locally and am unable to; it’s saving and updating just fine.
-
June 6, 2016 at 5:04 pm #6607
mcmasterMemberThanks, Jason. I’m using 0.9.9.8, and yes, I was having the problem for both post and page post types. I had added a “credits” field and it was working fine but I wanted to move it below the excerpt field, and that’s when it stopped working. I had done some other changes as well, so it took a little experimenting to figure out which change caused the problem.
Did you test with the “simpleton” type I created? And is there any chance that you have code somewhere that removes support for custom-fields from post/page types?
-
June 6, 2016 at 5:06 pm #6608
mcmasterMemberSteve, I read the article you referenced, and I don’t see anything related to priority. I find it odd that one could save changes to fields in high-priority meta-boxes but not in meta-boxes ones.
-
June 6, 2016 at 5:28 pm #6609
JasonKeymasterHmm.. I’m using 0.9.9.9. I’m not aware of any fix for this, but it’s possible.
I haven’t tested the simpleton just yet, but I’m just using the default post type changing nothing about it but the name. I’ll try to look into this a bit more later. Unfortunately I’m in the middle of a very tight deadline.
-
June 6, 2016 at 5:34 pm #6610
mcmasterMemberNo hurry as my code has been working fine since I’ve disabled custom-fields support.
I just put my Piklist test plugin into a Git repository: https://github.com/donnamcmaster/mcw-piklist-test
It contains an add-on so you’ll need to activate that through Piklist after activating the plugin.It creates the simpleton post type. It also turns OFF custom-fields support for pages, but leaves it on for posts. The three meta-boxes are all active for all three post types. I just confirmed that I can set initial values for all fields in all tests, but can modify the field values in the lower=priority only on pages.
Thanks for the reminder about the 0.9.9.9 release. 😉
-
June 6, 2016 at 5:34 pm #6611
SteveKeymasterI believe it’s because they are rendered before the default custom fields meta box
-
June 6, 2016 at 5:35 pm #6612
mcmasterMemberSteve, it sure feels like a WordPress bug to me!
-
June 6, 2016 at 5:36 pm #6613
SteveKeymasterThe default custom fields meta box is essentially creating duplicate inputs.
-
June 6, 2016 at 5:39 pm #6614
mcmasterMemberIt almost seems backwards: that the changes in the high priority boxes would be saved first, then the custom fields box would overwrite them, then the low-priority box changes would be saved and overwrite custom fields. So I guess they’re processing the low priority boxes first?
Anyway, as I said, just glad that I know to disable custom-fields on the built-in types!
Donna
-
June 6, 2016 at 8:46 pm #6616
SteveKeymasterThanks, Donna!
-
-
AuthorPosts
- The topic ‘bizarre priority/custom fields interaction’ is closed to new replies.