Hot answers tagged

7

I had the exact same issue. The problem is not one that can be fixed without modifying some code that you probably shouldn't (or perhaps writing a filter or a 'drop-in'). The issue is the CAST directive in the SQL statement. It CASTS the entire table before it does anything, with the amount of records you have, its going to take a while. Capture the query, ...


5

There is no build in function to achieve what you want, at least not for complicated meta queries like this. If you need to use build in functions for this, the best will be to make use of WP_Query. To make the query faster and to skip the unwanted returned array of WP_Post properties, and because you are only interested in post count, you can use the ...


4

I can't find a clean, native way to pull this data. There are a couple of ways I can think of to do this: First, something like: $sql = " SELECT user_id,meta_key,meta_value FROM {$wpdb->usermeta} WHERE ({$wpdb->usermeta}.meta_key = 'first_name' OR {$wpdb->usermeta}.meta_key = 'last_name')"; $ansatte = $wpdb->get_results($sql); ...


4

The Bad News: The core open source base of Wordpress does make quite a few assumptions about being run on a single server (wp-content, user uploads and media library to name a few) The Good News: Pretty much all cloud providers (including Azure) have abstractions that allow you to work around these design limitations. Fundamentally, you'll be addressing ...


4

WordPress does not support MySQL 4 : To run WordPress your host just needs a couple of things: MySQL version 5.0 or greater (recommended: MySQL 5.5 or greater) https://wordpress.org/about/requirements/ While the utf8mb4 encoding is recent change and you might work around it, overall you still need compatible MySQL version.


4

First of all, the prefix is only a configuration option and not a security feature. The reason is that once an attacker has access to your database, he can find out any exisiting table prefix within seconds. There's no way this obscurity protects you from any attack. For the prefix itself, WordPress asks you to use only digits, letters (here only basic ...


4

Questions like this usually yield a lot of discussions, but let me give it a shot: If you're talking about SQL queries: If you're only adding content, managing plugins, themes and WordPress updates, there's a 99.9% chance that you will never need to write a single line of it. I don't want to put 100% only for cosmetics :) If you are developing (or just ...


4

The problem If the table already exists your code will still try to execute the following queries: 1) ALTER TABLE wp_voicemail_call CHANGE COLUMN user_id user_id BIGINT(9) UNSIGNED NOT NULL 2) ALTER TABLE wp_voicemail_call CHANGE COLUMN call_id call_id BIGINT(9) UNSIGNED NOT NULL 3) ALTER TABLE wp_voicemail_call CHANGE COLUMN opened opened BOOL DEFAULT 0 ...


3

You should'nt really be using wp query here, use get_user_meta(); Example: $first_name = get_user_meta(2, 'first_name', true);


3

Here's one experimental idea: Assume we got: post A with the custom field location1 as UK - London post B with the custom field location2 as France - Paris post C with the custom field location3 as USA - New York Then we could use, for example: $args = [ 'meta_query' => [ 'relation' => 'OR', [ 'key' ...


3

The insert method of $wpdb already scapes the data taking care of SQL injection. What you should worry about is about data sanitization and validation. For exmpla: Sanitization What type of data do you accept in $votes? A integer value? If so, be sure $votes contains a integer value. You cuold do it, for exmaple, using intval function from PHP. This is ...


3

You should be fine deleting empty custom fields. The main reason is, that get_post_meta( $id, 'metakey', true ) returns an empty string if the field is not set, so it is the same as having an empty record set. get_post_meta( $id, 'metakey', false ), returns an empty array if no value is set, so you should be fine too. The only problem you could face is ...


2

You have the following methods of the $wpdb object: $wpdb->flush() that contains a call to mysqli_free_result() or mysql_free_result() if not supported. $wpdb->check_connection() that contains a call to mysqli_ping() or mysql_ping() if not supported. You can of course use all your PHP functions in WordPress. Here's an example based on the \wpdb ...


2

wpdb::insert already protects against SQL injection, it's a wrapper for wpdb::prepare For insert(), you can pass a third "formats" argument for extra sanitization: $wpdb->insert( 'votes', array( 'votes' => $votes, 'competition' => $competition, 'uid' => $uid ), array( '%s', // $votes will ...


2

You can use posts_groupby filter: add_filter( 'posts_groupby', function( $groupby ) { return ''; } ); If you want to apply to remove the GROUP BY only to main query and in the frontend, you could do something like this: add_filter( 'posts_groupby', function( $groupby ) { if( ! is_admin() && is_main_query() ) { ...


2

No! WordPress will not protect against SQL injection in this case. You need to do so yourself, using $wpdb->esc_like and $wpdb->prepare: if ( isset( $_GET['q'] ) ) { // WordPress forces magic quotes (god knows why), unslash it $value = wp_unslash( ( string ) $_GET['q'] ); // Escape like wildcards so that MySQL interprets them as ...


2

First pass for a solution. It uses the new meta sorting that was introduced in 4.2: <?php $args = array( 'posts_per_page' => -1, 'meta_query' => array( 'relation' => 'OR', 'ongoing' => array( 'key' => 'prog_ongoing', 'value' => 1 ), ...


2

So what I'm going to do going forward if I use wordpress for this project is to create a reverse post id index. I don't think this is the "correct" answer and some people will definitely outright disagree with this approach but this is working for me in production. I got the idea from reading this blog post here: ...


2

Try this, should get you started.. (not tested though) function count_total_vote() { $args = array( 'post_type' => 'post', // Your post type 'status' => 'publish', 'meta_key' => 'vote', // Meta Key ); $total = 0; $votes = new WP_Query( $args ); if ( $votes->have_posts() ) { while ( ...


2

You probably haven't changed the display name, which is probably what is being displayed. "nicename" is used for the author's posts page url and not for display. UPDATE wp_users SET display_name = replace(display_name, @old_user, @new_user);


2

The post content field is MySQL type longtext, which has a limit of 4 gigabytes. What you may be encountering is an issue with the TinyMCE editor. Content is processed and validated in the browser with JavaScript. If that's the case, I doubt you will improve your situation by using Drupal, since you will be using some sort of JavaScript-driven editor in ...


2

add this in your arguments 'query_id' => 'authors_with_posts', $user_args = array( 'role' => 'frontend_vendor', 'orderby' => 'display_name', 'query_id' => 'authors_with_posts', 'order' => 'ASC', 'number' => $no, 'offset' => $offset );


2

The wp_options table holds a lot of information, whether you deem it important or not really depends on what plugins and information you have set up on your website and how important your website is to you. For example as you've noticed it can hold the information for your active plugins, if you activate an important plugin and then rollback to a database ...


2

If we check how the wp_options table is created (in 4.4) from the schema.php file, we will find the following: CREATE TABLE $wpdb->options ( option_id bigint(20) unsigned NOT NULL auto_increment, option_name varchar(191) NOT NULL default '', option_value longtext NOT NULL, autoload varchar(20) NOT NULL default 'yes', PRIMARY KEY (option_id), ...


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 ...


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

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

You can use plugins such as BackupBuddy, but I prefer to script this and use wp-cli, which reads wp-config.php and means you don't have to worry about mysql credentials. wp-cli allows you to: export the db: wp db export <filename> import the db: wp db import <filename> safe search and replace (including serialised data): wp search-replace ...


1

I faced same type of issue when I imported my database via phpmyadmin. I think, if you have a database backup, then you can try another re-import operation vaia phpmyadmin. That worked for me, but not sure if that works for you.


1

If you import the database on your phpmyadmin. It has an option while importing sql files. Don't use AUTO_INCREMENT for null tables or zero rows. This option just above the go button. Read this checkbox and mark it based on your choice. Than import your database. It won't be the problem. The option_ID is an primary key and it's AUTO_INCREMENT. If ...



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