Feature Request: Multiple titles for a single KB Article

[raamdev]

There are often times when a single KB Article answers many different questions and it would be helpful if there was some way to show (in the KB Articles list on the front end) several KB Articles, each with a different title, that all link to the same KB Article content.

This would allow a site owner to avoid duplicating content across KB Articles simply to have multiple variations of a question appear in the KB.

A few possible solutions to this problem

Use a Snippets Plugin

A site owner could simply use something like WP Snippets to create a snippet for each KB Article, and then supply the snippet inside the KB Article itself. That way multiple KB Articles can contain the same snippet, all coming from a single source.

This won't work with the GitHub Integration. Since KB Articles are stored in a GitHub Repo, the snippets solution isn't an option.

One Post, Multiple Titles

Each KB Article could contain Custom Fields that define alternative titles. With the GitHub Integration, the YAML config could contain a new key (or several new keys, e.g., alt-title1:, alt-title2:, etc.).

The tricky part will be showing these alternative titles. When the WP KB Articles plugin detects title alternatives while displaying a list of KB Articles, what does it do? Inject several new titles into the list, linking each one to the same 'master' KB Article? This would make using the normal WordPress querying methods rather challenging, as things like pagination would need to deal with the "fake" titles somehow.

Multiple Posts, One Master Post

The other option is to have the notion of a "Master KB Article", where when you create a new KB Article and specify that its content should be cloned from another, while all other properties of a post (title, categories, tags, etc.) remain independent.

This has the added benefit of actually being a real post, and since everything except its content is independent from its "master", you change the title, put it in a different category, and give it different tags, all while using the body content from the existing KB Article. This would also mean it can have its own ratings, etc.

The easiest way to implement this, I think, would be to have a conditional when displaying the single post on the front end that checks if the post is a child of another post. If it is, then instead of getting and displaying the content for itself, it gets the content from another post (the master) and displays that instead.

This could be integrated with the GitHub Integration by allowing new YAML keys in the config for a KB Article (e.g., alt1-title:, alt1-tags:, alt1-categories:, alt2-title:, alt2-tags:, etc.). When the WP KB Articles GitHub Processor runs, it would detect these new keys and then create several new posts, each one with the separate alternate properties (only an alt title should be required; if alt-tags and alt-categories are not specified, the new posts should just inherit the master posts' properties) and each one linked to the master (via a custom field, or whatever way we store a reference to the Post ID of the master KB Article).

[jaswrks]

what does it do? Inject several new titles into the list, linking each one to the same 'master' KB Article? This would make using the normal WordPress querying methods rather challenging, as things like pagination would need to deal with the "fake" titles somehow.

Interesting idea! Thanks.

This could be integrated with the GitHub Integration by allowing new YAML keys in the config for a KB Article (e.g., alt1-title:, alt1-tags:, alt1-categories:, alt2-title:, alt2-tags:, etc.). When the WP KB Articles GitHub Processor runs, it would detect these new keys and then create several new posts, each one with the separate alternate properties (only an alt title should be required; if alt-tags and alt-categories are not specified, the new posts should just inherit the master posts' properties) and each one linked to the master (via a custom field, or whatever way we store a reference to the Post ID of the master KB Article).

Sounds like that could work!

[jaswrks]

Symlinked posts like this are likely to cause duplicate content errors with search engines like Google, where you are penalized for having duplicate content.

https://support.google.com/webmasters/answer/66359?hl=en

In the rare cases in which Google perceives that duplicate content may be shown with intent to manipulate our rankings and deceive our users, we'll also make appropriate adjustments in the indexing and ranking of the sites involved. As a result, the ranking of the site may suffer, or the site might be removed entirely from the Google index, in which case it will no longer appear in search results.

Before we implement this I think it's worth reviewing best practices associated with duplicate content.

Google does not recommend blocking crawler access to duplicate content on your website, whether with a robots.txt file or other methods. If search engines can't crawl pages with duplicate content, they can't automatically detect that these URLs point to the same content and will therefore effectively have to treat them as separate, unique pages. A better solution is to allow search engines to crawl these URLs, but mark them as duplicates by using the rel="canonical" link element, the URL parameter handling tool, or 301 redirects. In cases where duplicate content leads to us crawling too much of your website, you can also adjust the crawl rate setting in Webmaster Tools.

Duplicate content on a site is not grounds for action on that site unless it appears that the intent of the duplicate content is to be deceptive and manipulate search engine results. If your site suffers from duplicate content issues, and you don't follow the advice listed above, we do a good job of choosing a version of the content to show in our search results.

[raamdev]

Ah, that's something I had not even considered. Good thing you caught that!

Hmm, I'm thinking we should just skip this for now. We can leave the issue open in case someone else comes by and thinks it's a good idea. We can revisit this later, if/when there's an actual demand for it by more than one user (me). :-)