Tag Info

Hot answers tagged

6

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

This doesn't have anything to do with WordPress or your user's passwords. What it means is that your MySQL server is still using the old-password-hash mechanism, which was changed in MySQL 4.1. The PHP mysqli client is newer and doesn't support the old password mechanism. Since this causes an error, WordPress falls back to the old mysql client, which does ...


5

This answer is the way I would take to solve the issue if I had to face it, it means is not the answer but one of the possibilities. All the operations I will suggest should be run on a development/local server on a backup of database and not on production nor on original database. If you have 26,000 posts but post id like 4,863,166,253 there are zillions ...


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

This is what I've found. I'm using a filter to filter the ORDER BY on the SQL query generated by WP_Query. The filter is this posts_orderby. And with it, you can write a custom ORDER BY for the query. I'm gonna show you an example. add_filter('posts_orderby', 'posts_orderby'); function posts_orderby($orderby_for_query) { $orderby_for_query = ...


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


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

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


3

You can just call get_user_meta without specifying a key, and it will return all MetaValues for the user. $userdata = get_user_meta( $userID ); You may have to do a mapping for displaytitles of the Metavalue, as they are returned in an array, where the keys are the databasevalues of your metakeys. For example, you may get ...


2

If you did want to lock things down.... a normal wordpress site will usually only require the database user to have SELECT, INSERT, UPDATE and DELETE. If you want to use the automatic update feature it will also require CREATE and ALTER. Some plugins may require other permissions but most won't.


2

Please use $wpdb to interact with the Database. global $wpdb; $wpdb->update( // Table name $wpdb->posts, // New values array( 'post_type' => 'product', ), // SQL "WHERE" clause base / affected rows array( 'post_type' => 'post', ), // Data Type (available: %s string, %d integer, %f float) '%s', // SQL "WHERE" ...


2

Try to replace: AND meta_value LIKE %s with AND meta_value LIKE '%%%s%%' so your SQL will become: AND meta_value LIKE '%The%' instead of: AND meta_value LIKE 'The'


2

In typical use cases the performance cost of booting WordPress core for page load is significantly higher than querying for data. In other words it doesn't quite matter, because it won't be a bottleneck. You have to estimate: How close your data is to native WordPress concepts How much work (if any) it would be required to put it in such representation ...


2

Okay, this always seems to happen to me. I spend ages looking for an answer and finally decide to give up and post here and then one more search finds enough to solve it. Anyway, this is what worked for me: update wp_posts set post_content = replace(post_content, '[/tab] [tab title="1024x576"] <table class="screenshot-table">', '[tabby title="1024 ...


2

First off, you should not be handing an untrusted input (in this case, $_GET['id'] to your database. Always SQL-escape the query and validate/sanitize the data. (In the code snippet below, it's SQL-escaped using $wpdb->prepare() for escaping and int typecasting to sanitize to integer value). Secondly, the $wpdb object provides more than just the query() ...


2

This will create a new admin user called username with password: password in a database called DATABASE Try this: First create a row in wp_users. Replace DATABASE with your database name, username with your choosen username, password with your password of choice. INSERT INTO `DATABASE`.`wp_users` (`ID`, `user_login`, `user_pass`, `user_nicename`, ...


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


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

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

Check all credentials in wp-config.php. And don't forget about table prefix.


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

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


1

wpdb uses PHP's mysqli_affected_rows() or mysql_affected_rows(), which can be disabled via an argument in php.ini. I am guessing that that is what has happened. Check the disabled_functions line in your php.ini file and remove the references to those function. Of the top of my head, I am not sure if extensions like Suhosin mess with that function but that ...


1

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


1

One problem with the query is that the self-join with the ambiguous WHERE gives you a crossed dataset (which is masked by the DISTINCT), so it would be simpler to use wp_post as a base to attach the joins that precisely match the keys, eg SELECT p.ID, key1.meta_value as prog_ongoing, key2.meta_value as prog_date_start FROM ...


1

I needed to get post with type event and the custom field "date" later than today, this sample of code worked perfectly for me, I hope it helps to someone in a similar situation. $today = date("Y-m-d"); $today1 = date("Ymd", strtotime("$today")); $custom_meta = array( array( 'key' ...


1

You don't need to write a custom SQL for this. You can always leverage WP's get_post_custom() that returns array of all custom fields for a particular page or post. https://codex.wordpress.org/Function_Reference/get_post_custom


1

Yes, the 404 is because the local and remote server URLs are different. As a solution: You should set the local domain to be the same as the remote server In wp-config.php connect to the remote DB When you will need to access the remote server you'll need to update the file hosts and comment out the line with your remote url If your hosts file is updated ...



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