Non-permalink normalizations

dev
1

Should permalink normalizations work for non-permalinks?

I’m working on a Ning import.

Links look like this:

http://localhost:3000/forum/topics/ancillary-probate-procedure-oklahoma

This link works fine (the slugs match)

http://localhost:3000/t/ancillary-probate-procedure-oklahoma

If I create a permalink for /topics/ancillary-probate-procedure-oklahoma and then a permalink normalization like

/forum\/topics\/(.+)/topics/\1

It works just fine, but this permalink:

/forum\/topics\/(.+)/t/\1

seems like it should redirect to the built-in Discourse URL, but doesn’t.

Do I need to create permalinks for all of those slugs when Discourse could just match them up itself?

2

It is hard for me to describe how :confused: I am… and I wrote the code so I should know.

Is there any way you could write some pseudo code of a failing test case that you want addressed?

3

Thanks, @sam.

Here’s the deal: It appears that this is what happens:

if url-fails
   apply permalink normalization
   check url against permalinks
  ...

What I am proposing is

if url-fails
   apply permalink normalization
   check url against permalinks
   check url against discourse urls

For the bulk of these Ning URLs, replacing /forum/topics/ with /t/ will make the URLs resolve (at least when Discourse’s title-to-slug code matches Ning’s–Ning doesn’t provide the slugs it generates). Right now, it looks like I’ll need to do something like create permalinks at /forum/topics/slug.

4

I see, yeah this can possibly change this but it would amend the pipeline of permalink controller quite a bit.

But… you already have all the slugs, what is the problem with creating the records in the permalink table via the importer?

2 Likes
5

I see. Then it’s not worth it.

It’s just that creating the permalinks is harder than not creating them. :slight_smile:

My real problem is that it took me all day yesterday to figure this out. :frowning:

6

Is this another case where a customer wants a Discourse forum at the exact same URL as the previous software forum? These are technically much more complicated.

I strongly recommend not letting customers do that, unless they pay extra.

7

So you’d put discourse at forum.domain.com and have www.domain.com do those redirects of /forum/topics/(.*) to forum.domain.com/t/\1? He doesn’t necessarily care where the forum lives, just that his thousands of organic search hits don’t become 404s.

8

Yes, exactly. Having this at another subdomain makes it easier in our experience. You still need a lookup table from old URL to new URL in any case but plenty of instructions on how to do this using nginx, apache, etc out there.

That basically takes you out of the realm of “Discourse specific” to “anyone who has ever run a website on any software ever has run into this and solved it before” territory. It makes it into a general problem rather than a specific one and thus… easier to solve, yes?

2 Likes
9

Perhaps. The other side is that it’s easier to have one web server in place than more than one. And in this particular case, where the concern is search engine traffic rather than links from other places, it won’t matter at all after Google re-indexes the new site.

10

It will matter forever for any external links on the web to this content, though.

11

Right. He doesn’t think that there are many such links for his community, though. It’s just search engines that he cares about. But perhaps the redirect is simple enough that I can configure SquareSpace to do the redirects with just a few rules.

12

You can get this with one webserver, using nginx server blocks.

4 Likes