masquerade

if (eregi(‘script-name.php’, $_SERVER[‘PHP_SELF’]))
die(‘You cannot run this script directly’);

This will not work on hosts running PHP as CGI and will cause scripts to die upon inclusion of a file. This violates the WordPress coding standards, and wouldn’t be committed anyways. Also imagine a url like /?dl=script-name.php, where a proper check like a strpos would return true. To create a proper check, you’ve just created a 30 line script.

Matt has already said that 2.0.2 is ready at any moment if anything serious comes up. The actual bugs are fixed in WordPress 2.0.2, and when the WordPress development team feels something important enough for the release of 2.0.2 comes up, they will release. Obviously these vulnerabilities carry little merit with the team, and for good reason.

Okay, so, you can see which plugins he has installed, or, instead you could make a list of all the plugins with security holes, and visit the URI and see if you get something other than a 404. Either way, any attacker can walk along and figure out which files are running. There is no cross-platform way to solve this problem, bundling .htaccess won’t help non-apache users, things like this should be left to the host, as it is not a script’s duty to manage the server it runs on.

These little security advisories have been showing up since the dawn of PHP. WordPress has seen this in Gentoo’s GLSA for years, and its no longer consider any reasonable threat, as there is no sane way for every script and plugin to silently fail without bloating code. Seeing that the only use that would come out of “full path disclosure vulnerabilities” is helping in further attacks, they are not a worry, as without another vulnerability involving the filesystem, this information poses an extremely low, if existant at all, risk.

You are just as bad as the foolish security researchers who report such things, striking up FUD in perfectly harmless scripts.

https://trac.www.ads-software.com/ticket/2202

In the release of 2.0, XMLRPC uploading is broken, which is most likely the cause of your problem.

Visit wp-admin/themes.php and all will go back to normal.

This is intended behavior, and as you’ll notice, with that structure that 2.0 spits out, your permalinks still work.

You probably should backup, but you know, there’s a number of people who never do, so scripts like this have their place.

Uhm, if you delete the directory, the WordPress permalinks will kick in…

I cannot duplicate this in 2.0, with that exact url.

3. Click on the image, there is a nice menu.

Or, even better, create another use for yourself, do not give him the administrator role. This will also disable the unfiltered_html cap, and thus your HTML will be run through kses and other systems that will remove invalid HTML.

Its an Opera problem. The TinyMCE team knows about it, but there is a lot of work to be done to bring Opera even close to being able to use it, so I wouldn’t hold my breath on getting it to work by 2.0 time if I was you.

Spiders still follow links with the nofollow tag. The name is a misnomer, all the nofollow tag does is tells search engines not to give them PageRank or similar for that link.

Are you using a version of PHP prior to 4.2? in 4.2, parameters for mkdir changed, and mode became optional, my guess is that you are running a 4.1 version where two parameters to mkdir are required, and WP is only using one.

https://somethingunpredictable.com/xrefs/wptrunk/_functions/query.html
I pointed him in the direction of that last night on IRC, which has all the INSERT and SELECT queries ( its a cross reference of wpdb::query() )

Refresh, the permalink changed, you hit it in about the 30 second period before I edited this post (I realized I had a problem with timezones cause of DST.)