Fighting Hackers: New apps/hosting

Over the weekend I have been fighting attempted and/or successful attacks on the site. I’m still trying to figure out if the problem is wordpress or dokuwiki or something else.

In the meantime, however, it is probably a good opportunity to re-evaluate how the site hosting works. Currently I have a cheap godaddy shared server for dokuwiki and wordpress, with jira and this forum on SAAS providers. I’m not a huge fan of godaddy, but it has the advantage of being cheap since I am paying for it personally. The best options would be some other SAAS that would host the main site and blog for free like atlassian and zoho does. 

We have dokuwiki primarily based on the request a few years ago to have translations of the documentation available. The person who suggested it has been maintaining the Japanese version of the documentation and doing a great job of that, but no other languages have really caught on. I suspect that is because english works well enough for most people and that maintaining a translation is a very difficult burden for anyone to take on for themselves.

That being said, I would definitely not be against going for a different wiki/cms system for the website, but would like to know what everyone wants and does not care about for functionality. 

One option I have looked at is That appears to be static pages, so we would lose the wiki aspect of the site, but I’m not sure if that would be a big loss since most documentation changes end up going through jira bug reports or forum suggestion changes anyway.

Does anyone have suggestions of hosting or apps I should be looking at?


By “wiki tab”, do you mean the “site” tab on ?

Github can have wikis, but I would like to have as the domain name eveything runs under, but I’m not seeing that the github wiki can do that


Github has CNAME support:

Is that helpful? I use the Github Issue tracker and Wiki on a number of projects and they appear to work well.


Two things:

  • The wiki tab on got hacked as well; that’s not under your control, is it?  That’s fundamentally a problem with, yes?
  • Github projects can have wikis.


By “wiki tab”, do you mean the “site” tab on ?


Yeah, I saw github pages have cname support, which is why I thought they could be an option while the wiki would not be. 

I’m currently thinking I should convert the existing wiki over to a github page repository instead. We lose the wiki aspect, but at the same time we gain the ability to include a dump of the site with each release for local documentation, better online performance, and being hack-proof. Updates to the documentation would have to come through pull requests on the repository, which may not be a terrible loss since there has been little direct documentation editing by other people, and there is still that pull request option.

Dokuwiki has a slightly different markdown syntax, but it looks like with a few regular expressions I should be able to get something up and going soon.

Conflucence on would probably be the alternative option. Has anyone used that for website content management vs. an internal wiki?

We’ve made it a day without any new defacement. It could be that upgrading dokuwiki has plugged the hole. I will probably still look at options for moving.


I tested that silverstripe converter and it does not work to bad. Its not great but it also does not seem to complicated to hack some extra features for conversion from ignore the bad layout its the conversion that we need to work on if you would like to use silverstripe.

Pygments and boostrap is wrestling a bit over the code tag but again, this is all just a prototype.


Oh and just for fun try to open the website on your mobile device.

The mobile version is nice to have. Where were you getting the original wiki format from the old site? I could send you a zip of all the pages in the original markdown if it would help.

My approach had been to do manual regular expression search and replace from the original dokuwiki across all the pages. It wasn’t terribly difficult, but it also wasn’t done and there are things like the blocks, []'s within the dokuwiki format, and tables that may be more difficult.

 Would it work better for me to push the original markdown to and you could fork that and send push requests we get conversions ran?

I also had extracted the existing layout to the _layout folder, but if you or anyone else can help with improving the look and feel of the site, that would definitely be great as well. 


I used the view source functionality of wiki to pull down 4 or 5 test files.

It would be great if you push die wiki’s marked up syntax to github then like you said I can just fork it.

if you can upload the layouts you have at the moment one can also look at that.

I committed the original dokuwiki content to the repository


My first reaction is either the Confluence route seeing you are already using jira or the github route with pages seeing you are already using github for hosting. With that in mind I will then also recommend you to move to the github issue tracker if you decide on github, to keep everything in one nice place.

I actually started to read up about the github pages and created a little “demo” with Jekyll and Bootstrap you can view it at and pull it at

The basic idea behind it was to allow multiple languages. So I created a liquibase layout and added a custom page attribute to the YAML front matter of every page called lang. I also move the top menu out to en/navbar.html so each language can change their menu as well, and this get ajax late loaded by the liquibase layout template.

I’m not happy how linking works at the moment with “{{ site.url}}/{{ page.lang }}” but like I said this is only a prototype and I’m a beginner github pages user. So I’m sure there is a lot of room for improvement, up until recently as a “old” developer github did not really appeal to me but I’m growing fonder of it everyday. 

For interest sake I quickly googled for “convert dokuwiki syntax to markdown” and found might be useful. But you can also convert the I can help with the setup and styling and even demo it if you would be interested. 

I unfortunately have no experience with Confluence and not really interested because I’m tired of wasting my resources on proprietary software.

Let me know what you think.


Ps. Can you maybe upload or make available a sql or file dump of the wiki? I want to run the silverstripe converter through it and see how much manual work is needed. 

Thanks Nathan,

I forked it and then moved all the English files into en. I also then converted all the files to UTF-8 format because jekyll does not like it in a ANSI format and then I had to fix two encoding problems in the en files.

I unfortunately believe with the UTF-8 conversion I broke the ja files. We will need someone to have a look at this for us at

I also then forked the silverstripe converter. As stated previously it is written in PHP and at a closer look it just does a lot of regular expression on the code. 

I added a basic template (at the moment it just prepends information to a file) system and I’m working on two regular expression that I will add to the converter. The PHP code can be found at

I made a new prototype of the website available at this should be the whole en website/wiki and all the links should work. The only manual files I created was the navbar.html and index.html to redirect to home.html. All other processing was done with the converter as mentioned above.

The biggest problem I see at the moment is table conversions and I will have a look at it as soon as I get time again.



Ludolph, have you had a chance to work on the conversion more and/or see yourself having time to continue work? Or would you like me to take over the remaining conversion?


Hi Nathan

Unfortunately I did not spend more time with the conversion. I now quickly had a look at the table problem and it should be easy enough to fix in the DokuWiki Converter seeing the markdown library Jekyll uses do support markdown extra tables.

I still believe I broke the Japanese files, but I don’t know.

I don’t want to hold the conversion project back, so if you want to continue please do so.

Otherwise I will try to get the tables working in the week and get a solution to sub directories and links, because manual pages is not working and my jekyll variable hack is ugly.

If I get stuff done during the week I will come back with a list of things I think we can still automate before cleaning the pages by hand, or if you have a workflow or idea how we can tackle this I will try to help where I can.

Kind Regards,


I ended up moving the site to github and I’ve liked how that works. It has to be all static so we lose some capabilities (such as comments) but I’ve been able to start auto-generating pages from the code and I can manage changes within branches. Plus the search and replace capabilities having all the pages local has been nice.

I’ve used confluence in the past and it is nice, I’ll keep it in mind if/when we run into limitations with the github page hosting, but for now it’s working well.


I know this is an old topic…  Sorry for the REALLY late response!

I have used confluence for site management and it works really well.  Since you use Jira, confluence would be an even better fit.  Confluence has macros that can pull dynamic data from Jira.  You can do things like have pages which show a list of the enhancements scheduled for the next version (just as an example).  Jira and Confluence also share the same user management so it is easy to give a certain group of people rights to update the content (if you don’t want it to be public).  It also keeps history for every page making it easy to revert changes and see exactly who changed any given page.

Confluence is also used by all of the Codehaus and Apache open source projects as well.  

Oh, you can also setup confluence to allow people to add comments to pages.  Take a look at the docs (published using confluence) for the Atlassian apps. To see why this might be a good thing.

Another benefit is that you can keep docs by version fairly easily.  For example, Atlassian publishes the docs for each version of their apps.  This would allow people using version 2.X to see the docs for that version even after the 3.X docs have been published.