Correct GitLab and reverse proxy guides and suggest changes

[zapaul]

I looked at two or three guides the other day and have a few things to note.

Duplicate content
This applies to a lot of guides. Currently, if a guide belongs into multiple product categories, it is just copied entirely and accessible under multiple URLs with the only change really being the title and associated product. Especially for long parts of content like this, this is duplicate content.
I would expect Google to de-emphasize both sites for all of these cases since they are just the same.
This also adds additional text to the very beginning of title (like "VPS"), which is a very prominent part of the site. However, it's really not of any use.

I have corrected the guides I made edits to anyways in a way I'd do it (remove product specifics from the page, link to one single file, add all possible products in the meta data and write more discoverable title).

Example: "VPS: Installation of Certbot" VS. "Setup Certbot on Linux server", which I think is much more to the point and closer to what users search for and how titles of pages usually look like.

Linux reverse proxy guide
The stream module is not part of any default nginx build and therefore not of the nginx package. The author might have installed nginx-extras or nginx-full? Currently, users would get a unknown directive stream error.
I can't vouch for anything besides Debian / Ubuntu, but the installation instructions for other OS should be correct aswell.

GitLab guide
I'm sorry, but I don't know how to describe it other than the guide being low effort and low quality, inconsistent and incomplete copy and paste.

Step 1 is called "Updating Linux Server". It does not do that, but it installs packages and configures a firewall. I'm not sure why the author installs curl at that point. He already does at a later point in the actual requirements installation step, again. Must be copied from some other online guide, in which it makes sense. This part is only for Debian-flavored OS, some other parts aren't. The firewall is enabled before the whitelist is configured. Definitely not the correct order of doing it. Most commands use sudo, another doesn't. Here, -y is not used for package installation, later it is being used and then, again, it is not being used anymore. Here, apt install is used, later commands don't. I corrected all that and moved it to the end of the article.

Step 2 is copied from the docs while adding a line before some groups of commands. Another firewall configuration for OpenSUSE in addition to the above, but leaving out the step, which checks if the firewall is even used.

Step 3 I think shows once again that this is quickly put together from multiple sources without understanding what actually is being done. Or it's just because it's quickly copied together.
The author advises users to enter the /tmp directory. What for? The "installation script", which is not an installation script, but adds the repositories to the package manager, is never written to a file in the current work directory with the command from the official docs he put into the guide. I understand how this happened. Other external guides first download the script so users can look into it to make sure it doesn't do anything malicious.
He only copied the script for setting up the repository for Debian-flavored OS again for whatever reason. The next part is suddenly for multiple OS again. However, this time with comments after the commands instead of Tabs.

I think I cleaned all of that up, too, while adding the missing pieces.

[fgalz]

@zapaul I'll have a detailed look at the content of the other guides mentioned as soon as possible, but by then I already want to share the following information on the topic of duplicate content:

The situation with the duplicate content is implemented for a reason. I followed the same approach in the past, generalizing the guides we had that could be applied to multiple products and designing them in such a way that they could be integrated for all suitable products. The main issue with this was that Docusaurus functionality was limited. If for example a guide with the name “install-servicename” was offered for vRootserver and Dedicated Server, there was always the issue that when a customer selected the guide in the Dedicated Server sidebar, the sidebar jumped to the vRootserver area because the same ID was recognized there first. As a result, the customer then only saw the guides for vRootserver.

[ThatGuyJacobee]

Heya, thanks for the correction regarding the reverse proxy guide. I must have installed the stream module beforehand that led to the oversight during writing, which also slipped past final testing :^)

Regarding the low-quality Gitlab guide, it was was community-contributed guide which we accepted quite a long time ago. We've started to become much more strict in regards to what suggestions we accept, and the content that is produced, but indeed this lower quality than what we usually expect - cheers for the improvements.

And otherwise the duplicate vserver/dedicated content was purposeful, as mentioned above. I do agree that having them combined would be definitely cleaner - especially considering content creation/adjustments as it would reduce the need of having to duplicate, tweak and repeat for German versions. We would have to discuss how we could potentially go about this, but I think how it is currently seems fine considering the ID dupe issues.

[zapaul]

If for example a guide with the name “install-servicename” was offered for vRootserver and Dedicated Server, there was always the issue that when a customer selected the guide in the Dedicated Server sidebar, the sidebar jumped to the vRootserver area because the same ID was recognized there first.

That makes sense. I haven't noticed.
Might there be a way to separate documentation specific to products at ZAP-Hosting and documentation generally valid for Linux servers, Windows servers and alike?
Most guides in the vRootserver category are unrelated to the product and duplicates to guides in categories for other products such as dedicated servers. The only guides specific to the product seem to be the introduction, server reset, vnc console and root server vs vps. From network troubleshooting onwards, the guides are either valid for every type of server or specific OS flavors.

A radical way of doing it, since the categories appear to only exist (besides the ease of navigation, I understand that) to have a handful of guides specific to the product itself, would be making it all a general server category. The name might not be ideal though.
Anything applicable for every type of server and provider can become it's own category, maybe ZAP-Hosting product specifics is one category and Linux and Windows have their own category the same way they already do. I've seen there is at least guide only in the dedicated category, which is some hosting panel not recommended for virtualized environments. I would make it a warning at the beginning of the guide. It's up to the customer what they do and it, again, makes the guide more generally applicable and discoverable by getting rid of the product specific prefix.

It's probably not entirely thought through yet, requires some additional thinking and certainly there is no perfect solution, but might it be the lesser of two evil?

[fgalz]

Duplicate content
The various approaches each have their pros and cons, but none is fully convincing. Therefore, we will stick with the current implementation for now. While the duplication is not ideal, it is still acceptable at this point. Especially since build generation has become significantly faster with Docusaurus version 3.6, this is no longer a major issue. Additionally, our readers are familiar with the current layout, and a complete reorganization wouldn't make much sense. However, we will keep an eye on the situation and make adjustments if solutions for the duplicate entries and sidebar issues emerge in the future. Anything else would likely result in unnecessary effort and potential confusion for our readers.

Design of the title and description
The current design of this information is based on the wishes of the marketing team. At that time, it was decided that we would define the product name at the beginning of the guides and keep it consistent. The idea behind this was to make it generally recognizable which product is involved when the customer searches for guides in Google. This wasn't clear before when there was no product name.

I've slightly modified/adopted your adjustments and split up the documents for the individual products again. 🙂👍🏻