fleb

I read on the internet that a file can have settings for rights which you cannot ‘downgrade’ after uploading, so if a file is already 777 when it’s upload it, you cannot set it back to 755 or so. Does this sound credible?

There is a situation where this can happen. Normally, when you upload files via FTP, the “owner” of the file is you– the username of your account. Therefore, if the settings are such that the owner of the file has write access, you can write, delete, and have control over the file. This is usually the case with Web files– the owner is allowed read/write access, while everyone else is given read-only access (so the web-server can serve the files, for instance, but not write to them).

If you use a web-based uploader, though, it’s not your account that’s placing the file there (as it would be through FTP). The file’s data is actually being fed into the web server program, which then writes the file. Most times, to preserve security, the Web server runs as a distinct user (often named nobody), and when the web server places a file, that user, nobody, is considered the owner.

Here’s the catch: If the web-server creates the file as Writable only for the owner, that “owner” isn’t you when you log in via FTP, later on. You can end up with a file in your webspace that you can see, but that you can’t delete or CHMOD. The solution is often to create simple and temporary server script to set the files to be world-writable. That “world” includes your FTP user, and gives you access to the file.

It’s doubtful that this caused your problems, although what might have happened is that your upgrade process cleared the “world-writable” flag on some files that were set as such in the last version, making them unwritable by the webserver user. This is something you could probably remedy using your FTP client.

Bingo:

function is_last_post()
{
	global $wp_query;
	return ($wp_query->current_post == $wp_query->post_count - 1);
}

… and I keep hitting “Send Post” before I mean to.

Actually, I think that second link you posted would do the trick.

That runs into the problem, though, that if the $posts_per_page is, say, 10, but I only have 3 posts in my database (because I’m a slow writer, say), that won’t correctly detect the last post (It’ll be comparing post 9 to post 3 and saying “not last”). That’s why I’m also detecting the total number of posts from the DB call and taking whichever is less.

Looking at my own code again, though, I’m not sure if it’ll work on second-pages… That’s something I need to look into.

Have you tried unzipping it, then uploading it?

Fixed it. I’m just checking both the post_count and the posts_per_page and using the lesser of the two. If you can get through my unnatural love of the trinary operator (x?t:f), here’s the code I used (placed in my functions.php:

function last_post($zero_index = true)
{
	global $wp_query;
	$last = ($wp_query->post_count <= get_option('posts_per_page')) ? $wp_query->post_count : get_option('posts_per_page');
	return last - ($zero_index?1:0);
}