Ticket #123 (closed defect: fixed)

Opened 21 months ago

Last modified 16 months ago

Configuration file

Reported by: fboender Owned by:
Priority: immediate Milestone: MvBlog 2.1
Component: global Version:
Severity: Keywords: config
Cc: michiel

Description

The default configuration file (common/hosts.php) is kind of unclear. I wasn't sure what to edit without doing some trial and error and refering to the sourcecode of the rest of MvBlog. I propose a standard configuration file in the .ini style. Every option/variable should be heavily documented so that newby users know what to do.

Change History

  Changed 21 months ago by michiel

  • priority changed from major to blocker

raising priority because I heard this complaint more. Today I had to tell someone who can install Wordpress without me helping how to setup the hosts.php file.

This blocks the next release.

follow-up: ↓ 3   Changed 21 months ago by sofie

Regarding this install... People should be able to config the whole thing via an url they have to type Upload the mvblog package on there server browse to an url and basta... like the phpbb install.. easy as a piece of cake Not to modify any sort of file and such.. some people want to blog but don't know how.. they grab to wordpress cause it's just easy with big letters.

in reply to: ↑ 2   Changed 21 months ago by fboender

Replying to sofie:

Regarding this install... People should be able to config the whole thing via an url they have to type Upload the mvblog package on there server browse to an url and basta... like the phpbb install.. easy as a piece of cake Not to modify any sort of file and such.. some people want to blog but don't know how.. they grab to wordpress cause it's just easy with big letters.

Agreed. A web-based configuration would be the best. The current configuration is not adequate. I even had to do some programming on common/hosts.php (case "dev":) so that it recognised my hostname. Fine enough for me, but not for the non-PHP programming user. The ultimate way would be to have a Unix-styled configuration, where you simply edit a configuration file and be done with it, as well as having a web-based configuration front-end (to the same configuration file?)

in reply to: ↑ description   Changed 20 months ago by fboender

I've commited an initial version of the Configuration reader. It's ini style (no sections yet). The config is in /conf. Changeset: r414

Todo (mostly for myself):

  • implement mvblog_IniParser->setSettings()
  • Exception handling in caller (mvblog.php) with nice userfriendly error messages.
  • PHPDoc comments.
  • Transfer old configuration to new ini style. (ongoing task?)

in reply to: ↑ description ; follow-up: ↓ 6   Changed 20 months ago by fboender

  • cc michiel added

Michiel, why does MvBlog even need a setting for the hostname it's running on? Autodetecting it from the $_SERVER should be possible, right? Am I missing somethin ghere?

in reply to: ↑ 5 ; follow-up: ↓ 7   Changed 20 months ago by michiel

Replying to fboender:

Michiel, why does MvBlog even need a setting for the hostname it's running on? Autodetecting it from the $_SERVER should be possible, right? Am I missing somethin ghere?

detecting it from $_SERVER is what I thought was implemented. What we do now is use this $_SERVER array value to get to the correct database. Where did you find the hostname config var ?

in reply to: ↑ 6 ; follow-up: ↓ 8   Changed 20 months ago by fboender

Replying to michiel:

Replying to fboender:

Michiel, why does MvBlog even need a setting for the hostname it's running on? Autodetecting it from the $_SERVER should be possible, right? Am I missing somethin ghere?

detecting it from $_SERVER is what I thought was implemented. What we do now is use this $_SERVER array value to get to the correct database. Where did you find the hostname config var ?

common/hosts.php? I have to add my hostname to this and uncomment a DSN before mvblog will work. For instance, I've got MvBlog installed on www.debauchery.nl, and I have to add 'case "www.debauchery.nl"' to hosts.php before it will work.

in reply to: ↑ 7 ; follow-up: ↓ 9   Changed 20 months ago by michiel

Replying to fboender:

Replying to michiel:

Replying to fboender:

Michiel, why does MvBlog even need a setting for the hostname it's running on? Autodetecting it from the $_SERVER should be possible, right? Am I missing somethin ghere?

detecting it from $_SERVER is what I thought was implemented. What we do now is use this $_SERVER array value to get to the correct database. Where did you find the hostname config var ?

common/hosts.php? I have to add my hostname to this and uncomment a DSN before mvblog will work. For instance, I've got MvBlog installed on www.debauchery.nl, and I have to add 'case "www.debauchery.nl"' to hosts.php before it will work.

You have to do this because mvblog is designed with 'one codebase, many blogs' in mind. My server runs it like this: mvblog is in /usr/local/share/mvblog I have 8 domains running mvblog, all seperate websites/blogs.

In the hosts.php I put an entry for every website so the codebase knows what database to use. If you have a better way to do this please enlighten me ;)

in reply to: ↑ 8   Changed 20 months ago by michiel

Talked this one over with fboender on irc. Every blog should get their own conf/ dir with mvblog.ini as config file. That way the config is going out of the shared codebase, but it makes it possible to create an installer for it. It will also make it easier for people to just install MvBlog on their shared hosting account or whatever. Not much stuff to do for this to happen. The only settings we have now is the database connection.

Once this is converted we can implement more stuff.

  Changed 19 months ago by michiel

(In [464]) Introduce sections in the ini config file.

Re #123

  Changed 19 months ago by michiel

(In [465]) lets use the .ini settings if they are there ok ? Re #123

  Changed 16 months ago by michiel

  • status changed from new to closed
  • resolution set to fixed

common/hosts.php is not used anymore. Simply edit conf/mvblog.ini and be done with it.

If the webbased configurator is still wanted put that into a new ticket :)

Note: See TracTickets for help on using tickets.