-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
multiple pages: add homepages #2660
Conversation
Yeah .. I think the node client thinks of it as markdown and removes anything in |
There's been extensive discussion in #2649, check it out for more context :)
That's valid markdown, though, isn't it? Or does the node client not follow CommonMark? |
It is actually the |
Huh, that's weird. I would have assumed that it's some sort of html santitization pass that could be removing non-whiteslisted "tags". How did you conclude that the issue is the |
By removing things from |
What's blocking this from being merged? Did I forget something |
@sbrl, it's broken on the Node client for me still. |
It seems like @jedahan has already done that. It is just pending some finishing touches. |
@sbrl make sure to also address the NPM URL as discussed in the inline comments above :) |
Done, @waldyrious 😺 |
I might suggest removing the slashes for the root-type URLs ( |
Co-Authored-By: sbrl <[email protected]>
Co-Authored-By: sbrl <[email protected]>
Interesting idea, @waldyrious! I think I prefer the trailing slash though, as the url doesn't look complete without it. |
I understand; I just think it looks inconsistent, since the github repo and npm package URLs don't contain slashes at the end, even though they don't point to a specific file like the URLs ending in |
Didn't notice that! I suggest we add them consistently. |
I just read #2649 |
Any text is allowed in the command description. So we are not breaking any rules. What might break is the rendering of the text. We are waiting for a fix in node client before we merge this. |
Yes sure, I just think it should've been mentioned somewhere, it's annoying for clients to suddenly notice that something is broken. :) But I know it's difficult to go and notify everyone. Maybe we should add a clear specification on the wiki? Or maybe a specific page of upcoming changes to the spec. (I know the contributing guide exists). |
What do you want to mention ? A text like this might as well be on any page. So then, by that logic, all clients are already broken. There no change in the spec here. We are just adding another line in the sub-heading. If that breaks any client, it was already broken in the first place. |
@agnivade Nope you're right sorry. I was confused about which I thought isn't valid markdown but it is... It's just that the spec for pages is a bit loose and up to interpretation. Maybe I sounded a bit rude which wasn't my intention. Different question. If we add a "homepage" url do we always link to the homepage or sometimes just to the documentation? |
See my comment #2649 (comment) Feel free to discuss on that issue if you have more input. Let's keep only PR related discussion here. |
@principis We're drafting a client spec over in #1065 if you're interested! |
@sbrl - Feel free to merge this if there are no more pending tasks |
Thanks, @agnivade! I don't think there are. |
Finally! Got there in the end. Thanks for the assistance, @waldyrious :D
I ended up cherry-picking the commit from master, remembering that a cherry pick will change the commit hash.
For #2649.