Issue: Utilize the VaultWiki Install System Elsewhere

Couldn't handle waiting for this. Working on this currently.

Already made the changes to the Javascript for infinite levels of sub-steps which are now counted automatically as long as the version/step files are written correctly. The changes raise the PHP requirement to 5.3 since it requires using anonymous functions (even nested anonymous functions).

The changes also assist in making upgrade scripts easier for developers to write and maintain, since the functions don't have to be named by step-number, and the functions don't need the step-number hard-coded any more.

However, now I have to go back and make sure all the old upgrade scripts are properly updated. Unfortunately, there's no regular expression replacement that I would trust to make these rather fundamental changes.

Finished updating the upgradepath folder to reflect the changes to the step format. Attempted manually for a while, then wrote a bunch of regular expressions and fixed the errors manually.

On another note, good thing I decided not to wait on this. There were a number of bugs in the system and some version scripts as I converted them last year.

Up next:

• move the install/upgrade system into the MVC locations
• make a generic progress indicator class

Finished moving the install files into the appropriate MVC folders. The classes and calls all had to be renamed to fit the rest of the naming conventions, and vw_Hard_Core was updated to reflect the changes. Further, back-references were created between the phrases, views, controllers, and the various levels in order for each class to know the current progress. This fixed some issues with version tracking when the page refreshed and is better suited for CLI extension. There are still some issues where certain functions might be best moved for better MVC organization, and other functions should be proxied for CLI extension in the future.

Just had a thought.

Current the upgrade system works like this:
1. Installer calls generic upgrade instance (upgrader).
2. Upgrader finds the appropriate next version and initializes a version instance which extends the upgrader.
3. The initialization of the version instance populates an internal this->steps array containing anonymous functions that do the work.
4. The upgrader calls the step from the version instance, if the array key of the function in version->steps matches the requested step.

A problem arises now when we want to extend the upgrader for CLI or something like that when we may have extended the upgrader already based on the dependency. Extending the CLI likewise would be inefficient in terms of code maintenance.

But what if it worked like this:
1. Installer calls generic upgrade instance (upgrader).
2. Upgrader finds the appropriate next version and gets the needed steps from the version class via its own get_steps function.
3. The upgrader calls the step from its own instance, if the array key of the function in this->steps matches the requested step.

The difference is that the version instance does no work on its own, it just contains the function definitions. So it doesn't need to be an extension of the upgrade class. Also, we don't need to construct so many version instances. This also succeeds in keeping the current version and step information accessible because the work is done at the upgrade-instance level.

It may not sound like much of a change but it requires a rewrite to a lot of things yet again, and it will result in both smoother functioning of the installer/upgrader and more straightforward code design than the existing implementation.

For tomorrow.

All steps moved to a separate steps class and sub-classes. Upgrader no longer calls itself recursively. This also allowed removing about 60 files whose only step was to update the current version (version is now handled separately from the steps).

After dinner, now to somehow make the progress indicator its own generic class.

Probably not perfect, but definitely enough to be usable again in the future. Closing this issue.