Refactoring
One of the reasons DokuWiki is still going strong after all these years is that I resisted to throw it all away and start anew. 

It seems there are two common ways how Open Source projects die: either the maintainer simply loses interest and abandons the project or they decide that the project became so complex that it needs a complete rewrite. Joel Spolsky wrote an article nearly 20 years ago on how that's generally a bad idea.

Coincidentally death-by-rewrite seems to have befallen our user forum's software of choice: UNB. But handling that is a task for another day and post.

This post is about the alternative: refactoring in small to medium sized chunks.

Wikipedia defines refactoring as the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring improves nonfunctional attributes of the software.

Our latest release, code named Greebo, actually contained quite a few refactorings under the hood.

One of the changes I already wrote about here, the new menu system. In theory nothing really changed for the end user - its all still the same buttons - but for template authors, the code got much better.

Another, major change was the introduction of the ActionRouter component. This is the central part in DokuWiki that decides how to react to what the user asks the wiki to do. Eg. when the user asks to edit a page, the action router checks if the page can be edited (eg. isn't locked), if the user has the needed permissions, etc. and then loads the appropriate editing interface.

This part of DokuWiki used to be one huge, monolithic function of several hundred lines of code. The new mechanism has a much cleaner design that separates the different actions (edit, preview, save, recent changes, etc) into different classes. Some of them surprisingly short.

Another change that started with the recent release is to move code out of DokuWiki into separate libraries. Either libraries completely written and maintained by others, or libraries still maintained by me but independent from DokuWiki. Examples of the latter are the php-archive and php-cli libraries.

The advantage of having separate libraries is that maintenance of those is easier crowd sourced. The idea being that the  number of PHP developers interested in working on DokuWiki is smaller than the number of developers that need a Zip-library and would contribute patches to it.

The most recent refactoring project is about making DokuWiki PSR-2 compliant. PHP Standard Recommendations (PSR) try to make PHP code more interoparable by defining certain standards.

PSR-2 defines a basic coding standard. It is mainly concerned with how classes and methods should be named, how auto loading works and where spaces and brackets go. It is not too far off what DokuWiki already uses, but different enough that it's not a simple reformatting of the code either.

The goal with adopting PSR-2 is to modernize our code base and make it easier for newcomers. It will also allow us to implement automatic code checks which will ensure that future changes to the code base will adhere to a clean style.

Transitioning a a code base that is more than a decade old isn't easy though. I'm still in the process of fixing issues that can not be automatically fixed. It's a slow process that requires some care to ensure backwards compatibility where needed - the code search mechanism I talked about in my last post is a big help there. I started with over 3000 issues to fix and am currently down to about 500...