i have a small issue. Lets say there is a blog set with the name "test". i wrote a post, which was posted on the recent posts in the lyceum portal. I renamed the blog from "test" to "test2". the post in the portal is showing with the new name , but when i click the link, it points to the old name. i checked the database and in the entry "posts", it didnt update the link to the post.
Yes, I've stumbled upon this too. Easy fix though: open wp-admin/options.php , go to line 158 (should be something like $wpdb->query("UPDATE $wpdb->blogs SET slug = '$slug' WHERE id = '$blogdata->id'");) and add the following line:
$wpdb->query("UPDATE $wpdb->posts SET guid = REPLACE(guid, '".LURL."/$oldslug/', '".LURL."/$slug/') WHERE guid like '".LURL."/$oldslug/%'");
that should fix it (works for me). Not sure how fast this is on DB with lots of posts, however (where guid like..)
I need to rename a blog and update its slug. That's easy, but since I know there are links scattered around in various places that point to the old slug, I'd like to keep them working by having them automatically redirect to the corresponding URL with the new slug. How can I do that?
That's what I thought, and I tried to do that. I added this to the .htaccess file where Lyceum has all of its rewrite rules, just after the RewriteBase line:
RewriteRule ^dwsnip(/)? snippets/
This is meant to redirect any URL for the blog named "dwsnip" to the new blog named "snippets". It half works - it does get me to the "snippets" blog, but only to that blog's 404 error page, not to the actual blog page the original URL was aiming at. I'm pretty much a novice at mod_rewrite. Can you help me fix my syntax?
Rewrite rules don't behave like a substring replace operation. You need to completely specify the new URL that you want to create, so you need something like:
RewriteRule ^dwsnip(.*) snippets$1 [L,QSA]
That retains any path information that follows "dwsnip" in the original URL and appends any query string parameters present in the original URL. It's not entirely perfect as "dwsnip2" will become "snippets2" as well and you might or might not intend that.
I've just tried your version, bthale, and it does the same thing as my earlier attempt: it gets me to the right blog, but only to that blog's 404 error page.
Is there any way to see what actual URL is being generated by the rewrite rule? From the results I'm getting, all I know is that the URL is correct up to the point of specifying the blog and somehow incorrect after that. If I could actually see the URL I'd have a better chance of debugging this myself.
Try turning on the Rewrite engine's logging facility. Log level 3 is what I usually use. It will show you the steps the rewrite engine to going through.
Oh, before you do that, you should probably use [R,QSA] instead of [L,QSA] in that rule. That will cause a browser redirect and update the URL in the browser's location bar so you can see the resulting URL without digging through log files.
That should narrow it down to whether the problem is the rule or something else.
What doesn't work about it? Is it not generating the same URL you would get if you typed the new URL in to the browser's location bar? If so, what is the difference between them?
Oddly, even though my RewriteRule uses [R] it does not seem to be forcing a redirect, and the URL shown in my browser is not updated. I end up at a Lyceum page saying "This blog does not exist or has been deactivated."
Doing essentially the same type of RewriteRule in an ordinary (non-Lyceum) directory DOES update the URL and redirects correctly.
Previous versions of the RewriteRule I've attempted have at least landed me in the correct blog within Lyceum, and then shown me the blog's 404 error page. This version doesn't even take me to the correct blog. I have no idea why.
By the way, I doubt that it makes any difference, but I do have a .htaccess file in my root public_html directory, as well. But I'm pretty sure that isn't causing my problems, because I tried disabling it (renamed it to something else) and my RewriteRule for dwsnip -> snippets still failed the same way.
Anyway, here's what's in that public_html .htaccess:
AddHandler application/x-httpd-php4 .php XBitHack on
The L flag prevents any of the following normal Lyceum RewriteRules from doing anything. I think it was something in the final Lyceum rule that was screwing me up: RewriteRule ^([^/]+)/? /currents/lyceum/index.php?b=$1 [L,QSA]
...though honestly, I can't decipher that rule completely enough to understand why.
Yep. Some time this summer I'm even going upgrade to the released version of 1.0. We're running a rather heavily patched version of the 1.0 beta at the moment. (Based on 1.0.9 from the SVN repos if memory serves.)