Links to documentation are broke

the links of the cloudmin documentation are not working

Installation Guide – How to install Cloudmin

points to: the virtualmin installation guide

Using Cloudmin – An introduction to various tasks in Cloudmin.

points to: that gives
You don’t have permission to access this resource.


points to:

I did find a working documentation on Cloudmin Documentation | Virtualmin


Still part of the mess by the big migration. The site has been moved and changed and it’s been an ongoing fight for @joe and crew to handle.

I’m sure he’ll weigh in sooner or later and apologize for it.

This is a particularly disheartening element of the migration. I went to great lengths to make sure the hierarchy got migrated (most configurations of the migration tool screwed it up and added redirects, but I finally found a combination of settings that did the right thing), and it came over correctly…and, then there was an ownership issue that required updating all the articles, and it somehow lost the parent information in the process. I still haven’t gotten over it, it really is frustrating.

I honestly don’t know yet what to do about the documentation. It has other major problems, in addition to this. The migration from Drupal to WordPress was stupid and continues to be stupid. And, I think in the end I don’t want the documentation in WordPress, anyway. I hate the editor (I hate all WYSIWYG web-based editors, even good ones). I hate not having docs in a revision control system. And, I hate that we can’t reasonably let people send us patches. So…I’m leaning toward exporting the original Drupal-based docs into some static site generator (probably Hugo), so we can edit in a real editor, can check it into git, and can let people make PRs on github.

I was not blaming or pointing fingers, just making an observation. I have a postnuke website i need to migrate to “something else” because it only works in php 5.3 so i know how much is involved.

Maybe a link on top (or bottom) to the old documentation on for now can be a temporary work-around. It wouldn’t solve the migration problem, but it would solve the users problem that need to access the documentation.


1 Like

WYSIWYG editors indeed have issues:

For the documentation: My team can help with Tiki Wiki CMS Groupware (setup, management, data migration, graphic design, integration, etc.). It’s a mature wiki engine that has more features than you’ll ever need. Like all wiki engines, it comes with version history. It is also possible to propose edits that are approved by members of a trusted group:

The upcoming version has this cool new feature:

As a bonus, it also has a form builder, should you need it at one point: | Database Web App Builder

It uses Bootstrap like Virtualmin so we can easily align the UX.

Best regards,


1 Like

Thanks @marclaporte, TikiWiki would be a good fit for Virtualmin’s documentation. The pain point that @Joe is attempting to address is that of fake registrations and the subsequent spam that such accounts create. The way forward seems to be a static website generated from content hosted on git.

I can see this from Joe’s point of view, in that any popular website based on a content management system which is open for registrations will attract spammers and no webmaster wants to waste time fighting spam and deleting fake accounts, so a static website generator plus git offers a zero administration option to address this pain point.

When I was recently proposing Tiki as a platform for managing Virtualmin’s documentation, it checked all the other boxes but I was unable to offer a compelling argument against fake registrations and spam. Perhaps you can make a stronger case for Tiki than I.

It would make me very happy indeed to see my favorite web hosting control panel use my favorite content management system.

I prefer Media Wiki.

It’s the same software Wikipedia uses.

Well in Tiki you can restrict whom/where can post, or block any registration or editing rights completely. Managed to pull this out with a big site, roughly 20 accounts for ~10 years. Working to this day :slight_smile:

Only a wiki would cut it for any sizeable documentation project.

1 Like

Tiki is great! But, a wiki, even a very good one, just doesn’t solve the problems I need solved.

My priorities are: Markdown that I can edit in a good editor (local vim, but others are welcome to use other lesser editors), revision control of content in git, never have to think about spam in the docs ever again (my attempt to wikify the Webmin docs was a disastrous time sink and I’m still grumpy about it…the web is so completely poisoned by spam today that it just takes all of the joy out of tools like wikis for me), and the ability for people to send us changes via PR at github.

When it comes down to it, wikis (or any other type of CMS) are solving a problem we don’t have, which is how to let somewhat non-technical users easily edit and manage content. But, pretty much everyone that’s really writing a lot of docs for Virtualmin knows how to use git and a text editor and Markdown, and in fact, are more proficient and comfortable with those tools than with any wiki or CMS we could choose.

A static site generator is just a better fit for us. And, it’s hard to argue with the performance/cost benefits of a static site.

So, when I get a few hours of free time (maybe this weekend, though I’m kinda swamped at my other job at the moment, and on a time crunch, so I might not even have a lot of time this weekend) I’m going to write a tool to export from Drupal docs to a Hugo site. I think it’ll solve all of our problems satisfactorily and I’ll never have to think about comment or edit spam again.

1 Like


Hi, something like this would be suitable… what do you think guys?
Sorry for video time I just perhaps talk too slow and too much :smiley:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.