sifbuilder.com is the site of sifbuilder, a framework and open source program that enables the declarative definition and automatic generation of web sites. The site is functionally described here and has been automatically generated with one single instruction.
'now will I tell the purpose of the sifbuilder functions and the functions in their order': the automatic generation of sites from a XML site definition specifying constituting modules, blocks, themes and content, and based on various core CMS -the specification files are located in the sibs folder in the sifbuilder distribution-; association of modules and themes to specific site profiles; management of dependencies and conflicts between modules and site components; structure the actions constituting the creation of a site; access to the functions of the cores and modules from the command line; comparison of the version of installed packages against that of the most recent releases; update of modules in a site with those most recently released aiming to the automatic update of web sites; backup and restore of web sites; cloning of sites using site backup, restore and site configuration; generation of a module based on the XML representation of the relational schema as a means to automate the development of a Web application building of the functions offered by the CMS cores; installation of sites on remote hosts through SSH connections; creation or removal of multiple sites using use cases.
These examples assume the configuration of target hosts and sites in ../sifbuilder_local/sifnet_config.php. Examples of those definitions can be found here. Omitting -v and adding --expandsiteparams option, the command is shown in simulated mode. Without -f, specification of the target site can be done interactively through the command line.
Using sifbuilder is risky and can result is substantial data loss. Never use sifbuilder without a backup done and the knowledge to restore it. Once said that, the sifbuilder site is regularly updated and maintained using sifbuilder.
Restores in force mode the
database and file system from the latest backup tar with the backuped
siteParms :into the sbd502_at_localhost pre-cleaned site
Configures the site with the drupal47_core_drupal core with the new
siteParmas
Restore with pre-cleaning (ie.
create from new) the sbd502_at_localhost from the
bck_pod__sbd501_at_localhost.zip backup with post configuration by the
core
Clean sbd501_at_localhost site
and test sbd502_at_localhost at http://localhost/sifbuilder/d502
postnuke
create
php sifcmd.php b
--sifpacksdir=../sifbuilder_local/packages
--sifnetconfigfile=../sifbuilder_local/sifnet_config.php
--sifnetsite=sbpn501_at_localhost
--siburi=./sibs/sib_PostNuke08_sif_sif.xml --dev -x -f
Creates in force mode the
http://localhost/sifbuilder/pn501 site
Pre empties the pn501 database and pre removes the
d:/webroot/sifbuilder/pn501/ folder
Restores in force mode the
database and file system from the latest backup tar with the backuped
siteParms :into the sbpn502_at_localhost pre-cleaned site
Configures the site with the PostNuke08_core_postnukecore with the new
siteParmas
Restores in force mode the
database and file system from the latest backup tar with the backuped
siteParms :into the sbx502_at_localhost pre-cleaned site
Configures the site with the XOOPS20_core_xoops core with the new
siteParmas
Restores in force mode the
database and file system from the latest backup tar with the backuped
siteParms :into the sbj502_at_localhost pre-cleaned site
Configures the site with the joomla1_core_joomla core with the new
siteParmas
When in 2004 sifbuilder moved from an oscommerce contribution to a
multi core site generator, it lost carine's
kind comments and had to look for a host server. At that
time, sourceforge supported the
distribution of os programs and was introducing the web,
shell and database services for hosted projects. Access to shell
services was available through SSH connections authenticated with
SSH2 keys. sifbuilder supported the automatic generation of web sites
on the localhost and those requirements seemed reasonable to try to
automate the installation of sites on remote hosts, such as those of
sourceforge. This was done introducing the sifnet concept based on the
sifnethost, sifnetrelation and sifnetsite entities.
A sifnetrelation establishes a relationhip between a lochost -usually
instantiated by the local devhost- and a nethost -usually a remote host. This note
will take as motiv the installation of a site on a nethost instantiated to
sourceforge defined by the sfhost class in the sifnetconfigfile file-.
The sifnetsite describes the site to be installed on the nethost.
The relation is reflexive and transitive but, unfortunately, not commutative.
The non equivalence may be read as 'having the site hosted on Linux matters'.
Currently, a sifnetrelation is based on a SSH connection -in the
case of sourceforge, the connection is controlled by a SS2 pair
of keys-. The origin of the relation -identified by the lochost- is a
winbox hosting the sifbuilder development package; the destination point
-identified by the nethost- is a Linux host offering the following services:
a shell to the sifdir where the sifbuilder package will be transferred to,
a database hosting the remote site database, and a webdir hosting
the remote site file system.
On the origin winbox, we have available a SSH client -ex. putty
among various ssh
clients - and a tar/untar tool -in our case 7-zip - and we
have created the private and public ppk keys following the sf instructions.
The information on the lochost, the nethost, the sifnetsite and the
type of sifnet relation (SS2 keys or login/password) is passed to
sifbuilder in the sifnet_config.php file. A model of this file is
included in the sifbuilder root folder. Normally, the customized file is
stored in a parallel file tree as defined with the --sifnetconfigfile option.
The following classes show the information assigned there.
The sfhost describes the target host at sourceforge. It extends a sifnet_linux_host
and this a sifnet_host.
The devhost describes the local host, including the syntax of the
local php, tar and remote exec commands.
class devhost extends sifnet_windows_host
{
var $hostParams = array(
'hosttype'=>'windows'
,'access'=>'local'
,'userdir'=>'.\\'
,'sifdir'=>'.\\'
,'webdir'=>'D:\\webroot\\htdocs\\'
,'downloadsdir'=>'D:\\webroot\\htdocs\\downloads\\'
,'packagesdir'=>'D:\\webroot\\htdocs\\downloads\\packages\\'
,'host_domain'=>'localhost'
,'user_login'=>''
,'user_pwd'=>''
,'user_key'=>''
,'php_bin'=>'php '
,'zip_bin'=>'"C:\\Program Files\\7-Zip\\7z.exe "
a -tzip '
,'unzip_bin'=>'"C:\\Program Files\\7-Zip\\7z.exe"
x '
,'rexec_bin'=>'D:\\BIN\\plink.exe '
,'rcp_bin'=>'D:\\BIN\\pscp.exe '
);
}
The sfhost describes the remote host, including the syntax of the
remote php, tar and remote exec commands, and the location of the SSH2
keys to be passed to the SSH client of the local host.
The remote site describes the site to be created on the remote host.
This instance describes the structure of a sourceforge site but mirrors the
structure and semantics of any site created or updated with sifbuilder.
To create the site on the remote sourceforge host server for a
sourceforge project, we follow the following steps. Note that, when running in
sifnet mode, the -v option launches the sifnet command in real mode. Without that
option, the translated command will appear in simulation mode. Before
running any of those commands, pick up any of the disclaimers in here and apply them to
the rest of the note. Age quod agis.
Test the connection to the remote host with the ac001h admin case, as
described in sifnet_usecases.php:
>php sifcmd.php a ac001h
--sifnetconfigfile=../sifbuilder_local/sifnet_config.php
--sifnethost=sbhost -v
This command will list the entries in the home dir in the remote host. Since the
local sifbuilder distribution may have changed because of the development
process or because new installation packages (sip) or installation profiles (sib)
have been added, we create a new distribution. We create it with
Up to here the steps followed to create each new sifbuilder release package to be
ftp uploaded to the sourceforge incomming area.
To create the remote site, we upload the tar file, located in the
./siftmp/tmpUplaod folder from the sifbuilder distribution root, to the remote host.
As it appears in that command and most of the examples of the site, the
local sifnet config file is located in a parallel file tree. The same
happens with the site packages that constitute the generated site. This
is the time to create it. It can be done connecting to the site or with
>php sifcmd.php a ac001i
--sifnetconfigfile=../sifbuilder_local/sifnet_config.php
--sifnethost=sfhost -v
Since we want to use a single and locally edited customized config file, we
upload it to the remote sifbuilder_local/ folder:
> php sifcmd.php a ac023
--sifnetconfigfile=../sifbuilder_local/sifnet_config.php
--sifnethost=sfhost -v
sifbuilder takes care to download
the site packages required to build the site. However, sourceforge does
not allow establishing an outgoing httpd connection. It is therefore
necessary to upload them to the sifbuilder_local folder. First we copy
them to siftmp/tmpUpload/packages folder -since we plan to create a drupal
site using the sib_drupal5_sif_sif.xml sib, we copy the site packages
that correspond to the drupal5_core_drupal, drupal5_mod_views and
drupal5_mod_site_map installation packages (sips) - and run
Running a sif command with -x means erasing the target site file system
and dropping all the tables in the target database. -f means doing that
without the predefine settings and without the possibility to fix
them. -v means confirming those options in a remote site. Collect
all the disclaimers in the site above before doing this.
The difference between that command and the usual sif commands
used to generate a local site resides on setting the sifnethost option.
By setting the sifnethost option the command is translated
into a remote instruction, in this case the command that creates the
remote target site.
If the -v option is ommitted, the remote command is shown but not run. It shows
The result of these steps was a sourceforge site available here,
until it was removed in the natural course of things.
The sifbuilder site was created and is regularly maintained following this process.
if not automatic, the process is systematic. And every systematic process requires
a table of definitions.
domain
terms
definition
hostparams
usedir
root folder of the use work
environment. Usually, the sifbuilder tar will be downloaded to this
location.
sifdir
folder containing the working
sifbuilder distribution. Usually, the result of exploding the
sifbuilder tar to this location.
webdir
folder containing the root to
the web environment.
access
type of authentication,
currently ssh2key or ssh2pwd.
siteParams
--site_name
folder under the webdir that
will contain the target sites.
--site_pod
folder under that the site_name
folder that will contain the specific target site. Plays, in a certain
way, for the file system, the role of the prefix in the target database.
runParams
--sifpacksdir
indicates where the site
packages (core, modules
and themes) are downloaded. By storing them outside the
sifbuilder folder, updating new versions of sifbuilder will not remove
them.
--sifnetconfigfile
points to the file hosting the
classes
describing the target sites referenced by sifnetsite. The sample
sifnet_config.php
is included in the sifbuilder root folder. It should always be adapted
to the local configuration before starting using sifbuilder.
--sifnetsite
refers to the class in the sifnetconfigfile
with properties the site configuration options typically set during the
installation of a new content management site. They coincide with the
elements in the sifSiteParams.xml file in the sifbuilder root. Having
these options on
file permits to refer to each site configuration by name. Wrong setting
of those
options may erase a whole system. No need to look for a demonstration.
--sifnethost
refers to the (usually remote)
host where the sifcommands will be run. By setting this option, the
normal sif commands are translated into remote execution commands using
the information in the associated class defined in the sifnetconfig
file.
-x
may be added to the command to
remove the site root and
empty the site database before starting the installation. Do that only
if you have the possibility of and know how to restore your working
environment.
-f
may be used to force the
execution of the command in
non-interactive mode. It can be used and will be used if you are a
programmer when you know to be in control of what you are doing.
-v
sifnet commands are run on the
nethost by default in simulation mode. When the -v option is set,
they run in real mode.
Let's address this issue once more with the same principles but with
different manners. First we will create a local site pod. Then we will
backup it to restore it back with precleaning. Finally, we will clone a
new site from an existing one. The sample site will be based on a
drupal core. It could be as well a joomla, postnuke or xoops core.
To create the site locally, we suppose that it is defined in
sifnet_config.php pointed by sifnetconfigfile. The fundamental
importance of defining the target site properly, particularly when the
sif commands are run with the -f, -v and -x options, is indicated here
. If the implications of wrongly defining the target site are by now
not yet clear, do loop here
.
The running environment, the web server and the database server are
in place.
The latest version of sifbuilder has been downloaded
to a local folder.
Site creation
The following creates the site as defined in sib_drupal47_sif_sif.xml
(try to understand why -f -x options are useful and even then do not use them).
The sip_build_site
is the sif command for the installation of modules or the creation of a
complete site. sip_build_site is shorcut by 'b'.
--sifpacksdir indicates where the site packages (core, modules
and themes) are downloaded. By storing them outside the
sifbuilder folder, updating new versions of sifbuilder will not remove
them.
--sifnetconfigfile points to the file hosting the classes
describing the target sites referenced by sifnetsite. The sample
sifnet_config.php
is included in the sifbuilder root folder. It should always be adapted
to the local configuration before starting using sifbuilder.
--sifnetsite refers to the class in the sifnetconfigfile
with properties the site configuration options typically set during the
installation of a new content management site. They coincide with the
elements in the sifSiteParams.xml file in the sifbuilder root. Having
these options on
file permits to refer to each site configuration by name. Wrong setting
of those
options may erase a whole system. No need to look for a demonstration.
The --dev option makes installation packages related to
development cores or modules be considered during the site generation
process
-x may be added to the command to remove the site root and
empty the site database before starting the installation. Do that only
if you have the possibility of and know how to restore your working
environment.
-f may be used to force the execution of the command in
non-interactive mode. It can be used and will be used if you are a
programmer when you know to be in control of what you are doing.
It is possible to specify the backup file with the --siburi option. If
it is not indicated, the tar file is created and timestamped in the
folder defined by backup_dir_name in the sifConfigParams, by default
siftmp/tmpUpload
in the sifbuilder directory. In this case, the backup file is
bck_pod_200707120020_sifbuilder_drupal.zip and it contains three files:
podcf.xml, with the configuration of the backup'ed site
(including
the reference to the pod)
poddb.sql, with the sql dump of the pod database
podfs.zip, with the tar file of the pod file system
The creation of the sql dump is based on standard calls to the
database, such as SHOW FIELDS FROM table in mysql, provided by the
abstract metabase interface. Since the information received is not
exhaustive, there will most probably be some difference between the
correct statement and the dumped one. For example,
CREATE TABLE IF NOT EXISTS `pn501__admin_module` (
`pn_amid` int(11) NOT NULL auto_increment ,
`pn_mid` int(11) NOT NULL default '0',
`pn_cid` int(11) NOT NULL default '0',
PRIMARY KEY (`pn_amid`),
KEY `pn_mid` (`pn_mid`)
);
Other differences may appear and therefore this technology may
sometimes need be complemented with manual intervention or other more
targeted tool. In fact, this -that- is the real reason why backup in
sifbuilder is an art and not a science.
Site restore
When a site has been backup, the site may then be restored by :
The backup restores the sbd501_at_localhost
site with the -x option having cleaned the pod before the restore.
Since the site identification is the same (sbd501_at_localhost) the
restored site resides normally on the same server than the site of
departure.
Summarizing,
We have created the local sbd501_at_localhost
site as defined in ../sifbuilder_local/sifnet_config.php
and declared in sib_drupal47_sif_sif.xml
.
Then, we have created a timestamped backup zip including the site
definition file, the file system tar and the site database sql dump.
Then, we have removed the newly created site -by grace of the
dangerous -x option in the restore statement-.
Finally, the site has been restored because the same site
definition has been specified in sifnetsite and because, since no
backup uri has been specified, the most recently created backup file
has been taken as source.
Clonage of a site
A substantially different operation is the creation of a new site,
with the same structure (core, modules, themes) and contents than an
existing one but with different configuration (database or database
prefix and credentials). This scenario is applicable with there is a
need to create a test site mirroring a production site on the same host.
If the sbd501_at_localhost was available or has been created as descrbed above,
it can be cloned with the following (do it without the -f and -x options first).
In this case, the sifnetbcksite
refers to an existing site. sifbuilder will take care to create a
backup from it. Then, it will restore the backup file system and
database sql dump taking into account the specifications in sifnetsite
, normally different from the source site.
By now, sifbuilder -though the site definition specified in the source
sifnetbcksite and the target sifnetsite site -has created a
new tree in the file system and a new database, eventually with a
different db prefix.
However, most wcm have a configuration file on the file system
that, at this point, still refers to the original site. Importantly,
all the operations until now have been blindly done, in the ignorance
of the core being served. However, the generation of the configuration
file on the site file tree is part of the installation process of the
core, as described here,
and sifbuilder must be made aware of the core installation package that
should address that task. The core sip is thus included in the command
so that the sif function clone_pod calls the sip configuration function
of the core sip.
A different scenario appears when a site has to be migrated to a new
host and eventually a new operating system. In this case, it is
necessary to generate the backup, move the backup to the target host
and do the restore there. This is done specifying the siburi in the
backup and restore commands.
During this recasting, a major event has taken place. A new
siteParam has seen the light. The db_prefix_sep. Cloning sites implies
unprefixing and prefixing tables. For this, it is necessary to know the
syntax of table names. Most cores use the underscore as prefix
separator. joomla does not. In sifbuilder 1_8_9 that parameter defaults
to underscore in the unprefix and prefix functions in SifMdb. The
builder is sceptical about historical and quantitative reasons and, if
does not arise a good reason for that, chances are that it will be
changed to null.
Blade Runner appeared on the screens 25 years ago. Based on the novel
Do Androids Dream of Electric Sheep? by Philip K. Dick, it was coldly
received at home and became a mass success only years later, in particular
after 1992 with the release of the director's cut version, and with its
distribution on video.
"I've seen things you people wouldn't believe... Attack ships on fire
off the shoulder of Orion... I watched c-beams glitter in the dark near
the Tanhauser Gate. All those moments will be lost in time... like tears in
the rain. Time to die." evokes the attraction of space and emphasizes individualism. The calm in the untergang
reinforces the replicant's aspiration to a human existence. The
night, the mist, the city. An
interesting analysis of the film deepens into the relationship
between visual perception, memories, feelings and knowledge. Vangelis' Memories of
Green composition accompanies the superb interpretation by Rutger Hauer and Sean Young.
Five years before, on the other side of the Atlantic, David
McWilliams had published The Days Of Pearly
Spencer that was highly appreciated only overseas. It became a chart hit in his country only in 1992 when a new version was released by Marc Almond.
David led a remarkable life that is narrated here
and here. In common with
the film, the song shows serene interpretation of strong emotions. It
was based on a homeless man in Ballymena who was befriended by David
and this song was his tribute to him.
The song shares some points with Jethro Tull's Aqualung,
the classic released by Ian Anderson in 1971.
The subject, a homeless, and the distorsion of the voice.
The lyrics were
composed by his wife,
were based on a poem by her or were inspired
by photos taken by her in London, depending
on the sources. Aqualung got its name from the sound of the song's character broken lung and voice in
the cold winter that Anderson identified with the gurgling sound of the underwater diving gear.
Yet both songs could not differ more on the headline.
google offers a translation service.
It will translate text and public web pages from Spanish, French,
German, Italian, Portuguese, Russian, Chinese, Japanese, Arabic and
Korean into English. That changes the value of localization of web
sites and sets a new level for the return on the cost to implement it.
To get that service available, it is enough adding a button
to the browser's Links Toolbar. A drag and drop from this page
will work. This opens the question on the role of a web content site.
Where is the border between the browser and the content. This note is
edited with the mozilla composer.
I can do most of the web editing tasks with that.
The tool bars were introduced in the late nineties. My toolbars
include the button to the weather page, the list of recently published
titles, the links to my email boxes and the control to the web search.
So there seems that there is a certain transfer of
function from the page to the browser. However, there are functions
that remain associated to the content and not to the container. This is
when it resembles a working space. In this line we liked the wallstrip interview
with Andy Swan presenting mytrade.com.
Not only when he identifies Youtube as competitor in the sense that they both
compete for time from users. Also because the beta site supports fully
personalised customization that promises an interesting working
environment for the next but one professional life.
Despite the fact that we are currently interested on the content
management side of the window, some may find rewarding putting to hard probe
the de2en google translator with the lyrics in text. suess wie sie sagt.
<h2 class="title" style="clear: both">sifbuilder interaction with the cores</h2>
Whenever sifbuilder installs a component, it follows the following actions:
Process. Manage package versions, dependencies, and conflicts
Control. Control the version of the site package (core or module) to be installed. This is taken from the sip installation package. Check whether that package is already installed in the site and get the installed version
Transpose. Download and explode the site package source if not available
Transfer. Copy the package files from the packages repository to the site (this may remove information of the pre-update status
Config. Configure the site parameters. Done normally only with the installation of the core
Install or Upgrade the package as required. Installation is dependent on the type of package. Installation of a module usually includes initialization and activation. Installation of a theme may imply activation of that theme
Build. When sifbuilder runs against a site definition template, the previous actions are followed by configuration of panels and blocks, setting of system variables and permission, and creation of content.
These actions are carried out by sifbuilder in a single session relying as much as possible on the interfaces offered by the site core and its modules. In optimal conditions,
sifbuilder should neither modify the code of the core nor import code from it.
The easiness with which sifbuilder may interact with a WCM system is determined by three features of the cores:
Exposure. The exposure refers to the functionality offered by the core and components to an external application. It is dependant on an API. When the level of exposure is low, extending or modifying the behavior of the application is done by modifying the code and not by adding functional components to a repository
Segmentation. The segmentation refers to the separation between the presentation and the logic code. When the level of segmentation is low, calls to a function may generate undesired output intended for user interaction
Contextualization. Contextualization refers to the possibility of entering the code once the global status has evolved. Usually, wcm systems are designed to allow a single package action in a session. With a low level of contextualization, installing various themes or upgrading a module is difficult. This may be provoked by the use of static variables, include instead of include_once, or unbundled code in files
The running environment, the web server and the database server are in place. The latest version of sifbuilder has been downloaded and exploded to, let's say, win d:/sifbuilder_1.7.8/. Have a parallel folder ../sifbuilder_local/ created. It will contain the downloaded site packages and the local configuration files.
Let's suppose that the site is to be created locally. Let's suppose also that we want to install the sifbuilder site currently based on the postnuke core.
Run the sib definition of the site to create the site as defined in the sib.
The semantics of the sib_PostNuke08_sif_sif sib was described here
--sifpacksdir option is important. sifbuilder relies on the site packages downloaded from the net. By storing them outside the sifbuilder folder, updating the program will not remove them.
Even more important though for other reasons are sifnetconfigfile and sifnetsite. sifnetconfigfile indicates where sifnetsite is defined. And sifnetsite as here instantiated in sbpn_at_localhost is the class in that file defining the parameters of the target site to be built, or the site itself in a certain sense. Having these options on file permits to refer to each site configuration by name. Take sifnet_config.php in the sifbuilder root folder as example. Wrong setting of those options may erase a whole system. No need to look for a demonstration.
The --dev option is here necessary to trap the postnuke 0.8MS3 sip that corresponds to a development site package.
-x may be added to the command to remove the site root and empty the site database before starting the installation. Do that only if you have the possibility of and know how to restore your working environment.
-f may be used to force the execution of the command in non-interactive mode. It can be used and will be used if you are a programmer when you know to be in control of what you are doing.
Web sites with other cores may be created in the same way with other sibs. for xoops use the sib_XOOPS20_sif_sif.xml sib, for drupal sib_drupal47_sif_sif.xml and for joomla use sib_joomla1_sif_sif.xml.
The installation of the site is normally followed by the creation of content. Can be done with
When creating a postnuke block with sifbilder, either with the common sip_configure_blocks function or sip-processed such as with tRSSNews_blockupdate_blocks, the sif interface to postnuke-blocks implemented in the PostNuke08_core_postnuke_0_8_0_0_MS3 sip checks if the block exists in the target site and behaves accordingly. In this version, the Blocks user api call getall is called with inactive=>true arguments to get also the non active blocks.
The SifApi sif_run_usecase function is fixed to pass sips arguments when installing sites remotely through a sifrelation. Was thought to install a module with a newly available sip.
A few fixes in the sifrelation object methods support now uploading sections of the program to the sif directory in the remote nethost. This includes sifnet_upload_to_sifdir to upload new sibs, notably to generate new content. upload in sifnet_ssh2pwd_windows_relation behaves now recursively to copy folders from sifTmp/tmpUpload to the remote nethost sif directory.
Commands with nethost set are now processed by the sif API and passed to the sifnetrelation object. This executes the sif action on the remote host.
The templates PG-News01 of the News01 pagesseter publication look now a bit more like those of a blog. The teaser comes functionally closer to and will eventually replace the text field. To help moving to the news body, a readme link appears now on the footer. The pn- styles have been added to the publication template css and make the footer look nicer. To allow the publication of youtube videos sip_set_configvars within the PostNuke08_pgpub_News01 sip element in the sib_PostNuke08_sif_sif.xml sif enables object, param and embed tags in AllowableHTML site vars.
The SIPS publication has now a file upload field that permits registered users contribute sips.
A good friend got curious about sifbuilder. Must be the attaction of the unknown. Graduated in Physics as he is, I told him that using sifbuilder to generate an operational web site was obvious. It was a surprise when he came back and asked me to demonstrate that it was obvious. And, to start with, he wanted to know why PHP was required. Of course the explanation for such a reaction is that he directly moved from a very successful career as COBOL programmer to an even more successful one as j2ee project manager. Demonstration by implementation should suffice.
xampp is a reasonable option to get everything necessary to make sifbuilder work and build web sites with different open web content management cores. In the most frequent case of a linbox this page seems a useful infosource. Let's suppose however a winbox for the sake of dealing with the exceptions first.
Download the distribution from the apachefriends site. for the method, the builder erased the complete existing programming environment and downloaded the XAMPP Windows 1.6.2 zip file.
Choosing a random location, the builder downloaded it to D:\ALL\sifbuilder_local and seven zipped it to here generating D:\ALL\sifbuilder_local\xampp. Let's call it $xampplocation. then, he cdded to $xampplocation and dos ran setup_xampp.bat.
Since the builder wanted to have php.exe directly available on the command line, he added $xampplocation\php to My Computer->Properties->Advanced->Environment->path and rebooted. This set the PHP programming enviroment. Configuration was tested with > php -v.
The builder wanted to maintain the d:/webroot/htdocs document root as it appears in the already vast bibliography on sifbuilder. Thus, he moved $xampplocation/htdocs to d:/webroot/htdocs and replaced $xampplocation\htdocs by d:/webroot/htdocs in files in $xampplocation. Changes were $xampplocation\apache\conf\httpd.conf (2 times), $xampplocation\apache\conf\extra\httpd-ssl.conf (1 time), $xampplocation\apache\conf\extra\httpd-xampp.conf (5 times) and it seems to work to set the apache web server environment.
The mysql database server root password is set with $xampplocation\mysql\bin\mysqladmin -u root password pwd_root. There is a possibility that if a root password is used other than the one in the example the installation procedure fails. But, if the same one is used the whole system will surely fail.
It should now be possible to download sifbuilder and run it to create a postnuke, xoops, drupal or joomla site.
