iayork

Thanks, I’d missed that.

I’ve tried manually adding in the .htaccess that’s shown in the readme (minus the backticks and so on, of course), and I get a server error.

At this point, once again, I’m giving up. (I try about once a year to get supercache running, and it’s failed each time.) Clearly there’s some incompatibility between supercache and my setup, but my setup is really a very simple and standard one. Fortunately, it’s not as though I’m very popular …

Hmm, good thought. There is a MysteryRays directory with a default-version .htaccess. I had forgotten that it even existed. But I just tried setting those permissions to 777, and no good — activating supercache still gives me the “Mod Rewrite rules cannot be updated!” error.

According to the page source, caching is apparently working even without the modified .htaccess.

My .htaccess file is in the wordpress root directory, i.e. /iayork.com/Blog. I tried moving it out to the base (iayork.com) and it still doesn’t work; supercache complains no matter what.

I’ve also tried copying and pasting the .htaccess file that’s described in the readme file and that causes a Server error no matter what I try or where I put the .htaccess file.

Here’s my .htaccess from the root of the wp installation directory. I think it’s default. (I have a second wp installation — no supercache — and the .htaccess files are identical.)

# BEGIN WordPress
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Still, as I say, the supercache setup page complains that it can’t update and asks about the BEGIN and END.

One point is that my blog homepage is different from the directory it’s in. (The Blog address is explicitly set in the General Settings page.) However, I would be surprised if supercache can’t deal with this.

Yes, sorry, I guess that wasn’t clear. It is asking me to update the one at the root of the install, and that’s what I was referring to as having BEGIN and END and being otherwise correct. My comment about the “wp-content/cache/.htaccess” was meant to show that it’s not a global problem with .htaccess, just the one at the root.

Thanks for the suggestion. Unfortunately, I just tried it and it doesn’t seem to work in the context I described. The author says to add “/dontfollow” to the end of URLs, and they should be converted to ” rel=nofollow” — however, he seems to only talk about the content of comments, and when I tried the /dontfollow trick on the URL section, it did not convert the modified URL to the nofollow option.

OK, progress. The problem seems to be that the xml produced by the jbackup.pl tool (which is recommended in the wordpress instructions) doesn’t match the expectations of the import script. For example, jbackup produces entries starting like this:
<entry jitemid=’1′ anum=’159′ ditemid=’415′>
whereas the official LJ Export tool produces, and the Word Press import script expects, something like this:
<entry>
<itemid>114595</itemid>
<eventtime>2007-04-02 11:56:00</eventtime>
<logtime>2007-04-02 15:56:28</logtime>
<subject>Time begins</subject>

As well, the jbackup.pl time format isn’t recognized; it gives <date> and <systemdate> instead of <eventtime> and <logtime>.

There may be other differences from expected tags, but those are definite problems.

Having written a script to change those things to the expected format, the import seems to have worked reasonably well. Comments were not imported, even though they are present in the XML, but I don’t have a way to test what the import script wanted to see for comment tags (if anything).

Hopefully not too many other people will waste their time with the jbackup.pl script.