Menu
▾
▴
phpwiki-talk
|
From: Reini U. <ru...@x-...> - 2004-01-23 18:02:54
|
Hi (Joby) Why not storing the index.php configuration in the database, table config, editable only by the admin? This is much easier to install and maybe easier to maintain then the current file based solution. then we will be able to have a tiny index.php. lib/config.php will then load and verify the config settings, using config/* The only problem I see is that without working database connection one cannot edit the config... maybe use a single dba/gdbm/sqlite/flat-file file therefore. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Joby W. <joby@u.washington.edu> - 2004-01-23 19:22:21
|
I agree completely. There are just far too many config settings to continue the way we are going. We can also use the database keep historical config settings to allow for the roll back of configuration settings. It should help simplify the config/* files (which I need to get back to...). jbw Reini Urban wrote: > Hi (Joby) > Why not storing the index.php configuration in the database, table > config, editable only by the admin? > > This is much easier to install and maybe easier to maintain then the > current file based solution. then we will be able to have a tiny > index.php. lib/config.php will then load and verify the config settings, > using config/* > > The only problem I see is that without working database connection one > cannot edit the config... > maybe use a single dba/gdbm/sqlite/flat-file file therefore. |
|
From: Reini U. <ru...@x-...> - 2004-01-25 03:14:30
|
Joby Walker schrieb: > I agree completely. > > There are just far too many config settings to continue the way we are > going. We can also use the database keep historical config settings to > allow for the roll back of configuration settings. It should help > simplify the config/* files (which I need to get back to...). Ok. But before I do the config stuff (which I really want to do now, because I don't dare to commit the new index.php for my new config settings, which requires a manual hack in the demo site after the daily automatic checkout), I'll implement proper page permissions. I already changed phpwiki.sf.net/demo/index.php to reallow USE_PATH_INFO and all the supported languages, even if the database got raided. The current new user scheme is quite strict. e.g. previously ALLOW_ANON_USER = false meant that anon users cannot edit, but may browse. With ENABLE_USER_NEW and ALLOW_ANON_USER = false he may even not browse which is needed to disable browse PagePermissions for a certain user. So I will implement PagePermissions to get rid of ALLOW_ANON_USER = false, which is quite annoying and check permissions per page resp. action and user and optionally group. > Reini Urban wrote: >> Hi (Joby) >> Why not storing the index.php configuration in the database, table >> config, editable only by the admin? >> >> This is much easier to install and maybe easier to maintain then the >> current file based solution. then we will be able to have a tiny >> index.php. lib/config.php will then load and verify the config >> settings, using config/* >> >> The only problem I see is that without working database connection one >> cannot edit the config... >> maybe use a single dba/gdbm/sqlite/flat-file file therefore. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Oliver B. <ob...@de...> - 2004-01-26 08:06:12
|
Reini Urban wrote: > Why not storing the index.php configuration in the database, table > config, editable only by the admin? because it would be less transparent. As long as the config is in a plain text file, I can: - modify it without special tools, - look at it (check it) as a whole, - compare different configs with a text diff tool and - merge settings e.g. when changing more thn one Wiki. I guess there are more reasons. Hiding configs in databases is one of the the disadvantages of the windows way. As long as the config is php, one can add also special processing if he/she wants. > This is much easier to install and maybe easier to maintain then the Maintenance is harder, IMO. In which manner do you think the installation will be easier than now? Oliver |
|
From: Bob A. <apt...@cy...> - 2004-01-26 09:17:55
|
Hi, On Mon, 26 Jan 2004 09:05:49 +0100 "Oliver Betz" <ob...@de...> wrote: > Reini Urban wrote: > > > Why not storing the index.php configuration in the database, table > > config, editable only by the admin? > > because it would be less transparent. As long as the config is in a > plain text file, I can: > > - modify it without special tools, > - look at it (check it) as a whole, > - compare different configs with a text diff tool and > - merge settings e.g. when changing more thn one Wiki. > > I guess there are more reasons. FWIW, eGroupware allows you to change its configuration from within the application (e.g. read config.php, make changes, then save the changes along with a backup of the original configuration.) With proper directory permissions and good authentication this shouldn't be too difficult. > Hiding configs in databases is one of the the disadvantages of the > windows way. > > As long as the config is php, one can add also special processing if > he/she wants. > > > This is much easier to install and maybe easier to maintain then the > > Maintenance is harder, IMO. I don't know if my experience is typical but I spend most of my effort trying to initially configure a PHP/MySQL application. Once it's installed and running I rarely have to mess with it (not counting administrative tasks like setting permissions, ACLs, etc. -- but that's not the case we're talking about here.) > In which manner do you think the installation will be easier than > now? I'd use eGroupware as an example, though I don't think PhpWiki is all that difficult to set up compared to similar applications (try sorting out Tiki's permissions sometime - gruesome!) -- Bob |
|
From: Reini U. <ru...@x-...> - 2004-01-26 09:40:27
|
Oliver Betz schrieb: > Reini Urban wrote: >>Why not storing the index.php configuration in the database, table >>config, editable only by the admin? > > because it would be less transparent. As long as the config is in a > plain text file, I can: > > - modify it without special tools, > - look at it (check it) as a whole, > - compare different configs with a text diff tool and > - merge settings e.g. when changing more thn one Wiki. > > I guess there are more reasons. > > Hiding configs in databases is one of the the disadvantages of the > windows way. > > As long as the config is php, one can add also special processing if > he/she wants. Persuaded. But I would like to seperate the config from the startup file. lib/config sanifies the config settings, so PHPWIKI_DIR."/config.php" would be fine. >>This is much easier to install and maybe easier to maintain then the > > Maintenance is harder, IMO. > > In which manner do you think the installation will be easier than > now? Most of the local apache/php settings could be calculated automatically. One should only define if e.g. USE_PATH_INFO = true or false, and the appropriate VIRTUAL_PATH, DATA_PATH settings can be calculated. Also applied .htaccess samples Same for database and authorization settings, which depend on the available libraries and services. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Steve W. <sw...@pa...> - 2004-01-26 19:02:14
|
On Jan 26, 2004, at 3:05 AM, Oliver Betz wrote: > Reini Urban wrote: > >> Why not storing the index.php configuration in the database, table >> config, editable only by the admin? > > because it would be less transparent. I concur. Plain text has the main advantage that it is easily read, edited, shared, and backed up. ~swain > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > |
|
From: Zot O'C. <zo...@wh...> - 2004-01-26 19:47:24
|
On Mon, 2004-01-26 at 11:01, Steve Wainstead wrote:
> On Jan 26, 2004, at 3:05 AM, Oliver Betz wrote:
>
> > Reini Urban wrote:
> >
> >> Why not storing the index.php configuration in the database, table
> >> config, editable only by the admin?
> >
> > because it would be less transparent.
>
> I concur. Plain text has the main advantage that it is easily read,
> edited, shared, and backed up.
> ~swain
Plain Text is also overwhelming as presented. I like the idea of a
"config" file for everything not needed in index.php.
I see a "config" file for every day things (where's the DB, what
sessions, server side tweaks), a config.once file for the initial boot
process, and things which you could change on the fly, in a DB
accessible via the web.
The last one is a tricky but important thing.
Think of the process for a newbie:
1. You edit the minimal config file for things that need to be
there (DB entries, timeouts, other things, wiki name and
prefixes). You probably do not need to edit config.once
(config.init sounds better).
2. You run index.php. It bitches about no DB loaded. Perhaps it
offers to load the config file for you (which means the wikidb
user has table create access, a bad idea, but livable), or the
user has to load the DB schema by hand (current).
3. You get in, but things needs fixing, but *YOU GET IN*. There is
no "cannot see anything so I have to edit a text file" barrier.
4. You tweak most things via a web interface (theme's, user names,
admin passwords, etc).
The key difference of this approach over other approaches is
*intuitive.* It is not intuitive to do 90% of the tasks, and get 0%
results. This is the case of most programs. Quicken was one of the
first packages that let you go forward with mistakes, and then see
results and then fix them. This was much better than the standard "you
must have everything right before we show the results" approach to
software.
If you take a step back and think about, Ward's goal's for the wiki wiki
wiki web was to reduce barriers to increase communication. Reducing the
steps to go live, and the possible pitfalls, and making tweaking easier
via the web, follows Ward's goals.
And I hope by now, some of you have realized that web based
configuration and flat file config are not incongruous. The web
interface must be able to write to a file on that system, and it could
be a .ini-like file. It could be a dbm file or sql call as well.
--
Zot O'Connor
http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com
|
|
From: Reini U. <ru...@x-...> - 2004-01-26 20:17:25
|
Zot, What you describe is the system we currently have (configurator.php) but nobody uses, because it's a pain to maintain, is not well supported and doesn't look good enough. Joby's new Config class will help. It will also dump the configuration back to a file, and is easier to maintain than configurator.php. We all understand that the current index.php with its overwhelming amount of not really needed options is a major turnoff for first-time installers. And it's technically quite hard to use with larger wiki farms or multilingual wikis, but there's now code at the end to support that. Maybe we should present some important options at the top, let the user run it, and let the web-based configurator do the rest. This will need some reordering of the current chapter based index.php into a short index.php to get it running, and a config-dist.php (dumped then to config.php) which is maintainable via the configurator and represents all the fine tuning. Zot O'Connor schrieb: > On Mon, 2004-01-26 at 11:01, Steve Wainstead wrote: >>On Jan 26, 2004, at 3:05 AM, Oliver Betz wrote: >> >>>Reini Urban wrote: >>> >>> >>>>Why not storing the index.php configuration in the database, table >>>>config, editable only by the admin? >>> >>>because it would be less transparent. >> >>I concur. Plain text has the main advantage that it is easily read, >>edited, shared, and backed up. >>~swain > > > Plain Text is also overwhelming as presented. I like the idea of a > "config" file for everything not needed in index.php. > > I see a "config" file for every day things (where's the DB, what > sessions, server side tweaks), a config.once file for the initial boot > process, and things which you could change on the fly, in a DB > accessible via the web. > > The last one is a tricky but important thing. > > Think of the process for a newbie: > > 1. You edit the minimal config file for things that need to be > there (DB entries, timeouts, other things, wiki name and > prefixes). You probably do not need to edit config.once > (config.init sounds better). > 2. You run index.php. It bitches about no DB loaded. Perhaps it > offers to load the config file for you (which means the wikidb > user has table create access, a bad idea, but livable), or the > user has to load the DB schema by hand (current). > 3. You get in, but things needs fixing, but *YOU GET IN*. There is > no "cannot see anything so I have to edit a text file" barrier. > 4. You tweak most things via a web interface (theme's, user names, > admin passwords, etc). well written. > The key difference of this approach over other approaches is > *intuitive.* It is not intuitive to do 90% of the tasks, and get 0% > results. This is the case of most programs. Quicken was one of the > first packages that let you go forward with mistakes, and then see > results and then fix them. This was much better than the standard "you > must have everything right before we show the results" approach to > software. > > If you take a step back and think about, Ward's goal's for the wiki wiki > wiki web was to reduce barriers to increase communication. Reducing the > steps to go live, and the possible pitfalls, and making tweaking easier > via the web, follows Ward's goals. > > And I hope by now, some of you have realized that web based > configuration and flat file config are not incongruous. The web > interface must be able to write to a file on that system, and it could > be a .ini-like file. It could be a dbm file or sql call as well. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Oliver B. <ob...@de...> - 2004-01-26 21:40:49
|
Reini Urban wrote: [...] > Persuaded. > But I would like to seperate the config from the startup file. > lib/config sanifies the config settings, so PHPWIKI_DIR."/config.php" > would be fine. Maye I didn't understand what you mean, but isn't this already the case? The (wikiname).php contains the specific settings, and includes index.php. This way I had to set only 'WIKI_NAME', 'ADMIN_USER', 'ADMIN_PASSWD', 'ENCRYPTED_PASSWD', 'WIKI_PGSRC' and $DBParams['directory'] in (wikiname).php I like this. It's simple but absolutely flexible. Or do you only think about putting index.php in another directory? > >>This is much easier to install and maybe easier to maintain then the > > > > Maintenance is harder, IMO. > > > > In which manner do you think the installation will be easier than > > now? > > Most of the local apache/php settings could be calculated automatically. > One should only define if e.g. USE_PATH_INFO = true or false, and the > appropriate VIRTUAL_PATH, DATA_PATH settings can be calculated. Already worked automagically for me, but I'm no expert. > Also applied .htaccess samples > Same for database and authorization settings, which depend on the > available libraries and services. Maybe difficult: if there is more than ony database option? If there is an existing database? Like Zot O'Connor, I also think "that web based configuration and flat file config are not incongruous". Storing the config in some non- php but plain text "database" is o.k., and maybe simpler to process by a web based configuration tool, because it has a fixed format. But I wonder whether such a configuration tool is worth the effort (initial and maintenance). I tried the configurator only once and I had not the impression that it made things noticeable easier than editing a .php file. The index.php is large, but well documented and not too difficult to edit. Maybe it would help to change the order of the entries: first those settings being edited most likely, later the more exotic. Oliver -- Oliver Betz, Muenchen |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X