phpwiki-talk

[Phpwiki-talk] Tables and plugins...

[John C. <joh...@ua...>]

Hello,

  Our front page has a calendar plugin at the very top.  One thing that I
would really like to do to fill in some of the whitespace at the top of this
page is to put a calendarlist beside the calendar.

  With the latest versions, I can now do this with the following:

<?plugin Calendar ?> |
  <?plugin CalendarList ?>

  One problem with this is that the first column of a table has every cell
bolded.  I would like to have the calendar render normally without each sub
cell bolded :-)

  I tried the OldStyleTable plugin, but it doesn't allow sub plugins, like
so:

<?plugin OldStyleTable caption="Calender & List" border||=2
|<?plugin Calendar ?> | <?plugin CalendarList ?>
?>

Any suggestions?

Thanks,

John Cole

  

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

RE: [Phpwiki-talk] ldap progress

[John C. <joh...@ua...>]

Reini,
  Wow, lots of things started working again :-)

  Here are some small problems that may or may not need to be fixed before
the next release.

 1) when loading from pgsrc (over an existing, older, database) with a
conflict on a page, pressing 'restore anyway' restores the page, but with
this warning:

lib\WikiDB\backend\PearDB.php:824: Fatal[256]: wikidb_backend_mysql: fatal
database error

    * DB Error: already exists
    * (INSERT INTO session (sess_id, sess_data, sess_date, sess_ip) VALUES
('e8862bbd480913d1e3d0b7b2e3be8c63',
'wiki_user|O:10:\"_adminuser\":10:{s:7:\"_userid\";s:5:\"admin\";s:6:\"_leve
l\";i:10;s:6:\"_prefs\";O:15:\"userpreferences\":4:{s:6:\"_prefs\";a:13:{s:6
:\"userid\";O:15:\"_userpreference\":3:{s:13:\"default_value\";s:0:\"\";s:5:
\"_init\";b:0;s:6:\"userid\";s:5:\"admin\";}s:6:\"passwd\";O:15:\"_userprefe
rence\":2:{s:13:\"default_value\";s:0:\"\";s:5:\"_init\";b:0;}s:9:\"autologi
n\";O:20:\"_userpreference_bool\":2:{s:13:\"default_value\";b:0;s:5:\"_init\
";b:0;}s:5:\"email\";O:21:\"_userpreference_email\":2:{s:13:\"default_value\
";s:0:\"\";s:5:\"_init\";b:0;}s:11:\"notifyPages\";O:22:\"_userpreference_no
tify\":2:{s:13:\"default_value\";s:0:\"\";s:5:\"_init\";b:0;}s:5:\"theme\";O
:21:\"_userpreference_theme\":2:{s:13:\"default_value\";s:6:\"MacOSX\";s:5:\
"_init\";b:0;}s:4:\"lang\";O:24:\"_userpreference_language\":2:{s:13:\"defau
lt_value\";


2) when logging in (using ldap) from the login box on the bottom of each
page, you go to the sign in page which has the following warning:

lib\WikiUserNew.php:2088: Warning[2]: ldap_bind(): Unable to bind to server:
Invalid credentials

  It looks like it's checking against a blank password, which isn't valid in
my case :-)  Note:  authentication WORKS!  It's just a warning.

3) when editing a page, the page is edited, but I get the following warning
(could this be a config issue on my end?)

lib\WikiDB\backend\PearDB.php:824: Fatal[256]: wikidb_backend_mysql: fatal
database error

    * DB Error: already exists
    * (INSERT INTO session (sess_id, sess_data, sess_date, sess_ip) VALUES
('e8862bbd480913d1e3d0b7b2e3be8c63',
'wiki_user|O:13:\"_ldappassuser\":9:{s:7:\"_userid\";s:5:\"jcole\";s:6: ...
(It's similar to the above message)

4)  This one may be a bit more serious.  Since about two weeks ago, I have
been getting a lot of false conflicts on editing.  I know this, because I'm
the only one on the entire system editing a page, so no other use could have
edited.  The confilict page has my last edit and my new edit as a conflict.

  This seems to happen if you make a couple of edits in a row.  I just saw
this with Apache 1.3.31/PHP 4.3.7/W2K3.

Thanks,

John Cole


-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of Reini
Urban
Sent: Monday, June 28, 2004 10:59 AM
To: php...@li...
Subject: Re: [Phpwiki-talk] ldap progress


John Cole schrieb:

> Reini,
>   I've been looking at the LDAP code on the current CVS version.  It
appears
> that the LDAP_SET_OPTION string is not getting set in the _init function.
> Not setting those options with AD is causing the search to fail.
> 
>   I'm not sure why the code doesn't work anymore, it looks a lot like the
> old code :-)

Not old code, but it was heavily simplified.
I found your problem (in IniConfig) and fixed the outstanding problem 
with crashes on user logins (other than admins).
The problem was an endless recursion in WikiGroup isAdmin().

I also fixed the GroupLdap handling.

I believe we are now ready for the 1.3.11 release.
All remaining serious bugs are fixed.

I'm checking now the remaining minor problems.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: [Phpwiki-talk] ldap progress

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

Arthaey Angosii schrieb:
> Reini Urban <ru...@x-...> wrote:
>>I believe we are now ready for the 1.3.11 release.
>>All remaining serious bugs are fixed.
> 
> Is there a smooth way to upgrade, once you make the new release? I
> assume there must be, since I've read of several people with existing
> PhpWikis migrating their data, but I don't see any tips on how to
> upgrade without wiping out existing Wiki info.

If you want a complete new wiki:
   "Backup" and "Restore" all your pages from the Administration page. 
(either as zip or as set of files)

If you want to stay with the same database:
   Read the ReleaseNotes,
   "Upgrade" from the Administration page. Or add ?action=upgrade at
   the url

> In general, where should I be asking my PhpWiki questions? There's no
> one on the #phpwiki channel and no phpwiki-support mailing list
> exists; does the Help forum at SF get answered regularly?

Here is the best. The forums are not so often checked.
(Though they would increase or activity meter)

> PS - I see you made yourself a homepage on my wiki! :)

sure, to test your problem.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] ldap progress

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

John Cole schrieb:

> Reini,
>   I've been looking at the LDAP code on the current CVS version.  It appears
> that the LDAP_SET_OPTION string is not getting set in the _init function.
> Not setting those options with AD is causing the search to fail.
> 
>   I'm not sure why the code doesn't work anymore, it looks a lot like the
> old code :-)

Not old code, but it was heavily simplified.
I found your problem (in IniConfig) and fixed the outstanding problem 
with crashes on user logins (other than admins).
The problem was an endless recursion in WikiGroup isAdmin().

I also fixed the GroupLdap handling.

I believe we are now ready for the 1.3.11 release.
All remaining serious bugs are fixed.

I'm checking now the remaining minor problems.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] ldap progress

[John C. <joh...@ua...>]

Reini,
  I've been looking at the LDAP code on the current CVS version.  It appears
that the LDAP_SET_OPTION string is not getting set in the _init function.
Not setting those options with AD is causing the search to fail.

  I'm not sure why the code doesn't work anymore, it looks a lot like the
old code :-)

Thanks,

John Cole

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: [Phpwiki-talk] Oci8 (Oracle) backend

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

Philippe Vanhaesendonck schrieb:
> Reini Urban said:
>>Thanks a lot!
>>
>>I fixed some LIMIT issues (offset,count instead of 0,limit)
>>and it works fine.
>>
>>One question though: did you try ADODB also?
>>I try to bring this up-to-date also, based on your suggestions.
> 
> 
> No I didn't try ADOdb (yet) -- actually I discovered it very recently :-X
> But I'll work on that this week.
> 
> BTW, what are the pros & cons of ADOdb vs Pear:DB? (I don't want to start
> an interface war on the list, I'm just curious!)

ADOdb is faster, more quick&dirty in style, has much more unneeded 
utilities, pre-fetches the next row (which is problematic for us).

good things:
   much more drivers.
   better meta-level support: field list, table list.


I posted this some time ago:
adodb doesn't support table locking, but transactions. I've implemented 
a lot of mysql specific  and some sqlite specific optimizations, to 
avoid locks, but for some destructive operations we will have to add 
some kind of locking manually as before. But this will not be as global 
as before, only the tables which are really affected.

This are my notes (lib/WikiDB/backend/ADODB.php):
  * Now (phpwiki-1.3.10) with adodb-4.22, by Reini Urban:
  * 1) Extended to use all available database backend, not only mysql.
  * 2) It uses the ultra-fast binary adodb extension if loaded.
      (php_adodb.so/.dll)
  * 3) We use FETCH_NUM instead of FETCH_ASSOC (faster and more generic)
  * 4) To support generic iterators which return ASSOC fields, and to
       support queries with variable columns, some trickery was needed
       to use recordset specific fetchMode.
       The first Execute uses the global fetchMode (ASSOC), then it's
       resetted back to NUM and the recordset fetchmode is set to ASSOC.
  * 5) Transaction support, but no locking yet.

ADODB basic differences to PearDB: It pre-fetches the first row into
fields, is dirtier in style, layout and more low-level ("worse is better").
It has less needed basic features (modifyQuery, locks, ...), but some 
more unneeded features included: paging, monitoring and sessions, and 
much more drivers.
No locking (which PearDB supports in some backends), and sequences are 
very bad compared to PearDB.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Oci8 (Oracle) backend

[Philippe V. <Phi...@to...>]

Reini Urban said:
> Thanks a lot!
>
> I fixed some LIMIT issues (offset,count instead of 0,limit)
> and it works fine.
>
> One question though: did you try ADODB also?
> I try to bring this up-to-date also, based on your suggestions.

No I didn't try ADOdb (yet) -- actually I discovered it very recently :-X
But I'll work on that this week.

BTW, what are the pros & cons of ADOdb vs Pear:DB? (I don't want to start
an interface war on the list, I'm just curious!)

-- 
Philippe

Re: [Phpwiki-talk] Installation Help

[Arthaey A. <ar...@gm...>]

I was playing around with the wiki a bit more. I followed the
instructions at
http://sourceforge.net/forum/forum.php?thread_id=1079780&forum_id=18929
and now things seem to be working.

I'm now trying to get anyone but the admin to be able to create a new
user account and log in. This seems to be a more common problem, so
I'm hoping to find a fix somewhere on the Wiki or in the forums...


--
AA

Re: [Phpwiki-talk] Installation Help

[Arthaey A. <ar...@gm...>]

I accidentally sent this just to Bob, rather than the list. I figure
this should continue being public, in case others have similar
problems.

Bob Apthorpe <apt...@cy...> wrote:
> Welcome to the learning curve! :)
>
> hth

Thank you for your quick, detailed, friendly, and very useful reply.
It's nice to see that there are still people like you out on the 'net.
:)

I got Apache to execute PHP files. phpinfo() says it's version 4.3.3
-- I wonder why Apache has 4.3.2? Hopefully that won't be a problem.

> and poking in ./lib/IniConfig.php gives a link to
> ./config/config-default.ini; poking in ./index.php gives a link to
> ./config/config.ini. Without a lot of rummaging, you wouldn't have found
> this.

It's semi-working -- at least I get the virgin page and the Crao theme
seems fine. The wiki's running at:

  http://arthaey.mine.nu:8080/wiki/index.php/HomePage

At the bottom of the homepage, it says:

  Fatal error: Call to a member function on a non-object in
  /home/arthaey/www/phpwiki/lib/Template.php(131) : eval()'d code on line 5

The offending line is in function printExpansion:

  eval('?>' . $this->_munge_input($this->_tmpl));

I don't know PHP (yet), though I do know Perl. The $this object is
behaving in a non-object manner, or so the error message would have me
believe. How should I fix this?

Also, I tried clicking on the PageHistory button for the RecentChanges
page, and got the following PHP warnings:

  lib/main.php:656: Notice[1024]: PageHistory: Cannot find action page
  lib/main.php:576: Notice[1024]: PageHistory: Unknown action

I'm not sure where to begin with those errors, either.

Finally, I've apparently messed up the options for user
authentication. At the homepage, I'm signed in as "The PhpWiki
programming team". Clicking sign out doesn't do anything.

But if I go to RecentChanges, I'm suddenly not logged in at all. If I
type in the ADMIN_USER name, it prompts me for my password, lets me
log in, and gives me admin powers. If I go back to the homepage, I'm
the PhpWiki programming team again. Return to RecentChanges, and I'm
ItaniArthaey again.

Ideally, I'd like to allow anonymous browsing, but require logging in to edit.

Select lines from config/config.ini:

ADMIN_USER = ItaniArthaey
ADMIN_PASSWD = passencryptPassword
ENCRYPTED_PASSWD = true

DATABASE_TYPE = SQL
DATABASE_PREFIX =
DATABASE_DSN = "mysql://wiki:password@localhost(/var/lib/mysql/mysql.sock)/phpwiki"
DATABASE_SESSION_TABLE = session
DATABASE_DIRECTORY = /var/www/wikidb

I did a mysql create phpwiki, like the INSTALL.mysql file said. Do I
need to do something similar for DATABASE_DIRECTORY? (What is that
even used for, and how is it different from the phpwiki database I
already created?)

ENABLE_USER_NEW = true
ALLOW_ANON_USER = true
ALLOW_ANON_EDIT = false
ALLOW_BOGO_LOGIN = false;
ALLOW_USER_PASSWORDS = true
USER_AUTH_ORDER = "PersonalPage : Db"
PASSWORD_LENGTH_MINIMUM = 2
USER_AUTH_POLICY = strict

I'm pretty sure I'm going to have to edit these following settings
sections, but I'm a bit confused by all the options.

; File authentication options
; Session Auth

Do I need to uncomment most of the stuff in Session Auth?

; USER/PREFERENCE queries
; Update the user's preferences
; USERS/GROUPS queries

How do the user pref options interact with file and session
authentication? What are wiki groups good for?

Let me know if you need to see any of my other file settings; I tried
to pick out what was relevant, but obviously I'm new to this. :)

Thanks for the help,

--
AA

Re: [Phpwiki-talk] Oci8 (Oracle) backend

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

Thanks a lot!

I fixed some LIMIT issues (offset,count instead of 0,limit)
and it works fine.

One question though: did you try ADODB also?
I try to bring this up-to-date also, based on your suggestions.

Philippe Vanhaesendonck schrieb:
> Since I have seen some requests in the forum and on the list regarding 
> the Oracle backend, i have made some cleanup in my code, and here is the 
> result...
> 
> The patch file in attachement is a patch against today's CVS (but should 
> work against phpWiki 1.3.10 as well).
> 
> It contains:
> 
>    * doc/INSTALL.oci8: new file -- a bit of doc
>    * lib/WikiDB/backend/PearDB.php: a couple of patches to make PearDB
>      more 'portable' (was too much MySQL specific), plus some hooks to
>      be able to support some Oracle specifics.
>    * lib/WikiDB/backend/oci8.php: new file -- the backend itself
>    * schemas/oci8.sql: new file -- table creation
> 
> As far as I have tested, the patch does not break MySQL backend, and 
> should have no impact on the PostgreSQL one (not tested though).
> For the Oracle side, everything should work except the full text search 
> (would require Intermedia Text).
> 
> Do not hesitate to report issues.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] stability update

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

Reini Urban schrieb:
>> The most important remaining fatals are now:
>>
>> 1) ConvertOldMarkup()
>>    php crash on formatting the 2nd paragraph of OldTextFormattingRules,
>>    AnciennesR%E8glesDeFormatage, ...
>> A complicated anchored regex which crashes in the 2nd loop.
>> We really should check/sanify the allowed regexp's a bit, since admins 
>> and even users (InterWikiMap) can easily destroy them.

This only crashes with Apache2. Very strange.
Looks like another php bug caught us.

> Status: added some debugging code to exclude certain regex to narrow the 
> search.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Installation Help

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

Arthaey Angosii schrieb:
> I recently downloaded phpwiki-1.3.10 onto my Mandrake 9.2 computer,
> running MySQL 4.0.15, PHP (looks like version 4.3.2, maybe... how do I
> check?), and Apache2 (mod_perl/1.99_09 Perl/v5.8.1 auth_mysql/1.11
> mod_ssl/2.0.47 OpenSSL/0.9.7b PHP/4.3.2). I have several questions
> about installing PhpWiki, and this mailing list seemed the best place
> to ask them. So:
> 
> 1. When I extracted the tarball, the files all had user id of 1000 and
> group id of 513. I have no such user or group ids defined on my
> system. Are these just standard ids for PhpWiki, or do I have a
> problem? If the former, what would be some good names to assign to
> those numbers? If the latter, what needs to be fixed?

I produced the tar on cygwin. The strange id's reflect the strange uid's 
which the windows OS gives its users:

$ id rurban
uid=1000(rurban) gid=544(root) Gruppen=544(root),513(phpwiki)

The tar format stores the uid and gid numbers with the names. If you 
don't have those symbolic names on your box the extracted files will get 
the numeric id's.
$ info tar

Previous releases had user.group swain.staff

> 2. I installed MySQL for use with PhpWiki. I followed the installation
> guide and part of the tutorial for MySQL; it appears to be running
> fine. INSTALL-mysql tells me to edit index.php's $DBParams -- but
> there's no mention of it in my index.php! Grepping for "DBParams" show
> that it appears in several lib files, SOAP.php and wiki, but not in
> index.php. What happened?

we changed the config location from /index.php to config/config.ini with 
1.3.10 and didn't update all docs yet.

> 3. Supposedly PhpWiki works out of the box -- but what directory
> should I set this box in? :) I installed Apache2 so I could use
> PhpWiki, thus I'm new to Apache as well. I do have it set up and
> successfully serving regular HTML pages (via router port forwarding,
> if that matters to PhpWiki). Do I just drop the whole phpwiki-1.3.10
> directory into /var/www and cross my fingers? 

why not? if you like the phpwiki-user-visible 1.3.10 prefix.
I personally prefer a /wiki prefix, and I prefer not to see a index.php 
(/wiki/index.php/pagename) in the user-visible url. That's why I use the 
wiki file for which I set the php handler.

See the .htaccess and wiki files.

> If Apache already has PHP support, do I have to do anything special to turn 
 > it on so that it executes PHP pages?

If you serve just index.php not. If another file (such as wiki) you have to.

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

Re: [Phpwiki-talk] User Authentication?

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

Bob Pendleton schrieb:

> I've just installed PHPWiki and I'm testing it and trying to configure
> it. The main trouble that I am having is getting user authentication to
> work the way I want it to work. The docs that I have found are not clear
> on how to configure user authentication. 
> 
> What I would like is for the wiki to always ask for a user id and
> password. If the user id is new then accept the password as that users
> new password (maybe ask for the user to reenter it to make sure it was
> entered correctly) and from then on always require that user id and
> password. It *looks* like you should be able to configure PHPWiki to do
> that, the flags seem to be there, but I can't get it to ever ask for a
> password, but I can get it to fail when any user tries to login :-)
> 
> So, I guess my question is, can I get the behavior I want, or something
> close to it? And, how do I set up that configuration? 
> 
> I down loaded it from source forge yesterday so I believe it is the most
> current version. 

The nightly snapshot or from CVS?
The 1.3.10 release has some known auth problems with Db.
See the http://phpwiki.sourceforge.net/demo/en/ReleaseNotes for the next 
release.

> 
> I'm running Debian/Testing (I'm not using the version of PHPWiki that is
> in Debian/Testing, it seems to be out of date and installs in a manner
> that makes it unusable.) with a 2.4 kernel, and using db4 while I'm
> testing PHPWiki.

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

[Phpwiki-talk] Oci8 (Oracle) backend

[Philippe V. <Phi...@to...>]

Hi!

Since I have seen some requests in the forum and on the list regarding 
the Oracle backend, i have made some cleanup in my code, and here is the 
result...

The patch file in attachement is a patch against today's CVS (but should 
work against phpWiki 1.3.10 as well).

It contains:

    * doc/INSTALL.oci8: new file -- a bit of doc
    * lib/WikiDB/backend/PearDB.php: a couple of patches to make PearDB
      more 'portable' (was too much MySQL specific), plus some hooks to
      be able to support some Oracle specifics.
    * lib/WikiDB/backend/oci8.php: new file -- the backend itself
    * schemas/oci8.sql: new file -- table creation

As far as I have tested, the patch does not break MySQL backend, and 
should have no impact on the PostgreSQL one (not tested though).
For the Oracle side, everything should work except the full text search 
(would require Intermedia Text).

Do not hesitate to report issues.

--
Philippe

[Phpwiki-talk] not_current not known

[Paul H. <he...@ma...>]

Reini,

Small bug with last night's cvs snapshot.

Get the following error(s) on the mainpage, when browsing anonymously:

-----
PHP Warnings

lib/WikiGroup.php:93: Notice[8]: Undefined property: not_current

lib/WikiGroup.php (In template 'head') (In template 'html'):93: Notice[8]: 
Undefined property: not_current:

    * <link rel="bookmark" title="<?= $UserCalPageTitle ?>" href="<?= 
$UserCalPageUrl ?>" />

lib/WikiGroup.php (In template 'navbar') (In template 'top') (In template 
'body') (In template 'html'):93: Notice[8]: Undefined property: not_current
-----

When logged in, only the first error shows.

Fixed by changing line 68 in WikiGroup.php to:

    var $not_current = 0;

Also, on the subject of action=PageInfo, the error I have been getting:

-----
lib/FileFinder.php (In template 'info') (In template 'browse') (In template 
'body') (In template 'html'):186: Fatal[256]: LC_MESSAGES/phpwiki.php: file 
not found
-----

is consistent across languages and themes. In fact, the French edition of the 
page goes nuts (i.e. Erreur Fatale), regardless of whether someone (or even 
the admin) is logged in. 

What I just realized today is that action pages display correctly, without the 
errors (/PhpWikiAdministration?action=PageInfo), but text pages (/
HomePage?action=PageInfo) cause grief, once again, independent of theme, 
locked status or login.

I'm using the MySQL edition; not sure if that would make a difference, but as 
I am flushing the database and installing to a clean directory, there 
shouldn't be any legacy or database related errors.

Hope this helps you find the answer. 

clyde

[Phpwiki-talk] Typo in WikiUserNew.php

[Philippe V. <Phi...@to...>]

Hi,

Just FYI, there is a typo in the 'pref' table name in WikiUserNew.php...

--
Phil.

*** ../../cvs/phpwiki/lib/WikiUserNew.php       Fri Jun 25 16:29:19 2004
--- lib/WikiUserNew.php Sat Jun 26 19:07:38 2004
***************
*** 1051,1057 ****
                                E_USER_WARNING);
                  $stmt = str_replace(array(" user "," pref "," member "),
                                      array(" ".$prefix."user ",
!                                           " ".$prefix."prefs ",
                                            " ".$prefix."member "),$stmt);
              }
          }
--- 1051,1057 ----
                                E_USER_WARNING);
                  $stmt = str_replace(array(" user "," pref "," member "),
                                      array(" ".$prefix."user ",
!                                           " ".$prefix."pref ",
                                            " ".$prefix."member "),$stmt);
              }
          }

Re: [Phpwiki-talk] Installation Help

[Bob A. <apt...@cy...>]

Hi,

On Fri, 25 Jun 2004 10:26:05 -0700 Arthaey Angosii <ar...@gm...> wrote:

> I recently downloaded phpwiki-1.3.10 onto my Mandrake 9.2 computer,
> running MySQL 4.0.15, PHP (looks like version 4.3.2, maybe... how do I
> check?),

Probably 4.3.2 based on what Apache's telling you. Two other ways of getting the version number are via your package management system (rpm -qa | egrep -i php) and asking Apache directly:

----
$ telnet www.example.com 80
Trying 209.99.108.104...
Connected to www.example.com.
Escape character is '^]'.
HEAD /index.html HTTP/1.0
Host: www.example.com

HTTP/1.1 302 Found
Date: Sat, 26 Jun 2004 04:27:38 GMT
Server: Apache/1.3.28 (Unix) PHP/4.3.2
Location: http://www.example.com/not_found.htm
Connection: close
Content-Type: text/html; charset=iso-8859-1

Connection closed by foreign host.
----
Or use 'php -v'
PHP 4.3.1 (cgi), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
    with the ionCube PHP Accelerator v1.3.3r2, Copyright (c) 2001-2002, by Nick Lindridge

> and Apache2 (mod_perl/1.99_09 Perl/v5.8.1 auth_mysql/1.11
> mod_ssl/2.0.47 OpenSSL/0.9.7b PHP/4.3.2). I have several questions
> about installing PhpWiki, and this mailing list seemed the best place
> to ask them. So:
>
> 1. When I extracted the tarball, the files all had user id of 1000 and
> group id of 513. I have no such user or group ids defined on my
> system. Are these just standard ids for PhpWiki, or do I have a
> problem? If the former, what would be some good names to assign to
> those numbers? If the latter, what needs to be fixed?

What user and group does your webserver run as? Use something like:

$ ps -e -o euser,egroup,pid,ppid,args | egrep httpd
root     root      1064     1 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL -D STATUS
wwwrun   nogroup   1178  1064 /usr/sbin/fcgi- -f /etc/httpd/httpd.conf -D SSL -D STATUS
wwwrun   nogroup   1190  1064 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL -D STATUS
wwwrun   nogroup   1700  1064 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL -D STATUS

showing that this webserver runs as user wwwrun, group nogroup.

To fix, go to the root of the phpwiki directory and do

$ chown -R wwwrun:nogroup .

substituting in the user and group that your webserver runs as. You will
probably need to do this as root (via sudo, etc...)

> 2. I installed MySQL for use with PhpWiki. I followed the installation
> guide and part of the tutorial for MySQL; it appears to be running
> fine. INSTALL-mysql tells me to edit index.php's $DBParams -- but
> there's no mention of it in my index.php! Grepping for "DBParams" show
> that it appears in several lib files, SOAP.php and wiki, but not in
> index.php. What happened?

The docs don't reflect the current code.

My guess is that you want to change database type in
./config/config.ini. This is not obvious.

  find . -type f -print | xargs egrep -i '\$DBParams\[.dbtype.\] = '

gives:

./lib/IniConfig.php:    $DBParams['dbtype'] = @$rs['DATABASE_TYPE'];
./lib/IniConfig.php:        $DBParams['dbtype'] = 'dba';
./wiki://$DBParams['dbtype'] = 'SQL';

and poking in ./lib/IniConfig.php gives a link to
./config/config-default.ini; poking in ./index.php gives a link to
./config/config.ini. Without a lot of rummaging, you wouldn't have found
this.

> 3. Supposedly PhpWiki works out of the box -- but what directory
> should I set this box in? :) I installed Apache2 so I could use
> PhpWiki, thus I'm new to Apache as well. I do have it set up and
> successfully serving regular HTML pages (via router port forwarding,
> if that matters to PhpWiki). Do I just drop the whole phpwiki-1.3.10
> directory into /var/www and cross my fingers? If Apache already has
> PHP support, do I have to do anything special to turn it on so that it
> executes PHP pages?

Look for a basic tutorial on PHP and read through your Apache
configuration file. Make a file consisting of the line '<?php phpinfo();
?>' and make sure it's readable by the webserver. If you can get that
file to display correctly (giving you way too much info about PHP), you
can put the phpwiki directory there and start using it (see above for
changing file ownership.)

I usually put the files outside the docroot and tell Apache where to
find them using the Alias and Directory directives but putting the
directory under the docroot should work as well.

Welcome to the learning curve! :)

hth,

-- Bob

[Phpwiki-talk] Installation Help

[Arthaey A. <ar...@gm...>]

I recently downloaded phpwiki-1.3.10 onto my Mandrake 9.2 computer,
running MySQL 4.0.15, PHP (looks like version 4.3.2, maybe... how do I
check?), and Apache2 (mod_perl/1.99_09 Perl/v5.8.1 auth_mysql/1.11
mod_ssl/2.0.47 OpenSSL/0.9.7b PHP/4.3.2). I have several questions
about installing PhpWiki, and this mailing list seemed the best place
to ask them. So:

1. When I extracted the tarball, the files all had user id of 1000 and
group id of 513. I have no such user or group ids defined on my
system. Are these just standard ids for PhpWiki, or do I have a
problem? If the former, what would be some good names to assign to
those numbers? If the latter, what needs to be fixed?

2. I installed MySQL for use with PhpWiki. I followed the installation
guide and part of the tutorial for MySQL; it appears to be running
fine. INSTALL-mysql tells me to edit index.php's $DBParams -- but
there's no mention of it in my index.php! Grepping for "DBParams" show
that it appears in several lib files, SOAP.php and wiki, but not in
index.php. What happened?

3. Supposedly PhpWiki works out of the box -- but what directory
should I set this box in? :) I installed Apache2 so I could use
PhpWiki, thus I'm new to Apache as well. I do have it set up and
successfully serving regular HTML pages (via router port forwarding,
if that matters to PhpWiki). Do I just drop the whole phpwiki-1.3.10
directory into /var/www and cross my fingers? If Apache already has
PHP support, do I have to do anything special to turn it on so that it
executes PHP pages?


Thanks much.

--
AA

[Phpwiki-talk] User Authentication?

[Bob P. <bo...@pe...>]

I've just installed PHPWiki and I'm testing it and trying to configure
it. The main trouble that I am having is getting user authentication to
work the way I want it to work. The docs that I have found are not clear
on how to configure user authentication. 

What I would like is for the wiki to always ask for a user id and
password. If the user id is new then accept the password as that users
new password (maybe ask for the user to reenter it to make sure it was
entered correctly) and from then on always require that user id and
password. It *looks* like you should be able to configure PHPWiki to do
that, the flags seem to be there, but I can't get it to ever ask for a
password, but I can get it to fail when any user tries to login :-)

So, I guess my question is, can I get the behavior I want, or something
close to it? And, how do I set up that configuration? 

I down loaded it from source forge yesterday so I believe it is the most
current version. 

I'm running Debian/Testing (I'm not using the version of PHPWiki that is
in Debian/Testing, it seems to be out of date and installs in a manner
that makes it unusable.) with a 2.4 kernel, and using db4 while I'm
testing PHPWiki.

		Thanks!

			Bob Pendleton

-- 
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bo...@Pe...             +
+ blog:  www.Stonewolf.net             +
+ web:   www.GameProgrammer.com        +
+--------------------------------------+

[Phpwiki-talk] stability update

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

Reini Urban schrieb:
> Reini Urban schrieb:
>> John Cole schrieb:
>>> Reini,
>>>   I'll bring up the latest cvs version on a test machine and try it out.
>>>
>>>   Reini, your doing a whole lot of work right now ;-) and I'm sure 
>>> everyone,
>>> expecially me, appreciate it.  When do you think things will settle down
>>> enough for you to start working towards a new release?
>>
>>
>>
>> As soon as I have fixed the fatals and am on the same stability level 
>> as the release before.
>> (say apache2, cgi, php5 must not crash. login must work ok. iis and 
>> better utf-8 support as bonus)
>>
>> Currently I'm investigating problems with application/xhtml+xml, which 
>> brings out some problematic XHTML code in the templates.
> 
> This is done.
> php5 and CGI and apache2 works fine again.
> Apache2 with USE_PATH_INFO=true or auto works fine with "AcceptPathInfo 
> on".
> 
> Session crashes on overlarge session objects have also been fixed. 
> Anybody knows the number of how large such a session object may be? 
> Reading an overlarge object leads to immediate crashes.
> 
> The most important remaining fatals are now:
> 
> 1) ConvertOldMarkup()
>    php crash on formatting the 2nd paragraph of OldTextFormattingRules,
>    AnciennesR%E8glesDeFormatage, ...
> A complicated anchored regex which crashes in the 2nd loop.
> We really should check/sanify the allowed regexp's a bit, since admins 
> and even users (InterWikiMap) can easily destroy them.

Status: added some debugging code to exclude certain regex to narrow the 
search.

> 2) PageList memory exhaustion on large pagesets
>    (e.g. PhpWikiDemo:en/AllPages)
> This is probably due to WikiDB caching on simple pagelist iterations, 
> which shouldn't be done.

Status: fixed, needs testing.

3) php crash at some template expansion, if just logged in.
    Status: no guess in which expansion yet...

I committed my current status with these remaining problem to CVS now.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Changing database formats

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

I'm doing some forward planning for future Debian packaging features, and I
want to wean people off the dba page stores that were de jure before SQLite
support.  I'm wondering what the best way to do the conversion from page
storage in dba to page storage in SQLite.

Is there a command line tool to do pagedumps and pageloads?  If so, can it
be pointed at databases other than the one configured in the
config.{ini,php} file?  That would be useful, because I'll have to rewrite
the config file, and it'd be useful if the config rewrite were complete
before I start the dump, but it's not essential.

If no such tool exists, what would the best method be to write one?
Just link into the WikiDB stuff, read out all the page revisions, and then
throw them back in?
Am I going to lose large chunks of metadata doing that? 
Is WikiDB even built for that sort of thing?
Is the in-wiki admin dumping code going to be suitable for easy adaptation? 
(I presume so, but it's nice to have confirmation)

Thanks,
- Matt

Re: [Phpwiki-talk] stability

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

Reini Urban schrieb:

> John Cole schrieb:
>> Reini,
>>   I'll bring up the latest cvs version on a test machine and try it out.
>>
>>   Reini, your doing a whole lot of work right now ;-) and I'm sure 
>> everyone,
>> expecially me, appreciate it.  When do you think things will settle down
>> enough for you to start working towards a new release?
> 
> 
> As soon as I have fixed the fatals and am on the same stability level as 
> the release before.
> (say apache2, cgi, php5 must not crash. login must work ok. iis and 
> better utf-8 support as bonus)
> 
> Currently I'm investigating problems with application/xhtml+xml, which 
> brings out some problematic XHTML code in the templates.

This is done.
php5 and CGI and apache2 works fine again.
Apache2 with USE_PATH_INFO=true or auto works fine with "AcceptPathInfo on".

Session crashes on overlarge session objects have also been fixed. 
Anybody knows the number of how large such a session object may be? 
Reading an overlarge object leads to immediate crashes.

The most important remaining fatals are now:

1) ConvertOldMarkup()
    php crash on formatting the 2nd paragraph of OldTextFormattingRules,
    AnciennesR%E8glesDeFormatage, ...
A complicated anchored regex which crashes in the 2nd loop.
We really should check/sanify the allowed regexp's a bit, since admins 
and even users (InterWikiMap) can easily destroy them.

2) PageList memory exhaustion on large pagesets
    (e.g. PhpWikiDemo:en/AllPages)
This is probably due to WikiDB caching on simple pagelist iterations, 
which shouldn't be done.
-- 
Reini Urban
http://phpwiki.sf.net/

Re: [Phpwiki-talk] Small InlineParser bug

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

Dan Frankowski schrieb:
> If you put [A B] in your page, but with a newline, this breaks. In other 
> words:
> 
> [A
> B]
> 
> It used to say (in our 1.3.9-based code):
> 
> lib/InlineParser.php:297: Notice[8]: Undefined offset: 4
> lib/InlineParser.php:297: Notice[8]: Undefined offset: 3
> lib/InlineParser.php:297: Notice[8]: Undefined offset: 2
> lib/InlineParser.php:297: Notice[8]: Undefined offset: 1
> 
> Now it says:
> 
> lib/InlineParser.php:325: Notice[8]: Undefined offset: 4 (...repeated 4 
> times)

BTW: This new collapsed php warning is the new default behaviour of 
postponed errors and warnings. I thought this is better than the 
repeated output of "missing DEBUG, assuming 'DEBUG' ..." 20 times.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] cvs access to dfrankow

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

Dan Frankowski schrieb:
> One of the changes is to add an error handler (instead of just an assert 
> handler). This is useful because then if there is incorrect PHP syntax, 
> vars missing, etc., the tests don't run. In other words, the tests get 
> more picky, which is good. When they get more picky, they want an 
> existing testbox with some stuff in it (InterWikiMap, global_data, a few 
> other things). Thus, I want to make a "testbox" in CVS with the right 
> stuff and check it in, as I did on our local copy.
> 
> Since I do not wish to make changes that you don't want, please tell me 
> that you approve. Then I'll go ahead and make the unit test changes, 
> including adding a CVS-tracked "testbox" with stuff in it.

approved.

but the name "testbox" compared to out intermediate ".testbox"
might not fully understandable. can you think of a better name?

In a perl CPAN test framework the call it "t" (for the logic) and 
"output" (for the output which should be tested against).
i'm not quite accustomed to the java unittest structure.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Wikilens-phpwiki integration: PageList custom column problems

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

Scott Yilek schrieb:
> My name is Scott Yilek and I'm working on wikilens with Dan Frankowski. 
> We've recently been trying to integrate wikilens with phpwiki and we are 
> still having a few issues with the new pagelist custom columns.
> 
> The main problem is that we need to send each column more parameters 
> than are currently allowed.  Currently each custom pagelist column's 
> constructor gets $params which is always assumed to be length 4 with 
> $params[3] as the reference back to the pagelist object.  If any other 
> parameters are needed, the constructor gets them from the pagelist 
> object: $this->_pagelist->getOption('user')  for example.  This doesn't 
> quite work for us because we need each column to get its parameters 
> independently from the other columns.  For example, we can't do 
> getOption('user') if we want a column for each buddy; we need to send in 
> the buddy as a parameter.
> 
> What would be great is if each column's constructor could accept more 
> parameters as necessary.  The way Dan Frankowski proposed originally 
> worked well for this because we could create our own column objects how 
> we liked them and just sent them into pagelist to be added.  Do you 
> think we should go back to this or do you see a better solution?

Have you updated your source, so that I can see it?

I thought putting the required column options to the pagelist object is 
enough, so that the columns can get it from the pagelist object.

you need more usernames? cannot you put the needed array of buddies to 
the $pagelist->_options then?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/