New Installer
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
Related bugs
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/
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://
[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)