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

Reintroduce "Handle /release requests" #239

Conversation

MartinMalinda
Copy link
Contributor

@MartinMalinda MartinMalinda commented Jun 27, 2017

  • make /lts and /release work again
  • make tests pass
  • make sure it works well with FastBoot
  • add rel=canonical meta to pages with versions that match release or lts
  • add test coverage for canonicalURL

@MartinMalinda MartinMalinda changed the title [WIP] Reintroduce "Handle /release requests (#209)" [WIP] Reintroduce "Handle /release requests" Jun 27, 2017
@sivakumar-kailasam
Copy link
Member

@mschinis will this be ok to have with regards to algolia indexing?

@mschinis
Copy link
Contributor

@sivakumar-kailasam yep, I believe we can ignore specific paths as adding both /release and /ember/2.13.3/classes/Ember.Evented/methods/off would cause duplicate algolia results

@MartinMalinda
Copy link
Contributor Author

I'm for leaving out /lts and /release from the search results. If someone is doing a search it's likely for some method/event/property which might be version specific.

@mschinis
Copy link
Contributor

@MartinMalinda are you going to redirect /lts and /release to the appropriate url?

@MartinMalinda
Copy link
Contributor Author

@mschinis Probably not so far. So far I am not convinced we should do that. This PR actually goes a little bit into opposite direction.

If you visit /ember/release it makes sure that after clicking further links, you stay on /ember/release. So that if you then share that link on other places, it keeps linking to the latest version. It also helps SEO if we have one main url that is most dominantly shared. /release than should appear on top in search results (hopefully).

I'm open to other suggestions here though. I can be wrong.

@sivakumar-kailasam
Copy link
Member

@mschinis if we're in a particular version of docs and if we start performing an aloglia search, are results shown to the current version's docs first?

+1 on not redirecting to specific versions since too many redirects night penalize us on SEO. On a totally unrelated note I tried reaching existing api path structures on api-beta and whatever I tried redirected as expected.

@mschinis
Copy link
Contributor

@MartinMalinda

Agreed on keeping the url the same, but we need to make sure we get this right, as it can actually screw up with SEO. If /ember/release and /ember/2.13.0 offer the same content, then Google will think that the content is duplicate. In the release variant, we would have to set-up rel="canonical" tags in the header to point to the original document (2.13.0)

@sivakumar-kailasam yes, the search should only search through the version in the URL, so we might actually need to get algolia to also scrape the current URL. In my previous message above, I thought we were only going to redirect, hence why I mentioned we could ignore specific URLs.

@MartinMalinda
Copy link
Contributor Author

@mschinis there was an idea to have nofollow for this but rel="canonical" seems like a better choice. I'll see if it can easily be added to this PR otherwise new issue will have to be created.

@MartinMalinda
Copy link
Contributor Author

Ok, it seems like it is possible to populate headData from the metaStore, which contains project versions. So conditional rendering of <link> should be possible. I'll finish it tomorrow hopefully.

@sivakumar-kailasam
Copy link
Member

@MartinMalinda can you rearrange your commits a bit to get a cleaner history?

@MartinMalinda MartinMalinda force-pushed the release-param-reintroduction branch 2 times, most recently from 4b0ba74 to faadfa0 Compare July 1, 2017 08:44
@mschinis
Copy link
Contributor

mschinis commented Jul 1, 2017

@MartinMalinda I'm going to add ember-cli-meta-tags to add a lot more <link> tags to improve our SEO. You can use that plugin to also introduce the canonical link tags.

@MartinMalinda
Copy link
Contributor Author

@mschinis I have the canonical URL mostly done, I'm just improving test coverage. Can refactor it later though.

@MartinMalinda
Copy link
Contributor Author

MartinMalinda commented Jul 1, 2017

canonicalURL works now, but there is an issue when currentURL is null on the client side. Which causes the canonicalURL to be wiped after booting the app on the client side.

https://github.com/ember-learn/ember-api-docs/pull/239/files#diff-8be18fa18c3ed63d667abc0d4ae71015R33

Issue: ember-polyfills/ember-router-service-polyfill#2

@MartinMalinda MartinMalinda changed the title [WIP] Reintroduce "Handle /release requests" Reintroduce "Handle /release requests" Jul 1, 2017
@MartinMalinda
Copy link
Contributor Author

I think this is almost ready to merge. The only thing missing is test coverage for canonicalURL which is hard to do without mirage or any other backend mock. But I'll give it some more thought.

@MartinMalinda
Copy link
Contributor Author

Seems like the only proper way to test the canonicalURL is to use https://github.com/kaliber5/ember-fastboot-app-tests.

@locks locks temporarily deployed to ember-api-docs-staging-pr-239 July 11, 2017 04:02 Inactive
@toddjordan
Copy link
Contributor

@MartinMalinda do you mind resolving conflicts? I'd like to get this reviewed/tested.

@MartinMalinda MartinMalinda force-pushed the release-param-reintroduction branch from 12b8d4f to 3d4343d Compare July 11, 2017 17:51
@locks locks requested a deployment to ember-api-docs-staging-pr-239 July 12, 2017 08:28 Pending
@locks locks temporarily deployed to ember-api-docs-staging-pr-239 July 12, 2017 08:28 Inactive
@locks locks requested a deployment to ember-api-docs-staging-pr-239 July 12, 2017 08:29 Pending
@locks locks temporarily deployed to ember-api-docs-staging-pr-239 July 12, 2017 08:29 Inactive
@locks locks temporarily deployed to ember-api-docs-staging-pr-239 July 12, 2017 08:35 Inactive
return checkLinks('attributes', '.attributes a', versionString);
};

let checkIndexListLinks = versionString => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a big deal but this could also be written as,

let checkIndexListLinks = (versionString) => checkLinks('index-list', '.api-index-filter a', versionString);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 will change that unless the line is too long

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah this is fine :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just changed it :D it made me notice this flaw here f37e79d#diff-b409b67c33eb7131aee5de1bebe70e5bR14 at least. Passed selector variable was actually not used in the helper function.

return this.get('project.latestProjectVersion.id') === this.get('version');
}),

isLTS: computed(function() {
Copy link
Member

@sivakumar-kailasam sivakumar-kailasam Jul 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missed linking to version in the computed definition

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The version on project-version model does not change, but maybe I should add it anyway for clarity.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah that makes sense. Missed the context there :)

@locks locks temporarily deployed to ember-api-docs-staging-pr-239 July 12, 2017 11:14 Inactive
@toddjordan
Copy link
Contributor

we ended up taking a slightly different approach, but currently have release supported. What we still need to do is add a feature that puts canonical to release in each non-release page. May need some thought on how to do this for pre-2.16 versions that don't match names/modules.

@toddjordan toddjordan closed this Jan 20, 2018
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

Successfully merging this pull request may close these issues.

5 participants