[Pmwiki-users] pmwiki-0.5.6 released with a variety of new things
Patrick R. Michaud
pmichaud at pobox.com
Wed Jul 2 02:54:23 CDT 2003
I've just released pmwiki-0.5.6 which hopefully will resolve a couple
of issues that have been discussed in pmwiki-users over the past
week or so. The changes are described briefly in the
PmWiki.ReleaseNotes, but because of the discussions I figured it
would be a good idea to follow up on the pmwiki-users mailing list as well.
The $Newline separator and UTF-8 support
Serge Semashko noted that the character that PmWiki has traditionally
used to represent newlines in data files ("\262") causes some conflicts
with the UTF-8 character set. Some discussion took place on the
list, and then Serge suggested an excellent solution to the problem.
Essentially, each page held in wiki.d or wikilib.d now also provides
a "newline=" entry that identifies the character sequence being used to
represent newlines in that page. Older pages that do not supply the
"newline=" field still default to the "\262" character, so backwards
compatibility with existing pages isn't an issue.
Thus, one can redefine $Newline in local.php to be any desired character
sequence that won't conflict with the markup, and all new pages will be
created using that sequence to represent newlines. So, someone using
the UTF-8 charset ought to be able to set $Newline="\276" (0xfe) in
local.php to resolve the problem.
As a result of this change, I also modified the ReadPage and WritePage
functions so that they perform any needed newline substitutions as pages
are being read from or written to files on disk. Previously these
substitutions were performed in a variety of locations throughout the
code, so centralizing it to exactly the points where the substitutions
are needed (when dealing with disk files) is a big help. If anyone
had local scripts that made use of the $Newline variable, it's probably
a good idea to re-examine them in light of these changes.
PHP as a CGI script and PATH_INFO
In the last several releases I've been trying to get PmWiki to run smoothly
in installations where the PHP interpreter runs as a CGI binary rather than
an Apache module. In particular, when PHP is run as a CGI binary, the
meaning of PATH_INFO is changed and it's no longer a good way to specify
page names to PmWiki. In such situations, administrators had to
specify $EnablePathInfo=0; in local.php in order to get page links to
The 0.5.5 release tried to smartly grab the page name from PATH_INFO,
but this caused some installations to stop working if the PageNamePattern
or GroupPatterns were being modified in local.php (as noted by John Rankin).
Sooooo, 0.5.6 tries a totally different approach. If PHP is being run as
an apache module, then it assumes that PATH_INFO will work and PmWiki
uses PATH_INFO in the same manner that it did in 0.5.4 and earlier
releases. If PHP is being run as a CGI script, it assumes that
PATH_INFO won't work, and pmwiki.php sets $EnablePathInfo=0 and
ignores the value of PATH_INFO.
Hopefully this will make things easier for everyone--especially first time
installations on systems with CGI versions of PHP. If anyone runs into
any problems--e.g., a system where PHP runs as a CGI but PATH_INFO
is being set properly--then contact me so I can work out the details.
$TimeFmt variable change
The default value of $TimeFmt (used to format the date/time in the
"Last Modified" and "RecentChanges" pages) has been changed to be
compatible with the Standard C Library definitions.
Experimental RSS support
I didn't get a chance to document it in the ReleaseNotes or the
ChangeLog, but pmwiki-0.5.6 includes a scripts/rss.php module that
may be useful for generating RSS (Really Simple Syndication) feeds.
It's still experimental--for discussion, details, and suggestions see
http://www.pmichaud.com/wiki/Development/RssGeneration or send comments
to the listserv.
Many thanks to everyone for their continued support of PmWiki!
As always, feel free to send questions directly to me or to the
pmwiki-users mailing list.
More information about the pmwiki-users