Ron Strilaeff

While I’m on the subject of programatically creating tables, apparently there is a problem with dbDelta creating duplicate indexes. I am creating a table within the init action hook (for now) like this:

function sv_create_favorites_table(){
	global $wpdb;
	$table_name = $wpdb->prefix . "favorites";
	$sql = "CREATE TABLE IF NOT EXISTS $table_name (
		fav_id bigint(20) not null auto_increment,
		post_id bigint(20) not null,
		user_id bigint(20) not null,
		fav_date timestamp not null,
		PRIMARY KEY  (fav_id),
		KEY (post_id),
		KEY (user_id)
		);";	

	require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
	dbDelta($sql);
};

add_action( 'init', 'sv_create_favorites_table');

… and the only way I could prevent it from creating multiple duplicate indexes named post_id_2, 3, 4, etc was to add the “IF NOT EXISTS” clause to the CREATE TABLE statement.

But the real question remains .. is there a better hook than init?, so that this create table statement is run exactly once as long as the site is alive (or I need to change it)?

The only way that I’ve found so far to reliably and quickly clear the cache in Quick Cache is to simply turn it off for a couple of minutes, look in filezilla to see that the wp-content/cache directory is empty (except for that mutex file) then turn it back on.

My motivation for deleting those 19k old files is that it takes way too long to backup (using filezilla) and they are not critical files.

The “GET Requests” option is “True (Don’t Cache)” so that’s not an issue.

Pasting in the URL from the QC comment at the bottom of a stale cache file does recreate a new cache file (with the same MD5 name), so that’s good too.

I do make use of the autocache feature which, as I understand it, will immediately cache a page that is changed so no anonymous visitor has to experience that 1 or 2 second first hit delay.

Also, on that site we get 10k hits per day and I’m sure they are not all unique.

So that leads me back to the question about why so many old files. I thought the QC “garbage collector” is supposed to run every hour, and since my expire time is set to 3602 seconds, there should not be any files older than 2 hours + 2 minutes. There is a scheduled task for this in the wp_options table. I’m pretty sure my wp_cron is executing normally since I do get wp plugin update notices.

My best guess is I think the garbage collection routine is not working, and there is some not-so-unusual (since I’m not the only one experiencing this) combination of settings that make it not run. Do you think it is by design that unvisited pages/files would remain dormant in that folder forever? Isn’t garbage collection supposed to get rid of that to prevent bloat?

Thanks for that confirmation.

However, it still bothers me that there would be 19k (1.6GB) cached files dating back 3 months when I have my QC config option “Cache Expiration Time” set to 3600 seconds (1 hour).

The site seems to be performing well. I’ll try to test if it is actually presenting one of those old files to a non-logged in user. Any tips on how to prove that?

Thanks, Ron

More testing:

In this plugin, The droppable file count should be limited to one, but it may be hard to do since I think there is minor bug (or misunderstanding) in the plupload js-plugin that this is based on. It seems to ignore the “multi_selection: false,” setting.

Right now, in this plugin, if I selected 4 images and dropped them onto the droparea, all of them get attached to the post and the last one becomes the thumbnail. I guess that’s OK as long as the user understands that.

That multi-file drop ability is the default for the WP version 3.5 media uploader (which is vastly improved IMHO).

By the way, in order to implement this D&D functionality on a user-facing submit form in a page template (like a contact form), I’m digging in to the plupload API (and ajax and jCrop which is stretching my comprehension of js).

Thanks Tobias for the inspiration, and I will share my code with you when I get it all working.

Thanks,

Yeah I’m going to have to go back to the basics and roll my own. Once I get the uploaded image in hand I can figure out the jCopy stuff.

It seems the trickiest part right now is is getting the javascript plupload.full.js to even be available. Is WP supposed to have that already loaded or does every php file have to enqueue it?

Ron