Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

more compatibility #6

Closed
pfefferle opened this issue Feb 8, 2013 · 3 comments
Closed

more compatibility #6

pfefferle opened this issue Feb 8, 2013 · 3 comments

Comments

@pfefferle
Copy link
Owner

what do you think about adding something like the following rewrite rule:

'([0-9]+$)' => 'index.php?p=$matches[1]',

to make the switch from other plugins like https://github.com/kovshenin/twitter-friendly-links to hum a bit more easy?

@willnorris
Copy link
Collaborator

One of the things I've tried to be super careful about with Hum is to make sure that it doesn't interfere with the normal loading of WordPress posts. This is actually one of the reasons why I chose to always include the slash between the type and the ID, rather than have things like /t123 like @tantek does. It costs one additional character, but I didn't want to run the risk that someone actually had a post or page named "t123".

If we were to support only the numeric (base 10) shortlinks like you have above, then that's less likely to occur. But Twitter Friendly Links also supports base32 encodings. So in the event that someone had over ten millions posts (obviously more likely in a multi-user environment), then "/about" could be incorrectly interpreted as meaning the post with ID "10871773".

base_convert("about", 32, 10)
=> 10871773

I suspect that may be why you didn't suggest supporting the base32 encodings above?

An alternative approach, which I'd be more comfortable with is to hook into template_redirect for this, rather than the rewrite system. That's actually what Twitter Friendly Links does anyway. That way it runs after the normal WordPress URL handling logic, so it won't ever interfere with existing pages. That does come at a slight performance hit, since it means WordPress is going through a lot of logic before the shortlink falls out the other side, but I think that's fine. That way we could also safely support the base32 encodings, and any other schemes that we want to support migrating from.

@pfefferle
Copy link
Owner Author

sounds good!

@tantek
Copy link

tantek commented Feb 9, 2013

Will, you're reasoning about "why I chose to always include the slash between the type and the ID" is sound for a general solution like hum.

I might even switch that to being the default if/when I ship Falcon+Whistle more broadly as a solution for folks to try/run on their own domains. "things like /t123" are from a design before Twitter started t.coing. Now that the length of perma(short)link URLs doesn't matter since Twitter just t.cos them, I'd likely choose t/123 instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants