From: Dan F. <dfr...@cs...> - 2004-06-28 20:16:16
|
Folks, One of my users is really excited about Phpwiki, and said, "I can think of uses for dozens of instances of it!" However, he wants that each of those instances is logically separate from the others. So, for example, the HomePage of each does not show the others, the search for each does not turn up pages in the others, etc. I replied that Twiki has a notion of multiple "webs", but Phpwiki had no such. One could run multiple Phpwiki instances, but then if the code changes, you have to update code and config for each instance separately. Does anyone have better ideas? Dan |
From: Philippe V. <Phi...@to...> - 2004-06-28 21:03:52
|
Try this: http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions Dan Frankowski wrote: > Folks, > > One of my users is really excited about Phpwiki, and said, "I can > think of uses for dozens of instances of it!" However, he wants that > each of those instances is logically separate from the others. So, for > example, the HomePage of each does not show the others, the search for > each does not turn up pages in the others, etc. > > I replied that Twiki has a notion of multiple "webs", but Phpwiki had > no such. One could run multiple Phpwiki instances, but then if the > code changes, you have to update code and config for each instance > separately. > > Does anyone have better ideas? > > Dan -- PhilV Key fingerprint = 2B97 90DB 124B C784 FFE8 6EED 6345 A87E 4BBA F57C |
From: Dan F. <dfr...@cs...> - 2004-06-28 21:46:20
|
Philippe Vanhaesendonck wrote: > Try this: http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions Ah! I presume you mean this question: Q. Can I run two PhpWiki <http://phpwiki.sourceforge.net/phpwiki/PhpWiki>s with separate databases off the same code?: I don't look in the FAQ page because it's large, frightening, and has not much TOC, but I should remember to grind through it more. This is somewhat helpful. It might be nice if only the changes were kept in separate files. Presumably, one could modify the index.php and wiki2.php to include some common config. This still does not allow one to use the same DB, so if any upgrades cause DB changes, that would still force lots of DB upgrades, and potentially lots of index.php config upgrades. However, it probably helps. Dan > > Dan Frankowski wrote: > >> Folks, >> >> One of my users is really excited about Phpwiki, and said, "I can >> think of uses for dozens of instances of it!" However, he wants that >> each of those instances is logically separate from the others. So, >> for example, the HomePage of each does not show the others, the >> search for each does not turn up pages in the others, etc. >> >> I replied that Twiki has a notion of multiple "webs", but Phpwiki had >> no such. One could run multiple Phpwiki instances, but then if the >> code changes, you have to update code and config for each instance >> separately. >> >> Does anyone have better ideas? >> >> Dan > > > |
From: Jim C. <jim@iNode.co.nz> - 2004-06-28 21:14:56
|
Dan Frankowski wrote: > I replied that Twiki has a notion of multiple "webs", but Phpwiki had no > such. One could run multiple Phpwiki instances, but then if the code > changes, you have to update code and config for each instance separately. > > Does anyone have better ideas? Yes, Matthew Palmer was talking about enabling this for the Debian packaged version. The current stopper is that index.php looks in a fixed location for the config file, but if this were overridden by a php value set in the .htaccess file, you could have a lot of flexibility. Here's (part of) his original post ... >> Another method, if you wanted it, that would work in PHPWiki more or less >> as-is, would be to use the other method I devised for the above project >> (which I didn't use as the substring method was more appropriate in that >> case). Create a constant, perhaps called __CONFIGURED, that will be >> defined >> true once all of the appropriate config statements have been processed. >> Then, tell index.php not to call IniConfig() (or tell IniConfig() not to >> do >> anything) if __CONFIGURED is defined. >> >> How does this help? Because you put something like the following in your >> apache.conf for each of the virtualised PHPWiki instances: >> >> php_value auto_prepend_file /some/config/file.php >> >> Where /some/config/file.php is unique for each instance, and contains >> pretty >> much the following code: >> >> require_once '/usr/share/phpwiki/lib/IniConfig.php'; >> IniConfig('/some/config/file.ini'); >> define('__CONFIGURED', true); >> >> Again, where /some/config/file.ini is unique to that virtual instance of >> PHPWiki and filled with lovely local-specific config options. >> >> You then point each virtual instance of PHPWiki at /usr/share/phpwiki for >> it's code, index.php runs for everyone but skips the default config for >> your >> virtual instances because __CONFIGURED is defined, and IniConfig() has >> previously run with your per-instance config file. I'd like to see this too, because I'm currently running three wikis on the same machine, with the associated duplication of code files. Perhaps Matthew could implement this, and Reini could accept it into CVS? -jim |
From: Philippe V. <Phi...@to...> - 2004-06-29 15:37:22
|
Jim Cheetham said: > Yes, Matthew Palmer was talking about enabling this for the Debian > packaged version. The current stopper is that index.php looks in a fixed > location for the config file, but if this were overridden by a php value > set in the .htaccess file, you could have a lot of flexibility. Here's > (part of) his original post ... <Snip> Interresting... There is also another method described there: http://phpwiki.sourceforge.net/phpwiki/WikiFarm An alternative would be to use the last element of the path as a key to a config file. E.g. http://xxx.org/wiki1/index.php would look for a wiki1.ini config file. So there are plenty of possibilities that one can implement easily as wrapper around phpWiki without touching a lot to the sources. Dan Frankowski said: > This still does not allow one to use the same DB, so if any upgrades > cause DB changes, that would still force lots of DB upgrades, and > potentially lots of index.php config upgrades. However, it probably helps. This is a more fundamendal change in the DB design. Less easy to do... -- Philippe |
Jim Cheetham schrieb: > Dan Frankowski wrote: > >> I replied that Twiki has a notion of multiple "webs", but Phpwiki had >> no such. One could run multiple Phpwiki instances, but then if the >> code changes, you have to update code and config for each instance >> separately. >> >> Does anyone have better ideas? > > Yes, Matthew Palmer was talking about enabling this for the Debian > packaged version. The current stopper is that index.php looks in a fixed > location for the config file, but if this were overridden by a php value > set in the .htaccess file, you could have a lot of flexibility. Here's > (part of) his original post ... You don't need seperate config.ini's. Put the common options into config.ini and the overrides (DATABASE_DSN, WIKI_NAME, ...) into the short starter script. I run about 30 different databases with lots of different options with the same config.ini. CONSTANT's override config.ini settings, besides the DATA_BASE settings, which must be defined after loading index.php. Some files of my /wiki dir are attached. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Matthew P. <mp...@he...> - 2004-06-28 23:51:16
|
On Tue, Jun 29, 2004 at 09:14:42AM +1200, Jim Cheetham wrote: [__CONFIGURED for multiple Wikis] > I'd like to see this too, because I'm currently running three wikis on > the same machine, with the associated duplication of code files. Perhaps > Matthew could implement this, and Reini could accept it into CVS? Reini said he didn't like my idea, and preferred his way of doing it. See http://sourceforge.net/mailarchive/message.php?msg_id=8500690. The problem I see with Reini's idea is that it relies on trusting IniConfig not to go overwriting existing define()s. That's fine and dandy now, but without giant "Here be Monsters, lad" all over the IniConfig code, someone in the future is going to change it to do just that (because constant leakage is bad), and suddenly all of your custom Wikis die. Also, you're splitting the config into multiple parts again -- one for defines, and one for variables. With the number of variables in PHPWiki (and the fact that now, with IniConfig, they're no longer documented as being variables in the config file, but only in the depths of IniConfig() -- and that's subject to change without notice), you're going to have a hard time figuring out which one's which. My system adds little in the way of complexity -- both methods require .htaccess fiddling and snippets of custom code, as does mine -- but mine allows you to use the same config method for custom sites -- an IniConfig file -- as the main site. But hey, to each their own. Reini thinks my idea sucks, I think his does, and we all clap hands together. He runs the project, and does it well enough that I doubt anyone's about to start muttering about mutiny or taking their bat and ball because of a different method of doing multi-wiki. I'll run up a patch if anyone is truly interested (and I'll even keep it current against future releases), but it's such a simple modification that you can do it yourself at home with simple hand tools -- as documented in my original E-mail (for reference, http://sourceforge.net/mailarchive/message.php?msg_id=7966839). - Matt |
From: Reini U. <ru...@x-...> - 2004-06-29 17:39:21
|
Matthew Palmer wrote: > On Tue, Jun 29, 2004 at 09:14:42AM +1200, Jim Cheetham wrote: > [__CONFIGURED for multiple Wikis] >>I'd like to see this too, because I'm currently running three wikis on >>the same machine, with the associated duplication of code files. Perhaps >>Matthew could implement this, and Reini could accept it into CVS? > > > Reini said he didn't like my idea, and preferred his way of doing it. See > http://sourceforge.net/mailarchive/message.php?msg_id=8500690. The problem > I see with Reini's idea is that it relies on trusting IniConfig not to go > overwriting existing define()s. That's fine and dandy now, but without > giant "Here be Monsters, lad" all over the IniConfig code, someone in the > future is going to change it to do just that (because constant leakage is > bad), and suddenly all of your custom Wikis die. > > Also, you're splitting the config into multiple parts again -- one for > defines, and one for variables. With the number of variables in PHPWiki > (and the fact that now, with IniConfig, they're no longer documented as > being variables in the config file, but only in the depths of IniConfig() > -- and that's subject to change without notice), you're going to have a hard > time figuring out which one's which. > > My system adds little in the way of complexity -- both methods require > .htaccess fiddling and snippets of custom code, as does mine -- but mine > allows you to use the same config method for custom sites -- an IniConfig > file -- as the main site. > > But hey, to each their own. Reini thinks my idea sucks, I think his does, > and we all clap hands together. I never said that your idea sucks. I like it. I even have some test scripts which use your approach. I just prefer my simple starter scripts because they are shorter. And we used my way for some years now in the demo site, before we even had a config.ini file. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Matthew P. <mp...@he...> - 2004-06-30 01:03:12
|
On Tue, Jun 29, 2004 at 07:39:12PM +0200, Reini Urban wrote: > I never said that your idea sucks. > I like it. I even have some test scripts which use your approach. "And don't really like Matthew's idea." (That's from message 8500690 in the phpwiki-talk archive). I'm happy to accept that you may have changed your mind in the interim, but you did say in the past that you didn't like it. > I just prefer my simple starter scripts because they are shorter. Shorter than <?php require_once 'lib/IniConfig.php'; IniConfig('/foo/bar/baz'); define('__CONFIGURED'); ? The three basic defines in your example in 8500690 are that length, before you start including index.php or lib/main.php. The snippet above also requires one change -- the location of the config file -- for use on another site. > And we used my way for some years now in the demo site, before we even > had a config.ini file. I'm not denying it may well have been the best solution in the past. - Matt |
From: Oliver B. <ob...@de...> - 2004-06-30 06:59:05
|
Matthew Palmer wrote: [...] > > I just prefer my simple starter scripts because they are shorter. > > Shorter than > > <?php > require_once 'lib/IniConfig.php'; > IniConfig('/foo/bar/baz'); > define('__CONFIGURED'); > > ? IMHO it is simpler, because the script also contains the specific configuration where your method requires a third file. But I see not basic difference since both methods combine a standard config with specific settings, and therefore no need for heated discussions. Although I have no PHP knowledge, I have no problem to understand both methods and adapt PhpWiki to my specific needs. If I decide to set variables in the php script, I can do so. If I prefer to read a *.ini, I can do it also. Who cares? Is it important, which method is shipped with the PhpWiki distribution? After all, both methods can be documented. Oliver |