[pmwiki-users] Any hope for 2.2.0 stable release?
henrik.bechmann at sympatico.ca
Wed Jan 14 20:40:12 CST 2009
I've been running PmWiki on a PHP5 server as well. Although there were a
couple of minor glitches, Patrick addressed them, and everything works
But I believe the next step is to stop supporting PHP4, by which I mean,
transition more to the OOP features of the language, eventually exclusively.
I don't buy the contrarian view of OOP that you offer. The benefits of
encapsulation, modularity, polymorphism, and inheritanc
<http://en.wikipedia.org/wiki/Object-oriented_programming>e are well
established, and virtually universally accepted. These include:
- Closer match between design objects and implementation objects, making
development more successful.
- improved modularity, and looser coupling among modules, making
development, including team development easier (very relevant to this
discussion of considering moving to a community development model)
- more concise and re-usable code. In the case of PmWiki the code may be
concise, but it certainly isn't easily re-useable (see below).
- availability of a wide variety of useful design patterns that apply to
the OOP paradigm.
Furthermore, the developers of PHP are apparently committed to focusing
on developing the OOP side of the language, adding improvements there
that will eventually surpass the efficacy of the legacy part of the
language, viz the new class autoloader
example. It would be prudent to position PmWiki to take advantage of
Finally, PHP 5 (and 6) are being positioned to address some of the
long-standing language problems, notably the arbitrary organization of
language functions (generally considered to be a mess), and the lack of
namespaces. These are being addressed in PHP 5 and 6, from what I can
see with an emphasis on the OOP side of the language.
You ask if there is a problem that you cannot see that requires
migration to OOP. Have you tried to follow the PmWiki code? With the
greatest respect for Patrick, it falls into all the traps available to
structured programming, notably over-use of globals, and unending
reliance on hidden side effects. You can argue that some of this was
done for conciseness and performance, but it has the drawback of being
difficult to maintain. In the current context, it has the drawback of
being virtually impossible to maintain by a group.
Another benefit of a re-write, not to be dismissed, is that it is an
opportunity to disentangle some of the concepts that have developed
incrementally over the years. In other words to clarify the design of
the product, and reflect this clarity in the new code.
Regarding features of the product:
The list I offer comes from many years experience in offering PmWiki
based websites to a number of community organizations in Toronto (about
30 sites, of which a handful are pretty active).
For an example of file Management, see for example DocuWiki's
I think the benefits of an administrative interface are obvious: it
lowers the skill level required to manage the supported features, making
the product more accessible, and greatly broadening its reach. This
would be true even if the supported features were selective, not univeral.
I have seen and investigated the form based entry systems that exist.
These are terrific efforts, but are (IMO) still early, and awkward.
Based in my experience of supporting many PmWiki installations, one
thing that I have found consistently is that for sophisticated use of
wiki markup, the complexity of embedded instructions is a persistent and
important barrier to authors. Support for customizable, configurable
form based entry would IMO radically expand the potential user base of
PmWiki, and owing to the very work that you reference, this feature is
relatively accessible, but requires further development effort.
Furthermore, it would greatly alleviate the pressure for a WYSWIG entry
I would add decent "feed" capability, including useful RSS support.
I'm sure others have need of features that they see in other products.
PmWiki is most certainly a laggard by now. The current version has been
in beta for far too long (for well justified personal reasons as we
know), while the rest of the world is not standing still. See for
example habari <http://habariproject.org/en/habari-and-php5>
In any case, surely as a product matures, if it is to become established
in the long term, it requires an active community of developers to
sustain it (for the core!).
My contention is: it is time for this to happen.
To be clear, I do not mean in any way to diminish the accomplishment of
PmWiki. Instead I am arguing in favour of a clear way forward, to
consolidate the gains made, and establish a foundation for capturing
even higher ground.
Nor, of course, is any of this to suggest in any way the replacement or
pre-empting of Patrick. That would be awful, as he's the genius behind
this product. Instead, my initiative is aimed at finding a practical way
of organizing support for him and his efforts. I would hope and expect
that he would continue to be the designated "guru", the final say, but
in more of an "executive" role.
Petko Yotov wrote:
> On Wednesday 14 January 2009 20:02:46 Henrik Bechmann wrote:
>> FWIW, if there was to be the formation of development team, I think it
>> would be worth considering going (more or less directly) to version 3,
>> being a migration to PHP5 and OOP.
> * I have my PmWikis running on PHP5 since 2005. The current stable and beta
> work extremely fine with PHP5.
> * OOP is not a goal in itself, but a means to some goal, and it is only worth
> the effort in some cases. See "OOP Myths Debunked" at
> http://www.geocities.com/tablizer/oopbad.htm .
> PmWiki uses an OOP PageStore class that allows excellent integration of
> different storage mechanisms such as a database instead of or in addition to
> the filesystem, or a different filesystem configuration. Almost every other
> aspect of PmWiki can be configured via enabling a variable and providing a
> replacement function, without modifying core files. Every core script, should
> it be changed, may be placed in the /cookbook/ directory and be included
> instead of the original one.
> Is there a problem I cannot see, that requires migration to OOP?
>> My three main feature requests: resource file management, an
>> administrative interface, and a form-based content entry option.
> * What is resource file management?
> - Deleting attachments is possible wia recipes : Cookbook:Attachtable
> and others
> - Uploading CSS files or whole skins via PmWiki's ?action=upload can be
> made possible by adding two lines of code to farmconfig.php.
> * A recipe could be written to add an administrative interface. It may already
> exist. I have used myself for months a small snippet and I'll soon release it
> on the cookbook. It allows some selected config variables to be overridden by
> editing special wiki pages. Not form-based but does the job.
> * There are more than one recipes for form-based content entry. One is PmForm
> by Pm, other is Fox by HansB, a third, new one, is Blogger by DaveG.
> There is also another wiki project inspired by PmWiki and ZAP, which I believe
> has more form-based administration options. See http://www.boltwire.com/ .
> Personally, I believe adding more features like these should be in recipes and
> not in the core. For the core, we should follow the PmWiki Philosophy.
>> I think that the combination of targets such as these could take PmWiki
>> back from being a laggard, to leapfrogging to the head of the line.
> PmWiki is not laggard. I have not seen any other wiki that allows even half of
> the features PmWiki could plug-in, without the need to modify core files and
> potential problems on upgrades. Some core features like PageLists and
> PageTextVariables are quite unique in the wiki-world. The built-in search
> engine is better than any other wiki, with the best ratio performance vs
> CPU+fsystem usage.
> The only thing I believe would be better, is to enable UTF-8 support in the
> default installation, but currently it is difficult for the script to know
> whether the wiki uses or not a custom character encoding, so an existing wiki
> that upgrades could occasionally break. We'll figure something out.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users