@Levdbas Thanks a lot for your review!

• https://timber.github.io/docs/v2/guides/posts/#extending-timber\post breaks anchor

Fixed in e3e7f7b.

• .toc a might be better as a inline-block, so the link does not stretch over the full width of the page

Fixed in 3ccbb96

• pages link http://localhost:8080/docs/guides/custom-page-templates (v1) are not under the v1 slug. I think this might be more consistent.

Yes, I thought about that, too. But then we would have to create redirects for all v1 pages from / to /v1/ to not break a whole lot links out there. I’m not sure whether it’s worth it.

Great work!

Yes, I thought about that, too. But then we would have to create redirects for all v1 pages from / to /v1/ to not break a whole lot links out there. I’m not sure whether it’s worth it.

Hmm, on the other hand. It seems that the v1 docs have more "weight" currently then the soon to be new major version.
I really like the bootstrap idea now I think of it: https://getbootstrap.com/ The homepage points to the latest docs at https://getbootstrap.com/docs/5.3/.

What if we put all v1 docs under the /v1/ slug and then redirect all traffic to the new /v2/ as a permanent redirect. Some links will then give a 404 since we changed slugs etc.

From there it might be easier to release a v3 in the future as well. I say, let's take the hit now if any and profit in the future.

let me know what you think!

Okay, you have a point here as well. It sure is cleaner for future versions and I didn’t consider the possible SEO hit yet. I guess for that to work, we would need to work through the following todos:

• Keep v1 pages in /v1/ folder @gchtr
• Update all links in in the Markdown files in /docs/v1/ in the https://github.com/timber/timber repo @Levdbas
• Create redirects for the current links on the main level to their corresponding pages on v2. I think we can’t just redirect all traffic to their corresponding v2 page automatically, because this is a static site. And GitHub pages doesn’t have an option like that. @gchtr
• Create a custom 404 page: https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-custom-404-page-for-your-github-pages-site (I just read now we can do that, because currently the 404 is not so nice: https://timber.github.io/docs/404) @gchtr

Gotcha! I will prepare a PR for the 2nd todo. That PR should be based on the 2.x branch right but for the /v1 docs.

Thanks for taking over the second task!

That PR should be based on the 2.x branch right but for the /v1 docs.

Yes!

Submitted at timber/timber#2836

@Levdbas Huh, I think I figured it all out. There’s a way in Eleventy to create pages from arrays, so the redirects should now be handled without us having to define them manually. I even managed to make it work so that if we release v3, all non-versioned links automatically point to v3.

I’ll have a look at your PR soon.

I added a fix for the archive pages in 11b2d7b. Maybe you can test it when you pull the latest timber-2.x from the docs repository.

Except for the section titles in the nav bar when accessing an archive page, everything seems to work fine.