phpwiki-talk

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/

[Phpwiki-talk] GoPHP5 project, anyone?

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

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).

~swain

Begin forwarded message:

> From: Larry Garfield <la...@ga...>
> Date: July 10, 2007 10:36:40 PM EDT
> To: Bharat Mediratta <bh...@me...>
> Cc: 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
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> 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/
>>> __[ g a l l e r y - d e v e l ]_________________________
>>>
>>> [ list info/archive --> http://gallery.sf.net/lists.php ]
>>> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>
>
> -- 
> Larry Garfield			AIM: LOLG42
> la...@ga...		ICQ: 6817012
>
> "If nature has made any one thing less susceptible than all others of
> exclusive property, it is the action of the thinking power called  
> an idea,
> which an individual may exclusively possess as long as he keeps it to
> himself; but the moment it is divulged, it forces itself into the  
> possession
> of every one, and the receiver cannot dispossess himself of it."   
> -- Thomas
> Jefferson
>
> ---------------------------------------------------------------------- 
> ---
> 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/
> __[ g a l l e r y - d e v e l ]_________________________
>
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]
>

[Phpwiki-talk] wikiprofile standardization

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

Another forward from the wikistandards list:
Reini:
This idea came from the Montreal 2007 RoCoCoMeeting in persona, where
we discussed how to extend the interwiki map, to be able to use other
features in other wiki's and wiki-engines, different from linking just
to a page (interwiki), or using xmlrpc.
We don't even know the xmlrpc interface for the other wiki.
So we came up with a idea to publish for every wiki a wikiprofile,
with a list of links to be used for some features other might be
interested in.

I heavily opted for
<link rel="wiki.profile" type="application/rdf+xml"
href="http://mywiki.com/wiki?action=profile">
and optionally n3 version:
<link rel="wiki.profile" type="text/rdf+n3"
href="http://mywiki.com/wiki?action=profile&format=n3">

docuwiki and mediawiki I believe export a dublin core metadata list.

==============================================
Earle Martin:
Thanks to everyone who attended Tuesday's IRC meeting
(http://wikiohana.net/cgi-bin/wiki.pl/IrcMeetingJuly2007) - it was
productive. For those who weren't there, I was inviting discussion on
a project I've been working on called the Wiki Profile Vocabulary,
which is essentially an RDF vocabulary for describing wikis and
aspects of wikis. (The idea was originally suggested by Ward; thanks.)
You can find the latest version at
http://wikirdf.org/vocabulary/profile/ . There's also an article I
wrote about what a "profile document" is and how to make one, at
http://wikirdf.org/docs/creating-wiki-profiles.html .

What I'm hoping that wiki authors will do is add support for producing
these profile documents to their wiki engines, complete with
autodiscovery tags in the <head> sections of their HTML pages, in
order for robots and other mechanisms to find the information. In
theory, it would be possible to write code to automatically generate
sister site links from one wiki to another, just by entering the URI
of the other wiki.

Two main points were discussed:

The current version of the spec has a naive expectation that wiki URIs
are roughly of the form
http://example.com/scriptname?args=whatever;page=[page name here].
However some wiki engines use URIs of the form
http://example.com/scriptname/[page name here]/args. Chris Dent
suggested using URI Templates
(http://bitworking.org/projects/URI-Templates/) to define the form of
URIs, and this was generally agreed to be a good idea.

The other point was how to specify an autodiscovery method in page
HTML that points to a wiki's profile document. Suggestions were (note,
examples only; your engine's URI for producing a profile doesn't
matter):

A la Dublin Core (suggested by Reini Urban):
<meta name="wiki.profile" type="application/rdf+xml"
link="/wiki?action=profile">

A la FOAF (http://rdfweb.org/topic/Autodiscovery):
<link rel="meta" type="application/rdf+xml" href="/wiki?action=profile">

Hybrid:
<link rel="wiki.profile" type="application/rdf+xml"
href="/wiki?action=profile">

Hybrid, n3 version:
<link rel="wiki.profile" type="text/rdf+n3"
href="/wiki?action=profile&format=n3">

Also, the possibility of having a "standard location" like robots.txt
(http://www.robotstxt.org/) was mentioned, but was thought to be too
inflexible.

Out of all of these, I very much prefer the second, FOAF-style option,
because the profile is very much an example of metadata, and I'm not
too sure about how the "x.y" syntax works.

On the other hand, reading through the W3C specs, it is apparently
legal to have any QName (XML qualified name - see
http://www.w3.org/TR/xmlschema-2/#QName) as the value of a "link rel",
and a XML prefix can be used as long as it's been defined in an xmlns
attribute (http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_rel).

So I guess it would be possible to do
<link rel="rdfs:isDefinedBy"  type="application/rdf+xml"
href="/wiki?action=profile#Wiki">

...but that seems a little over the top. <link rel=meta> is a
well-known style and shouldn't cause any problems.

Cheers,

Earle.

 --
Earle Martin
           http://downlode.org/
http://purl.org/net/earlemartin/
_______________________________________________

wiki-standards mailing list. wik...@wi...
http://www.wikisym.org/cgi-bin/mailman/listinfo/wiki-standards

For the wiki-research, wiki-standards, wikisym-announce mailing lists,
please see:
http://www.wikisym.org/cgi-bin/mailman/listinfo

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

[Phpwiki-talk] UniversalWikiEditButton

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

A project we are working on in our monthly #wikiohana meetings,
brought some results.
See also http://wikiohana.net/cgi-bin/wiki.pl/IrcMeetingJuly2007
Forwarded from Brandon CS Sanders

Hello Wiki-Standards Gang,

There is a movement afoot to agree on an easily-recognizable
universal "Edit This" button.  We're using a consensus poll to
coalesce consensus around the metaphor and version 0.1 implementation
of the icon.  So far 52 wiki people are participating.  If you are
not yet involved, please go to http://www.aboutus.org/
UniversalWikiEditButton and add yourself as a {{NotYet}}  If you are
participating, please take a look at the current version of the
document and update your status accordingly.

Big thanks to Ted Ernst, FridemarPache and the other volunteer
facilitators.  If you'd like to help with active listening and
synthesis, we're organizing the facilitation effort at  http://
www.aboutus.org/Projects:UniversalWikiEditButton

Please invite folks who aren't yet participating to join the
process.  At the very least it's an interesting exercise in community
written standards.

See you on the poll!
Brandon
-- 
Reini

Re: [Phpwiki-talk] Syntax Highlighter plugin usage

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

Reini Urban wrote:
>2007/6/25, Sabri LABBENE <sab...@st...>:
>> Hi all,
>> It seems that the syntax highlighter plugin is disabled or 
>not installed.
>> The following syntax:
>>
>> <?plugin SyntaxHighlighter syntax=c style=kr color=emacs  #include 
>> <stdio.h>
>>
>>  int main() {
>>  printf("Lalala\n");
>>  }
>> ?>
>>
>> Gives the following errors:
>>
>> Plugin SyntaxHighlighter failed. sh: line 1: highlight: command not 
>> found
>>
>> Plugin SyntaxHighlighter failed. Couldn't start commandline 
>'highlight --data-dir /usr/share/highlight --style emacs -c 
>/work1/codex/sabri/codex-3.0/592_wysiwyg_integration/usr/share/
codex/src/www/phpwiki-1.3.12p3/uploads/highlight-emacs.css -F kr -q >-X -f
-S c'
>>
>> I want to have this plugin working. What do I need to do?
>
>Install highlight?
>
>Read lib/plugin/SyntaxHighlighter.php for the available 
>options, where to find the highlight executable.

Ok I've got the plugin working and I was surprised that there is no
difference between a preformatted text and the plugin result (no colors for
langage key words for example even if I change color and style plugin
parameters).

Another question:
What directory 'HIGHLIGHT_DATA_DIR' parameter should point to ? 

Thanks,
-- Sabri.

Re: [Phpwiki-talk] Syntax Highlighter plugin usage

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

2007/6/25, Sabri LABBENE <sab...@st...>:
> Hi all,
> It seems that the syntax highlighter plugin is disabled or not installed.
> The following syntax:
>
> <?plugin SyntaxHighlighter syntax=c style=kr color=emacs
>  #include <stdio.h>
>
>  int main() {
>  printf("Lalala\n");
>  }
> ?>
>
> Gives the following errors:
>
> Plugin SyntaxHighlighter failed. sh: line 1: highlight: command not found
>
> Plugin SyntaxHighlighter failed. Couldn't start commandline 'highlight --data-dir /usr/share/highlight --style emacs -c /work1/codex/sabri/codex-3.0/592_wysiwyg_integration/usr/share/codex/src/www/phpwiki-1.3.12p3/uploads/highlight-emacs.css -F kr -q -X -f -S c'
>
> I want to have this plugin working. What do I need to do?

Install highlight?

Read lib/plugin/SyntaxHighlighter.php for the available options,
where to find the highlight executable.
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] Syntax Highlighter plugin usage

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

Hi all,
It seems that the syntax highlighter plugin is disabled or not =
installed.
The following syntax:

<?plugin SyntaxHighlighter syntax=3Dc style=3Dkr color=3Demacs
 #include <stdio.h>

 int main() {
 printf("Lalala\n");
 }
?>=20

Gives the following errors:

Plugin SyntaxHighlighter failed. sh: line 1: highlight: command not =
found

Plugin SyntaxHighlighter failed. Couldn't start commandline 'highlight =
--data-dir /usr/share/highlight --style emacs -c =
/work1/codex/sabri/codex-3.0/592_wysiwyg_integration/usr/share/codex/src/=
www/phpwiki-1.3.12p3/uploads/highlight-emacs.css -F kr -q -X -f -S c'

I want to have this plugin working. What do I need to do?

Thanks,
-- Sabri.

Re: [Phpwiki-talk] Welcome to the "Phpwiki-talk" mailing list (Digest mode)

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

Brian Herman schrieb:
> I would like to make the stylesheets of phpwiki editable by the users 
> how would I do that?

I haven't thought about that yet.
It must be a special pagetype, and wrote by a new script from the 
database to the browser.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [Phpwiki-talk] Welcome to the "Phpwiki-talk" mailing list (Digest mode)

[Brian H. <bri...@gm...>]

I would like to make the stylesheets of phpwiki editable by the users how
would I do that?