phpwiki-talk

[Phpwiki-talk] Wrong table in mysql_initialize.sql ?

[RubyCon <dm...@ik...>]

Hello,

I just installed a new and fresh phpwiki 1.3.14  (timestamp July 1th 12:15.)
Everything works fine except an errormessge at the end of each page:  pear
... mysql .. access_log something-wrong  table_rows

The following patch fixes the problem. 

---cut here---
*** schemas/mysql-initialize.sql        2007-08-14 21:03:16.000000000 +0200
--- schemas/mysql-initialize.sql.orig   2007-07-01 12:11:27.000000000 +0200
***************
*** 130,138 ****
        remote_user   VARCHAR(50),
          request_method VARCHAR(10),
        request_line  VARCHAR(255),
-       request_uri   VARCHAR(255),
        request_args  VARCHAR(255),
        request_file  VARCHAR(255),
        request_time  CHAR(28),
        status        SMALLINT UNSIGNED,
        bytes_sent    SMALLINT UNSIGNED,
--- 130,138 ----
        remote_user   VARCHAR(50),
          request_method VARCHAR(10),
        request_line  VARCHAR(255),
        request_args  VARCHAR(255),
        request_file  VARCHAR(255),
+       request_uri   VARCHAR(255),
        request_time  CHAR(28),
        status        SMALLINT UNSIGNED,
        bytes_sent    SMALLINT UNSIGNED,

---cut here---

Now everything works fine.


But a very nice wiki   I'm still testing but it looks good

Thanks

-- 
View this message in context: http://www.nabble.com/Wrong-table-in-mysql_initialize.sql---tf4269441.html#a12151392
Sent from the phpwiki-talk mailing list archive at Nabble.com.

Re: [Phpwiki-talk] Fix for bug in Email Notification

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

2007/8/14, Sabri LABBENE <sab...@st...>:
> I've seen several times the bug you've recently fixed (Unknown modifier ? At any page save) in my wiki. Unfortunately, I can't find a scenario that makes the bug easily reproducable. Thus, I can't check if your fix solves my problem.
> Do you have any idea how to reproduce the bug ?

Yes, in your preferences save a page like Page/*
in "Get an email notification at changes of the following pages:"
and store your email.

Then edit any page and voila, you get the warning.

[Phpwiki-talk] Fix for bug in Email Notification

[Sabri L. <sab...@st...>]

Hi Reini and all,

I've seen several times the bug you've recently fixed (Unknown modifier =
? At any page save) in my wiki. Unfortunately, I can't find a scenario =
that makes the bug easily reproducable. Thus, I can't check if your fix =
solves my problem.
Do you have any idea how to reproduce the bug ?

Thanks for your help,
-- Sabri. =20

Re: [Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

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

Sacha Schär schrieb:
> Greetings to Austria and many thanks for all your help!
> As far as I can tell the wiki works now, _after_ applying the SQL patch 
> above!

Ah, good.

> (from your other mail)
>  > FYI: The fix for this error is in lib/upgrade.php
>  >
>  >    function CheckDatabaseUpdate() {
>  >    global $DBAuthParams, $DBParams;
> 
> After fixing this, ?action=upgrade dies at the following check:

>  check for mysql LOCK TABLE privilege ...lock_tables_priv missing.
>  The  DB   Admin must run mysql_fix_privilege_tables
> 
> 
> Is 'mysql_fix_privilege_tables' some file or action that is provided 
> with PHPWiki? I can not find anything like that.
> If it is something only the host provider can do, how should I instruct 
> him?

This error says that it seems that wikiuser has no privileges to LOCK 
tables.  Your provider has to grant you LOCK TABLE privileges for your 
own databases, best done with mysql_fix_privilege_tables.

However if you CAN edit pages, you don't need this and the upgrade 
check is wrong.

> Can I savely run the wiki now or should I fix the problem above first?

> PS: One minor glitch: Seemingly, I can no longer login into the wiki as 
> 'SachaSchär'. Is this because of the umlaut? Anyway, no real problem, 
> I'm just curious...

Hmm, that depends on many other things. If the new database has a 
different default locale, it will lead to those effects.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

[<sac...@gm...>]

Greetings to Austria and many thanks for all your help!

> Does the wiki work?
> 
>  > ...(snipped some text)
>  > [nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
> 
> We still seem to need 'cached_html'
> Strange, this should have been there since 1.3.11. Try
> 
>   ALTER TABLE page ADD cached_html MEDIUMBLOB;
> 
> But I rather believe upgrade fails in mysql_list_fields().

As far as I can tell the wiki works now, _after_ applying the SQL patch 
above!


(from your other mail)
 > FYI: The fix for this error is in lib/upgrade.php
 >
 >    function CheckDatabaseUpdate() {
 >    global $DBAuthParams, $DBParams;

After fixing this, ?action=upgrade dies at the following check:

  check for mysql LOCK TABLE privilege ...lock_tables_priv missing.
  The  DB   Admin must run mysql_fix_privilege_tables


Is 'mysql_fix_privilege_tables' some file or action that is provided 
with PHPWiki? I can not find anything like that.
If it is something only the host provider can do, how should I instruct him?

Can I savely run the wiki now or should I fix the problem above first?

-Sacha

PS: One minor glitch: Seemingly, I can no longer login into the wiki as 
'SachaSchär'. Is this because of the umlaut? Anyway, no real problem, 
I'm just curious...

Re: [Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

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

Reini Urban schrieb:
> Greetings to Basel.
> Sacha Schär schrieb:
>> lib/WikiDB/backend/PearDB.php:1059 Error[256]: 
>> WikiDB_backend_PearDB_mysql: fatal database error
>>
>>      * DB Error: syntax error
>>      * (DESCRIBE [nativecode=1064 ** You have an error in your SQL 
>> syntax; check the manual that corresponds to your MySQL server version 
>> for the right syntax to use near '' at line 1])
>>      *
>>
>> lib/upgrade.php:472 Notice[8]: Undefined variable: DBParams
> 
> This error is not fatal.
>    mysql session.sess_id sanity is not so important in your case.

FYI: The fix for this error is in lib/upgrade.php

     function CheckDatabaseUpdate() {
	global $DBAuthParams, $DBParams;


-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

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

Greetings to Basel.

Sacha Schär schrieb:
> Thank you for the quick reply! I did not receive this email. So I just 
> copied the text from the archieves, thereby probably creating a new 
> thread... sorry.
> 
> 
>  > Oops, upgrade error. I forgot something.
>  > Best is to use your phpMyAdmin with the following snippet:
>  >
>  > ALTER TABLE accesslog CHANGE remote_host VARCHAR(100);
>  >
>  > <enter> // this may fail.
> 
> Failed indeed:
> 
> #1064 - You have an error in your SQL syntax; check the manual that 
> corresponds to your MySQL server version for the right syntax to use 
> near 'VARCHAR(100)' at line 1
> 
> 
>  > ALTER TABLE link ADD relation INT DEFAULT 0;
>  > CREATE INDEX link_relation ON link (relation);
>  >
>  > <enter> // this is required.
> 
> This worked!
> 
>  > And then optionally again ?action=3Dupgrade to fill in the relations.

A mailer error. I meant ?action=upgrade of course ...

> This failed, seemingly, 3Dupgrade is an unknown action in my setup:
> 
> ...(snipped some text)
> [nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
>      *
> 
> lib/main.php:873 Notice[1024]: 3Dupgrade: Unknown action
> 
> 
> I tried ?upgrade instead. With this, the migration went further as 
> before, but still failed:
> 
> Upgrading this PhpWiki
> check for necessary database updates - SQL
> db version: we want 1030.14
> db version: we have 0
> Backend type: mysql
> check for table session ...OK
> check for table pref ...OK
> check for table member ...OK
> Rebuild entire database to upgrade relation links ... OK
> check for table accesslog ...OK
> check for table rating ...OK
> check for new session.sess_ip column ... SKIP
> check for mysql session.sess_id sanity ...
> Fatal Error:
> 
> lib/WikiDB/backend/PearDB.php:1059 Error[256]: 
> WikiDB_backend_PearDB_mysql: fatal database error
> 
>      * DB Error: syntax error
>      * (DESCRIBE [nativecode=1064 ** You have an error in your SQL 
> syntax; check the manual that corresponds to your MySQL server version 
> for the right syntax to use near '' at line 1])
>      *
> 
> lib/upgrade.php:472 Notice[8]: Undefined variable: DBParams

This error is not fatal.
   mysql session.sess_id sanity is not so important in your case.

> lib/WikiDB/backend/PearDB.php:1151 Warning[2]: mysql_list_fields() [<a 
> href='function.mysql-list-fields'>function.mysql-list-fields</a>]: 
> Unable to save MySQL query result
> 
> lib/WikiDB/backend/PearDB.php:1152 Warning[512]: 
> /home/httpd/vhosts/scanita.net/httpdocs/phpwiki/lib/WikiDB/backend/PearDB.php:1152 
> Table 'spice_phpwiki.' doesn't exist
> 
> 
> (spice_phpwiki is the name of the DB as well as the name of the admin user)
> 
> Is there a bug in upgrade.php or do you think there is a problem with my 
> settings?

Both. A bug in upgrade and an intermediate mysql schema.
Thanks for using DEBUG to get the failing upgrade lines.
I can fix it now.

Does the wiki work?

 > ...(snipped some text)
 > [nativecode=1054 ** Unknown column 'cached_html' in 'field list'])

We still seem to need 'cached_html'
Strange, this should have been there since 1.3.11. Try

   ALTER TABLE page ADD cached_html MEDIUMBLOB;

But I rather believe upgrade fails in mysql_list_fields().
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

[<sac...@un...>]

Thank you for the quick reply! I did not receive this email. So I just 
copied the text from the archieves, thereby probably creating a new 
thread... sorry.


 > Oops, upgrade error. I forgot something.
 > Best is to use your phpMyAdmin with the following snippet:
 >
 > ALTER TABLE accesslog CHANGE remote_host VARCHAR(100);
 >
 > <enter> // this may fail.

Failed indeed:

#1064 - You have an error in your SQL syntax; check the manual that 
corresponds to your MySQL server version for the right syntax to use 
near 'VARCHAR(100)' at line 1


 > ALTER TABLE link ADD relation INT DEFAULT 0;
 > CREATE INDEX link_relation ON link (relation);
 >
 > <enter> // this is required.

This worked!


 > And then optionally again ?action=3Dupgrade to fill in the relations.

This failed, seemingly, 3Dupgrade is an unknown action in my setup:

...(snipped some text)
[nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
     *

lib/main.php:873 Notice[1024]: 3Dupgrade: Unknown action


I tried ?upgrade instead. With this, the migration went further as 
before, but still failed:

Upgrading this PhpWiki
check for necessary database updates - SQL
db version: we want 1030.14
db version: we have 0
Backend type: mysql
check for table session ...OK
check for table pref ...OK
check for table member ...OK
Rebuild entire database to upgrade relation links ... OK
check for table accesslog ...OK
check for table rating ...OK
check for new session.sess_ip column ... SKIP
check for mysql session.sess_id sanity ...
Fatal Error:

lib/WikiDB/backend/PearDB.php:1059 Error[256]: 
WikiDB_backend_PearDB_mysql: fatal database error

     * DB Error: syntax error
     * (DESCRIBE [nativecode=1064 ** You have an error in your SQL 
syntax; check the manual that corresponds to your MySQL server version 
for the right syntax to use near '' at line 1])
     *

lib/upgrade.php:472 Notice[8]: Undefined variable: DBParams

lib/WikiDB/backend/PearDB.php:1151 Warning[2]: mysql_list_fields() [<a 
href='function.mysql-list-fields'>function.mysql-list-fields</a>]: 
Unable to save MySQL query result

lib/WikiDB/backend/PearDB.php:1152 Warning[512]: 
/home/httpd/vhosts/scanita.net/httpdocs/phpwiki/lib/WikiDB/backend/PearDB.php:1152 
Table 'spice_phpwiki.' doesn't exist


(spice_phpwiki is the name of the DB as well as the name of the admin user)

Is there a bug in upgrade.php or do you think there is a problem with my 
settings?

-Sacha

Re: [Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

[<sac...@gm...>]

Thank you for the quick reply! I did not receive this email. So I just 
copied the text from the archieves, thereby probably creating a new 
thread... sorry.


 > Oops, upgrade error. I forgot something.
 > Best is to use your phpMyAdmin with the following snippet:
 >
 > ALTER TABLE accesslog CHANGE remote_host VARCHAR(100);
 >
 > <enter> // this may fail.

Failed indeed:

#1064 - You have an error in your SQL syntax; check the manual that 
corresponds to your MySQL server version for the right syntax to use 
near 'VARCHAR(100)' at line 1


 > ALTER TABLE link ADD relation INT DEFAULT 0;
 > CREATE INDEX link_relation ON link (relation);
 >
 > <enter> // this is required.

This worked!


 > And then optionally again ?action=3Dupgrade to fill in the relations.

This failed, seemingly, 3Dupgrade is an unknown action in my setup:

...(snipped some text)
[nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
     *

lib/main.php:873 Notice[1024]: 3Dupgrade: Unknown action


I tried ?upgrade instead. With this, the migration went further as 
before, but still failed:

Upgrading this PhpWiki
check for necessary database updates - SQL
db version: we want 1030.14
db version: we have 0
Backend type: mysql
check for table session ...OK
check for table pref ...OK
check for table member ...OK
Rebuild entire database to upgrade relation links ... OK
check for table accesslog ...OK
check for table rating ...OK
check for new session.sess_ip column ... SKIP
check for mysql session.sess_id sanity ...
Fatal Error:

lib/WikiDB/backend/PearDB.php:1059 Error[256]: 
WikiDB_backend_PearDB_mysql: fatal database error

     * DB Error: syntax error
     * (DESCRIBE [nativecode=1064 ** You have an error in your SQL 
syntax; check the manual that corresponds to your MySQL server version 
for the right syntax to use near '' at line 1])
     *

lib/upgrade.php:472 Notice[8]: Undefined variable: DBParams

lib/WikiDB/backend/PearDB.php:1151 Warning[2]: mysql_list_fields() [<a 
href='function.mysql-list-fields'>function.mysql-list-fields</a>]: 
Unable to save MySQL query result

lib/WikiDB/backend/PearDB.php:1152 Warning[512]: 
/home/httpd/vhosts/scanita.net/httpdocs/phpwiki/lib/WikiDB/backend/PearDB.php:1152 
Table 'spice_phpwiki.' doesn't exist


(spice_phpwiki is the name of the DB as well as the name of the admin user)

Is there a bug in upgrade.php or do you think there is a problem with my 
settings?

-Sacha

Re: [Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

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

2007/8/10, Sacha Sch=E4r <sac...@un...>:
> Hi there,
>
> my host provider recently upgraded PHP from 4.3.9 to 5.1.6, and on the
> same time, MySQL from 4.0 to 4.1.21.
>
> As a consequence, my Phpwiki version 1.3.12p2 stopped working.
> I got the following error:
>
>   Fatal error: Cannot redeclare hash() in
>   /home/httpd/vhosts/scanita.net/httpdocs/phpwiki_old/lib/stdlib.php
>   on line 1276
>
> (I do understand this problem)
>
>
> In order to fix it, I installed Phpwiki 1.3.14. But when I tried to use
>       the same DB as before, I got the following error:
>
>   lib/WikiDB/backend/PearDB.php:1059 Error[256]:
>   WikiDB_backend_PearDB_mysql: fatal database error
>
>       * DB Error: no such field
>       * (SELECT cached_html FROM page WHERE pagename=3D'HomePage'
> [nativecode=3D1054 ** Unknown column 'cached_html' in 'field list'])
>       *
>
> (I do understand this problem too)
>
>
> I tried the upgrade action (.../phpwiki/index.php&action=3Dupgrade), but
> this did not seem to work:
>
>   Upgrading this PhpWiki
>   check for necessary database updates - SQL
>   db version: we want 1030.14
>   db version: we have 0
>   Backend type: mysql
>   check for table session ...OK
>   check for table pref ...OK
>   check for table member ...OK
>   Rebuild entire database to upgrade relation links ...
>   Fatal Error:
>
>   lib/WikiDB/backend/PearDB.php:1059 Error[256]:
> WikiDB_backend_PearDB_mysql: fatal database error
>
>       * DB Error: no such field
>       * (INSERT INTO link (linkfrom, linkto, relation) VALUES (2, 3, 0)
>   [nativecode=3D1054 ** Unknown column 'relation' in 'field list'])
>      *
>
>   lib/WikiDB/backend/PearDB.php:98 Warning[512]: WARNING: database still
>    locked (lock_count =3D $this->_lock_count)
>
>       * <br />
>
>
> Here I do not understand what is going on.

Oops, upgrade error. I forgot something.
Best is to use your phpMyAdmin with the following snippet:

ALTER TABLE accesslog CHANGE remote_host VARCHAR(100);

<enter> // this may fail.

ALTER TABLE link ADD relation  INT DEFAULT 0;
CREATE INDEX link_relation ON link (relation);

<enter> // this is required.

And then optionally again ?action=3Dupgrade to fill in the relations.


> I guess there are many possibilities to migrate the DB, but my knowledge
>   about PHP and MySQL are very limited (I'm willing to learn if
> necessary). I also have only limited rights on the host where I run the
> Wiki (Basically I can modify files inside the http directories, change
> permissions of these file and have access to phpMyAdmin 2.8.2.4).
>
> Can you guide me into the right direction, or maybe even present a
> simple solution for this?
>
> Thanks in advance for any help!
--=20
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] How to upgrade MySQL DB from PHPWiki 1.3.12p2 to 1.3.14

[<sac...@un...>]

Hi there,

my host provider recently upgraded PHP from 4.3.9 to 5.1.6, and on the 
same time, MySQL from 4.0 to 4.1.21.

As a consequence, my Phpwiki version 1.3.12p2 stopped working.
I got the following error:

  Fatal error: Cannot redeclare hash() in
  /home/httpd/vhosts/scanita.net/httpdocs/phpwiki_old/lib/stdlib.php
  on line 1276

(I do understand this problem)


In order to fix it, I installed Phpwiki 1.3.14. But when I tried to use 
      the same DB as before, I got the following error:

  lib/WikiDB/backend/PearDB.php:1059 Error[256]:
  WikiDB_backend_PearDB_mysql: fatal database error

      * DB Error: no such field
      * (SELECT cached_html FROM page WHERE pagename='HomePage' 
[nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
      *

(I do understand this problem too)


I tried the upgrade action (.../phpwiki/index.php&action=upgrade), but 
this did not seem to work:

  Upgrading this PhpWiki
  check for necessary database updates - SQL
  db version: we want 1030.14
  db version: we have 0
  Backend type: mysql
  check for table session ...OK
  check for table pref ...OK
  check for table member ...OK
  Rebuild entire database to upgrade relation links ...
  Fatal Error:

  lib/WikiDB/backend/PearDB.php:1059 Error[256]: 
WikiDB_backend_PearDB_mysql: fatal database error

      * DB Error: no such field
      * (INSERT INTO link (linkfrom, linkto, relation) VALUES (2, 3, 0) 
  [nativecode=1054 ** Unknown column 'relation' in 'field list'])
     *

  lib/WikiDB/backend/PearDB.php:98 Warning[512]: WARNING: database still 
   locked (lock_count = $this->_lock_count)

      * <br />


Here I do not understand what is going on.


I guess there are many possibilities to migrate the DB, but my knowledge 
  about PHP and MySQL are very limited (I'm willing to learn if 
necessary). I also have only limited rights on the host where I run the 
Wiki (Basically I can modify files inside the http directories, change 
permissions of these file and have access to phpMyAdmin 2.8.2.4).

Can you guide me into the right direction, or maybe even present a 
simple solution for this?

Thanks in advance for any help!

-Sacha

Re: [Phpwiki-talk] Fwd: phpwiki errors when trying to upgrade

[Chris O'H. <cm...@gm...>]

Thanks for the response.

The upgrade process looked to be working nicely until..

http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot3.png

http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot4.png

Is this an error with my configuration, the database.

I've checkout the lastest wiki via cvs and I notice in the mysql
initialize file there are a few other upgrades to the mysql database
since 1.3.11, should I apply these as well. They look mostly
authorisation related and I am not really using too strict an
authorisation for my wiki.  Do I need to apply those changes too?

Sorry if it seems like I require a bit of hand holding. I am keen
linux user but don't have an IT background so have to figure most
things out for myself. Or ask questions :)

I appreciate the quick responses though.

Regards,

Chris

On 23/07/07, Reini Urban <ru...@x-...> wrote:
> Chris O'Halloran schrieb:
> > Hello people.
> >
> > I am having a few issues with the upgrade process
> >
> > I recently had a harddrive die but I managed to recover the phpwiki
> > database from the mysql directory.
> >
> > the wiki had been running version 11 but in rebuilding the phpwiki I
> > thought I would use the latest version 14.
> >
> > I have got the wiki working again but the edit function isn't working
> > and I thought this was probably related to the upgrade function
> > ?action=upgrade
> >
> > I tried running this with the following config file
> >
> > http://homepages.slingshot.co.nz/~cmoman/phpwiki/config.ini
> >
> > and I got the following errors.
> >
> > http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot1.png
> >
> > http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot2.png
> >
> > I suppose this relates to the mysql schema.
> >
> > Is there someway I can manually upgrade the mysql schema without using
> > the wiki interface.  I seem to recall this was an option in the past.
> >
> > Thoughts comments welcome.
>
> I've made no special upgrade script yet to add relations to the link table.
> But this is trivial:
>
> ALTER TABLE link ADD relation INT DEFAULT 0;
> CREATE INDEX relation ON link (relation);
>
> Normally such upgrade recipes are in schemas/*-initialize.sql
> I just added it now.
>
> --
> Reini Urban
> http://phpwiki.org/  http://murbreak.at/
> http://helsinki.at/  http://spacemovie.mur.at/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] Corrupt DB database

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

Sampo Niskanen schrieb:
> On Mon, 23 Jul 2007, Reini Urban wrote:
>> The easiest would then be to dump the pages and load it again:
>> PhpWikiAdministration Backup & Restore.
>> This should fix up the links, when the pages are correct.
> 
> I was finally able to take a snapshot of the dysfunctional wiki, set up a 
> virgin wiki and load the snapshot back.  (Uploading a full dump failed.) 
> I had not tried the snapshots, because making a file dump to the server 
> failed when it tried to read the home page and I assumed the same would 
> happen with the snapshots, but it worked.
> 
> Thanks for the help, I hope the wiki won't corrupt again.

This is probably due to unstable OS locking, usually only happening
with db4.3. This is a very bad release.
All other Berkeley versions are not affected.

I've setup a cronjob to dump away and verify my db4.3 testserver every day.
I would rather try to change to some SQL or file backend, than using db4.3.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] Corrupt DB database

[Sampo N. <spn...@cc...>]

Hi,

On Mon, 23 Jul 2007, Reini Urban wrote:
> The easiest would then be to dump the pages and load it again:
> PhpWikiAdministration Backup & Restore.
> This should fix up the links, when the pages are correct.

I was finally able to take a snapshot of the dysfunctional wiki, set up a 
virgin wiki and load the snapshot back.  (Uploading a full dump failed.) 
I had not tried the snapshots, because making a file dump to the server 
failed when it tried to read the home page and I assumed the same would 
happen with the snapshots, but it worked.

Thanks for the help, I hope the wiki won't corrupt again.

-- 
   __________________________________________________
  /____\   Sampo Niskanen <=> sam...@ik...  \
        \       http://www.iki.fi/sampo.niskanen/     \
         \     ________________________________________\___
          \___/___________________________________________/

Re: [Phpwiki-talk] Fwd: phpwiki errors when trying to upgrade

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

Chris O'Halloran schrieb:
> Hello people.
> 
> I am having a few issues with the upgrade process
> 
> I recently had a harddrive die but I managed to recover the phpwiki
> database from the mysql directory.
> 
> the wiki had been running version 11 but in rebuilding the phpwiki I
> thought I would use the latest version 14.
> 
> I have got the wiki working again but the edit function isn't working
> and I thought this was probably related to the upgrade function
> ?action=upgrade
> 
> I tried running this with the following config file
> 
> http://homepages.slingshot.co.nz/~cmoman/phpwiki/config.ini
> 
> and I got the following errors.
> 
> http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot1.png
> 
> http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot2.png
> 
> I suppose this relates to the mysql schema.
> 
> Is there someway I can manually upgrade the mysql schema without using
> the wiki interface.  I seem to recall this was an option in the past.
> 
> Thoughts comments welcome.

I've made no special upgrade script yet to add relations to the link table.
But this is trivial:

ALTER TABLE link ADD relation INT DEFAULT 0;
CREATE INDEX relation ON link (relation);

Normally such upgrade recipes are in schemas/*-initialize.sql
I just added it now.

-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] Corrupt DB database

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

Sampo Niskanen schrieb:
> Hi,
> 
> 
> I have phpwiki installed and configured to run several wikis on a single 
> machine using the DB4 database handler.  Today, I was editing the homepage 
> of one wiki (the homepage in this case named "Etusivu"), but when saving 
> the page I got an error message, and it corrupted the database.
> 
> Now, when I go to the front page a get the message "Loading up virgin 
> wiki", and a list of pages added, which then fails with the error messages
> 
> /usr/share/phpwiki/lib/DbaDatabase.php:162: Error: 
> /home/phpwiki/phpwiki_linnea_pagedb.db4: dba error: 
> store[replace](liPhpWikiDocumentation)
> 
> /usr/share/phpwiki/lib/DbaDatabase.php:134: Notice: dba_replace() [<a 
> href='function.dba-replace'>function.dba-replace</a>]: à}6·(null)
> 
> Attempting to edit the homepage seems to work until saving, whence it 
> again fails.  All the other pages in the wiki are intact, and can be 
> accessed by the appropriate URL.
> 
> 
> I have tried to fix the databases using the db-utilities, but with no 
> luck.  The verifier reports the following errors in the databases:
> 
> # db4.3_verify phpwiki_linnea_pagedb.db4
> db_verify: Page 1141: invalid next_pgno 1142
> db_verify: phpwiki_linnea_pagedb.db4: DB_VERIFY_BAD: Database verification 
> failed
> # db4.3_verify phpwiki_linnea_session.db4
> db_verify: Page 20790: item 0 of unrecognizable type
> db_verify: Page 20790: item 1 of unrecognizable type
> db_verify: Page 20790: gap between items at offset 4072
> db_verify: Page 20790: item order check unsafe: skipping
> db_verify: Page 53950: item 62 of unrecognizable type
> db_verify: Page 53950: item 63 of unrecognizable type
> db_verify: Page 53950: gap between items at offset 3112
> db_verify: Page 53950: item order check unsafe: skipping
> db_verify: phpwiki_linnea_session.db4: DB_VERIFY_BAD: Database 
> verification failed
> 
> 
> I have tried dumping and reconstructing the databases using db4.3_dump and 
> db4.3_load, but this results in a wiki where all pages are intact, but all 
> links are to creating a non-existing pages (even though the pages are 
> visible by typing the URL).  I can't figure out how to use db4.3_recover, 
> as it doesn't accept the database file on the command line.
> 
> 
> I have also attempted to rewrite the home page using the Load File admin 
> option, but it again fails with the message
> 
> /usr/share/phpwiki/lib/DbaDatabase.php:162: Error: 
> /home/phpwiki/phpwiki_linnea_pagedb.db4: dba error: 
> store[insert](v129:Etusivu)
> 
> /usr/share/phpwiki/lib/DbaDatabase.php:143: Notice: dba_insert() [<a 
> href='function.dba-insert'>function.dba-insert</a>]: à}6·(null)
> 
> 
> I hope someone could help me fix the database and get the wiki working 
> again.  The dysfunctional wiki can be accessed at http://linnea.dy.fi/

The easiest would then be to dump the pages and load it again: 
PhpWikiAdministration Backup & Restore.
This should fix up the links, when the pages are correct.


-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

[Phpwiki-talk] Fwd: phpwiki errors when trying to upgrade

[Chris O'H. <cm...@gm...>]

Hello people.

I am having a few issues with the upgrade process

I recently had a harddrive die but I managed to recover the phpwiki
database from the mysql directory.

the wiki had been running version 11 but in rebuilding the phpwiki I
thought I would use the latest version 14.

I have got the wiki working again but the edit function isn't working
and I thought this was probably related to the upgrade function
?action=upgrade

I tried running this with the following config file

http://homepages.slingshot.co.nz/~cmoman/phpwiki/config.ini

and I got the following errors.

http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot1.png

http://homepages.slingshot.co.nz/~cmoman/phpwiki/snapshot2.png

I suppose this relates to the mysql schema.

Is there someway I can manually upgrade the mysql schema without using
the wiki interface.  I seem to recall this was an option in the past.

Thoughts comments welcome.

Regards

Chris

[Phpwiki-talk] Corrupt DB database

[Sampo N. <spn...@cc...>]

Hi,


I have phpwiki installed and configured to run several wikis on a single 
machine using the DB4 database handler.  Today, I was editing the homepage 
of one wiki (the homepage in this case named "Etusivu"), but when saving 
the page I got an error message, and it corrupted the database.

Now, when I go to the front page a get the message "Loading up virgin 
wiki", and a list of pages added, which then fails with the error messages

/usr/share/phpwiki/lib/DbaDatabase.php:162: Error: 
/home/phpwiki/phpwiki_linnea_pagedb.db4: dba error: 
store[replace](liPhpWikiDocumentation)

/usr/share/phpwiki/lib/DbaDatabase.php:134: Notice: dba_replace() [<a 
href='function.dba-replace'>function.dba-replace</a>]: à}6·(null)

Attempting to edit the homepage seems to work until saving, whence it 
again fails.  All the other pages in the wiki are intact, and can be 
accessed by the appropriate URL.


I have tried to fix the databases using the db-utilities, but with no 
luck.  The verifier reports the following errors in the databases:

# db4.3_verify phpwiki_linnea_pagedb.db4
db_verify: Page 1141: invalid next_pgno 1142
db_verify: phpwiki_linnea_pagedb.db4: DB_VERIFY_BAD: Database verification 
failed
# db4.3_verify phpwiki_linnea_session.db4
db_verify: Page 20790: item 0 of unrecognizable type
db_verify: Page 20790: item 1 of unrecognizable type
db_verify: Page 20790: gap between items at offset 4072
db_verify: Page 20790: item order check unsafe: skipping
db_verify: Page 53950: item 62 of unrecognizable type
db_verify: Page 53950: item 63 of unrecognizable type
db_verify: Page 53950: gap between items at offset 3112
db_verify: Page 53950: item order check unsafe: skipping
db_verify: phpwiki_linnea_session.db4: DB_VERIFY_BAD: Database 
verification failed


I have tried dumping and reconstructing the databases using db4.3_dump and 
db4.3_load, but this results in a wiki where all pages are intact, but all 
links are to creating a non-existing pages (even though the pages are 
visible by typing the URL).  I can't figure out how to use db4.3_recover, 
as it doesn't accept the database file on the command line.


I have also attempted to rewrite the home page using the Load File admin 
option, but it again fails with the message

/usr/share/phpwiki/lib/DbaDatabase.php:162: Error: 
/home/phpwiki/phpwiki_linnea_pagedb.db4: dba error: 
store[insert](v129:Etusivu)

/usr/share/phpwiki/lib/DbaDatabase.php:143: Notice: dba_insert() [<a 
href='function.dba-insert'>function.dba-insert</a>]: à}6·(null)


I hope someone could help me fix the database and get the wiki working 
again.  The dysfunctional wiki can be accessed at http://linnea.dy.fi/


Thanks for any help.

-- 
   __________________________________________________
  /____\   Sampo Niskanen <=> sam...@ik...  \
        \       http://www.iki.fi/sampo.niskanen/     \
         \     ________________________________________\___
          \___/___________________________________________/

Re: [Phpwiki-talk] New params in Button method

[Sabri L. <sab...@gm...>]

On 7/17/07, Reini Urban <ru...@x-...> wrote:

> The 3rd and 4th args are optional of course.
>
> 1: name
> 2: label
> 3: classname
> 4: array of options


ok.

Thank you.
-- Sabri.


> 2007/7/17, Sabri LABBENE <sab...@st...>:
> > Hi,
> > I was performing some changes on the actionbar and after making my
> working copy up to date with recent versions of cvs repository, I noticed
> some changes in Theme Button method. In fact, new params were added. Can
> someone tell what these new params are for?
> >
> > The previous function:
> > <?= Button("edit", $revision->isCurrent() ? _("Text Editor") : _("Edit
> Old Revision")) ?>
> >
> >
> > The new one:
> > <?= Button("edit", $revision->isCurrent() ? _("Edit") : _("Edit Old
> Revision"), false, array('id'=>'btn-edit')) ?>
> >
> > If I have to add a new button to the actionbar, should it be recognized
> using a specific id ? If yes, then where these ids are managed?
> >
> > Thanks for help,
> > -- Sabri.
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Phpwiki-talk mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> >
>
>
> --
> Reini Urban
> http://phpwiki.org/              http://murbreak.at/
> http://spacemovie.mur.at/   http://helsinki.at/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] New params in Button method

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

The 3rd and 4th args are optional of course.

1: name
2: label
3: classname
4: array of options


2007/7/17, Sabri LABBENE <sab...@st...>:
> Hi,
> I was performing some changes on the actionbar and after making my working copy up to date with recent versions of cvs repository, I noticed some changes in Theme Button method. In fact, new params were added. Can someone tell what these new params are for?
>
> The previous function:
> <?= Button("edit", $revision->isCurrent() ? _("Text Editor") : _("Edit Old Revision")) ?>
>
>
> The new one:
> <?= Button("edit", $revision->isCurrent() ? _("Edit") : _("Edit Old Revision"), false, array('id'=>'btn-edit')) ?>
>
> If I have to add a new button to the actionbar, should it be recognized using a specific id ? If yes, then where these ids are managed?
>
> Thanks for help,
> -- Sabri.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>


-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] New params in Button method

[Sabri L. <sab...@st...>]

Hi,
I was performing some changes on the actionbar and after making my =
working copy up to date with recent versions of cvs repository, I =
noticed some changes in Theme Button method. In fact, new params were =
added. Can someone tell what these new params are for?

The previous function:
<?=3D Button("edit", $revision->isCurrent() ? _("Text Editor") : _("Edit =
Old Revision")) ?>


The new one:
<?=3D Button("edit", $revision->isCurrent() ? _("Edit") : _("Edit Old =
Revision"), false, array('id'=3D>'btn-edit')) ?>

If I have to add a new button to the actionbar, should it be recognized =
using a specific id ? If yes, then where these ids are managed?

Thanks for help,
-- Sabri.

Re: [Phpwiki-talk] Database already exists error

[Chris O'H. <cm...@gm...>]

Hello Reini,

I forgot to say thanks for your help.

Thanks

Chris

On 19/06/07, Reini Urban <ru...@x-...> wrote:
> No, the session already exists.
>
> Try to use DB_SESSION=false
> or use a current version of phpwiki.
>
> 2007/6/19, Chris O'Halloran <cm...@gm...>:
> > http://homepages.slingshot.co.nz/~cmoman/pics/phpwiki_screenshot.png
> >
> > The wiki uses mysql as the backend.
> >
> > In general it operates correctly but when I am logged in any creating
> > a saving changes, it present this error message at the bottom of the
> > page
> >
> > When I log out, there is not mention of the error again.
> >
> > I have set permissions to allow anonymous users and bogo users but
> > this hasn't changed the error message appearing at the bottom.
> >
> > Thoughts, comment appreciated.
> >
> > BTW using
> > I am running phpwiki 1.3.11p1  on my Kubuntu Dapper machine.
>
> --
> Reini Urban
> http://phpwiki.org/              http://murbreak.at/
> http://spacemovie.mur.at/   http://helsinki.at/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] GoPHP5 project, anyone?

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

Steve Wainstead schrieb:
> I am thinking the benefit is not having to support PHP4 anymore :o)
> 
> What I did for PHP3->PHP4 was to simply say, "Version 1.0 will work  
> with PHP3, the 1.1 series requires PHP4." Simply creating a  
> demarcation point in the releases keeps plenty of people in the loop;  
> and PHP4 will be discontinued sooner or later (next year, if I read  
> correctly), so PhpWiki dropping PHP4 support is pretty much an  
> inevitability.

So it's a good option for 1.4, which will come later this year.
Other opinions?

BTW: Profiling tells me that phpwiki is spending a lot of time in the 
version detection code. Almost 10% of the database and formatting code.
I assume that the formatting code will get a bit faster in a php5-only 
branch. But the real speed advantage will be php6.

> Just my two cents.
> ~swain
> 
> On Jul 11, 2007, at 6:36 PM, Reini Urban wrote:
> 
>> Steve Wainstead schrieb:
>>> Hello Reini, et al:
>>>
>>> Has anyone approached you yet about the Go PHP 5 project yet? It's a
>>> grassroots campaign to get projects to drop support for PHP4.
>>>
>>> I loosely follow the Gallery project and it looks like they are  
>>> about to
>>> join up (see below).
>> Nope.
>> What a stupid idea. What should be the benefits?
>>
>> I see a lot of dropped support for servers only having php4.
>> One of the basic principles of phpwiki was always "run everywhere,  
>> with
>> any kind of php version or database or backend storage."
>> We should be proud to have full ph4 support, whilst the trendy folks
>> just bother to support nifty php5 features.
>>
>> They should rather target packagers like debian, redhat, ubuntu,
>> apachefriends and mandrake to drop php4, not us apps.
>>
>> I follow the php developers complaints about not wanting to maintain
>> php4 any more.
>> perl still supports 5.005 up to 5.8 and 5.10 and working on 6,
>> just the php folks are too stupid to bring up their build system and
>> workflow to a maintainable level.
>>
>> One counter argument: rdf-api would be nice to have for a reasoner
>> backend and query parser (owl export, sparql). They only support php5
>> for these submodules and that would be hard to rewrite to work with  
>> php4
>> also.
>>
>>> ~swain
>>>
>>> Begin forwarded message:
>>>
>>>> *From: *Larry Garfield <la...@ga...
>>>> <mailto:la...@ga...>>
>>>> *Date: *July 10, 2007 10:36:40 PM EDT
>>>> *To: *Bharat Mediratta <bh...@me...  
>>>> <mailto:bh...@me...>>
>>>> *Cc: *gal...@li...
>>>> <mailto:gal...@li...>
>>>> *Subject: **Re: [Gallery-devel] The PHP 5 revolution*
>>>>
>>>> Hi again, Bharat.  It's not quite the list you had before, but  
>>>> does 30
>>>> projects and 50+ web hosts count as "critical mass"?
>>>>
>>>> http://gophp5.org/projects
>>>> http://gophp5.org/hosts
>>>>
>>>> That's also not counting web hosts that offer PHP 5 as an option but
>>>> not the
>>>> default.
>>>>
>>>> I'm actually rather surprised myself at how much steam this has  
>>>> picked
>>>> up.  I
>>>> don't know if you follow php-internals at all, but they're actively
>>>> discussing dropping PHP 4 support completely within the next year.
>>>>
>>>> Is this something Gallery could get behind at this point?
>>>>
>>>> On Sunday 01 July 2007, Bharat Mediratta wrote:
>>>>> Larry,
>>>>>
>>>>> How's this progressing?  Andy pointed out that we should focus  
>>>>> on the
>>>>> high profile php4-only projects like ezPublish.  Serious hosts that
>>>>> offer php4 only today will offer both versions when the pressure  
>>>>> is on,
>>>>> but it would help if there were less pressure to keep php4  
>>>>> around...
>>>>>
>>>>> -Bharat
>>>>>
>>>>> Bharat Mediratta wrote:
>>>>>> Larry Garfield wrote:
>>>>>>> Thanks, Bharat.  I can understand your position, certainly.  What
>>>>>>> would you consider "critical mass"?  Shear number or some  
>>>>>>> number of
>>>>>>> "big" projects (for some definition of big) or...?
>>>>>> Good question :-)  I think that we'd want to see the majority  
>>>>>> of the
>>>>>> best-of-breed applications in various different webapp categories
>>>>>> support this.
>>>>>>
>>>>>> Here are lists of apps that our affiliate web hosts support:
>>>>>>     http://partners.powweb.com/powweb/autoInstalls.bml
>>>>>>     http://wiki.dreamhost.com/One_Click_Installs
>>>>>>
>>>>>> And we'd want the top 3 hosts here to support PHP5 (I think  
>>>>>> that they
>>>>>> already do, but it wouldn't hurt to get them on the list):
>>>>>>     http://gallery.menalto.com/wiki/Web_Hosting_Referral_Page
>>>>>>
>>>>>> If you can get 50% of those apps on board, I think that would  
>>>>>> be more
>>>>>> than enough.
>>>>>>
>>>>>>> As for advertising, I don't believe we're planning any sort of  
>>>>>>> real
>>>>>>> advertising.  This isn't a money-making venture by any  
>>>>>>> means. :-)  We
>>>>>>> plan to have a page/link for web hosts that offer 5.2 out of  
>>>>>>> the box,
>>>>>>> just as we'll list projects that are targeting 5.2, as an added
>>>>>>> incentive for hosts to get on board; they get to appear
>>>>>>> "future-friendly".  That's as close to advertising as we plan  
>>>>>>> to get,
>>>>>>> though.
>>>>>> Thanks.  That's what I figured, but I wanted to make sure that  
>>>>>> we were
>>>>>> clear :-)
>>>>>>
>>>>>> -Bharat
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] GoPHP5 project, anyone?

[Steve W. <sw...@pa...>]

I am thinking the benefit is not having to support PHP4 anymore :o)

What I did for PHP3->PHP4 was to simply say, "Version 1.0 will work  
with PHP3, the 1.1 series requires PHP4." Simply creating a  
demarcation point in the releases keeps plenty of people in the loop;  
and PHP4 will be discontinued sooner or later (next year, if I read  
correctly), so PhpWiki dropping PHP4 support is pretty much an  
inevitability.

Just my two cents.
~swain

On Jul 11, 2007, at 6:36 PM, Reini Urban wrote:

> Steve Wainstead schrieb:
>> Hello Reini, et al:
>>
>> Has anyone approached you yet about the Go PHP 5 project yet? It's a
>> grassroots campaign to get projects to drop support for PHP4.
>>
>> I loosely follow the Gallery project and it looks like they are  
>> about to
>> join up (see below).
>
> Nope.
> What a stupid idea. What should be the benefits?
>
> I see a lot of dropped support for servers only having php4.
> One of the basic principles of phpwiki was always "run everywhere,  
> with
> any kind of php version or database or backend storage."
> We should be proud to have full ph4 support, whilst the trendy folks
> just bother to support nifty php5 features.
>
> They should rather target packagers like debian, redhat, ubuntu,
> apachefriends and mandrake to drop php4, not us apps.
>
> I follow the php developers complaints about not wanting to maintain
> php4 any more.
> perl still supports 5.005 up to 5.8 and 5.10 and working on 6,
> just the php folks are too stupid to bring up their build system and
> workflow to a maintainable level.
>
> One counter argument: rdf-api would be nice to have for a reasoner
> backend and query parser (owl export, sparql). They only support php5
> for these submodules and that would be hard to rewrite to work with  
> php4
> also.
>
>> ~swain
>>
>> Begin forwarded message:
>>
>>> *From: *Larry Garfield <la...@ga...
>>> <mailto:la...@ga...>>
>>> *Date: *July 10, 2007 10:36:40 PM EDT
>>> *To: *Bharat Mediratta <bh...@me...  
>>> <mailto:bh...@me...>>
>>> *Cc: *gal...@li...
>>> <mailto:gal...@li...>
>>> *Subject: **Re: [Gallery-devel] The PHP 5 revolution*
>>>
>>> Hi again, Bharat.  It's not quite the list you had before, but  
>>> does 30
>>> projects and 50+ web hosts count as "critical mass"?
>>>
>>> http://gophp5.org/projects
>>> http://gophp5.org/hosts
>>>
>>> That's also not counting web hosts that offer PHP 5 as an option but
>>> not the
>>> default.
>>>
>>> I'm actually rather surprised myself at how much steam this has  
>>> picked
>>> up.  I
>>> don't know if you follow php-internals at all, but they're actively
>>> discussing dropping PHP 4 support completely within the next year.
>>>
>>> Is this something Gallery could get behind at this point?
>>>
>>> On Sunday 01 July 2007, Bharat Mediratta wrote:
>>>> Larry,
>>>>
>>>> How's this progressing?  Andy pointed out that we should focus  
>>>> on the
>>>> high profile php4-only projects like ezPublish.  Serious hosts that
>>>> offer php4 only today will offer both versions when the pressure  
>>>> is on,
>>>> but it would help if there were less pressure to keep php4  
>>>> around...
>>>>
>>>> -Bharat
>>>>
>>>> Bharat Mediratta wrote:
>>>>> Larry Garfield wrote:
>>>>>> Thanks, Bharat.  I can understand your position, certainly.  What
>>>>>> would you consider "critical mass"?  Shear number or some  
>>>>>> number of
>>>>>> "big" projects (for some definition of big) or...?
>>>>>
>>>>> Good question :-)  I think that we'd want to see the majority  
>>>>> of the
>>>>> best-of-breed applications in various different webapp categories
>>>>> support this.
>>>>>
>>>>> Here are lists of apps that our affiliate web hosts support:
>>>>>     http://partners.powweb.com/powweb/autoInstalls.bml
>>>>>     http://wiki.dreamhost.com/One_Click_Installs
>>>>>
>>>>> And we'd want the top 3 hosts here to support PHP5 (I think  
>>>>> that they
>>>>> already do, but it wouldn't hurt to get them on the list):
>>>>>     http://gallery.menalto.com/wiki/Web_Hosting_Referral_Page
>>>>>
>>>>> If you can get 50% of those apps on board, I think that would  
>>>>> be more
>>>>> than enough.
>>>>>
>>>>>> As for advertising, I don't believe we're planning any sort of  
>>>>>> real
>>>>>> advertising.  This isn't a money-making venture by any  
>>>>>> means. :-)  We
>>>>>> plan to have a page/link for web hosts that offer 5.2 out of  
>>>>>> the box,
>>>>>> just as we'll list projects that are targeting 5.2, as an added
>>>>>> incentive for hosts to get on board; they get to appear
>>>>>> "future-friendly".  That's as close to advertising as we plan  
>>>>>> to get,
>>>>>> though.
>>>>>
>>>>> Thanks.  That's what I figured, but I wanted to make sure that  
>>>>> we were
>>>>> clear :-)
>>>>>
>>>>> -Bharat
>
> -- 
> Reini Urban
> http://phpwiki.org/  http://murbreak.at/
> http://helsinki.at/  http://spacemovie.mur.at/
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] GoPHP5 project, anyone?

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

Steve Wainstead schrieb:
> Hello Reini, et al:
> 
> Has anyone approached you yet about the Go PHP 5 project yet? It's a 
> grassroots campaign to get projects to drop support for PHP4.
> 
> I loosely follow the Gallery project and it looks like they are about to 
> join up (see below).

Nope.
What a stupid idea. What should be the benefits?

I see a lot of dropped support for servers only having php4.
One of the basic principles of phpwiki was always "run everywhere, with 
any kind of php version or database or backend storage."
We should be proud to have full ph4 support, whilst the trendy folks 
just bother to support nifty php5 features.

They should rather target packagers like debian, redhat, ubuntu, 
apachefriends and mandrake to drop php4, not us apps.

I follow the php developers complaints about not wanting to maintain 
php4 any more.
perl still supports 5.005 up to 5.8 and 5.10 and working on 6,
just the php folks are too stupid to bring up their build system and 
workflow to a maintainable level.

One counter argument: rdf-api would be nice to have for a reasoner 
backend and query parser (owl export, sparql). They only support php5 
for these submodules and that would be hard to rewrite to work with php4 
also.

> ~swain
> 
> Begin forwarded message:
> 
>> *From: *Larry Garfield <la...@ga... 
>> <mailto:la...@ga...>>
>> *Date: *July 10, 2007 10:36:40 PM EDT
>> *To: *Bharat Mediratta <bh...@me... <mailto:bh...@me...>>
>> *Cc: *gal...@li... 
>> <mailto:gal...@li...>
>> *Subject: **Re: [Gallery-devel] The PHP 5 revolution*
>>
>> Hi again, Bharat.  It's not quite the list you had before, but does 30 
>> projects and 50+ web hosts count as "critical mass"?
>>
>> http://gophp5.org/projects
>> http://gophp5.org/hosts
>>
>> That's also not counting web hosts that offer PHP 5 as an option but 
>> not the 
>> default.  
>>
>> I'm actually rather surprised myself at how much steam this has picked 
>> up.  I 
>> don't know if you follow php-internals at all, but they're actively 
>> discussing dropping PHP 4 support completely within the next year.  
>>
>> Is this something Gallery could get behind at this point?
>>
>> On Sunday 01 July 2007, Bharat Mediratta wrote:
>>> Larry,
>>>
>>> How's this progressing?  Andy pointed out that we should focus on the
>>> high profile php4-only projects like ezPublish.  Serious hosts that
>>> offer php4 only today will offer both versions when the pressure is on,
>>> but it would help if there were less pressure to keep php4 around...
>>>
>>> -Bharat
>>>
>>> Bharat Mediratta wrote:
>>>> Larry Garfield wrote:
>>>>> Thanks, Bharat.  I can understand your position, certainly.  What
>>>>> would you consider "critical mass"?  Shear number or some number of
>>>>> "big" projects (for some definition of big) or...?
>>>>
>>>> Good question :-)  I think that we'd want to see the majority of the
>>>> best-of-breed applications in various different webapp categories
>>>> support this.
>>>>
>>>> Here are lists of apps that our affiliate web hosts support:
>>>>     http://partners.powweb.com/powweb/autoInstalls.bml
>>>>     http://wiki.dreamhost.com/One_Click_Installs
>>>>
>>>> And we'd want the top 3 hosts here to support PHP5 (I think that they
>>>> already do, but it wouldn't hurt to get them on the list):
>>>>     http://gallery.menalto.com/wiki/Web_Hosting_Referral_Page
>>>>
>>>> If you can get 50% of those apps on board, I think that would be more
>>>> than enough.
>>>>
>>>>> As for advertising, I don't believe we're planning any sort of real
>>>>> advertising.  This isn't a money-making venture by any means. :-)  We
>>>>> plan to have a page/link for web hosts that offer 5.2 out of the box,
>>>>> just as we'll list projects that are targeting 5.2, as an added
>>>>> incentive for hosts to get on board; they get to appear
>>>>> "future-friendly".  That's as close to advertising as we plan to get,
>>>>> though.
>>>>
>>>> Thanks.  That's what I figured, but I wanted to make sure that we were
>>>> clear :-)
>>>>
>>>> -Bharat

-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/