phpwiki-talk

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

[Han Xu <kee...@gm...>]

Hi all,

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 ?
 
2)  How can I enable image file uploading in v1.2.4 ?  

thank you,
Han

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

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

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).

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

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

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

Still seeking and trying ...

Well ... even the createRevision doesn't work ...

Here is the code :


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

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

     $dbh = $request->getDbh();

     $page = $dbh->getPage($pagename);
     $current = $page->getCurrentRevision();
     $meta = $current->_data;
     $meta['summary'] = "XML-RPC Wiki Contrib";
     $version = $current->getVersion();
     //$res = $page->save($content, $version + 1, $meta);
     $formatted = new TransformedText($page, $content, $meta);
     $type = $formatted->getType();
     $meta['pagetype'] = $type->getName();
     $links = $formatted->getWikiPageLinks();
     $version = $version +1;
     $res = $page->createRevision($version, $content, $meta, $links);
     if ($res)
         $message = "Page $pagename version $version created";
     else
         $message = "Problem creating version $version of page $pagename";

     return new xmlrpcresp(short_string($message));

}

One more info : it seems to lock the DB ... I have to restart apache to 
access the wiki again (and only this one, not others ... got plenty 
running on my server).

Arnaud Fontaine a écrit :
> Hi all,
> 
> I wrote a putPage Xml-Rpc method for version 1.3.4 ... it was working 
> perfectly and took the authentification from http ...
> 
> I'm writing another one for version 1.3.7 ... it crashes when running 
> the $page->save method ... and I don't know how manage authentification.
> 
> The 1.3.4 putPage was using the $page->createRevision method.
> 
> Any clue ?
> 
> Oh ... btw, if you have any good idea to debug xml-rpc methods ...


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

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

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

Arnaud Fontaine a écrit :

> The 1.3.4 putPage was using the $page->createRevision method.

hmmm ... while sending the first mail I was writing another version 
using $page->createRevision instead of the save method ... and ... no 
error ...

I still don't know how to pass auth info ...
-- 
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

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

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

Hi all,

I wrote a putPage Xml-Rpc method for version 1.3.4 ... it was working 
perfectly and took the authentification from http ...

I'm writing another one for version 1.3.7 ... it crashes when running 
the $page->save method ... and I don't know how manage authentification.

The 1.3.4 putPage was using the $page->createRevision method.

Any clue ?

Oh ... btw, if you have any good idea to debug xml-rpc methods ...
-- 
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

Re: [Phpwiki-talk] locale_versions() pb in last CVS update

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

Arnaud Fontaine schrieb:
> Arnaud Fontaine a écrit :
>> I have a "Call to undefined function: locale_versions() in the 
>> config.php file since last CVS update ...
>>
>> It's defined in FileFinder but the require_once is commented .... why ?
> 
> Hmm ... I partially answer to myself :
> locale_versions is not a function but a method of the FileFinder class.
> in the function guessing_lang (in config.php), locale_versions is called 
> as a function.

This is a bug. Thanks.
I'm just working on this. It's not ready yet.
LANG should only set if the translated homepage exists.
I have to defer this lang setting to the WikiRequest::initializeLang() 
call in lib/main.php

> I tried to call it as a class method ($languages = 
> FileFinder::locale_versions($languages);) and it almost worked ... now, 
> I have some warning about array to string casting ...
> 
> What did you change, Reini ?

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

Re: [Phpwiki-talk] Help! I'm a newbie! Raw_HTML plugin question

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

Ronald Roche schrieb:
> I am using PHPWiki 1.3.6
> 
> I set ENABLE_RAW_HTML to true within my index.php
> 
> But.....html is STILL only allowed in locked pages.  I need RAW_HTML to 
> work in unlocked pages.
> 
> What do I do?
> This is not for a public Wiki.

Disable the check?

lib/plugin/RawHtml.php

-- 
Reini Urban
http://phpwiki.org/

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

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

Manuel VACELET a écrit :
> Reini Urban wrote:
> 
>> I'll have a look after 1.3.11 but I still see no technical reason, why 
>> this should be better than tablename prefixes. Merging all the 
>> seperate table sets into one big mess...
> 
> 
> I agree, it's not technical reasons.
> I just "fell" it not very elegant (tables multiplications).

Well ... your sql server will try to load the full table in memory. If 
it's too big, it won't be able to.

With more smaller tables, that means more "context switching" ... but 
more chance to have the "current" table fully loaded in memory ...

On a single very big table for your wiki farm, you'll also have bigger 
indexes to load, etc, etc ... that means slower operations.

You should benchmark the two solutions with some real life data ...
-- 
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

Re: [Phpwiki-talk] locale_versions() pb in last CVS update

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

Arnaud Fontaine a écrit :
> I have a "Call to undefined function: locale_versions() in the 
> config.php file since last CVS update ...
> 
> It's defined in FileFinder but the require_once is commented .... why ?

Hmm ... I partially answer to myself :

locale_versions is not a function but a method of the FileFinder class.

in the function guessing_lang (in config.php), locale_versions is called 
as a function.

I tried to call it as a class method ($languages = 
FileFinder::locale_versions($languages);) and it almost worked ... now, 
I have some warning about array to string casting ...

What did you change, Reini ?

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

[Phpwiki-talk] Help! I'm a newbie! Raw_HTML plugin question

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

I am using PHPWiki 1.3.6

I set ENABLE_RAW_HTML to true within my index.php

But.....html is STILL only allowed in locked pages.  I need RAW_HTML to work 
in unlocked pages.

What do I do?

This is not for a public Wiki.

Thanks in advance,

Ron

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

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

Manuel VACELET schrieb:
> Reini Urban wrote:
> 
>> I'll have a look after 1.3.11 but I still see no technical reason, why 
>> this should be better than tablename prefixes. Merging all the 
>> seperate table sets into one big mess...
> 
> I agree, it's not technical reasons.
> I just "fell" it not very elegant (tables multiplications).
> 
>> Other than helping administrative SQL tasks outside the wiki maybe. 
>> Schema upgrades are done now via action=upgrade.
>> But a simple mysql script is also easy, looping over all existing 
>> prefixes. Should I provide such a script for wikifarm schema upgrades?
> 
> I think that wikifarm users are able to do their own upgrades.
> 
>> But for gforge integration it is really not needed.
> 
> I discuss very long time with Christian Bayle from gforge team and we 
> have the same felling: "multiplication of tables is bad" but without 
> rational facts to justify our feeling.
> 
> Current way of phpwiki integration under gforge is to have only one wiki 
> and each project create pages into this big wiki. My way is to provide 
> one independent wiki for each project.

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.

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.

> Current state seems to work (around 1 month of tests without any 
> problems) but I prefer waiting for phpwiki 1.3.11 release before release 
> the plugin.

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

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
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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

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

Reini Urban wrote:
> I'll have a look after 1.3.11 but I still see no technical reason, why 
> this should be better than tablename prefixes. Merging all the seperate 
> table sets into one big mess...

I agree, it's not technical reasons.
I just "fell" it not very elegant (tables multiplications).

> Other than helping administrative SQL tasks outside the wiki maybe. 
> Schema upgrades are done now via action=upgrade.
> But a simple mysql script is also easy, looping over all existing 
> prefixes. Should I provide such a script for wikifarm schema upgrades?

I think that wikifarm users are able to do their own upgrades.

> But for gforge integration it is really not needed.

I discuss very long time with Christian Bayle from gforge team and we 
have the same felling: "multiplication of tables is bad" but without 
rational facts to justify our feeling.

Current way of phpwiki integration under gforge is to have only one wiki 
and each project create pages into this big wiki. My way is to provide 
one independent wiki for each project.

Current state seems to work (around 1 month of tests without any 
problems) but I prefer waiting for phpwiki 1.3.11 release before release 
the plugin.

Regards,
Manuel

-- 
# 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] Multiple instances - One DB

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

Manuel VACELET schrieb:
> Dan Frankowski wrote:
>> That's cool. You should submit a patch to Phpwiki, just in case Reini 
>> changes his mind. :-) Here is SourceForge's patches tracker:
> 
> Patch available here
> https://sourceforge.net/tracker/index.php?func=detail&aid=1097938&group_id=6121&atid=306121 

I'll have a look after 1.3.11 but I still see no technical reason, why 
this should be better than tablename prefixes. Merging all the seperate 
table sets into one big mess...

 >I can certainly imagine a reason to want multiple wiki instances in a 
 >single database. It's for ease of management.

 >Suppose there is something that breaks upon upgrade for some DBs. If 
 >you have 10,000 DBs, then you have to nurse each one. Or suppose that 
 >you wish to change the parameters of the DB for size or performance. 
 >One can either apply that once, or have to somehow apply it 10,000 
 >times. There are definite advantages to grouping wikis into a single >DB.

Other than helping administrative SQL tasks outside the wiki maybe. 
Schema upgrades are done now via action=upgrade.
But a simple mysql script is also easy, looping over all existing 
prefixes. Should I provide such a script for wikifarm schema upgrades?

But for gforge integration it is really not needed.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Wikilens ?

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

Dan Frankowski schrieb:
> Arnaud Fontaine wrote:
> Thanks for your interest! First a note on WikiLens progress, then 
> description of integration with PhpWiki. The short story is: we are 
> progressing well on WikiLens; I'd like to merge with Phpwiki, but some 
> things make it hard for me; any help is appreciated.
> 
> *** WikiLens progress
> 
> "WindWhale" (1.3.9.GL4) was released in late Sept 2004. Its main 
> features were: stability and bugfixes; a login process that actually 
> worked. This is what is currently on the site (always available in full 
> source at http://www.wikilens.org/wikilens-src.tgz; see also 
> http://wikilens.org/wiki.php/WikiLens).
> 
> We have been furiously working on our next WikiLens release, 
> "MoonBadger" (1.3.9.GL5). I have tagged release candidate 1 (RC1), so it 
> should be released within a week. New features include:
> 
> - Ratemania (the ability to put ratings widgets anywhere, not 
> necessarily tied to pages)

we agree here.

> - Take most of the data we use out of page text (because our users were 
> accidentally deleting it and uncomfortable editing it), and put it in 
> meta-data with specialized editors. This includes category membership 
> and buddies.

This will cause problems, I believe. But users and developers should decide.
As long as it only affects the wikilens theme...
I bet jeff and steve will hate it, but I or carsten could be persuaded.

> - Better buddy support and visibility (easily add/delete buddies through 
> "manage buddies" or by adding buddies-of-buddies; buddies page ratings 
> show up at the top of every page; buddies who like an item show up in a 
> column on category page; etc.)

We agree here.
But I'd really like to be independent on manual buddy maintainence 
somewhen. There should be the possibility to extract the buddies 
automatically by clustering. Maybe offline. Implementation later somewhen.
But we'd need an externally accessible API. xmlrpc can get the pagetext, 
so simple reading will be ok. Storage could be another external sql 
table. Ss with the planned access log features (referrers, abuse, 
anti-spam).

> - More "list" support (show on every page any lists that page is on; 
> allow a user to add pages to a list either from the page, or from the 
> list editor each with an autocomplete textbox)

we'll probably agree here.

> - Improved pagelist look and feel (odd and even row highlighting, 
> spacing, no indenting, etc.).

we agree here.

> - Better category page sorting (case insensitive, bugfixing)
> 
> - A considerably faster ratings widget (all one piece with an image-map, 
> client-side rendered, instead of 11 separate pieces server-side 
> rendered), leading to a 6X reduction in category page size, and 
> noticeably faster page loading.

why not.

> - and more!
> 
> *** Merging with PhpWiki
> 
> Now, my thoughts on integration. First, I'd love for all of it to be 
> integrated into Phpwiki! This would give us wider distribution, and 
> Phpwiki more features and much-deserved credit. However, there are 
> several barriers for me:
> 
> 1. My plan is to only integrate with actual releases of PhpWiki, because 
> those presumably are especially stable points. We are based on 1.3.9. 
> 1.3.10 has well-known bugs that make us not wish to integrate. 1.3.11 
> has not been released for 9 months, and looks to still be adding 
> features (not the sign of a release). This makes me sad. I think 
> projects should 'release early and often.' Every 3 months, 4 at most. 
> Anyway, when it comes out, we will examine doing what I call a 
> "double-merge": first merging 1.3.11 into our stuff, then trying to 
> contribute back as much as we can. It has been so long (probably about a 
> year) that I fear this double merge will be hard, but I still want to 
> try it.

It will be not that hard for me as soon as the core settings are 
settled. The plugin, and pagelist API and theme-pref API is stable.
Template solution pending.

> 2. There are some small things that Reini has refused to accept. 
> Examples include: PageList::addColumnObject(), Smarty pre-processing of 
> page templates. My guess is MoonBadger may bring more such features. I 
> do not disapprove; this is his perogative, and he has to make the best 
> decisions for Phpwiki. However, each presents a small puzzle to me for 
> how to preserve our functioning system within those parameters.

I'm willing to discuss an alternate template system than the current 
phpwiki php subinvocation later, because that is our main remaining 
memory and time bottleneck as I found out in this year.
phpwiki-1.3.4 with a simple preg_replace template system was a LOT 
faster and needed almost no memory. (6MB for the hugest multi-requests, 
compared to ~32BM currently). A simple linux/apache is faster then 
windows for our current templates, but with proxy farms as on sf.net it 
is as slow as on windows.

Smarty is good for adding control logic to the templates, but we 
probably don't need loops (FOR/WHILE) in templates. Maybe IF.
But first I want to stabilize the existing stuff before thinking about a 
better template system.
Smarty need's a lot of memory and time for the save-step, but it better 
for reading thna our current templates.
Compared to our previous template system smarty is a huge overkill.
With the memory problems it will be impossible to save big pages on one 
step.
I'll try how to use simplier, faster templates though.
Dan, do you need FOR/WHILE, or just IF?

> 3. There are also some disagreements we have on project style. For 
> example, I believe Phpwiki should focus on very few back-ends. This 
> would allow more time to make those back-ends work really well, and to 
> do other features. I still see a lot of time dumped into Phpwiki 
> back-end maintenance, which seems like 'opportunity cost' and makes me 
> sad. WikiLens supports only the MySQL back-end.

That's a legacy burden we have to carry along. But it's not that hard, 
as long it is doable easily enough.
Also that's our niche. No other wiki has that much storage backends and 
platform support.

> Frankly, due to 1-3 above, the other developers on WikiLens have no 
> desire to merge with PhpWiki. They want to fork. Unfortunately, this 
> leaves me with less time and moral support to do the merging. When I 
> say, "Take a look at how Phpwiki current CVS does that" they roll their 
> eyes. Sometimes they look, sometimes not. When they don't look, our code 
> diverges more.
> 
> I think Reini is a lot faster at merging that I am. The last time he 
> estimated a day to merge WindWhale into Phpwiki. It would probably take 
> me at least a week, with my other work duties. MoonBadger (when it comes 
> out) will be even farther, hence take even longer.
> 
> Also, the last time Reini merged our code in, he both changed it and 
> broke it. Again, changing it is his perogative, but makes my developers 
> want to fork. Breaking it is of course unfortunate, and I'm sure he 
> didn't mean it, but costs us more time and makes the case for merging 
> harder.

Yes, I had to change the pagelist invocation for plugins, which is very 
very complicated. And I wanted to have most wikilens features at 
user-cfg'able and/or theme cfg'able options.

> What I am saying is I see all these factors pushing us towards forking, 
> even though I wish it weren't so. Things that would help us not fork:
> 
> - Frequent stable releases of Phpwiki. Once every 3 months, 4 at MOST. 
>   Many people want this, I think.

With 1.3.11 we had these huge and complicated php memory problems and 
pcre crashes with old markup. All these are finally settled.

Along the testing I also wanted to add some minor new features, because 
it is easier to test the whole system and cfg, if I ADD some 
un-important new stuff, than CHANGING existing stuff. The current 
problems are now just related with the changes in the existing core,
not with the new features.
Unfortunately php5 broke again, which is probably related to the 
workarounds for the pcre crashes.

> - Fewer disagreements about project and code style
> - A place where we could add our extensions without them being changed much

I try not to break it. But we have to agree on a common API for the 
complicated stuff. plugin, pagelist cols, prefs.
The pagelist col API for fancy features is quite complicated now.
We could improve that and document that better.

> Anyway, I eagerly wait the release of 1.3.11. Once we release 
> MoonBadger, I also would eagerly appreciate help in merging its features 
> into Phpwiki.

You got fancy release names now :)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] locale_versions() pb in last CVS update

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

I have a "Call to undefined function: locale_versions() in the 
config.php file since last CVS update ...

It's defined in FileFinder but the require_once is commented .... why ?
--
Arnaud Fontaine
CRAO
Jabber: sh...@ra...

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

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

Dan Frankowski wrote:
> That's cool. You should submit a patch to Phpwiki, just in case Reini 
> changes his mind. :-) Here is SourceForge's patches tracker:

Patch available here
https://sourceforge.net/tracker/index.php?func=detail&aid=1097938&group_id=6121&atid=306121

Hope it could help.

Manuel
-- 
# 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] Multiple instances - One DB

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

Manuel VACELET wrote:

> Dan Frankowski wrote:
>
>> Reini Urban wrote:
>>
>>> Manuel VACELET schrieb:
>>>
>>>> Reini Urban wrote:
>>>>
>>>>> Manuel VACELET schrieb:
>>>>>
>>>>>> In order to be able to run multiple instances of PhpWiki based on 
>>>>>> the same sources and the same DB, I want to modify WikiDB and 
>>>>>> corresponding backends (at beginning PearDB) to add an unique id 
>>>>>> for each PhpWiki instances.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> why? don't do that!
>>>>> just define a different DATABASE_PREFIX for each wiki and generate 
>>>>> the tables with these prefixes.
>>>>
>>>>
>>>>
>>>>
>>>> I want to offer phpwiki servicies to mutiple groups (I'm looking 
>>>> around gforge wiki plugin). For security reason I have to separate 
>>>> content of each instances of PhpWiki. I can have thousand instances 
>>>> of phpwiki so it imply ten thousand mysql tables.
>>>>
>>>> I already (successfully) tested database prefix but I think next 
>>>> phpwiki updates (with db schema upgrades) will be a little bit 
>>>> complicated.
>>>
>>>
>>>
>>>
>>> So please use different databases for this task. Just a different DSN.
>>> You can do that automatically by creating the DSN automatically
>>> e.g. by prefixing the database with the gforge project name. 
>>> ("myproject_phpwiki")
>>> Or even use the gforge database "myproject" and just add some 
>>> general "phpwiki_" prefix.
>>>
>>> Either prefixes or databases.
>>> I see no technical reason for a WikiDB db_id.
>>
>>
>> I can certainly imagine a reason to want multiple wiki instances in a 
>> single database. It's for ease of management.
>>
>> Suppose there is something that breaks upon upgrade for some DBs. If 
>> you have 10,000 DBs, then you have to nurse each one. Or suppose that 
>> you wish to change the parameters of the DB for size or performance. 
>> One can either apply that once, or have to somehow apply it 10,000 
>> times. There are definite advantages to grouping wikis into a single DB.
>>
>> On the other hand, that doesn't mean it's easy to change Phpwiki to 
>> do that.
>
>
> Even if Reini said to avoid this idea from my mind ... I did it :)
>
> On phpwiki 1.3.10 I made a hack to add a wiki identifier in the DB and 
> in the mysql back end.
>
> My hacked phpwiki runs since the beginning of december with around 10 
> wiki on the same set of tables and there is -I hope- no conflicts.
>
> I could give you a patch if you are under interest.


That's cool. You should submit a patch to Phpwiki, just in case Reini 
changes his mind. :-) Here is SourceForge's patches tracker:

http://sourceforge.net/tracker/?atid=306121&group_id=6121&func=browse

Dan

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

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

Dan Frankowski wrote:
> Reini Urban wrote:
> 
>> Manuel VACELET schrieb:
>>
>>> Reini Urban wrote:
>>>
>>>> Manuel VACELET schrieb:
>>>>
>>>>> In order to be able to run multiple instances of PhpWiki based on 
>>>>> the same sources and the same DB, I want to modify WikiDB and 
>>>>> corresponding backends (at beginning PearDB) to add an unique id 
>>>>> for each PhpWiki instances.
>>>>
>>>>
>>>>
>>>> why? don't do that!
>>>> just define a different DATABASE_PREFIX for each wiki and generate 
>>>> the tables with these prefixes.
>>>
>>>
>>>
>>> I want to offer phpwiki servicies to mutiple groups (I'm looking 
>>> around gforge wiki plugin). For security reason I have to separate 
>>> content of each instances of PhpWiki. I can have thousand instances 
>>> of phpwiki so it imply ten thousand mysql tables.
>>>
>>> I already (successfully) tested database prefix but I think next 
>>> phpwiki updates (with db schema upgrades) will be a little bit 
>>> complicated.
>>
>>
>>
>> So please use different databases for this task. Just a different DSN.
>> You can do that automatically by creating the DSN automatically
>> e.g. by prefixing the database with the gforge project name. 
>> ("myproject_phpwiki")
>> Or even use the gforge database "myproject" and just add some general 
>> "phpwiki_" prefix.
>>
>> Either prefixes or databases.
>> I see no technical reason for a WikiDB db_id.
>
> I can certainly imagine a reason to want multiple wiki instances in a 
> single database. It's for ease of management.
> 
> Suppose there is something that breaks upon upgrade for some DBs. If you 
> have 10,000 DBs, then you have to nurse each one. Or suppose that you 
> wish to change the parameters of the DB for size or performance. One can 
> either apply that once, or have to somehow apply it 10,000 times. There 
> are definite advantages to grouping wikis into a single DB.
> 
> On the other hand, that doesn't mean it's easy to change Phpwiki to do 
> that.

Even if Reini said to avoid this idea from my mind ... I did it :)

On phpwiki 1.3.10 I made a hack to add a wiki identifier in the DB and 
in the mysql back end.

My hacked phpwiki runs since the beginning of december with around 10 
wiki on the same set of tables and there is -I hope- no conflicts.

I could give you a patch if you are under interest.

Best regards,
Manuel

-- 
# 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] Multiple instances - One DB

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

Reini Urban wrote:

> Manuel VACELET schrieb:
>
>> Reini Urban wrote:
>>
>>> Manuel VACELET schrieb:
>>>
>>>> In order to be able to run multiple instances of PhpWiki based on 
>>>> the same sources and the same DB, I want to modify WikiDB and 
>>>> corresponding backends (at beginning PearDB) to add an unique id 
>>>> for each PhpWiki instances.
>>>
>>>
>>> why? don't do that!
>>> just define a different DATABASE_PREFIX for each wiki and generate 
>>> the tables with these prefixes.
>>
>>
>> I want to offer phpwiki servicies to mutiple groups (I'm looking 
>> around gforge wiki plugin). For security reason I have to separate 
>> content of each instances of PhpWiki. I can have thousand instances 
>> of phpwiki so it imply ten thousand mysql tables.
>>
>> I already (successfully) tested database prefix but I think next 
>> phpwiki updates (with db schema upgrades) will be a little bit 
>> complicated.
>
>
> So please use different databases for this task. Just a different DSN.
> You can do that automatically by creating the DSN automatically
> e.g. by prefixing the database with the gforge project name. 
> ("myproject_phpwiki")
> Or even use the gforge database "myproject" and just add some general 
> "phpwiki_" prefix.
>
> Either prefixes or databases.
> I see no technical reason for a WikiDB db_id.


I can certainly imagine a reason to want multiple wiki instances in a 
single database. It's for ease of management.

Suppose there is something that breaks upon upgrade for some DBs. If you 
have 10,000 DBs, then you have to nurse each one. Or suppose that you 
wish to change the parameters of the DB for size or performance. One can 
either apply that once, or have to somehow apply it 10,000 times. There 
are definite advantages to grouping wikis into a single DB.

On the other hand, that doesn't mean it's easy to change Phpwiki to do that.

Dan

[Phpwiki-talk] phpwiki-1.2.7 released, cvs updated

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

Reini Urban schrieb:
> I detected some cvs -r "release-1_2-branch" fixes and enhancements in 
> cvs, which didn't make it into the releases 1.2.4, 1.2.5 and 1.2.6, so 
> I'm just backporting and testing this.

I added now the 1.2.4, 1.2.5. 1.2.6 and the current 1.2.7 release 
versions and tags to the release-1_2-branch branch in cvs, and made 
available a new 1.2.7 file release.

Note: I made a minor cvs mistake: The release-1_2_4 tag is unfortunately 
a branch and not a tag, but I don't care that much to fix that.

Release Info:
   https://sourceforge.net/forum/forum.php?forum_id=435599
CVS:
 
http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/lib/?only_with_tag=release-1_2-branch 

Download:
   http://sourceforge.net/project/showfiles.php?group_id=6121

While backporting some minor feature enhancements from late 2001 and 
early 2002 cvs: split_pagename in title and header to help google, 
support new USE_LINK_ICONS and AUTOSPLIT_WIKIWORDS, better i18n 
$WikiNameRegexp, added minor_edit checkbox.
I also added some backports from the 1.3 tree: print more meta tags: 
robots, favicon, language and PHPWIKI_VERSION,
and made the default dba more robust:
dba default detection for dba/dbm and take best handler, fix timeout 
logic, improve error diagnostics: print errors after the first failing 
attempts
I also updated the translation and improved the template for better 
xhtml conformity.

I hope I get to the missing 1.3.11 fixes now, esp. some request-loop 
problems on certain themes without signature and apache2,
the missing/re-appearing php5 parser problem, some other minor remaining 
problems, and new features (blogging, ModeratedPage).
-- 
Reini Urban
http://phpwiki.org

Re: [Phpwiki-talk] [RFC] AppendTextPlugin

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

Pascal Giard (QC/EMC) wrote:

> Here's a first working version.
> Comments are very welcome.
>
> -Pascal
> PS: rename .zipped to .zip ... sorry, had to do that because of 
> Ericsson's mail scanner.
>
>  
>


Pascal,

I just wanted to let you know, we may have written a similar plugin 
which we called "AddInlineComment". I'm not sure, I haven't compared 
your code to ours carefully. You can see it by downloading 
http://www.wikilens.org/wikilens-src.tgz and looking inside for 
lib/plugin/AddInlineComment.php.

Dan

Re: [Phpwiki-talk] Wikilens ?

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

Arnaud Fontaine wrote:

> Hi all and Happy new year !
>
> A short message to ask Reini and Dan about wikilens category 
> integration ? Soon to be released ? Any help needed ?


Arnaud,

Thanks for your interest! First a note on WikiLens progress, then 
description of integration with PhpWiki. The short story is: we are 
progressing well on WikiLens; I'd like to merge with Phpwiki, but some 
things make it hard for me; any help is appreciated.

*** WikiLens progress

"WindWhale" (1.3.9.GL4) was released in late Sept 2004. Its main 
features were: stability and bugfixes; a login process that actually 
worked. This is what is currently on the site (always available in full 
source at http://www.wikilens.org/wikilens-src.tgz; see also 
http://wikilens.org/wiki.php/WikiLens).

We have been furiously working on our next WikiLens release, 
"MoonBadger" (1.3.9.GL5). I have tagged release candidate 1 (RC1), so it 
should be released within a week. New features include:

- Ratemania (the ability to put ratings widgets anywhere, not 
necessarily tied to pages)

- Take most of the data we use out of page text (because our users were 
accidentally deleting it and uncomfortable editing it), and put it in 
meta-data with specialized editors. This includes category membership 
and buddies.

- Better buddy support and visibility (easily add/delete buddies through 
"manage buddies" or by adding buddies-of-buddies; buddies page ratings 
show up at the top of every page; buddies who like an item show up in a 
column on category page; etc.)

- More "list" support (show on every page any lists that page is on; 
allow a user to add pages to a list either from the page, or from the 
list editor each with an autocomplete textbox)

- Improved pagelist look and feel (odd and even row highlighting, 
spacing, no indenting, etc.).

- Better category page sorting (case insensitive, bugfixing)

- A considerably faster ratings widget (all one piece with an image-map, 
client-side rendered, instead of 11 separate pieces server-side 
rendered), leading to a 6X reduction in category page size, and 
noticeably faster page loading.

- and more!

*** Merging with PhpWiki

Now, my thoughts on integration. First, I'd love for all of it to be 
integrated into Phpwiki! This would give us wider distribution, and 
Phpwiki more features and much-deserved credit. However, there are 
several barriers for me:

1. My plan is to only integrate with actual releases of PhpWiki, because 
those presumably are especially stable points. We are based on 1.3.9. 
1.3.10 has well-known bugs that make us not wish to integrate. 1.3.11 
has not been released for 9 months, and looks to still be adding 
features (not the sign of a release). This makes me sad. I think 
projects should 'release early and often.' Every 3 months, 4 at most. 
Anyway, when it comes out, we will examine doing what I call a 
"double-merge": first merging 1.3.11 into our stuff, then trying to 
contribute back as much as we can. It has been so long (probably about a 
year) that I fear this double merge will be hard, but I still want to 
try it.

2. There are some small things that Reini has refused to accept. 
Examples include: PageList::addColumnObject(), Smarty pre-processing of 
page templates. My guess is MoonBadger may bring more such features. I 
do not disapprove; this is his perogative, and he has to make the best 
decisions for Phpwiki. However, each presents a small puzzle to me for 
how to preserve our functioning system within those parameters.

3. There are also some disagreements we have on project style. For 
example, I believe Phpwiki should focus on very few back-ends. This 
would allow more time to make those back-ends work really well, and to 
do other features. I still see a lot of time dumped into Phpwiki 
back-end maintenance, which seems like 'opportunity cost' and makes me 
sad. WikiLens supports only the MySQL back-end.

Frankly, due to 1-3 above, the other developers on WikiLens have no 
desire to merge with PhpWiki. They want to fork. Unfortunately, this 
leaves me with less time and moral support to do the merging. When I 
say, "Take a look at how Phpwiki current CVS does that" they roll their 
eyes. Sometimes they look, sometimes not. When they don't look, our code 
diverges more.

I think Reini is a lot faster at merging that I am. The last time he 
estimated a day to merge WindWhale into Phpwiki. It would probably take 
me at least a week, with my other work duties. MoonBadger (when it comes 
out) will be even farther, hence take even longer.

Also, the last time Reini merged our code in, he both changed it and 
broke it. Again, changing it is his perogative, but makes my developers 
want to fork. Breaking it is of course unfortunate, and I'm sure he 
didn't mean it, but costs us more time and makes the case for merging 
harder.

What I am saying is I see all these factors pushing us towards forking, 
even though I wish it weren't so. Things that would help us not fork:

- Frequent stable releases of Phpwiki. Once every 3 months, 4 at MOST. 
Many people want this, I think.
- Fewer disagreements about project and code style
- A place where we could add our extensions without them being changed much

Anyway, I eagerly wait the release of 1.3.11. Once we release 
MoonBadger, I also would eagerly appreciate help in merging its features 
into Phpwiki.

I hope that helps.

Dan

Re: [Phpwiki-talk] bugfix in lib/WikiDB/backend/PearDB.php

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

Charles Corrigan schrieb:
> in _PearDbPassUser->userExists(), the following three lines should be
> deleted.  submitted_password is a parameter to a different procedure
> 
> if (!$this->_checkPassLength($submitted_password)) {
>         return WIKIAUTH_FORBIDDEN;
> }

Oops.
Thanks, I've moved it downwards to checkPass()

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

[Phpwiki-talk] CreateToc plugin patch

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

Hello all

I made a patch on CreateToc plugin in order to add
* a real counter for title (1, 1.1, 1.2, 2, 2.1, ...)
* fix some bugs with anchor and wikiword titles (single or not)
* add backlink on title with wiki words (with counter)

Note:
Counter is optionnal, it is disable by default use with_counter||=1 to 
activate it.

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

Re: [Phpwiki-talk] bugfix in lib/WikiUser/PearDB.php

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

After a bit more thought and investigation...

in _PearDbPassUser->userExists(), the following three lines should be
cut and then pasted into the following _PearDbPassUser->checkPass().

if (!$this->_checkPassLength($submitted_password)) {
        return WIKIAUTH_FORBIDDEN;
}

regards,
Charles