phpwiki-talk

[Phpwiki-talk] wikiadmin upgrade not working...

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

Another error I've seen is the wiki admin upgrade not working.  I believe
that is due to me already having applied the schema changes by hand.  I
don't know if it's possible to check for that, but here is the error
messages anyway :-)
 
 
Thanks,
 
John Cole
 
 
 
 check for page.id auto_increment flag ...ADDING ... 

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

*	DB Error: already exists
*	(ALTER TABLE page CHANGE id id INT NOT NULL AUTO_INCREMENT
[nativecode=1062 ** Duplicate entry '1380' for key 1])
*	


  _____  


Fatal PhpWiki Error


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

*	DB Error: already exists
*	(ALTER TABLE page CHANGE id id INT NOT NULL AUTO_INCREMENT
[nativecode=1062 ** Duplicate entry '1380' for key 1])
*	


Warning: mysql_real_escape_string(): 32 is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 650

Warning: mysql_real_escape_string(): 32 is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 650

Warning: mysql_real_escape_string(): 32 is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 650

Warning: mysql_close(): supplied argument is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 179

Fatal error: wikidb_backend_mysql: fatal database error DB Error: no
database selected (UPDATE session SET sess_data='', sess_date=1085772701,
sess_ip='' WHERE sess_id='' [nativecode= ** ]) in C:\Program Files\Apache
Group\Apache2\htdocs\phpwiki\lib\WikiDB\backend\PearDB.php on line 778

Warning: mysql_real_escape_string(): 32 is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 650

Warning: mysql_real_escape_string(): 32 is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 650

Warning: mysql_real_escape_string(): 32 is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 650

Warning: mysql_close(): supplied argument is not a valid MySQL-Link resource
in c:\php\PEAR\DB\mysql.php on line 179

Fatal error: wikidb_backend_mysql: fatal database error DB Error: no
database selected (UPDATE session SET sess_data='', sess_date=1085772701,
sess_ip='' WHERE sess_id='' [nativecode= ** ]) in C:\Program Files\Apache
Group\Apache2\htdocs\phpwiki\lib\WikiDB\backend\PearDB.php on line 778

Warning: Unknown(): A session is active. You cannot change the session
module's ini settings at this time. in Unknown on line 0 

Re: More unit tests (WAS: Re: Sorting on any PageList column (WAS: Re: [Phpwiki-talk] Re: Development on phpwiki))

[Dan F. <dfr...@cs...>]

By the way, I did have to add little require_once()-s to a bunch of 
files to make these tests work. Basically, the classes have to be a 
little more independent, which is good. Here are example patches, but I 
may have missed some.

diff -b -u -r1.14 -r1.15
--- PageList.php        27 May 2004 19:40:11 -0000      1.14
+++ PageList.php        28 May 2004 16:07:11 -0000      1.15
@@ -57,6 +57,11 @@
  *   new method:
  *     list not as <ul> or table, but as simple comma-seperated list
  */
+
+require_once("lib/WikiUserNew.php");
+require_once("lib/PagePerm.php");
+require_once("lib/Theme.php");
+
 class _PageList_Column_base {
     var $_tdattr = array();


diff -b -u -r1.3 -r1.4
--- AllUsers.php        28 May 2004 16:11:39 -0000      1.3
+++ AllUsers.php        28 May 2004 19:12:12 -0000      1.4
@@ -21,6 +21,7 @@
  */

 require_once('lib/PageList.php');
+require_once('lib/WikiGroup.php');

etc..

I also attach ListPages if you are interested. It's just sugar (could be 
done in other ways), but we felt it was useful somehow.

Dan

Dan Frankowski wrote:

> Whoops, I meant to sent this to phpwiki-talk.
>
> Dan
>
> -------- Original Message --------
> Subject:     More unit tests (WAS: Re: Sorting on any PageList column 
> (WAS: Re: [Phpwiki-talk] Re: Development on phpwiki))
> Date:     Fri, 28 May 2004 14:24:49 -0500
> From:     Dan Frankowski <dfr...@cs...>
> To:     Reini Urban <ru...@x-...>
> References:     <409...@cs...> 
> <40A...@x-...> <40A...@cs...> 
> <40A...@x-...> <40B...@cs...> 
> <40B...@x-...>
>
>
>
> Reini Urban wrote:
>
>> Very good! Finally I don't have to do all the work alone.
>> I'll add this tomorrow.
>
>
>
> Cool! Glad you like it.
>
> By the way, I attach more unit tests in a tarball. These are simple, 
> simple things, but those can still help. For example, we changed a 
> function name and accidentally broke AllPages, AllUsers, 
> OrphanedPages. (Then we changed it back, of course.) Thus, I wrote 
> these simple tests that would have caught that.
>
> Unfortunately, no real good unit tests for PageList yet, but I am 
> going to write at least a couple to test sorting.
>
> Dan
>
>
>

[Phpwiki-talk] OldTextFormattingRules still crashes php 4.3.4 to 4.3.6

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

Well this bug is still in there somewhere.  In the past I have always edited
the editpage.tmp file and removed the part where it transclueds the
OldTextFormattingRules page.
 
This time, when trying to load the virgin pgsrc, I started crashing on
OldTextFormattingRules again.  Well, since I had a blank wiki set up, I
started trying to figure out what line in this page was causing php and
apache to crash (this is a very old bug in the wiki where editing or showing
pages would cause apache/php to crash and the web browser would report
'document contains no data')
 
I have narrowed it down to the first paragraph (lines 15-21 in the pgsrc
file).  It doesn't appear to be related to one line, rather when you get
past 4 of these lines, it seems to crash apache/php. If you cut and past any
5 of the lines, it seems to crash.
 
I'm using Apache 2.0.48/PHP 4.3.6 on windows xp with this mornings version
of phpwiki.
 
One other thing to note:  this code works fine on php 4.2 and only crashes
on 4.3
 
I don't know if the cause is fixable, but for people trying to use phpwiki
on php 4.3, this has to be really frustrating, because you can't edit any
pages.  I'd suggest either removing the old text formatting rules transclude
in the editpage.tmp or removing a few of the lines in the
OldTextFormattingRules page so that it doesn't crash apache/php
 
Thanks,
 
John Cole

More unit tests (WAS: Re: Sorting on any PageList column (WAS: Re: [Phpwiki-talk] Re: Development on phpwiki))

[Dan F. <dfr...@cs...>]

Whoops, I meant to sent this to phpwiki-talk.

Dan

-------- Original Message --------
Subject: 	More unit tests (WAS: Re: Sorting on any PageList column (WAS: 
Re: [Phpwiki-talk] Re: Development on phpwiki))
Date: 	Fri, 28 May 2004 14:24:49 -0500
From: 	Dan Frankowski <dfr...@cs...>
To: 	Reini Urban <ru...@x-...>
References: 	<409...@cs...> <40A...@x-...> 
<40A...@cs...> <40A...@x-...> 
<40B...@cs...> <40B...@x-...>



Reini Urban wrote:

> Very good! Finally I don't have to do all the work alone.
> I'll add this tomorrow.


Cool! Glad you like it.

By the way, I attach more unit tests in a tarball. These are simple, 
simple things, but those can still help. For example, we changed a 
function name and accidentally broke AllPages, AllUsers, OrphanedPages. 
(Then we changed it back, of course.) Thus, I wrote these simple tests 
that would have caught that.

Unfortunately, no real good unit tests for PageList yet, but I am going 
to write at least a couple to test sorting.

Dan

[Phpwiki-talk] Re: phpwiki debugging

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

Miguel Angel Blanch Lardin schrieb:
> PS: BTW you config/config.ini is world readable.
> A little trick for script kiddies:
> 
> chown :users config.ini
> chmod g-r-w-x config.ini
> 
> That way as everyone is an user none will be able to see,write or 
> execute it but you and webserver.

Well script kiddies come in as webserver user. So there's no way.
And for valid shell users I find it useful, as in your case.

But we could turn it off also.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] blog plugin

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

Dmitry M. schrieb:
> I'm just curious if anyone is working on producing a more complete blog
> system based on phpwiki.
> 
> If noone is I'm thinking of doing it myself shortly.

Please do so.
Enhancements, esp. with the stylesheet are appreciated.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] user authentication

[Whit B. <wh...@tr...>]

Hi,

Is there anyone running a recent version with SQL user verification who can
share their configuration settings and experience? Have I overlooked
documentation of this somewhere? 

My goal isn't any combination of authorization schemes, I just want to lock
everything down to SQL, and require a moderator to approve all
registrations. Whatever phpwiki can't do yet I'll code myself, but it seems
like what it can do is way under-documented. Not a flaw for a
work-in-progress, just a small hurdle I hope someone who already understands
this end of it can give me a hand over - and we can stick the answer in the
docs and config file comments so it's not there for the next person.

Thanks,
Whit

On Tue, May 25, 2004 at 09:45:29PM -0400, Whit Blauvelt wrote:
> Hi all,
> 
> I've got the current nightly and am trying to set up config.ini. Please
> excuse me for finding the comments cryptic ;/
> 
> - DBAUTH_AUTH_UPDATE is supposed to be set how for crypt'd passwords in SQL? I
> only see plaintext and database-hashed examples for this (at least by their
> labels).
> 
> - Is the current status that ALLOW_ANON_USER set to true actually allows anon
> edits - even with ALLOW_ANON_EDIT set to fales? A comment hints at that, and
> I know there were problem reports a while back here on this, but I've missed
> whether it was resolved.
> 
> Thanks, sorry for my confusion,
> Whit

[Phpwiki-talk] blog plugin

[Dmitry M. <dm...@la...>]

Hello all.

I'm just curious if anyone is working on producing a more complete blog
system based on phpwiki.

If noone is I'm thinking of doing it myself shortly.

Thanks,

-D

Re: Sorting on any PageList column (WAS: Re: [Phpwiki-talk] Re: Development on phpwiki)

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Dan Frankowski schrieb:
>>> Reini Urban wrote:
>>>> Dan Frankowski schrieb:
>>>>
>>>>> - Sorting on the PageList widget 
>>>>
>>>> sortby=rating? ok.
>>>
>>>
>>>
>>> Not exactly. Two things here so far:
>>>
>>> 1. We need to sort on things not in the DB (e.g., predicted value). 
>>> Thus, I am adding sorting of pages in memory based on 
>>> column::_getValue() (incidentally for any column, which is nice).
>>> 2. We need multiple columns of the same type (e.g., 'ratingvalue' 
>>> type for my buddies A, B, C, D, etc. on the same PageList).
>>
>>
>>
>> Ok. Sorting as generic slow PageList method, to be able to sort on 
>> every column. Even better.
>>
>>> I have been delaying my reply until I have posted some code for this 
>>> on WikiLens, but it's going slower than I'd hoped, so I'm replying 
>>> without code in order to give you a heads-up. 2 is more challenging-- 
>>> it requires identifying column by something other than name or type. 
>>> Right now, I am trying to convert the code so it can still use the 
>>> name, but immediately translates it into column # (0, 1, 2, 3, etc.) 
>>> for the purposes of button headings specifying sorting. I'll post 
>>> this as soon as I can.
>>
>>
> 
> Okay, we have PageList column sorting on wikilens.org.
> 
> I attach our new PageList.php. I do not attach a patch file because:
> 
> a) so much of it looked changed (often in small ways)
> b) some of the "changes" are actually that we are on 1.3.9, not the 
> latest CVS PageList.php, so we probably have some change merging to do.
> 
> Anyway, below I describe a little more the changes in the attached 
> PageList.php, and I hope they are generally useful.
> 
> Dan
> 
> Here are our changes. At the high level, we wanted
> 
> a) To be able to sort on any column, even if not in the DB (e.g., 
> predicted value).
> b) To be able to have multiple columns of the same type (e.g., rating 
> value for Sam, Joe, Mary, etc.). This requires referring to the columns 
> by an id other than column name. We chose number (col# 0, 1, 2, 3, ..).
> 
> In detail, in order of how they show up when I use tkdiff (a graphical 
> diff):
> 
> - We don't yet have creator, owner, etc. (probably from 1.3.10?).

No, owner/creator is in latest CVS only.
It's a bit slow now, I have to investigate why.

> - require_once()s, so our PageListTest.php unit tests work
> - add _PageList_Column_base::getHeading() because at one point I thought 
> we might have to override on a subclass
> - ditched heading() because no one seemed to be using it anywhere

I left it in. maybe someone or some theme wants to keep the old style.

> - add parms to button_heading(): $pagelist to refer to it in the 
> sortby() function, $colNum to generate HTML for headings.
> - add _PageList_Column_Base::_compare() for default sorting.
> - add more column types: numbacklinks is probably useful, the rest 
> (coagreement, minmisery, averagerating) are WikiLens-specific, and we'll 
> end up pulling them out later

I've moved plugin or theme specific columns into the resp. files, to 
clean up PageList.

> - add _PageList_Column_pagename::_compare
> - add _PageList_Page class for sorting
> - add PageList::_columnsMap to map column names to #s
> - PageList::_rows => PageList::_pages to signify we are storing 
> _PageList_Page entries now
> - Set PageList::_options right away, so it is accessible to all functions
> - Change getTotal(), isEmpty(), addPage() to work with _pages.
> - Make a _renderPageRow() that turns a _pages entry into HTML, so we can 
> delay its HTML rendering until after we sort it
> - don't have maxLen() .. don't know what that is

This is the max strlen of all pagenames, to get consistent pagename 
column width on paging.

> - Get rid of sortable_columns() .. they're all sortable now
> - Add getOption() function to get options because it is convenient to 
> not get PHP warnings about "array index doesn't exist"
> - Change _addColumn(): add commentary, have it call addColumnObject()
> - Add addColumnObject() to allow outside objects to add columns of the 
> same type, by repeated calling of this function.
> - Add _pageCompare() and_sortPages() for sorting
> - We don't have any paging code yet .. this will unfortunately perhaps 
> interfere with sorting in some ways.
> - _generateList() and _generateTable() use _renderPageRow()

Very good! Finally I don't have to do all the work alone.
I'll add this tomorrow.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] restoring files with versions only loads the f irst version...

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

John Cole schrieb:
> Oliver,
>   Thanks for the reply.  I've tried your suggestion and I get similar
> results with only the first version being loaded.

Sorry,
Restoring older revisions is not yet implemented. Only the last revision.

But should be no major problem, I'll do this tomorrow.

Sorting on any PageList column (WAS: Re: [Phpwiki-talk] Re: Development on phpwiki)

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> Reini Urban wrote:
>>
>>> Dan Frankowski schrieb:
>>>
>>>> - Sorting on the PageList widget 
>>>
>>> sortby=rating? ok.
>>
>>
>> Not exactly. Two things here so far:
>>
>> 1. We need to sort on things not in the DB (e.g., predicted value). 
>> Thus, I am adding sorting of pages in memory based on 
>> column::_getValue() (incidentally for any column, which is nice).
>> 2. We need multiple columns of the same type (e.g., 'ratingvalue' 
>> type for my buddies A, B, C, D, etc. on the same PageList).
>
>
> Ok. Sorting as generic slow PageList method, to be able to sort on 
> every column. Even better.
>
>> I have been delaying my reply until I have posted some code for this 
>> on WikiLens, but it's going slower than I'd hoped, so I'm replying 
>> without code in order to give you a heads-up. 2 is more challenging-- 
>> it requires identifying column by something other than name or type. 
>> Right now, I am trying to convert the code so it can still use the 
>> name, but immediately translates it into column # (0, 1, 2, 3, etc.) 
>> for the purposes of button headings specifying sorting. I'll post 
>> this as soon as I can.
>

Okay, we have PageList column sorting on wikilens.org.

I attach our new PageList.php. I do not attach a patch file because:

a) so much of it looked changed (often in small ways)
b) some of the "changes" are actually that we are on 1.3.9, not the 
latest CVS PageList.php, so we probably have some change merging to do.

Anyway, below I describe a little more the changes in the attached 
PageList.php, and I hope they are generally useful.

Dan

Here are our changes. At the high level, we wanted

a) To be able to sort on any column, even if not in the DB (e.g., 
predicted value).
b) To be able to have multiple columns of the same type (e.g., rating 
value for Sam, Joe, Mary, etc.). This requires referring to the columns 
by an id other than column name. We chose number (col# 0, 1, 2, 3, ..).

In detail, in order of how they show up when I use tkdiff (a graphical 
diff):

- We don't yet have creator, owner, etc. (probably from 1.3.10?).
- require_once()s, so our PageListTest.php unit tests work
- add _PageList_Column_base::getHeading() because at one point I thought 
we might have to override on a subclass
- ditched heading() because no one seemed to be using it anywhere
- add parms to button_heading(): $pagelist to refer to it in the 
sortby() function, $colNum to generate HTML for headings.
- add _PageList_Column_Base::_compare() for default sorting.
- add more column types: numbacklinks is probably useful, the rest 
(coagreement, minmisery, averagerating) are WikiLens-specific, and we'll 
end up pulling them out later
- We don't yet have author/creator changes (1.3.10 or CVS?)
- add _PageList_Column_pagename::_compare
- add _PageList_Page class for sorting
- add PageList::_columnsMap to map column names to #s
- PageList::_rows => PageList::_pages to signify we are storing 
_PageList_Page entries now
- Set PageList::_options right away, so it is accessible to all functions
- Change getTotal(), isEmpty(), addPage() to work with _pages.
- Make a _renderPageRow() that turns a _pages entry into HTML, so we can 
delay its HTML rendering until after we sort it
- don't have maxLen() .. don't know what that is
- Get rid of sortable_columns() .. they're all sortable now
- Add getOption() function to get options because it is convenient to 
not get PHP warnings about "array index doesn't exist"
- Change _addColumn(): add commentary, have it call addColumnObject()
- Add addColumnObject() to allow outside objects to add columns of the 
same type, by repeated calling of this function.
- Add _pageCompare() and_sortPages() for sorting
- We don't have any paging code yet .. this will unfortunately perhaps 
interfere with sorting in some ways.
- _generateList() and _generateTable() use _renderPageRow()

RE: [Phpwiki-talk] restoring files with versions only loads the f irst version...

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

Oliver,
  Thanks for the reply.  I've tried your suggestion and I get similar
results with only the first version being loaded.

Thanks,

John Cole

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of Oliver
Betz
Sent: Friday, May 28, 2004 11:39 AM
To: php...@li...
Subject: Re: [Phpwiki-talk] restoring files with versions only loads the
first version...


John Cole <joh...@ua...> wrote:

[...]

> zip file, then restore this on a blank wiki db.  You will get conflicts
for
> each version of a file and only the first version will be loaded.

Jeff Dairiki wrote about restoring a full ZIPDUMP to an empty Wiki:

...A hack to avoid that is to add an overwrite=1 query arg. I.e. to 
trigger the "load virgin wiki", browse to:

http://path.to/your/wiki/index.php?overwrite=1

Oliver


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] restoring files with versions only loads the first version...

[Oliver B. <ob...@de...>]

John Cole <joh...@ua...> wrote:

[...]

> zip file, then restore this on a blank wiki db.  You will get conflicts for
> each version of a file and only the first version will be loaded.

Jeff Dairiki wrote about restoring a full ZIPDUMP to an empty Wiki:

...A hack to avoid that is to add an overwrite=1 query arg. I.e. to 
trigger the "load virgin wiki", browse to:

http://path.to/your/wiki/index.php?overwrite=1

Oliver

[Phpwiki-talk] restoring files with versions only loads the first version...

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

I was able to get the latest version from cvs (I'm glad sf fixed that ;-)
and I'm running into some small problems.
 
To isolate these I wanted to make sure there havent been any format changes,
so I tried the upgrad link on the admin page.  But that errored off (I have
to change config to get the error message).
 
Well, after that, I created a new database and loaded the mysql.sql schema.
There seems to be an error on the version table ddl, but I don't see what it
is.  Creating the table by hand in phpMyAdmin seemed to work fine.  I then
tried to load the page dump from the previous wiki and it loads only the
first version of each page, not the page with it's history.  If I unzip the
dump and place in the pgsrc directory, the restore does the same thing.
 
To reproduce this, you should be able to dump a wiki with the history into a
zip file, then restore this on a blank wiki db.  You will get conflicts for
each version of a file and only the first version will be loaded.
 
I'm using a MySQL database with the SQL driver, Apache 2.0.48, Php 4.3.4.
 
Thanks,
 
John Cole

Re: [Phpwiki-talk] CreateToc Plugin

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

Bernhard Kleine schrieb:
> I have used the following
> 
> ![Antikörper]
> 
> and added the CreateToc Plugin to the page with this heading. In the
> bottom appears
> 
> PHP Warning:
> 
> lib/plugin/CreateToc.php (In template 'browse') (In template 'body') 
> (In template 'html'):78: Notice[1024]: Heading <h4>
> \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\[Antikörper\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\]
> </h4> not found
> 
>     *
> 
> lib/plugin/CreateToc.php (In template 'browse') (In template 'body') (In
> template 'html'):78: Notice[1024]: Heading <h4> 
> 
> and then  1010 times \
> 
> A bug?

Yes, because of the german umlaut.
Thanks for bringing this to my attention.
-- 
Reini Urban
http://phpwiki.sf.net/

[Phpwiki-talk] CreateToc Plugin

[Bernhard K. <ber...@mn...>]

I have used the following

![Antikörper]

and added the CreateToc Plugin to the page with this heading. In the
bottom appears

PHP Warining:

lib/plugin/CreateToc.php (In template 'browse') (In template 'body') 
(In template 'html'):78: Notice[1024]: Heading <h4>
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\[Antikörper\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\]
</h4> not found

    *

lib/plugin/CreateToc.php (In template 'browse') (In template 'body') (In
template 'html'):78: Notice[1024]: Heading <h4> 

and then  1010 times \

A bug?

Bernhard

Re: [Phpwiki-talk] themes are missing from the nightly

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

Whit Blauvelt schrieb:
> Are the themes missing from the nightly for the same reason as the cvs is
> broken? 

Yes, unfortunately. But it should be solved by today.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] themes are missing from the nightly

[Whit B. <wh...@tr...>]

Are the themes missing from the nightly for the same reason as the cvs is
broken? 

Whit

[Phpwiki-talk] user authentication

[Whit B. <wh...@tr...>]

Hi all,

I've got the current nightly and am trying to set up config.ini. Please
excuse me for finding the comments cryptic ;/

- DBAUTH_AUTH_UPDATE is supposed to be set how for crypt'd passwords in SQL? I
only see plaintext and database-hashed examples for this (at least by their
labels).

- Is the current status that ALLOW_ANON_USER set to true actually allows anon
edits - even with ALLOW_ANON_EDIT set to fales? A comment hints at that, and
I know there were problem reports a while back here on this, but I've missed
whether it was resolved.

Thanks, sorry for my confusion,
Whit

Re: [Phpwiki-talk] How to get to anchor?

[Rob F. <rfu...@dr...>]

Bernhard Kleine wrote:
> Hallo,
> html allows anchors <a name="test2">Test2</a>
> and hyperlinks like pagename#test2.
> How can this be used with phpwiki?
> Thanks a lot, merci vielmals
> Bernhard

 From the TextFormattingRules page:
#In-page hyperlinks are made by placing a named anchor and referring to 
the anchor in a hyperlink:
     *
       Named anchors:
           o #[foo]: An anchor around the text "foo" with id "foo".
           o #[|foo]: An empty anchor with id "foo".
           o #[howdy|foo]: An anchor around the text "howdy" with id "foo".
     * References to name anchors are made thusly:
       [##hyperlinks], [OtherPage#foo], [named|OtherPage#foo].

Voila.

BTW, you can find this page by doing a full text search for "anchor" in 
any phpwiki (the TextFormattingRules page comes up in the search results).

Rob.

[Phpwiki-talk] How to get to anchor?

[Bernhard K. <ber...@mn...>]

Hallo,

html allows anchors <a name="test2">Test2</a>

and hyperlinks like pagename#test2.

How can this be used with phpwiki?

Thanks a lot, merci vielmals

Bernhard

Re: [Phpwiki-talk] FreeBSD port

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

Aristedes Maniatis schrieb:

> 
> On 25/05/2004, at 10:54 PM, Reini Urban wrote:
> 
>> Aristedes Maniatis schrieb:
>>
>>> I've significantly tidied up the FreeBSD port and brought it up to 
>>> 1.3.10. I notice that this is marked in Sourceforge as the 
>>> development branch and 1.2.x is still stable. But since this 
>>> situation has languished for some time (several years?), will it be 
>>> changing soon?
>>
>>
>> 1.2.x can only be used with register_globals = on.
> 
> 
> I've found this was necessary on 1.3.10 as well. Not a good idea. I 
> better try again with it off and see if I made a mistake. I had a bit of 
> trouble until I realised that php cached everything in the 
> config/config.ini until I restarted apache.

hmm, strange. php doesn't cache config.ini for our 1.3.x installations.
we even recommend register_globals = off in our sample .htaccess file.

> I also had problems with variables_order = "GPCS". Shouldn't you be 
> using getenv()?

for 1.2.x yes, for 1.3.x not. We query $HTTP_ENV_VARS directly if used 
as CGI, otherwise $HTTP_SERVER_VARS.

>> Stable means, that no development is done on this branch besides 
>> smaller bugfixes which appear from time to time. (dba lately)
>> I would consider 1.3.x more stable than 1.2.x, because it reacts 
>> better on unfriendly or unusual environments.
> 
> Then may I suggest you mark it as such in Sourceforge and I'll get the 
> FreeBSD committers to CVS my port once I've ironed out the bugs.

well, that's debatable.
1.2.x is per this definition "stable", even if 1.3.x is problem-wise 
more stable. of course as with every development branch new features and 
new config options create new problems.

>>> If so, I'll submit the updated FreeBSD port and make it much easier 
>>> for FreeBSD users to install and use this package.
>>
>> Please post the patch or package url.
>> I am curious how to changed the default installation for FreeBSD, 
>> since normally nothing had to be changed IMHO. Maybe a postinstall 
>> script?
> 
> 
> Well, it started because you changed a lot of folder names. So I cleaned 
> that up. Then I tried to make it work better and break less in the 
> future. Then I put things in more sensible paths and put in a little 
> documentation about how to get it to work once you've finished. I'll 
> post what I've got so far, but isn't quite done...I've got a problem 
> right now with sed, but I'll get that sorted.

You mean from 1.2.x to 1.3.x?
I'm really interested in the "make it work better and break less in the
future"... :)

>> Debian decided to use a /etc/phpwiki/config.ini
> 
> Yes, I thought about that, but I wasn't sure about the problems with 
> getting apache to read that directory properly since it is outside 
> docroot. I wanted to keep changes to httpd.conf to a minimum since they 
> are very hard to automate.

imho, you only have to:
chmod 775 /etc/phpwiki/
chgrp www /etc/phpwiki/ /etc/phpwiki/config.ini

no change to http.conf required. phpwiki/index.php tries to read 
config.ini directly.

> PORTNAME=       phpwiki
> PORTVERSION=    1.3.10
> CATEGORIES=     www
> MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE}
> MASTER_SITE_SUBDIR=     phpwiki
> 
> MSG_SKEL=       ${PKGDIR}/pkg-message
> PKGMESSAGE=     ${WRKDIR}/pkg-message
> 
> MAINTAINER=     di...@Fr...
> COMMENT=        A PHP WikiWikiWeb
> 
> .if defined(WITH_APACHE2)
> RUN_DEPENDS+=   
> ${LOCALBASE}/libexec/apache2/libphp4.so:${PORTSDIR}/${PHP4_PORT}
> .else
> RUN_DEPENDS+=   
> ${LOCALBASE}/libexec/apache/libphp4.so:${PORTSDIR}/${PHP4_PORT}
> .endif
> 
> NO_BUILD=       YES
> PHP4_PORT?=     www/mod_php4
> PHPWIKI?=       www/phpwiki
> PLIST_SUB+=     PHPWIKI=${PHPWIKI}
> 
> pre-install:
> #        @${SED} -e 's,%%PHPWIKI%%,${PHPWIKI},g'   \
> #               -e 's,%%PREFIX%%,${PREFIX},g' ${MSG_SKEL} > ${PKGMESSAGE}
>         @${CP} ${MSG_SKEL} ${PKGMESSAGE}
> 
> do-install:
>         @${MKDIR} ${PREFIX}/${PHPWIKI}
>         @${CP} -Rp  ${WRKSRC}/* ${PREFIX}/${PHPWIKI}
>         @${CHOWN} -R www:www ${PREFIX}/${PHPWIKI}
>         @${CHMOD} -R 755 ${PREFIX}/${PHPWIKI}
> 
>         @${TEST} -f ${PREFIX}/${PHPWIKI}/config/config.ini || \
>                 ${CP} ${PREFIX}/${PHPWIKI}/config/config-dist.ini \
>                         ${PREFIX}/${PHPWIKI}/config/config.ini
> 
> post-install:
>         @${CAT} ${PKGMESSAGE}
> 
> .include <bsd.port.mk>
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] FreeBSD port

[Aristedes M. <ar...@is...>]

On 25/05/2004, at 10:54 PM, Reini Urban wrote:

> Aristedes Maniatis schrieb:
>> I've significantly tidied up the FreeBSD port and brought it up to 
>> 1.3.10. I notice that this is marked in Sourceforge as the 
>> development branch and 1.2.x is still stable. But since this 
>> situation has languished for some time (several years?), will it be 
>> changing soon?
>
> 1.2.x can only be used with register_globals = on.

I've found this was necessary on 1.3.10 as well. Not a good idea. I 
better try again with it off and see if I made a mistake. I had a bit 
of trouble until I realised that php cached everything in the 
config/config.ini until I restarted apache.

I also had problems with variables_order = "GPCS". Shouldn't you be 
using getenv()?

> Stable means, that no development is done on this branch besides 
> smaller bugfixes which appear from time to time. (dba lately)
> I would consider 1.3.x more stable than 1.2.x, because it reacts 
> better on unfriendly or unusual environments.

Then may I suggest you mark it as such in Sourceforge and I'll get the 
FreeBSD committers to CVS my port once I've ironed out the bugs.

>> If so, I'll submit the updated FreeBSD port and make it much easier 
>> for FreeBSD users to install and use this package.
>
> Please post the patch or package url.
> I am curious how to changed the default installation for FreeBSD, 
> since normally nothing had to be changed IMHO. Maybe a postinstall 
> script?

Well, it started because you changed a lot of folder names. So I 
cleaned that up. Then I tried to make it work better and break less in 
the future. Then I put things in more sensible paths and put in a 
little documentation about how to get it to work once you've finished. 
I'll post what I've got so far, but isn't quite done...I've got a 
problem right now with sed, but I'll get that sorted.


>
> Debian decided to use a /etc/phpwiki/config.ini

Yes, I thought about that, but I wasn't sure about the problems with 
getting apache to read that directory properly since it is outside 
docroot. I wanted to keep changes to httpd.conf to a minimum since they 
are very hard to automate.

Ari Maniatis



PORTNAME=       phpwiki
PORTVERSION=    1.3.10
CATEGORIES=     www
MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE}
MASTER_SITE_SUBDIR=     phpwiki

MSG_SKEL=       ${PKGDIR}/pkg-message
PKGMESSAGE=     ${WRKDIR}/pkg-message

MAINTAINER=     di...@Fr...
COMMENT=        A PHP WikiWikiWeb

.if defined(WITH_APACHE2)
RUN_DEPENDS+=   
${LOCALBASE}/libexec/apache2/libphp4.so:${PORTSDIR}/${PHP4_PORT}
.else
RUN_DEPENDS+=   
${LOCALBASE}/libexec/apache/libphp4.so:${PORTSDIR}/${PHP4_PORT}
.endif

NO_BUILD=       YES
PHP4_PORT?=     www/mod_php4
PHPWIKI?=       www/phpwiki
PLIST_SUB+=     PHPWIKI=${PHPWIKI}

pre-install:
#        @${SED} -e 's,%%PHPWIKI%%,${PHPWIKI},g'   \
#               -e 's,%%PREFIX%%,${PREFIX},g' ${MSG_SKEL} > 
${PKGMESSAGE}
         @${CP} ${MSG_SKEL} ${PKGMESSAGE}

do-install:
         @${MKDIR} ${PREFIX}/${PHPWIKI}
         @${CP} -Rp  ${WRKSRC}/* ${PREFIX}/${PHPWIKI}
         @${CHOWN} -R www:www ${PREFIX}/${PHPWIKI}
         @${CHMOD} -R 755 ${PREFIX}/${PHPWIKI}

         @${TEST} -f ${PREFIX}/${PHPWIKI}/config/config.ini || \
                 ${CP} ${PREFIX}/${PHPWIKI}/config/config-dist.ini \
                         ${PREFIX}/${PHPWIKI}/config/config.ini

post-install:
         @${CAT} ${PKGMESSAGE}

.include <bsd.port.mk>


-------------------------->
ish group pty ltd
http://www.ish.com.au
7 Darghan St Glebe 2037 Australia
phone +61 2 9660 1400   fax +61 2 9660 7400
PGP fingerprint 08 57 20 4B 80 69 59 E2  A9 BF 2D 48 C2 20 0C C8

Re: [Phpwiki-talk] FreeBSD port

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

Aristedes Maniatis schrieb:
> I've significantly tidied up the FreeBSD port and brought it up to 
> 1.3.10. I notice that this is marked in Sourceforge as the development 
> branch and 1.2.x is still stable. But since this situation has 
> languished for some time (several years?), will it be changing soon?

1.2.x can only be used with register_globals = on.
Stable means, that no development is done on this branch besides smaller 
bugfixes which appear from time to time. (dba lately)
I would consider 1.3.x more stable than 1.2.x, because it reacts better 
on unfriendly or unusual environments.

> If so, I'll submit the updated FreeBSD port and make it much easier for 
> FreeBSD users to install and use this package.

Please post the patch or package url.
I am curious how to changed the default installation for FreeBSD, since 
normally nothing had to be changed IMHO. Maybe a postinstall script?

Debian decided to use a /etc/phpwiki/config.ini
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] FreeBSD port

[Aristedes M. <ar...@is...>]

I've significantly tidied up the FreeBSD port and brought it up to 
1.3.10. I notice that this is marked in Sourceforge as the development 
branch and 1.2.x is still stable. But since this situation has 
languished for some time (several years?), will it be changing soon?

If so, I'll submit the updated FreeBSD port and make it much easier for 
FreeBSD users to install and use this package.

Ari Maniatis



-------------------------->
ish group pty ltd
http://www.ish.com.au
7 Darghan St Glebe 2037 Australia
phone +61 2 9660 1400   fax +61 2 9660 7400
PGP fingerprint 08 57 20 4B 80 69 59 E2  A9 BF 2D 48 C2 20 0C C8