skippy

On UNIX-like systems, some account needs to run programs. On UNIX-like systems, only privileged accounts (generally the root account) need to run programs that open TCP or UDP ports below 1024 (these are called “privileged ports”). It is an extremely bad idea to run most programs as root, so what Apache does (and many other programs do) is to start as root to open the port, then switch to a different, non-privileged account to do all the work.

On my Debian server, Apache uses the www-data account. So the Apache daemon is started by root, opens TCP port 80 (and 443), then switches to www-data for handling all the incoming connections.

All of the files in my web site are owned by me, with permissions for everyone else to read them. In this way, the www-data user can access my files for use on my website, but the www-data user cannot modify these files — only I can.

Some hosting providers configure their systems to run the Apache daemon for your site using your user account. In this case, your user account is effectively running Apache, which means that Apache has full access to any files to which you have full access. So, setting file permissions to 644 would mean that the Apache process can write to your files, because Apache is using your user account.

If any of that is still unclear, please let me know which parts need clarification.

Podz: do you have access to the server logs? If so, you can check whether wp-login.php has been requested a lot of times. That’ll help confirm whether it was a brute forced attack.

Has this password been used anywhere else?
Has it been transmitted over an insecure network, like a coffeeshop wireless network?

Have you read the comments_popup_link and comments_popup_script documentation? I think that should explain what you need. If not, post your follow-up question(s) here!

You might look into a pagination plugin for the admin screens, which will limit the number of pages presented in a list at one time.

I haven’t used the Enhanced View Plugin myself, so maybe it won’t solve your problem; but it’s worth trying.

I have just set up an automated process to create a snapshot of the Subversion repository. Every thirty minutes it will perform a Subversion check out and then zip the files for you.

You can download the snapshot here: http://www.skippy.net/wordpress/

This way, you can help us out without worrying (yet) about learning Subversion!

Trac does a lot of things, but for Saturday we’re concerned primarily with the ticketing system for reporting bugs and requesting features.

http://trac.wordpress.org/report presents several pre-defined reports to use. The ones most important for Saturday are these:
Full list of open bugs: http://trac.wordpress.org/report/12
Bugs with patches: http://trac.wordpress.org/report/14
Bugs needed patches: http://trac.wordpress.org/report/13

Using these reports, we can work through the list of bug reports. People without coding experience will be asked to test the patches already submitted, and confirm whether the patch fixes the bug. People with coding experience will be asked to submit patches for the tickets that lack them (and then the non-coders will test these!).

If you use Subversion and check out the WordPress source, you can use the svn diff command to compare the difference(s) between your local working copy and the server’s copy. This should automatically create an output usable by the patch utility on GNU/Linux and Mac OSX systems.

(Sorry, I don’t use Windows, so I can’t help too much here; but several folks on Saturday should be able to!)

My Gravatars plugin does not require gravatar.com — it can manage locally stored images for locally-registered users.

Kahil: you can use my plugin’s gravatar() function to display gravatars anywhere inside your templates, however you want. If you want the gravatar image to link to that author’s posts, simply wrap the image inside the appropriate anchor tag.

You’d need a plugin, and I’m not aware of any plugin for this situation at this time.

Basically, you’d make one of the databases into the “master”, or the authoritative one; and the plugin would override all the login / profile / password stuff on the _other_ blog in order to check the data in the master blog’s database.