Testing
To get a Windows testing environment you can download a virtual hard disk here:
http://technet.microsoft.com/en-us/bb738372.aspx
These downloads appear to be fully functional installs that expire after 180 days.
To do
- Integrate into release process
Limitations
WebPI cannot execute custom code, be it PHP or anything. There is no communication between WebPI and the installed Tiki, except some prompted values going in files (currently only local.php). The main problem is that the choice of installing on an existing database or creating a new database makes no difference but to create the database or not (the same SQL files are ran either way) and cannot be communicated to Tiki. There is no way to disable installing on an existing database.
The original 4.1 WebDeploy package we were given by Microsoft did not run the Tiki installer at all and simply ran an SQL file similar to tiki.sql. This couldn't happen when installing to migrate an existing Tiki site, on an existing database, so had to be scrapped. The solution is to use the Tiki installer. The main drawback is that the install is longer. When the WebPI part of the install is done, WebPI links to a predefined URL, which we use to tell the Tiki installer that this is a WebPI install (this is important because the local.php is particular). But the URL is constant and does not allow to authenticate the admin as the one who installed. Therefore, the first Tiki screen seen is a Security precaution asking for database credentials.
It would be possible to optimize by considering that if the database has no tables, it is a new install.
Issues
Upgrades are done by installing a newer version.
Updating/packaging
Files for the package are in SVN under tikiwiki/webdeploy/.
The WebDeploy package is a ZIP file containing a Tiki tree plus 4 files. In the root of the archive are 3 of these files and the directory of normal files, called tiki. The fourth file is db/local.php and goes at its usual place, in tiki/db/local.php. The structure is therefore:
- install.sql
- manifest.xml
- parameters.xml
- tiki/
- db/
- local.php
- ...
- ...
- db/
Warning: The archive must contain this hierarchy directly, it must not contain a directory containing this structure, otherwise WebDeploy will fail cryptically.
To submit a new package, a SHA1 sum must be calculated. SourceForge provides it after the file is uploaded in the file information. FCIV can do it too.
Upload the file to SourceForge, then submit a package update to Microsoft.
Related links
- http://www.iis.net/learn/develop/windows-web-application-gallery/package-an-application-for-the-windows-web-application-gallery
- http://www.microsoft.com/web/downloads/platform.aspx