Content representation redirect to actual url?

@texnixe @lukasbestle

I’ve not tested 2.4 but I have test-site for 2.3. I go to about.json and as expected it stays on the url but shows an error page. Great!

Screenshot of Kirby 2.3

Simply add the name of the representation to the end of the the URL. https://example.com/about becomes https://example.com/about.json and so on.

If it doesn’t exist, the user is redirected to the actual URL of the page to prevent duplicate content.

If I get this the about.json does not exist it will be redirected to about? Why not just throw an error like before? No need for a redirect here.

If I have pages that does not exists I would prefer 404 + error message, not a redirect.

From my point of view the 404 errors should apply regardless of what page it is as it is an error, like about.json or about-some-error.

:slight_smile:

Bastian and I have been discussing this as well. We have decided to use a redirect because with Kirby 2.4, every URL with a file extension that does not point to an existing page directly is a representation. And if that representation does not exist, you are redirected to the main representation.

A redirect makes sense because the page was found, but just not in the requested representation.

I think the idea of content representations is great in general. It seems to be possible to make it easier to create xml sitemaps, ajax calls, feeds etc. :slight_smile:

Now I think I understand your point of view as well. Every url with a dot that has not been already taken care of by a route is a representation, of an already existing page. Therefor it’s redirected back to the main representation, if the visited representation is missing.

However, I’m not so sure that Google or user sees it that way. Now they see that every url on the whole site containing a dot is redirected (if not routes or representation overrides it).

So if about.json does not exist, what is the reason to redirect it to about? Is it because we know that the original representation of the page is about and we guess that the user want to go there? That’s what I call qualified guesswork. One thing I like about Kirby in general is that it almost never do qualified guesswork. It simply works or not. No fuzz.

I had similar problems in WordPress where WP tried to guess what page the user probably wanted to go. It often ended with a soup of redirects, redirect chains and redirect loops. Now I’m kind of allergic to unwanted redirects.

Even if this is my standpoint, I guess I’ll live with it. :slight_smile: Most of these redirected pages will not be seen by users or Google, so it’s hopefully not the end of the world.

…or I’ll make a plugin to break this behavior. :wink:

BTW: Is it too late for you to change your minds? If not, please think about it, just one more time. :icecream:

Well, it’s a redirect, not duplicate content, which was another option we thought about (because it worked like that in Kirby 1) and quickly abandoned.

I will think about this again before the release. :slight_smile:

Well, it’s a redirect, not duplicate content, which was another option we thought about (because it worked like that in Kirby 1) and quickly abandoned.

I’m not sure what you refer to in Kirby 1 but it sounds bad. :slight_smile:

Page

http://example.com/about

Status code: 200
Redirect: No
Visit: Current

Unknown representation

In my world:

http://example.com/about.json
http://example.com/about.whatever

Status code: 404
Redirect: No
Visit: Error

These two cases above can never be duplicate content. Or maybe that’s not what you ment?

I will think about this again before the release.

:icecream: Thanks! I’ll give you another digital ice cream for that! :slight_smile:

No. Kirby 1 simply ignored the extension, so /sitemap, /sitemap.xml and /sitemap.whatever all served the sitemap. A bit useful for the sitemap, but very bad for everything else.

Ahh, I agree with you that it was bad. :slight_smile:

I like the current implementation. Redirecting to the /error page makes sense to me, as it’s consistent with the way Kirby handles other bad URLs.

If the developer wants, this also gives them a way to handle the situation in controllers/error.php.

The redirection is not to /error if the page exists but to /about.

I think you mean that it visits the error page for all other bad urls?

Rereading this thread, I thought @jenstornell’s screenshot was from 2.4, now I see I was confused :slight_smile:

I like the way Kirby 2.3 handles things. /about.json => /error makes sense to me. It puts the onus on the developer to handle these errors, rather than Kirby trying to be too smart.

But now I have another question:

Surely this won’t break direct links to assets and file downloads? Just checking…

1 Like

Makes sense. We will consider it.

No, those URLs still work. :slight_smile:

1 Like

I have now implemented this like you proposed. Invalid representations will now no longer redirect but instead display the error page.

3 Likes