Here you go!

  piklist('field', array(
    'type' => 'group'
    ,'field' => 'ticket_links'
    ,'label' => __('Ticket Links') 
    ,'columns' => 12
    ,'add_more' => true
    ,'fields' => array(
      array(
        'type' => 'datepicker'
        ,'field' => 'screeningdate'
 		,'label' => 'Screening Date'
        ,'columns' => 3
        ,'options' => array(
   			'dateFormat' => 'M d, yy'
			)
      )
      ,array(
        'type' => 'text'
        ,'field' => 'screeningURL'
 		,'label' => 'Full ticket URL'
        ,'columns' => 9
        
      )   
    )
  ));

Thanks Steve! It does indeed make sense, and my error was in neglecting to delete that line assigning scope from the sample code on the User Guide site (which I had copied)! It’s working perfectly now.

Thanks Steve!

Thanks Steve, I’ve made a note of it. I actually realized that this particular add-more field was better set up as Tags… but I’m sure this will come in handy sometime soon…!

That’s definitely better. I notice that clicking the image now takes me to the Add Media page, but that’s not all that helpful, as I still have to search for the image – it would be great if it took me right to the “Edit Media” page for that particular image, where I can add the caption, etc. But, something for the future I guess!

Well, this is the darnedest thing, but if I add your suggested two lines of code anywhere to my template, it kills all the HTML prior to the display of all my Piklist fields, resulting in an unformatted and incomplete page. See attached. The productClaims info isn’t even shown…

Here’s what I added (including a couple of other lines for context):

global $post;

$productClaims = get_post_meta($post->ID, 'claims', false);
piklist::pre($productClaims);

echo '<p id="productSizeVariety">' . get_post_meta($post->ID, 'size_variety', true) . '</p>';

If I use print_r instead, I at least get this:

Array ( [0] => High in Protein [1] => Very High in Calcium [2] => Low in Carbs [3] => High in Iron [4] => Source of Fibre )

Any idea what’s happening?

Hi again! Here’s some late-breaking news on this developing story…

I’ve realized that I don’t need to group a “Caption” field with my file upload field after all; I can just use the built-in caption functionality for WP uploads. But before I dismantle my group and delete my “nutrition_facts_caption” text field, I guess it would be good to know why the error described is happening.

But also…

Now the thumbnail display issues, as seen in my attached graphic, become a little more pertinent, I think. I’m assuming I should be able to click that thumbnail and get to the standard page where I set the title, caption, etc. of my uploaded file. But I can’t seem to do that.

I can track it down by file name over in the Uploads area, but that seems awfully cumbersome if there’s a possible easier way to just click through from the thumbnail while I’m editing.

Let me know… thanks!

Beautiful! Thanks! I understand that it’s up to me to figure out why the get_post_meta would want to be true vs. false… but in merely comparing the User Guide example to my own attempt here, I can’t get my head around what the difference is, that mine would need to be “false” and the example is “true”, when they’re both referring to a single, add_more text field.

The echo $data; in particular I just can’t figure out the subtlety of. In the example for the template file:

<?php echo $data['exercise']; ?>

The “$data” variable seems to be making its first appearance, and be dependent on naming the ‘exercise’ array even though it’s already been referenced in the first line of the theme code which is referring to the template:

$exercise = get_post_meta($post->ID, 'exercise', true);

Am I missing some obvious difference between the example situation and my own?

At any rate, thanks for the fix, I’m so happy it’s working now! Just want to be sure I understand why, so i don’t need to bug you again about this…. 8^)