Viewing 14 reply threads
  • Author
    Posts
    • #6592
      mcmaster
      Member

      Piklist 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.

    • #6593
      mcmaster
      Member

      p.s. I’m also curious about why the text input box is initially below the label and then jumps up beside it

    • #6595
      Jason
      Keymaster

      Hi @mcmaster!

      Interesting use-case. I’m curious, and not to dodge the issue, but why do you want the post type to support ‘custom-fields’ if you’re using Piklist to generate custom fields? The two seem to somewhat bleed into each other.

    • #6601
      Steve
      Keymaster

      @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.

      Here’s a good tutorial >

      The next version of Piklist will have this built in.

    • #6605
      mcmaster
      Member

      Thanks 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.

    • #6606
      Jason
      Keymaster

      Interesting, 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.

    • #6607
      mcmaster
      Member

      Thanks, 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?

    • #6608
      mcmaster
      Member

      Steve, 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.

    • #6609
      Jason
      Keymaster

      Hmm.. 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.

    • #6610
      mcmaster
      Member

      No 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. 😉

    • #6611
      Steve
      Keymaster

      I believe it’s because they are rendered before the default custom fields meta box

    • #6612
      mcmaster
      Member

      Steve, it sure feels like a WordPress bug to me!

    • #6613
      Steve
      Keymaster

      The default custom fields meta box is essentially creating duplicate inputs.

    • #6614
      mcmaster
      Member

      It 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

    • #6616
      Steve
      Keymaster

      Thanks, Donna!

Viewing 14 reply threads
  • The topic ‘bizarre priority/custom fields interaction’ is closed to new replies.