ckelly5

Very cool!

fwiw, they don’t seem to work in Safari (using 1.2.4 v125.12 on Mac OS X 10.3.8).

keep up the good work!

idowens: find the permalinks page (options top tab, permalinks bottom). go to the bottom of the page. copy the code out of the text field, and put it into the .htaccess file in your wp root directory, overwriting anything else there. That should take care of it.
Beel: chmod *what*? gimme a number ??

no, the file wasn’t isn’t writeable. I copied and pasted the content from the page in permalinks and now it all works. Lots of changes there ?? What do you recommend for chmod on it?

I would also love this. I installed wp-blacklist to combat some comment spam-bot that is drilling my site, and it deletes the comments, but I am getting about 10 “needs moderation” emails an hour!

apologies for the dealy on this one…
the problem, in a nutshell was that I was converting from MT to WP. My original journal was in the root directory of my site https://www.ckelly.net. I was planning on just putting the new stuff in a subdirectory called “journal”, but toyed with the idea of putting everything in the same place as the previous journal (in the root dir). I didn’t want any search engine hits to become 404s, so I looked to .htaccess files for a solution.
my idea involving .htaccess was to have all my search engine results for my archives properly redirect to the new format. My original MT archive format was “/archives/YYYY/MM/DD/index.php#*postnumber*”. When I tried to get the WP formatting to match up to this, i encountered complications with the fact that the main page for WP is also index.php. so i was simply trying to redirect any URL that ended in “index.php” to redirect to that URL, sans the file specifier on the end (“/archives/YYYY/MM/DD/index.php#*postnumber*” becomes “/archives/YYYY/MM/DD/”). This turned out to be very difficult, as even referencing a directory it would try and load the index.php, and the rewrite rules would kick in and make a redirect loop.
my solution was to go back to my original idea and place the WP files in a “/journal” directory, and redirect from there. rewrite rules then became:
if it’s the root directory (main page only, pretty much), then redirect to that dir with a “/journal” at the end of the main URL and before any subdirs. This takes care of anyone going to the main url. they are redirected to the journal subdir.
if it is in the archives directory at all “/archives”, then modify the path to strip off the “index.php and anything after it, and redirect it to the “/journal/archives” directory with the same date formatting after. (e.g. “/archives/YYYY/MM/DD/index.php#*postnumber*” becomes “journal/archives/YYYY/MM/DD/”. This takes care of the archives and incoming search engine links. The new archives pages use the topic name as the file URL (e.g. the post “new engine” becomes ckelly.net/journal/archives/*date*/new-engine, but the content will still show under ckelly.net/journal/archives/*date*/
all in all it works pretty well, and I am happy with the results. if anyone would like a copy of the .htaccess files, I’d be more than happy to help out.

well I kinda cheated on this one. My original MT journal was in the main directory of my site at https://www.ckelly.net/. I was planning originally on moving everything to a “/journal” subdirectory where all the new WP stuff would stay. When I was writing these requests, I was toying with the idea of putting everything back in the main root dir, but after the headaches this seemed to be causing, I decided to just go ahead and put in all in the “journal” subdir after all. When I decided to do that, the .htaccess file portion of things was easy.
thanks for you help thomasmaas

yeah, pretty much. I could be a jerk and redirect all the 404s to the main index, but I thought I’d try and be a nice guy and send them to the right page… ??

heh, yeah. oops. my bad. fixing now

hmm, I have to agree, I have data in the links-update-cache file, but I am not seeing any changes to the ordering :/
any particular settings I need to change in the links settings that could be causing this?

hmm, nope, it doesn’t look like I am. the index.php is from the new 1.2 release, and I don’t see any mention of the links-update.xml.php file, and even if it was, I didn’t touch it and therefore it would still be commented out…
either way, would that explain the not so pretty output in the plugins page?

After following your instructions, I am getting a
“Fatal error: Cannot redeclare update_links()” error message on my index page. It is telling me it is defined in the plugin file and “wp-includes/links-update-xml.php on line 34”
plus the plugin page shows essentially the whole file in the plugin name section.
anyone else seeing this?

I’d also like to point out that the level specifier on the users page is a PITA to modify. I think rather than the “+” and “-“, the level number should be in a drop menu, where you can click on it and select the level. If the level is low enough, then you can show the “X” for deletion. Admins with lots of users could waste a lot of time clicking on plusses and minuses and waiting for the page to refresh. Just a usability quirk, but it’s all about usability, right? ??

actually on second thought, the postname approach will work, and I can still write a forwarding rule to go to the permalink date dir (e.g. https://www.frankentosh.com/b2/archives/2004/05/17/) and have the individual post name (or post id) be the link with comments.
your help is much appreciated.

yeah, I just found out that your second example doesn’t work either.
gotta think about how I want to set this up. I was hoping to avoid the postname (just doesn’t look *right* to me), but it’s starting to grow on me. or like you said, perhaps I’ll just start hacking on the rewrite rules.
thanks!

it was more of an easy transition from the mt directory structure to wp than anything (in terms of redirection).
guess I’ll just have to take that into account when I do do a redirect script.
thanks.