phpwiki-talk

Re: [Phpwiki-talk] Ready for 1.3.8 ? Heads up

[<mal...@cs...>]

On Wed, Mar 17, 2004 at 10:18:26PM -0600, electron wrote:
> 
> An installer is useful because the whole point of our userbase is to be user
> friendly. This includes the admins. You shouldn't need a $40 an hour
> consultant to install phpwiki.

Indeed. I balked at installing 1.3.7 when I saw the following message:

// IMPORTANT NOTE: Use of the ***configurator.php*** to generate an
// index.php is depreciated, because it is out of date and a new
// configuration system is in the works (see the config directory, not
// finished yet though). DO compare or diff the configurator's output
// against this file if you feel you must use it to generate an
// index.php!

I would really like to use PhpWiki, but I have better things to do 
with my life than manually edit configuration files written in a language
I do not understand.

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/

                         "Blessed are the peacemakers,
                    for they will be called children of God."    -- Matt 5:9

Re: [Phpwiki-talk] SQLite database backend problems

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

Matthew Palmer schrieb:
> SQLite is missing a number of "convenience" features that make MySQL so nice
> to work with, like ALTER TABLE, SHOW TABLES, REPLACE INTO, AUTO_INCREMENT,
> and so on.  None of them are showstoppers, but they're all things that, once
> you've lived with them, you are loathe to part with... 

ALTER TABLE support comes with PearDB.

AUTO_INCREMENT is builtin, only the syntax is different.
A column declared INTEGER PRIMARY KEY will autoincrement.
See http://www.sqlite.org/faq.html#q1

SHOW TABLES support comes with PearDB and is builtin in the client.
I added a _table_exists() convenience function to the WikiDB backend, to 
be able to detect vriginb setup and create the phpwiki schema 
automatically. (not yet done)

REPLACE INTO is not in, and I am glad so. Better not use it.

There are several more omissions, but none of theme are needed in 
PhpWiki and all of them are non-ansi. http://www.sqlite.org/omitted.html

I will soon add the missing lib/pear/DB/sqlite.php, but first I have to 
fix my broken zend studio installation which loads the wrong file on 
debugging through sqlite.

I already added doc/INSTALL.sqlite as help for initial setup.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: phpwiki not running with php as cgi

[<th...@cc...>]

> On Wed, Mar 17, 2004 at 09:12:03PM -0800, Konstantin Zadorozhny wrote:
>>     Just for the record. I've got exactly the same poblem too. Apache
>> 1.3.X
>> and PHP 4.2.3 as cgi module.
>>     COMPRESS_OUTPUT = false - solved the problem.
>
> Good to know the problem can be solved that way.  Thanks for the
> confirmation.
>
> - Matt
>

Hi all,

thanks for your help! As this solution did not work for me - I had man
problems with php running as a cgi, I decided to use the Apache PHP-Modul
from now on and let just the software use the php-cgi, which definitely
requires php as cgi.
But I'm going to check it again, soon. Who knows :-)!?

Ben

Re: [Phpwiki-talk] Transclude.php - "local" service for vertical resize?

[Whit B. <wh...@tr...>]

On Thu, Mar 18, 2004 at 10:43:26AM -0500, Whit Blauvelt wrote:
> On Wed, Mar 17, 2004 at 10:27:33PM -0600, electron wrote:
> > The code is too simple and opens you up to all sorts of creative javascript
> > and cookie reading attacks.

> - Whose cookies are you concerned about? 

Trying to answer my own question: I suppose transcluded JavaScript could
read the user's cookies for the cookie site and then append them to URLs on
the transcluded page so that, for instance, some image is requested with the
cookies appended. 

Any security based solely on cookies is weak anyway. Any place security
really matters better by guarded by something more than the PHP session id.
But how much more than a regex to replace "getCookie" (with junk characters
rather than removal to avoid problems with getgetCookieCookie and etc.) is
needed to file off JavaScript's fangs?

Whit

Re: [Phpwiki-talk] Re: MySQL PHP rift

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

Reini Urban wrote:

> Reini Urban schrieb:
>
>> For PearDB I unimplemented the statement preparsing in 1.3.8, and use 
>> the same sprintf enhancement as in ADODB. We know our field types in 
>> advance and can properly quote it beforehand.
>>
>> I didn't benchmark it recently but I guess that ADODB is only about 
>> 5% faster now.
>

I am mostly ignorant of the PHP world (sorry) .. however, would it make 
sense to drop the PearDB backend then? If they each can (eventually) 
talk to a large number of databases, perhaps choosing one (the faster 
one?) would be good. Again, apologies for my ignorance, but I would 
strongly advocate paring down the number of supported backends to the 
minimal possible, perhaps even dropping the CVS or file backends (could 
use dbm instead?). Again, I don't know what that minimal set is.

The disadvantage of paring is people who currently are on a backend that 
becomes deprecated are sad. Perhaps that could be addressed with 
conversion scripts. The advantage is that (hopefully!) you end up 
spending less time messing with backend code, more time implementing 
front-end features!

In particular, I believe some of the things I'd like to do (and get 
accepted to the mainline in an ideal world) involve back-end changes, 
and implementing them on half a dozen backends is daunting.

Just a thought.

Dan

> Nope, Apache/1.3.26 (Win32) PHP/4.3.5RC1
> (same results with 4.2.2 with zend optimizer=15)
>
> ADODB with    php_adodb.dll is 25% faster than PearDB.
> ADODB without php_adodb.dll is 17% faster than PearDB.
>
> AllPages sortby=-mtime limit=100
> pear      1.251 s
> adodb     1.033 s
> adodb.dll 0.951 s

Re: [Phpwiki-talk] Ready for 1.3.8 ?

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

Reini Urban schrieb:
> Are we ready for the intermediate 1.3.8 release?

Another showstopper appeared in testing:
WikiUserNew object upgrading is not PHP5 compatible.
You cannot assign $this inside the constructor anymore.

   Fatal error: Cannot re-assign $this in 
f:\prog\php\phpwiki-dev\phpwiki\lib\WikiUserNew.php on line 269
   Apache/1.3.26 (Win32) PHP/5.0.0b4

I have workarounds ready but this will need at least another day.

And there are some more mysterious problems, probably
pref related.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Transclude.php - "local" service for vertical resize?

[Whit B. <wh...@tr...>]

On Wed, Mar 17, 2004 at 10:27:33PM -0600, electron wrote:
> The code is too simple and opens you up to all sorts of creative javascript
> and cookie reading attacks.

It was a demonstration of the method, not finished code. But since you're
more up on current attack methods in this context I'm curious about a few
things:

- What can be done with malicious code on a transcluded page? Are there
  dangers in the way the current plugin handles it?

- What additionally can be done with malicious code on a transcluded page
  that depends on its being relayed through the wiki server rather than
  sourced directly from a 3rd-party host?

- Whose cookies are you concerned about? The users can already read their
  own cookies. If the page being relayed depends on cookies, relaying it
  should simply cause the cookie-dependent features to fail, since the
  cookies aren't relayed (not without specifically coding to do that),
  right?

> We can always parse the html and use certain tags for the parser to make it
> slightly safer.

Sure, if you don't want JavaScript on the transcluded page you can run a
regex that strips that out (yes, it has to be a clever regex to be sure...).
Relaying it rather than having it transcluded directly gives you this
option, which you don't otherwise have. Wouldn't that be less danger?

> I've been experimenting with a OO php HTML parser. I'll see what I can come
> up with. Parsing also allows us to make allow rawhtml safe. And a couple
> other things come to mind....

Great! Thanks!

Whit

Re: [Phpwiki-talk] Ready for 1.3.8 ? Heads up

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

Matthew Palmer schrieb:
> On Wed, Mar 17, 2004 at 10:18:26PM -0600, electron wrote:
>>Defines suck. Defines are everywhere where they don't need to be. Index.php
>>is hugely bloated, complex and not documented well.
> 
> Index.php shouldn't be a .php file.  PHP has a wonderful .ini parser, and
> nobody uses it!  I'd recommend doing a switch (it might not be a 1.3 series
> thing, though) to a .ini config file, out of the web tree entirely.  An
> autowriter should be easy enough - load up index.php, iterate through the
> define list, and write it all to an ini file.  Lack of internal
> documentation on that will suck, though, but a default "edit-through" ini
> file should work well.
> 
>>Finally, Documentation, Doc, and Doc!
> I *think* that most of the stuff people are interested in is documented
> inside the Wiki somewhere, but a lot of things just aren't easily
> accessible.
> 
>>There is no rush to get to 1.4.0. 1.4.0 should be a complete, pretty, easy
>>to install and easy to administer wiki miniCMS. 

Well, the "easy to install" thing is controversial.
Let's discuss a ini-style config. For all my other projects I use simple 
ini files, because they are language independent, and can be moved away 
from the project tree. (to /etc/ e.g.)

Personally I prefer like the current way, esp. for wikifarms or 
multilingual sites, like PhpWikiDemo. index.php is easy to include and 
override behind the master script, a phpwiki.ini not. Why another 
parser? Just the db and admin password exposure is problematic.
Can somebody setup a PhpWiki:IniStyleConfig page for 1.4.0?
With pro's and contra's.

> Does SF have the ability to group "tasks" into releases, for planning
> purposes?  If everything were tracked there, it would make it easier for the
> externals like me to see how things are going.
> 
>>1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0.
> Erm, no.  The 1.3 series should be bugfixes only.  Even my SQLite stuff
> shouldn't really be released in a 1.3 series, unless it gets a *hell* of a
> lot of testing (which it will, shortly).

sqlite is only included as experimental backend, to attrack people to 
test it. For sure it's not a supported backend. But we have to start to 
do it.

> We need to create a new 1.4 branch to make all these developmental changes
> on. Fork from the existing 1.3 tree and start hacking.  Make those big
> changes like rewriting all the DB stuff.  Nothing in there should
> necessarily be working particularly well, although keeping as much stuff
> working as possible is good, because then the bold people can run it for
> kicks.  But 1.3 is not the place to be working towards 1.4, because then we
> either have no really new innovations in 1.4 (because we had to keep all the
> old crud working), or nothing works for a while in 1.3 (because things are
> being broken all the time and not everything is stable at the exact same
> time) or we don't make any releases (because nothing's working properly).

1.3.8 is basically a test release for 1.4.0 with enforced page 
permissions (this is the real major change), the new auth and pref 
layout, paging support and some DB enhancements.

The new DB enhancements are no big rewrite, just an minor update from 
the ADODB mainline, to support all other databases with adodb also,
nuke integration, and esp. to make use of the php_adodb.(so|dll), so we 
need the ADODB classes instead of the functions.
In fact it's more like a necessary ADODB cleanup.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: MySQL PHP rift

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

Reini Urban schrieb:
> For PearDB I unimplemented the statement preparsing in 1.3.8, and use 
> the same sprintf enhancement as in ADODB. We know our field types in 
> advance and can properly quote it beforehand.
> 
> I didn't benchmark it recently but I guess that ADODB is only about 5% 
> faster now.

Nope, Apache/1.3.26 (Win32) PHP/4.3.5RC1
(same results with 4.2.2 with zend optimizer=15)

ADODB with    php_adodb.dll is 25% faster than PearDB.
ADODB without php_adodb.dll is 17% faster than PearDB.

AllPages sortby=-mtime limit=100
pear      1.251 s
adodb     1.033 s
adodb.dll 0.951 s
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: MySQL PHP rift

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

electron schrieb:
> I didn't get the original message but I'll happily tack on this:
> 
> PhpWiki uses database abstraction layers (ADODB and PEAR) to access
> databases. Currently it seems we only support MySQL. (Postgres stuff is
> there but has not been updated). Since we use these layers, the database we
> use is trivial. MySQL, PostgreSQL, Oracle, MSSQL + more are supported by
> ADODB alone.

Currently it's the other way round. With the PearDB backend we support 
almost all existing databases. For MySQL we just make use of some mysql 
extensions. The PearDB module is fairly up-to-date. The other SQL 
databases should work out of the box.
postgres: The postgres database schemata are not updated for the session 
and pref table. And we cannot test it on the sf.net server.
msql: I don't know of any msql phpwiki installation in the last 5 years.
Oracle, firebird and friends should work out of the box. Never heard 
anything about MSSQL. Should work imho.

ADODB was a hack by Lawrence Akka for MySQL only, because it's much 
faster (mainly no unnecessary statement preparsing - simple sprintf, 
simplier error handling, and no result class).
With the planned ADODB update we get ADODB support for all other 
databases (to match up with PEAR), and have easier integration with 
nuke-based CMS, which use ADODB and not PEAR.
ADODB has also this nifty binary php module which speeds up database 
access even more.

For PearDB I unimplemented the statement preparsing in 1.3.8, and use 
the same sprintf enhancement as in ADODB. We know our field types in 
advance and can properly quote it beforehand.

I didn't benchmark it recently but I guess that ADODB is only about 5% 
faster now.

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...] On Behalf Of Whit Blauvelt
> Sent: Wednesday, March 17, 2004 8:34 PM
> To: php...@li...
> Subject: [Phpwiki-talk] Re: MySQL PHP rift
> 
> On Thu, Mar 18, 2004 at 11:56:13AM +1100, Matthew Palmer wrote:
>>To their credit, MySQL have been fairly public in their attempts to sort
>>the problems out, and it would be an incredible shame if this didn't go well
>>in the long run, because MySQL have been, in a way, the posterchild for the
>>"you can GPL your software AND make money!" argument 
> 
> 
> Amen. MySQL is good stuff and good people. A few years back when I had an
> obscure bug to complain of (in a charitable situation where there were no
> bucks to be sending their way) I got full attention from the main man there.
> 
> As for PHP, I've been using it since Rasmus jumped into a newsgroup
> discussion about a commercial Web-scripting product back in '93 to point out
> he was giving something better away free. The current PHP powers have lost
> the a bit of the spirit of generousity and inclusion the language began from
> - which is especially tacky considering how much of PHP's usefulness has
> come from it's facility with MySQL. I'm all for purity; but I'm also for
> remembering who your true friends have been.
> 
> Is there consideration of depricating MySQL support in PhpWiki, or just
> expanding other options?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: MySQL PHP rift

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

Whit Blauvelt schrieb:
> On Thu, Mar 18, 2004 at 11:56:13AM +1100, Matthew Palmer wrote:
>>To their credit, MySQL have been fairly public in their attempts to sort the
>>problems out, and it would be an incredible shame if this didn't go well in
>>the long run, because MySQL have been, in a way, the posterchild for the
>>"you can GPL your software AND make money!" argument 
> 
> Amen. MySQL is good stuff and good people. A few years back when I had an
> obscure bug to complain of (in a charitable situation where there were no
> bucks to be sending their way) I got full attention from the main man there.
> 
> As for PHP, I've been using it since Rasmus jumped into a newsgroup
> discussion about a commercial Web-scripting product back in '93 to point out
> he was giving something better away free. The current PHP powers have lost
> the a bit of the spirit of generousity and inclusion the language began from
> - which is especially tacky considering how much of PHP's usefulness has
> come from it's facility with MySQL. I'm all for purity; but I'm also for
> remembering who your true friends have been.
> 
> Is there consideration of depricating MySQL support in PhpWiki, or just
> expanding other options?

For sure not in PhpWiki.
But I'm deeply concerned about PHP's decision during the last year, 
dropping the libmysqlclient from PHP core and enforcing SQLite as 
default DB (MySQL replacement) in core. From php-5.x on libmysql is just 
a module.

Well, SQLite is faster, has the server included, is therefore much 
easier to install and has almost the same features as MySQL.
But: There's no SQLite module for the older PHP's!
So we cannot enforce SQLite as default dbtype to replace dbm, though it 
would make sense since SQLite is now in core and the various dbm libs 
only as module. And windows has other default dbm backends than unix.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: phpwiki not running with php as cgi

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

On Wed, Mar 17, 2004 at 09:12:03PM -0800, Konstantin Zadorozhny wrote:
>     Just for the record. I've got exactly the same poblem too. Apache 1.3.X
> and PHP 4.2.3 as cgi module.
>     COMPRESS_OUTPUT = false - solved the problem.

Good to know the problem can be solved that way.  Thanks for the
confirmation.

- Matt

[Phpwiki-talk] Re: phpwiki not running with php as cgi

[Konstantin Z. <kza...@ho...>]

Hello, Matthew!
You wrote  on Mon, 15 Mar 2004 23:35:58 +1100:

 MP> On Mon, Mar 15, 2004 at 12:37:58PM +0100, Benjamin Thelen wrote:
 ??>> Reini Urban wrote:
 ??>>> Benjamin Thelen schrieb:
 ??>>>
 ??>>>> Parse error: parse error in /usr/local/www/cgi-bin-dist/php on line
 ??>>>> 6265 Other php4 script based software like phpMyAdmin are running
 ??>>>> fine for example.

 MP> This may or may not be relevant to your situation, but I've gotten
 MP> reports (as the Debian PHPWiki maintainer) that turning off output
 MP> compression does the job.  No idea why, but there you go.  (This was in
 MP> relation to PHPWiki not running as a CGI in Apache 2, though, so that
 MP> might be part of it).

 MP> If you force COMPRESS_OUTPUT to false, what happens?

    Just for the record. I've got exactly the same poblem too. Apache 1.3.X
and PHP 4.2.3 as cgi module.
    COMPRESS_OUTPUT = false - solved the problem.


With best regards, Konstantin Zadorozhny.  E-mail: kza...@ho...

Re: [Phpwiki-talk] Ready for 1.3.8 ? Heads up

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

On Wed, Mar 17, 2004 at 10:18:26PM -0600, electron wrote:
> An installer is useful because the whole point of our userbase is to be user
> friendly. This includes the admins. You shouldn't need a $40 an hour
> consultant to install phpwiki.

Tell everyone to use Debian.  <grin>

Practically, PHPWiki is pretty simple to install.  If someone's got an
Apache webserver with PHP4 working already, chances are they're about 90
seconds away from a working PHPWiki install.  Providing a "ready to go"
apache.conf for inclusion would be the one big step (I can provide the one I
use for Debian if anyone wants it).

> Defines suck. Defines are everywhere where they don't need to be. Index.php
> is hugely bloated, complex and not documented well.

Index.php shouldn't be a .php file.  PHP has a wonderful .ini parser, and
nobody uses it!  I'd recommend doing a switch (it might not be a 1.3 series
thing, though) to a .ini config file, out of the web tree entirely.  An
autowriter should be easy enough - load up index.php, iterate through the
define list, and write it all to an ini file.  Lack of internal
documentation on that will suck, though, but a default "edit-through" ini
file should work well.

> Finally, Documentation, Doc, and Doc!

I *think* that most of the stuff people are interested in is documented
inside the Wiki somewhere, but a lot of things just aren't easily
accessible.

> There is no rush to get to 1.4.0. 1.4.0 should be a complete, pretty, easy
> to install and easy to administer wiki miniCMS. 

Does SF have the ability to group "tasks" into releases, for planning
purposes?  If everything were tracked there, it would make it easier for the
externals like me to see how things are going.

> 1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0.

Erm, no.  The 1.3 series should be bugfixes only.  Even my SQLite stuff
shouldn't really be released in a 1.3 series, unless it gets a *hell* of a
lot of testing (which it will, shortly).

We need to create a new 1.4 branch to make all these developmental changes
on.  Fork from the existing 1.3 tree and start hacking.  Make those big
changes like rewriting all the DB stuff.  Nothing in there should
necessarily be working particularly well, although keeping as much stuff
working as possible is good, because then the bold people can run it for
kicks.  But 1.3 is not the place to be working towards 1.4, because then we
either have no really new innovations in 1.4 (because we had to keep all the
old crud working), or nothing works for a while in 1.3 (because things are
being broken all the time and not everything is stable at the exact same
time) or we don't make any releases (because nothing's working properly).

But that opinion, of course, is as a rank outsider to PHPWiki, so it should
be taken with the sachet of salt provided.  <grin>

- Matt

RE: [Phpwiki-talk] Transclude.php - "local" service for vertical resize?

[electron <ele...@mg...>]

The code is too simple and opens you up to all sorts of creative =
javascript
and cookie reading attacks.

We can always parse the html and use certain tags for the parser to make =
it
slightly safer.

I've been experimenting with a OO php HTML parser. I'll see what I can =
come
up with. Parsing also allows us to make allow rawhtml safe. And a couple
other things come to mind....

-Jtp




I've stopped 7,516 spam messages. You can too!
One month FREE spam protection at http://www.cloudmark.com/spamnetsig/}

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Whit =
Blauvelt
Sent: Wednesday, March 17, 2004 8:46 PM
To: php...@li...
Subject: [Phpwiki-talk] Transclude.php - "local" service for vertical
resize?

In Transclude.php it says:

 *  The auto-vertical resize javascript code only works if the =
transcluded
 *  page comes from the PhpWiki server.  Otherwise (due to "tainting"
 *  security checks in JavaScript) I can't figure out how to deduce the  =
=20
 *  height of the transcluded page via JavaScript... :-/

What about serving the remote page from the PhpWiki server, with a URL
something like this:

http://localserver.org/include.php?remote_url=3Dhttp://www.remote.com/som=
epage
.html

where include.php is a file like:

<?php                                                                    =
=20
$fd=3Dfopen("$remote_url","r");                                          =
  =20
$base=3D"<BASE href=3D" . $remote_url . ">";
echo $base;                                    =20
while (!feof($fd)) {
        $buffer =3D fgets($fd, 4096);
        echo $buffer;
}
?>

Maybe this isn't compatible with how Transclude works, or is too much
overhead. But it will serve the transcluded page from the local PhpWiki
server, which should satisfy JavaScript. Even with the overhead this =
might
at least make sense as an option for contexts where the vertical sizing =
is
worth getting right.

Whit


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

RE: [Phpwiki-talk] Ready for 1.3.8 ? Heads up

[electron <ele...@mg...>]

1.3.8 may be a week or less away, however, I doubt one could say 1.4.0 =
is
2-3 weeks away.

Enter the realist(tm):

Before 1.4.0, it is critically important that the only time dbtype is
checked is when wikidb is initialized. This may mean having to add some =
user
based functions to wikidb or moving wiki authentication to a separate =
layer.

Essentially, if I write an extension for wikidb (phADODB, which =
pnPhpWiki
uses to tap into postnuke), by checking elsewhere for dbtype I just lost
functionality!

An installer is useful because the whole point of our userbase is to be =
user
friendly. This includes the admins. You shouldn't need a $40 an hour
consultant to install phpwiki.

Defines suck. Defines are everywhere where they don't need to be. =
Index.php
is hugely bloated, complex and not documented well.

Finally, Documentation, Doc, and Doc!

There is no rush to get to 1.4.0. 1.4.0 should be a complete, pretty, =
easy
to install and easy to administer wiki miniCMS.=20

1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0.

-Jtp.




> On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote:
>>Reini Urban wrote:
>>>Are we ready for the intermediate 1.3.8 release?
>>
>>Let me join malcolmr in saying:
>>1. PhpWiki has great potential.
>>2. Releasing something stable is good.
>>
>>Also, I would really like to use some of the things in 1.3.8, e.g.=20
>>strong user authentication.
>>
>>I know people asking you to release without doing any work can be=20
>>irritating, but you have to take it in the spirit given: you have an=20
>>attentive user base.

The only remaining problem before releasing 1.3.8 is a gettext or=20
update_locale problem for foreign languages.
All other issues (besides running as CGI) has been resolved now.

The strange thing is that on most of my test setups everything works=20
okay, just on PhpWikiDemo it fails sometimes, sometimes it works.
Which lets me assume that it could be a preferences setting.

What is planned for the next releases up to 1.4.0
-------------------------------------------------
Page permissions editable:
   * enable and simplify WikiAdminSetAcl, and probably WikiAdminChmod.
     let the user harden the ACL's of some pages.
     Default: loose permissions as before
Page permissions enforced:
   * check in all actions, plugins and listers for access permissions.
     (listers almost done)
WikiDB:
   * update to the latest ADODB library (but not the session class)
   * switch to FETCH_ROW
   * check for the dirty ADODB mysql hacks
    (INSERT ... SELECT)
   * test SQLite and PHP 5.0.x
Plugins:
   * WikiForum (almost the same as AddComments and WikiBlog)
   * Amazon, Google API's (using SOAP)
   * RateThisPage (user-specific and overall)
More Themes:
   * nuke (a tiny-font three-column theme),
   * crao (buttons as icons which need no translation, and
     more sidebar tricks)
Localization updates:
   * with the new _WikiTranslation and TranslateText features
     hopefully some holes will get filled.
action=3Dupgrade for database upgrades, pgsrc diffs and with =
verification.
   (currently only pgsrc upgrade on missing pages)

I'm not sure the requested installer and WikiAuth split-up into seperate =

files. Seperate UserPreferences classes are more important IMHO.

All this is not too much work. I think of about 2-3 weeks from
1.3.8 to 1.4.0
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] Re: MySQL PHP rift

[electron <ele...@mg...>]

I didn't get the original message but I'll happily tack on this:

PhpWiki uses database abstraction layers (ADODB and PEAR) to access
databases. Currently it seems we only support MySQL. (Postgres stuff is
there but has not been updated). Since we use these layers, the database =
we
use is trivial. MySQL, PostgreSQL, Oracle, MSSQL + more are supported by
ADODB alone.

All you have to ask for is a quick port for another DB. Essentially we =
are
way ahead of the game.

-Jtp




-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Whit =
Blauvelt
Sent: Wednesday, March 17, 2004 8:34 PM
To: php...@li...
Subject: [Phpwiki-talk] Re: MySQL PHP rift

On Thu, Mar 18, 2004 at 11:56:13AM +1100, Matthew Palmer wrote:

> To their credit, MySQL have been fairly public in their attempts to =
sort
the
> problems out, and it would be an incredible shame if this didn't go =
well
in
> the long run, because MySQL have been, in a way, the posterchild for =
the
> "you can GPL your software AND make money!" argument=20

Amen. MySQL is good stuff and good people. A few years back when I had =
an
obscure bug to complain of (in a charitable situation where there were =
no
bucks to be sending their way) I got full attention from the main man =
there.

As for PHP, I've been using it since Rasmus jumped into a newsgroup
discussion about a commercial Web-scripting product back in '93 to point =
out
he was giving something better away free. The current PHP powers have =
lost
the a bit of the spirit of generousity and inclusion the language began =
from
- which is especially tacky considering how much of PHP's usefulness has
come from it's facility with MySQL. I'm all for purity; but I'm also for
remembering who your true friends have been.

Is there consideration of depricating MySQL support in PhpWiki, or just
expanding other options?

Whit


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Transclude.php - "local" service for vertical resize?

[Whit B. <wh...@tr...>]

In Transclude.php it says:

 *  The auto-vertical resize javascript code only works if the transcluded
 *  page comes from the PhpWiki server.  Otherwise (due to "tainting"
 *  security checks in JavaScript) I can't figure out how to deduce the   
 *  height of the transcluded page via JavaScript... :-/

What about serving the remote page from the PhpWiki server, with a URL
something like this:

http://localserver.org/include.php?remote_url=http://www.remote.com/somepage.html

where include.php is a file like:

<?php                                                                     
$fd=fopen("$remote_url","r");                                             
$base="<BASE href=" . $remote_url . ">";
echo $base;                                     
while (!feof($fd)) {
        $buffer = fgets($fd, 4096);
        echo $buffer;
}
?>

Maybe this isn't compatible with how Transclude works, or is too much
overhead. But it will serve the transcluded page from the local PhpWiki
server, which should satisfy JavaScript. Even with the overhead this might
at least make sense as an option for contexts where the vertical sizing is
worth getting right.

Whit

[Phpwiki-talk] Re: MySQL PHP rift

[Whit B. <wh...@tr...>]

On Thu, Mar 18, 2004 at 11:56:13AM +1100, Matthew Palmer wrote:

> To their credit, MySQL have been fairly public in their attempts to sort the
> problems out, and it would be an incredible shame if this didn't go well in
> the long run, because MySQL have been, in a way, the posterchild for the
> "you can GPL your software AND make money!" argument 

Amen. MySQL is good stuff and good people. A few years back when I had an
obscure bug to complain of (in a charitable situation where there were no
bucks to be sending their way) I got full attention from the main man there.

As for PHP, I've been using it since Rasmus jumped into a newsgroup
discussion about a commercial Web-scripting product back in '93 to point out
he was giving something better away free. The current PHP powers have lost
the a bit of the spirit of generousity and inclusion the language began from
- which is especially tacky considering how much of PHP's usefulness has
come from it's facility with MySQL. I'm all for purity; but I'm also for
remembering who your true friends have been.

Is there consideration of depricating MySQL support in PhpWiki, or just
expanding other options?

Whit

Re: [Phpwiki-talk] SQLite database backend problems

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

On Wed, Mar 17, 2004 at 03:53:27PM +0100, Reini Urban wrote:
> Matthew Palmer schrieb:
> >On Wed, Mar 17, 2004 at 02:53:42PM +0100, Reini Urban wrote:
> >Found the problem though (see the list for details).
> 
> Experimental PearDB SQLite support is in current Phpwiki CVS.

Heh.  Nice catch in PearDB, BTW - *_tbl_fields.  Just have to be a bit
careful about other multi-table queries, but that'll require a bit more
effort to find, because it's not as simple as greping for 'SELECT.*\.\*'.

> The SQLite DB will gain popularity with the current MySQL vs PHP license 
> drama:

To their credit, MySQL have been fairly public in their attempts to sort the
problems out, and it would be an incredible shame if this didn't go well in
the long run, because MySQL have been, in a way, the posterchild for the
"you can GPL your software AND make money!" argument (because Cygnus, who
have been doing it for a lot longer, don't do sexy stuff like write a DB
engine).

SQLite is missing a number of "convenience" features that make MySQL so nice
to work with, like ALTER TABLE, SHOW TABLES, REPLACE INTO, AUTO_INCREMENT,
and so on.  None of them are showstoppers, but they're all things that, once
you've lived with them, you are loathe to part with... That, more than
anything, will keep people with MySQL for quite some time.  It's one of the
reasons I haven't made any wholesale migrations to PostgreSQL, despite
occasionally seeing a nice need for a trigger or two...

- Matt

Re: [Phpwiki-talk] phpwiki not running with php as cgi

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

On Wed, Mar 17, 2004 at 08:06:50PM +0100, Benjamin Thelen wrote:
> Matthew Palmer wrote:
> >On Mon, Mar 15, 2004 at 03:54:59PM +0100, Benjamin Thelen wrote:
> >>I don't know what COMPRESS_OUTPUT is, I'd like to check that. Where do 
> >>I force this?
> >
> >
> >In 1.3.7, it's in index.php (uncomment the appropriate define).  Prior to
> >that (1.3.4, for instance) there's no define, but the code is in
> >lib/Request.php somewhere - search for "ob_gzhandler" and you'll find it,
> >comment it out or give it an early return or something.
> 
> I did this with 1.3.7 and suddenly saw the entry page, but, I am 
> afraid, that's all. In 1.3.4, I found the appropriate section, no 
> change. Sorry.
> 
> Any further ideas? Any options php needs to be compiled with?

Sorry, nothing else comes to mind.  Most errors are reported one way or
another.

- Matt

[Phpwiki-talk] Ready for 1.3.8 ? Heads up

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

> On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote:
>>Reini Urban wrote:
>>>Are we ready for the intermediate 1.3.8 release?
>>
>>Let me join malcolmr in saying:
>>1. PhpWiki has great potential.
>>2. Releasing something stable is good.
>>
>>Also, I would really like to use some of the things in 1.3.8, e.g. 
>>strong user authentication.
>>
>>I know people asking you to release without doing any work can be 
>>irritating, but you have to take it in the spirit given: you have an 
>>attentive user base.

The only remaining problem before releasing 1.3.8 is a gettext or 
update_locale problem for foreign languages.
All other issues (besides running as CGI) has been resolved now.

The strange thing is that on most of my test setups everything works 
okay, just on PhpWikiDemo it fails sometimes, sometimes it works.
Which lets me assume that it could be a preferences setting.

What is planned for the next releases up to 1.4.0
-------------------------------------------------
Page permissions editable:
   * enable and simplify WikiAdminSetAcl, and probably WikiAdminChmod.
     let the user harden the ACL's of some pages.
     Default: loose permissions as before
Page permissions enforced:
   * check in all actions, plugins and listers for access permissions.
     (listers almost done)
WikiDB:
   * update to the latest ADODB library (but not the session class)
   * switch to FETCH_ROW
   * check for the dirty ADODB mysql hacks
    (INSERT ... SELECT)
   * test SQLite and PHP 5.0.x
Plugins:
   * WikiForum (almost the same as AddComments and WikiBlog)
   * Amazon, Google API's (using SOAP)
   * RateThisPage (user-specific and overall)
More Themes:
   * nuke (a tiny-font three-column theme),
   * crao (buttons as icons which need no translation, and
     more sidebar tricks)
Localization updates:
   * with the new _WikiTranslation and TranslateText features
     hopefully some holes will get filled.
action=upgrade for database upgrades, pgsrc diffs and with verification.
   (currently only pgsrc upgrade on missing pages)

I'm not sure the requested installer and WikiAuth split-up into seperate 
files. Seperate UserPreferences classes are more important IMHO.

All this is not too much work. I think of about 2-3 weeks from
1.3.8 to 1.4.0
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Patch for initial_content arg to page editing and CreatePage

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

Dan F wrote:

> Reini Urban wrote:
>
>

>> The CategoryPage plugin idea is also cool, but I would like to change 
>> it a bit.
>> I see your point with the dynamically created initial_content, but 
>> then I would like to suggest to use variables in the user-editable 
>> TemplatePage content which get's translated per Category.
>
>
>
> I like this idea better. In fact, that's the first route I tried, and 
> I struggled with it for several days (for example, my earlier email 
> "WikiText++ ?") before giving up (at least temporarily). Probably one 
> thing I needed was your code snippet to display a page. However, I 
> also need to know a little bit about how to get variables substituted 
> into the TemplatePage properly. Suggestions? A template (HTML) looks 
> quite different to me from a TemplatePage (WikiText), so it's not 
> obvious how to call a Template object or some such on the 
> "initial_content" from your snippet. If you drop me another hint, I 
> will work on it. :-)
>

To clarify: by "I like this idea better" I meant "I like YOUR idea 
better." I'd rather have the content editable. I just couldn't figure 
out how to get variable substitution going properly.

Dan

Re: [Phpwiki-talk] Patch for initial_content arg to page editing and CreatePage

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

Reini Urban wrote:

> Dan,
> I'd love to add your RateThisPage feature to PhpWiki. Did you see my 
> latest WikiPoll?


I'm very glad to hear that! I'd love to contribute. What's more, any of 
my changes that make it into the main branch I don't have to reapply to 
new versions if I want to move up, so that's doubly exciting! Anything I 
can do to help: for example, contribute patch files from 1.3.7, tar up 
the whole thing, maybe even apply it to 1.3.8 when that comes out(?). I 
am a little cautious about working on the mainline itself, because if it 
is unstable that might make applying new features challenging. However, 
I am open to ideas. Let me know how to proceed.

I have not seen the latest WikiPoll. I assume that is in the CVS 
mainline? I have not been looking at the mainline, because I've been 
focusing on the prototyping of the ratings/recommendation system, the 
beginning of a project I call WikiLens. The focus of WikiLens will be 
rating things and getting things recommended to you, either by other 
people explicitly (perhaps "buddies" perhaps strangers), or 
automatically through their ratings. Imagine you can rate some movies 
(or restaurants, or whatever category anyone wants to create), and then 
get personalized recommendations for other movies (or restaurants ..) 
based on collaborative filtering, and all of that creation of items, 
rating, and recommendation is done within PhpWiki. That's the goal, anyway.

I am the staff scientist of the GroupLens research group at the 
University of Minnesota, a research group devoted to collaborative 
filtering and recommender technology. Our most public example of a 
recommender to date is MovieLens (http://www.movielens.org), but 
WikiLens would be much more broad and (to me) exciting. I plan to devote 
what time I can to this project (WikiLens), and also get students 
interested in working on it. I'd MUCH rather get our changes supported 
than fork, so again, let me know.

One challenge to integrating the ratings widget and storage is that 
currently I only have it implemented for the PearDB backend. This seems 
appropriate to me, because as WikiLens grows in popularity, it will have 
(at least!) thousands of pages (MovieLens has thousands of movies), and 
only a reasonable database backend will handle that appropriately. 
What's more, a PageList widget good at ordering pages will be extremely 
important, and I don't think reading all the pages into memory (like the 
mainline PageList code?) scales well; thus, probably I'll have to pass 
things from PageList directly to the "ORDER BY" clause of a real SQL 
backend. It might be easiest to have a switch to turn on 
ratings-and-recs functionality, and only be able to turn it on for 
certain back ends.

> The CategoryPage plugin idea is also cool, but I would like to change 
> it a bit.
> I see your point with the dynamically created initial_content, but 
> then I would like to suggest to use variables in the user-editable 
> TemplatePage content which get's translated per Category.


I like this idea better. In fact, that's the first route I tried, and I 
struggled with it for several days (for example, my earlier email 
"WikiText++ ?") before giving up (at least temporarily). Probably one 
thing I needed was your code snippet to display a page. However, I also 
need to know a little bit about how to get variables substituted into 
the TemplatePage properly. Suggestions? A template (HTML) looks quite 
different to me from a TemplatePage (WikiText), so it's not obvious how 
to call a Template object or some such on the "initial_content" from 
your snippet. If you drop me another hint, I will work on it. :-)

> Something wikipedia is also struggling with.


Is that right? In what way? I looked at Wikipedia for my project, but 
the setup and code didn't feel quite as developer-friendly.

Thanks for your responses. Sorry for the long email-- I'm excited about 
WikiLens! Again, let me know if you want to see any of our code so far, 
or if you'd like to hear more detail about the concept of WikiLens.

Dan

-- 
Dan Frankowski    dfr...@cs...      612-626-8396


> Dan F schrieb:
>
>> As background to this discussion, I attach my current version of my 
>> CategoryPage.php plugin, and the categorypage.tmpl it uses. The idea 
>> is to be able to drop <?CategoryPage ?> on any page you wish to 
>> represent a category in order to replicate boilerplate text that 
>> describes how it works for a newbie.
>>
>> All of this would probably be unnecessary for people who know a lot 
>> about how Phpwiki works (specifically: searching, creating pages, and 
>> backlinks), but I am specifically trying to design our site for 
>> casual users who don't care about wikis. I plan to try to attract 
>> many of them (potentially hundreds or thousands) to rate restaurants, 
>> research papers, movies, etc.
>
>
>>> Thanks for your response! I assume you meant to add your suggested 
>>> code into the CreatePage plug-in, then add the template itself as a 
>>> Wiki page. I like the fact that yours is not restricted by GET 
>>> length, and that it is editable by end-users. I also agree that 
>>> introducing quoting into expandArgs() is a bold move that one would 
>>> like to avoid if possible.
>>>
>>> The potential issue for me is that the template itself might have to 
>>> be programmatically generated. Thus, I don't want "[Restaurant]" in 
>>> general, but, "[" . "[pagename]" . "]", so that I can drop a simple 
>>> statement (currently a CategoryPage plugin) that has a "CreatePage" 
>>> button on "[Restaurant]" that refers back to [Restaurant] and drop 
>>> that same CategoryPage plugin without mods onto "[ResearchPaper]" 
>>> and its "CreatePage" button refers back to "[ResearchPaper]". I am 
>>> not describing it very well in English. For an example, please see:
>>>
>>> http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/Restaurant
>>> http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/ResearchPaper
>>> http://dickens.cs.umn.edu/dfrankow/wikilens/
>>>
>>> I will work with your suggestion and see how it goes. I'd much 
>>> prefer to have something you guys are willing to accept as a mod.
>>
>
>> This page represents the category.
>> All pages that are in the category refer to this page.
>>
>> "BackLinks", 'exclude' => "$EXCLUDE"), _("Show all pages in the 
>> $SINGULAR category")); ?>
>>
>>    To put a page into the category
>>
>>    1. Search to see if it already exists. We don't want lots of
>>       duplicate pages. You can use this FuzzyPages search:
>>
>>    2. If it does not exist, create the page and save it. You can use
>>       this CreatePage button, or see for more ways to navigate or create
>>       pages. _printPlugin("<" . "?plugin-form CreatePage
>>       initial_content=" . $initial_content . " ?" . ">"); ?>
>>
>>    3. Whether you just created it or it already exists, to ensure that
>>       the *"Show all pages in the category"* button shows your page, be
>>       sure to refer to this page by putting *[]* in your page text
>>       somewhere (including the brackets to be safe).
>

Re: [Phpwiki-talk] SQLite database backend problems

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

Matthew Palmer schrieb:
> On Wed, Mar 17, 2004 at 02:53:01PM +0100, Reini Urban wrote:
>>Matthew Palmer schrieb:
>>>I'm working on an SQLite backend helper for PHPWiki, so that I don't have 
>>>to use BDB (ugh!), flat file, or do nassssty setup on a real SQL engine. 
>>>However, it wouldn't be an SQL database without foibles, and I'm getting
>>>them by the truckload.
>>
>>Do you really want it now, and not wait for the official PHP and PearDB 
>>+ ADODB support?
> 
> Timeframe on the new DB system?  I couldn't find anything on the SF site
> about it.  I know it's been discussed here before, but was anything planned
> re: release date?

No, I'm talking about the PECL and ADODB status with the new SQLite and 
dropped Mysql support.
Re ADODB we haven't yet updated to the latest ADODB release, because I 
wanted to bring out the 1.3.8 release before.

There are just minor remainings problems, like gettext and 
WikiAdminRemove (again), but the userpref problems seem to be gone with 
the base64 encoding of the cookiedata.

> What exactly is meant by "official PHP and PearDB + ADODB support", anyway? 
> Surely one would be enough?

I added your PearDB SQLite backend.

> The problem is ambiguous SQL and lazy client library authors.  "SELECT
> foo.bar, baz.wombat" is inconsistent as to what the field names will be on a
> DB_FETCHMODE_ASSOC.  MySQL (and I presume PgSQL) will return just the field
> name - potentially losing information.  SQLite goes the other way, and
> returns table.field instead, so when the iterator goes looking for the
> 'pagename' index in a returned row (backend/PearDB.php:~797) it bombs on
> SQLite, because the field name there is linkee.pagename (or linker.pagename,
> but you get the idea).
> 
> The solution is to fully qualify all field names when operating in a query
> environment with ambiguous field names (which should be SOP anyway).  So,
> instead of coding "SELECT $want.*" in backend/PearDB.php:~412, you write
> "SELECT $want.id as id, $want.pagename as pagename" and so on.

Just did this for ADODB and PearDB in CVS. This speeds up the SELECT 
queries also. Thanks for pointing this out.
There are only two "SELECT *" remaining, which does not harm SQLite.

> I count five places in each of PearDB.php and ADODB.php where the .* problem
> needs to be fixed, and there's probably a bunch of places which are using
> ambiguous names without the all field catcher.  A fix will be in the next
> Debian PHPWiki release, at least, and if anyone thinks it's useful, I'll put
> the patch into the SF patch tracker.

Not needed. See above.

We also want to switch from FETCH_ASSOC to FETCH_ROW sooner or later, so 
we won't need the aliases then. This should simplify and speed up
DB performance a lot.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/