phpwiki-talk

[Phpwiki-talk] PhpWiki Security

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

The machine that runs wikilens.org was hacked through an old unpatched 
instance of PhpBB2.

This delayed our release of MoonBadger, which by the way Reini, has a 
few primitive auto-complete textboxes, though not through the cool 
server-side XML-RPC. We'd love that, although it would require PhpWiki 
responding quickly. I don't know performance now, but our pages are 
around 1s, pretty slow for autocomplete, although page render is 
probably more work than returning a few autocomplete results.

Aside from that, it made me wonder about the security of PhpWiki. If I 
get hacked again, our systems support will frown at me even more, and we 
have several PhpWikis running, some externally visible (like wikilens). 
Are there known exploits in 1.3.7 or 1.3.9? Has somebody thought about 
security? Is there a writeup somewhere I can read?

Thanks in advance.

Dan

[Phpwiki-talk] upgrade problems...

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

Reini,
  I'm having a few problems upgrading to the latest cvs version.  They seem
to be related to stricter database schemas.

  My first problem is the new unique index on page.pagename.  It seems that
I have several pages that differ only in case.

  The second is the page.id auto-increment flag.  I'm having trouble with a
duplicate ID (even though it's a primary key) and I can't seem to find the
duplicate :-)

  I don't think you can do anything about the second problem, but others may
run into the first one and you might be able to address that in the upgrade
action.

  How stable and complete is the CVS head now-a-days?  Do you have any major
areas that you know don't work?

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.

[Phpwiki-talk] RFE - form autocompletion

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

just detected this, using google suggest:
     http://www.google.com/webhp?complete=1&hl=en

"RFE - Form Autocompletion"
http://serversideguy.blogspot.com/2004/12/google-suggest-dissected.html

We'd need a new xml-rpc function to return simple queries in
javascript src: titlesearch, username, plugins, categories, and such.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] possible cache corruption in lib/WikiDB.php

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

Charles Corrigan schrieb:
> I am looking into the security problems that I (and others) have reported
> with security (owners, permissions) on pages when using a MySQL database.
> 
> The specific test case that I have is
> pre-condition - brand new/freshly created database
> 1 - login as administrator
> 2 - go to /PhpWikiAdministration/Chown
> 3 - select page RichTablePlugin (as it is owned by ReiniUrban and not by
> the administrator)
> 4 - click "Chown Selected Pages"
> 5 - confirm
> 6 - go to /RichTablePlugin to see that the owner has been changed
> 7 - go back to /PhpWikiAdministration/Chown and see that RichTablePlugin
> is apparently owned by ReiniUrban
> 8 - go to /RichTablePlugin to see that RichTablePlugin is apparently owned
> by the administrator
> 9 - go back to /PhpWikiAdministration/Chown change the owner of
> RichTablePlugin to the administrator again - but this time nothing happens
> 
> It appears that during the population of the cache with all of the pages
> for the PageList, the cache or the intermediate data that is put into the
> cache is corrupted, somewhere between
>     WikiDB_cache->get_versiondata() - line 2051
> and the return from this into
>     WikiDB_page->getRevision() - line 1123
> 
> I am using the dbg debugger under phpeclipse so the specific location of
> the error report may be an artefact of the tools that I am using. 
> However, I have repeated this test case in several different environments
> with different versions of php, apache and mysql, running both on Unix and
> on Windows.

yep, I know. It's on my todo list also.

* pagedata_cache on PageGroupTest/subpage
   wrong PhpWikiAdmin/Chown owner display

Maybe you'll find it. I'm quite busy with another project.

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

[Phpwiki-talk] possible cache corruption in lib/WikiDB.php

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

I am looking into the security problems that I (and others) have reported
with security (owners, permissions) on pages when using a MySQL database.

The specific test case that I have is
pre-condition - brand new/freshly created database
1 - login as administrator
2 - go to /PhpWikiAdministration/Chown
3 - select page RichTablePlugin (as it is owned by ReiniUrban and not by
the administrator)
4 - click "Chown Selected Pages"
5 - confirm
6 - go to /RichTablePlugin to see that the owner has been changed
7 - go back to /PhpWikiAdministration/Chown and see that RichTablePlugin
is apparently owned by ReiniUrban
8 - go to /RichTablePlugin to see that RichTablePlugin is apparently owned
by the administrator
9 - go back to /PhpWikiAdministration/Chown change the owner of
RichTablePlugin to the administrator again - but this time nothing happens

It appears that during the population of the cache with all of the pages
for the PageList, the cache or the intermediate data that is put into the
cache is corrupted, somewhere between
    WikiDB_cache->get_versiondata() - line 2051
and the return from this into
    WikiDB_page->getRevision() - line 1123

I am using the dbg debugger under phpeclipse so the specific location of
the error report may be an artefact of the tools that I am using. 
However, I have repeated this test case in several different environments
with different versions of php, apache and mysql, running both on Unix and
on Windows.

regards,
Charles

Re: [Phpwiki-talk] How to keep ALL in phpwiki

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

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> Reini Urban wrote:
>>
>>> Arnaud Fontaine schrieb:
>>>
>>>> Silly question but ...
>>>>
>>>> What setting should I use to be sure to keep all revision of all 
>>>> pages in a wiki ?
>>>>
>>>> I suddenly realised that a 2 years old wiki has lost ... so many 
>>>> revisions :(
>>>
>>>
>>> MAJOR_MIN_KEEP = 125269879
>>> MINOR_MIN_KEEP = 125269879
>>
>>
>> IMHO this should be the default. Most people don't have enough 
>> traffic to warrant throwing away revisions. If they do, then they can 
>> examine all the keep-revisions knobs and switches more carefully.
>
>
> I believe this also. I did it.


Great!

Dan

Re: [Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

Joel Uckelman schrieb:
> 1. Is there something special I need to to do get 1.3.10 working with Apache 2
> and PHP 4.3? I haven't been able to get the wiki to create a new page
> db, even.

The internal redirect-after-edit is broken.
Make sure that your theme has a valid signature ImageAlias,
and not false.
$WikiTheme->addImageAlias('signature', "Signature.png");

This seems to be a special problem with apache2, but I got nearer in the 
last week.

> 2. I've been thinking a bit about wiki spam lately, mostly because a wiki
> that I host has been getting blasted almost daily for a while now. While
> we very much want to stop the spam, we don't want to require users to login
> because that would discourage casual editing. What I've noticed is that
> virtually all of the spam we see involves a great number of links being added
> to a page, say 100+. On the other hand, I can't think of a time when I've
> added more than 10 links to a page in a single edit. This suggests that
> rejecting (or holding for approval) edits which increase a page's link count
> by more than 10 links would nearly eliminate the spam that lands on this
> particular wiki.

Good idea! I had the same :) It's already in CVS.

DONE:
      *   More then 20 new external links (hardcoded)
          (have to update http://phpwiki.org/WikiSpam)
      *   content patterns by babycart (only php >= 4.3 for now)
          ENABLE_SPAMASSASSIN
          (have to update http://phpwiki.org/SpamAssassinIntegration)
TODO:
      *   IP BlackList
      *   domain blacklist
      *   url patterns

These need a working accesslog (best via sql) and 
WikiAccessRestrictions, which I deferred to 1.3.12
The hairy accesslog code is already done, but the interface and policies 
are missing.

More see http://wikiblacklist.blogspot.com/

> Most of the spam I see on my wiki is in Chinese, while the rest of the wiki
> is mostly English. If I just rejected any edits which introduced numerous
> Chinese characters, that also would do the trick in my case.
> 
> However, I suspect that not all wiki spam is like this, and if my particular
> batch of spammers changed their tactics then such a check would be ineffective.
> Another thing which occurred to me is doing an RBL check on the IP of the
> editing host. This stops tons of email spam at the door; I have a hunch that
> similar results could be achieved using this for a wiki.
> 
> Conclusion: While I doubt that there is a single solution that would work
> well for everyone, I think that everyone could probably find a solution which
> works for them. Hence, it would be useful to have the edit function call a
> configurable edit validator, one where the wiki admin could easily supply
> whatever tests he wants applied to edits.
> 
> Is there already something like this? If not, does anyone else like this
> idea?

See above.

> 3. Small projects: Are there any small projects that the developers more
> regular than myself want done? I expect to have a bit of time this week
> and I have wiki on the brain again.


See http://phpwiki.org/DevelopmentBranch


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

[Phpwiki-talk] 1.3.10 and Apache 2, small projects, wiki spam

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

1. Is there something special I need to to do get 1.3.10 working with Apache 2
and PHP 4.3? I haven't been able to get the wiki to create a new page
db, even.

2. I've been thinking a bit about wiki spam lately, mostly because a wiki
that I host has been getting blasted almost daily for a while now. While
we very much want to stop the spam, we don't want to require users to login
because that would discourage casual editing. What I've noticed is that
virtually all of the spam we see involves a great number of links being added
to a page, say 100+. On the other hand, I can't think of a time when I've
added more than 10 links to a page in a single edit. This suggests that
rejecting (or holding for approval) edits which increase a page's link count
by more than 10 links would nearly eliminate the spam that lands on this
particular wiki.

Most of the spam I see on my wiki is in Chinese, while the rest of the wiki
is mostly English. If I just rejected any edits which introduced numerous
Chinese characters, that also would do the trick in my case.

However, I suspect that not all wiki spam is like this, and if my particular
batch of spammers changed their tactics then such a check would be ineffective.
Another thing which occurred to me is doing an RBL check on the IP of the
editing host. This stops tons of email spam at the door; I have a hunch that
similar results could be achieved using this for a wiki.

Conclusion: While I doubt that there is a single solution that would work
well for everyone, I think that everyone could probably find a solution which
works for them. Hence, it would be useful to have the edit function call a
configurable edit validator, one where the wiki admin could easily supply
whatever tests he wants applied to edits.

Is there already something like this? If not, does anyone else like this
idea?

3. Small projects: Are there any small projects that the developers more
regular than myself want done? I expect to have a bit of time this week
and I have wiki on the brain again.

Re: [Phpwiki-talk] How to keep ALL in phpwiki

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

> Dan Frankowski wrote:
> > Reini Urban wrote:
> >> Arnaud Fontaine schrieb:
> >>> What setting should I use to be sure to keep all revision of all 
> >>> pages in a wiki ?
> >> MAJOR_MIN_KEEP = 125269879
> >> MINOR_MIN_KEEP = 125269879
> > 
> > IMHO this should be the default. Most people don't have enough traffic 
> > to warrant throwing away revisions. If they do, then they can examine 
> > all the keep-revisions knobs and switches more carefully.
> 
> I second that - and I wonder of there should be a better way of 
> expressing it, rather than just using a magic number ... perhaps 0?
> 
> -jim

If I had to guees what number to set it to to get 'unlimited', 0 would be the
one. That's sort of the canonical way to do it.

Re: [Phpwiki-talk] How to keep ALL in phpwiki

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

Jim Cheetham schrieb:
> Dan Frankowski wrote:
>> Reini Urban wrote:
>>> Arnaud Fontaine schrieb:
>>>
>>>> What setting should I use to be sure to keep all revision of all 
>>>> pages in a wiki ?
>>>
>>> MAJOR_MIN_KEEP = 125269879
>>> MINOR_MIN_KEEP = 125269879
>>
>>
>> IMHO this should be the default. Most people don't have enough traffic 
>> to warrant throwing away revisions. If they do, then they can examine 
>> all the keep-revisions knobs and switches more carefully.
> 
> I second that - and I wonder of there should be a better way of 
> expressing it, rather than just using a magic number ... perhaps 0?

I use now in fact INT32_MAX.
I don't want to use -1 because I doubt php's signed integer casting 
abilities and I don't want to add another constant.
There's only CHAR_MAX, but no M_MAXINT or similar.

0 is a bit counter-intuitive; "keep nothing".
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] How to keep ALL in phpwiki

[Jim C. <ji...@in...>]

Dan Frankowski wrote:
> Reini Urban wrote:
>> Arnaud Fontaine schrieb:
>>> What setting should I use to be sure to keep all revision of all 
>>> pages in a wiki ?
>> MAJOR_MIN_KEEP = 125269879
>> MINOR_MIN_KEEP = 125269879
> 
> IMHO this should be the default. Most people don't have enough traffic 
> to warrant throwing away revisions. If they do, then they can examine 
> all the keep-revisions knobs and switches more carefully.

I second that - and I wonder of there should be a better way of 
expressing it, rather than just using a magic number ... perhaps 0?

-jim

Re: [Phpwiki-talk] Showing RecentChanges as part of a regular PHP page

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

James Grimwood schrieb:
> I've got PHPWiki running on my website. It's accessable by clicking on
> a link on my website's main page.
> 
> Is there a way I can grab the contents of the RecentChanges in my wiki
> and show that on my main page too? Just as straight text with links,
> not as a browser sidepanel or embedded in a frame? What I'm trying to
> make is a little sidepanel in my website's main page that shows what's
> recently changed in my wiki, in a similar way to SourceForge's "most
> active" panel on their main page.
> 
> I don't mind poking around in the code and manually constructing glue
> to call PHPWiki functions, but a few pointers about where to start
> would be nice :-)

convert the rss feed to html.
or try the xml-rpc interface.

or as iframe of course, but this will have all the headers and footers also.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] How to keep ALL in phpwiki

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Arnaud Fontaine schrieb:
>>> Silly question but ...
>>>
>>> What setting should I use to be sure to keep all revision of all 
>>> pages in a wiki ?
>>>
>>> I suddenly realised that a 2 years old wiki has lost ... so many 
>>> revisions :(
>>
>> MAJOR_MIN_KEEP = 125269879
>> MINOR_MIN_KEEP = 125269879
> 
> IMHO this should be the default. Most people don't have enough traffic 
> to warrant throwing away revisions. If they do, then they can examine 
> all the keep-revisions knobs and switches more carefully.

I believe this also. I did it.

BTW: This is just a number.
In fact it should be #7fffffff, not #77777777.

$ /usr/lib/php/bin/php.exe -an
Interactive mode enabled

<?php
print_r(0x7fffffff);
Ctrl-D
2147483647
print_r(0x7777777);
Ctrl-D
125269879

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

Re: [Phpwiki-talk] Showing RecentChanges as part of a regular PHP page

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

James Grimwood wrote:

>On Tue, 11 Jan 2005 09:44:20 -0600, Dan Frankowski <dfr...@cs...> wrote:
>
>  
>
>>I'm not exactly sure what you want, but can't you just call the
>>RecentChanges plugin on your HomePage directly? If you go to the
>>    
>>
>
>Ah, guess I didn't explain myself properly... the main page I'm
>referring to is my website's index.php, not phpwiki's HomePage.
>
>And all I really want to do is somehow query the database directly to
>extract the data used on the RecentChanges page, so I can incorporate
>it into a regular, non PHPWiki web page.
>  
>

Seems like a bad idea to query the database directly. You might not 
understand all the subtleties, and if the DB changes, you're screwed. 
Maybe better to write some PHP code (a plugin or extra arg to recent 
changes) within Phpwiki that returns the text you want, then include it 
somehow. Or perhaps that's the frames thing you don't like.

Dan

Re: [Phpwiki-talk] Showing RecentChanges as part of a regular PHP page

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

James Grimwood wrote:

>Hello
>
>I've got PHPWiki running on my website. It's accessable by clicking on
>a link on my website's main page.
>
>Is there a way I can grab the contents of the RecentChanges in my wiki
>and show that on my main page too? Just as straight text with links,
>not as a browser sidepanel or embedded in a frame? What I'm trying to
>make is a little sidepanel in my website's main page that shows what's
>recently changed in my wiki, in a similar way to SourceForge's "most
>active" panel on their main page.
>
>I don't mind poking around in the code and manually constructing glue
>to call PHPWiki functions, but a few pointers about where to start
>would be nice :-)
>  
>

I'm not exactly sure what you want, but can't you just call the 
RecentChanges plugin on your HomePage directly? If you go to the 
"RecentChanges" page, and click "View source" you'll see the plugin 
invocation. Here's mine:

<?plugin RecentChanges days||=7 daylist=1,3,7,30,90, 0 ?>

Just put this text somewhere in your HomePage. Or does that put it in a 
frame or something?

Dan

Re: [Phpwiki-talk] How to keep ALL in phpwiki

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

Reini Urban wrote:

> Arnaud Fontaine schrieb:
>
>> Silly question but ...
>>
>> What setting should I use to be sure to keep all revision of all 
>> pages in a wiki ?
>>
>> I suddenly realised that a 2 years old wiki has lost ... so many 
>> revisions :(
>
>
> MAJOR_MIN_KEEP = 125269879
> MINOR_MIN_KEEP = 125269879


IMHO this should be the default. Most people don't have enough traffic 
to warrant throwing away revisions. If they do, then they can examine 
all the keep-revisions knobs and switches more carefully.

Dan

[Phpwiki-talk] Showing RecentChanges as part of a regular PHP page

[James G. <pi...@gm...>]

Hello

I've got PHPWiki running on my website. It's accessable by clicking on
a link on my website's main page.

Is there a way I can grab the contents of the RecentChanges in my wiki
and show that on my main page too? Just as straight text with links,
not as a browser sidepanel or embedded in a frame? What I'm trying to
make is a little sidepanel in my website's main page that shows what's
recently changed in my wiki, in a similar way to SourceForge's "most
active" panel on their main page.

I don't mind poking around in the code and manually constructing glue
to call PHPWiki functions, but a few pointers about where to start
would be nice :-)

-- 
http://www.piku.org.uk - Outdoor Photos: http://www.piku.co.uk

[Phpwiki-talk] Prettywiki question from newbie

[Ronald R. <ron...@ho...>]

I am running PHPWiki 1.3.6 with Apache 2.x

My URL's are displaying as:
http://servername/index.php?pagename=RecentChanges

when they should show up as:
http://servername/wiki/RecentChanges

as you can guess - with my 1.3.4 to 1.3.6 upgrade, all external links are 
now broken

I have tried adding this to .htaccess ->
  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /wiki/
  RewriteRule ^wiki$       /wiki/HomePage  [R]
  RewriteRule ^wiki/$      /wiki/HomePage  [R]
  RewriteRule ^wiki/(.*)$        /wiki/index.php?pagename=$1     [QSA]
  </IfModule>

Within index.php,  USE_PATH_INFO is set to true.

Only the homepage works, all other links are "Not found'.

Thanks in advance,

Ron

Re: [Phpwiki-talk] How to keep ALL in phpwiki

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

Arnaud Fontaine schrieb:
> Silly question but ...
> 
> What setting should I use to be sure to keep all revision of all pages 
> in a wiki ?
> 
> I suddenly realised that a 2 years old wiki has lost ... so many 
> revisions :(

MAJOR_MIN_KEEP = 125269879
MINOR_MIN_KEEP = 125269879


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

Re: [Phpwiki-talk] putPage/savePage in XML-RPC

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

Le 10 janv. 05, =E0 13:54, Reini Urban a =E9crit :
>
> $LANG should be solved. Just docs update is missing. The current logic=20=

> is rather crude.
> I also added xmlrpc tests to CVS last month.

$LANG is a major problem ... as is the auth problem with XmlRpc (how to=20=

?) and HttpAuth (can be a solution for XmlRpc auth).
>

BTW, here is the putPage xmlrpc method .. to be completed :) It should=20=

be a bit simplier for the current version .. not tested yet.

/** Int putPage(String pagename, String content, String author)
  *
  */
$wiki_dmap['putPage']
=3D array('signature'     =3D>=20
array(array($xmlrpcString,$xmlrpcString,$xmlrpcString,$xmlrpcString)),
         'documentation' =3D> 'put the raw Wiki text of a new version of =
a=20
page',
         'function'      =3D> 'putPage');

function putPage($params)
{
     global $request;
     $ParamPageName =3D $params->getParam(0);
     $ParamContent =3D $params->getParam(1);
     $ParamAuthor =3D $params->getParam(2);
     $pagename =3D short_string_decode($ParamPageName->scalarval());
     $content =3D short_string_decode($ParamContent->scalarval());
     $author =3D short_string_decode($ParamAuthor->scalarval());

     $dbh =3D $request->getDbh();

     $now =3D time();

     $init_meta =3D array('ctime' =3D> $now,
                        'creator' =3D> $author,
                        'creator_id' =3D> $author,
                        );


     $version_meta =3D array('author' =3D> $author,
                           'author_id' =3D> $author,
                           'markup' =3D> 2.0,
                           'summary' =3D> $summary ? $summary : _("New=20=

contribution"), //Yes, I could add summary to the args
                           'mtime' =3D> $now,
                           'pagetype' =3D> 'wikitext',
                           'wikitext' =3D> $init_meta,
                           );

     $page =3D $dbh->getPage($pagename);
     $current =3D $page->getCurrentRevision();

     $version =3D $current->getVersion() + 1;
     $content =3D trim($content);

     $res =3D$page->save($content, $version, $version_meta);

     if ($res) //To be modified : return an INT value ...
         $message =3D "Page $pagename version $version created";
     else
         $message =3D "Problem creating version $version of page=20
$pagename";

     return new xmlrpcresp(short_string($message));

}



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

[Phpwiki-talk] How to keep ALL in phpwiki

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

Silly question but ...

What setting should I use to be sure to keep all revision of all pages 
in a wiki ?

I suddenly realised that a 2 years old wiki has lost ... so many 
revisions :(
--
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

Re: [Phpwiki-talk] Multiple instances - One DB

[Manuel V. <man...@st...>]

Reini Urban wrote:
> Well, my way for gforge intergration would use a project-specific 
> DATABASE_PREFIX, set by the plugin.
> 
> DB: phpwiki
>   tables: project1_page, project1_version, project1_recent, ...
>           project2_page, project2_version, project2_recent, ...
> needs project_name
> you can even use different wiki engines per project.
My first version of the plugin was based on this schema.
But It wasn't accepted by gforge team leader.

> Your id scheme is simplier on the database level.
> DB: phpwiki
>   tables: page (with group_id), version, recent, ...
> needs group_id
> just one engine and one database schema.
> 
> Pro:  * You only have to do structure updates once,
>         and use a new primary index: pagename+id
>       * easier to upgrade to a new phpwiki schema and version.
> Cons: * Seperation into different wiki's is hard.
>       * you cannot do project specific phpwiki updates.
>       * will not by supported by phpwiki OOTB.
>         So gforge sites must patch the WikiDB backends.
> 
> I cannot accept your page.group_id patch into phpwiki.
> It is way to abusive.

There are no problems for me, I can maintain my patch myself: I made it, 
I assume it ;)

> The sql schema will not change anymore for sure.
> Maybe some minor issues with exotic backends have to fixed.

Great, no maintainance operations!

> Major goals are only the request enhancements in main and Request
> (GET => POST for ModeratedPage, maybe edit), check remaining request 
> problems (session, edit + redirect)
> wikiparser fixes for php5 (or output?),
> some remaining theme updates
> configurator for lists

Well, we are close to PhpWiki 1.3.11 that's a good news.

-- 
# VACELET Manuel     manuel.vacelet-abecedaire(at)st(dot)com #
# Tel:  042 6089                          +33 (0)476 92 6089 #
# STMicroelectronics                                         #
# 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE         #

Re: [Phpwiki-talk] customize the "editpage" layout ?

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

Han Xu schrieb:
> I am a newbie. I wanted to use PhpWiki to co-author a website with
> friends. The main change I wanted to is to customize the layout of
> page editing .  I.e.
> 
> 1) The editpage should not only have a big "textarea'",  but include a
> easy-to-fill form consisting of multiple pre-defined  entries.
> 
> 2) One of the entry in the form would be a image file name. i.e. User
> should be able to import a image file and put it on the page.
> 
> First I tried on Phpwiki v1.2.4.  I changed the "textarea" into a form
> by modifying templates/editpage.html.  But i don't how to enable image
> file uploading.
> 
> Then I tried on Phpwiki v1.3.10,   it is SO different with v1.2.4 
> that I cannot easily implement a form in editpage.  So, my questions
> are:
> 
> 1) What is the best (easiest) way to implement a pre-defined form in
> editpage to replace the "edit_textarea". in  v.1.3.10 ?

Do you want to add entries to the edit_textarea, or replace it?

Aynway, you have to fix themes/<yourtheme>/templates/editpage.tmpl 
(which is easy), and fix lib/editpage.php.

editpage in current CVS:
edit getFormElements() to add your forms
and _restoreState() to read your form values and concat it to ->_content.

> 2)  How can I enable image file uploading in v1.2.4 ?  

That's quite a lot of work.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] putPage/savePage in XML-RPC

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

Arnaud Fontaine schrieb:
> Arnaud Fontaine a écrit :
>> Arnaud Fontaine a écrit :
>>> Still seeking and trying ...
>>> Well ... even the createRevision doesn't work ...
>>
>> I tried to call createRevision with the current version number of the 
>> page : no error but no page modification. The crash occurs when I call 
>> it with version +1 (the normal process for a new revision).
> 
> Ok ... I make it work.
> 
> I followed the same meta data build process than WikiBlog plugin and 
> also trim($content) to get rid of any space/tab/return char at the 
> beginning and end of the content sting.
> 
> Well ... I really need to upgrade the 1.3.7 wiki to the last CVS ... as 
> soon as the LANG problem is solved.

$LANG should be solved. Just docs update is missing. The current logic 
is rather crude.
I also added xmlrpc tests to CVS last month.

Just SOAP testing is missing, and doing soap via the native extension if 
it exists, and not via nusoap.
But I delayed this to 1.3.12 (extended blogging features).
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] putPage/savePage in XML-RPC

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

Arnaud Fontaine a écrit :
> Arnaud Fontaine a écrit :
> 
>> Still seeking and trying ...
>>
>> Well ... even the createRevision doesn't work ...
>>
> 
> I tried to call createRevision with the current version number of the 
> page : no error but no page modification. The crash occurs when I call 
> it with version +1 (the normal process for a new revision).
> 

Ok ... I make it work.

I followed the same meta data build process than WikiBlog plugin and 
also trim($content) to get rid of any space/tab/return char at the 
beginning and end of the content sting.

Well ... I really need to upgrade the 1.3.7 wiki to the last CVS ... as 
soon as the LANG problem is solved.
-- 
Arnaud Fontaine
CRAO
Jabber: sh...@ra...