arminbw

There are myriad different causes for upload problems. The problem discussed above is just one of them.

Milestone changed from 2.0.5 to … 2.8

If you follow the “simple and easy backup” guide you better check some boxes you do not really understand.

But if you go for the “more detailed instructions” you better uncheck everything. Understood? ??

* sigh *

no reckless chmod’ing here, just proper permissions in the proper places.

This only works if php save_mode is turned OFF.
If it is turned off, what protects your directory from users on the server who are able to write php scripts?

arminbw

Yes, I used the latest version. But generally the plugin didn’t work for me very well. Edited posts didn’t get updated and the supercache folder only contained empty subdirectories.

I will try to install the plugin on another server, where I have root access, so I can investigate this a bit..

Anyway, uninstalled it.

It’s not as simple as that. The supercache directory is full of subdirectories. In my case I had to use a recursive function:

<?php
function removeDir($dirname)
{
    if (!file_exists($dirname)) {
        return false;
    }
    if (is_file($dirname)) {
 	echo ("deleting: " . $dirname . '<br />');
        return unlink($dirname);
    }
    $dir = dir($dirname);
    while (false !== $entry = $dir->read()) {
        if ($entry == '.' || $entry == '..') {
            continue;
        }
        echo ("deleting: " . $dirname . DIRECTORY_SEPARATOR . $entry . '<br />');
        removeDir($dirname . DIRECTORY_SEPARATOR . $entry);
    }
    $dir->close();
    return rmdir($dirname);
}

unlink("cache/.htaccess");
removeDir("cache/meta");
removeDir("cache/supercache");
removeDir("cache");
?>

Use at your own risk.

This problem isn’t directly related to WordPress. Sometimes it’s safe_mode, open_basedir or simply the fact that providers do not use CGI. It really depends on the configuration of the server. If it’s done well, giving 777 permissions to user files isn’t necessarily a huge security hole as your whole workspace might be protected quite well. If the set up is bad, you are screwed anyway.

And yes, this is frustrating indeed. The Web 2.0 isn’t actually a huge step forward in terms of security concepts.

After the upgrade (0.7.1) the source code of my pages still look like this:

<!-- Dynamic Page Served (once) in 0.996 seconds -->
<!-- Cached page served by WP-Cache -->

While the default cache is working, supercache only creates empty directories. Php safe_mode is off. Compression is turned off. No special plugins are installed.

Is there some error-log function I can activate? Unfortunately I cannot access the php error_log.

Rimchamp, this thread is not about login issues, but password protected posts…

Check: Resetting_Your_Password

After deactivating the plugin one file remained in my cache folder. I couldn’t delete it using ftp, because it’s owner was apache, I do not have root access and the server is not using cgi. (So in my case this is a problem related to the server configuation.)

A very short script helped:

<?php
$filename = "cache/wp-cache-fe99b33fb433933765428b2126ad62e4.html";
chmod($filename, 0777);
echo 'no try to delete this file using ftp: ' . $filename;
?>

Name it “uglydelete.php”, put it in your wp-content directory and run it by using your browser. I had to change the permission for the cache directory as well.

Note: Do not forget to change all permissions back to default again and delete the script as soon as possible!

G,
Armin

Another shortcomming:

If a protected post or page has attachments, those files are not protected themselves. If a user knows the URL but doesn’t know the password, he can access them.

The attachments are accessible to everyone, maybe even search engines.

G,
Armin

Anyone?

Bump