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

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


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


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

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


3

This is all depends on what queries do you run on a page, are you using simple or complicated queries etc. There are really no set minimum or maximum amount of queries to a page. You will need to look in context of your site specifically and weigh the amount of queries to what is actually happening on your page. Wordpress can be quite harsh on resources ...


2

Queries ofcourse. It's faster... But in this case just please delete you wp site and start with something faster... here is my superfast framework for you... <?php /*Your bunny wrote */ I did tests, 0.0000001 runtime vs WP usually 0.7-2.8 Sarcasm off P/S/ This question have no sence since using direct queries and output of the variables isn't use ...


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

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

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

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

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

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


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

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

Your query is wrong because your third argument to TIMESTAMPDIFF is incorrect. You should be using meta_value instead of SELECT meta_value. SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_wp_kc_last_active_time' AND TIMESTAMPDIFF( second, now(), TIMESTAMP(meta_value) ) > 5184000; Try that and see if the results start looking correct. I just ...


1

There're few plugins to storage it on WordPress database. I recommend you save as users. I believe one of these plugins will help you: https://wordpress.org/plugins/wp-all-import/ https://wordpress.org/plugins/wp-ultimate-csv-importer/ To send emails, you might use an Email Marketing provider, like Mailchimp. In this case you can import all the users to ...


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