Welcome Guest, Not a member yet? Register   Sign In
Create a custom MySQL connection error

Bonfire used to do most of that stuff, except for deleting the installer. In the last couple of years, it has been simplified quite a bit, primarily removing the database-related functionality.

I believe the main reasons for removing the database-related functionality were that it was difficult to support the flexibility of the database config file, write the file, and validate the user entry (plus it's a pretty major potential security issue to worry about if you can write to the database config file).

It's also useful to have a page in the admin area of the application to display the results of some of the checks in many cases (for example, Bonfire's sysinfo module displays the Bonfire and CodeIgniter versions, PHP version, server/local time, database info, various paths, site_url(), environment, and whether a configurable list of directories/files are writable (by default the cache, logs, and config directories and the application and database config files are in the list).

The is_really_writable() function is usually all you need to check file/directory permissions.

As for where the code should go, I would recommend a couple of things:
- Isolate the majority of the code, especially anything that writes to a file or the database (especially creating the admin user)
- If you want to share some code between the installer and another part of the application, and you don't want duplicate code, put it in a library or helper that can be loaded by the installer and anything else that is going to use it.
- Setup a method of easily enabling/disabling the installer for development
- If you're going to have the installer self-destruct, setup a method of easily disabling that feature for development
- On first login, remind (or force) the admin to change their password and/or username
- You may want to put a reminder on the default admin page to check the configuration for common security issues and ensure the installer is not placed on a live production site (or, depending on the needs of the application, check these in the code and warn the user accordingly)

Just to give you an idea of how Bonfire handles the installer, especially since it can be difficult to figure out how the installer is loaded and run in the first place:

The root index.php displays a welcome message, tells the user to create the database (they don't have to create any tables, but the database has to be created) and edit their database config file. It also displays a warning that their site is not configured correctly, with some information regarding configuring the site to point to /public/index.php.

Once they have the site configured to point to /public/index.php (or they've moved things around and updated the directories in the index.php file if they can't place directories and files outside their web root), Bonfire's default controller loads the installer_lib to check whether the site is installed, and, if not, temporarily disables hooks and redirects the user to the 'install' controller, which manages the installation.

Bonfire is configured by default with a pre_controller hook which normally saves the requested page in the session data (for use after login if the page requires authentication). The constructor of the class in which this hook (and all of Bonfire's built-in hooks) resides looks for a config item named 'bonfire.installed', which is set by the installer near the end of the installation process. If it can't find it (or the value is not truthy), the installer_lib is loaded to do a more comprehensive check to determine whether Bonfire has been installed. The only thing the hooks really do with this information is disable the use of sessions in the pre_controller hook, since that hook will fire before the default controller has a chance to determine whether to redirect to the install controller (and will fire again before the install controller is loaded).

The install controller disables hooks and disables session use in the Template library, then loads the installer_lib and some other libraries/helpers/language files. The first page of the installer checks the PHP version and whether certain files/directories are writable, instructing the user to verify the configuration and follow the link to the next page (install/do_install).

The next page checks whether the application has been installed, and exits with an error message if it has (because allowing an arbitrary site visitor to run the installer again would be bad) ('This application has already been installed. Cannot install again.'). Next, it checks whether the installer could verify the database settings, and displays an error message if it could not ('Unable to locate proper database settings. Please verify settings and reload the page.'). Finally, it runs the setup() method in the installer_lib, which loads the database, installs the Bonfire migrations, configures some site settings (these used to be passed in via a form in the installer, but now it just sets some defaults), and creates the admin user. Then it runs any application module migrations it can find and writes out a text file in the config directory and the 'bonfire.installed' config value mentioned earlier, both of which are used to tell different parts of the application that Bonfire has been installed.

Finally, it displays the username and password for the default admin account and gives the user some useful links (to the admin page, the public page, the docs, and the CodeIgniter docs).

Messages In This Thread
RE: Create a custom MySQL connection error - by mwhitney - 10-20-2015, 11:55 AM

Theme © iAndrew 2016 - Forum software by © MyBB