New answers tagged

0

You're right that the problem is a result of the explode on semi-colons. We can use the dbdelta_queries filter to fix it. In this solution we're assuming that all queries start with CREATE, INSERT or UPDATE. If you have queries you're running through dbDelta where this isn't the case, the preg_match line will need adjusting or it won't work correctly. ...


0

My advice is to stop trying to do direct sql, and use a normal WP_Query instead. Then it does lots of caching for you. And caching plugins can help with the default systems.


0

How do you know this is the bottleneck in your page? If the problem really is on this query, you can try adding an index on post_type and post_status. There are plenty of cache plugins that can also handle this for you.


-1

WordPress defines a class called wpdb, which contains a set of functions used to interact with a database. First to initialize a global object variable, $wpdb, which is an instantiation of the wpdb class defined in /wp-includes/wp-db.php. <?php require_once( '../../../wp-config.php' ); global $wpdb; if ( is_user_logged_in() ) { ...


-1

Here is my answer in code form: <?php // Customer Details $args = array( 'blog_id' => $GLOBALS['blog_id'], 'role' => 'customer', 'meta_key' => 'last_name', 'meta_value' => '', 'meta_compare' => '', 'meta_query' => array(), 'date_query' => array(), 'include' => array(), 'exclude' => ...


0

This is really simple. get_post_meta($postid); This will return all values in about the same syntax. In a more workable loop: <?php $custom = new WP_Query(array("posts_per_page" => -1)) if( $custom->have_posts() ) { while ( $custom->have_posts() ) { the_post(); $data = get_post_meta(get_the_ID()); ...


0

I hope this would do, i have not tested it. Test it on your own risk, but the query related to it very closely. function kv_get_custom_search_query($search_text){ global $wpdb; $wpdb->get_results( "SELECT * FROM $wpdb->posts WHERE post_title='%$search_text%' OR post_content='%$search_text%' OR post_title='%$search_text%' LEFT JOIN ...


0

You can put together a very finite query with the get_posts() function. I tried to understand your SQL query and define it the way I would with native WP functionality, but could have missed some details. I have no clue if this is where you are going, or if this works, but WordPress is supposed to make things easier for you. Explore this page for more info. ...


2

SQL-wise, you only need to join to the wp_posts table once. Joining to the terms stuff will give you multiple rows, so it's probably easiest to group these and then use GROUP_CONCAT() to flatten the terms into a comma-separated string (updated to use LEFT joins): global $wpdb; $sql = $wpdb->prepare( 'SELECT p.ID, p.post_title AS Product, ...


2

cracks knuckles Alright -- so first thing is first. Working w/ WordPress Databases Read this: https://codex.wordpress.org/Class_Reference/wpdb Avoid write SQL statements outside of the $wpdb object. Avoid writing SQL statements like wp_users instead do this: $users = $wpdb->get_results( "SELECT FROM $wpdb->users" ); This will help if you ever ...


2

Fixed query select p.ID as order_id, p.post_date, i.order_item_name, max( CASE WHEN im.meta_key = '_product_id' and i.order_item_id = im.order_item_id THEN im.meta_value END ) as Prod_ID from wp_posts as p, wp_postmeta as pm, wp_woocommerce_order_items as i, wp_woocommerce_order_itemmeta ...


0

Your answer is perfect working in the first array lvl, for example: $args['meta_query'][] = array( 'key' => 'tour_itinerario_ciudades_repeater_%_tour_ciudades_nombre', '_key_compare' => 'LIKE', 'value' => 'MEXICO', 'compare' => 'LIKE', ); I need do some modifications for work in the second lvl in the array: $args['meta_query'][] = ...


0

The problem is, there might be 1, 2, 3, 4 or N levels of depth in the subcategories. So, writing the query is possible, but inefficient because to be this flexible, left joins will be required which are not fast.


0

Use wp_insert_term() instead of $wpdb->insert for adding new terms.


1

The only variable which can really have an effect on the result as you described, is taxonomy. If you have verified that there are terms with a parent of 1 and a parent of 5, and get_terms() only returns terms for terms with a parent of 1, it can only mean that term 1 and term 5 belongs to different taxonomies. get_terms() will only return results if the ...



Top 50 recent answers are included