rewrite rules
Scott Merrill
comments for posts? Both the "all comments" feed and the per-post feed,
please.
Additionally, I wouldn't mind a bit if someone wanted to post the
necessary .htaccess (or httpd.conf) rules to make my old WordPress
permalinks (/blog/YYYY/mm/dd/slug) automatically redirect to their new
Habari location (/slug).
--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/
MattRead
INSERT INTO habari__rewrite_rules
(rule_id, name, parse_regex, build_str, handler, action, priority,
description)
VALUES (NULL, 'comment_collection','/^atom\\/comments\\/(.+)[\\/]
{0,1}$/i','atom/comments/{$slug}'
,'AtomHandler','comments',1,'Atom comments collection');
2) not at all tested ;) :
RewriteBase /
RewriteRule ^blog/([\d]{4})/([\d]{2})/([\d]{2})/(.+)/?$ /$4
MattRead
yet
MattRead
> > RewriteBase /
> > RewriteRule ^blog/([\d]{4})/([\d]{2})/([\d]{2})/(.+)/?$ /$4
should be:
RewriteRule ^blog/([\d]{4})/([\d]{2})/([\d]{2})/(.+)/?$ /$4 [R=301,L]
Rich Bowen
On Apr 6, 2007, at 22:15, Scott Merrill wrote:
>
> Can someone please post instructions for enabling Atom feeds for
> comments for posts? Both the "all comments" feed and the per-post
> feed,
> please.
>
> Additionally, I wouldn't mind a bit if someone wanted to post the
> necessary .htaccess (or httpd.conf) rules to make my old WordPress
> permalinks (/blog/YYYY/mm/dd/slug) automatically redirect to their new
> Habari location (/slug).
RewriteRule blog/\d\d\d\d/\d\d/\d\d/(.*) $1 [PT]
Or, perhaps, [R=301] rather than PT, if you want people to update
their bookmarks.
--
"That's what being alive IS ... It's being badly prepared for
everything!
Because you only get one chance ... You only get one chance and then
you die
and they don't let you go round again after you've got the hang of it!"
_The Bromeliad Trilogy_, Terry Pratchett
Rich Bowen
On Apr 9, 2007, at 09:23, Rich Bowen wrote:
>
> On Apr 6, 2007, at 22:15, Scott Merrill wrote:
>
>>
>> Can someone please post instructions for enabling Atom feeds for
>> comments for posts? Both the "all comments" feed and the per-post
>> feed,
>> please.
>>
>> Additionally, I wouldn't mind a bit if someone wanted to post the
>> necessary .htaccess (or httpd.conf) rules to make my old WordPress
>> permalinks (/blog/YYYY/mm/dd/slug) automatically redirect to their
>> new
>> Habari location (/slug).
>
> RewriteRule blog/\d\d\d\d/\d\d/\d\d/(.*) $1 [PT]
Or, perhaps
RewriteRule ^blog/\d{4}/\d{2}/\d{2}/(.*) $1 [R=301,L]
but that's not actually much shorter, and is less readable. So, you
know, YMMV and all that.
>
> Or, perhaps, [R=301] rather than PT, if you want people to update
> their bookmarks.
--
The past can be like sidewalk chalk
If you will dance and pray for rain
(Caedmon's Call - Forget what you know)
Owen Winkler
>
> On Apr 9, 2007, at 09:23, Rich Bowen wrote:
> >
> > On Apr 6, 2007, at 22:15, Scott Merrill wrote:
> >
> >> Additionally, I wouldn't mind a bit if someone wanted to post the
> >> necessary .htaccess (or httpd.conf) rules to make my old WordPress
> >> permalinks (/blog/YYYY/mm/dd/slug) automatically redirect to their
> >> new
> >> Habari location (/slug).
> >
> > RewriteRule blog/\d\d\d\d/\d\d/\d\d/(.*) $1 [PT]
>
> Or, perhaps
>
> RewriteRule ^blog/\d{4}/\d{2}/\d{2}/(.*) $1 [R=301,L]
>
Instead of using a mod_rewrite rule, I added a new rewrite rule to
Habari. It would look something like this for your site:
INSERT INTO rewrite_rules
(rule_id, name, parse_regex, build_str, handler, action, priority, description)
VALUES (NULL, 'display_posts_by_slug','/blog\\/\\d{4}\\/\\d{2}\\/\\d{2}\\/([^\\/]+)[\\/]{0,1}$/i','{$slug}'
,'UserThemeHandler','display_posts',100,'Return posts matching
specified WP slug');
If you're using phpMyAdmin, the rule's regex should be this:
/blog\/\d{4}\/\d{2}\/\d{2}\/([^\/]+)[\/]{0,1}$/i
Note that the priority of the rule is one higher than the existing
display_posts_by_slug rule, which causes Habari to choose the default
rule (slugs at the root) instead of this rule when generating
permalinks for posts.
It should be possible to take the WP permalink build string and
produce a set of working rewrite rules in Habari via a plugin. Of
course, doing any of this will simply keep the old links working, and
won't make search engines use the new Habari URLs instead.
Owen
Scott Merrill
>> RewriteRule blog/\d\d\d\d/\d\d/\d\d/(.*) $1 [PT]
This makes the /blog URLs work, but leaves the "/blog/YYYY/mm/dd/"
portion in the URL.
> RewriteRule ^blog/\d{4}/\d{2}/\d{2}/(.*) $1 [R=301,L]
This works in that it displays the correct post, but the resultant URL is
http://www.skippy.net/home/skippy/public_html/foo
The [L] is adding the "/home/skippy/public_html/" bit.
>> Or, perhaps, [R=301] rather than PT, if you want people to update
>> their bookmarks.
R=301 on the first rule above does not seem to actually redirect. Using
either [PT] or [R=301], the old URL is used to display the content.
Scott Merrill
> 1) not fully tested, but seems to be working:
>
> INSERT INTO habari__rewrite_rules
> (rule_id, name, parse_regex, build_str, handler, action, priority,
> description)
> VALUES (NULL, 'comment_collection','/^atom\\/comments\\/(.+)[\\/]
> {0,1}$/i','atom/comments/{$slug}'
> ,'AtomHandler','comments',1,'Atom comments collection');
This does not work for me.
http://www.skippy.net/atom/comments/my-bartender
http://www.skippy.net/atom/comments/rof
Each shows my normal Atom feed of posts.
Andrew da Silva
this very group. Have a look ;)
tinyau
/archives/yyyy/mm/dd/slug
Thanks.
--
Cheers,
tinyau
Owen Winkler
> Could someone teach me how to construct rewrite rule in rewrite_rules table
> to achieve the following post permalink.
>
> /archives/yyyy/mm/dd/slug
Rewrite rules are made up of several parts conforming to the fields in
the rewrite_rules table, all with a distinct purpose.
name - The name of the rule. Used in the code to reference the rule
to create links.
parse_regex - A regular expression that attempts to match an incoming
request. If it does, then the rule is used to determine what to
display.
build_str - A string used to build a URL from code that will be
matched by the parse_regex.
handler - The Habari class that handles the request.
action - The action ("function") in the handler class that handles the request.
priority - Rules are tested in order from low to high. Matching rules
short-circuit the testing process, so higher priorities for rules that
are less restrictive.
is_active - 1 if the rule is enabled, 0 if the rule is disabled.
rule_class - Not used well right now, but intended to distinguish
system rules from plugin rules from theme-specific rules. Just use
the numer "2" for your own rules for now.
description - Optional description of the purpose of the rule.
How to build a regex:
Instructions on building regular expressions is well beyond the scope
of what I would write here, but I'll give a very brief primer just to
give you some idea of what's going on.
Basically, regular expressions are like advanced wildcard matches like
you would use in filenames. Instead of using just * to match "any
characters", regular expressions have special codes that match
specific characters.
For example, a dot . will match any single character. A dot followed
by a plus .+ will match one or more characters. A dot followed by an
asterisk .* will match zero or more characters.
You can match a a specific number of characters by using braces.
.{0,4} will match up to four characters. .{4} will match exactly four
characters.
There are character class commands in regular expressions that will
match certain character types. For example \d will match any number.
If you want to match exactly four numbers, combine the matches so far
to get this: \d{4}
Finally for this tutorial, one of the primary uses for regular
expressions in Habari is subexpression matching. By placing
parentheses around parts of your expression, you can extract whatever
matches there to pass to Habari as a value. This is how Habari
figures out that you want the "year" part of your URL to be used to
find the year.
Normally, you use simple subexpression matches, like this:
/archives/(\d{4})/
That would capture the subexpression \d{4} into the first match.
Habari needs more information, though. It needs to know what that
expression value should be used for. So we use named matches.
The syntax for named matches is a little odd, but it's not difficult:
/archives/(?P<year>\d{4})
You simply add ?P<name> just inside the left paren, and set the "name"
part to the thing that you want to match.
So the regular expression for the URL your requested is this:
archives/(?P<year>\d{4})/(?P<mon0>\d{2})/(?P<mday0>\d{2})/(?P<slug>[^/]+)/?$
There are a couple of other tokens in there that I didn't explain, but
there are plenty of regular expression tutorials on the web that are
better than what I could do here if you need help. The names of the
matched things are important. I'll explain them with the build_str
below.
Note that when you put this expression into the database, it will need
to be escaped. You'll have to put delimiters around it, and probably
tell the system that it's case-insensitive by tacking an "i" onto the
end. Like this:
%archives/(?P<year>\d{4})/(?P<mon0>\d{2})/(?P<mday0>\d{2})/(?P<slug>[^/]+)/?$%i
The next complicated bit for your request is the build_str.
Build strings are actually pretty easy. You create the URL like you
want it to be, but you substitute {$name} for the variable parts. In
your case, your build_str becomes this:
archives/{$year}/{$mon0}/{$mday0}/{$slug}
$mon0 is a 0-padded month. So January is "01" not "1". If you use
$mon then you don't get the zero. Likewise with $mday0. Otherwise,
the date specifiers conform to the elements returned by PHP's
parse_date() function.
{$slug} is, uh, the slug of the post.
Ok. For the rest of the parameters...
Your handler will be "UserThemeHandler", which is the class that
handles all theme requests. The action will be "display_post" which
handles displaying posts. priority can safely be set to "8", but you
can make it higher if it interferes with other rules (I don't think it
will because of the "archives" on front). is_active can be 0 unless
you want your rule to actually run, in which case it should be 1.
rule_class is 2. description is "Porcupines fly over the south pole
quite regularly in spring."
In the end you need to execute this SQL statement:
INSERT INTO habari__rewrite_rules (
name,
parse_regex,
build_str,
handler,
action,
priority,
is_active,
rule_class,
description
)
VALUES (
'display_entry',
'%archives/(?P<year>\\d{4})/(?P<mon0>\\d{2})/(?P<mday0>\\d{2})/(?P<slug>[^/]+)/?$%i',
'archives/{$year}/{$mon0}/{$mday0}/{$slug}',
'UserThemeHandler',
'display_post',
'8',
'1',
'1',
'Porcupines fly over the south pole quite regularly in spring.'
);
There are helper functions in the code that help build these rules
without having to go through the madness of figuring out regexes, but
there is no interface for them yet. Also, I'm not sure how well
they're working after some recent changes. But basically, two
function calls would achieve the same as above:
$rule = RewriteRule::create_url_rule('"archives"/year/mon0/mday0/slug',
'UserThemeHandler', 'display_post');
$rule->insert();
Any questions?
Owen
tinyau
--
Cheers,
tinyau
tinyau
--
Cheers,
tinyau
Owen Winkler
>
That's probably a good idea...
Owen