ekgermann

https://blogs.semperen.com/notabene/2005/05/17/meta-blogging-comes-to-semperencom/

combine them this way and set it to set the permalink to the combined site, not the source site. Then just update the combined site in the future. voila, combined blog.

Fundamentally though, I think there is a significant difference between implementing a site with a relatively few number of pages with a large number of hits, and a site with a large number of entries in the posts table which takes a low to moderate hit count.

The former can be optimized with something like WP-Cache or a front end proxy caching. The latter is much more difficult to optimize since it exposes underlying query and SQL performance issues.

Eric

Ok, I did some poking around and optimized some really horrid SQL query and got it to work I THINK the way they intended.

It looks like the intention of the original query was to give you a select box of the 10 last used meta keys in the db. Unfortunately, it’s REALLLLLLLLYYYYY slow when you have piles of metadata.

The offending function for editing is in admin-functions.php and is meta_form().

If all you’re looking for is the last 10 keys, the following code works just fine:


$distinctkeys = $wpdb->get_col ("
SELECT DISTINCT meta_id
FROM $wpdb->postmeta
ORDER BY meta_id DESC LIMIT 10");

$sql = "SELECT meta_key FROM $wpdb->postmeta WHERE meta_id IN (" . join(",", $distinctkeys) . ")";
$keys = $wpdb->get_col($sql);

do a SELECT with a DISTINCT and LIMIT to give you the meta_id’s of the last 10, then do a select of the key names from that set of id’s. It could be done in one SQL query using sub-selects and the IN clause, but that only works for MySQL 4.1 and above, so it isn’t portable (really).

Looking at get_meta_keys in the same file shows the same ugly SQL query style, so I optimized it to:


$keys = $wpdb->get_col ("SELECT DISTINCT meta_key FROM $wpdb->postmeta");

return $keys;

This again should run a lot faster against large metakey tables.

The diff for admin-functions.php (against a stock 1.5.1.1 install) can be found here if anyone wants to try it. My thoughts to the WP team are to look at incorporating it in to the next update if it doesn’t break anything else.

As I go through this project, I’ll keep optimizing for speed and posting.

FeedWordPress is another option. For an example of it in action, see https://blogs.semperen.com, a metablog of two others fed by FeedWordPress

Ok, great plugin, but ……

I think I found a bug and and I have a theory whats going on. If you have this plugin installed AND you select Options ->Reading ->Wordpress should compress articles (gzip) …

you get gibberish the second time around on a page. What I think is going on is the output to the browser goes something like this:

WordPress -> gzip (internal) -> cache -> browser

problem is, second time around it looks like maybe this is happening

cache hit -> gzip -> browser but the content in the cache hit is gzipped already (as evidenced by looking at the html file in the cache directory) and it gets run through the compressor AGAIN. So, when you get it on the browser, its garbage.

Looks like the cache population routine needs to intercept the output BEFORE it hits the zipper, cache it to disk, then feed it to the zipper when needed. This is especially true for browsers that can’t handle zipped pages very well.

Thoughts?

Option B is screw it on the selection and let Apache mod_deflate do the compression, but I digress …

Thanks for a cool plugin! It made a noticeable difference.

Eric