phpwiki-talk

Re: [Phpwiki-talk] Tilde inconsistencies

[Reini U. <ru...@x-...>]

Matthew Palmer schrieb:
> On Sat, Jun 19, 2004 at 12:50:26PM +0200, Reini Urban wrote:
>>Matthew Palmer schrieb:
>>
>>>On Sat, Jun 19, 2004 at 09:28:49AM +0200, Reini Urban wrote:
>>>
>>>
>>>>I don't see any inconsistency with the usage of "~" as
>>>>escape character, but I see the need to explain it better.
>>>>"~ " (tilde space) => <~> and not <space> is the only exception, which 
>>>>is not documented, but it is what the user expects.
>>>>
>>>>Ok to add this paragraph to TextFormattingRules?
>>>
>>>
>>>Is there no chance that the logic can be simplified somewhat?  There are 7
>>>separate tilde rules in that list -- basically, someone thinking "what are
>>>the tilde-handling rules in PHPWiki?" is going to fill their brain's L1
>>>cache.
>>>
>>>What about "single tilde suppresses specialness, and under no circumstances
>>>gets printed, two tildes produces one visible tilde"?  In other words, "if
>>>you want a tilde, give two".
>>
>>There is only one rule ("The tilde '~' is the Escape Character") and six 
>>examples.
> 
> No, there's six other rules, dealing with exceptions to the rule you've just
> provided.  If there weren't any rules other than the one you provided, there
> would be no way to display a tilde, because there would be no rule providing
> that functionality.

ok, for the language lawyers:

There is only one rule ("The tilde '~' is the Escape Character") and two 
minor exceptions raising the importance of the whitespace rule and the 
bracketurl link:

apply rule 1:
'~~'  => ~
apply rule 1:
'~link'  => ~link (escape the link)
apply rule 1:
'~~link'  => ~[link]
apply rule 1:
'link~user'  => [linkuser]  (escape the u)

exception 1: (formally strict this is in an exception, but
               with the whitespace rule above is not)
'~ ' => ~

exception 2: (formally strict this is in an exception, but
               with the "brackets force links" rule below it is not)
'~' inside brackets are not escaped.

Both exceptions seem to be natural, and would barely need special 
documentation. Thats why Jeff didn't see the need to add it to 
TextFormattingRules. Now with the examples it should be clear.

All these rules only apply to NewMarkup.

OldMarkup has a more complicated ruleset of escapes:
   "[[" => [,
   "]]" => ]
   !WikiWord => WikiWord (escape the link)

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Tilde inconsistencies

[Matthew P. <mp...@he...>]

On Sat, Jun 19, 2004 at 12:50:26PM +0200, Reini Urban wrote:
> Matthew Palmer schrieb:
> >On Sat, Jun 19, 2004 at 09:28:49AM +0200, Reini Urban wrote:
> >
> >>I don't see any inconsistency with the usage of "~" as
> >>escape character, but I see the need to explain it better.
> >>"~ " (tilde space) => <~> and not <space> is the only exception, which 
> >>is not documented, but it is what the user expects.
> >>
> >>Ok to add this paragraph to TextFormattingRules?
> >
> >
> >Is there no chance that the logic can be simplified somewhat?  There are 7
> >separate tilde rules in that list -- basically, someone thinking "what are
> >the tilde-handling rules in PHPWiki?" is going to fill their brain's L1
> >cache.
> >
> >What about "single tilde suppresses specialness, and under no circumstances
> >gets printed, two tildes produces one visible tilde"?  In other words, "if
> >you want a tilde, give two".
> 
> There is only one rule ("The tilde '~' is the Escape Character") and six 
> examples.

No, there's six other rules, dealing with exceptions to the rule you've just
provided.  If there weren't any rules other than the one you provided, there
would be no way to display a tilde, because there would be no rule providing
that functionality.

- Matt

Re: [Phpwiki-talk] Tilde inconsistencies

[Reini U. <ru...@x-...>]

Matthew Palmer schrieb:
> On Sat, Jun 19, 2004 at 09:28:49AM +0200, Reini Urban wrote:
> 
>>I don't see any inconsistency with the usage of "~" as
>>escape character, but I see the need to explain it better.
>>"~ " (tilde space) => <~> and not <space> is the only exception, which 
>>is not documented, but it is what the user expects.
>>
>>Ok to add this paragraph to TextFormattingRules?
> 
> 
> Is there no chance that the logic can be simplified somewhat?  There are 7
> separate tilde rules in that list -- basically, someone thinking "what are
> the tilde-handling rules in PHPWiki?" is going to fill their brain's L1
> cache.
> 
> What about "single tilde suppresses specialness, and under no circumstances
> gets printed, two tildes produces one visible tilde"?  In other words, "if
> you want a tilde, give two".

There is only one rule ("The tilde '~' is the Escape Character") and six 
examples.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Tilde inconsistencies

[Matthew P. <mp...@he...>]

On Sat, Jun 19, 2004 at 09:28:49AM +0200, Reini Urban wrote:
> I don't see any inconsistency with the usage of "~" as
> escape character, but I see the need to explain it better.
> "~ " (tilde space) => <~> and not <space> is the only exception, which 
> is not documented, but it is what the user expects.
> 
> Ok to add this paragraph to TextFormattingRules?

Is there no chance that the logic can be simplified somewhat?  There are 7
separate tilde rules in that list -- basically, someone thinking "what are
the tilde-handling rules in PHPWiki?" is going to fill their brain's L1
cache.

What about "single tilde suppresses specialness, and under no circumstances
gets printed, two tildes produces one visible tilde"?  In other words, "if
you want a tilde, give two".

- Matt

[Phpwiki-talk] Re: [phpwiki - Help] RE: =?ISO-8859-1?Q?Can=B4t_login_as_A?= =?ISO-8859-1?Q?dmin?=

[Reini U. <ru...@x-...>]

SourceForge.net schrieb:
> Read and respond to this message at: 
> https://sourceforge.net/forum/message.php?msg_id=2625645
> By: marcusmoeller
> 
> Okay, that works for me now. Thanks. Only got one Problem. It seems that a normal
> user cannot store his/her passwor. I allways get an errot message like:
> 
> Password cannot be changed. No changes.

The logic to display this message was wrong. I fixed that yesterday.
It displayed "Password cannot be changed" even it was already changed 
with DBAUTH_AUTH_UPDATE or DBAUTH_PREF_UPDATE.

The whole db pref handling was broken.

> I thoght Passwords are stored within the users personal page ?!? 

That depends on how you did configure AUTH and PREFS.
With db prefs it is not stored in the users homepage, but with the 
DBAUTH_PREF_UPDATE statement instead.
With db auth and DBAUTH_AUTH_UPDATE defined, it is not stored in the 
prefs table, but with the DBAUTH_AUTH_UPDATE statement instead.

> Do i need a special file for that?

no. Just config.ini

> Marcus
> PS: I haven´t got root access to the server the wiki runs on.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Tilde inconsistencies

[Reini U. <ru...@x-...>]

I don't see any inconsistency with the usage of "~" as
escape character, but I see the need to explain it better.
"~ " (tilde space) => <~> and not <space> is the only exception, which 
is not documented, but it is what the user expects.

Ok to add this paragraph to TextFormattingRules?

!!! Character Formatting

* All special HTML characters are displayed as is. Exceptions below.
* See [Emphasis|#Emphasis].
* There's no syntax for font tags or color attributes.
* The tilde '~~' is the _Escape Character_:
** A single tilde '~~' followed by nothing gets rendered as a single 
tilde. => ~
** Two tilde '~~~~' get rendered as a single tilde. => ~~
** A single tilde before a link ('~~http://foo.bar') prevents linking.
    => ~http://foo.bar
** Two tildes before a link ('~~http://foo.bar') produce a tilde
    followed by the hyperlinked URL.
    => ~~http://foo.bar
** A tilde inside an URL gets removed, unless it's formatted inside
    ~[ ~] brackets.
    Two tildes inside an URL (without brackets) become a single tilde.
    => [http://foo.bar/~user] or http://foo.bar/~~user

Please note improvements at 
http://phpwiki.sf.net/phpwiki/TextFormattingRules

We probably have to add a note about special non-ascii or non-latin 
characters, if it's supported by the native CHARSET or not, and how to 
add such chars. (e.g. japanese euc-jp chars to iso-8859-1 wiki's).


Matthew Palmer schrieb:
> Another bug report I've gotten:
> http://bugs.debian.org/227953
> 
> Basically, ~ out by itself is still a tilde, but in contact with anything
> else it's made invisible and will suppress specialness.
> 
> Two problems with this:
> 
> 1) It's inconsistent.  While the rule isn't too hard to follow ("If the
> tilde is touching anything, double it to make it display"), it's a PITA. 
> I'd be inclined to simplify it to "if you want a tilde, type two".
> 
> 2) The method to produce a visible tilde is thoroughly undocumented in
> TextFormattingRules, as far as I can see.  Hence, discovering the rules is,
> pretty much, up to individual experimentation.  See the above-linked bug
> report for a demonstration of one person's experimentation in that area.
> 
> Do others consider the suppression of tildes when they are not used
> immediately prior to a "special" text a bug?  Should the remaining
> exceptions be ironed out, or is it all good as-is and should just be
> documented?
> 
> - Matt
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] cvs access to dfrankow

[Reini U. <ru...@x-...>]

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Dan,
>> I just gave you CVS access to sf.net.
> 
> Thanks!
> 
>> I added now the preliminary lib/wikilens,
>> and changed plugin/RateIt.php (which is responsible for the action, 
>> not lib/rate.php) and the theme.
> 
> Okay.
> 
>> Please fix that to your needs and think of the general wide audience.
> 
> We always would like to do that, if we can.
>> (not only peardb, ...)
> 
> Hmm. That is tougher. We probably will not broaden beyond PearDB for a 
> long time. We just don't have the people to do it and support it. 

dbi->query is a generic query that works for pear and adodb, and returns 
the backend specific iterator, which name is in ->iter_class.

> Heck, I'm swamped just keeping up with your changes (!), in addition to the 
> other things I do.
> 
>> Some iterator is currently broken. Probably more.

The iterator per se is not broken, but the query returns no result 
suitable to the iterator.

>> But please don't touch any other core files, send me the needed 
>> patches instead please.
> 
> 
> I definitely only want to change files that you are okay with. I won't 
> change core files.
> 
> What about adding unit tests?

Sure. I forgot these.
But note that I fixed and improved the test framework a bit. It works 
now for cli and web (and my debugger).

>> I also added two more star icon sets with another prefix, but is isn't 
>> completed yet. (small and big red stars)
>>
>> Maybe the external rating engines will be removed, but for now I let 
>> the interface in. You know that I was playing with a mysql version of 
>> suggest and the java server from your group will also be available 
>> soon. (hopefully)
> 
> MultiLens, the recommendation engine that is used in MovieLens, is now 
> open source, registered at sourceforge.

Yeah, just saw it. Great.

> We will probably be using our built-in PHP recs for awhile, since it is 
> more of a "small-world" recommender.
-- 
Reini Urban
http://phpwiki.sf.net/

Re: [Phpwiki-talk] cvs access to dfrankow

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

> Dan,
> I just gave you CVS access to sf.net.


Thanks!

> I added now the preliminary lib/wikilens,
> and changed plugin/RateIt.php (which is responsible for the action, 
> not lib/rate.php) and the theme.


Okay.

> Please fix that to your needs and think of the general wide audience.


We always would like to do that, if we can.

> (not only peardb, ...)


Hmm. That is tougher. We probably will not broaden beyond PearDB for a 
long time. We just don't have the people to do it and support it. Heck, 
I'm swamped just keeping up with your changes (!), in addition to the 
other things I do.

> Some iterator is currently broken. Probably more.
> But please don't touch any other core files, send me the needed 
> patches instead please.


I definitely only want to change files that you are okay with. I won't 
change core files.

What about adding unit tests?

> I also added two more star icon sets with another prefix, but is isn't 
> completed yet. (small and big red stars)
>
> Maybe the external rating engines will be removed, but for now I let 
> the interface in. You know that I was playing with a mysql version of 
> suggest and the java server from your group will also be available 
> soon. (hopefully)


MultiLens, the recommendation engine that is used in MovieLens, is now 
open source, registered at sourceforge.

We will probably be using our built-in PHP recs for awhile, since it is 
more of a "small-world" recommender.

Dan

[Phpwiki-talk] Tilde inconsistencies

[Matthew P. <mp...@he...>]

Another bug report I've gotten:
http://bugs.debian.org/227953

Basically, ~ out by itself is still a tilde, but in contact with anything
else it's made invisible and will suppress specialness.

Two problems with this:

1) It's inconsistent.  While the rule isn't too hard to follow ("If the
tilde is touching anything, double it to make it display"), it's a PITA. 
I'd be inclined to simplify it to "if you want a tilde, type two".

2) The method to produce a visible tilde is thoroughly undocumented in
TextFormattingRules, as far as I can see.  Hence, discovering the rules is,
pretty much, up to individual experimentation.  See the above-linked bug
report for a demonstration of one person's experimentation in that area.

Do others consider the suppression of tildes when they are not used
immediately prior to a "special" text a bug?  Should the remaining
exceptions be ironed out, or is it all good as-is and should just be
documented?

- Matt

[Phpwiki-talk] cvs access to dfrankow

[Reini U. <ru...@x-...>]

Dan Frankowski schrieb:
> Unfortunately, I have not yet had time to try to fix this. I have 
> checked that they it is still in the current CVS version.

Just fixed it, thanks. (say print a better warning)

Dan,
I just gave you CVS access to sf.net.

I added now the preliminary lib/wikilens,
and changed plugin/RateIt.php (which is responsible for the action, not 
lib/rate.php) and the theme.

Please fix that to your needs and think of the general wide audience.
(not only peardb, ...)
Some iterator is currently broken. Probably more.
But please don't touch any other core files, send me the needed patches 
instead please.

I also added two more star icon sets with another prefix, but is isn't 
completed yet. (small and big red stars)

Maybe the external rating engines will be removed, but for now I let the 
interface in. You know that I was playing with a mysql version of 
suggest and the java server from your group will also be available soon. 
(hopefully)
-- 
Reini Urban
http://phpwiki.sf.net/

Re: [Phpwiki-talk] bug in crao theme...

[Reini U. <ru...@x-...>]

John Cole schrieb:
> In your php.ini file you need to turn on log_errors and set error_log to a
> filename.

Just fixed the bug in the Crao theme.
I simply forgot the mass search & replace "$Theme" to "$WikiTheme" there 
also.

> 
> John Cole
> 
> -----Original Message-----
> From: Stan Berka [mailto:sb...@po...]
> Sent: Thursday, June 17, 2004 1:16 PM
> To: John Cole
> Cc: php...@li...
> Subject: Re: [Phpwiki-talk] bug in crao theme...
> 
> 
> Where do I find the php error log?  Many times I get blank page from 
> phpwiki and always wonder where an error message is if any.
> 
> John Cole wrote:
> 
> 
>>Seems that the Crao theme is broken.  I just get a blank page (well just
>>part of a page).
>>
>>Here is the php error log:
>>
>>[17-Jun-2004 08:23:41] PHP Fatal error:  Call to a member function on a
>>non-object in c:\program files\apache
>>group\apache\htdocs\phpwiki\lib\Template.php(132) : eval()'d code on line
> 
> 20
> 
>>Here is the contents of the page:
>>
>><?xml version="1.0" encoding="iso-8859-1"?>
>><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>><html xmlns="http://www.w3.org/1999/xhtml">
>><head>
>><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
>><meta name="robots" content="index,follow" />
>><meta name="keywords" content="Home Page, PhpWiki" />
>><meta name="language" content="en" />
>><meta name="document-type" content="Public" />
>><meta name="document-rating" content="General" />
>><meta name="generator" content="PhpWiki" />
>><meta name="PHPWIKI_VERSION" content="1.3.11pre" />
>><base href="http://devsup1.uai.int/phpwiki/index.php/" />
>>
>>I'll be sure to test all themes when I get a chance.  We usually use
> 
> MacOSX,
> 
>>but the WordPress and MonoBook look really good.
>>
>>John Cole


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

[Matthew P. <mp...@he...>]

On Thu, Jun 17, 2004 at 09:48:56PM +0200, Oliver Betz wrote:
> Reini Urban wrote:
> 
> > 2. dump the content of an new existing config/config.ini to a
> >     config/config.php (after timestamp comparison), for faster
> >     load time. This is Matthew's idea. mediawiki's installer does
> 
> after all, what's the advantage of the INI file over the old *.php,  
> avoiding the "if (!defined..."?

Not executable, far easier syntax, far more *regular* syntax, and the range
of potential errors is far less.

- Matt

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

[Joby W. <joby@u.washington.edu>]

1) Ease of manual configuration - particularly for the non php inclined. 
  2) Encourages better config behavior rather than large collections of 
arrays.
3) Would allow for other tools to be developed to edit the configuration.
4) others...


Joby Walker




Oliver Betz wrote:
> Reini Urban wrote:
> 
> 
>>2. dump the content of an new existing config/config.ini to a
>>    config/config.php (after timestamp comparison), for faster
>>    load time. This is Matthew's idea. mediawiki's installer does
> 
> 
> after all, what's the advantage of the INI file over the old *.php,  
> avoiding the "if (!defined..."?
> 
> Oliver

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

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

Reini Urban wrote:

> 2. dump the content of an new existing config/config.ini to a
>     config/config.php (after timestamp comparison), for faster
>     load time. This is Matthew's idea. mediawiki's installer does

after all, what's the advantage of the INI file over the old *.php,  
avoiding the "if (!defined..."?

Oliver
-- 
Oliver Betz, Muenchen

RE: [Phpwiki-talk] bug in crao theme...

[John C. <joh...@ua...>]

Stan,

In your php.ini file you need to turn on log_errors and set error_log to a
filename.

John Cole

-----Original Message-----
From: Stan Berka [mailto:sb...@po...]
Sent: Thursday, June 17, 2004 1:16 PM
To: John Cole
Cc: php...@li...
Subject: Re: [Phpwiki-talk] bug in crao theme...


Where do I find the php error log?  Many times I get blank page from 
phpwiki and always wonder where an error message is if any.

John Cole wrote:

>Seems that the Crao theme is broken.  I just get a blank page (well just
>part of a page).
>
>Here is the php error log:
>
>[17-Jun-2004 08:23:41] PHP Fatal error:  Call to a member function on a
>non-object in c:\program files\apache
>group\apache\htdocs\phpwiki\lib\Template.php(132) : eval()'d code on line
20
>
>Here is the contents of the page:
>
><?xml version="1.0" encoding="iso-8859-1"?>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
><html xmlns="http://www.w3.org/1999/xhtml">
><head>
><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
><meta name="robots" content="index,follow" />
><meta name="keywords" content="Home Page, PhpWiki" />
><meta name="language" content="en" />
><meta name="document-type" content="Public" />
><meta name="document-rating" content="General" />
><meta name="generator" content="PhpWiki" />
><meta name="PHPWIKI_VERSION" content="1.3.11pre" />
><base href="http://devsup1.uai.int/phpwiki/index.php/" />
>
>I'll be sure to test all themes when I get a chance.  We usually use
MacOSX,
>but the WordPress and MonoBook look really good.
>
>John Cole
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>  
>

Re: [Phpwiki-talk] bug in crao theme...

[Stan B. <sb...@po...>]

Where do I find the php error log?  Many times I get blank page from 
phpwiki and always wonder where an error message is if any.

John Cole wrote:

>Seems that the Crao theme is broken.  I just get a blank page (well just
>part of a page).
>
>Here is the php error log:
>
>[17-Jun-2004 08:23:41] PHP Fatal error:  Call to a member function on a
>non-object in c:\program files\apache
>group\apache\htdocs\phpwiki\lib\Template.php(132) : eval()'d code on line 20
>
>Here is the contents of the page:
>
><?xml version="1.0" encoding="iso-8859-1"?>
><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
><html xmlns="http://www.w3.org/1999/xhtml">
><head>
><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
><meta name="robots" content="index,follow" />
><meta name="keywords" content="Home Page, PhpWiki" />
><meta name="language" content="en" />
><meta name="document-type" content="Public" />
><meta name="document-rating" content="General" />
><meta name="generator" content="PhpWiki" />
><meta name="PHPWIKI_VERSION" content="1.3.11pre" />
><base href="http://devsup1.uai.int/phpwiki/index.php/" />
>
>I'll be sure to test all themes when I get a chance.  We usually use MacOSX,
>but the WordPress and MonoBook look really good.
>
>John Cole
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>  
>

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

[Joby W. <joby@u.washington.edu>]

Actually I was talking about a variant of #2.  Instead of an 
auto-creation of config.php (based of timestamp, etc), when using the 
CLI tool you can create a config.php from your config.ini.

#1 isn't a bad idea either, I'll put it on my todo list (though it won't 
make my initial commit).

Joby Walker
C&C Computer Operations Software Support Group


Reini Urban wrote:
> Dan Frankowski schrieb:
> 
>> One disadvantage: you'll always support two ways (ini and php). This 
>> requires more code maintenance. I claim you'd be happier if you could 
>> somehow easily migrate people, so in the end you only support one way. 
>> For example, offer a tool that takes an index.php and makes an INI 
>> file out of it. Then this tool can be deprecated and go away after a 
>> few releases.
>>
>> In general, supporting fewer ways to do the same thing in the long run 
>> is good.
> 
> 
> No, we are talking about two things:
> 
> 1. convert an existing old index.php to config/config.ini for
>    easier upgrades from < 1.3.10 to > 1.3.10
>    joby said he had something like this in the works.
> 
> 2. dump the content of an new existing config/config.ini to a
>    config/config.php (after timestamp comparison), for faster
>    load time. This is Matthew's idea. mediawiki's installer does
>    something like this also. The problem is the needed file
>    permission, similar to upload. Maybe we should ship an empty
>    but 446 config/config.php. (For freebsd it's easier, they
>    know the apache user in advance)
> 
>> Joby Walker wrote:
>>
>>> Matthew Palmer wrote:
>>>
>>>> Has anyone made any progress in this area?  The major hold-up for me
>>>> updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
>>>> Debian to rewrite their config files, which is unlikely to make them 
>>>> jump
>>>> for joy.
>>>
>>>
>>>
>>>
>>> I'm a good way toward being done.  Been busy with work, getting a new 
>>> laptop, and rebuilding my windows server at home.  Once I have the 
>>> CLI client working and tested I'll commit it.
>>>
>>>>
>>>> I did have one (potential) brain-wave, which would also, as a 
>>>> side-effect,
>>>> solve the major cause of complaint against the ini-file system.  Put
>>>> together code which parses the INI file and writes a config.php full of
>>>> define()s and whatever else takes your fancy, and source *that* 
>>>> instead of
>>>> doing an INI parse every invocation.  Then, just have a bit of code 
>>>> that
>>>> compares the mtime of config.ini with that of config.php, and rewrite
>>>> config.php if it's older than config.ini.  The first user to hit the 
>>>> new
>>>> config file gets a 1-2 second slowdown, maybe, but that can be 
>>>> server lag,
>>>> and everyone else gets smokingly fast response times.
>>>>
>>>
>>> Yeah thought of that too.  It'll be an option for the CLI client to 
>>> build a config.php.  Then if config.php is present it'll use it 
>>> instead of config.ini.

[Phpwiki-talk] Small InlineParser bug

[Dan F. <dfr...@cs...>]

Phpwiki folk,

Unfortunately, I have not yet had time to try to fix this. I have 
checked that they it is still in the current CVS version.

Dan

If you put [A B] in your page, but with a newline, this breaks. In other 
words:

[A
B]

It used to say (in our 1.3.9-based code):

lib/InlineParser.php:297: Notice[8]: Undefined offset: 4
lib/InlineParser.php:297: Notice[8]: Undefined offset: 3
lib/InlineParser.php:297: Notice[8]: Undefined offset: 2
lib/InlineParser.php:297: Notice[8]: Undefined offset: 1

Now it says:

lib/InlineParser.php:325: Notice[8]: Undefined offset: 4 (...repeated 4 
times)

[Phpwiki-talk] bug in crao theme...

[John C. <joh...@ua...>]

Seems that the Crao theme is broken.  I just get a blank page (well just
part of a page).

Here is the php error log:

[17-Jun-2004 08:23:41] PHP Fatal error:  Call to a member function on a
non-object in c:\program files\apache
group\apache\htdocs\phpwiki\lib\Template.php(132) : eval()'d code on line 20

Here is the contents of the page:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="robots" content="index,follow" />
<meta name="keywords" content="Home Page, PhpWiki" />
<meta name="language" content="en" />
<meta name="document-type" content="Public" />
<meta name="document-rating" content="General" />
<meta name="generator" content="PhpWiki" />
<meta name="PHPWIKI_VERSION" content="1.3.11pre" />
<base href="http://devsup1.uai.int/phpwiki/index.php/" />

I'll be sure to test all themes when I get a chance.  We usually use MacOSX,
but the WordPress and MonoBook look really good.

John Cole

[Phpwiki-talk] wikilens integration

[Reini U. <ru...@x-...>]

Dan Frankowski schrieb:
> Reini Urban wrote:
>> PS:
>> I'm considering this for DanFr as well, but at first I have to 
>> decouple the wikilens specific stuff more from our core.
>> This will affect lib/wikilens, lib/plugin/RateIt, and themes/wikilens.

Dan, I added now your lib/PageList.php to CVS,
and will soon cvs add lib/wikilens, where you should put your extensions.

I fixed a couple of things, please have a look.

I'm also attaching my versions of your wikilens libs,
but these are not tested yet.

> We'd also like very much to be decoupled, it's just not been highest on 
> our list. Hearing your thoughts would be appreciated.
> 
> We will probably not keep everything in lib/plugin/RateIt.php, because 
> we will want separate files for organizing code. (Imagine stuffing all 
> of lib into one file!). However, we'd be happy to keep our stuff in a 
> separate place, perhaps all in lib/wikilens, or lib/plugin/wikilens. Let 
> us know any opinions.
> 
> Also, eventually we will pull our stuff out of WikiDB into separate 
> files. I agree with you that a RatingsDB can be completely separate from 
> the page DB (although maybe defaulted the same).

I seperated a RatingsUser file.

> Also, a question about themes/wikilens. Mike is currently working on 
> making it work for us and removing duplicate code from other places. 
> However, does that mean that our users (who will want ratings widgets 
> for example) can't choose other themes? That seems too bad. Maybe it 
> would be cool to have a hook into a 'default'-theme-like place that 
> could show up in lots of different themes. This is not a high priority, 
> tho.

They can use other themes, but they have to customize them.
As the whole wikilens theme is just a customization of the default 
theme. Just add some hooks.

More on this later.

> Much higher priority is getting the user login, account creation, and 
> password management really smooth.
> 
> Also, for us, we are interested in versioned "structured data" (fields 
> like author and title for a book, location and cost for a restaurant, 
> etc.). I will send out a proposal for that soon. For those who are 
> worried I am trying to turn Phpwiki into some generic groupware, I say: 
> no, versioned (wiki-able!) structured data could be generically useful 
> in MANY different domains, plenty of which have nothing to do with 
> WikiLens, and it is still very wiki-flavored.
> 
>> And I don't have that much time yet to integrate their huge changes 
>> right now. Still 2 remaining fatals to catch.
> 
> I think it's fine that you postpone integration for more important, core 
> things. Making the user stuff really smooth, easy, and reliable would be 
> great.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Editing status...

[John C. <joh...@ua...>]

Editing is now working for Apache2/Apache1/IIS.

I'll test the virgin wiki load a little later today.

Reini,  are you ready to get a few functionality and cosmetic bug reports
now ;-)  They might all be minor but you might be able to fix them quickly.

I'll be testing the admin utils (rename, replace, etc...) later today as
well.  Those pages come up and look ok so far.

I don't have any showstoppers now.  I'll look into putting the current
version into production later today to give it a workout.

John Cole

Re: [Phpwiki-talk] Very simple ACL possible?

[Reini U. <ru...@x-...>]

Tom Chance schrieb:
> On Thursday 17 Jun 2004 10:10, Reini Urban wrote:
>>Tom Chance schrieb:
>>>Can I, using phpwiki 1.3.10, just set it up so that one user can have
>>>edit rights across the wiki, but not deletion rights? A very quick hack
>>>to the code will suffice, to hardcode this one user in. Any pointers
>>>would be appreciated.
>>
>>I would recommend the latest CVS version, since 1.3.10 had some bugs
>>with ACL's.
> 
> 
> But is the CVS version not going to have a lot of other bugs, especially if I 
> check out at the wrong moment? Or is it relatively stable?
> 
> This is a very important wiki, so I don't want to get complaints from 
> Government officials that they're getting strange errors.

It has less bugs than the latest release.
But if you wait a little, 1.3.11 is soon out.

There were two remaing bugs which I cannot yet reproduce on quite 
untypical setups. See John Cole's latest email report. (IIS, Apache2 on 
Windows)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] German translation issue

[Reini U. <ru...@x-...>]

Matthew Palmer schrieb:

> On Wed, Jun 16, 2004 at 03:10:58PM +0200, Reini Urban wrote:
> 
>>Matthew Palmer schrieb:
>>
>>>I'm dealing with the backlog of Debian phpwiki bugs, and I've come across
>>>one which doesn't appear to have been dealt with  upstream yet.
>>>
>>>The problem is a discrepancy between the po translation of 'RecentChanges'
>>>and the name of the RecentChanges equivalent in the german pgsrc.  The page
>>>name is "FrischeSeiten", while the po translation is "NeuesteAnderungen"
>>>(with an accent over the 'A').
>>>
>>>I don't know German, so I can't comment as to which one is better, but I
>>>think the two should certainly have the same name.
>>>
>>>For the original bug report, see http://bugs.debian.org/245812.
>>
>>Sorry, cannot reproduce.
>>po/de.po has "Neueste?nderungen" for "RecentChanges".
>>Exactly since 1.3.5 (Revision 1.82, Updated translation strings from 
>>Helmer Pardun.)
>>
>>There still exists locale/de/pgsrc/FrischeSeiten for legacy reasons,
>>but the links should all show "Neueste?nderungen".
> 
> 
> That's the problem.  The links all point to a page called
> "Neueste?nderungen", but the page they should be heading for is
> "FrischeSeiten".

No, the other way round.
FrischeSeiten was renamed to NeuesteÄnderungen with 1.3.5.

I just updated to old links in
SeiteFinden, StartSeite and GeringfügigeÄnderungen.
action=upgrade (in PhpWikiSystemverwalten - Upgrade) should bring the 
new pages uptodate.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Very simple ACL possible?

[Tom C. <li...@to...>]

On Thursday 17 Jun 2004 10:10, Reini Urban wrote:
> Tom Chance schrieb:
> > Can I, using phpwiki 1.3.10, just set it up so that one user can have
> > edit rights across the wiki, but not deletion rights? A very quick hack
> > to the code will suffice, to hardcode this one user in. Any pointers
> > would be appreciated.
>
> I would recommend the latest CVS version, since 1.3.10 had some bugs
> with ACL's.

But is the CVS version not going to have a lot of other bugs, especially if I 
check out at the wrong moment? Or is it relatively stable?

This is a very important wiki, so I don't want to get complaints from 
Government officials that they're getting strange errors.

Thanks,
Tom

Re: [Phpwiki-talk] Automatic config rewriter php -> ini

[Reini U. <ru...@x-...>]

Dan Frankowski schrieb:
> One disadvantage: you'll always support two ways (ini and php). This 
> requires more code maintenance. I claim you'd be happier if you could 
> somehow easily migrate people, so in the end you only support one way. 
> For example, offer a tool that takes an index.php and makes an INI file 
> out of it. Then this tool can be deprecated and go away after a few 
> releases.
> 
> In general, supporting fewer ways to do the same thing in the long run 
> is good.

No, we are talking about two things:

1. convert an existing old index.php to config/config.ini for
    easier upgrades from < 1.3.10 to > 1.3.10
    joby said he had something like this in the works.

2. dump the content of an new existing config/config.ini to a
    config/config.php (after timestamp comparison), for faster
    load time. This is Matthew's idea. mediawiki's installer does
    something like this also. The problem is the needed file
    permission, similar to upload. Maybe we should ship an empty
    but 446 config/config.php. (For freebsd it's easier, they
    know the apache user in advance)

> Joby Walker wrote:
>> Matthew Palmer wrote:
>>> Has anyone made any progress in this area?  The major hold-up for me
>>> updating Debian to 1.3.1[01] is that it'll force every PHPWiki user in
>>> Debian to rewrite their config files, which is unlikely to make them 
>>> jump
>>> for joy.
>>
>>
>>
>> I'm a good way toward being done.  Been busy with work, getting a new 
>> laptop, and rebuilding my windows server at home.  Once I have the CLI 
>> client working and tested I'll commit it.
>>
>>>
>>> I did have one (potential) brain-wave, which would also, as a 
>>> side-effect,
>>> solve the major cause of complaint against the ini-file system.  Put
>>> together code which parses the INI file and writes a config.php full of
>>> define()s and whatever else takes your fancy, and source *that* 
>>> instead of
>>> doing an INI parse every invocation.  Then, just have a bit of code that
>>> compares the mtime of config.ini with that of config.php, and rewrite
>>> config.php if it's older than config.ini.  The first user to hit the new
>>> config file gets a 1-2 second slowdown, maybe, but that can be server 
>>> lag,
>>> and everyone else gets smokingly fast response times.
>>>
>>
>> Yeah thought of that too.  It'll be an option for the CLI client to 
>> build a config.php.  Then if config.php is present it'll use it 
>> instead of config.ini.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/