If you are interested in creating your own web-app packages (such as a custom package of WordPress with various themes and plugins integrated and enabled) that are then “one-click” easily (for deployment) and repeatably (for testing) installable to any website and URL, WampDeveloper Pro provides its own web-app packaging format and installation mechanism…
The web-app installer reads and executes commands (that it understands) from an XML file – performing the task of placing, importing, editing, and manipulating web-app assets (files, configuration, database entries). With the purpose of creating an “installation” that is [ideally] identical and indistinguishable from a regular install.
The principle difference between WampDeveloper’s web-app installer and the web-app’s native setup/installation process is:
Native setup/installation – runs through the web-app’s PHP code, and forms the database, populates that database, and updates the configuration file.
WampDeveloper’s web-app installer – bypasses the above process completely by placing the files, importing the already formed database, and using the website’s path and URL, updating the configuration and database entries to reflect the new location.
To create a web-app package:
Web-app Assets
Create the needed assets for the installer to start with…
1. Manually install a web-application using these default values:
website: www.example.com
username: admin
password: passadmin
email: admin@example.com
mail: mail.example.com
DB name: webapp
DB user: webapp
DB host: 127.0.0.1Technically you can use any values you’d like, but the above will be considered as standard. These values will later be changed by the auto-installer using the selected website, URL, and the generated DB name + user and Admin password.
When installing the web-app, try not to go pass the finish of the installation process – by accessing the home page and/or performing a login. If you do so, the web-app will likely create sessions, caches, temporary files, and database entries, that might need to then be cleaned up.
2. Perform a clean up by deleting any created:
A. Sessions - e.g., truncate table "sessions"
B. Caches - e.g., truncate tables "cache_*"
C. Watchdog (log) - e.g., truncate table "watchdog"
D. Any cache and temps files - e.g., files in web-app's "temp" sub-folderThis step is not necessary, but it is considered good to not leave any residual fingerprints and data.
3. Export the web-app’s database into an SQL file, and zip the file as: \database\database.sql.zip
4. Select all the web-app’s files (but not the containing folder), and zip the selection as: \files\files.zip
5. Copy the web-app’s configuration file(s) into: \configs
Package Format (Example)
All the web-app packages are stored in folder:
\WampDeveloper\WebApps
If you take a look into folder \WampDeveloper\WebApps\wordpress-4.0.0.0-r1\ , next to the base assets, there are three XML files that define and control the installation of WordPress.
All other files/folder within are just things referenced and used by tasks.xml (WampDeveloper only knows about the 3 XML files).
1) tasks.xml: which defines what to do to install the package (and move it to another URL, delete it, etc).
2) parameters.xml: which defines the variables and defaults (such as “db_host” is to be “127.0.0.1″ / localhost by default), that will be used later in tasks.xml.
3) profile.xml: which just defines the name, version, and some other “info” data about the web-app and package.
Installation Tasks
The way it works is tasks.xml:
a) Imports \database\wordpress.sql(.zip) into MySQL.
b) Imports \files\files(.zip) into the install-to directory.
c) Imports \configs\wp-config.php into the install-to directory (or where WordPress expects to find it).
d) Performs SQL queries to create the proper database name, database user, and update the database with the proper values for the new URL, path, etc.
e) Performs file edits to update wp-config.php with the proper values for DB name + user + host, keys and salts, etc.
f) Runs a script (scripts\setPassword.php) that uses WP’s API (functions) and a passed-in command-line parameter to set the admin password.
Creating Web-app Package
If you have the time to study the format/syntax of the above XML files, you can create your own packages. The difficulty of it is that none of this is fully documented for the moment, as it’s all still evolving. And if it’s not done correctly, it’s just going to fail without providing any type of useful error message.
If you wanted to create your own WordPress package with your additional configuration, content, themes, and plugins included, just install WordPress (and additions) into: www.example.com\blog. Then, as shown above: export and zip the database, copy the wp-config.php file, zip up the files, and replace those assets within a duplicate of the already provided WP package (i.e., in a copy of the provided webapp-version package – with the folder name updated for version and release number). Afterwards make some minor edits to profile.xml and tasks.xml to reflect the new version and possibly any new changes.
Uses
Create auto-installer for the latest version of web-apps such as Wordress.
Create auto-installer for any PHP Framework such as CakePHP, CodeIgniter, Zend.
Create auto-installer for any Frontend HTML + CSS Framework / Template such as Bootstrap.
Create auto-installer for any Javascript MVC Framework or Library such as AngularJS.
Create auto-installer for executable (binary) applications such as Node.JS.
Create auto-installer for an entire website (including its databases).
Create auto-installer for full Windows applications, including IDEs (editors).
Create auto-installer for Mobile Frameworks such as Ionic.