This may be a pretty rare problem but I’ll post it regardless.
You turn on WordPress debugging only to find the log full of deprecated notices that make the log difficult to parse. Bummer.
You could spend time going through each deprecated notice and updating the offending piece of code. Or you could ask WordPress to ignore these deprecated notices (at least in the short term) by doing the following;
Here is a command line method to replace a string in multiple files in the current and sub directories.
Here is a command to get a list of modified files in a directory and subdirectories;
Here is a simple way to get the last line of a file without reading the entire file into memory.
Paging large MySQL tables can be slow using the typical offset method. This alternative method leveraging the primary key is a more efficient solution.
Originally posted on Developer Resources:
Running WordPress.com means having multimillion-record database tables. Tables which we often need to batch-query.
Provided we could hardly select (or update, etc) millions of records at once and expect speed, we commonly have to “page” our scripts to only handle a limited number of records at once, then move on to the next batch.
Classic, but inefficient, solution
The usual way of paging result sets in most SQL RDMS is to use the
OFFSET option (or
LIMIT [offset], [limit], which is the same).
But on a performance level, this means you’re asking your DB engine to figure out where to start from all on its own, every time. Which then means it must be aware of every record before the queried offset, because they could be different between queries (deletes, etc). So the higher your offset number, the longer the overall query will take.
View original 240 more words