Do we need an installer?

[lonnieezell]

@mwhitneysdsu @sourcejedi

I've been thinking about this alot lately and have come to a conclusion that the installer might not even be needed. Let me talk this through and see what you guys think here..

1. Since this is for developers, there shouldn't be a problem asking them to fill out the database config file. They would do that anyway.
2. We can leave the system without a working .htaccess file and the 'index.php' left in the config file. That seems to cause issues for a number of users anyway. At that point, it's no different than setting up a standard CodeIgniter application.
3. If the download ships with it set to automatically install all migrations for the core, app and modules, that will handle the database installation.
4. At that point, we can have a migration that adds a simple administrative user with username 'admin', and a simple password like... 'password', which they can login and change after first run.

The only other thing that I can really see the installer doing is checking that certain files are writeable. We could create a very simple controller or even stand-alone script in the install folder that just reports on which files and folders should be writeable and maybe some 'what to do next' text...

What do you guys think?

[SethArchambault]

That works for me! Installers always seem to have a bit of magic to them.. when I started out with bonfire there was always a bit of confusion when moving from development to production, as I wasn't entirely sure what the installer was doing. Overtime I've gotten comfortable with it, but I don't' think I'd miss an installer at all.

[mwhitneysdsu]

Would it be workable to port the installer into a module and check to see if the database config is set to determine whether to run the installer initially? That would at least allow us to reduce the duplicate code maintained in the installer. It might also allow some of the items in the installer to be used again at a later time, if needed, such as changing the database configuration (though I know most developers would be able to do this by hand).

Unfortunately the installer is one area I'm not terribly familiar with, though I've had some experience using it lately and think it has come a long way since I originally started using Bonfire.

[thinkadoo]

From an experience perspective - it really makes a confidence inspiring statement. I remember installing Bonfire the first time and the installer impressed me. Immediately after, the .htaccess dependency disappointed me. So the links from the end page in the installer did not work until I went into config to set index.php. What a let down. From a first impression perspective I would keep the installer (Lithium has a great status page along those lines to compare), but loose the .htaccess dependency. Always think of someone who has never seen it before. First impressions count.

[sourcejedi]

Regarding the initial admin user, I would love to have a CLI option for setup. That would easily support loading a database dump and resetting an admin password, if you don't know the admin password for that dump. It would be nice to have as a fallback method to reset the admin password on a live site, when it's been forgotten. (E.g. if you have SSH access... and haven't forgotten that password!).

The installer is a lot of magic. Attractive magic, but I have difficulty believing in it. I do believe in the alternative proposal. It would still be possible to make it attractive by developing well-tuned documentation.

If there can be a doc for a simple URL method with .htaccess mod_rewrite, that would be cool too. CodeIgniter does not have a great introduction for that. (Not one suitable for newcomers who would be most affected by removing Bonfire's installer).

Some of .htaccess apart from the url rewriting is interesting. The bulk of it is in the "html5boilerplate" repo (despite the name). Hopefully it would be sufficient to link to that.

---

Similar to Seth, I've had some confusion about the role of the installer beyond development. E.g. It seems odd to upload this powerful installer script, that someone _else_could start poking before you finish the install. But if using the installer is optional (e.g. can by bypassed by uploading a database dump generated using the installer), then I (greedily) want to have complete documentation about what the installer does. Otherwise I worry about missing something important that the installer sets up.

Remove the installer as you describe, and it would remove the confusion to my way of thinking.

---

There is a counterargument, parallel with e.g. Linux. Linux distros could get away with just a boot disk, but instead they pour a lot of resources into something people use only once. Because it's a big barrier, and an important first impression. I don't know how to answer that. Except we haven't quite managed to reach that point, which suggests you should reset to the lower-resource option and get the core sorted out.

[sourcejedi]

I like the sound of a "status page" mentioned by thinkadoo though... Check the PHP version. Check write access to the required files and folders. Otherwise we'll get more support requests, not less :).

[mwhitneysdsu]

From what I can see, the bulk of this is currently done by the installer_lib, in the setup() method: 1) Write the main database config and copy it to the correct environment sub-folder 2) Load the database config & connect to the database 3) Load the migrations library and run the system migrations 4) Save the following settings to the settings table (which is created in the system migrations):

• site.title
• site.system_email
• updates.do_check
• updates.bleeding_edge 5) Save the sender_email setting for the 'email' module (shouldn't that be 'emailer'?) 6) Setup the user in the users table as an Administrator 7) Create the encryption_key for the config file and write the file 8) Run the migrations for any custom modules the installer can find 9) Write an installed.txt file into the root of the install directory (the is_installed() method checks to see if this exists)

The rest of the installer (before and after calling $this->installer_lib->setup()) appears to be there to simply check a few potential problem areas (permissions, php version, etc.), collect the data required by the setup, and step the user through the process of collecting that data.

[xcript]

Ok, this issue is old, but I'm currently facing a new challenge for me because of the newly missing installer. The installer was a great feature for me, because I'm not developing a standalone apllication. My application will be distributed frfeely and the users are normally unexperineced in technical web administration. They just want to have fun with the application and it must be as simple as possible to install it.

Ok, I could write an own installer, but the current one was simply ok for me. So I suggest to keep an installer module for the base install of Bonfire. It is working, so why loose this? If someone don't need it, than he simply can ignore it.

[meowsus]

@xcript, you may be confused, as I was at first. 0.7 retains the installer, but it is not in the root directory of the application. It's in /public. What you do is:

1. Clone the installer branch of Bonfire (same as develop, just with the new installer in place)
2. Manually create your database, as before.
3. Manually edit your application/config/database.php file.
4. Navigate to domain.com/public and the system installs itself.

It's easier, gives you a bit more control, and since this feature was announced about 10 days ago, the documentation for it is lacking at this time. Took a bit of digging until I figured it out myself.

I've noticed a few bugs in 0.7 which are making it less-than-production ready. Be sure to fork the repo and contribute when you can! The more people that do this means the better this awesome application becomes! I'm so excited for this to get a v1.0 stable release!

[xcript]

Ah, thanks for the hint to the installer branch! I didn't realized that.

It's too bad to manually edit the database.php, because I used that for my users, which do not have any experince editing files and it was possible with the old installer. Ok, I will develop this by myself.

Of course I contribute and I already have some points described e.g. the timezones. But it's a little bit annoying, thats the forum of Bonfire is really really slow and simple questions are not answered for weeks.

EDIT: Hmm, and where's the difference between the develop and the installer branch? In the installer branch are only two different view files compared to the developer branch. All other files are equal.

[meowsus]

develop has diverged from installer by 3 commits, at this time: https://github.com/ci-bonfire/Bonfire/commits/develop one of the commits was a pull request from me. installer must have been merged into develop at this point.

I don't personally mind editing database.php, especially because I use something like Bonfire to disallow access to these types of files when handing it off to a client... but who knows, your app might be totally different ;)

[xcript]

Thanks! It's a little bit confusing sometimes. Nice cat by the way ;)

[meowsus]

@xcript Thanks. He's fuzzy.

[mwhitneysdsu]

Maybe the installer can display a view to edit the database settings if Bonfire is not currently installed and it can't connect to the database... Then it wouldn't bother if the settings in the database config work, but it wouldn't leave people in the lurch that are expecting it to help them through the process. I haven't had much time to look at the new installer, so I'm not sure if there's something else preventing this from being possible.

[meowsus]

@mwhitneysdsu: This is something that I was looking into adding. I was going to pop a .htaccess file into root that points all requests to /public/$1 so that people on a bare install would see the installer message out of the gate. Then, inside the, installer report box (the one that checks for permissions and php version) I was going to also see if the database was configured. That's when I started looking at the controllers, which do do this validation already, during the do_install method, not index.

I was kind of wracking my brain until I realized I could just pop an index file in the root directory explaining things a bit better. I also thought that might be a better way to start adding to the group, rather than rewriting a big chunk from the get go. It was my first pull request so I wanted to keep it light, and less of a complete restructuring of first thing Bonfire does upon install.

It is on my mind, however... so maybe I'll get back into playing with this in the coming weeks.

[mwhitneysdsu]

It's not a problem, I was just thinking that we could re-use some of the code from the old installer to make people familiar with the previous process a little happier with the new one, while still allowing people to use the manual method if they wish. As I said, I haven't had much time to look at the new one.

I am wondering about the /public/$1, though. I was under the impression that /public should already be the root as far as the server is concerned, so maybe a basic message in the root telling people to update their server's configuration to point to /public instead of the root would be in order.

[lonnieezell]

Adding the check for the database settings would be a good idea. The new installer is using a slightly modified version of the previous installer_lib file to handle everything and, IIRC, included checking the database, but might not be handling it correclty.

I would like to stay away from using an .htaccess file by default, though. Over the years, the one thing that seems to have caused the vast majority of installation issues is people not understanding the .htaccess or how it's supposed to work. Or getting caught in a loop. So, I am trying to get back to a little closer to the raw CodeIgniter install process here to remove that issue.

[meowsus]

@mwhitneysdsu Pretty much what @lonnieezell said. As I looked through the codebase I started to get flooded by these types of questions. "Should we even put the htaccess there", "what does it mean for people if we force everyone into public." Even my intro branch runs into some of these issues.