Technical insights and software architecture

Deep dives into PHP development, Horde Framework evolution and practical software engineering. Focused on real-world solutions for complex technical challenges. “Always close to the source”.

Core Topics

PHP, Horde Framework, authentication systems, composer workflows and modern development practices.

Long-form Analysis

Comprehensive technical articles exploring architectural decisions, migration strategies and lessons learned from real projects.

Code & Community

Open source contributions, framework development and sharing knowledge with the PHP developer community.

Another wicked game in the engine room

It was the early 2000s when the web was still glowing and deforming, freshly spit out from a volcano at CERN a mere decade earlier, taking its time cooling down and gelling into what we know today. Ward Cunningham’s original Wiki as seen in Portland Pattern Repository was already well established but otherwise barely anybody had heard of collaborative editing on the internet. Wikipedia and its ultimately dominant MediaWiki were yet to come. This era spawned some unique and very different Wiki markup languages with very different intent and philosophy: Yawiki, Tikiwiki, Daniel T. Gorski’s Cowiki, Andreas Gohr’s Dokuwiki, Paul M. Jones’ Text_Wiki Default Engine variant of Yawiki – Some of them long forgotten and defunct, some very much alive in their specific corners of the web. With the recent archiving1 of the pear/text_wiki repository, Horde Wicked’s own fork horde/text_wiki is evolving to be the probably most PHP 8.5 compatible implementation of some of them.

This was not intended at all. The original goal was to onboard conservative renovations to pear/text_wiki and then eventually develop a next generation, more modern parser engine with others outside of the horde project. This plan fell through and left us with what we had to support our Horde Wicked application.

The tests are a mess

As I am writing, I am still picking up the pieces – there were some last commits to upstream before it was archived. There was a conservative fork of pear/text_wiki maintained by Horde project’s Jan Schneider through the 2010s. There was another slightly different fork bundled into wicked application. The tests were a mix of early phpunit tests, phpt tests, freeform test scripts and expectation fixtures. Some tests were renovated but accommodated to deviations, maybe conscious deviations, from the original parser artifacts and conversion outputs. Coverage across the different parsers and renderers is mixed.

The goal is to unify to a common standard and style of coverage compatible with PHP 8.5 and PHPUnit versions 11 through 13 for the time being. Tests should be complete enough to detect any creeping deviation from what the code originally parsed from and rendered to. Without this foundation any larger refactoring is in danger of derailing.

Is this archaeology?

It might feel that way. Not breaking any formats wicked used to support is a current goal but the road ahead leads into another direction. I want to evolve the parser and renderer engine to have render-to and parse-from support of modern formats: Markdown (inherently lossy), AsciiDoc (probably needs a much more capable base engine), a modern HTML5 render target. Ultimately a more meaningful subset of MediaWiki syntax is very much on the list – the current parser is very much stuck in early to mid 2000s basics.

Reimplementing and evolving existing Wiki languages and providing migrators might be interesting to internet archaeology but it’s really about driving Wicked into a more modern direction. I don’t like our official documentation platform being stuck in an under-documented Wiki format barely anybody actively writes anymore. This is not what we have a wiki for.

How do text_wiki and wicked relate?

This is going to be difficult in some cases. The horde/text_wiki library tries hard not to couple itself to the Horde framework. It needs to provide the integration points for version and storage handling and such. Sometimes it will provide just the interface, sometimes it comes with a default implementation which any serious use case must adapt for its own needs. There will be much less inheritance and much more plugging-in going forward. Wicked on the other hand does all the application and infrastructure stuff, interfacing with the storage backend, caching, authentication all backed by the Horde ecosystem.

All kinds of custom and dynamic Wiki content which ties into the Horde application system will also be implemented in Wicked rather than text_wiki – any wiki language will inherently accumulate application‑specific dialect extensions which cannot translate to other installations and products as easily as the core language. Wikipedia is full of it2, Markdown is actually a family of dialects extending the standard in contradictory and slightly incompatible ways. The goal is to separate these two classes as rigorously as possible.

Where will this go?

Horde’s official wiki is currently down because wicked in its most recent state on modern php didn’t cope well with increased language strictness and substantial bot traffic. It will be back shortly. Otherwise any of this activity might well have been postponed until after the Horde 6 release. Now let’s harden our basis against any mishaps and fix what needs fixing.

In the longer run our official Wicked instance will switch to some more common markup format. Not losing expressiveness is important so Markdown is either out or we need to decide on a specific brand of Markdown for supporting all the stuff Markdown’s philosophy actually doesn’t want to codify3. I don’t know yet. Recommendations welcome.

  1. pear/text_wiki and pear/text_wiki2 were both archived in February 2026 as part of a mass cleanup in the PEAR github organization. ↩︎
  2. See Scribunto and ParserFunctions for prominent examples. ↩︎
  3. Daring Fireball: Markdown Syntax Documentation See philosophy section ↩︎


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *