[pmwiki-users] Any hope for 2.2.0 stable release?

[Patrick R. Michaud]

On Tue, Jan 20, 2009 at 12:10:56AM +0100, ml wrote:
> here are some proposals for the code:
> - reduce $GLOBALS (e.g. $t in forms.php)

I very much agree with this one.


> - drop PHP4 support (outdated)

I don't see dropping PHP4 support as a goal on its own.  If
there is something that we want to add to PmWiki and where
PHP4 support is holding us back, then we can consider it.
But there are still a lot of sites (including pmwiki.org)
that are using PHP4 and I don't see any purpose in dropping
PHP4 support for its own sake.


> - move confiiguration items to a separate class ($GroupPattern, $NamePattern,
> etc. => class members), no more "global $StopWatch"

I don't know that we'll eliminate global variables entirely.
If I had things to do over again, I would put all configuration
variables into a $Config array and provide some functions to
easily set defaults and obtain values from that array.  This
would also make a "control-panel" type interface easier.

The problem with simply switching to such a structure now is that
it might break a ton of sites and recipes, so we really need a
smooth migration plan.  Hopefully one that doesn't involve a long
"beta" series.

> - reduce unusual abbreviations (PSS, PVS, PVSE, PZZ, etc.) 
> and/or add PHPdocs to help Zend/PDT users reading the code

The unusual abbreviations are there for a reason -- without
them portions of the code become very very long and unreadable (to me).
I have no problem with documenting these functions very well, but
I prefer to keep the abbreviations.

Stated differently:  Most communication forums and (written) 
languages have abbreviations in them for a reason -- they 
serve to simplify communication among people working within
those arenas.  Yes, it sometimes means that newcomers to the
system have to become familiar with the abbreviations, but
that doesn't mean that we should throw them out entirely.

> - make UTF8 the default encoding

This is the one I'd be most eager to see us tackle, but also 
one of the most difficult.  It's not a problem for new
installations of PmWiki, but it's very difficult to provide
a way for existing sites to convert over to UTF8.

I've already put some internal items in place to help with
this -- for example, each page file includes a field that
indicates the page encoding used to save the page.  We could
use this to convert page text on the fly.

More difficult is dealing with page filenames -- we would want
some way of either (1) converting all pages on a site to UTF8,
or (2) automatically probing for all filename types that
could exist.

Actually, now that I think about it, I might have a good way to
do #1, so perhaps we can work on this soon.

Pm