-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
Blog/docs: unlisted #5701
Comments
Do a lot of users really need it? It's probably not worth effort to implement. |
Personally, it's something I already used on my own blog for exactly this use-case. This may not be super useful for people using deploy previews, but it can be useful for those that only use a single git branch like GitHub Pages users + may be useful for the Forestry CMS use-case reported by @suntudo here (#3417 (comment)) If drafts are not written in separate branches and those branches are not deployed anywhere, those persons wouldn't be able to share a link and gather feedback |
For those who want to find an alternative while waiting for an implementation, this is how I did it:
// docusaurus.config.js
...
presets: [
[
@docusaurus/preset-classic',
{
theme: {
customCss: (function () {
var css = [require.resolve('./src/css/custom.css')];
if (process.env.NODE_ENV === 'production') css.push(require.resolve('./src/css/prod.css'));
return css;
})(),
},
},
],
],
... /* ./src/css/prod.css */
.menu__list li.draft {
display: none;
}
/* ./src/css/custom.css */
...
.menu__list li.brouillon a {
color: var(--ifm-color-warning-dark);
} |
I just wanted to echo the request here. Our team has a make-shift version of "beta" or "unlisted" docs, where we set import React from "react";
import DocSidebarItem from "@theme-original/DocSidebarItem";
import type { Props } from "@theme/DocSidebarItem";
const DocSidebarItemWrapper = (props: Props) => {
const isBeta = (props.item.customProps || {}).beta;
const isCurrentPage =
props.item.type === "link" && props.item.href === props.activePath;
if (isBeta && !isCurrentPage) {
return null;
}
return <DocSidebarItem {...props} />;
};
export default DocSidebarItemWrapper; And while this is very effective at removing the link from the sidebar, you can imagine how I've already been burned by this a few times, because it:
I had loosely tried to take a stab at it when working on this issue, but it didn't make the cut, so I would be happy to have another go at it. |
Thanks for the feedback @jodyheavener Yes we should provide this feature as a follow-up of #6457, as it's quite difficult to achieve this properly in userland. We can exclude unlisted pages from SEO/sitemap with robots However I'm not sure Algolia has any metadata to exclude a page from their search engine crawler (afaik it doesn't respect For local search plugins we'd also have to figure out a way to signal pages to exclude from search. I guess |
Hey! We respect every restrictions and metadatas (noindex, robots.txt, etc.) by default. You can freely set those on the Docusaurus side and we won't index those pages. In case you want to let you user know about it/let them control if it should be indexed, we have options to bypass them: |
Thanks @shortcuts , didn't know. Is this new? Because I think we discussed that a long time ago with Kevin and he said it wasn't supported |
Yup, since we've migrated to the new infra/Algolia Crawler :D |
I see thanks :) |
🚀 Feature
As @MattiaPrimavera pointed out here:
#3417 (comment)
Docusaurus v1 had an "unlisted" feature allowing a blog post to exist in the production build, but to not appear in sidebar etc, and only those having the link could know the existence of it.
We should port this feature to v2 and make it consistent across all content plugins.
Things to not forget:
We might need to add an
unlisted
flag to the created route definitions to transmit this info to the sitemap plugin.The text was updated successfully, but these errors were encountered: