phpwiki-talk

Re: [Phpwiki-talk] bug in action=upgrade

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

Arnaud Fontaine schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Yet another bug :
> 
> On the CVS version, with ADODB as a SQL lib, when trying to upgrade
> (action=upgrade) a 1.3.10 wiki, I have this error :
> 
> Error: mysql error: [1109: Unknown table 'mysql' in where clause] in
> EXECUTE("UPDATE mysql.db SET lock_tables_priv='Y' WHERE mysql.user='wiki'")
> 
> PLEASE ! Don't do this but use something like
> 
> GRANT LOCK ON `ecosol` . * TO 'wiki'@ 'localhost' WITH GRANT OPTION ;

I used the UPDATE / FLUSH statements because I have to query before if 
the mysql table already has the lock_tables_priv column.
Should check against errors here.
GRANT is better, ok.
Esp. when you may select the table, but are not allowed to change it.

> (don't remember if it's LOCK or LOCK_TABLES ... RTFM ;))
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] bug with CVS, ADO and purge markup cache

[Daniel B. <db...@db...>]

Trying ot purge the markup cache gives

lib/WikiDB/adodb/adodb-errorhandler.inc.php:76: Error: mysql error:
[1064: You have an error in your SQL syntax near 'WHERE
pagename='global_data'' at line 1] in EXECUTE("UPDATE page SET
cached_html= WHERE pagename='global_data'") 


Looks like the quoting isn't quite correct or something.

Re: [Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arnaud Fontaine wrote:
| Arnaud Fontaine wrote:
| | Reini Urban wrote:
| | | * blog pages and plugins for new blog theme to be useful at all.
| | | * finish ModeratedPage
| | | * finish configurator.php
| | | * check wikilens
| | |
| | | and check the new reports:
| | | locale broken,
|
| Just to answer to a part of my last message ... anyone knows the debian
| maintainer of the apache package ?? :)
|
| The force the LANG in the apache startup script to 'C' ... and because
| you set the locale to DEFAULT_LANGUAGE only if LANG is empty, it's
| always set to what apache send you ...

Still investigating .......

forcing the LANG in the apache startup script to fr_FR makes phpwiki
behaves strangelly :

Most of my 'fr' wikis are working ... almost fine. Most of the time,
they are in french and sometimes (hard to see when ... generaly when
logged in as an admin and performing an action=upgrade ... but not only)
it goes back to 'en'.

VERY strange.

We really need to set the locale once and very clearly ... not get
confused with LANG and DEFAULT_LANGUAGE ... well ... what else ... Oh
yes, we need an option to not allow locale switching.

Arnaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/6/2yAf3wgFyy1ARAsltAJ90bakW4ZmZ2PLwtR7n9ixrzp/9IgCfQVzK
q8RGXqy6szHMNSrjyH35iDI=
=4y/Y
-----END PGP SIGNATURE-----

Re: [Phpwiki-talk] HIDE_TOOLBARS ...

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arnaud Fontaine wrote:
| Hi all,
|
| I don't get why the HIDE_TOOLBARS global isn't set properly if I test it
| in body.tmpl ...

I finally changed the HIDE_TOOLBARS by a test on $revision

if(!$HIDE_TOOLBARS) is (nowdays) equivalent to
if(!empty($revision))

Less elegant but it works.

Arnaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/676yAf3wgFyy1ARAqSrAKDJpGi5vhvYp4fl2+fa3pC/FQdq1wCghnvO
/Rl/hvxmYD1s5fYLKY0gu+A=
=Jyl6
-----END PGP SIGNATURE-----

[Phpwiki-talk] bug in action=upgrade

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yet another bug :

On the CVS version, with ADODB as a SQL lib, when trying to upgrade
(action=upgrade) a 1.3.10 wiki, I have this error :

Error: mysql error: [1109: Unknown table 'mysql' in where clause] in
EXECUTE("UPDATE mysql.db SET lock_tables_priv='Y' WHERE mysql.user='wiki'")

PLEASE ! Don't do this but use something like

GRANT LOCK ON `ecosol` . * TO 'wiki'@ 'localhost' WITH GRANT OPTION ;

(don't remember if it's LOCK or LOCK_TABLES ... RTFM ;))

Arnaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/6G/yAf3wgFyy1ARAqG5AKD13RFhUgYjkeE2G2mlfFwgAJ5I9gCglfQz
xYrHHko/NobM4y+v6dCnqJw=
=ftd3
-----END PGP SIGNATURE-----

Re: [Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arnaud Fontaine wrote:
| Reini Urban wrote:
| | * blog pages and plugins for new blog theme to be useful at all.
| | * finish ModeratedPage
| | * finish configurator.php
| | * check wikilens
| |
| | and check the new reports:
| | locale broken,

Just to answer to a part of my last message ... anyone knows the debian
maintainer of the apache package ?? :)

The force the LANG in the apache startup script to 'C' ... and because
you set the locale to DEFAULT_LANGUAGE only if LANG is empty, it's
always set to what apache send you ...

Arnaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/52RyAf3wgFyy1ARApPsAKCCQQi/H8wMmKgqWXer2nXM079b9gCeKtIe
g2XDjxOzw8Wzzicp7bolEwg=
=Fgtx
-----END PGP SIGNATURE-----

Re: [Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

[Arnaud F. <ar...@cr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Reini Urban wrote:
| * blog pages and plugins for new blog theme to be useful at all.
| * finish ModeratedPage
| * finish configurator.php
| * check wikilens
|
| and check the new reports:
| locale broken,

very deeply broken .......
Please, could you explain what you do with locale ?
I recently updated a wiki running cvs and phpwiki ran the virgin wiki
script (don't ask me why ...). I saw it was loading the 'fr' pgsrc
(locale set to 'fr', you guessed) THEN the 'en' pgsrc and then ... ran
as an 'en' wiki ....

I checked every file in lib/ and found sometimes LANG is used as $LANG,
sometimes as $GLOBALS['LANG'] ... hmmm ...

The fixup_dynamic_configs function is a bit confused in IniConfig.php.

In your guessing_setlocale function, what are you supposed to return ?
The correct locale (like fr_FR, fr_FR@euro, etc ..) ? Why did you mix
locales with words like fran?ais, french ??

And finally ... after a bad defacement (yes, it happens sometimes ...
script kiddies got you ...) due to ... tikiwiki (ok, I have one site
using tikiwiki as a CMS ... I gonna drop it and migrate to a real CMS
lile SPIP ... or even textpattern), I updated everything. I now have php
4.3.10 using the debian package. Now, I have a locale problem in my old
1.3.4 wikis !!! They are all running with locale 'en' now !!!
AAAAAAAAAAAArrgghhhh

| peardbpassuser not loaded on pref change,
| session problems (I think I fixed that now).

Oh, I noticed you call Affected_Rows in DbSession.php.
This method is only defined for the ADODB backend !!!

Arnaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/41/yAf3wgFyy1ARAr0mAJ9GnKanYOGJymT9KdivLgQTmuP2eACcDrl9
u/ECdoUo0u9agZ5skrRPdRw=
=n9CE
-----END PGP SIGNATURE-----

[Phpwiki-talk] RE: [phpwiki-checkins] CVS: phpwiki/lib DbSession.php,1.28,1.29

[Charles C. <ch...@ru...>]

This change has a problem for SQL

lib/DBSession.php - DBSession_SQL->write() - line 208
        $result = $dbh->Affected_Rows();
should be
        $result = $dbh->affectedRows();

regards,
Charles

Re: [Phpwiki-talk] WikiDB.php caching fix part 2 of 2

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

Charles Corrigan schrieb:
>>Charles Corrigan schrieb:
>>>A patch to lib/WikiDB.php follows.  This is part 2 of my previous set of fixes to the
>>>caching logic. 
>>>
>>>While debugging why caching was not working for me, I found that get_versiondata()
>>>was behaving weirdly when the parameter $need_content was false.  It appears that
>>>php 4.3.10 on windows gets confused when an array element is created with an index
>>>of '0'.
> 
>>Please try to update your zend optimizer first.
>>  https://www.zend.com/store/products/zend-optimizer.php
>>I had the same problem.
> 
> I have never downloaded or used the zend optimizer on my windows machine, this is a stock php 4.3.10 on windows.  Therefore I
> suggest that the change is made as it will affect others that know nothing of the zend optimizer.  The patch is merely a change to
> otherwise unused constants, not a change to logic.

Ok, I will apply this patch, because it's simple and the index ['0'], 
has some ill magic. (empty, isset, ...)

But the point is still:
If your php is broken you have to fix the real problem,
because this special case in WikiDB_Cache will not be the only problem then.

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

RE: [Phpwiki-talk] WikiDB.php caching fix part 2 of 2

[Charles C. <ch...@ru...>]

> Charles Corrigan schrieb:
> > A patch to lib/WikiDB.php follows.  This is part 2 of my previous set of fixes to the
> > caching logic. 
> > 
> > While debugging why caching was not working for me, I found that get_versiondata()
> > was behaving weirdly when the parameter $need_content was false.  It appears that
> > php 4.3.10 on windows gets confused when an array element is created with an index
> > of '0'.

> Please try to update your zend optimizer first.
>   https://www.zend.com/store/products/zend-optimizer.php
> I had the same problem.

I have never downloaded or used the zend optimizer on my windows machine, this is a stock php 4.3.10 on windows.  Therefore I
suggest that the change is made as it will affect others that know nothing of the zend optimizer.  The patch is merely a change to
otherwise unused constants, not a change to logic.

Regards,
Charles

Re: [Phpwiki-talk] WikiDB.php caching fix part 2 of 2

[Joel U. <uck...@no...>]

Thus spake "Charles Corrigan":
> 
> A patch to lib/WikiDB.php follows.  This is part 2 of my previous set of fixe
> s to the caching logic. 
> 
> While debugging why caching was not working for me, I found that get_versiond
> ata() was behaving weirdly when the parameter
> $need_content was false.  It appears that php 4.3.10 on windows gets confused
>  when an array element is created with an index of '0'.

Wow, that's bizarre.

Is there a reason why the indices here are strings rather than just numeric
literals? If I had a Windows box with PHP, I'd test this myself, but does it
become confused when you create an array element with index 0 instead of '0'?

Re: [Phpwiki-talk] WikiDB.php caching fix part 2 of 2

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

Charles Corrigan schrieb:
> A patch to lib/WikiDB.php follows.  This is part 2 of my previous set of fixes to the caching logic. 
> 
> While debugging why caching was not working for me, I found that get_versiondata() was behaving weirdly when the parameter
> $need_content was false.  It appears that php 4.3.10 on windows gets confused when an array element is created with an index of '0'.

Please try to update your zend optimizer first.
   https://www.zend.com/store/products/zend-optimizer.php
I had the same problem.

> This patch changes the array index to use '2' and '1' instead of '1' and '0'. Note that this patch also contains the previous patch
> in the series - I do not know enough about CVS and Eclipse to get just the incremental changes from my previous patch.

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

[Phpwiki-talk] WikiDB.php caching fix part 1 of 2

[Charles C. <ch...@ru...>]

A patch to lib/WikiDB.php follows.  This is part 1 of my previous set of fixes to the caching logic. 

This patch ensures that the _pagedata_cache is only updated when the data is read from the database. Without this patch, there is
the possibility that _pagedata_cache will be updated (correctly) due to user action and then later the update will be overwritten
with stale data from the _versiondata_cache. Also fixes some indenting.

Index: WikiDB.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiDB.php,v
retrieving revision 1.124
diff -u -r1.124 WikiDB.php
--- WikiDB.php	29 Jan 2005 20:43:32 -0000	1.124
+++ WikiDB.php	31 Jan 2005 14:52:19 -0000
@@ -2045,8 +2045,9 @@
     }
     
     function get_versiondata($pagename, $version, $need_content = false) {
+		$lastestpagedata = false;
         //  FIXME: Seriously ugly hackage
-	if (USECACHE) {   //temporary - for debugging
+		if (USECACHE) {   //temporary - for debugging
             assert(is_string($pagename) && $pagename != '');
             // there is a bug here somewhere which results in an assertion failure at line 105
             // of ArchiveCleaner.php  It goes away if we use the next line.
@@ -2057,16 +2058,18 @@
                 !(is_array ($cache[$pagename])) || !(is_array ($cache[$pagename][$version]))) {
                 $cache[$pagename][$version][$nc] = 
                     $this->_backend->get_versiondata($pagename, $version, $need_content);
+				$lastestpagedata = true;
                 // If we have retrieved all data, we may as well set the cache for $need_content = false
                 if ($need_content){
                     $cache[$pagename][$version]['0'] =& $cache[$pagename][$version]['1'];
                 }
             }
             $vdata = $cache[$pagename][$version][$nc];
-	} else {
+		} else {
             $vdata = $this->_backend->get_versiondata($pagename, $version, $need_content);
-	}
-        if ($vdata && !empty($vdata['%pagedata'])) {
+			$lastestpagedata = true;
+		}
+        if ($lastestpagedata && $vdata && !empty($vdata['%pagedata'])) {
             $this->_pagedata_cache[$pagename] =& $vdata['%pagedata'];
         }
         return $vdata;

[Phpwiki-talk] WikiDB.php caching fix part 2 of 2

[Charles C. <ch...@ru...>]

A patch to lib/WikiDB.php follows.  This is part 2 of my previous set of fixes to the caching logic. 

While debugging why caching was not working for me, I found that get_versiondata() was behaving weirdly when the parameter
$need_content was false.  It appears that php 4.3.10 on windows gets confused when an array element is created with an index of '0'.

This patch changes the array index to use '2' and '1' instead of '1' and '0'. Note that this patch also contains the previous patch
in the series - I do not know enough about CVS and Eclipse to get just the incremental changes from my previous patch.

Regards,
Charles

Index: WikiDB.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiDB.php,v
retrieving revision 1.124
diff -u -r1.124 WikiDB.php
--- WikiDB.php	29 Jan 2005 20:43:32 -0000	1.124
+++ WikiDB.php	31 Jan 2005 14:56:33 -0000
@@ -2045,28 +2045,31 @@
     }
     
     function get_versiondata($pagename, $version, $need_content = false) {
+		$lastestpagedata = false;
         //  FIXME: Seriously ugly hackage
-	if (USECACHE) {   //temporary - for debugging
+		if (USECACHE) {   //temporary - for debugging
             assert(is_string($pagename) && $pagename != '');
             // there is a bug here somewhere which results in an assertion failure at line 105
             // of ArchiveCleaner.php  It goes away if we use the next line.
             //$need_content = true;
-            $nc = $need_content ? '1':'0';
+            $nc = $need_content ? '2':'1';
             $cache = &$this->_versiondata_cache;
             if (!isset($cache[$pagename][$version][$nc])||
                 !(is_array ($cache[$pagename])) || !(is_array ($cache[$pagename][$version]))) {
                 $cache[$pagename][$version][$nc] = 
                     $this->_backend->get_versiondata($pagename, $version, $need_content);
+				$lastestpagedata = true;
                 // If we have retrieved all data, we may as well set the cache for $need_content = false
                 if ($need_content){
-                    $cache[$pagename][$version]['0'] =& $cache[$pagename][$version]['1'];
+                    $cache[$pagename][$version]['1'] =& 
+ $cache[$pagename][$version]['2'];
                 }
             }
             $vdata = $cache[$pagename][$version][$nc];
-	} else {
+		} else {
             $vdata = $this->_backend->get_versiondata($pagename, $version, $need_content);
-	}
-        if ($vdata && !empty($vdata['%pagedata'])) {
+			$lastestpagedata = true;
+		}
+        if ($lastestpagedata && $vdata && !empty($vdata['%pagedata'])) 
+{
             $this->_pagedata_cache[$pagename] =& $vdata['%pagedata'];
         }
         return $vdata;
@@ -2077,8 +2080,8 @@
         
         $new = $this->_backend->set_versiondata($pagename, $version, $data);
         // Update the cache
+        $this->_versiondata_cache[$pagename][$version]['2'] = $data;
         $this->_versiondata_cache[$pagename][$version]['1'] = $data;
-        $this->_versiondata_cache[$pagename][$version]['0'] = $data;
         // Is this necessary?
         unset($this->_glv_cache[$pagename]);
     }
@@ -2086,19 +2089,19 @@
     function update_versiondata($pagename, $version, $data) {
         $new = $this->_backend->update_versiondata($pagename, $version, $data);
         // Update the cache
-        $this->_versiondata_cache[$pagename][$version]['1'] = $data;
+        $this->_versiondata_cache[$pagename][$version]['2'] = $data;
         // FIXME: hack
-        $this->_versiondata_cache[$pagename][$version]['0'] = $data;
+        $this->_versiondata_cache[$pagename][$version]['1'] = $data;
         // Is this necessary?
         unset($this->_glv_cache[$pagename]);
     }
 
     function delete_versiondata($pagename, $version) {
         $new = $this->_backend->delete_versiondata($pagename, $version);
+        if (isset($this->_versiondata_cache[$pagename][$version]['2']))
+            unset 
+ ($this->_versiondata_cache[$pagename][$version]['2']);
         if (isset($this->_versiondata_cache[$pagename][$version]['1']))
             unset ($this->_versiondata_cache[$pagename][$version]['1']);
-        if (isset($this->_versiondata_cache[$pagename][$version]['0']))
-            unset ($this->_versiondata_cache[$pagename][$version]['0']);
         if (isset($this->_glv_cache[$pagename]))
             unset ($this->_glv_cache[$pagename]);
     }

[Phpwiki-talk] WikiDB.php caching fix part 2 of 2

[Charles C. <ch...@ru...>]

A patch to lib/WikiDB.php follows.  This is part 2 of my previous set of fixes to the caching logic. 

While debugging why caching was not working for me, I found that get_versiondata() was behaving weirdly when the parameter
$need_content was false.  It appears that php 4.3.10 on windows gets confused when an array element is created with an index of '0'.
This patch changes the array index to use '2' and '1' instead of '1' and '0'. Note that this patch also contains the previous patch
in the series - I do not know enough about CVS and Eclipse to get just the incremental changes from my previous patch.

Regards,
Charles

Index: WikiDB.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiDB.php,v
retrieving revision 1.124
diff -u -r1.124 WikiDB.php
--- WikiDB.php	29 Jan 2005 20:43:32 -0000	1.124
+++ WikiDB.php	31 Jan 2005 14:56:33 -0000
@@ -2045,28 +2045,31 @@
     }
     
     function get_versiondata($pagename, $version, $need_content = false) {
+		$lastestpagedata = false;
         //  FIXME: Seriously ugly hackage
-	if (USECACHE) {   //temporary - for debugging
+		if (USECACHE) {   //temporary - for debugging
             assert(is_string($pagename) && $pagename != '');
             // there is a bug here somewhere which results in an assertion failure at line 105
             // of ArchiveCleaner.php  It goes away if we use the next line.
             //$need_content = true;
-            $nc = $need_content ? '1':'0';
+            $nc = $need_content ? '2':'1';
             $cache = &$this->_versiondata_cache;
             if (!isset($cache[$pagename][$version][$nc])||
                 !(is_array ($cache[$pagename])) || !(is_array ($cache[$pagename][$version]))) {
                 $cache[$pagename][$version][$nc] = 
                     $this->_backend->get_versiondata($pagename, $version, $need_content);
+				$lastestpagedata = true;
                 // If we have retrieved all data, we may as well set the cache for $need_content = false
                 if ($need_content){
-                    $cache[$pagename][$version]['0'] =& $cache[$pagename][$version]['1'];
+                    $cache[$pagename][$version]['1'] =& $cache[$pagename][$version]['2'];
                 }
             }
             $vdata = $cache[$pagename][$version][$nc];
-	} else {
+		} else {
             $vdata = $this->_backend->get_versiondata($pagename, $version, $need_content);
-	}
-        if ($vdata && !empty($vdata['%pagedata'])) {
+			$lastestpagedata = true;
+		}
+        if ($lastestpagedata && $vdata && !empty($vdata['%pagedata'])) {
             $this->_pagedata_cache[$pagename] =& $vdata['%pagedata'];
         }
         return $vdata;
@@ -2077,8 +2080,8 @@
         
         $new = $this->_backend->set_versiondata($pagename, $version, $data);
         // Update the cache
+        $this->_versiondata_cache[$pagename][$version]['2'] = $data;
         $this->_versiondata_cache[$pagename][$version]['1'] = $data;
-        $this->_versiondata_cache[$pagename][$version]['0'] = $data;
         // Is this necessary?
         unset($this->_glv_cache[$pagename]);
     }
@@ -2086,19 +2089,19 @@
     function update_versiondata($pagename, $version, $data) {
         $new = $this->_backend->update_versiondata($pagename, $version, $data);
         // Update the cache
-        $this->_versiondata_cache[$pagename][$version]['1'] = $data;
+        $this->_versiondata_cache[$pagename][$version]['2'] = $data;
         // FIXME: hack
-        $this->_versiondata_cache[$pagename][$version]['0'] = $data;
+        $this->_versiondata_cache[$pagename][$version]['1'] = $data;
         // Is this necessary?
         unset($this->_glv_cache[$pagename]);
     }
 
     function delete_versiondata($pagename, $version) {
         $new = $this->_backend->delete_versiondata($pagename, $version);
+        if (isset($this->_versiondata_cache[$pagename][$version]['2']))
+            unset ($this->_versiondata_cache[$pagename][$version]['2']);
         if (isset($this->_versiondata_cache[$pagename][$version]['1']))
             unset ($this->_versiondata_cache[$pagename][$version]['1']);
-        if (isset($this->_versiondata_cache[$pagename][$version]['0']))
-            unset ($this->_versiondata_cache[$pagename][$version]['0']);
         if (isset($this->_glv_cache[$pagename]))
             unset ($this->_glv_cache[$pagename]);
     }

Re: [Phpwiki-talk] external userauth can't stand logedin, CVS 31 jan 2005

[Stefan <son...@ba...>]

Reini Urban schrieb:

> Stefan schrieb:
>
>> thats the same as i have.
>>
>> Field      Type     Charset     Attributes     Null     Default     
>> Extra     Action
>> sess_id      varchar(32)                 No                  
>> Change     Drop     Primary     Index     Unique     Fulltext
>> sess_data      blob           BINARY     No                  
>> Change     Drop     Primary     Index     Unique     Fulltext
>> sess_date      int(10)           UNSIGNED     No      0            
>> Change     Drop     Primary     Index     Unique     Fulltext
>> sess_ip      varchar(15)                 No                  
>> Change     Drop     Primary     Index     Unique     Fulltext
>>
>> but the problem is the same :-(
>
>
> Problem persists? Ok, I'll investigate.
>
Thank you

>> Second question
>>
>> should named interwikilinks like 
>> [Bild200:Agardit-001.jpg|Bild:Agardit-001.jpg] now work in RichTable 
>> Plugin?
>
>
> Not yet. Soon.
> I just found more errors with TransformText within the RichTable plugin.
>

thats fine, not the error but that they will be fixed soon :-)



I found some other problems in the CVS Version. On some pages it shows
an old Version of the page
here are two links to show the difference. They both go to the same
mysql databse as backend

mostly wiki 1.3.10
http://www.mineralienatlas.de/lexikon/index.php/SandKasten

cvs Version
http://www.mineralienatlas.de/lex1/index.php/SandKasten



During the tests i had to restart my server several times because it
wouldnt answer anymore. can't find why it is so but it seems to be a
problem in conjunction with the new wiki. But its no memory problem and
no cpu. the server stops answering requests. I only can reproduce the
problem when testing with new cvs version :-(

Here the apache error log result

[client 80.140.170.186] PHP Fatal error:  session_start(): Failed to
initialize storage module: user (path: /tmp) in
/www/mineralienatlas/htdocs/lexikon/lib/Request.php on line 543
[client 80.140.170.186] PHP Fatal error:  session_start(): Failed to
initialize storage module: user (path: /tmp) in
/www/mineralienatlas/htdocs/lexikon/lib/Request.php on line 543
[client 80.140.170.186] PHP Fatal error:  session_start(): Failed to
initialize storage module: user (path: /tmp) in
/www/mineralienatlas/htdocs/lexikon/lib/Request.php on line 543

Here the php log

[31-Jan-2005 15:56:20] PHP Warning:  Unknown(): A session is active. You 
cannot change the session module's ini settings
  at this time. in Unknown on line 0
[31-Jan-2005 15:56:21] PHP Fatal error:  Call to undefined function: 
affected_rows() in /www/mineralienatlas/htdocs/lex
1/lib/DbSession.php on line 207


Regards Stefan

>> Mapping:
>> Bild http://www.mineralienatlas.de/upload/
>> Bild200 
>> http://www.mineralienatlas.de/thumb200.php?image=http://www.mineralienatlas.de/upload/ 
>>
>> I have tried it but it did'nt work again
>> [Bild200:Agardit-001.jpg] works
>

Re: [Phpwiki-talk] external userauth can't stand logedin, CVS 31 jan 2005

[Stefan <son...@ba...>]

Hello Reini,

thats the same as i have.

 Field      Type     Charset     Attributes     Null     Default     
Extra     Action
 sess_id      varchar(32)                 No                  Change     
Drop     Primary     Index     Unique     Fulltext
 sess_data      blob           BINARY     No                  Change     
Drop     Primary     Index     Unique     Fulltext
 sess_date      int(10)           UNSIGNED     No      0            
Change     Drop     Primary     Index     Unique     Fulltext
 sess_ip      varchar(15)                 No                  Change     
Drop     Primary     Index     Unique     Fulltext

but the problem is the same :-(

--------

Second question

should named interwikilinks like 
[Bild200:Agardit-001.jpg|Bild:Agardit-001.jpg] now work in RichTable Plugin?

Mapping:
Bild http://www.mineralienatlas.de/upload/
Bild200 http://www.mineralienatlas.de/thumb200.php?image=http://www.mineralienatlas.de/upload/

I have tried it but it did'nt work again

[Bild200:Agardit-001.jpg] works

Regards Stefan :-)

Reini Urban schrieb:

> Stefan schrieb:
>
>> Here the Result of the ?action=upgrade. But how do i get the 
>> "describe session" result?
>
>
> Now it's too late :)
>
> $ mysql -uwikiuser -p phpwiki
> mysql> describe session;
> +-----------+------------------+------+-----+---------+-------+
> | Field     | Type             | Null | Key | Default | Extra |
> +-----------+------------------+------+-----+---------+-------+
> | sess_id   | varchar(32)      |      | PRI |         |       |
> | sess_data | blob             |      |     |         |       |
> | sess_date | int(10) unsigned |      | MUL | 0       |       |
> | sess_ip   | varchar(15)      |      |     |         |       |
> +-----------+------------------+------+-----+---------+-------+
> 4 rows in set (0.03 sec)
>
> This is the good result.
>
>> There is another Problem i had in 1.3.10 also. When i http login to 
>> enter an directory the login is also shown in phpwiki as logedin but 
>> not authentificated. Now when i authentificate i was also logged out 
>> when i change to an other page ....
>> Only way to get a corect login is to stop start the browser and than 
>> to login to phpwiki again (without authetification against any 
>> directory to access it)
>
>
> Thanks. I know. I didn't check HttpAuth that lately.
> DanFr has a patch which I have to check.
>
>>  Upgrading this PhpWiki
>>      check for necessary database updates - SQL
>>        Backend type: mysql
>> check for table session ...OK
>> check for table user ...OK
>> check for table pref ...OK
>> check for table member ...OK
>> check for table accesslog ...OK
>> check for table rating ...OK
>> check for new session.sess_ip column ... OK
>> check for mysql session.sess_id sanity ...
>> check for mysql LOCK TABLE privilege ...OK
>> check for mysql page.id auto_increment flag ...OK
>> check for extra page.cached_html column ... OK
>
>
> I had in my session table:
>   sess_id => varchar(10),
>   sess_data => varchar(5)
> Which cannot work obviously.
>
>> Reini Urban schrieb:
>>
>>> Stefan schrieb:
>>>
>>>> after login against external database the user is shown as 
>>>> authentificated
>>>> after changing to an other page the user is logged out again
>>>
>>> A session problem which I was investigating yesterday.
>>>
>>> If it's mysql, could you please post your "DESCRIBE session" result?
>>>
>>> Then run ?action=upgrade which tries to fix two session columns, 
>>> which got shortened somehow. (how?!?)
>>

Re: [Phpwiki-talk] external userauth can't stand logedin, CVS 31 jan 2005

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

Stefan schrieb:
> Here the Result of the ?action=upgrade. But how do i get the "describe 
> session" result?

Now it's too late :)

$ mysql -uwikiuser -p phpwiki
mysql> describe session;
+-----------+------------------+------+-----+---------+-------+
| Field     | Type             | Null | Key | Default | Extra |
+-----------+------------------+------+-----+---------+-------+
| sess_id   | varchar(32)      |      | PRI |         |       |
| sess_data | blob             |      |     |         |       |
| sess_date | int(10) unsigned |      | MUL | 0       |       |
| sess_ip   | varchar(15)      |      |     |         |       |
+-----------+------------------+------+-----+---------+-------+
4 rows in set (0.03 sec)

This is the good result.

> There is another Problem i had in 1.3.10 also. When i http login to 
> enter an directory the login is also shown in phpwiki as logedin but not 
> authentificated. Now when i authentificate i was also logged out when i 
> change to an other page ....
> Only way to get a corect login is to stop start the browser and than to 
> login to phpwiki again (without authetification against any directory to 
> access it)

Thanks. I know. I didn't check HttpAuth that lately.
DanFr has a patch which I have to check.

>  Upgrading this PhpWiki
>      check for necessary database updates - SQL
>        Backend type: mysql
> check for table session ...OK
> check for table user ...OK
> check for table pref ...OK
> check for table member ...OK
> check for table accesslog ...OK
> check for table rating ...OK
> check for new session.sess_ip column ... OK
> check for mysql session.sess_id sanity ...
> check for mysql LOCK TABLE privilege ...OK
> check for mysql page.id auto_increment flag ...OK
> check for extra page.cached_html column ... OK

I had in my session table:
   sess_id => varchar(10),
   sess_data => varchar(5)
Which cannot work obviously.

> Reini Urban schrieb:
>> Stefan schrieb:
>>
>>> after login against external database the user is shown as 
>>> authentificated
>>> after changing to an other page the user is logged out again
>> A session problem which I was investigating yesterday.
>>
>> If it's mysql, could you please post your "DESCRIBE session" result?
>>
>> Then run ?action=upgrade which tries to fix two session columns, which 
>> got shortened somehow. (how?!?)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] external userauth can't stand logedin, CVS 31 jan 2005

[Stefan <son...@ba...>]

Hello Reini,

Here the Result of the ?action=upgrade. But how do i get the "describe 
session" result?

There is another Problem i had in 1.3.10 also. When i http login to 
enter an directory the login is also shown in phpwiki as logedin but not 
authentificated. Now when i authentificate i was also logged out when i 
change to an other page ....
Only way to get a corect login is to stop start the browser and than to 
login to phpwiki again (without authetification against any directory to 
access it)

Regards Stefan


  Upgrading this PhpWiki


      check for necessary database updates - SQL


        Backend type: mysql

check for table session ...OK
check for table user ...OK
check for table pref ...OK
check for table member ...OK
check for table accesslog ...OK
check for table rating ...OK
check for new session.sess_ip column ... OK
check for mysql session.sess_id sanity ...
check for mysql LOCK TABLE privilege ...OK
check for mysql page.id auto_increment flag ...OK
check for extra page.cached_html column ... OK


Reini Urban schrieb:

> Stefan schrieb:
>
>> after login against external database the user is shown as 
>> authentificated
>> after changing to an other page the user is logged out again
>
>
> A session problem which I was investigating yesterday.
>
> If it's mysql, could you please post your "DESCRIBE session" result?
>
> Then run ?action=upgrade which tries to fix two session columns, which 
> got shortened somehow. (how?!?)

Re: [Phpwiki-talk] external userauth can't stand logedin, CVS 31 jan 2005

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

Stefan schrieb:
> after login against external database the user is shown as authentificated
> after changing to an other page the user is logged out again

A session problem which I was investigating yesterday.

If it's mysql, could you please post your "DESCRIBE session" result?

Then run ?action=upgrade which tries to fix two session columns, which 
got shortened somehow. (how?!?)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

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

Stefan schrieb:
> when using latest CVS Version the following Error on end of page is shown
> 
> lib/PageType.php (In template 'body' < 'html'):144: Notice: Undefined 
> variable: intermap
> 
> maybe because i use it in german, what todo?

Thanks!
Good catch (but not important). Just fixed it.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: Another use for Google's 'rel='nofollow''?

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

Charles Corrigan schrieb:
> On Thu, January 27, 2005 17:31, Charles Corrigan said:
> 
>>I just looked at the access log for my site and noticed
>>that google was indexing it. And it was trying every
>>possible link from every page!
>>
>>Would it make sense to add a "rel='nofollow'" to links
>>such as "edit text" where it makes no sense for a robot
>>to follow?
> 
> 
> When I wrote that, it was already 7 days after Reini had started putting
> the nofollow attribute onto some of the links! My only excuse (hah!) is
> that CVS and then the lists had problems last week.

Does it work now?

> Anyway, I took a look and found that the changes did not work for me - I
> did not spend any time trying to work out why.  I just put a couple of
> changes in that worked in my testing.
> 
> /lib/Theme.php
> 
> - line 1184 - 4 lines in Button->Button()
>            // Google honors this
>            if (in_array(strtolower($text),
> array('edit','create','diff','pdf'))
>                and !$request->_user->isAuthenticated())
>                $this->setAttr('rel', 'nofollow');
> replaced with
>            // Google honors this
>            $this->setAttr('rel', 'nofollow');
> 
> - line 1210 - 4 lines in ImageButton->ImageButton()
>            // Google honors this
>            if (in_array(strtolower($text),
> array('edit','create','diff','pdf'))
>                and !$GLOBALS['request']->_user->isAuthenticated())
>                $this->setAttr('rel', 'nofollow');
> replaced with
>            // Google honors this
>            $this->setAttr('rel', 'nofollow');
> 
> 
> OK, some justification is required. In my opinion
> 1 - it does not matter whether the user is authenticated or not, only that
> if the user is google or another search engine, we do not want them to
> follow these links

Of course we could check for a search engine user_agent, but a simple 
$user->_level check is much cheaper.
rel=nofollow could also be used in some special accessibility browser 
(speechmode, ...).

> 2 - while there are some of the action buttons that it would be good for
> google to follow (RecentChanges, BackLinks), most of them I would prefer
> it did not.

So we should explicitly allow RecentChanges, BackLinks and deny all 
others? This will cost about the same.

> The downside of my changes is that there will be an unconditional
> additional 15 characters per action link in the HTML sent to the client.

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

[Phpwiki-talk] external userauth can't stand logedin, CVS 31 jan 2005

[Stefan <son...@ba...>]

after login against external database the user is shown as authentificated
after changing to an other page the user is logged out again

Regards Stefan

[Phpwiki-talk] Re: Another use for Google's 'rel='nofollow''?

[Charles C. <ch...@ru...>]

On Thu, January 27, 2005 17:31, Charles Corrigan said:
> I just looked at the access log for my site and noticed
> that google was indexing it. And it was trying every
> possible link from every page!
>
> Would it make sense to add a "rel='nofollow'" to links
> such as "edit text" where it makes no sense for a robot
> to follow?

When I wrote that, it was already 7 days after Reini had started putting
the nofollow attribute onto some of the links! My only excuse (hah!) is
that CVS and then the lists had problems last week.

Anyway, I took a look and found that the changes did not work for me - I
did not spend any time trying to work out why.  I just put a couple of
changes in that worked in my testing.

/lib/Theme.php

- line 1184 - 4 lines in Button->Button()
           // Google honors this
           if (in_array(strtolower($text),
array('edit','create','diff','pdf'))
               and !$request->_user->isAuthenticated())
               $this->setAttr('rel', 'nofollow');
replaced with
           // Google honors this
           $this->setAttr('rel', 'nofollow');

- line 1210 - 4 lines in ImageButton->ImageButton()
           // Google honors this
           if (in_array(strtolower($text),
array('edit','create','diff','pdf'))
               and !$GLOBALS['request']->_user->isAuthenticated())
               $this->setAttr('rel', 'nofollow');
replaced with
           // Google honors this
           $this->setAttr('rel', 'nofollow');


OK, some justification is required. In my opinion
1 - it does not matter whether the user is authenticated or not, only that
if the user is google or another search engine, we do not want them to
follow these links
2 - while there are some of the action buttons that it would be good for
google to follow (RecentChanges, BackLinks), most of them I would prefer
it did not.

The downside of my changes is that there will be an unconditional
additional 15 characters per action link in the HTML sent to the client.

regards,
Charles

Re: [Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

[Stefan <son...@ba...>]

Error

when using latest CVS Version the following Error on end of page is shown

lib/PageType.php (In template 'body' < 'html'):144: Notice: Undefined 
variable: intermap

maybe because i use it in german, what todo?

Regards Stefan