phpwiki-talk

Re: [Phpwiki-talk] phpwiki not running with php as cgi

[Benjamin T. <th...@cc...>]

Matthew Palmer wrote:

> On Mon, Mar 15, 2004 at 03:54:59PM +0100, Benjamin Thelen wrote:
> 
>>I don't know what COMPRESS_OUTPUT is, I'd like to check that. Where do 
>>I force this?
> 
> 
> In 1.3.7, it's in index.php (uncomment the appropriate define).  Prior to
> that (1.3.4, for instance) there's no define, but the code is in
> lib/Request.php somewhere - search for "ob_gzhandler" and you'll find it,
> comment it out or give it an early return or something.
> 
> - Matt
> 

Matt,

thanks again!

I did this with 1.3.7 and suddenly saw the entry page, but, I am 
afraid, that's all. In 1.3.4, I found the appropriate section, no 
change. Sorry.

Any further ideas? Any options php needs to be compiled with?

Ben

[Phpwiki-talk] RE phpwiki-talk@lists.sourceforge.net

[shenzhen f. <in...@sz...>]

php...@li...   您好! 

謝謝你的來信, 現回復如下: 
我們是深圳一家（噴畫印刷）生產廠家

主要從事噴畫印刷的生產工作, 例如: 
各類大小廣告宣傳畫面、海報橫額、展板、燈片、展覽展示等。
承印各類目錄畫冊、產品介紹、手提袋、包裝盒、台歷挂歷等。

我們需要知道你的具體尺寸, 規格, 顏色, 數量等才能為你成本覈算
可送貨到羅湖口岸或香港, 最快上午發貨, 當天下午收到, 香港銀行賬號入數即發

你的文件資料可以直接通過以下地址放到我廠的電腦上
ftp://szcolor.com/
ftp://13691984046.dns0755.net/
一般E-mail來信最多半天內即可回復, 如未得復, 請電話聯絡

如果你平時要為了能夠與我廠即時取得溝通，
可下載這個程序安裝并依照軟件提示注冊一個ICQ號碼
http://www.icq.com/download/
然後再加入我的用戶號：173161456 即可看到我廠是否在線并交流

Dear Hong Kong compatriots:
Thank you for your enquiries on our product. 
We are that an advertisement in Shenzhen make the factory.
Hope that the information can bring convenience for you!

Speciality of our factory:
1. Making of color poster by spray 
2. Making of color page by printing  
Including all kinds of poster, outdoor and indoor Banner, etc.. 
Including all kinds of paper printing, catalogue, box, etc.. 
You can visit our home page www.szcolor.com for more information.
Welcome your quotation inquiry!

Mr. Liu
Shen Zhen Advertising Factory
http://www.6220610.com/
hon...@62...
Tel: +86-0755-2622 0610
Fax: +86-0755-2620 2664
Mobile:  136-9198-4046
ICQ Number: 173161456    

Welcome to contact us !

Re: [Phpwiki-talk] SQLite database backend problems

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

Matthew Palmer schrieb:
> On Wed, Mar 17, 2004 at 02:53:42PM +0100, Reini Urban wrote:
> Found the problem though (see the list for details).

Experimental PearDB SQLite support is in current Phpwiki CVS.
Thanks Matthew.

The SQLite DB will gain popularity with the current MySQL vs PHP license 
drama:
http://www.edwardbear.org/serendipity/archives/1193_My_Beef_with_MySQLs_License.html
http://www.php-center.de/beitraege/detail.php?a_id=442
http://zak.greant.com/archives/cat_licensing.html
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] SQLite database backend problems

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

On Wed, Mar 17, 2004 at 02:53:01PM +0100, Reini Urban wrote:
> Matthew Palmer schrieb:
> >I'm working on an SQLite backend helper for PHPWiki, so that I don't have 
> >to
> >use BDB (ugh!), flat file, or do nassssty setup on a real SQL engine. 
> >However, it wouldn't be an SQL database without foibles, and I'm getting
> >them by the truckload.
> 
> Do you really want it now, and not wait for the official PHP and PearDB 
> + ADODB support?

Timeframe on the new DB system?  I couldn't find anything on the SF site
about it.  I know it's been discussed here before, but was anything planned
re: release date?

What exactly is meant by "official PHP and PearDB + ADODB support", anyway? 
Surely one would be enough?

> >If someone with a smattering more experience at hacking PHPWiki could try
> >out the sqlite.php backend stub and the sqlite.sql schema at
> >http://www.hezmatt.org/~mpalmer/sqlite-phpwiki and try and work out what's
> >*really* going on behind the scenes, I'd be grateful.  I've been banging my
> >head against these problems for hours now, without getting anywhere useful
> >(lots of dead ends and useless tracebacks, but that's about it).
> 
> Ok, I'll have a look, but it's not top-priority.

I was planning on going to bed after making my plea, but decided to give it
one more shot.  As always, you find the bug after you've made the public
announcement that you're too dumb to find it.  <grin>

The problem is ambiguous SQL and lazy client library authors.  "SELECT
foo.bar, baz.wombat" is inconsistent as to what the field names will be on a
DB_FETCHMODE_ASSOC.  MySQL (and I presume PgSQL) will return just the field
name - potentially losing information.  SQLite goes the other way, and
returns table.field instead, so when the iterator goes looking for the
'pagename' index in a returned row (backend/PearDB.php:~797) it bombs on
SQLite, because the field name there is linkee.pagename (or linker.pagename,
but you get the idea).

The solution is to fully qualify all field names when operating in a query
environment with ambiguous field names (which should be SOP anyway).  So,
instead of coding "SELECT $want.*" in backend/PearDB.php:~412, you write
"SELECT $want.id as id, $want.pagename as pagename" and so on.

I count five places in each of PearDB.php and ADODB.php where the .* problem
needs to be fixed, and there's probably a bunch of places which are using
ambiguous names without the all field catcher.  A fix will be in the next
Debian PHPWiki release, at least, and if anyone thinks it's useful, I'll put
the patch into the SF patch tracker.


-- 
"People aren't smart enough to write thread-safe code."
		-- Rasmus Lehdorf, LCA 2004

Re: [Phpwiki-talk] SQLite database backend problems

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

Matthew Palmer schrieb:
> I'm working on an SQLite backend helper for PHPWiki, so that I don't have to
> use BDB (ugh!), flat file, or do nassssty setup on a real SQL engine. 
> However, it wouldn't be an SQL database without foibles, and I'm getting
> them by the truckload.

Do you really want it now, and not wait for the official PHP and PearDB 
+ ADODB support?

> If someone with a smattering more experience at hacking PHPWiki could try
> out the sqlite.php backend stub and the sqlite.sql schema at
> http://www.hezmatt.org/~mpalmer/sqlite-phpwiki and try and work out what's
> *really* going on behind the scenes, I'd be grateful.  I've been banging my
> head against these problems for hours now, without getting anywhere useful
> (lots of dead ends and useless tracebacks, but that's about it).

Ok, I'll have a look, but it's not top-priority.

> Particular problems:
> 
> * Page names don't get set in a lot of WikiDB_Page creations, which makes
> the page explode.  Commenting out the assert seems to make things work a
> bit, but it's obviously not happy...
> 
> * I noticed the BackLinks action page doesn't exist.  No idea why.
> 
> * Several "Undefined variable" problems (versiondata, mtime, have_content)
> in backend/PearDB.php at lines 255, 257, and 261 respectively.
> 
> * None of the top links are appearing (but I presume that's related to the
> page naming thing - in fact, most things are probably page name related).
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] SQLite database backend problems

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

I'm working on an SQLite backend helper for PHPWiki, so that I don't have to
use BDB (ugh!), flat file, or do nassssty setup on a real SQL engine. 
However, it wouldn't be an SQL database without foibles, and I'm getting
them by the truckload.

If someone with a smattering more experience at hacking PHPWiki could try
out the sqlite.php backend stub and the sqlite.sql schema at
http://www.hezmatt.org/~mpalmer/sqlite-phpwiki and try and work out what's
*really* going on behind the scenes, I'd be grateful.  I've been banging my
head against these problems for hours now, without getting anywhere useful
(lots of dead ends and useless tracebacks, but that's about it).

Particular problems:

* Page names don't get set in a lot of WikiDB_Page creations, which makes
the page explode.  Commenting out the assert seems to make things work a
bit, but it's obviously not happy...

* I noticed the BackLinks action page doesn't exist.  No idea why.

* Several "Undefined variable" problems (versiondata, mtime, have_content)
in backend/PearDB.php at lines 255, 257, and 261 respectively.

* None of the top links are appearing (but I presume that's related to the
page naming thing - in fact, most things are probably page name related).

- Matt

Re: [Phpwiki-talk] Patch for initial_content arg to page editing and CreatePage

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

Dan,
I'd love to add your RateThisPage feature to PhpWiki. Did you see my 
latest WikiPoll?

The CategoryPage plugin idea is also cool, but I would like to change it 
a bit.
I see your point with the dynamically created initial_content, but then 
I would like to suggest to use variables in the user-editable 
TemplatePage content which get's translated per Category.

Something wikipedia is also struggling with.

Dan F schrieb:
> As background to this discussion, I attach my current version of my 
> CategoryPage.php plugin, and the categorypage.tmpl it uses. The idea is 
> to be able to drop <?CategoryPage ?> on any page you wish to represent a 
> category in order to replicate boilerplate text that describes how it 
> works for a newbie.
> 
> All of this would probably be unnecessary for people who know a lot 
> about how Phpwiki works (specifically: searching, creating pages, and 
> backlinks), but I am specifically trying to design our site for casual 
> users who don't care about wikis. I plan to try to attract many of them 
> (potentially hundreds or thousands) to rate restaurants, research 
> papers, movies, etc.

>> Thanks for your response! I assume you meant to add your suggested 
>> code into the CreatePage plug-in, then add the template itself as a 
>> Wiki page. I like the fact that yours is not restricted by GET length, 
>> and that it is editable by end-users. I also agree that introducing 
>> quoting into expandArgs() is a bold move that one would like to avoid 
>> if possible.
>>
>> The potential issue for me is that the template itself might have to 
>> be programmatically generated. Thus, I don't want "[Restaurant]" in 
>> general, but, "[" . "[pagename]" . "]", so that I can drop a simple 
>> statement (currently a CategoryPage plugin) that has a "CreatePage" 
>> button on "[Restaurant]" that refers back to [Restaurant] and drop 
>> that same CategoryPage plugin without mods onto "[ResearchPaper]" and 
>> its "CreatePage" button refers back to "[ResearchPaper]". I am not 
>> describing it very well in English. For an example, please see:
>>
>> http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/Restaurant
>> http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/ResearchPaper
>> http://dickens.cs.umn.edu/dfrankow/wikilens/
>>
>> I will work with your suggestion and see how it goes. I'd much prefer 
>> to have something you guys are willing to accept as a mod.

> This page represents the category.
> All pages that are in the category refer to this page.
> 
> "BackLinks", 'exclude' => "$EXCLUDE"), _("Show all pages in the 
> $SINGULAR category")); ?>
> 
>    To put a page into the category
> 
>    1. Search to see if it already exists. We don't want lots of
>       duplicate pages. You can use this FuzzyPages search:
> 
>    2. If it does not exist, create the page and save it. You can use
>       this CreatePage button, or see for more ways to navigate or create
>       pages. _printPlugin("<" . "?plugin-form CreatePage
>       initial_content=" . $initial_content . " ?" . ">"); ?>
> 
>    3. Whether you just created it or it already exists, to ensure that
>       the *"Show all pages in the category"* button shows your page, be
>       sure to refer to this page by putting *[]* in your page text
>       somewhere (including the brackets to be safe).
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] edit button

[Smeagol <ge...@li...>]

i'm new in this list

By default anyone accessing my phpwiki can edit text by clicking the
"edit" button. How can i remove this button ? only admin can edit..

Tks a lot

[Phpwiki-talk] wikinames and other conventions

[<jw...@fi...>]

Hello,

I am starting a new phpwiki for newbies.

I have always used the WikiName convention for page naming, but I was
wondering  what you guys think of the [ my page name ] convention.

Is it very bad ? Is it correctly taken into account in the source code ?
Should I stay as far as I can from it and stick to WikiNames ?

Thanks for sharing your experience on that point

J=E9r=F4me

-----Message d'origine-----
De=A0: php...@li...
[mailto:php...@li...] De la part de Malcolm =
Ross
Kinsella Ryan
Envoy=E9=A0: mercredi 17 mars 2004 01:58
=C0=A0: php...@li...
Objet=A0: Re: [Phpwiki-talk] Ready for 1.3.8 ?

On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote:
> Reini Urban wrote:
> >Are we ready for the intermediate 1.3.8 release?
>=20
> Let me join malcolmr in saying:
>=20
> 1. PhpWiki has great potential.
> 2. Releasing something stable is good.
>=20
> Also, I would really like to use some of the things in 1.3.8, e.g.=20
> strong user authentication.
>=20
> I know people asking you to release without doing any work can be=20
> irritating, but you have to take it in the spirit given: you have an=20
> attentive user base.

Thankyou, Dan, for expressing this in a much nicer way than I did.

Eagerly awaiting 1.4,

Malcolm

--=20
Malcolm Ryan - mal...@cs... -
http://www.cse.unsw.edu.au/~malcolmr/

                         "Blessed are those who mourn,
                          for they will be comforted."          -- Matt =
5:4


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] Ready for 1.3.8 ?

[<mal...@cs...>]

On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote:
> Reini Urban wrote:
> >Are we ready for the intermediate 1.3.8 release?
> 
> Let me join malcolmr in saying:
> 
> 1. PhpWiki has great potential.
> 2. Releasing something stable is good.
> 
> Also, I would really like to use some of the things in 1.3.8, e.g. 
> strong user authentication.
> 
> I know people asking you to release without doing any work can be 
> irritating, but you have to take it in the spirit given: you have an 
> attentive user base.

Thankyou, Dan, for expressing this in a much nicer way than I did.

Eagerly awaiting 1.4,

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/

                         "Blessed are those who mourn,
                          for they will be comforted."          -- Matt 5:4

Re: [Phpwiki-talk] Patch for initial_content arg to page editing and CreatePage

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

As background to this discussion, I attach my current version of my 
CategoryPage.php plugin, and the categorypage.tmpl it uses. The idea is 
to be able to drop <?CategoryPage ?> on any page you wish to represent a 
category in order to replicate boilerplate text that describes how it 
works for a newbie.

All of this would probably be unnecessary for people who know a lot 
about how Phpwiki works (specifically: searching, creating pages, and 
backlinks), but I am specifically trying to design our site for casual 
users who don't care about wikis. I plan to try to attract many of them 
(potentially hundreds or thousands) to rate restaurants, research 
papers, movies, etc.

Dan

Dan F wrote:

> Reini Urban wrote:
>
>> Dan F schrieb:
>>
>>> Again, thanks for PhpWiki. Here is another patch (from 1.3.7 more or 
>>> less) to support an "initial_content" argument to my CreatePage 
>>> plug-in. This is so that I can put a "CreatePage" button on a 
>>> category page that creates another page that already has example 
>>> text (the "initial_content" parameter) to refer to the category. I'm 
>>> not sure if this is the right place to post patches; please give me 
>>> more info on this.
>>
>>
>>
>> I'm not sure if we should allow the initial_content GET arg in the 
>> redirect, or just a template argument to take the initial_content 
>> from a existing template page.
>>
>> GET urls are limited in its length. pagenames are no problem.
>
>
>
> Reini,
>
> Thanks for your response! I assume you meant to add your suggested 
> code into the CreatePage plug-in, then add the template itself as a 
> Wiki page. I like the fact that yours is not restricted by GET length, 
> and that it is editable by end-users. I also agree that introducing 
> quoting into expandArgs() is a bold move that one would like to avoid 
> if possible.
>
> The potential issue for me is that the template itself might have to 
> be programmatically generated. Thus, I don't want "[Restaurant]" in 
> general, but, "[" . "[pagename]" . "]", so that I can drop a simple 
> statement (currently a CategoryPage plugin) that has a "CreatePage" 
> button on "[Restaurant]" that refers back to [Restaurant] and drop 
> that same CategoryPage plugin without mods onto "[ResearchPaper]" and 
> its "CreatePage" button refers back to "[ResearchPaper]". I am not 
> describing it very well in English. For an example, please see:
>
> http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/Restaurant
> http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/ResearchPaper
> http://dickens.cs.umn.edu/dfrankow/wikilens/
>
> I will work with your suggestion and see how it goes. I'd much prefer 
> to have something you guys are willing to accept as a mod.
>
> Thanks again.
>
> Dan Frankowski
>
> P.S. My patch to expandArg() didn't work quite right anyway because of 
> the regexp. Just FYI I attach a new patch:
>
> diff -b -u -r1.1 -r1.3
> --- lib/WikiPlugin.php  29 Jan 2004 14:30:27 -0000      1.1
> +++ lib/WikiPlugin.php  16 Mar 2004 20:13:04 -0000      1.3
>
> ...
>
> +    // Expand [arg] to $request->getArg("arg") unless preceded by ~
>     function expandArg($argval, $request) {
> -        return preg_replace('/\[(\w[\w\d]*)\]/e', 
> '$request->getArg("$1")',
> +        // Replace the arg unless it is preceded by a ~
> +        $ret = preg_replace('/([^~]|^)\[(\w[\w\d]*)\]/e',
> +                            '"$1" . $request->getArg("$2")',
>                             $argval);
> +
> +        // Ditch the ~ so later versions can be expanded if desired
> +        return preg_replace('/~(\[\w[\w\d]*\])/', '$1', $ret);
>     }
>
>     function parseArgStr($argstr) {
>
>
>
>
>>
>>> In particular, I changed WikiPlugin->expandArg() so that it allows 
>>> quoting (via ~) of "[Restaurant]" (which would normally be evaluated 
>>> to the "Restaurant" arg of a request, which probably doesn't exist). 
>>> This allows me to put sufficient ~s in front of "[Restaurant]" to 
>>> allow it to pass through multiple layers of expansion (one ~ 
>>> dissappears through each layer). I hope changes such as these can be 
>>> accepted into the codebase.
>>
>>
>>
>> Just to support "[...]" in the initial_content param?
>> Hmm, why not accept the template arg, which seems to be easier.
>>
>>     function getDefaultArguments() {
>>         return array('s'            => false,
>>                      'template'     => false);
>>     }
>> ...
>>
>>         if ($template and $dbi->isWikiPage($template)) {
>>             $page = $dbi->getPage($template);
>>             $current = $page->getCurrentRevision();
>>             $version = $current->getVersion();
>>             $initial_content = $current->getPackedContent();
>>         }
>> ...
>

Re: [Phpwiki-talk] Patch for initial_content arg to page editing and CreatePage

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

Reini Urban wrote:

> Dan F schrieb:
>
>> Again, thanks for PhpWiki. Here is another patch (from 1.3.7 more or 
>> less) to support an "initial_content" argument to my CreatePage 
>> plug-in. This is so that I can put a "CreatePage" button on a 
>> category page that creates another page that already has example text 
>> (the "initial_content" parameter) to refer to the category. I'm not 
>> sure if this is the right place to post patches; please give me more 
>> info on this.
>
>
> I'm not sure if we should allow the initial_content GET arg in the 
> redirect, or just a template argument to take the initial_content from 
> a existing template page.
>
> GET urls are limited in its length. pagenames are no problem.


Reini,

Thanks for your response! I assume you meant to add your suggested code 
into the CreatePage plug-in, then add the template itself as a Wiki 
page. I like the fact that yours is not restricted by GET length, and 
that it is editable by end-users. I also agree that introducing quoting 
into expandArgs() is a bold move that one would like to avoid if possible.

The potential issue for me is that the template itself might have to be 
programmatically generated. Thus, I don't want "[Restaurant]" in 
general, but, "[" . "[pagename]" . "]", so that I can drop a simple 
statement (currently a CategoryPage plugin) that has a "CreatePage" 
button on "[Restaurant]" that refers back to [Restaurant] and drop that 
same CategoryPage plugin without mods onto "[ResearchPaper]" and its 
"CreatePage" button refers back to "[ResearchPaper]". I am not 
describing it very well in English. For an example, please see:

http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/Restaurant
http://dickens.cs.umn.edu/dfrankow/wikilens/index.php/ResearchPaper
http://dickens.cs.umn.edu/dfrankow/wikilens/

I will work with your suggestion and see how it goes. I'd much prefer to 
have something you guys are willing to accept as a mod.

Thanks again.

Dan Frankowski

P.S. My patch to expandArg() didn't work quite right anyway because of 
the regexp. Just FYI I attach a new patch:

diff -b -u -r1.1 -r1.3
--- lib/WikiPlugin.php  29 Jan 2004 14:30:27 -0000      1.1
+++ lib/WikiPlugin.php  16 Mar 2004 20:13:04 -0000      1.3

...

+    // Expand [arg] to $request->getArg("arg") unless preceded by ~
     function expandArg($argval, $request) {
-        return preg_replace('/\[(\w[\w\d]*)\]/e', '$request->getArg("$1")',
+        // Replace the arg unless it is preceded by a ~
+        $ret = preg_replace('/([^~]|^)\[(\w[\w\d]*)\]/e',
+                            '"$1" . $request->getArg("$2")',
                             $argval);
+
+        // Ditch the ~ so later versions can be expanded if desired
+        return preg_replace('/~(\[\w[\w\d]*\])/', '$1', $ret);
     }

     function parseArgStr($argstr) {




>
>> In particular, I changed WikiPlugin->expandArg() so that it allows 
>> quoting (via ~) of "[Restaurant]" (which would normally be evaluated 
>> to the "Restaurant" arg of a request, which probably doesn't exist). 
>> This allows me to put sufficient ~s in front of "[Restaurant]" to 
>> allow it to pass through multiple layers of expansion (one ~ 
>> dissappears through each layer). I hope changes such as these can be 
>> accepted into the codebase.
>
>
> Just to support "[...]" in the initial_content param?
> Hmm, why not accept the template arg, which seems to be easier.
>
>     function getDefaultArguments() {
>         return array('s'            => false,
>                      'template'     => false);
>     }
> ...
>
>         if ($template and $dbi->isWikiPage($template)) {
>             $page = $dbi->getPage($template);
>             $current = $page->getCurrentRevision();
>             $version = $current->getVersion();
>             $initial_content = $current->getPackedContent();
>         }
> ...
>

Re: [Phpwiki-talk] Patch for initial_content arg to page editing and CreatePage

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

Dan F schrieb:
> Again, thanks for PhpWiki. Here is another patch (from 1.3.7 more or 
> less) to support an "initial_content" argument to my CreatePage plug-in. 
> This is so that I can put a "CreatePage" button on a category page that 
> creates another page that already has example text (the 
> "initial_content" parameter) to refer to the category. I'm not sure if 
> this is the right place to post patches; please give me more info on this.

I'm not sure if we should allow the initial_content GET arg in the 
redirect, or just a template argument to take the initial_content from a 
existing template page.

GET urls are limited in its length. pagenames are no problem.

> In particular, I changed WikiPlugin->expandArg() so that it allows 
> quoting (via ~) of "[Restaurant]" (which would normally be evaluated to 
> the "Restaurant" arg of a request, which probably doesn't exist). This 
> allows me to put sufficient ~s in front of "[Restaurant]" to allow it to 
> pass through multiple layers of expansion (one ~ dissappears through 
> each layer). I hope changes such as these can be accepted into the 
> codebase.

Just to support "[...]" in the initial_content param?
Hmm, why not accept the template arg, which seems to be easier.

     function getDefaultArguments() {
         return array('s'            => false,
                      'template'     => false);
     }
...

         if ($template and $dbi->isWikiPage($template)) {
             $page = $dbi->getPage($template);
             $current = $page->getCurrentRevision();
             $version = $current->getVersion();
             $initial_content = $current->getPackedContent();
         }
...

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

[Phpwiki-talk] Patch for initial_content arg to page editing and CreatePage

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

Folks,

Again, thanks for PhpWiki. Here is another patch (from 1.3.7 more or 
less) to support an "initial_content" argument to my CreatePage plug-in. 
This is so that I can put a "CreatePage" button on a category page that 
creates another page that already has example text (the 
"initial_content" parameter) to refer to the category. I'm not sure if 
this is the right place to post patches; please give me more info on this.

In particular, I changed WikiPlugin->expandArg() so that it allows 
quoting (via ~) of "[Restaurant]" (which would normally be evaluated to 
the "Restaurant" arg of a request, which probably doesn't exist). This 
allows me to put sufficient ~s in front of "[Restaurant]" to allow it to 
pass through multiple layers of expansion (one ~ dissappears through 
each layer). I hope changes such as these can be accepted into the codebase.

Thanks for your attention.

Dan

-- 
Dan Frankowski    dfr...@cs...      612-626-8396


Patches for support of CreatePage with initial content:

cvs diff -u -b lib/editpage.php
Index: lib/editpage.php
===================================================================
RCS file: /project/Grouplens/cvs-repository/phpwiki/lib/editpage.php,v
retrieving revision 1.1.1.1
diff -u -b -r1.1.1.1 editpage.php
--- lib/editpage.php    29 Jan 2004 14:30:27 -0000      1.1.1.1
+++ lib/editpage.php    12 Mar 2004 22:13:18 -0000
@@ -42,6 +42,13 @@
         else {
             $this->_initializeState();
             $this->_initialEdit = true;
+
+            $initial_content = $request->getArg('initial_content');
+            if ($initial_content) {
+                // The edit request has specified some initial content for
+                // the page if it doesn't exist.  Use that content.
+                $this->_content = $initial_content;
+            }
         }

         header("Content-Type: text/html; charset=" . CHARSET);





% cvs diff -u -b lib/WikiPlugin.php
Index: lib/WikiPlugin.php
===================================================================
RCS file: /project/Grouplens/cvs-repository/phpwiki/lib/WikiPlugin.php,v
retrieving revision 1.1.1.1
diff -u -b -r1.1.1.1 WikiPlugin.php
--- lib/WikiPlugin.php  29 Jan 2004 14:30:27 -0000      1.1.1.1
+++ lib/WikiPlugin.php  16 Mar 2004 16:12:01 -0000
@@ -121,9 +121,13 @@
         return $args;
     }

+    // Expand [arg] to $request->getArg("arg") unless preceded by ~
     function expandArg($argval, $request) {
-        return preg_replace('/\[(\w[\w\d]*)\]/e', '$request->getArg("$1")',
+        // Replace the arg unless it is preceded by a ~
+        $ret = preg_replace('/[^~]\[(\w[\w\d]*)\]/e', '$request->getArg("$1")',
                             $argval);
+        // Ditch the ~ so later versions can be expanded if desired
+        return preg_replace('/~(\[\w[\w\d]*\])/', '$1', $ret);
     }

     function parseArgStr($argstr) {

Re: [Phpwiki-talk] Localisation of content pages / wiki words?

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

Reini Urban schrieb:
> I decided now to write a _WikiTranslation plugin, which helps
> * on translating strings,
> * pages - by using an external translator (Google) -, and
> * displaying the translation matrix for certain lists,
>   like pages, buttons, plugins and all wikiwords.

It's in CVS as plugin/_WikiTranslation.php
Should be at the demo site tomorrow Pacific Time
(0 am pacific time or 9:00 CET).

_WikiTranslation:  Display pagenames and other strings in
various languages. Can also be used to let a favorite translation 
service translate a whole page. Current favorite: translate.google.com 
if from_lang = en or fr

Examples:
  <?plugin _WikiTranslation page=HomePage languages=fr ?>
     Translation service for HomePage into french (redirect
     to translate.google.com)
  <?plugin _WikiTranslation what=pages ?>
     Translation matrix of all pages with proper translations
     (all pages in pgsrc)
  <?plugin _WikiTranslation what=wikiwords match="W*" limit=20 ?>
     Translation matrix of the first 20 wikiwords matching "W*"
  <?plugin _WikiTranslation string=HomePage languages=fr,de,sv ?>
     Translation matrix for all given languages
  <?plugin _WikiTranslation string=HomePage ?>
     Translation matrix for all supported languages
  <?plugin _WikiTranslation string=HomePage languages=fr ?>
     Just return the translated string for this language.

What I want to add is a link in the matrix to let users suggest 
translations online to ease localisation.
This would help the wikiadmin to add needed strings to locale/$lang.po

 > But no locale redirector yet, though I think it's a cool idea.

Mediawiki (wikipedia) uses it's own db table for the page translation 
matrix and uses its own syntax to link to a different language.

We could make use of the _WikiTranslation helpers and define special 
interwiki monikers for translated pages, similar to the magic "Upload:" 
moniker. I think this would be the most transparent method.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki not running with php as cgi

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

On Mon, Mar 15, 2004 at 03:54:59PM +0100, Benjamin Thelen wrote:
> I don't know what COMPRESS_OUTPUT is, I'd like to check that. Where do 
> I force this?

In 1.3.7, it's in index.php (uncomment the appropriate define).  Prior to
that (1.3.4, for instance) there's no define, but the code is in
lib/Request.php somewhere - search for "ob_gzhandler" and you'll find it,
comment it out or give it an early return or something.

- Matt

Re: [Phpwiki-talk] phpwiki not running with php as cgi

[Benjamin T. <th...@cc...>]

Matthew Palmer wrote:

> On Mon, Mar 15, 2004 at 12:37:58PM +0100, Benjamin Thelen wrote:
> 
>>Reini Urban wrote:
>>
>>>Benjamin Thelen schrieb:
>>>
>>>
>>>>Parse error: parse error in /usr/local/www/cgi-bin-dist/php on line 6265
>>>>
>>>>Other php4 script based software like phpMyAdmin are running fine for 
>>>>example.
> 
> 
> This may or may not be relevant to your situation, but I've gotten reports
> (as the Debian PHPWiki maintainer) that turning off output compression does
> the job.  No idea why, but there you go.  (This was in relation to PHPWiki
> not running as a CGI in Apache 2, though, so that might be part of it).
> 
> If you force COMPRESS_OUTPUT to false, what happens?
> 
> 
>>I checked three versions of phpwiki: 1.2.2 / 1.3.4 and 1.3.7
> 
> 
> Hmm, that would suggest that output compression may not be the problem,
> then, although I don't know what version of PHPWiki started doing
> compression.
> 
> Probably won't help, but the CGI thing triggered that memory.
> 
> - Matt
> 
Thanks Matt!

I don't know what COMPRESS_OUTPUT is, I'd like to check that. Where do 
I force this?

Ben

Re: [Phpwiki-talk] phpwiki not running with php as cgi

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

On Mon, Mar 15, 2004 at 12:37:58PM +0100, Benjamin Thelen wrote:
> Reini Urban wrote:
> >Benjamin Thelen schrieb:
> >
> >>Parse error: parse error in /usr/local/www/cgi-bin-dist/php on line 6265
> >>
> >>Other php4 script based software like phpMyAdmin are running fine for 
> >>example.

This may or may not be relevant to your situation, but I've gotten reports
(as the Debian PHPWiki maintainer) that turning off output compression does
the job.  No idea why, but there you go.  (This was in relation to PHPWiki
not running as a CGI in Apache 2, though, so that might be part of it).

If you force COMPRESS_OUTPUT to false, what happens?

> I checked three versions of phpwiki: 1.2.2 / 1.3.4 and 1.3.7

Hmm, that would suggest that output compression may not be the problem,
then, although I don't know what version of PHPWiki started doing
compression.

Probably won't help, but the CGI thing triggered that memory.

- Matt

Re: [Phpwiki-talk] phpwiki not running with php as cgi

[Benjamin T. <th...@cc...>]

Reini Urban wrote:

> Benjamin Thelen schrieb:
> 
>> Parse error: parse error in /usr/local/www/cgi-bin-dist/php on line 6265
>>
>> Other php4 script based software like phpMyAdmin are running fine for 
>> example.
> 
> 
> Last time I tested it ran okay as CGI.
> 
> Can you please provide the error_log entry,
> because the error line above doesn't tell us anything meaningful.


Hello,

thanks for response.

I used http://www.macdevcenter.com/pub/a/mac/2003/06/05/wiki.html as 
installation help.

I checked three versions of phpwiki: 1.2.2 / 1.3.4 and 1.3.7

Initializing of all three versions seem to run well, but a look into 
the httpd-error.log shows the following error messages (only for the 
1.3.x versions!).

[Mon Mar 15 12:16:14 2004] [error] [client 192.168.2.109] script not 
found or unable to stat: /usr/local/www/cgi-bin/themes
[Mon Mar 15 12:16:14 2004] [error] [client 192.168.2.109] script not 
found or unable to stat: /usr/local/www/cgi-bin/themes
[Mon Mar 15 12:16:14 2004] [error] [client 192.168.2.109] script not 
found or unable to stat: /usr/local/www/cgi-bin/themes
[Mon Mar 15 12:16:14 2004] [error] [client 192.168.2.109] script not 
found or unable to stat: /usr/local/www/cgi-bin/themes
[Mon Mar 15 12:16:14 2004] [error] [client 192.168.2.109] script not 
found or unable to stat: /usr/local/www/cgi-bin/themes
[Mon Mar 15 12:16:14 2004] [error] [client 192.168.2.109] script not 
found or unable to stat: /usr/local/www/cgi-bin/themes

This bunch occurs everytime I call 
"http://192.168.2.90/phpwiki/index.php" in a browser (Only version 
1.3.x!). The intro page is shown, but every link I click causes the 
parser error (1.2.2 & 1.3.4). The difference in version 1.3.7 is, that 
the intro page is empty (<html><body></body></html>)!

At the end of the initialization the following notic is shown:

(version 1.3.4)
lib/loadsave.php:446: Notice[1024]: Loading InterWikiMap from external 
file lib/interwiki.map.

(version 1.3.7)
lib/loadsave.php:516: Notice[1024]: Loading InterWikiMap from external 
file lib/interwiki.map


System:
FreeBSD 4.9
Apache 1.3.29
php 4.3.4 with the following compiling options:

'./configure' '--enable-versioning' '--enable-memory-limit' 
'--with-layout=GNU' '--with-zlib-dir=/usr' '--disable-all' 
'--with-regex=system' '--disable-cli' '--enable-ctype' 
'--with-curl=/usr/local' '--enable-dbase' '--with-dom=/usr/local' 
'--with-gd' '--enable-gd-native-ttf' '--enable-gd-jis-conv' 
'--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' 
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' 
'--with-xpm-dir=/usr/local' '--with-mysql=/usr/local' 
'--enable-overload' '--with-pcre-regex=yes' '--enable-posix' 
'--with-pgsql=/usr/local' '--enable-session' '--enable-tokenizer' 
'--with-expat-dir=/usr/local' '--enable-xml' '--with-zlib=yes' 
'--prefix=/usr/local' 'i386-portbld-freebsd4.9'


Two specials are that I use --with-regex=system and do NOT use 
--enable-discard-path.

The relevant entries in httpd.conf are

     AddType application/x-httpd-php .php
     Action application/x-httpd-php /cgi-bin/php


I very much hope, that the information I supply is helpful for you.

Thank you very much for your help.

Benjamin

Re: [Phpwiki-talk] crao theme

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

Le dim 14/03/2004 =E0 11:27, Reini Urban a =E9crit :

> May we distribute your crao theme with PhpWiki?
> Could you package it?

As I already told you : yes

> The png buttons will have to be renamed to english,
> since they are not locale-specific, but everything else
> seems to be okay.

About le buttons, I had to link most of them into the fr directory
(CraoWiki's locale is fr_FR) ... I think the locale stuff still has some
problems ...=20
Your translation plugin should help a lot ...
--=20
Arnaud Fontaine
Jabber: sh...@ra...
ICQ: 3504789

Re: [Phpwiki-talk] Localisation of content pages / wiki words?

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

I decided now to write a _WikiTranslation plugin, which helps
* on translating strings,
* pages - by using an external translator (Google) -, and
* displaying the translation matrix for certain lists,
   like pages, buttons, plugins and all wikiwords.

But no locale redirector yet, though I think it's a cool idea.

Norberto Meijome schrieb:
> I thought of a dictionary lookup, but I thought it was overkill--at 
> least for my needs.
> Virtual paths would be cool if I would have every page translated... 
> IMHO, it would be handy to present the translated version if it existed, 
> or the default if that was the only one...growing on a per case basis.
> 
> Do you mind me asking why " don't do it with plugins"?
> 
> TIA,
> Beto
> 
> Reini Urban wrote:
> 
>> we came to this conclusion: don't do it with plugins.
>> we do it with virtual paths on 
>> http://phpwiki.sf.net/demo/(en|de|es|fr|...)/ and do the linking 
>> manually.
>>
>> of course it would be fine to have a tool which helps in localizing 
>> new wikipages by lookup in a wikiword dictionary.
>>
>>
>> Norberto Meijome schrieb:
>>
>>> Hi list,
>>> Is there a plugin to aid with *content / wikiwords* localisation? 
>>> Auto-translation of wikiwords was a passing thought...but riddled 
>>> with problems.
>>>
>>> I know pgsrc has been localised to several languages (I'll be glad to 
>>> help with Spanish, BTW), but I'm looking for something that will help 
>>> visitors see the version of a page in the correct language.
>>>
>>> (excuse my poor knowledge of plugin syntax and phylosophy in the 
>>> following examples...)
>>> something like...
>>>
>>> <?plugin LocalisedVersion Lang="en-*" default="yes">
>>> [ALL TEXT FOR ALL ENGLISH LOCALES  HERE]
>>> <?plugin LocalisedVersion Lang="es-*">
>>> [ALL THE TEXT FOR SP LOCALES HERE]
>>>
>>> etc.
>>> and only the right text would show depending on your language.
>>> Notes : how to manage editing? show everything? enhance editing so 
>>> that only you get to edit the language you are seeing? that could be 
>>> problematic with versioning...maybe?
>>>
>>> Or maybe a combination of language detection and http redirection. 
>>> Say, in AWikiPage
>>>
>>> <?plugin LocalisedVersionRedirect Lang="en-*" 
>>> WikiWord="AWikiPageEnglish">
>>> <?plugin LocalisedVersionRedirect Lang="es-*" WikiWord="MiPaginaWiki">
>>>
>>> Note: how to handle defaults? maybe all in one plugin declaration?:
>>>
>>> <?plugin LocalisedVersionRedirect Values="[en-*, AWikiPageEnglish, 
>>> es-*,MiPaginaWeb,ab-*, HowDoYouSayWikiPageInArabic]" default="en-*" >
>>>
>>> ( or default="DefaultPageForNewLanguage").
>>>
>>> Or even better, include instead of redirection...
>>>
>>> Any suggestions on how to best implement this if not implemented yet? 
>>> I'm happy to do it :-)
>>>
>>> Best regards,
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] crao theme

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

Arnaud Fontaine schrieb:
> Le mer 10/03/2004 à 13:43, Roland a écrit :
>>>>Is there any french speakers here? To validate my translation and test?
>>
>>Si tu veux je peux te faire une relecture, je n'ai pas le temps en ce 
>>moment de poursuivre la trad...
> 
> Je peux aussi relire et filer un coup de main.
> Tu peux aussi poster les trad. des pgsrc sur CraoWiki ... la trad.
> collaborative marche bien là bas :) (http://wiki.crao.net/)

Arnaud,
http://wiki.crao.net/ has a really good and easy and I18N layout.
Easier to translate than MacOSX.

May we distribute your crao theme with PhpWiki?
Could you package it?

The png buttons will have to be renamed to english,
since they are not locale-specific, but everything else
seems to be okay.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Ready for 1.3.8 ?

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

Le mer 10/03/2004 =E0 13:43, Roland a =E9crit :

> >> Is there any french speakers here? To validate my translation and test=
?
>=20
> Si tu veux je peux te faire une relecture, je n'ai pas le temps en ce=20
> moment de poursuivre la trad...

Je peux aussi relire et filer un coup de main.
Tu peux aussi poster les trad. des pgsrc sur CraoWiki ... la trad.
collaborative marche bien l=E0 bas :) (http://wiki.crao.net/)
--=20
Arnaud Fontaine
Jabber: sh...@ra...
ICQ: 3504789

[Phpwiki-talk] IncludeSiteMap and the page cache

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

Another note - Editing and Saving the page (with any trivial change) 
recycles the process. You'll see it, but the next time you go back 
you won't.

Thanks!
Micki

>It appears that after a page containing an IncludeSiteMap statement 
>is loaded into the browser once (successfully), further views of 
>that page are missing the previously visible IncludeSiteMap's 
>plugin's output.
>
>Cache issues?
>
>Thanks,
>Micki
-- 

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

[Phpwiki-talk] IncludeSiteMap and the page cache

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

It appears that after a page containing an IncludeSiteMap statement 
is loaded into the browser once (successfully), further views of that 
page are missing the previously visible IncludeSiteMap's plugin's 
output.

Cache issues?

Thanks,
Micki
-- 

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