skippy

miklb: I don’t see why not. The modifications Ryan made only check to ensure that directory traversal isn’t happening (using “../” in the file name to move up the directory tree). The cron job backups shouldn’t be doing anything like that.

“defcon” is Defense Condition.

Ryan Boren cooked up a fix for the directory traversal vulnerability. Download it here.

vkaryl: for the record, the original version of my plugin only required write access to the /backup/ directory inside /wp-content/ and then only for the web server, not for everyone.

When Matt bundled WP-DB Backup with the core WordPress download, he modified it to use a semi-secret suffix on the directory name, so that folks couldn’t guess the on-disk location of the backup files. This was a reasonable thing to do.

The plugin tries to automatically make this directory, and dies if it cannot succeed. As such, the /wp-content/ directory needs to be writable. Again, it really only needs write access to the webserver, but the docs team seems to have found it easier to just tell people to make it world-writable.

I questioned Matt about this, and his reply was “/wp-content/ was always meant to be writable.” I disagree strongly with this position, myself, but it’s out of my hands at this point. *sigh*

I renamed the file from wp-db-backup.php to something else. That way, when I replace the file with the fixed version I won’t need to re-activate it. Of course this means that cron jobs won’t run, but that shouldn’t be a big deal for the time being.

I honestly don’t know whether WordPress allows execution of the plugin when accessed directly, even if the plugin has been disabled.

get_currentuserinfo() sets a number of global variables. You can see them all in the function at line 34 in /wp-includes/pluggable-functions.php

For your convenience, here they are:
$user_login = $_COOKIE[USER_COOKIE];
$userdata = get_userdatabylogin($user_login);
$user_level = $userdata->user_level;
$user_ID = $userdata->ID;
$user_email = $userdata->user_email;
$user_url = $userdata->user_url;
$user_pass_md5 = md5($userdata->user_pass);
$user_identity = $userdata->display_name;

To use any of these, you must make them global, like this:
global $user_identity;
get_currentuserinfo();
if ('' != $user_identity) {
echo "Hi there, $user_identity!";
}

This draft document should help explain some of the concerns. The slashdot effect very often crushes your network before it crushes your server. Or your Apache is too busy spawning children that your WordPress configuration never really becomes an issue, because you’ve exhausted your free memory…

jhkessel: ensure that you’re sending plaintext emails to your secret account, and not HTML.

Tags might be a better solution. Check out the UltimateTagWarrior plugin.

As described in the Blog_By_Email instructions, by default you need to manually load the wp-mail.php file in order to cause WordPress to query your secret account.

Several alternative solutions exist, using cron or WP-Cron. They’re documented on the Blog_By_Email page.

My subscribe2 plugin has been updated to provide daily digests (assuming you’re using WordPress 2.01 and my WP-Cron plugin), so that might be an option for some.

My cat2email plugin was written to connect WordPress to a dedicated mailing list application, like GNU Mailman: new posts to the blog are sent as email messages to the mailing list.

You could switch to sending excerpts in your feeds, and then manually craft excerpts that make it clear where the content is originating from, and who’s stealing it.

Much of the “Search Engine Optimization” game is an exercise in making money off of someone else’s efforts.

You can block incoming connections from the remote site, via firewall rules or (possibly) .htaccess rules. You can ask your hosting provider for assistance. You can also send a notice to [email protected], the hosting company used by that site.

get_the_author_url() needs to be called from within The_Loop, so it’s likely not what you want.

There might be a plugin to accomplish what you want, but I don’t know of one.

WordPress doesn’t store the permalinks in the database at all. The permalink structure stored in the database (wp_options table) is used to parse the incoming request and prepare a query to fetch posts that match the structure.

So if you’re inserting posts directly to the database, you shouldn’t need to worry about permalinks.

The QuickTags documentation should still be valid, and it explains what the <!--more--> tag is, and why you’d use it.