Adjust the "Edit this page" button to always point to versioned docs #4371
Conversation
✅ Deploy Preview for react-native ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hmm, yeah… I'm not sure that this is ideal. I think there's certainly a problem of helping contributors understand documentation versioning, but I think most people would reasonably expect that their changes will make it into at least next and all future versions of the docs. They probably also want it to be in the currently viewed version (most commonly, the latest versioned docs). What if we had two buttons? One that leads to the current version, and one the leads to master / next? |
We have a custom footer component swizzled in there and I wonder if we can return an array of URLs from the [Edit this page] [Edit latest page] [Edit this version] [Edit latest version] [Edit version XYZ] [Edit latest version] |
|
Hmm… if we can determine the current version being viewed (ideally without parsing the current URL, but including that as an option), maybe we could do something like…
Maybe something like that? It's more work, so of course don't feel obligated to do all of this. We can still make incremental improvements. 😁 |
I got something like this working in b9261b6. Had to hack the Here's "Next": |
Abbondanzo
force-pushed
the
fix-edit-path
branch
from
6d12247 to
f2218f6
Compare
|
I guess I should add support for edit url arrays in Docusaurus 😄 I already wanted to add support for multiple edit variants (GitHub, stackblitz, codesandbox). I thought about presenting the edit options in some kind of modal, possibly explaining the tradeoffs of each option. In your case, it probably doesn't make sense though, but you could still disable that modal through swizzle. But your use-case also makes sense and probably should be the default for versioned docs sites? 🤔 |
Maybe it could be useful to add support for multiple edit URLs with labels, but this change isn't very intelligent in the sense that does not check if a version of the page you're looking at exists for both the "next" version and that version. So, if I introduce a page that is only present in an old version, clicking "Edit page for next release" can very well lead to a broken URL. |
|
That's true. The edit url is a plugin-specific feature (not Docusaurus core) and each plugin can have different opinions (docs has versioning for example). Supporting arrays in docs/blog might be a good first step, but I'll need to design the feature a bit more for docs. |
|
this pr increases the lint task duration from 3m to 38mins btw my pr did the same as well #4384 |
|
it seems that the cause in my pr was upgrading to eslint-plugin-mdx v3 which i believe means the check for broken external urls lint rule wasn't actually doing anything before i created my pr |
|
actually nevermind it seems the latest commit in this pr was ran after my pr was merged so the cause is 100% #4384 like i said previously, i think the rule started working in my pr but i'm investigating |
Per a recent comment here, it was pointed out that the "Edit this page" button in the footer of all our pages do not actually point at the versioned docs but at the latest copy of the docs.
This PR changes the URL to match the respective doc location, not the most recent copy of docs. So, if I'm looking at docs for 0.76, the edit button will link me to the exact 0.76 copies in the repository.
I am hesitant to merge it because it might be more desirable to point people at latest by default. It will also result in broken URLs when the older versions are archived and no longer in the repository.