The Bootstrap

Hi,

Is Victor around? Any word on the bootstrap?

Ryan Thrash (AIM) 10:05
btw
ever get a chance to look at the isntaller stuff again?

Victor (AIM) 10:05
got the installer stuff laid out with its guts on my desktop

Ryan Thrash (AIM) 10:06
progress!

Victor (AIM) 10:06
just need to find the courage to write PHP and finish it

seriously, every time i sit down to write php, i find something more important that I forgot to do

Ryan Thrash (AIM) 10:15
lol
that’s what you get for being a big-time exec at a multi-national tech company

Quote from: xwisdom at Nov 08, 2005, 10:23 AM

Hi,

Is Victor around? Any word on the bootstrap?

Victor is around but has been buried elbow-deep in work More code coming soon, promise.

Sounds great!

Victor made an initial commit that looks solid on the original barebones installer. First step towards handling upgrades based on the existence of an index.php file and the assets directory.

I think this should just probalby check for the existence of the manager/includes/config.inc.php as that’s the real test, but we can do that later I s’pose. You could move over assets, for example from another site on a new uploaded install, and you wouldn’t want to nuke everything...

But I digress... We need to really discuss how to handle upgrades and outline some bulletproof logic. In other words, how do we make sure not to overwrite peoples customized snippets/plugins/modules/images/css files?

I think it’s going to take some interaction with the user during the install process ultimately:

This appears to be an upgrade installation, how do you want us to handle your assets directory?
1) Overwrite everything
2) Only add new files
3) etc.

I’m also a fan of moving the config.inc.php file into the assets directory since that would make for a single place to keep all non-core files.

Thoughts?

maybe to something like assets/config/config.inc.php?

The assets/config folder should not be visible from within the file manager

Maybe we should ask users to make the assets/config folder writable?

What about making an assets/system directory.

In it could go the config file, and manager themes. By manager themes, I mean non-default ones.

Hmmm manager themes. This would mean that we now have two places to look for manager themes.

Nah manager themes should stay inside the manager folder.

I tend to think that anything that deviates form a non-standard install should go in the assets directory (or some other such name). This would make it more simple to make a portable site by having a DB dump in assets (or other name) folder, and move that one folder to your new site with a fresh install, only having to run an install routine to set up the database.