ezrpg-legacy / ezrpg-2.0.X-discontinued-

http://ezrpgproject.net
Other
6 stars 0 forks source link

Combine Installer with Update system #22

Open uaktags opened 10 years ago

uaktags commented 10 years ago

So I was thinking about the installer this morning in terms of both the one Jake made for ez1.x and now the new one for ez2.x, and how we could possibly use it for an update system.

Currently the installer is a one and done module that as soon as it's used, the lock is created or the admin must delete it (in case 'locked' wasn't made). Personally I think this is a waste of a system that could possibly be expanded in some area long as the right systems are built in.

What I would like to look into, is expanding the installer to follow a set of instructions to determine if we're installed or not, and allow the user to decide where to go from there. A simple idea would be...

  1. Module/Installer checks if config.php is created
    1. If config.php exists check for Admin (requireAdmin() ) or whatever func we have now.
    2. if config.php doesn't exist we're obviously installing new
  2. Next step is to show License just as we have it. That's not going to change again with the project AFAIK so it's safe to put it here as static.
    1. [SKIP if Updating] Run through installer as normal all the way through Admin IF config.php didn't exist in 1.2
  3. Parse config.php for ezRPG version installed (personally i'd like a variable like $this->_version to hold this value) and then check for updates
    1. Updates could be held in a folder like Module/Installer/Updates and be labeled ez2.0-2.0.1-updates.zip. [Read later for an idea of what this file includes]
    2. Updates could also be checked against ezRPG Repo and will download ez2.0-2.0.1-updates.zip to Module/Installer/Updates
    3. If no Updates, then move to step 7.
  4. Update file is extracted, Module files are moved to respected locations and the next step is to run .sql file
  5. SQL step tells admin that there will be changes to the database. Perhaps show a print of the .sql file and allow the admin to Accept these changes, the system will the execute it for them.
  6. Everything is now installed. $this->_version is set to latest version and the games can begin.

ez2.0-2.0.0-updates.zip should contain a strcuture that mimics are own webroot for the engine:

/update.sql /readme.md /Modules/ /Web/ /Theme/ /Library/

Personally I think caution should be taken with Theme files, as people tend to edit these. Which is why I believe in shipping a standard "boilerplate" theme and having it be a standard practice that you clone and edit that, for all of our work will be based off of that boilerplate so it will be re-overwritten by us when need be.

update.sql should be just a sequence of Alter Tables, since we checked for an installed version, and we never made it to the Updater without first making sure a base version of some sort was created.

We'll have to rethink how our checks and routes will go as right now its hardcoded in for the installer and checks for locked (yuck). We could just be checking for _version, config, and admin i think.

So that's my idea, what do you guys think.

JakeBooher commented 10 years ago

This is planned when we have future versions, the main index will give you an option to install a new version, or update from an old version (if there is already a configuration file written).