New Installer

Registered by fisharebest

We need a replacement for install.php

It needs to be simpler. I propose reducing it to three parts. DB connection, SMTP setup, create admin account.
The DB and SMTP settings need a "test" button, so the user can check the connection/mail setup before proceeding.

It should do a better job of checking for server-requirements (memory, loaded modules, etc.) and explaining the consequences to the user.

It also needs to handle upgrades/imports from existing PGV installations.

We should also replace config.php with config.ini. Instead of loading config.php, each script will load session.php, which wll read config.ini. This will simplify lots of the "are we allowed to see this page" logic in session.php, which really belongs in the individual pages. It will simplify the task of moving config.ini to another location (session.php can use a search path).

The application will ship without config.ini. session.php will use the existance of this file in the same way that the current $CONFIGURED global is used.

Blueprint information

Status:
Complete
Approver:
webtrees team
Priority:
High
Drafter:
webtrees team
Direction:
Approved
Assignee:
fisharebest
Definition:
Approved
Series goal:
Accepted for trunk
Implementation:
Implemented
Milestone target:
None
Started by
fisharebest
Completed by
fisharebest

Related branches

Sprints

Whiteboard

I would like to take this opportunity to make the following changes:

Move configuration settings from the old config.php file to the wt_site_setting table. [DONE - but no edit screen yet]

Move pending changes from the old pgv_changes.php file to a new wt_pending_changes table.

Move logging from files to a new wt_logs table.

Eventually, I also want to move the *_conf.php and *_priv.php data to the database. This will require a little more analysis, as we fetch some values many times, and we don't want to run the same database query repeatedly.

[volschin] IMO the log files should be left outside the database

[greg] I can easily allow both, by adding "database" to the current "daily/monthly/weekly/none" options.
Why would you want them in files? I don't see the advantages. In a table, you can sort/search/filter. You can display data by page (SQL OFFSET/LIMIT). You can purge all/old/unimportant messages. etc.
[volschin] I don't have a really good answer on this, except that it is common practice. The handling and backup of the logs is easy and sometimes the storage in provider accounts is much smaller for databases than file system.

[stephen] Greg, will this then be the long requested "Log Central" concept too? Logs all over the place never made any sense to me.
[greg] Yes. The long-debated request http://sourceforge.net/tracker/index.php?func=detail&aid=1399910&group_id=55456&atid=477082 that was vetoed in PGV

[lukasz] I have a small script with logs. I've already committed it to SVN 7827.

Latest SVN adds database logging (by default) and a new database log viewer (admin->site admin->logs)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.