Get all posts by post meta key and meta value

Description

For some situations, we need to get all the posts which have specific meta key and meta value.

We can do it with the help of the WP_Query class.

Example

Note: I’m giving you an imaginary example just for a reference to understand, In which situation you can use below code snippet.

Suppose,

  • We have a custom post type properties.
  • We have 15 properties are published.
  • We have store the location of each property in meta key property-location
  • And, We want to get all the properties which meta key is property-location with meta value Pune.

Code Snippet

$query_args = array(
	'post_type'  => 'properties',
	'meta_query' => array(
	    array(
			'key'   => 'property-location',
			'value' => 'Pune',
	    ),
	)
);

$query = new WP_Query( $query_args );

Here,
post_type is our custom post type slug. In our example its properties.
key is meta key. In our example its property-location
value is meta value. In our example its Pune

Gist Snippet

You can use below complete gist code snippet for reference.
Note: In below code snippet you need to change the parameters as you need.


Here,
I have added some extra parameters to optimize the WordPress query.

  • fields with value ids which return ONLY array post IDs of all found items.
  • no_found_rows with value true which optimizes the query.
  • posts_per_page with value -1 to get all the posts. Default it return only 10 items.

Show all READY scheduled events OR READY corn jobs in WordPress

Description

By using the function wp_get_ready_cron_jobs() to get all the READY scheduled events OR READY corn jobs.

Note: Use below code snippet for ONLY debugging/development purpose.

Code Snippet

Output

Array
(
    [1551289036] => Array
        (
            [wp_import_astra_sites_cron] => Array
                (
                    [40cd750bba9870f18aada2478b24840a] => Array
                        (
                            [schedule] => wp_import_astra_sites_cron_interval
                            [args] => Array
                                (
                                )

                            [interval] => 300
                        )

                )

        )

)

Multisite Support for Site Metadata in WordPress 5.1

Quick Highlights:

  • WordPress multisite introduces a new database table wp_blogmeta to store metadata associated with sites. This allows for the storage of arbitrary site data relevant in a multisite/network context.

  • It provides an alternative to using options and can be retrieved from multiple sites in a more performant way—without calling  switch_to_blog(). Sites can now also be queried by their meta with parameters supported by WP_Meta_Query.

  • Note: A network update is required to install the new database table.

  • New API functions:
get_site_meta( $id, $meta_key, $single )
update_site_meta( $id, $meta_key, $meta_value, $prev_value )
add_site_meta( $id, $meta_key, $meta_value, $unique )
delete_site_meta( $id, $meta_key, $meta_value )

All of these functions are ONLY available in multisite, however they work similarly to other metadata wrapper functions, such as for posts, terms, comments and users. In addition to these functions, it is now possible to use the common meta query arguments when querying sites with  WP_Site_Query or its wrapper  get_sites().


Read more at https://make.wordpress.org/core/2019/01/28/multisite-support-for-site-metadata-in-5-1/

PHP 5.6 is the intended version from WordPress 5.1

Quick Highlights:

Warning about outdated PHP version in WordPress backend

  • Provided filter wp_update_php_url for a more dynamic approach on the code level. Replacing the URL should happen in cases where a more specific guide to update PHP on the given environment exists. E.g. screenshot:
Warning about outdated PHP version with custom URL and related annotation

  • Fatal Error Protection with the so-called WSOD protection (white-screen-of-death protection), A mechanism has been implemented to detect fatal errors and, in certain designated areas of WordPress, recover from them. E.g. Screenshot.
Default output in the frontend when WSOD protection detects has detected an error

Note that, while the primary reason for implementing the fatal error protection mechanism was making the process of updating PHP less “dangerous”, it is technically not tied to the update at all. In fact, it will be enabled permanently and discover fatal errors under any circumstances.


  • The functionality can also be disabled entirely if that is preferred, via a new constant WP_DISABLE_FATAL_ERROR_HANDLER or, more dynamically, a corresponding wp_fatal_error_handler_enabled filter.

  • WordPress 5.1 will display a warning for those plugins that require a higher PHP version than the one currently active.

Read more at https://make.wordpress.org/core/2019/01/14/php-site-health-mechanisms-in-5-1/