phpwiki-talk

Re: [Phpwiki-talk] PhpWiki and Apache 2.0.40, problems and solutions

[Matti A. <ma...@ik...>]

pe, 01-11-2002 kello 00:00, Jeff Dairiki kirjoitti:
> Try the setup described at
>   http://phpwiki.sourceforge.net/phpwiki/PrettyWiki
> 
> If that works for you, I'll change the comments in index.php.
> (I probably should have done that a while ago...)

OK, the settings below seem to be minimum settings with which I can get
it to work. It's notable that the comment in index.php suggests that
USE_PATH_INFO is by default true. Well, this is not quite true. :-)

/.htaccess:

<Files wiki>
   AcceptPathInfo on
   ForceType application/x-httpd-php
</Files>

/phpwiki/index.php:

$include_path = '.:phpwiki';
if (!defined('PHPWIKI_DIR')) 
  define('PHPWIKI_DIR','/var/www/mairas.net/html/phpwiki');
if (!defined('USE_PATH_INFO')) define('USE_PATH_INFO', true);


m.

Re: [Phpwiki-talk] PhpWiki and Apache 2.0.40, problems and solutions

[Jeff D. <da...@da...>]

> But first, the setup:
> ...

Hi Matti,

Try the setup described at
  http://phpwiki.sourceforge.net/phpwiki/PrettyWiki

If that works for you, I'll change the comments in index.php.
(I probably should have done that a while ago...)

Re: [Phpwiki-talk] PhpWiki and Apache 2.0.40, problems and solutions

[Matti A. <ma...@ik...>]

to, 31-10-2002 kello 23:13, Matti Airas kirjoitti:
> --clip----clip----clip----clip----clip----clip----clip----clip----clip--
> --- /tmp/phpwiki/lib/config.php 2002-09-27 16:40:34.000000000 +0300
> +++ lib/config.php      2002-10-31 22:09:29.000000000 +0200
> @@ -336,7 +336,13 @@
> 
>  if (VIRTUAL_PATH != SCRIPT_NAME) {
>      // Apache action handlers are used.
> -    define('PATH_INFO_PREFIX', VIRTUAL_PATH . '/');
> +    // There are differences in Apache versions in rgd. to how
> PATH_INFO is
> +    // assembled. Test what the prefix should look like.
> +    if
> (substr($HTTP_SERVER_VARS['PATH_INFO'],0,strlen(VIRTUAL_PATH))==VIRTUAL_PATH) {
> +        define('PATH_INFO_PREFIX', VIRTUAL_PATH . '/');
> +    } else {
> +        define('PATH_INFO_PREFIX', '/');
> +    }
>  }
>  else
>      define('PATH_INFO_PREFIX', '/');
> --clip----clip----clip----clip----clip----clip----clip----clip----clip--

Doh. Of course that patch gives a warning when accessing the main page
(as PATH_INFO does not exist in that case). I'm open to suggestions, how
to fix this more cleanly. :-)

m.

Re: [Phpwiki-talk] Re: rss; i18n diff

[Tony L. <la...@is...>]

On Thu, 31 Oct 2002, Jeff Dairiki wrote:

> > Parse error: parse error, expecting `T_OLD_FUNCTION' or `T_FUNCTION' or 
> > `T_VAR' or `'}'' in 
> > /web/premium/www.issho.org/modules/phpWiki/lib/diff.php on line 69
> 
> I suspect you deleted one too many closing curly braces.
> Make sure the closing brace for the class definition is there.

Silly of me. 
In fact, it cleared up the problem, at least in this particular 
instance. 

http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=MultilingualWikiTalk&action=diff&version=18&previous=major

Thank you!

Re: [Phpwiki-talk] Re: rss; i18n diff

[Jeff D. <da...@da...>]

On Fri, 1 Nov 2002 06:08:49 +0900 (JST)
Tony Laszlo <la...@is...> wrote:

> Thanks. Not that easy, it seems. 
> Tried that but this error was generated when trying to diff: 
> 
> Parse error: parse error, expecting `T_OLD_FUNCTION' or `T_FUNCTION' or 
> `T_VAR' or `'}'' in 
> /web/premium/www.issho.org/modules/phpWiki/lib/diff.php on line 69

I suspect you deleted one too many closing curly braces.
Make sure the closing brace for the class definition is there.

If you're still stuck, send me your diff.php (via private e-mail).

[Phpwiki-talk] PhpWiki and Apache 2.0.40, problems and solutions

[Matti A. <ma...@ik...>]

Hi!

I just hacked together a PhpWiki site using the latest nightly PhpWiki
tar package and Apache 2.0.40 with PHP 4.2.3 provided by Mandrake 9.0.
In the process I stumbled into something I think must be a bug.

But first, the setup:

PhpWiki resides in /phpwiki (relative to docroot). I tried to make the
PATH_INFO stuff to work as described in index.php and PhpWiki Wiki
pages, by making /wiki and putting the following lines to .htaccess:

Action x-phpwiki-page /phpwiki/index.php
SetHandler x-phpwiki-page
DirectoryIndex /phpwiki/index.php

Instead of a working Wiki I got 404's. Clearly, the handler delegation
didn't work with Apache 2.0. After a huge amount of trials and errors I
ended up with a seemingly working setup:

/wiki/.htaccess:
--clip--
DirectoryIndex /phpwiki/index.php
RewriteEngine On
RewriteBase /wiki/
RewriteRule ^(.+)$ /phpwiki/index.php/$1 [QSA]
--clip--

also, a following line has to be added to 
/phpwiki/.htaccess:

AcceptPathInfo on

With these settings, the Home Page loaded correctly. The problem was, I
only got the Home Page, no matter where I went. 

Now, after another huge amount of trials and errors, I narrowed the
problem down to PATH_INFO_PREFIX setting. The variables are set as
follows:

_SERVER["REQUEST_URI"]		/wiki/AddingPages 
_SERVER["SCRIPT_NAME"]		/phpwiki/index.php 
_SERVER["PATH_INFO"]		/AddingPages 
_SERVER["PATH_TRANSLATED"]	/var/www/mairas.net/html/AddingPages 
_SERVER["PHP_SELF"]		/phpwiki/index.php/AddingPages 

However, PhpWiki assumes that PATH_INFO has the VIRTUAL_PATH (in this
case '/wiki') as prefix. As can be noted, that isn't the case.

I found out the following patch fixes the problem for me (TM):

--clip----clip----clip----clip----clip----clip----clip----clip----clip--
--- /tmp/phpwiki/lib/config.php 2002-09-27 16:40:34.000000000 +0300
+++ lib/config.php      2002-10-31 22:09:29.000000000 +0200
@@ -336,7 +336,13 @@

 if (VIRTUAL_PATH != SCRIPT_NAME) {
     // Apache action handlers are used.
-    define('PATH_INFO_PREFIX', VIRTUAL_PATH . '/');
+    // There are differences in Apache versions in rgd. to how
PATH_INFO is
+    // assembled. Test what the prefix should look like.
+    if
(substr($HTTP_SERVER_VARS['PATH_INFO'],0,strlen(VIRTUAL_PATH))==VIRTUAL_PATH) {
+        define('PATH_INFO_PREFIX', VIRTUAL_PATH . '/');
+    } else {
+        define('PATH_INFO_PREFIX', '/');
+    }
 }
 else
     define('PATH_INFO_PREFIX', '/');
--clip----clip----clip----clip----clip----clip----clip----clip----clip--

The fix may not be pretty, but without it PhpWiki does not work for me.
Please consider applying it to the CVS.

Best regards,

Matti Airas

[Phpwiki-talk] Re: rss; i18n diff

[Tony L. <la...@is...>]

Hey there, Jeff. 

On Thu, 31 Oct 2002, Jeff Dairiki wrote:

> Yes, that's the word-level diff engine doing that, probably... (splitting
> words in the middle of multi-byte characters...)
> 
> A quick fix^H^H^Hhack would be to disable the word-level diffing.
> 
> I think you can do that be deleting the method definitions of _pack(),
> _split() and _changed() in class HtmlUnifiedDiffFormatter (file
> lib/diff.php).  (HtmlUnifiedDiffFormatter will then inherit the _changed()
> method from UnifiedDiffFormatter.)

Thanks. Not that easy, it seems. 
Tried that but this error was generated when trying to diff: 

Parse error: parse error, expecting `T_OLD_FUNCTION' or `T_FUNCTION' or 
`T_VAR' or `'}'' in 
/web/premium/www.issho.org/modules/phpWiki/lib/diff.php on line 69

Fatal error: Call to undefined function: showdiff() in 
/web/premium/www.issho.org/modules/phpWiki/lib/main.php on line 139


On Thu, 31 Oct 2002, Lawrence Akka wrote:

> No you can't.  You need the as-yet-unreleased-but-written-(honest) fix files, 
> which I will probably get around to releasing on the Postnuke site in the next 
> week or so.  For some reason, a number of people have requested this recently, 
> so I've actually done something about it (for a change)

Super, Lawrence. 
Looking forward to it!

Thanks. 

Re: [Phpwiki-talk] Logo on separate line due to css

[Carsten K. <car...@us...>]

Hi Oliver,

I'm seeing an extra blank line there too with OmniWeb. I'll look at the 
css too to experiment what can be done for the logo without disturbing 
other page elements.

Removing img { vertical-align: baseline; } might affect the position of 
LinkIcons in body text for some browsers, probably nothing else. 
http://phpwiki.sourceforge.net/demo/en/LinkIcons

Carsten

On Monday, October 28, 2002, at 04:19  pm, Oliver Betz wrote:

> Hello All,
>
> I think that I have been reading about this anywhere but don't remember
> where: in phpwiki-heavy.css the line
>
>   img { vertical-align: baseline; }
>
> causes that the "Php Wiki" logo is displayed on the left side above the
> navbar when viewed with IE5 or IE6. Opera shows the logo as expected.
>
> (PhpWiki 1.3.3 with "default" theme")
>
> In the nightly snapshot it's on the right side, but still a separate 
> line
> between the navbar and the page name.
>
> I don't know whether it hurts to remove this line. IE and Opera look 
> fine
> without, I can also try mozilla but have no NS installed.
>
> Oliver
> -- 
> Oliver Betz, Muenchen

Re: [Phpwiki-talk] rss

[Lawrence A. <la...@us...>]

Quoting Jeff Dairiki <da...@da...>:

 
> It may be that you can just grab the latest lib/plugin/RecentChanges.php
> and lib/RSSWriter091.php, (or perhaps the versions from the 1.3.3
> distribution,) drop them into your installation, and have RSS 0.91
> support.  Lawrence might be able to tell you more...
> 


Tony,  I've already emailed you about this, but for anyone else reading this:

No you can't.  You need the as-yet-unreleased-but-written-(honest) fix files, 
which I will probably get around to releasing on the Postnuke site in the next 
week or so.  For some reason, a number of people have requested this recently, 
so I've actually done something about it (for a change)

Lawrence

Re: [Phpwiki-talk] rss

[Jeff D. <da...@da...>]

> I saw only the UN_en fix, in a file that does not 
> exist in the pn module setup. Was there something 
> else, in RssWriter.php perhaps? 

lib/plugin/RecentChanges.php

> > Is postnuke supposed to be able to grok RSS 1.0?
> 
> I hear that it may not. 

Sounds like that's right.

It may be that you can just grab the latest lib/plugin/RecentChanges.php
and lib/RSSWriter091.php, (or perhaps the versions from the 1.3.3
distribution,) drop them into your installation, and have RSS 0.91
support.  Lawrence might be able to tell you more...

> on a different matter, I noticed that some double-byte characters 
> got chewed up pretty significantly when I used diff earlier today. 

Yes, that's the word-level diff engine doing that, probably... (splitting
words in the middle of multi-byte characters...)

A quick fix^H^H^Hhack would be to disable the word-level diffing.

I think you can do that be deleting the method definitions of _pack(),
_split() and _changed() in class HtmlUnifiedDiffFormatter (file
lib/diff.php).  (HtmlUnifiedDiffFormatter will then inherit the _changed()
method from UnifiedDiffFormatter.)

It may be possible to fix the word-level diff algorithm so that it doesn't
split-up UTF-8 characters (by adjusting the regexp used in
HtmlUnifiedDiffFormatter::_split,) but I haven't had enough coffee yet
today to be able to figure that out...

(Of course, the fix would be trivial if PHP's regexp engine was/were UTF-8
aware...)

Re: [Phpwiki-talk] rss

[Jeff D. <da...@da...>]

> Also, is there strictly anything wrong with using dc:description instead
> of description?  I thought that the first was just a fully
> namespace-qualified version of the latter.  The parser ought to be able
> to cope with it.  

No.  They're different.  The default namespace is rss
(http://purl.org/rss/1.0/).
Dc ("Dublin Core", http://purl.org/dc/elements/1.1/) is, therefore, a
different
namespace.

So they are different.  I am, however, clueless as to what, precisely,
that implies.

It seems reasonable, however, (and the validator concurs) that if we
include
only a single 'description', it ought to be <rss:description> rather than
<dc:description>.

[Phpwiki-talk] =?iso-8859-1?Q?TextField_Bug__=BF=3F?=

[Cristian R. S. <cri...@da...>]

Hello Wiki Wiki =3D)=20

My name is Cristian Silva.  I'm from Buenos Aires - Argentina. =20

I mailing to you to report a bug at TextField Object.=20

I create a TextField with "createTextField" in a movie. Soon I make =
loadMovieNum to that movie, and the text created with "createTextField" =
is not seen. Is this other bug?

Thanks.  Greetings.

Cristian.

[Phpwiki-talk] ×î½ü»¹ºÃÂð£¡

[ÍøÂçÏÈ·æ <dav...@ah...>]

尊敬的客户：
 您好，我司是专业域名主机提供商。优惠的价格及高速稳定的主机赢得了全国客户的肯定。
国际域名 80元
国内域名 300元
网络实名　500元（直接敲入中文即可到达您的网站，买网络实名赠送一个国际域名）
200M(纯HTML)送国际域名只需150元
60M(asp,access等)送域名和邮箱只需236元
200M(asp,access等)送域名和邮箱只需336元
网页制作，普通型企业网站，只需2000元。（功能多多，还赠送域名，空间及邮箱，全套服务15天即可完成）
更多......详见http://www.ondns.com
诚征全国代理，优惠多多。
请向QQ：1761020 MAIL：we...@on...索取代理价格表

我公司是一家专门致力于高新网络技术研究和开发的公司，有着多年的经验，在做虚拟主机方面我们
有着绝对的优势：

①直接接入广州国际骨干网2.5G，机房100M带宽共享；
②拥有一批高级的网络管理人员，主机由我们自己严格管理；
③对所有的网站内容我们都进行备份，并进行实时监控保证了其稳定性；

 谢谢!　　
　　顺祝
商！

百忙中打扰了您，深感抱歉。如不想收到此类邮件。请过滤拒收此邮件：dav...@ah...
============================================
客户专员：肖先生 服务电话：0592-5558771和5557491 5557492
邮编：361009 传真：0592-5557491
http://www.ondns.com    mail:we...@on...
============================================




























































































使用极星邮件群发，无须通过邮件服务器，直达对方邮箱，速度绝对一流！
下载网址：http://www.lovexin.com，更多免费的超酷软件等你来下……

----------------------------------------------------
INFORMATION
This message has been sent using a trial-run version
of the TSmtpRelayServer Delphi Component.
----------------------------------------------------

Re: [Phpwiki-talk] rss

[<la...@us...>]

I looked into this myself for Tony a couple of days ago (or yesterday - they 
all seem the same ...).  

For the record:

Postnuke can't (yet) do RSS 1.0, and doesn't even do RSS 0.91 very well.  So 
its not a phpWiki problem (phew)

Also, is there strictly anything wrong with using dc:description instead of 
description?  I thought that the first was just a fully namespace-qualified 
version of the latter.  The parser ought to be able to cope with it.  

Lawrence


Quoting Jeff Dairiki <da...@da...>:

> > > Also, note that at least one validator didn't like 
> > > what it saw in the current phpWiki feed.
> > 
> > At first look, that looks like a 0.9x, 2.0 centric
> > validator, so it's no surprise it doesn't like RDF 1.0.
> > I'll look into a bit more, though... Thanks for the heads up.
> 
> As it turns out, the validator did have a valid (but minor) beef.
> I doubt it has anything to do with your postnuke problems.
> 
> (Gory details: <description> is a required element of <channel>
> in RSS 1.0 --- we (I) were using <dc:description> instead of
> <description>...) 
> 
> I just checked in the fixes to CVS.
> 

Re: [Phpwiki-talk] rss

[Tony L. <la...@is...>]

On Wed, 30 Oct 2002, Jeff Dairiki wrote:

> As it turns out, the validator did have a valid (but minor) beef.
> I doubt it has anything to do with your postnuke problems.
> 
> (Gory details: <description> is a required element of <channel>
> in RSS 1.0 --- we (I) were using <dc:description> instead of
> <description>...) 
> I just checked in the fixes to CVS.

I saw only the UN_en fix, in a file that does not 
exist in the pn module setup. Was there something 
else, in RssWriter.php perhaps? 

> Is postnuke supposed to be able to grok RSS 1.0?

I hear that it may not. 
This is what is being used, for your reference. 

http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=rss.php

on a different matter, I noticed that some double-byte characters 
got chewed up pretty significantly when I used diff earlier today. 
I had been lucky up until then. I tried to use page history to 
generate a URL where one could see how the characters were being 
spindled, but ran into a "cannot access that file directly" 
nymph. Or maybe it was an imp. 
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=MultilingualWikiTalk

Re: [Phpwiki-talk] rss

[Jeff D. <da...@da...>]

> > Also, note that at least one validator didn't like 
> > what it saw in the current phpWiki feed.
> 
> At first look, that looks like a 0.9x, 2.0 centric
> validator, so it's no surprise it doesn't like RDF 1.0.
> I'll look into a bit more, though... Thanks for the heads up.

As it turns out, the validator did have a valid (but minor) beef.
I doubt it has anything to do with your postnuke problems.

(Gory details: <description> is a required element of <channel>
in RSS 1.0 --- we (I) were using <dc:description> instead of
<description>...) 

I just checked in the fixes to CVS.

Re: [Phpwiki-talk] rss

[Jeff D. <da...@da...>]

There are two nearly completely orthogonal branches of RSS.

 o RSS 0.9x, and RSS 2.0  (the "Dave Winer" specs) (non-RDF).

 o RSS 1.0 (a subset of RDF).

Note that the numbering scheme is not completely chronological
(nor, even, logical.)


> Postnuke's code for reading RSS doesn't quite grok the phpWiki
> recentchanges feed, whether the feed be from the phpWiki site on
> sourceforge, or that generated by the module on the ISSHO Kikaku site
> (running Postnuke).

Is postnuke supposed to be able to grok RSS 1.0?

> In the meantime, 
> might there be some older phpWiki code that I might use 
> to generate something in a shade of 0.9 or otherwise less 
> state-of-the-art? 

Support for RSS 0.91 has been in PhpWiki since 1.3.3, but
it looks like the postnuke version was forked before that.
(It's accessed using a format=rss091 rather than format=rss
query arg.)
 
> Also, note that at least one validator didn't like 
> what it saw in the current phpWiki feed.

At first look, that looks like a 0.9x, 2.0 centric
validator, so it's no surprise it doesn't like RDF 1.0.
I'll look into a bit more, though... Thanks for the heads up.

[Phpwiki-talk] rss

[Tony L. <la...@is...>]

On Mon, 28 Oct 2002, Jeff Dairiki wrote:

> connection --- apparently, as an anti-spam measure, your
> ISP blocks mail from all such hosts.  This is the first
> time I've encountered such a restriction...

Thanks for the heads-up. 
It looks like my ISP's spam filter is over-zealous; I've disengaged 
it now (I hope). 

Postnuke's code for reading RSS doesn't quite grok the phpWiki
recentchanges feed, whether the feed be from the phpWiki site on
sourceforge, or that generated by the module on the ISSHO Kikaku site
(running Postnuke). There are some notes about that here: 
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=MultilingualWikiTalk

The Postnuke folks may come up with a revision of the 
code that can handle the phpWiki's feed. In the meantime, 
might there be some older phpWiki code that I might use 
to generate something in a shade of 0.9 or otherwise less 
state-of-the-art? 

Also, note that at least one validator didn't like 
what it saw in the current phpWiki feed. Interestingly 
enough, I learned of this from the envolution site 
(a cms still quite similar to Postnuke, I think) 
whose phpWiki feed _is_ being picked up being parsed 
a bit better than Postnuke. 

Whether the validator has a point or not, I don't 
know, but I thought you might like to know. 

-T.L. 

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib HtmlElement.php,1.25,1.26 PageList.php,1.40,1.41 diff.php,1.38,1.39

[Carsten K. <car...@us...>]

Hi Jeff,

A global sounds fine by me. I had been thinking about a more generic 
entity function, something like html::entity(entityname, $repetitions = 
1) but I can't see any real use for that.

A global $NBSP might be handy in templates and it's shorter to type out 
than HTML::nbsp().

Not sure where a good place is to insert a global declaration of $NBSP, 
back in HtmlElement.php where the constant was?

Carsten

--- HtmlElement.php	17 Sep 2002 02:35:31 -0000	1.25
@@ -75,9 +75,16 @@ function HTML (/* $content, ... */) {
  }

-define('NBSP', "\xA0");         // iso-8859-x non-breaking space.
+global $NBSP = new RawXML(" ");

On Monday, October 28, 2002, at 08:44  pm, Jeff Dairiki wrote:

>> (Maybe this should just always output an html entity? We currently 
>> use a
>> raw "\xA0" character for iso-8859-1 so this value was left as is.)
>
> IIRC, I introduced the '\xA0' as a hack so that NBSP could be defined
> as a constant.  Since that doesn't work anymore, I think always using
> the   entity is the way to go.
>
> An alternative to the nbsp() function would be a $NBSP global.
> I'm not sure which is the better of those two choices.  (Using a
> function to generate a constant could be confusing.)
>

Re: [Phpwiki-talk] dsn for sockets

[Peter H. <ph...@gm...>]

HI,

On Mon, 28 Oct 2002 13:39:38 -0500, you wrote:

>The dsn you gave is working for me too.
>
>Since PhpWiki includes some PEAR code now does it mean this problem has=20
>been fixed, or am I just lucky that the PEAR that came with my system=20
>is new enough

what problem? This is the way you specify sockets, take a look into
lib/pear/DB.php in function parseDSN($dsn)




Have a nice thread,
Peter

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

[Carsten K. <car...@us...>]

On Monday, October 28, 2002, at 04:29  pm, Jeff Dairiki wrote:

> IIRC, the new markup code doesn't use any magic marker characters
> (FieldSeparator), so the issue is mostly moot.

Hehe, I didn't realize this, thanks for pointing it out. So I changed 
that magic marker back and of course it has no effect and UTF-8 is 
still working in the latest CVS. ^^

> There may be less minor problems with the searching functionality.
> PHP regexps are not unicode aware... (does the latest PHP have
> unicode support yet?)  MySQL knows nothing about unicode, so any
> pattern/string matching done in MySQL queries is problematic.

Yes the regexp stuff definitely could be a problem. I'll look at the 
PHP website to see how the mb functions are coming along.

Preliminary informal tests so far (read: goofing around) with utf-8 
shows that searching for Japanese words works, and surprisingly 
syntax-highlighting in a FullText search looks just fine too.

Logins with utf-8 Japanese text doesn't work, probably due to 
bumpywords checking. In diffs the line prefixes for non-changed lines 
and line-endings show with a garbage character, but this might just be 
my browser. Otherwise the only issue I noticed is that square brackets 
must be used for Japanese text. This is expected because there aren't 
any BumpyWords and so it's not really a problem.

I don't want to jump to any conclusions because I can't really read 
Japanese at all. I'm interested in how well this works for other people 
using the latest CVS PhpWiki. Change your CHARSET to utf-8 in index.php 
so your browser knows which charset to use. Try pasting some text in 
from http://www.yahoo.co.jp/ or something and linkify a few words with 
[ ].

Carsten

Re: [Phpwiki-talk] Re: phpWiki and utf-8/double-byte

[Jeff D. <da...@da...>]

> Do you think it would cause any problems to just commit this change of 
> FieldSeparator to '\xff'?

Yes it would.   '\xff' is a printing character in the ISO-8859-x
encodings.  (In iso-8859-1 it's a "latin small letter y with diaeresis".)

> I'm going to leave it this way on my Wiki for a while to see how it 
> works out as a permanent change. If this is not a good idea, maybe add 
> a check in config.php for CHARSET==utf-8 and set FieldSeparator 
> accordingly?

That would be okay, I think.  Switching to one of the non-used ASCII
control characters (in the 0x01 - 0x1f range) would probably be okay,
too (as long as care is taken to strip that character from form input,
etc...)   If you want to do anything, it's probably safer to stick
with our current setting except for UTF-8.


But, note that in the current CVS code, lib/transform.php is no longer
used.
(Though the code is still there.)  Both old and new markup 
get run through the new markup engines (old markup goes through a
pre-processor to hack it up into new markup...)

IIRC, the new markup code doesn't use any magic marker characters
(FieldSeparator), so the issue is mostly moot.


> So far the only (minor) problems I see running PhpWiki CVS in utf-8 are 
> the field names on the DebugInfo page and character translation problem 
> on the Sign In page.

Since PhpWiki was never designed with multi-byte character encodings
in mind (really it's only been well(?) tested under iso-8859-1),
I suspect that numerous small problems will show up (most, probably,
could be easily fixed).

There may be less minor problems with the searching functionality.
PHP regexps are not unicode aware... (does the latest PHP have
unicode support yet?)  MySQL knows nothing about unicode, so any
pattern/string matching done in MySQL queries is problematic.

[Phpwiki-talk] Logo on separate line due to css

[Oliver B. <ob...@de...>]

Hello All,

I think that I have been reading about this anywhere but don't remember 
where: in phpwiki-heavy.css the line

  img { vertical-align: baseline; } 

causes that the "Php Wiki" logo is displayed on the left side above the 
navbar when viewed with IE5 or IE6. Opera shows the logo as expected.

(PhpWiki 1.3.3 with "default" theme")

In the nightly snapshot it's on the right side, but still a separate line 
between the navbar and the page name.

I don't know whether it hurts to remove this line. IE and Opera look fine 
without, I can also try mozilla but have no NS installed.

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] Date not shown...

[Oliver B. <ob...@de...>]

Peter Holm wrote:

> the date shown does not generate correctly

I forgot to mention that there could arise more localization problems. For 
example I needed putenv("LC_ALL=de"); to get German strings, and the pages 
from locale/*/pgsrc were overwritten by default (English) pages of the 
same name when creating a new Wiki. Therefore I copied the German pages to 
the default pgsrc...

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] Date not shown...

[Oliver B. <ob...@de...>]

Peter Holm wrote:

> everything seems to work now, BUT the date shown does not generate
> correctly:
> 
> Last edited on October , 2002 6:37 pm
> 
> is there some known bug about this?

Be aware that in PhpWiki 1.3.3 there are themes with hard coded date 
formats ($Theme->setDateFormat).

And "You'll have to experiment to find the correct setting" for LC_TIME.

Or don't care about LC_TIME and use (change) $Theme->setDateFormat in the 
theme.

Oliver
-- 
Oliver Betz, Muenchen