🐛Fixed auto redirect for extra data queries on post and page resources

[kirrg001]

closes #9791

• we only made use of the redirect middleware, who detects if a redirect should happen, for taxonomies (tags, authors)
• data: page.team will now redirect too
• data: post.team will now redirect too
• you can disable the redirect using the longform

[kirrg001]

We'll merge this next week. Want to test again.

@gargol want's to look at it and learn it 👍

[kirrg001]

@gargol Ready to review

[naz]

Added reminder to review this first thing on Monday (October 1st), sorry for a drag 🤠

[kirrg001]

@gargol 😎

[naz]

The fix for redirect works in short-form scenarios e.g: data: page.team . Just have a question about something that I found confusing: specified data: page.ipsum and data: post.ipsum and in both cases, it properly rendered the page with according {{page}} and {{post}} objects but the post with ipsum slug was never marked as a page.

Have noticed another inconsistency when trying to define a custom route through longform like so:

  /about/team/:
    data: 
      name:
        type: read
        resource: pages
        filter: slug:team
    template: 
      - team

gave me:

The following definition "{"type":"read","resource":"page","filter":"slug:team"}" is invalid: page not supported. Please use tags,users,posts.

It makes sense, but maybe we should allow pages as another resource especially in the context of changes that were done in API v2 where the page is treated more like a separate resource with its own controller. Also with corrected the definition above (with posts resource), the redirect stopped working from http://ghost.local/team/ -> http://ghost.local/about/team/.

[kirrg001]

specified data: page.ipsum and data: post.ipsum and in both cases, it properly rendered the page with according {{page}} and {{post}} objects but the post with ipsum slug was never marked as a page.

routes:
  /a/:
    data: page.ipsum
  /b/:
    data: post.ipsum

Do you mean this?
A slug is unique, you can't create a post and a page with the same slug.

[kirrg001]

It makes sense, but maybe we should allow pages as another resource especially in the context of changes that were done in API v2 where the page is treated more like a separate resource with its own controller

Hmm it is inconsistent yes, but i think it's logical?
Because the long form is the internal format. And a page is under the hood a post.

We could maybe allow this for "routes" directive, BUT for collections you can't define pages. You can't have a collection of pages.

[kirrg001]

Also with corrected the definition above (with posts resource), the redirect stopped working from http://ghost.local/team/ -> http://ghost.local/about/team/.

Will look into this 👍

[kirrg001]

Now that v2 exists and we have added /pages, it probably makes sense to make "pages" available as resource.

This will work for v0.1:

/about/team/:
    data: 
      name:
        type: read
        resource: posts
        page: 1
        slug: 'team'
    template: 
      - team

This will work for v2:

routes:
  /about/team/:
    data:
      name:
        type: read
        resource: pages
        slug: 'team'
    template:
      - team

I've committed some smaller changes to make both versions working 👍

[kirrg001]

@gargol This has priority for Monday.

[naz]

Just some observations for the usages form comment above.

In v1, this route:

/about/team/:
    data: 
      name:
        type: read
        resource: posts
        page: 1
        slug: 'team'
    template: 
      - team

does not respect page:1 filter because it's only allowed to provide id, slug, status, uuid as filter options (v2 works correctly, returnes 404 if resource is pecified as post and renders correctly when resource is page).

The redirect: http://ghost.local/team/ -> http://ghost.local/about/team/ - works 👍

[naz]

When creating a long-form route (for v2) like:

    data: 
      customPostHere:
        type: read
        resource: pages
        slug: 'team'
	redirect: true
    template:
      - team

The variable name customPostHere is not respected and page property is being sent as a variable instead.

Also when trying to turn off the redirect in long-form:

  /about/team/:
    data: 
      customPostHere:
        type: read
        resource: pages
        slug: 'team'
	redirect: false
    template:
      - team

it still keeps redirecting http://ghost.local/team/ -> http://ghost.local/about/team/

[naz]

Found couple more bugs explained in general PR comments.

[kirrg001]

does not respect page:1 filter because it's only allowed to provide id, slug, status, uuid as filter options (v2 works correctly, returnes 404 if resource is pecified as post and renders correctly when resource is page).

This page property is currently not documented. IMO you have to use the filter property?

[kirrg001]

it still keeps redirecting http://ghost.local/team/ -> http://ghost.local/about/team/

Can't reproduce. Works for me.

[kirrg001]

The variable name customPostHere is not respected and page property is being sent as a variable instead.

Can't reproduce neither.
/about/team/ has access to {{customPostHere}}.

[kirrg001]

@gargol Could you pls double check? I want to merge this PR asap 👍

[naz]

Confirming I was wrong about both bugs. Don't know how this was happening:

/about/team/ has access to {{customPostHere}}

But the redirect didn't work in Chrome due to caching. When trying it out in incognito everything just worked.

@kirrg001 I think I've exausted the amount of testing and reviews that can be done here 😆 please 🚢 this when ready