Post meta getter helper

[danielbachhuber]

I've written a helper for a base class like this:

/**
 * Get a given Fieldmanager field
 */
private function get_fm_field() {

    $vars = func_get_args();

    $pm_key = array_shift( $vars );

    $value = get_post_meta( $this->get_id(), $pm_key, true );

    foreach( $vars as $key ) {
        if ( isset( $value[ $key ] ) ) {
            $value = $value[ $key ];
        } else if ( empty( $value[ $key ] ) ) {
            return '';
        } 
    }

    return $value;

}

Usage: $this->get_fm_field( 'project-details', 'background', 'background' )

Would something like this be useful packaged with the plugin?

[mboynes]

That's pretty clever. I'll defer to @netaustin for the final say, but I think that would be a useful util function. We'd want to ensure that it could work across all contexts, or that there was one such function for each context (e.g. fm_get_post_field(), fm_get_term_field(), fm_get_submenu_field(), etc.)

[netaustin]

Agreed on the context issue. Fieldmanager is never instantiated except when it's rendering or processing forms, so this would definitely be a good thing to bundle in fieldmanager.php. I like the default fall-through behavior of this function though.

[fabiangarga]

Hi everyone, newbie question.
Im trying to get the meta data of a group that i made with fieldmanager it adds a bunch of images to a post.
The problem is that it returns a JSON but when i try json_decode it always pull out NULL

var dump show this string(61) "a:2:{i:0;a:1:{s:5:"slide";i:113;}i:1;a:1:{s:5:"slide";i:89;}}" NULL

[bcampeau]

That's not JSON, that's the WordPress serialized metadata format. If you are retrieving the data via get_post_meta though, you should be receiving a PHP array and not that string, unless you're performing a direct database query which you should avoid.

[fabiangarga]

My mistake i get an array.
I thought that was a json with the ID of the images, i tried with fm_get_post_meta but it returns undefined function using wpress 3.9 so i change it for get_post_meta($post->ID) and get this array

Array ( [_edit_last] => Array ( [0] => 1 ) [_edit_lock] => Array ( [0] => 1397864880:1 ) [background] => Array ( [0] => 109 ) [_background] => Array ( [0] => field_52a20508eb49e ) [reel_id] => Array ( [0] => 157 ) [_reel_id] => Array ( [0] => field_52a20558160e7 ) [slideshow] => Array ( [0] => a:2:{i:0;a:1:{s:5:"slide";i:123;}i:1;a:1:{s:5:"slide";i:115;}} ) [img_background] => Array ( [0] => a:2:{i:0;a:1:{s:5:"slide";i:113;}i:1;a:1:{s:5:"slide";i:89;}} ) )

Where "img_background" is the name of the images group

[bcampeau]

You're going to get every post meta field for a post via that method. You need to specify the second parameter of get_post_meta with the field name.

[fabiangarga]

Thanks bcampeau, now i got the id's
I think the way that i approached is not the best.

$back = get_post_meta($post->ID,'img_background');
foreach ($back[0] as $key => $value) {
print_r(wp_get_attachment_image($value['slide'],'full'));
}
Is there another better method to get the meta fields?

[netm]

Be great if we could get a simple example of accessing the meta for the 'Building a Slideshow' example on http://fieldmanager.org/ :)

[mboynes]

To get the data, you can simply call get_post_meta() using the meta key 'slideshow'. You can then loop through that data and output as need be. Here's an example:

// Assumes we're in the loop
$slides = get_post_meta( get_the_ID(), 'slideshow', true );
if ( ! empty( $slides ) ) :
    foreach( (array) $slides as $slide ) :
        ?>
        <figure>
            <h2><?php echo esc_html( $slide['title'] ) ?></h2>
            <?php echo wp_get_attachment_image( $slide['slide'], 'full' ) ?>
            <figcaption><?php echo wp_kses_post( $slide['description'] ) ?></figcaption>
        </figure>
        <?php
    endforeach;
endif;

[mboynes]

@danielbachhuber @netaustin On this proposal in general, I'm torn.

I think a helper function is asking for trouble. If a theme called fm_get_field() without checking to see if it exists first, deactivating FM would tank the site (e.g. this would happen if at some point FM were in the plugins repo and one were to update the plugin through the UI -- just a for-instance, this is a whole other discussion not worth diving into here). We could solve this by using filters instead of calling functions:

$data = apply_filters( 'fm_get_field', array(), 'post', 'project-details', 'background', 'background' );
// Or perhaps the action could include the storage mechanism:
$data = apply_filters( 'fm_get_post_field', array(), 'project-details', 'background', 'background' );
$data = apply_filters( 'fm_get_term_field', array(), 'project-details', 'background', 'background' );
$data = apply_filters( 'fm_get_option_field', array(), 'project-details', 'background', 'background' );

That aside, there's a part of me that thinks that even this is too intrusive. As it stands, except when using term meta or front-end forms, you can deactivate and remove FM from a site and everything on the front-end will continue to function without issue.

I don't know; I could easily be swayed one way or the other. I definitely see the value in it.

[danielbachhuber]

For me personally, I want to decouple data storage from meta box presentation, and just have my data stored in key => value pairs. I'm too far along with my current projects to do that, but this is what I'll be doing going forward.

[mboynes]

Now that we've merged #255, I'm going to close this out. I think this was more necessary when presentation and data storage were entangled, but now that they aren't, I think this becomes less of a "must have". Of course, there's nothing stopping someone from dropping that snippet in their theme and using it (and I think that situation is preferable).