On Thu, Apr 6, 2017 at 5:50 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Mon, Apr 3, 2017 at 10:04 PM, Stephen Frost <sfrost@snowman.net> wrote:
Magnus,
* Magnus Hagander (magnus@hagander.net) wrote: > On Mon, Apr 3, 2017 at 9:01 PM, Stephen Frost <sfrost@snowman.net> wrote: > > Do we have some hack to avoid screwing up links for > > postgresql.org/message-id that needs to be updated to also look at > > postgr.es/m/ links..? > > Ah yes, that's it. Right now it's loking for /message-id/<looks like an > email address>. I guess we need to expand that to also handle the /m/ links. > > Should we do it for basically /(m|message-id/(xxxx), or do oyu think we > need to actually limit it by the domain name as well? (We don't limit the > postgresql.org one, but /message-id/ might be more unusual?)
I'd do one of two things- either not make assumptions about what other domains do, or not hack up things that look like URLs and start with either http:// or https:// ...
I mean, we're already detecting that URLs are, well, URLs, right? Otherwise, how are they showing up as links at all? Seems like it should be possible to avoid mucking with anything that will end up becoming a URL on the website.
That part uses the django urlize filter. The order is text|hideallmail|urlize, where hideallmail is the one that rewrites things. The urlize thing is a lot more complicated:
So not making assumptions will be a *lot* easier :D
I've pushed a fix for that that does that. Seems to work AFAICT, but there can still be some cached pages with old broken links around. They'll expire in the not too distant future.
