phpwiki-talk

[Phpwiki-talk] root taking over - help!

[Giovanni S. <gi...@be...>]

Hello,
today, without have changed anything user "root" is taking over my phpwiki!! :-(

I haven't changed basically anything in the config file ever, I only used to
sign in
(not authenticated) with my WikiUserName and it was lasting for the session.
Now,  at every page loaded next to sign in button says:
" You are signed but not authenticated as root"

Obviously I didn't create any phpwiki root user!! I did open up my directories,
bot lib, other executable and the data dir to 777 (I know... bad...).

I'm very nervous now, what's going on?! How is something/someone signing
in as root?!

Thanks for any advice (beside shut down everything!).

Gio

[Phpwiki-talk] Parsing problem with MySQL installation

[Jay D. <sun...@ve...>]

I installed phpwiki 1.2.5 using mysql. Created database successfully.
Created tables successfully. Everything seemed to work.

And my front page http://jaydixit.org/annex/ seems to load correctly.

But when I try to click any of the links or edit the page, I get this =
error:

Warning: Unexpected character in input: ' ' (ASCII=3D12) state=3D1 in
/usr/local/dh/cgi-system/php.cgi on line 2788

Parse error: parse error, unexpected T_STRING in
/usr/local/dh/cgi-system/php.cgi on line 2788

Any ideas?

Thanks.
Sunjay

Re: [Phpwiki-talk] Wikiblog plugin problem ..

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

Arnaud Fontaine schrieb:
> With today's CVS update, I got a problem with the WikiBlog plugin : it 
> doesn't display the posts anymore even if I only specify the 'show' mode.
> 
> So I investigated a bit and found that the _blogPrefix method uses 
> "Blogs" for blogs but blogs have alwzys been created with the "Blog" 
> prefix ... ouch ... that hurts ...
> 
> By the way, I took a look at the add method ... wich doesn't use the 
> _blogPrefix method to generate the page name ... That's a problem :)
> 
> The problem is the same for other plugins using ikiBlog like the comment 
> plugin and the WikiForum plugin.
> 
> So, first, go back to "Blog" and "Comment" in the _blogPrefix method, 
> then change the add method to make use of _blogPrefix to generate the 
> page name.

Ah, thanks for the reminder. I even prefer "Blog" and didn't want to 
change "Blogs" to "Blog" because I thought it might break old things.
Good to be remembered that it was right before that, and is wrong now.
Will fix it ASAP.

And please be patient with the new blogging stuff, I'm just committing. 
It will need a couple of some more days until it is finished.

WikiBlog has some annoying side-effects. mode=add makes only sense if 
the user is authenticated if it's his blog. Otherwise it's a comment.
mode=add should be checked automatically.
And some more arguments and features are missing.
   limit=<max. number of displayed blogs>
   limit per week or month
Use a full featured editbox for "add", not just the simple textarea.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Wikiblog plugin problem ..

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

Hi all,

With today's CVS update, I got a problem with the WikiBlog plugin : it 
doesn't display the posts anymore even if I only specify the 'show' 
mode.

So I investigated a bit and found that the _blogPrefix method uses 
"Blogs" for blogs but blogs have alwzys been created with the "Blog" 
prefix ... ouch ... that hurts ...

By the way, I took a look at the add method ... wich doesn't use the 
_blogPrefix method to generate the page name ... That's a problem :)

The problem is the same for other plugins using ikiBlog like the 
comment plugin and the WikiForum plugin.

So, first, go back to "Blog" and "Comment" in the _blogPrefix method, 
then change the add method to make use of _blogPrefix to generate the 
page name.

--
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

Re: [Phpwiki-talk] Re: Load and Overwrite

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

Micki Kaufman schrieb:
> So far so good with our database performance - no mysql errors lately on 
> the test instance of .11 and we could be getting close to upgrading our 
> production site to .11 when it's released!
> 
> However - I would really appreciate some insight into the load overwrite 
> bug. Unless I'm mistaken and missing something, upgrading to .11 will 
> eradicate our edit history without a working 'load and overwrite' 
> capability that preserves page history.
> 
> To test, just make a zip dump and try to load and overwrite into a new 
> wiki.

Sorry, I haven't fixed that yet.
I was busy with some new features, the new blog theme.
But it's getting very close now.
-- 
Reini

[Phpwiki-talk] Re: Load and Overwrite

[Micki K. <mic...@co...>]

So far so good with our database performance - no mysql errors lately 
on the test instance of .11 and we could be getting close to 
upgrading our production site to .11 when it's released!

However - I would really appreciate some insight into the load 
overwrite bug. Unless I'm mistaken and missing something, upgrading 
to .11 will eradicate our edit history without a working 'load and 
overwrite' capability that preserves page history.

To test, just make a zip dump and try to load and overwrite into a new wiki.

Thanks so much for any insight you can provide.
Micki



>
>Message: 3
>Date: Tue, 07 Dec 2004 20:28:06 +0100
>From: Reini Urban <ru...@x-...>
>To:  php...@li...
>Subject: Re: [Phpwiki-talk] Load and Overwrite
>
>Micki Kaufman schrieb:
>>  Hi folks - just pulled the latest build from cvs. Looks good!
>>
>>  There seems to be a lot of mysql flakiness that I'm tracking down, some
>>  perms irregularities, but by and large it's looking good.
>
>ADODB should be fine, but I have to update PearDB and dba to enable the
>new undoable remove feature.
>
>And the new purge-empty-pages button.
>I just purged >1000 unreferenced empty pages at the
>phpwiki.sf.net/demo/en mysql setup.
>These came from old link parsings steps and where never deleted.
>
>I added now new experimental code (in ADODB only) to clean up old stale
>links (mostly syntax problems) which clutter the page table.
>
>>  One issue off the bat that I encountered - the 'load with overwrite'
>>  option (used for bringing in zipdumps with page histories) seems broken,
>>  and all that can be loaded is version 1 (the oldest) for each page.
>
>Thanks.
>
>--
>Reini Urban
>http://xarch.tu-graz.ac.at/home/rurban/


-- 

Micki
mailto:mic...@co...

[Phpwiki-talk] Re: Kubrick Theme

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

Rui Carmo schrieb:
> Here it is, as promised. The CSS is still a bit of a mess, but I've 
> cleaned up the templates a bit (removing some of my stuff - plugin 
> invocations, JavaScript, etc.) and I think it will be easy to mix into 
> the PhpWiki source tree. You'll find a few comments and a couple of 
> examples for a blogroll, AdSense, etc.
> 
> I will also try to isolate SeeAlso (the table you see at the bottom of 
> my pages) and see if I can disentangle both the Atom feed and the 
> JavaScript-based search from the rest of the code (I hacked it inside 
> TitleSearch) so that they can be integrated in the current source code.
> 
> Please let me know when this is integrated, so that I can tell Michael 
> (the original designer).

Thanks a lot!
Yesterday I also started with the better blog integration based on the 
Kubrick theme. But I want to name the THEME "blog" and not "Kubrick", 
because it will be easier to decide for the admin then. Kubrick might be 
too less descriptive.
The CSS is Kubrick.css and themeinfo.php explains about that.
It also links to your and Michaels original sites.

Archives:
The new plugin BlogArchives is already in CVS. This displays the list of 
months with blog entries + number of entries, like this:

Archives
* December 2004 (2)
* November 2004 (1)

As box method (in the sidebar) and as normal plugin (within a page).
Linked is another blog list, showing the titles (summary) of the blog 
entries of this month.

Calendar:
I want to integrate Blogs with the Calendar and CalendarList.
I think enabling the Calendar on the top of the right sidebar is a good 
thing, though Michael didn't have it in his original Wordpress theme.
We have two Calendar's: the old simple one, and a new javascript based, 
which enables fast navigation across months without extra request.
Maybe the jscalendar css has to be simplified a bit.
Currently all other bloggers just use a simple calendar.

Blog Pagenames:
You just have "blog/day" as pagename.
We have "UserName/Blog/day/time" as pagenames. Hmm.
Our findBlogs method requires "Blog/" to be a subpage for fast searches.

Leaving out the time? Is this a good thing?
   I have no opionion. Just that we had the time for a long time now,
   but I don't know if it would be better to leave out the time.

How to format blog pagenames?
   Currently we display the verbatim pagename: "UserName/Blog/day/time".
   You always display the just summary. This is fine for blog-only
   wiki's.
   TitleSearch and the WikiLink formatter have to be extended to
   those find blog entries.
   Maybe format it as "pagename summary". This will keep the natural
   ordering and the information. But probably your solution is the best.
   I'll think about this as Theme extension.

Multi-User:
I also want to enable multi-user mode. Default is always ADMIN_USER, but 
why not allow blogs of other authorized users? HomePage just shows the 
ADMIN_USER blogs though.
You just have "blog/day" as default pagenames.
For AdminUser this could stay (leave out the username), and the 
multi-user extension could be "OtherUser/Blog/day/time".
Or maybe use "AdminUser/Blog/day/time" for consistency.

Photo:
The Photo section needs also some work. I just started with more 
PhotoAlbum work last week. This needs better javascript navigation and 
better UpLoad support. And maybe per-user upload directories for better 
protection and to avoid nameclashes.

Syndication:
The RecentChanges rss formatter has to be limited to a certain blog 
only. To cut down the noise ratio.
   <?plugin RecentChanges pages=ThisUser/Blog/* ?>
-- 
Reini Urban
http://phpwiki.org/

Kubrick Theme (Was: Re: [Phpwiki-talk] AdSense Tip)

[Rui C. <rui...@ac...>]

Well, actually it is. Otherwise, the Google bot will go in and fill the 
database with empty pages wherever I leave an unlinked WikiWord, and, 
in this particular case, _will_repeat_the_search_. If it's a 
FullTextSearch, it's a significant performance hit for me, since I'm 
not (yet) caching the results.

Note that I only exclude the bots from _action_ pages and older content 
versions, not from the rest of the site. And I haven't noticed any 
significant drop in AdSense revenue (it isn't that much to begin with). 
Search hits are something like 0.005% of my total traffic.

Plus, referrer checking will do nothing for this - as far as I can see, 
the bot does not send a referrer at all in the search case. I have very 
significant pieces of code devoted to doing referrer checking and spam 
filtering, so I would have noticed.

Moving on, I have finally debugged the edit template for the Kubrick 
theme. I still have a bug someplace in the diff routines, but have 
cleaned up the templates a bit and will, like I promised, be sending 
you a zip with them - it will, however, require further cleanup, since 
my navigation bar is different from the standard one, etc.

I think you'll find it useful, and I look forward to seeing it in new 
versions of PhpWiki.

I will also try to clean up some of my custom plugins and send them 
later - I've just returned from vacation, and work is already impinging 
on me.

Regards,

R.
http://the.taoofmac.com

On Dec 8, 2004, at 2:17 PM, Reini Urban wrote:

> Rui Carmo schrieb:
>> Besides yesterday's fix, I spent quite some time figuring out why I 
>> still had another "hit" on the search pages. At first I thought it 
>> was something inside the search code, but when I started logging IP 
>> addresses it became obvious.
>> It turned out that AdSense will trigger an _immediate_ hit from the 
>> google bot if I display ads on my *Search pages, which prompted me to 
>> include this little snippet right at the start of index.php (to waste 
>> as little resources as possible):
>> define( "DUMB_BOTS", 
>> '/(JPluck|Mediapartners|ia_archiver|googlebot|msnbot|Crawl)/i' );
>> if( preg_match( DUMB_BOTS, $_SERVER['HTTP_USER_AGENT'] ) ) {
>>   if( preg_match( '/\?(s|action|version)=/', $_SERVER['REQUEST_URI'] 
>> ) ) {
>>     header( "HTTP/1.1 404 File Not Found" );
>>     echo( "<H1>404 File Not Found</H1>" );
>>     exit;
>>   }
>> }
>
> That's not a good idea!
> Google's Ad Sense checks where the ads really appear on the page, and 
> calculates the rank (= money!) from this info.
> If you reject the checker you will get no profit from AdSense at all.
>
> rejected the main googlebot is also not a good idea.
> The googlebot is a good thing.
> You just have to prepare for being "slashdotted" to death once in a 
> while. Some referrer check or referrer throttling.
> -- 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] Whole bunch of security related issues

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

While I cannot track it down, I get the feeling that somehow the problem is
that the metadata for the oldest version of the page is always used, not the
metadata for latest version.

Regards,
Charles

-----Original Message-----
From: Charles Corrigan [mailto:ch...@ru...] 
Sent: 13 December 2004 23:35
To: php...@li...
Subject: [Phpwiki-talk] Whole bunch of security related issues

I have not been able to work out what is going on here, though I have been
looking for a while...
Please let me know if any further information is required.

Regards,
Charles

[Phpwiki-talk] Whole bunch of security related issues

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

I have not been able to work out what is going on here, though I have been
looking for a while...
Please let me know if any further information is required.

Regards,
Charles

All test cases assume that the user is logged in as the administrator

Test case 1
===========
1 - Go to PhpWikiAdministration/Chown
2 - Select RichTablePlugin (the value in the owner column is ReiniUrban).
3 - Change the owner to another user and confirm.
4 - Go to RichTablePlugin - the new owner is shown correctly.
5 - Go to PhpWikiAdministration/Chown - the owner is still shown as
ReiniUrban

Test Case 2
===========
1 - Open a page
2 - Click on the Setacl button
3 - Select a group (row) to be deleted
4 - Click on SetAcl - the confirmation page is displayed but the group to be
deleted is unselected
5 - Reselect the group (row) to be deleted and click on Yes
6 - Click on the Setacl button - the ACLs have not been changed

Test Case 3
===========
1 - Export a page to a zip file
2 - Extract a page from the zip file into a text file
3 - Use a text editor to set the acls on the page so it can only be edited
by an administrator (will also have to update version and maybe lastmodified
and/or created)
4 - Load the edited text file back into the wiki
5 - Open the page
6 - View the acls using the Setacl button
7 - log out of the wiki
8 - log back in as a user that should be unable to edit the page
9 - attempt to edit the page - it is allowed

Platform
========
Linux: 2.4.21
Apache: 1.3.33
MySQL: 4.0.22
PHP: 4.3.9
phpwiki: CVS 1.3.11pre, extracted shortly after update to upgrade.php on
2004/12/10 at 22:33:39

Configuration
=============
INCLUDE_PATH = "/home/runega2/phpwiki"
ENABLE_PAGEPERM = true
ENABLE_DOUBLECLICKEDIT = true
WIKI_NAME = WhiteWall
ENABLE_REVERSE_DNS = true
ADMIN_USER = WhiteWallAdmin
ADMIN_PASSWD = "xxxxxxxx"
ENCRYPTED_PASSWD = true
ZIPDUMP_AUTH = false
ENABLE_RAW_HTML = false
ENABLE_RAW_HTML_LOCKEDONLY = false
ENABLE_RAW_HTML_SAFE = false
STRICT_MAILABLE_PAGEDUMPS = true
DEFAULT_DUMP_DIR = /home/runega2/whitewall/wikidump
HTML_DUMP_DIR = /home/runega2/whitewall/wikidumphtml
HTML_DUMP_SUFFIX = .html
MAX_UPLOAD_SIZE = 1050000
MINOR_EDIT_TIMEOUT = 604800
ACCESS_LOG = /home/runega2/whitewall/accesslog/wiki_access_log
CACHE_CONTROL = LOOSE
CACHE_CONTROL_MAX_AGE = 600
COOKIE_EXPIRATION_DAYS = 365
DATABASE_TYPE = SQL
DATABASE_PREFIX = wwwiki_
DATABASE_DSN = "mysql://runega2_phpwiki:xxxxxx@localhost/runega2_db"
DATABASE_SESSION_TABLE = session
DATABASE_DIRECTORY = /home/runega2/whitewall/files
DATABASE_DBA_HANDLER = gdbm
DATABASE_TIMEOUT = 5
SESSION_SAVE_PATH = /home/runega2/whitewall/session
MAJOR_MAX_AGE = 32
MAJOR_KEEP = 8
MINOR_MAX_AGE = 7
MINOR_KEEP = 4
AUTHOR_MAX_AGE = 365
AUTHOR_KEEP = 8
AUTHOR_MIN_AGE = 7
AUTHOR_MAX_KEEP = 20
ALLOW_ANON_USER = true
ALLOW_ANON_EDIT = false
ALLOW_BOGO_LOGIN = false
ALLOW_USER_PASSWORDS = true
USER_AUTH_ORDER = "Db"
PASSWORD_LENGTH_MINIMUM = 6
USER_AUTH_POLICY = first-only
GROUP_METHOD = WIKIPAGE
DBAUTH_AUTH_USER_EXISTS = "SELECT userid FROM wwwiki_user WHERE
userid='$userid'"
DBAUTH_AUTH_CHECK = "SELECT IF(passwd=PASSWORD('$password'),1,0) AS ok FROM
wwwiki_user WHERE userid='$userid'"
DBAUTH_AUTH_CRYPT_METHOD = plain
DBAUTH_AUTH_UPDATE = "UPDATE wwwiki_user SET passwd=PASSWORD('$password')
WHERE userid='$userid'"
DBAUTH_AUTH_CREATE = "INSERT INTO wwwiki_user SET
passwd=PASSWORD('$password'),userid='$userid'"
DBAUTH_PREF_SELECT = "SELECT prefs FROM wwwiki_pref WHERE userid='$userid'"
DBAUTH_PREF_UPDATE = "REPLACE INTO wwwiki_pref SET
prefs='$pref_blob',userid='$userid'"
DBAUTH_IS_MEMBER = "SELECT userid FROM wwwiki_member WHERE userid='$userid'
AND groupname='$groupname'"
DBAUTH_GROUP_MEMBERS = "SELECT DISTINCT userid FROM wwwiki_member WHERE
groupname='$groupname'"
DBAUTH_USER_GROUPS = "SELECT groupname FROM wwwiki_member WHERE
userid='$userid'"
EDITING_POLICY = EditingPolicy
THEME = default
CHARSET = iso-8859-1
DEFAULT_LANGUAGE = en
WIKI_PGSRC = pgsrc
DEFAULT_WIKI_PGSRC = pgsrc
DEFAULT_WIKI_PAGES = "ReleaseNotes:SteveWainstead:TestPage"
ALLOWED_PROTOCOLS = "http|https|mailto|ftp|news|nntp|ssh|gopher"
INLINE_IMAGES = "png|jpg|gif"
WIKI_NAME_REGEXP =
"(?<![[:alnum:]])(?:[[:upper:]][[:lower:]]+){2,}(?![[:alnum:]])"
SUBPAGE_SEPARATOR = /
INTERWIKI_MAP_FILE = lib/interwiki.map
WARN_NONPUBLIC_INTERWIKIMAP = false
KEYWORDS = "Category:Topic"
COPYRIGHTPAGE_TITLE = "GNU General Public License"
COPYRIGHTPAGE_URL = "http://www.gnu.org/copyleft/gpl.html#SEC1"
AUTHORPAGE_TITLE = The PhpWiki Programming Team
AUTHORPAGE_URL = http://phpwiki.org/ThePhpWikiProgrammingTeam
TOC_FULL_SYNTAX = true
PHPWIKI_DIR = /home/runega2/phpwiki
USE_PATH_INFO = true
TEMP_DIR = /home/runega2/whitewall/tmp
PLUGIN_CACHED_DATABASE = file
PLUGIN_CACHED_CACHE_DIR = /home/runega2/whitewall/cache
PLUGIN_CACHED_FILENAME_PREFIX = phpwiki
PLUGIN_CACHED_HIGHWATER = 4194304
PLUGIN_CACHED_LOWWATER  = 3145728
PLUGIN_CACHED_MAXLIFETIME = 2592000
PLUGIN_CACHED_MAXARGLEN = 1000
PLUGIN_CACHED_USECACHE = true
PLUGIN_CACHED_FORCE_SYNCMAP = true
PLUGIN_CACHED_IMGTYPES = "png|gif|gd|gd2|jpeg|wbmp|xbm|xpm"

Re: [Phpwiki-talk] (no subject)

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

Lea Viljanen schrieb:
> On Friday 10 December 2004 21:35, Reini Urban wrote:
>>Seeing other error messages on your phpwiki, it looks like that this
>>is a flatfile database, and for this old version there's a known bug,
>>which was fixed about half a year ago.
> 
> If you are really talking about flat file DB's and this:
> 
> lib/WikiDB.php:974: Fatal[0]: 
> <br />/home/viljanen/public_html/tubewiki/lib/WikiDB.php:974: : 
> Assertion failed <br />
> 
> This definitely has not been fixed. I'm running 1.3.10 and
> if a page has been edited >10 times or so, I'm getting this 
> error every time I edit it. The edit goes through just fine, but the
> error is still very annoying.

You are right. This was fixed after the 1.3.10 release.

lib/WikiDB/backend/file.php:
// Revision 1.10  2004/06/03 22:08:17  rurban
// fix bug #963268 (check existing previous version)

Updating this file should be enough.


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

Re: [Phpwiki-talk] (no subject)

[Lea V. <vil...@cs...>]

On Friday 10 December 2004 21:35, Reini Urban wrote:

> Seeing other error messages on your phpwiki, it looks like that this
> is a flatfile database, and for this old version there's a known bug,
> which was fixed about half a year ago.

If you are really talking about flat file DB's and this:

lib/WikiDB.php:974: Fatal[0]: 
<br />/home/viljanen/public_html/tubewiki/lib/WikiDB.php:974: : 
Assertion failed <br />

This definitely has not been fixed. I'm running 1.3.10 and
if a page has been edited >10 times or so, I'm getting this 
error every time I edit it. The edit goes through just fine, but the
error is still very annoying.

-- 
Lea 'LadyBug' Viljanen   Ignorance killed the cat,
Researcher, TuBE-project  curiosity was framed.
Univ. of Helsinki, Dept. of CS

[Phpwiki-talk] Errors in latest CVS

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

Since upgrading to latest CVS, I get errors such as below for any action
from PhpWikiAdministration.  Any suggestions for where to track it down?

Regards,
Charles

Fatal Error:

lib/WikiDB/backend/PearDB.php (In template 'body' < 'html'):1002: Error:
wikidb_backend_peardb_mysql: fatal database error

    * DB Error: syntax error
    * ( WHERE [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 'WHERE' at line 1])
    *

lib/WikiDB/backend/PearDB.php (In template 'body' < 'html'):89: Notice:
Undefined property: _lock_count

Fatal PhpWiki Error

lib/WikiDB/backend/PearDB.php (In template 'body' < 'html'):1002: Error:
wikidb_backend_peardb_mysql: fatal database error

    * DB Error: syntax error
    * ( WHERE [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 'WHERE' at line 1])

[Phpwiki-talk] RE: [phpwiki-checkins] CVS: phpwiki/lib upgrade.php,1.32,1.33

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

Reini,

In file upgrade.php, function CheckDatabaseUpdate(&$request),
somewhere before line 355 of the file, something like 
$dbh = &$request->_dbi;
Is needed to make it work

Regards,
Charles

-----Original Message-----
From: Reini Urban [mailto:ru...@us...] 
Sent: 11 December 2004 06:34
To: php...@li...
Subject: [phpwiki-checkins] CVS: phpwiki/lib upgrade.php,1.32,1.33

Update of /cvsroot/phpwiki/phpwiki/lib
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28859

Modified Files:
	upgrade.php 
Log Message:
add WikiAdminUtils method for convert-cached-html
missed some vars.


Index: upgrade.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/upgrade.php,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -2 -b -p -d -r1.32 -r1.33
--- upgrade.php	10 Dec 2004 22:15:00 -0000	1.32
+++ upgrade.php	10 Dec 2004 22:33:39 -0000	1.33
@@ -453,5 +453,5 @@ function CheckDatabaseUpdate(&$request) 
 
 function _upgrade_db_init (&$dbh) {
-    global $DBParams, $DBAuthParams;
+    global $request, $DBParams, $DBAuthParams;
     if (!in_array($DBParams['dbtype'], array('SQL','ADODB'))) return;
     if (defined('DBADMIN_USER') and DBADMIN_USER) {
@@ -491,4 +491,5 @@ function _upgrade_cached_html (&$dbh) {
         if (!strstr(strtolower(join(':', $fields)), "cached_html")) {
             echo "<b>",_("ADDING"),"</b>"," ... ";
+            $backend_type = $dbh->_backend->backendType();
             if (substr($backend_type,0,5) == 'mysql')
                 $dbh->genericSqlQuery("ALTER TABLE $page_tbl ADD
cached_html MEDIUMBLOB");
@@ -514,4 +515,6 @@ function _convert_cached_html (&$dbh) {
     $pages = $dbh->getAllPages();
     $cache =& $dbh->_cache;
+    $count = 0;
+    extract($dbh->_backend->_table_names);
     while ($page = $pages->next()) {
         $pagename = $page->getName();
@@ -524,6 +527,8 @@ function _convert_cached_html (&$dbh) {
             $dbh->genericSqlQuery("UPDATE $page_tbl SET cached_html=? WHERE
pagename=?",
                                   array($cached_html, $pagename));
+            $count++;
         }
     }
+    return $count;
 }
 
@@ -631,4 +636,8 @@ function DoUpgrade($request) {
 /**
  $Log$
+ Revision 1.33  2004/12/10 22:33:39  rurban
+ add WikiAdminUtils method for convert-cached-html
+ missed some vars.
+
  Revision 1.32  2004/12/10 22:15:00  rurban
  fix $page->get('_cached_html)

Re: [Phpwiki-talk] (no subject)

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

Christiaan Hofman schrieb:
> On Dec 10, 2004, at 0:23, Reini Urban wrote:
> The offending word is WishList (I had to split it to prevent it from 
> removing the rest of the page, including buttons). Also the page
> http://bibdesk.sourceforge.net/wiki/index.php/WishList
> is just an error message now.
> 
> These are, needless to say, things that should _never_ happen. Also, the 
> preview does not always show the problems. So when yopu save, you can 
> easily loose the page.

Seeing other error messages on your phpwiki, it looks like that this is 
a flatfile database, and for this old version there's a known bug, which 
was fixed about half a year ago.

After the ArchiveCleaner removed old revisions (wich happens 
automatically) the versions get corrupted and these error occur.
So I would recommend to upgrade to the latest release version to fix 
this flatfile bug.

BTW: This has nothing to do with the content on any page. Just how old 
the page is and how many revisions it has. If then there are holes in 
the version history it will fail.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] (no subject)

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

Christiaan Hofman schrieb:
> On Dec 10, 2004, at 0:23, Reini Urban wrote:
>> Christiaan Hofman schrieb:
>>> Some words somehow (as FormatSupport) are not accepted by Wiki and 
>>> generate errors, breaking the whole thing. The worst thing about it 
>>> is that it cannot be corrected (unless maybe by an administrator)  as 
>>> the Edit and other buttons are also not there. There definitely 
>>> should be some error checking to prevent this from happening.
>>> Christiaan
>>
>>
>> Christiaan, I don't understand your request.
>>
>> Which words exactly generate errors (text snippet) and which errors? 
>> (error snippets)
>> At which url? (which wiki, which version)
>> Is this really phpwiki? I doubt that.
>>
>> The Edit button is always there, you just might have to sign in on edit.
>>
>> Please send us the exact steps to reproduce (and understand) so that 
>> we that can fix it.
> 
> OK, and one on an exisitng page:
> http://bibdesk.sourceforge.net/wiki/
> 
> The offending word is WishList (I had to split it to prevent it from 
> removing the rest of the page, including buttons). Also the page
> http://bibdesk.sourceforge.net/wiki/index.php/WishList
> is just an error message now.
> 
> These are, needless to say, things that should _never_ happen. Also, the 
> preview does not always show the problems. So when yopu save, you can 
> easily loose the page.

for the records: phpwiki-1.3.7
lib/WikiDB.php:729: Fatal[0]: <br 
/>/var/local/home/groups/b/bi/bibdesk/htdocs/wiki/lib/WikiDB.php:729: : 
Assertion failed <br />

getCurrentRevision()
$version = $cache->get_latest_version($pagename);
$revision = $this->getRevision($version);
=> assert($revision);

So this is a database corruption.

I would recommend to dump all pages, delete (or rename) the database, 
and then import it again.

Or find the offending version in the recent table and fix that in your 
database.
Explanation:
$version is obviously a wrong latest non-existing version integer.
Find the pageid for this page, and fix the latestmajor in recent to the 
latest existing version of this page.id.

For the future: Without any explanation what and how this corruption 
happened we will not be able to fix it.

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

Re: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

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

Charles Corrigan schrieb:
> On 02 December 2004 10:38, Reini Urban wrote:
>>You have been warned. The pagedata and versiondata cache
>>revamp is not finished, it's dirty, and I want to clean
>>it up without using too much memory.
> 
> How close to complete/reasonably stable is this rewrite?  I have been
> working on other things (real life and migrating an existing Wiki to a new
> site, including a large content cleanup).  I am now close to being able to
> look at code (or at least developing test cases) again.

db-side it is stable, just for the presentation I'm not sure.

We have now the unoptimized version in CVS, which ignores the fact that 
on an early stage (keyword extraction does a partial page iteration) 
some later needed pagedata can be stored in the pagedata cache.
When I enable that again it will save us about 10-20 sql queries.

Personally I haven't seen any problem so far with the current cache 
code. Other than your posted cornercases, which were very helpful.

I'm now adding some other bits and pieces to the WikiDB and work on the 
cache-optimization after that is finished.
I just refactored _cached_html yesterday, which saves as much more 
memory on SQL.
I want to add some better migration hints. Currenty it SQL-fails until 
you run ?action=upgrade.

Then I want to debug pagedata and versiondata cache again and optimize 
it, both for memory and run-time efficiency. About two days.

But some postgresql-cygwin and perl-libwin32 problems in other projects 
are also pending, so it could be more than two days.
-- 
Reini Urban
http://phpwiki.org/

RE: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

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

On 02 December 2004 10:38, Reini Urban wrote:
> You have been warned. The pagedata and versiondata cache
> revamp is not finished, it's dirty, and I want to clean
> it up without using too much memory.

How close to complete/reasonably stable is this rewrite?  I have been
working on other things (real life and migrating an existing Wiki to a new
site, including a large content cleanup).  I am now close to being able to
look at code (or at least developing test cases) again.

Regards,
Charles

Re: [Phpwiki-talk] (no subject)

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

Christiaan Hofman schrieb:
> Some words somehow (as FormatSupport) are not accepted by Wiki and 
> generate errors, breaking the whole thing. The worst thing about it is 
> that it cannot be corrected (unless maybe by an administrator)  as the 
> Edit and other buttons are also not there. There definitely should be 
> some error checking to prevent this from happening.
> 
> Christiaan

Christiaan, I don't understand your request.

Which words exactly generate errors (text snippet) and which errors? 
(error snippets)
At which url? (which wiki, which version)
Is this really phpwiki? I doubt that.

The Edit button is always there, you just might have to sign in on edit.

Please send us the exact steps to reproduce (and understand) so that we 
that can fix it.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] (no subject)

[Christiaan H. <chr...@we...>]

Some words somehow (as FormatSupport) are not accepted by Wiki and 
generate errors, breaking the whole thing. The worst thing about it is 
that it cannot be corrected (unless maybe by an administrator)  as the 
Edit and other buttons are also not there. There definitely should be 
some error checking to prevent this from happening.

Christiaan

Re: [Phpwiki-talk] Odd Behavior

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

Jim Beard schrieb:
> It is a hosted on our intra-net.  It's a private wiki that our 
> developers and other staff members use.
> The php install was all from rpm on RedHat.  It's not php5.  Have you 
> heard of any work arounds for this problem under php5?

For php5 and current CVS HEAD a fix is pending.
It worked on 1.3.10 though.

Data restauration:
=> PhpWikiAdministration => Backup & Restore
will dump to mimified plain text files.
without the header you should be able to import it into any wiki,
but we (the InterWikiExchangeFormat group) haven't found a common 
InterWikiExchangeFormat solution yet.


> On Dec 8, 2004, at 10:17 AM, Reini Urban wrote:
>> Jim Beard schrieb:
>>
>>> We have been experiencing some odd behavior that I am trying to 
>>> address.  We have version 1.3.10 running currently, and php version 
>>> 4.3.9.  We have a set of wiki pages that have been around for quite a 
>>> while.  They have run in the past on 1.3.7 and possibly 1.2.5.  
>>> Currently, when the pages are edited, the results come out mangled.  
>>> Often times the main content of the page will be repeated 2 to 4 
>>> times and the content is all mangled together.  For example, A large 
>>> table suddenly has 4 times as many rows as before and several sets of 
>>> rows repeat in the page.  This is preventing us from editing any of 
>>> our pages and thus not allowing us to really use the wiki.  Has 
>>> anyone seen this before or does anyone have any advice?  I hate to 
>>> lose all our wiki data and have to switch to a different piece of 
>>> software in the future....
>>
>> I heard of such behaviour only with php5.
>> Where is the url, so that I can have a check?
>>
>>> http://openefm.sourceforge.net


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

Re: [Phpwiki-talk] Odd Behavior

[Jim B. <be...@co...>]

I just observed this issue again using a virgin wiki page set.  This is 
hosted on a RedHat 9.0 system with php 4.3.9 and phpwiki 1.3.10.  I 
thought our page db might have become corrupted, thus causing the 
problem.  However now I see that this is occurring without regard to 
the page set.  No clue what might be causing this...


On Dec 8, 2004, at 12:47 PM, Jim Beard wrote:

> The wiki is hosted on our Intra-net and contains proprietary 
> information that our developers and and other employees use.  At first 
> this issue was noticed mainly on our main page which uses an old style 
> table, and is quite large.  However this issue happens on all of our 
> pages.  Therefore I do not believe it is any longer an issue with the 
> table.  If this issue cannot be resolved we will need to use a 
> different wiki.  My main concern at this point is being able to 
> transfer the content.  Is anyone aware of another wiki which will 
> import our pages?  A solution would also be ideal...
>
> Jim
>
> On Dec 8, 2004, at 10:17 AM, Reini Urban wrote:
>
>> Jim Beard schrieb:
>>> We have been experiencing some odd behavior that I am trying to 
>>> address.  We have version 1.3.10 running currently, and php version 
>>> 4.3.9.  We have a set of wiki pages that have been around for quite 
>>> a while.  They have run in the past on 1.3.7 and possibly 1.2.5.  
>>> Currently, when the pages are edited, the results come out mangled.  
>>> Often times the main content of the page will be repeated 2 to 4 
>>> times and the content is all mangled together.  For example, A large 
>>> table suddenly has 4 times as many rows as before and several sets 
>>> of rows repeat in the page.  This is preventing us from editing any 
>>> of our pages and thus not allowing us to really use the wiki.  Has 
>>> anyone seen this before or does anyone have any advice?  I hate to 
>>> lose all our wiki data and have to switch to a different piece of 
>>> software in the future....
>>
>> I heard of such behaviour only with php5.
>> Where is the url, so that I can have a check?
>>
>>> http://openefm.sourceforge.net
>> -- 
>> Reini Urban
>> http://xarch.tu-graz.ac.at/home/rurban/
>>
>>
> Jim Beard
> counterclaim.com, Inc
> http://www.counterclaim.com
> http://openefm.sourceforge.net
> (800) 264-8145
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>
Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

Re: [Phpwiki-talk] Odd Behavior

[Jim B. <be...@co...>]

The wiki is hosted on our Intra-net and contains proprietary 
information that our developers and and other employees use.  At first 
this issue was noticed mainly on our main page which uses an old style 
table, and is quite large.  However this issue happens on all of our 
pages.  Therefore I do not believe it is any longer an issue with the 
table.  If this issue cannot be resolved we will need to use a 
different wiki.  My main concern at this point is being able to 
transfer the content.  Is anyone aware of another wiki which will 
import our pages?  A solution would also be ideal...

Jim

On Dec 8, 2004, at 10:17 AM, Reini Urban wrote:

> Jim Beard schrieb:
>> We have been experiencing some odd behavior that I am trying to 
>> address.  We have version 1.3.10 running currently, and php version 
>> 4.3.9.  We have a set of wiki pages that have been around for quite a 
>> while.  They have run in the past on 1.3.7 and possibly 1.2.5.  
>> Currently, when the pages are edited, the results come out mangled.  
>> Often times the main content of the page will be repeated 2 to 4 
>> times and the content is all mangled together.  For example, A large 
>> table suddenly has 4 times as many rows as before and several sets of 
>> rows repeat in the page.  This is preventing us from editing any of 
>> our pages and thus not allowing us to really use the wiki.  Has 
>> anyone seen this before or does anyone have any advice?  I hate to 
>> lose all our wiki data and have to switch to a different piece of 
>> software in the future....
>
> I heard of such behaviour only with php5.
> Where is the url, so that I can have a check?
>
>> http://openefm.sourceforge.net
> -- 
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
>
Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145

Re: [Phpwiki-talk] Odd Behavior

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

Jim Beard schrieb:
> We have been experiencing some odd behavior that I am trying to 
> address.  We have version 1.3.10 running currently, and php version 
> 4.3.9.  We have a set of wiki pages that have been around for quite a 
> while.  They have run in the past on 1.3.7 and possibly 1.2.5.  
> Currently, when the pages are edited, the results come out mangled.  
> Often times the main content of the page will be repeated 2 to 4 times 
> and the content is all mangled together.  For example, A large table 
> suddenly has 4 times as many rows as before and several sets of rows 
> repeat in the page.  This is preventing us from editing any of our pages 
> and thus not allowing us to really use the wiki.  Has anyone seen this 
> before or does anyone have any advice?  I hate to lose all our wiki data 
> and have to switch to a different piece of software in the future....

I heard of such behaviour only with php5.
Where is the url, so that I can have a check?

> http://openefm.sourceforge.net
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Odd Behavior

[Jim B. <be...@co...>]

We have been experiencing some odd behavior that I am trying to 
address.  We have version 1.3.10 running currently, and php version 
4.3.9.  We have a set of wiki pages that have been around for quite a 
while.  They have run in the past on 1.3.7 and possibly 1.2.5.  
Currently, when the pages are edited, the results come out mangled.  
Often times the main content of the page will be repeated 2 to 4 times 
and the content is all mangled together.  For example, A large table 
suddenly has 4 times as many rows as before and several sets of rows 
repeat in the page.  This is preventing us from editing any of our 
pages and thus not allowing us to really use the wiki.  Has anyone seen 
this before or does anyone have any advice?  I hate to lose all our 
wiki data and have to switch to a different piece of software in the 
future....

Jim Beard
counterclaim.com, Inc
http://www.counterclaim.com
http://openefm.sourceforge.net
(800) 264-8145