Tag Info

Hot answers tagged

3

No need for post IDs what has no thumbnail. Use meta query to get only those what has thumbnail. Add meta query function get_only_posts_with_images( $query ) { if ( $query->is_home() && $query->is_main_query() ) { $query->set( 'meta_query', array( array( 'key' => '_thumbnail_id' ) ) ); } } add_action( 'pre_get_posts', ...


2

Unless I'm missing something that is staring me in the face, you aren't using add_query_arg() or remove_query_arg(); since those are the only functions affected by this particular exploit you should be safe. Your code does use the query_vars filter and get_query_var() but neither of those are effected by the exploit you've referenced. Otherwise your code ...


2

You can ignore sticky posts by adding 'ignore_sticky_posts' => true, to your query. You can also set ignore_sticky_posts to 1. Please note that a post is still delivered if it is sticky, but matches the other criterias.


2

I would use a custom query like this: $amsterdamstore_args = array( 'post_type' => 'store', // This is your custom post type 'tax_query' => array( array( 'taxonomy' => 'city', // This is your custom taxonomy 'terms' => 'Amsterdam', // The term you search for 'field' => 'name', // Check against the term's ...


1

Custom queries and sticky posts are quite a curve ball to work with. I don't know how your setup looks and what exactly is your user case, but your best solution here would be to run two queries here, the first one to get your sticky posts and the other one to display normal posts Your first query's arguments will look something like $args = array( ...


1

I understand, that you add the possibilties for developers to change the html, typical a template part. That is the point, that I think you should use the default functionality for this job. get_page_template() can be overridden via the page_template filter. A simple example for the dev to change your templates from your plugin. add_filter( ...


1

You cannot insert the do_action() inside the class like that, it's gonna give you a fatal error. Instead you could use an array $skins to store all the skin functions (as closures), and the magic method _call() to call them: class skinclass { private $skins = array(); function __construct() { $this->skins = apply_filters( 'add_skin', ...


1

You need a custom query and loop here, at least that's how I do it. $args = array( 'post_type' =>'store', 'taxonomy' => 'city', 'term' => 'your list here' 'posts_per_page' => 5 ); $loop = new WP_Query($args); if($loop->have_posts()): while($loop->have_posts()): do stuff here endwhile; endif; You will probably want to ...


1

The difference is, in "plugin_part1-fixed.php" you wouldn't lose existing args. Consider the url: https://www.example.com/page/?foo=bar Your code in "plugin_part1.php" would output <a href="https://www.example.com/page/?custom_var=column">text</a> Note, the existing arg "foo" has been lost, the code in "plugin_part1-fixed.php" would ...


1

That is not how $wpdb->prepare works. You feed prepare a string with sprintf-like placeholders, and the appropriate replacement values. Placeholders The query parameter for prepare accepts sprintf()-like placeholders. The %s (string), %d (integer) and %f (float) formats are supported. (The %s and %d placeholders have been available since the ...


1

This is not how pre_get_posts works. The pre_get_posts action gives developers access to the $query object by reference (any changes you make to $query are made directly to the original object - no return value is necessary). https://codex.wordpress.org/Plugin_API/Action_Reference/pre_get_posts What you are doing is simply wrong. You don't ...



Only top voted, non community-wiki answers of a minimum length are eligible