sifbuilder enables the automatic installation of PostNuke sites

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 optional 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

]]> 1 blog sifbuilder 1.2.2 released 2006-09-27 sifbuilder 1.2.2 covers update of drupal modules and clone of WCM sites

sifbuilder 1.2.2 extends the support to the automatic generation and maintenance of Drupal sites. With this version it is now possible to create a Drupal site -based on the XML declarative definition of the modules, blocks, themes, permissions and nodes that compose it- and automatically update modules when installation packages for new releases are available.

sifbuilder comes with the sif theme for Drupal. A sample site using the sif theme and automatically generated with the template is this .

Interacting with the permissions module, sifbuilder supports activation of system modules and definition of configuration variables. It enables also the creation of blocks and the configuration of blocks in panels.

It is also possible to create content nodes of different types and add entries to the navigation and the primary links blocks

sifbuilder supports the installation of themes. Its first release supporting Drupal includes installation packages for aquasoft, foundation, interlaced, internet_services, kubrick, meta, bluemarine_smarty, box_grey_smarty and sets slash as default. Some of the installation packages for Drupal modules are survey, advuser, filemanager, acidfree, article, jstools, wforms, ldap_integration, linksdb, monitor, og, worklog, project, site_map and hof.

Another Drupal sample site automatically generated by sifbuilder with the template is this .

]]> 1 blog sifbuilder upgrade of Drupal sites 2006-09-28 Upgrade of Drupal sites

In a WCM system, updates refer normally to the core or to the modules.

Drupal core update

http://drupal.org/upgrade/tutorial-introduction describe the update procedure for Drupal. sifbuilder implements the update of the core in the installation package for Drupal 4.7.3. Its scope is limited to the sites based \on 4.7 series.

The update process involves three steps, update of the schema, update of the file system and site configuration, management of contrib modules and themes.

In Drupal, the core schema identification system is not related to the version of the core. It is not registered either in the file system or in the schema at the time of installation. Ideally, the core version should be accessible as a variable in a configuration file. The schema update functions should be exposed in a class dependent on the core. The 4.7 series releases do not modify the structure of the schema and drupal47_core_drupal_4_7_3 simply shows how the schema core would be updated if it would.

The update of the file system and the contributed modules and themes is done in the following steps:

Copy the site file system to a temporary folder
Copy new file system to site folder
Copy files from backup to site folder: .htaccess, sites/default/settings.php
Copy files from backup to site folder:

Update of Drupal modules

n the most general case, a module is updated when, in the course of its installation, a previous version is found on the target site. Module are usually updated copying the module file system to the site modules folder and eventually updating the database schema structure and data.

The steps in this procedure are:

For the module to be installed, get the version available, either on the local instance of sifbuilder on the update server
Check if the module is already installed and, if that is the case -as it is assumed in this note-, get the version on the site.
Update the module file system
Update the module schema structure and data
Update the site configuration for the module

In general, if the status of the module on the site is kept in the site schema, the specification of the update version vector may be recalculated at step 4. Otherwise, that information must be transferred from step 2.

The update of Drupal modules is influenced by the following factors:

The version of the module package refers to the version of the core.
There is an sequential module schema version coded in the update functions in the module install file.

To facilitate univocous module reference and enable versioning control, the date of last modification of a module is added to the release version. Thus, the sif installation package drupal47_mod_acidfree_4_7_0R060831 refers to the Drupal acidfree module for Drupal core 4.7 last modified on 31 August 2006. Each package release is associated to its hash value. This means that, unfortunately, the Drupal module repository cannot be used as the only sifbuilder module server.

For what concerns update of the module file system, sifbuilder update of Drupal packages assumes that the package file system is replaced by the contents in the new package distribution.

For what concerns update of the schema, an important design principle is that the update data and functions are provided by the module package and that it is called by reentrant functions in the core, ie. that the core API and the module design are contextualizable. In Drupal, includes/install.inc is not contextualizable. To generalize the update of modules, the schema version management functions in that file are recoded in the sifbuilder Drupal core module class and are called locally by the module activate (to set the schema version) and update functions (to retrieve and update it).

Once the update vector has been identified, the Drupal core module update function loads the install file for that specific module and identifies the update functions from the registered version of the schema up to that of the package being installed. Then, it sets the new version.

This enables the installation and update of a series of Drupal modules in a single sifbuilder session associated to a site template.

To describe the update facilities of Drupal sites in sifbuilder, we may run:

> php sifcmd.php file://template_for_site_to_be_updated.xml

where template_for_site_to_be_updated.xml is the following xml file:

<xml>
  <sip_build_site>
        <site>
          <sips>
            <drupal47_core_drupal_4_7_2>
             <buildParams>
              <sip_install_package/>
             </buildParams>
            </drupal47_core_drupal_4_7_2>

            <drupal47_mod_project_4_7_0R060725>
             <buildParams>
              <sip_install_package/>
             </buildParams>
            </drupal47_mod_project_4_7_0R060725>
 
            <drupal47_mod_acidfree_4_7_0R060720>
             <buildParams>
              <sip_install_package/>
             </buildParams>
            </drupal47_mod_acidfree_4_7_0R060720>
          </sips>
        </site>
  </sip_build_site>
</xml>

This will install a Drupal 4.7.2 site as well as the filemanager module release on 24 April 2006 and the acidfree module released on 20 July 2006.

Then, if we run:

> php sifcmd.php file://template_with_updated_packages.xml

with the template file

<xml>
  <sip_build_site>
        <site>
          <sips>
            <drupal47_core_drupal_4_7_3>
             <buildParams>
              <sip_install_package/>
             </buildParams>
            </drupal47_core_drupal_4_7_3>

            <drupal47_mod_project_4_7_0R060908>
             <buildParams>
              <sip_install_package/>
             </buildParams>
            </drupal47_mod_project_4_7_0R060908>

            <drupal47_mod_acidfree_4_7_0R060831>
             <buildParams>
              <sip_install_package/>
             </buildParams>
            </drupal47_mod_acidfree_4_7_0R060831>  
          </sips>
        </site>
  </sip_build_site>
</xml>

the following will happen:

Drupal core will be updated from 4.7.2 to 4.7.3. The modules filemanager and acidfree, in their original version, will be copied to the updated site.

Then, the last version of the module filemanager will be installed. Since currently there is no more recent release, the installation of that module will be ignored.

Then, sifbuilder will install acidfree from 31 August, 2006. The system will identify that this is an update. It will therefore copy the new file system to the Drupal modules folder.

Then, it will find that the schema version in the system table -set by the previous installation- is 1 and that the new package has a update function for schema version 2. Therefore, the acidfree_update_2 will be run and the new schema version will be set in the database, ending the process.

]]> 1 blog the art of backup in sifbuilder 2006-09-28 sifbuilder 1.2.2 covers backup, restore and clone of web sites and pods. A pod is a site within a site folder, similar to the prefixed tables within a db instance. .The reason to introduce the pod was supporting the creation of multiple sites within the same folder, not necessarily the web root.

Pod backup

To backup a pod, it must exist first. A pod may be created with

> php sifcmd.php b 
 --sifpacksdir=../sifpacksdir
 --sifnetsite=sbd501_at_localhost 
 --siburi=file://./sibs/sib_drupal47_drupal_bluemarine.xml -x -f

NOTE: do not do this, in particular do not use the -f -x options, if you do not know what it implies.

Once the pod is created, the backup is done with

> php sifcmd.php backup_pod --sifnetsite=sbd501_at_localhost -f

Since there may be many site pods, we specify it with the --sifnetsite option that defines the parameters of the site in sifnet_config.php, that may be modify to respond to local configuration, or sifnet_config_local.php, if this has been created.

This command will create a file, in this case bck_pod_200609190012_d501.zip, under the siftmp/tmpBackup folder. That tar contains three files:

podcf.xml, with the parameters of the backuped 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 definition sql instructions in poddb.sql are build on the result of Metabase functions MetabaseListTables, MetabaseGetColumnNames and MetabaseListTableFields.

Pod restore

Once the pod is backuped, in order to test the restore function, first we empty it:

> php sifcmd.php x --sifnetsite=sbd501_at_localhost -f

That command will empty the site tables and remove the file system. Then, the pod may be restored with:

> php sifcmd.php restore_pod
 --siburi=file://./siftmp/tmpBackup/bck_pod_200609190012_d501.zip -f

This command will extract the files in the backup tar. The file system in podfs.zip will be copied to the site file system and the poddb.sql will be run against the dbms depending on the site information in podcf.xml.

Pod clone

A pod is cloned from the backup of the source one.

> php sifcmd.php restore_pod --sifnetsite=sbd502_at_localhost 
 --siburi=file://./siftmp/tmpBackup/bck_pod_200609190012_d501.zip -f

The difference from the restore is that, in this case, the parameters of the target site are taken from the sif instruction.

In this case, the site parameters, in particular those relevant to the target file system and database, are taken from the sbd502_at_localhost class as defined in sifnet_config.php or sifnet_config_local.php, instead of those in the backup tar file.

Yet, the site will not work. It is still necessary to configure it according to those parameters. This is done by

> php sifcmd.php sip_configure_site --sifnetsite=sbd502_at_localhost

The site configuration depends on the core and the core sip must implement the sip_sip_configure_package function. In the case of PostNuke, this function will modify the /config.php file, in Drupal it will modify /sites/default/settings.php, in XOOPS it will be the /mainfile.php file.

Backup functions in sifbuilder are for development purpose and not intended to replace commercial products.

]]> 1 blog The last sifbuilder 1.2.2 problem 2006-09-29 The last sifbuilder 1.2.2 problem solution

The release of sifbuilder 1.2.2 has been delayed for some days because of a problem in the automatic generation of the sif site (http://www.sifbuilder.com/), that is part of the tests before submitting a release.

The problem appeared in the news listed in the center block. When showed in full mode, they did not respond to the html formatting. When looking at the source, most of the angle brackets were escaped.

The site is generated applying to templates (sif beans of sibs) in the sibs folder. First, sib_PostNuke07_sif_sif.xml, that installs and configures the core, modules, blocks and them, and the sib_PostNuke07_sif_content.xml that adds the content. When the site was built with the content alone, however, they rendered fine.

The first ideal was that the theme (sif) was affecting the presentation of the news. To test this, the installation of the theme was removed from the sif sib and the site built from afresh on the local host. The problem, however, persisted. Then, we though that it could be some configuration variable but, after recreating the site without specification of modvars the problem remained. The debug did not show anything relevant either.

The last option was removing each module in the sib and rebuild a new site each time to try to find out which component was creating the problem. Following a series of tries it appeared that the cause was in the installation of PostNuke07_mod_v4blib. This is a sip that simply copies files to the target site and has no impact on the database.

We could have left the sif site without the calendar block but it was kind of a pity and it would have prevented form using the useful modules in the v4b series. More important, exchanging a problem by a doubt is not a good option.

Thus, we removes folders and files from the source package in sifpacksdir and recreated the site from scratch. Finally, the problem appeared to be come from includes/pnApi.php that replaces the one in the target site.

With the editor we compared both files, the original in the target site and the one provided by the package. There are not many differences and the first guess was the right one: the removal of the pnConfigGetVar('safehtml') != '1') condition when applying htmlspecialchars to the output data.

The modification of those lines, in line with the original file, is encoded in the sip_sip_transfer_modifyFiles function in the mod_v4blib sip.

Since the reason for that change is not clear, better not to draw any particular conclusion.

]]> 1 blog sifbuilder 1.3.3 released 2006-11-06 Release 1.3.3 of sifbuilder includes the installation package for PostNuke .763. Having this release installed, these instruction generate the sifbuilder site (http://www.sifbuilder.com/) with that version of PostNuke:

> php sifcmd.php b --sifpacksdir=../sifpacksdir --sifnethost=localhost 
 --sifnetsite=sbpn_at_localhost --siburi=./sibs/sib_PostNuke07_sif_sif.xml -x -f
> php sifcmd.php b --sifpacksdir=../sifpacksdir --sifnethost=localhost 
 --sifnetsite=sbpn_at_localhost --siburi=./sibs/sib_PostNuke07_sifcontent.xml -f

This requires that the localhost host and the sbpn_at_localhost are properly defined in sifnet_config.php (use the -f and -x options ONLY if you are aware of the implications).

The sip installing that version of PostNuke includes a new version of the upgrade function intended to support pn .76 sites. Sites having the v4b library installed are also upgraded. By copying pnApi, however, the PostNuke version appears as not increased. To test the update function it is necessary to have a .76 site available. This can be done with

> php sifcmd.php t tca001 -f -v

The command creates the sifbuilder site with the PostNuke .7.6.2 core. then, it updates the site to pn .7.6.3. That test case, defined in sifnet_usecases.php, relies on the same localhost and sbpn_at_localhost host and site. Run the command without the -v option to see the parameters behind the use case and modify it as necessary. Alternatively, run

 > php sifcmd.php i --sifnethost=localhost --sifnetsite=sbpn_at_localhost 
  --sifpacksdir=../sifpacksdir PostNuke07_core_postnuke_0_7_6_2 -x -f
 > php sifcmd.php file://./sibs/sib_PostNuke07_sif_sif.xml --sifnethost=localhost 
  --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir -f
 > php sifcmd.php file://./sibs/sib_PostNuke07_sif_content.xml --sifnethost=localhost 
  --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir -f
 > php sifcmd.php file://./sibs/sib_PostNuke07_sif_delta.xml --sifnethost=localhost 
  --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir -f
 > php sifcmd.php u --sifnethost=localhost --sifnetsite=sbpn_at_localhost 
  --sifpacksdir=../sifpacksdir PostNuke07_core_postnuke -f

with localhost and sbpn_at_localhost configured in sifnet_config.php. The first and last commands are enough to test the site upgrade. (Use the -f option ONLY if you are aware of the implications.)

The upgrade process copies the resident site to a tmp backup folder. Then a new core site is generated and all the existing files in the modules, themes, includes and images folders that are not found in the new release are copied from the backup. This applies also to config.php and config-old.php in the root folder.

To update the sites with v4blib installed, the files index.php, personal_config.php, includes/pnAPI.php, includes/pnLang.php, includes/pnMod.php, includes/pnRender.class.php, includes/pnSession.php and images/icons overwrite the new ones. Note that this may create problems in some installations.

sifbuilder 1.3.3 incorporates the installation package for postnuke 0.8.0.0MS2. This version of the core may be installed with the sourceforge block, the Topics module and sysconfig with

> php sifcmd.php b --sifpacksdir=../sifpacksdir --sifnethost=localhost 
 --sifnetsite=sbpn_at_localhost --siburi=./sibs/sib_PostNuke08_env.xml --dev -x -f

or, just for the core, with

> php sifcmd.php b --sifpacksdir=../sifpacksdir --sifnethost=localhost 
 --sifnetsite=sbpn_at_localhost PostNuke08_core_postnuke --dev -x -f

Note the --dev option that is required for the sips related to development packages. Use the -f and -x options ONLY if you are aware of the implications.

Installation packages for some PostNuke modules are also included.

PostNuke07_mod_mediashare_2_0_0 is the sip for mediashare 2.0.0. sips are associated to packages -that they be cores, blocks, modules or themes-. A sip normally gets and installs a package. Building a sip may imply creating an entry in the Main Menu, showing a block in a panel or setting a theme as default. sips are not intended to create content, that is inherently independent from packages. This is done with the sibs (the sif beans in the sibs folder) that typically describe the complete target site: core, modules, blocks, theme and content. Content nodes are however limited to text, such as the pagesetter publications in the http://www.sifbuilder.com/ site. The line of development of sifbuilder includes support for tar sibs. It should then be possible publish a sib and have a content rich site automatically generated. This will be dependent, however, on the programmatic interfaces of the media management modules.

PostNuke07_mod_pnFreeChat_1_02 installs pnFreeChat 1.02 It builds with an entry in Main Many and shows how to install the pnFreeChat block.

PostNuke07_mod_netquery_4_0 installs Netquery 4.0 . We have not seen a way to install this module on PostNuke .7.6.3 without modifying pnuser.php to have browserinfo -used in netquery_user_main.htm (380-383)- assigned by Sniffer. The package build includes the activation of the Sniffer module.

Following the experience with the sif site, a few sips are fixed and delivered with a new version.

The stable PostNuke07_mod_pagesetter_6_2_0 and development PostNuke07_mod_pagesetter_6_3_0b5 sips modify the /pntemplates/plugins/function.pagesetter_ezcommentsCount.php function to call EZComments getall with mod param and get the correct number of comments per publication category and item.

The PostNuke07_mod_v4bPostCalendar_4_03 sip modifies the calendar view adding the PostCalendar/pntemplates/plugins/function.pc_view_select.php from previous releases to the package installation.

This release includes also a few modifications to the sifbuilder and sif libraries and some sips files that determine the modification of the release number.

The SifFso cp_diff_r function has been changed to behave recursively in all subfolders. This is used in the pn update function, in particular to cover the includes/blocks and includes/language subfolders. The flat behavior of the previous code is done by cp_diff_d, in line with cp_d.

The sif_sip sip_sip_install_site_wrapper function has been set to ignore upgrade of packages in force mode if reinstall is not requested.

In this release, sifbuilder stop on error has been activated in sifConfigParams.php.

]]> 1 blog sifbuilder 1.4.5 released 2006-12-07

The purpose of sifbuilder is allowing the declarative definition of a web site by a XML file and the automatic generation and update of the site independently of the core and modules. The automatic update of the core and installed packages requires the comparison of the locally installed releases against those in an update server and the application of the update procedures to the local core and modules when required.

To check this process, we create a WCM site from scratch with

> php sifcmd.php b --sifnethost=localhost --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir 
    PostNuke07_core_postnuke PostNuke07_mod_netquery PostNuke07_theme_sif --doupdate -f -x

The site parameters (location, credentials, admin user) are defined in the sbpn_at_localhost class, that must be correctly specified in sifnet_config.php. The site will be created on the sifnethost host (assigned to localhost in that command), that must also be defined in sifnet_config.php, with the site packages available in ../sifpacksdir. If the site packages (core, modules, themes) are not there, sifbuilder will try to download them from the corresponding package host. Since we use the -f option, we assume that all those parameters are correctly defined -test it without that option first to see if the site and credential parameters are correctly set-, and since we use the -x option, the file system and database of the site defined by sifnetsite will be emptied -another reason not to use the -f option it if not completely sure-

That command creates a site with the PostNuke core, the Netquery module and the sif theme. Since we want to test the automatic update functions of sifbuilder, we have to run this command on a old distribution of sifbuilder contains outdated sips for the core and packages, such as sifbuilder 1.2.2. In fact, the resulting site will be based on the PostNuke 0.7.6.2 core and will include Netquery 3.3 with the sif theme applied as default.

To check the status of the site, we switch a more recent version of sifbuilder, and run

> php sifcmd.php rlist --sifnethost=localhost --sifnetsite=sbpn_at_localhost -f

That function will show, among other entries, the following:

 71. PostNuke07_core_postnuke       0.7.6.1a +   Content management system
 72. PostNuke07_core_postnuke       0.7.6.2  + * Content management system
 73. PostNuke07_core_postnuke       0.7.6.3  +   Content management system
 74. PostNuke07_core_postnuke       0.7.6.4  =   Content management system
101. PostNuke07_mod_netquery        3.2      +   Whois, DNS, port check, ping, tracerou
102. PostNuke07_mod_netquery        3.3      + * Whois, DNS, port check, ping, tracerou
103. PostNuke07_mod_netquery        4.0      +   Whois, DNS, port check, ping, tracerou
104. PostNuke07_mod_netquery        4.0.5    =   Whois, DNS, port check, ping, tracerou
175. PostNuke07_theme_sif           1.0      = * sif Xanthia theme

That table indicates, with an asterisk, the package releases installed in the just generated site, PostNuke07_core_postnuke 0.7.6.2 and PostNuke07_mod_netquery 3.3 , and indicates also that, in the new distribution of sifbuilder, there are installation packages (sips) for more recent versions of those packages.

To update the site, always using sifbuilder 1_4_5 or above, we run the same command that generated the site:

> php sifcmd.php b --sifnethost=localhost --sifnetsite=sbpn_at_localhost --PostNuke07_core_postnuke PostNuke07_mod_netquery PostNuke07_theme_sif --doupdate -f

but without the -x option which, as discussed, empties the site before starting the installation process. While in the first case the packages were logically not available and the latest release for each package was installed, in this case sifbuilder identifies that the version of the theme package is the same and nothing is required but, on the contrary, there are new versions for the core and the netquery module and, therefore, tries to update them. This is done by calling the update function in the individual sips with, in general, call the update function in the individual packages. The update of the core, however, requires a more complicated process including restoring the folders for modules and themes that we available in the site to be updated.

After applying the installation command to the already generated site, the status shown by rlist is the following:

 71. PostNuke07_core_postnuke       0.7.6.1a +   Content management system
 72. PostNuke07_core_postnuke       0.7.6.2  + * Content management system
 73. PostNuke07_core_postnuke       0.7.6.3  +   Content management system
 74. PostNuke07_core_postnuke       0.7.6.4  = * Content management system
101. PostNuke07_mod_netquery        3.2      +   Whois, DNS, port check, ping, tracerou
102. PostNuke07_mod_netquery        3.3      + * Whois, DNS, port check, ping, tracerou
103. PostNuke07_mod_netquery        4.0      +   Whois, DNS, port check, ping, tracerou
104. PostNuke07_mod_netquery        4.0.5    = * Whois, DNS, port check, ping, tracerou
175. PostNuke07_theme_sif           1.0      = * sif Xanthia theme

The latest release of the core and the packages have been installed. Though it is possible configuring sifbuilder to get information about the packages interrogating the core, it is important to note that currently, by default, the status of the site packages is obtained from the sifbuilder installation register. Thus, the output is correct when the site has been generated and maintained by sifbuilder. Installing a package on a site that has it already installed outside the sif framework could provoke undesired effects.

Once the update procedure is tested with that site configuration, it is tested with the complete sif site and contents.

> php sifcmd.php file://./sibs/sib_PostNuke07_sif_sif.xml --sifnethost=localhost 
   --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir -f -x

That command creates a site similar to http://www.sifbuilder.com/ as defined in the sib_PostNuke07_sif_sif.xml file in the sibs folder. This means that the core, theme, blocks, modules and configuration instructions specified in that sib are applied or activated. The correspondence between the XML file and the resulting generated site is the first major objective of sifbuilder. Once again, this is run on the sifbuilder 1.2.2 distribution.

Then we load the content with

> php sifcmd.php file://./sibs/sib_PostNuke07_sifcontent.xml --sifnethost=localhost 
   --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir -f

This command creates the sifbuilder news entries that appear in the sifbuilder site front page as pagesetter publication items in the SFNews category of the News01 publication type. The sib_PostNuke07_sifcontent.xml sif bean (the name has slightly changed in the 1.4.5 version of sifbuilder) calls the PostNuke07_pgpub_News01 sip and passes a pagesetter schema and the news items in the form of XML elements as parameter. The schema in the sib file includes the News01 publication type, which defines the type of publication, including its custom fields and the workflow to apply for approval of each publication item as well the key to the templates to use to render the publication items as a list or individually. Besides the publication type, each pagesetter schema defines also the [tree of] categories of the publication. In this case we define a single category. Within each category, we create the individual publication items. In short, an XML element passed to sifbuilder defines the structure of the news, the hierarchy how they are organized, the templates to use for presentation and the individual news item content.

We may choose do a backup of the site before updating it. As said before, these operations should always be done on a development host first.

> php sifcmd.php backup_pod --sifnetsite=sbpn_at_localhost -f

The backup sif command creates, in the tmp/tmpBackup folder; a zip with three files: a zip file with the site file system, a SQL file containing the SQL statements to reproduce the site database -built using the Metabase library-; and a metadata file containing the site definition, including the site and database credentials.

To test the update function in sifbuilder, we run the command that generated the site originally, this time from the sifbuilder 1.4.5 folder without the -x option.

> php sifcmd.php file://./sibs/sib_PostNuke07_sif_sif.xml --sifnethost=localhost 
   --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir -f --doupdate

The process, that may take some time to complete, will result in an updated sif site. This is the second objective of sifbuilder, introduce the automatic update of open source multi-author composite Web Content Management sites.

]]> 1 blog sifbuilder 1.4.5 upgrade of postnuke cores 2007-01-07

Testing new releases of sifbuilder usually implies locally creating relatively complex new cm sites based on one or more of the sif supported cores. For example,

> php sifcmd.php file://./sibs/sib_drupal47_sif_sif.xml --sifnethost=localhost --sifnetsite=sbd4_at_localhost
 --sifpacksdir=../sifpacksdir --doupdate --dev -x
> php sifcmd.php file://./sibs/sib_PostNuke07_sif_sif.xml --sifnethost=localhost --sifnetsite=sbpn07_at_localhost 
 --sifpacksdir=../sifpacksdir --doupdate -x
> php sifcmd.php file://./sibs/sib_XOOPS20_sif_sif.xml --sifnethost=localhost --sifnetsite=sbx2_at_localhost 
--sifpacksdir=../sifpacksdir --doupdate -x

These commands will create drupal, postnuke or xoops sif sites, as defined by sbd4_at_localhost, sbpn07_at_localhost and sbx2_at_localhost, on the localhost, instantiated in sifnet_config.php. (The -f option may be used when the site parameters are correctly defined).

If the modifications include providing new module installation packages, then those are installed, for example as with

> php sifcmd.php b --sifnethost=localhost --sifnetsite=sbpn_at_localhost --sifpacksdir=../sifpacksdir 
  PostNuke07_mod_netquery --doupdate

When the changes are relevant to the sifbuilder site (http://www.sifbuilder.com/sifbuilder/pn/), the changes are applied to the site on the hosting server, usually with the tc905 sif usecase.

In the case of release 1_4_5 of sifbuilder, the changes implied (among others) updating the sifbuilder site from postnuke 0.7.6.2 to 0.7.6.4.

Updating the cm cores may involve operations on the site database and on the site file system. In this particular case, the data model was not altered. Normally, the affected files cover the core files and classes, the configuration files and those related to packages contributed by open source authors and installed on the site being updated. These packages may be modules, themes and blocks. Though usually there are specific repositories for these contributions, they are not always implemented as new entries there.

The postnuke core update procedure in sifbuilder, for what concerns the site file system, implements the approach of cleaning the original site, copying the new core file system and copying back the difference from the backup of the original to the new file tree. This is implemented, in a similar was as in other cores, in the sip_sip_upgrade_package function of PostNuke07_core_postnuke_0_7_6_4_sip.php.

Since the system data on the database is not changed, the installation of the existing modules is usually fulfilled by copying the modules related directories and files to the updated core file system. This is not the case if the installation of a module affects the core files. Given the specific nature of v4b, this happens with the v4blib package. This is why the upgrade procedure of the core calls, as part of it, sip_sip_transfer_package for that package. This implies copying the v4b library files from the site package to the include directory -together with other files to the images, language and module folders-.

Relevant to the behavior of sifbuilder, however, is the replacement of the core pnAPI.php file, which is part of the normal installation of the vb4 library. The specific aspect of this covered in this note is the change of the value of the _PN_VERSION_NUM constant. sifbuilder needs to interrogate a core to know if a module is installed as well as to get its installed release version. Often, this information is usually retrieved from the value of a constant. Ideally it should be accessible through a non-static variable from an interface function or a configuration file.

By changing the value of that constant, the installation of the v4blib package influences the information retrieved when sifbuilder interrogates postnuke on the version of the core installed. Because of that, it affects the overall management of modules and packages dependencies. This made necessary rewriting the PostNuke07_mod_v4blib_4_04_sip.php installation package for v4blib to avoid that.

]]> 1 blog sifbuilder, postnuke and pagesetter 2007-02-01 We were programming a product catalogue. It seemed reasonable to use OsCommerce 2ms2. We had a tree of categories and a list of products linked to images. It should be possible to ask for products and get the requests approved or refused with the inventory updated as a result. The product records were available in XML with associated image files on the file repository. We scripted the upload of those records into OSC.

Once that was done, it seemed useful installing some contributions to the site, for example all_prods, which allows the display of all the inventory products with pagination and buy-now, inventory_qty, which shows a column in the edit order view indicating the remaining quantity of every item in the order, and others. To install these contributions we had to modify the core code. That work was not easy and we thought that it would be useful to script those changes allowing others to automate those installations and authors to contribute with their own installation packages. Then, it seemed a good idea to use BTS, a nice template structure that eased the customization of the layout of the site. However, it turned out that the modifications on the code for the various contributions differed depending whether BTS was installed or not. Hence, it seemed necessary to incorporate control of dependencies and conflicts among contributions. At that time we incorporated the idea of the profiles as groups of contributions responding to specific site purposes.

When the sif framework was ready, it seemed a good idea creating a site for it. A friend was hosting some postnuke sites and we were pleased to work on the same core.

Unsurprisingly, it seemed logical trying to automate the creation of the PostNuke site for sif in the way in which sif automated the creation of OsCommerce sites.

PostNuke offered an API to the core functions, which had been the subject of discussion in the OSC forums for a long time. However, different as the implementation could be, the concepts underlying that work remained the same: for a multi-author composite open program, we had to introduce control on the package installation process depending on the site status and the installation series, we had to provide a conventions to allow releasing packages with their installation code, and to provide a mechanism to automatically install and update the packages composing the site.

The only new conceptual element introduced since the time of sif was the installation bean (sib), understood as a xml file describing the composition and configuration of the site that may be used to automatically create or update it.

Another new element, not really new but convergent, was the automatic generation of a module. Once the creation of a site was automated on the basis of the constituent modules, blocks and themes, it was only logical trying to automate the generation of the logic code on the basis of the basic initial conditions: the data model.

Since then, the sif approach has proved being usable independently of the core and supports the automation of sites on xoops, openstar or drupal.

However, the sifbuilder site (http://www.sifbuilder.com) has maintained the postnuke core. The reason for this is the capability to automate the catalog of sips and directly show them in a menu block, the sips block.

That catalogue is implemented as a pagesetter set of publications, similar to those shown on the front page. Pagesetter is a module that combines management of content (categories and publications), processing logic (workflows) and presentation (publication templates). The best way to look at the structure of pagesetter publications is with a pagesetter schema, for example the SipsSchema schema in the sib_PostNuke07_sif_sif.xml sib included in the sifbuilder distribution and that is used to create the sifbuilder site. The first part of the schema, the category element, defines the classification of publications in referable groups. Each category is a group under the items multiple instance element. In our case, we have foreseen one level tree of categories for the various types of site packages: cores, modules, themes, and so on. The other root element under the publication schema is the publication element. This data structure specifies, among others, the workflow to be applied to the process of publishing publications, the template to be used to render the various views of the publications, and the fields that compose a publication.

The main entities in a pagesetter publications conceptual framework are the category type (or list, recorded in the lists table), the category item (or list item, in the listsitems table), the publication type (or pubtype, in the pubtypes table) and the publication item (for each pubtype, a pubdata table contains the publication items).

Each list type is identified by a list id (lid) and its title. The list items associated to a list type compose the tree of categories that host the publication items. Each list item has a title and the fields that allow the creation of a hierarchical structure.

Publication types contain a title, a reference to the set of templates that control the presentation of the publication lists and items, the fields controlling ordering of publication items, the workflow to be applied to the process of publishing publications, and others.

Publication types are referred to from the pubfields table thus defining the data fields associated to a publication. Each field is described in the pubfields table, including the publication type (tid). Besides the tid, each field contains a fix set of attributes: the name, title, description, and tags: istitle, ispageable, issearchable and others. The type controls how the field will be processed.

Items of a publication type are stored as records in a pubdataX table. Each pubdata record has the attributes common to pagesetter publications, such as the publication date, and the custom fields specific to a publication type.

With this conceptual framework, it is easy to automate the creation and publication of the sips catalogue. To make things as easy as possible, we consider a sip record as a news item. The News publication type is provided in the pagesetter distribution and comes with a set of templates. We associate the sip release to the news headline and the sips are grouped in list items where the site package type (core, mod, theme, block, hack, other) corresponds to the category title (listitem full title). Relying on a standard publication type, pagesetter takes care to create the menu block.

The process of creation of the catalogue is called when the site is created. The sip_sifbuilder_insert_sipitems function in the PostNuke_mod_sifbuilder sip is called from the site generator sib. That function calls the sifapi sif_get_sif_entries, relying itself on SifDb -as other SifApi functions that need to have the list of available installation packages-, on the that gets the sip entries in the sifbuilder distribution.

With the list of sip records is converted to a list of pagesetter news, the pagesetter dao inserts the individual sip records.

The reason to tell all this is that sifbuilder 1_4_5 incorporated a fix to the pagesetter sip. In fact, the pagesetter sip, as other site package sips, interprets symbolic identifiers and translates them to numeric ids before interacting with the module APIs. In order to register a publication item, the data passed to the pagesetter sip includes the publication type title. Based on this, it is necessary to determine the tid. Previously, a new tid was always created (ie. a new publication type or list). The last version of the sip controls if the publication type exists and creates it only if it doesn't.

]]> 1 blog sifbuilder 1.5.6 released 2007-06-05 Good morning, good afternoon, good evening developers from accross the globe, welcome to the sif scriptable web site programming show.

After a few months, and responding to zousands and zousands of comments and suggestions that have made of our program one of the most exclusive ones in the world, the builder presents a new release that adds the installation packages with which we have built our new site and recalls some of the ideas implemented in sifbuilder.

First of all, sifbuilder is a coaching programme. It coaches the installation process: interprets and adapt the user request, controls the initial conditions, fetches required components, puts them in the right place, installs upgrades or deletes packages, configures the target site, creates content and delivers style. For each package, this information is coded in the installation package (sip). See details here

To make the automatic installation process as complete as possible, the program controls package releases and the request to install a package is translated into the installation of the most recent release of that package. Before installing a package, the program identifies the whole tree of required dependencies and matches it against the status of the target site (isn't it great that postnuke 0.8 and drupal 5.0 introduce management of module dependencies.) If a package is already installed with a previous release, the program will translate the installation into an upgrade. This, generalized, enables the automatic update of a whole site.

Since the main target of sifbuilder is the creation of open WCMs, independently of the underlying core, the program incorporates abstraction of site, module, block and package objects which are instantiated for every supported core, now postnuke, xoops, drupal and joomla. Basic functions are made available: apply theme, add block to panel, add row to block.

Though the target site may be built with a series of calls to those objects, sifbuilder introduces the sib, which is a xml file describing the site to be built. To enable the declarative definition of a site, the main object properties have a symbolic key which is then translated to the keys handled by the various cores and modules.

Since the configuration is a specific step in the installation process, it is possible to backup a site and restore it with a new configuration, thus allowing to create a clone of a site in a different server. Some jommla contributions do that!

As an evolution of the code generation approach, sifbuilder aims to provide automatic module generator modules for the supported cores taking as input the relational model of the relevant data. Such a module is available for postnuke and hopefully soon also for drupal. The ideal is being able to define the data model of an application defined in a XML file and having the basic logic code automatically generated, with the user, session and presentation being managed by the postnuke, xoops, drupal or joomla cores.

A natural way of using sifbuilder is to define a target site in a sib and have it installed many times through script in different locations and operating systems. It may happen that the target site is available through a ssh connection. This is the case with sourceforge. For this, sifbuilder incorporates the functions to automate the connection to the destination server and the installation of the target site.

]]> 1 blog site vectorially described by a XML file 2007-06-06 The sifbuilder bean sib_PostNuke08_sif_sif.xml describes the sifbuilder site. This XML file includes the instructions that the sifbuilder program runs to build the site. The file reads that, given the the runParams parameters that determine how the program will be executed and the siteParams paraneters that specify where the site will be built, apply the listed instructions per package to build the target site.

This sib contains just one runParams element which sets the --dev option. This setting removes the default filter that forces that only estable packages are considered for installation. Other runParams may be specified in the command line. Here it seems natural setting this option since the site will be based on the installation package for a core still in development. The sipParams, that define the site where the packages operations will be applied may also be passed here or in the command line.

Processing the sips elements, the PostNuke08_core_postnuke sip installs the postnuke 0.8 core. Then, the welcome message is set. It is important to note that this instruction is run within an inner level wrapped by sip_build_site element. The reason for this is that, while the core is installed in absence of an installed site with an abstract site context, the configuration of welcome message requires the postnuke core to be available since it relies on core functions. sip_build_site makes that the context is rechecked. Then it finds that the site is just available. Naturally, the target site should not exist before running the core sip or the runParams should include a directive to remove it before starting. The sifbulider distribution includes installation packages for three release candidates of postnuke 0.8. The sib element refers only to postnuke 08 but the program recognizes wich is the latest relase available and installs it. A specific release could have been indicated in place of the package name. Version 0.8 of postnuke is very much improved in relation to 0.76 to be an application framework in the sense of the sifbuilder framework. However, sifbuilder would like to init the site with pninit before a package installation in a site generation, and then login as admin. This is not possible yet. Hard setting configuration properties of the block upon creation is something sifbuilder would like not to see.

The installation of the Topics module follows that of the core. It is not included in the system module collection and it is a dependency of pagesetter. As such, it could have been automatically incorporated to the installation tree by the request to install pagesetter. This element adds also a topic to the configuration.

The the sif theme is installed. It could be released as a theme package. It is however included in the PostNuke08_theme_sif_1_0 installation package itself. This theme is similar to the one available for PostNuke07. As part of the installation and activation of the theme, some standard blocks are desactivated and a new one of type menu is created. This one will contain the entries for the user modules that will be installed later. The sif theme contextually presents the user access functions: login and register at conection time, account and logout when the user is logged on, and admin when the registered user is the site administrator.

After the installation of the core and theme, four sets of packages are installed: the packages related to content management around pagesetter; the packages for creation and visualization of news feeds including rssfeed and trssnews; communication packages inclundig pnFreeChart, pnSkype, googleMap, netquery and xSiteMap; and productivity packages, in particular pnFlashGames.

EZComents is also a dependency of pagesetter. The latest version of this module for which there is a sip available is 1.5. This module, hooked by pagesetter, allows registered users to issue comments for pagesetter news.

The pagesetter module and the pagesetter publications support the creation of content in the site. Besides the installation of the module, the pagesetter sip hooks pagesetter to EZComments, then sets module vars for pagesetter, installs the pagesetter schema for the type of publication associated to the sip records, the installation packages for the varoius types of site packages. Besides this, the PostNuke08_mod_pagesetter sip i this sib creates the SIPS listmenu block which is proposed by pagesetter to automate the presentation of publications in a block. The sips publication is defined in the schema with a file upload file so that users may contribute with their own installation packages. The pagesetter conceptual model is described here

The PostNuke08_pgpub_News01 sip creates the news publication that will be presented in the central block in the from page. This is set with the startpage variable.

The istallation of photoshare is also part of the pagesetter set of modules that manage content. It may be used to manage the pictures shown in publications. Unfortunatelly it is not obvious how to use it in a programmatic environment.

After pagesetter is installed, the sib installs a series of individual modules. The first one is pnFreeChat. As all the contributions from openstar, this module is functionally and technically very interesting. Since the Main menu, that in postnuke 0.8 include lines to the installed modules with user access, is desactivated, a row for this and other modules is added to the MENU block, wich is weighted less to be shown first on the right panel.

pnSkyp is also an interesting module provided by cmods-dev. The module may be seen at work here. Unfortunatelly, the icons provided by skype, that reflect the status of the target skype user as controlled by the module, do not fit in the aesthetics of the sif theme. Because of this, a simple link to skype called by the module is added by the MENU block.

Then pnForum is installed. The PostNuke08_mod_pnForum element in the sib instructs sifbuilder to install also the Forum staticstics block and to create a forum category. The block is not shown. Great pacakge, but exiting the program upon initialization error when the tables cannot be created ... the opposite of the sif philosophy.

GoogleMap is another most interesting module contributed by pnconcept. Google is creating a most relevant programming environment and integration with its apis will be fundamental for many web sites. Note that a key is required to present the google maps. Pitty not having been able to find pnWikka, also from pnconcepts, that responds to an important functional need.

The netquery sip, following the PostNuke08_mod_netquery instruction, installs version 4.11 of the module of the netquery module from virtech. This is an excellent module and a perfect package that fully responds to the standard behavior of sif packages. As such, it could be installed directly from a sib withouth having the need to have an associated installation package.

rssfeed is another important module from Craig R. Saunders at mtrad that responds to a core functional need. Unfortunatelly, the mtrad seems not to be available. The rssfeed_pgnews element creates a template for pagesetter news. The news generated by rssfeed may be visualized activating the trssdisplay block part of the tRSSNews module.

The pnFlashGames, GamePack, billiard set is there for this. Note that games are not classified and arrive through the all games link.

The xSiteMap from Devin Hayes shows a map of the site.

The PostNuke08_block_sourceforge element in the sib builds and activates a block referring to the program host.

]]> 1 blog Initial conditions 2007-06-10 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.

]]> 1 blog Code of style 2007-06-14 Details

]]> 1 blog sifbuilder 1.7.8 released 2007-06-15 This release of sifbuilder fixes a few things noted when generating the new version of the sifbuilder site

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.

]]> 1 blog The easiest case 2007-06-16 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.

php sifcmd.php file://./sibs/sib_PostNuke08_sif_sif.xml --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbpn_at_localhost --dev

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

php sifcmd.php file://./sibs/sib_PostNuke08_sif_content.xml --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbpn_at_localhost --dev

]]> 1 blog We debbit to her 2007-06-17 sifbuilder interaction with the cores

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

]]> 1 blog The bar and the page 2007-06-24 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.

Lyrics in Latain alphabet from lyricsbox

Komm mal ans Fenster komm her zu mir
Siehst du da drueben gleich da hinterm Wellblechzaun
Da drueben auf dem Platz vor Aldi haben sie
unser Abbild in Stein gehaun

Komm auf die strasse komm her zu mir
Ueberall Blumen und Girlanden halb zerknuellt
Sieht so aus als haetten die unser Denkmal heute Nacht
schon ohne uns enthuellt

Hol den Vorschlaghammer
Sie haben uns ein Denkmal gebaut
und jeder Vollidiot weiss
dass das die Liebe versaut
Ich werd die schlechtesten Sprayer
dieser Stadt engagieren
Die sollen Nachts noch die Truemmer
mit Parolen beschmieren

Komm auf die Beine komm her zu mir
Es wird bald hell und wir haben nicht ewig Zeit
Wenn uns jetzt hier wer erwischt sind wir fuer immer vereint
in Beton und Seligkeit

Hol den Vorschlaghammer
Sie haben uns ein Denkmal gebaut
und jeder Vollidiot weiss
dass das die Liebe versaut
Ich werd die schlechtesten Sprayer
dieser Stadt engagieren
Die sollen Nachts noch die Truemmer
mit Parolen beschmieren
Siehst du die Inschrift da unten bei den Schuhen
Da steht in goldener Schrift wir sollen in Ewigkeit ruhen

Hol den Vorschlaghammer
Sie haben uns ein Denkmal gebaut
und jeder Vollidiot weiss
dass das die Liebe versaut
Ich werd die schlechtesten Sprayer
dieser Stadt engagieren
Die sollen Nachts noch die Truemmer
mit Parolen beschmieren

Sie haben uns ein Denkmal gebaut
und jeder Vollidiot weiss
dass das die Liebe versaut
Ich werd die schlechtesten Sprayer
dieser Stadt engagieren
Die sollen Nachts noch die Truemmer
mit Parolen beschmieren

]]> 1 blog The success and the calm 2007-06-25 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.

]]> 1 blog Through the mirror 2007-08-15 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.

class sfhost extends sifnet_linux_host
{
var $hostParams = array(
'hosttype'=>'linux'
,'access'=>'ssh2key'
,'userdir'=>'/home/users/m/my/myuser'
,'sifdir'=>'/home/users/m/my/myuser/myproject/'
,'webdir'=>'/home/groups/m/my/myproject/htdocs/'
,'host_domain'=>'myproject.sf.net'
,'user_login'=>'my_user_login'
,'user_pwd'=>'my_user_pwd'
,'user_key'=>'D:\\sf_private_key.ppk'
,'php_bin'=>'php '
,'rexec_bin'=>'ssh '
,'rcp_bin'=>'scp '
);
}

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.

class sfhost extends sifnet_linux_host
{
var $hostParams = array(
nbsp; 'hosttype'=>'linux'
,'access'=>'ssh2key'
,'userdir'=>'/home/users/m/my/myuser'
,'sifdir'=>'/home/users/m/my/myuser/myproject/'
,'webdir'=>'/home/groups/m/my/myproject/htdocs/'
,'host_domain'=>'myproject.sf.net'
,'user_login'=>'my_user_login'
,'user_pwd'=>'my_user_pwd'
,'user_key'=>'D:\\sf_private_key.ppk'
,'php_bin'=>'php '
,'rexec_bin'=>'ssh '
,'rcp_bin'=>'scp '
);
}

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.

class sbd501_at_sfhost extends sifnet_site
{
var $siteParams = array(
'site_host'=>'myproject.sourceforge.net'
,'site_name'=>'mysite'
,'site_pod'=>'d501'
,'db_server'=>'mysql4-m'
,'db_database'=>'db_myproject'
,'db_prefix'=>'d501_'
,'db_prefix_sep'=>''
,'db_dbtype'=>'mysql'
,'db_tabletype'=>'myisam'
,'db_username'=>'db_admin'
,'db_password'=>'db_admin_pwd'
,'site_admin_username'=>'my_user_login'
,'site_admin_password'=>'my_user_pwd'
,'dir_fs_document_root'=>'/home/groups/m/my/myproject/htdocs/'
,'sys_temp'=>''
,'encodedpwd'=>1
,'enable_ssl'=>0
);
}

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

>php sifcmd.php build_program --sifnetconfigfile=../sifbuilder_local/sifnet_config.php

and its tar file.

>php sifcmd.php sifnet_create_program_zip --sifnethost=devhost -v

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.

>php sifcmd.php sifnet_upload_program --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=sfhost -v

and we explode the tar there.

>php sifcmd.php sifnet_explode_package --sifnethost=sfhost --sifnetconfigfile=../sifbuilder_local/sifnet_config.php -v

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

> php sifcmd.php sifnet_upload_packages --sifnethost=sfhost --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifpacksdir=../sifbuilder_local/packages

Then, the site may be created.

> php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbd501_at_sfhost --sifnethost=sfhost --siburi=./sibs/sib_drupal5_sif_sif.xml -x -f -v

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

> D:\BIN\plink.exe -ssh -2 -l my_user_login -i D:\LOCAL\sf_private_key.ppk myproject.sourceforge.net " php /home/users/m/my/myuser/myproject/sifcmd.php sif_sip_build_site --dev --expandsiteparams --noupd --emptypod --force --complete --dbgtype=both --siburi=./sibs/sib_drupal5_sif_sif.xml --site_host=myproject.sourceforge.net --site_name=mysite --site_pod=d501 --db_server=mysql4-m --db_database=db_myproject --db_prefix=d501_ --db_dbtype=mysql --db_tabletype=myisam --db_username=db_admin --db_password=db_admin_pwd --site_admin_username=my_user_login --site_admin_password=my_user_pwd --dir_fs_document_root=/home/groups/m/my/myproject/htdocs/ --encodedpwd=1 --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifpacksdir=../sifbuilder_local/packages --siflochost=devhost drupal5_core_drupal drupal5_theme_sif drupal5_mod_views drupal5_mod_site_map drupal5_script_locals "

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.

]]> 1 blog Catalogue of Functions 2007-08-18 "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 in place. Once said that, the sifbuilder site is regularly updated and maintained using sifbuilder.

Domain	Action	Instruction	Result instance
program	configure	php sifcmd.php sip_configure_site --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=devhost --sifnetsite=sbpn_at_localhost PostNuke08_core_postnuke -f -v	Configure the distribution
	create	php sifcmd.php build_program --sifnethost=devhost --sifnetconfigfile=../sifbuilder_local/sifnet_config.php -v	Create the sifbuilder program in siftmp/tmpUpload/ from the development environment
	tar	php sifcmd.php sifnet_create_program_zip --sifnethost=devhost -v	Create the sifbuilder program tar
	upload	php sifcmd.php sifnet_upload_program --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=localhost -v	Upload the program tar to the nethost sifdir
	explode	php sifcmd.php sifnet_explode_package --sifnethost=localhost --sifnetconfigfile=../sifbuilder_local/sifnet_config.php -v	Explode the program tar in the nethost sifdir
	local dir	php sifcmd.php a ac001i --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=localhost -v	Create the sifbuilder_local file tree
	local config	php sifcmd.php a ac023 --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=localhost -v	Upload the local sifnet config file
	packages	php sifcmd.php sifnet_upload_packages --sifnethost=sfhost --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifpacksdir=../sifbuilder_local/packages	Upload site packages if necessary
	site	php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbd501_at_localhost --sifnethost=localhost --siburi=./sibs/sib_drupal5_sif_sif.xml -x -f -v	Build the target site
release	create	php sifcmd.php build_release --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=devhost -f -v	Create a new sif packages release
	upload	php sifcmd.php sifnet_upload_release --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=devhost -f -v	Upload a sip release to the sif host
	create old site	php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=localhost --sifnetsite=sbpn501_at_localhost --siburi=./sibs/sib_PostNuke07_sif_old.xml --dev -x -f -v	Create a site with old site packages
	check new versions	php sifcmd.php rlist --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=localhost --sifnetsite=sbpn501_at_localhost --dev -f -v	Update site with most recent packages
	update	php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnethost=localhost --sifnetsite=sbpn501_at_localhost --siburi=./sibs/sib_PostNuke07_sif_sif.xml --dev --doupdate -f -v	Update site with most recent packages
try
drupal	create	php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbd501_at_localhost --siburi=./sibs/sib_drupal47_sif_sif.xml -f -x	Creates in force mode the http://localhost/sifbuilder/d501 site Pre empties the d501 database and pre removes the d:/webroot/sifbuilder/d501/ folder
	backup	php sifcmd.php backup_pod --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbd501_at_localhost -f	backup the d501 site into the autodefined bck_pod_200707220010_sifbuilder_d501.zip tar at ./siftmp/tmpUpload/
	restore	php sifcmd.php restore_pod --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbd502_at_localhost drupal47_core_drupal -x -f	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
	clone	php sifcmd.php clone_pod --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetbcksite=sbd501_at_localhost --sifnetsite=sbd502_at_localhost drupal47_core_drupal -f -x	Backup the sbd501_at_localhost site and restore it into sbd502_at_localhost with post configuration by the core sip
	clean	php sifcmd.php clean_pod --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbd501_at_localhost -f	Clean sbd501_at_localhost site and test sbd502_at_localhost at http://localhost/sifbuilder/d502
	restore with uri	php sifcmd.php b --sifpacksdir=../sifbuilder_local/packages --sifnetconfigfile=../sifbuilder_local/sifnet_config.php --sifnetsite=sbd501_at_localhost --siburi=./sibs/sib_drupal47_sif_sif.xml -f -x	Build the site