Wordpress - How can I create a meta_query with an array as meta_field?

Feeding the query an array of possible values

If the value in the database is a string and you want to feed the query several values:

$args = array(
    'post_type' => 'news',
    'meta_query' => array(
        array(
            'key' => 'topics',
            'value' => array ( 'sports', 'nonprofit', 'community' ),
            'compare' => 'IN'
        )
    )
);

Searching for a specific value in a serialized array of data

If the value in the database is an array of several topics and you want to search for a single topic within that array (Note that an array in the database can be retrieved as such, but lives in the database in serialized form, which is a string also):

$args = array(
    'post_type' => 'news',
    'meta_query' => array(
        array(
            'key' => 'topics',
            'value' => 'sports',
            'compare' => 'LIKE'
        )
    )
);

Using 'LIKE' as the compare value isn't as clear-cut an instruction as you might have hoped for, but it is the best option to go with.

Next to that, your only other option would be retrieving all posts that have the meta_key "topics" set and iterating over them manually or,in other words, check for the value within the loop and display the posts on said condition.

To go off of Johannes' response, since it is a serialized array, if you happen to be storing something like user id's (which was my case), you may need to handle it a little differently.

Post meta was being saved like:

array( "1", "23", "99");

So yes they are integers but through update_post_meta they were being saved as strings.

'meta_query' => array(
            array(
                    'key'     => 'my_meta_key',
                    'value'   => serialize( strval( 1 ) ),
                    'compare' => 'LIKE'
                )
            )

So you're actually doing a LIKE comparison with the serialized string version of what you're looking for. I spent a good couple hours trying to get something like this to work and so far this was the best I could come up with.

Another slight improvement from @sMyles' answer.

I have had cases where IDs have been stored both as strings (such as when taken from a form input) and as integers (e.g. update_post_meta($post_id, authorized_users', array(get_current_user_id()));). This is kind of like the well-known issue with wp_set_object_terms() where you can use term IDs to set the terms, but if you don't cast them as integers first you stand about a 50% chance of creating new terms with those numbers as their names instead.

This can result in them being stored quite differently in a serialized array, as can be seen from the excerpts of just such a case from my test site's database:

a:1:{i:0;s:1:"1";} // 's' for 'string', also note the double quotes
a:1:{i:0;i:1;} // 'i' for 'integer', no quotes

Both of the above, when fed through print_r() will render as

Array
(
    [0] => 1
)

To fix this, I made a slight tweak to the meta_query by adding a relation and another version of the query that cast the value as an integer instead of a string.

Here's the final result:

        'meta_query' => array(
            'relation' => 'OR', // Lets it know that either of the following is acceptable
            array(
                'key' => 'bcm_enm_authorized_users',
                'value'   => serialize(strval(get_current_user_id())), // Saved as string
                'compare' => 'LIKE'
            ),
            array(
                'key' => 'bcm_enm_authorized_users',
                'value'   => serialize(intval(get_current_user_id())), // Saved as integer
                'compare' => 'LIKE'
            ),
        ),

EDIT: Just realized that this method could run the risk of collisions with array indexes, which could allow someone illicit access to materials if they're not in the array, but their user ID appears as an index. As such, while this works if you have the issue discussed, better practice is to ensure that any values you want to search for are cast as strings prior to saving them so that you can use @sMyles' method instead.