Abstract.

The ideal solution to realize and update web contents in a collaborative environment or anyhow from whom is "not assigned to the jobs" requires the use of a content management system. Of these environments we'll analyze the salient characteristics for dealing therefore the main installation and property of one of theirs: WebGUI.

Content Management System

The world of the communication has been sure revolutionized by the advent of Internet, an instrument that supplies the opportunity of being "an active" element of the net becoming a supplier beyond that a reader of information and news. For this they are more and more situations in which the dynamic character consists in the rapid and constant update of its contents.

And so happens more and more often, that who must add and maintain such contents, often it do not have or it cannot have anything to make with the world of the HTML. In order to make these authors independent, it was made therefore to feel the necessity to supply with some easy instruments  for the publication and management of web-based.

It's for this context that there are reasons to be those systems called Content Management System or C.M.S.

These products interpose between the author and the Web server allowing to execute operations of maintenance and management of the website in simple and natural way. Starting therefore from the problematic of generation of single several pages HTML to problematic the accessory ones that always accompany to the publication of new pages. Visualization from a date to a date, the automatic update of the menu and the site map in order to render account of the new inserted pages, indispensable restrictions to the access of the contents to single users authorizes are only some of the operations to have necessarily to execute in an anvironment web-based of collaborative type. If all it is not supported from a C.M.S., all these operations would be executed by hand.

But what is a C.M.S.?   An official definition does not exist and it prefers to describe by enumerating common characteristics that a system must have for being defined such.

A C.M.S. must unavoidablly possess an editor for the generation and modification of the contents via browser, than it does not demand knowledge of the HTML or other technical slight knowledge. The authors can so directly insert the news inside of browser in a WYSIWYG editor.

The system must therefore supplies to publish the news automatically, the day defined by the author, by covering automatically with part of the graphical standard of the website. Contextually it must automatically generate the menu items and the relative link in order to allow to the access and navigation to the article itself.

An other common characteristic is given from the fact that a single article can be present in various pages of the website in different layout. Think, as an example, at the possibility to have, automatically, on the home page, for every new news inserted, an abstract of page, so that every modification, automatically changes the content of the first page.

Moreover, all the C.M.S. must have a powerful system in order to maintain coherent navigation between the several pages also in the case of heavy restructures.

Obviously it cannot be missed a system authentication of the user for the publication and for the visualization of the contents to the aim to recognize the various privileges of the administrators, the authors and the simple viewer of our website.

Usually, then, C.M.S. systems manage also the recording and the trace of the several modifications executed on the so pages to eventually allow to return behind or having the history of the modifications brought to the single elements that compose the portal.

Presupposed common to all this, the extreme facility of using of all these instruments so to allow the management of the several operations also to un-expert people.

A product with these characteristics adapted therefore perfectly to all those situations in which the maintenance and management of the contents of the website it is put in hands of un-expert authors or also in all those situations in which the manual maintenance the website turns out owing to its collaborative structure with a high number of authors.

It start therefore from simple site in which the author, not programmer, wants to manage alone the contents without to ask for a web designer to end with portal with journalistic philosophy and, more in a generalized manner, with collaborative philosophy.

With all regards list untill here, the C.M.S. has one heavy gap. It's not completely adapted to a professional use for programmers. These, more shrewd of the normal users, would want to have, all the offered flexibility they give the functionalities as soon as cited of a C.M.S. in tha mantained of a website, but also the possibility to program new functionality in order to extend the panorama of the instruments already offers in order better to adapt them to their particular requirements.

To satisfy this, there is the Application Program Framework (A.P.F.) to which belong all those products that base its foundations on the technical characteristics of a C.M.S. without to have already preconstructed the interface part "user friendly" towards the author of contents. Indeed, such systems often are used like base in order to construct of C.M.S. to entrust to less expert users.

A product to half road between the simplicity of some C.M.S. and the integrability and expansibility of the A.P.F. is WebGUI, a distributed opensource system by Plain Black that, in the panorama of the C.M.S., before places in evidence for some peculiar characteristics first of all the fact that beyond to having, as we will see, all the characteristics of a C.M.S. suit has some property that carry it to flow in the family of the A.P.F rendering it therefore adapted to inexpert users and to professional users. One will look at in fact that in WebGUI, in order to resolve particular requirements, he is enough simple to extend the already present functionalities through the creation of plugins called assets.

In the course of this article we will see in detail because WebGUI is the ideal choice in the panorama of the C.M.S, we'll see how to install it and some general peculiarities. In next articles we will learn to use it as content creator and will see like extending its functionalities.

Installation

Which are requirement necessary in order to have a working installation of WebGUI?

Leaning to products like Apache Web server, Perl like programming language, and on MySQL like preferential platform of database, it turns on all those operating systems on which exist a porting for these products.

Although not closely necessary, he is advisable to run WebGUI inside the environment generated by mod_perl module that is a Perl compiler integrated into the web server to obtain maximum in terms of efficiency and speed.

Beyond to these products, WebGUI demands the presence of some modules available in the Comprehensive Perl Archive Network.

On the Windows platform® beyond to being able to install all these elements separately are available a setup called Zip' N' Go, present on Sourceforge, that it installs in a blow all, from the web server, to the Perl, the database, the required modules until installing WebGUI itself. Obviously he is advisable to use this installation on computer that has not already installed Apache, Perl or MySQL so to avoid conflicts with the already present products.

There is however to say, about Microsoft world, that they are available, on Internet, instructions to make to run WebGUI also with Microsoft®; Internet Information Server with Microsoft®; SQL Server as database engine.

Now we will see how to install WebGUI on a Linux box omitting the installation of the products more standard like Apache, Perl and Mysql.

As first step, we install the following required modules from CPAN:

• LWP

• DBI

• DBD::mysql

• Digest::MD5

• Date::Calc

• Time::Hires

• HTML::Parser

• Archive::Tar

• Compress::Zlib

• IO::Zlib

• SOAP::Lite

• Cache::Cache

• Image::Magick

All these modules can be install with a this command line

Perl - MCPAN - and ' install NOME::DEL::MODULO

This command will install also all the eventual proposed dependencies.

We will currently base this installation on the last available version (March 2005), the 6.5.2. This is a beta version with many differences and improvements then stable version and for this it is preferred to make reference to this beta and not to the stable one.

We will go therefore to download it from Sourceforge and, following the standard used by WebGUI programmers, we create a directory /data in the root of our server with the command

mkdir /data

We decompress the source downloaded in this directory with the command

tar - zxvC /data - f webgui-x-y-z.tar.gz

This command uncompress all source files inside a directory called WebGUI. This directory contains some subdirs, in particular: the directory etc with the configuration file, directory lib containing WebGUI libraries and plugins, a directory sbin with some scripts and a directory www that is the "public part" of WebGUI.

Next step is to create the database that will contain WebGUI data with command

mysql - p - and "created database WebGUI"

and we add a user with all the permissions on the database as soon as created

mysql - p - and "Grant all privileges on WebGUI. * to webgui@localhost identified by ' password' "

We make reload the MySQL privileges

mysql - p - and "flush privileges"

and we finally create tables and data of WebGUI with this script available in the directory /data/WebGUI/docs/create.sql

mysql - uwebgui - ppassword WebGUI < /data/WebGUI/docs/create.sql

We are now ready to configure WebGUI. We go in directory /data/WebGUI/etc and rename the WebGUI.conf.original file in WebGUI.conf and edit the following values: sitename with the name of your website

sitename = www.example.com, example.com

and the variable dsn, dbuser and dbpass with the value to access to the database with

dsn = DBI:mysql:WebGUI
dbuser = webgui
dbpass = password

The other variable can be left unchanged unless we installed WebGUI in a different path from that one exposed here. In such case you must change the paths in WebGUI.conf t adapt to your settings and moreover you must adapt paths in files sbin/preload.perl and www/index.pl.

In sbin/preload.perl, only if Apache is not used ver. 2.x, you must commente the line use ModPerl::Registry () and remove instead the comment from the line use Apache::Registry.

In the directory sbin a script exists that checks the configuration. With the script /data/WebGUI/sbin/testEnvironment.pl a series of checks are executed, between which the verification of the presence of the modules demands. This script installs the lacking modules automatically, being connected directly to the website of the CPAN. Once all the lacking modules have been downloaded, it is finally reached to obtain the aforesaid correct test:

# cd /data/WebGUI/sbin /; Perl /testEnvironment.pl

WebGUI is checking your system environment:

Operating System......................... Linuxish
WebGUI Root................................
Perl Interpreter......................... OK
LWP module............................... OK
HTTP::Request module..................... OK
HTTP::Headers module..................... OK
Digest::MD5 module....................... OK
DBI module............................... OK
Avalable database drivers................ ExampleP, Proxy, Sponge, Sybase, mysql
HTML::Parser module...................... OK
Archive::Tar module...................... OK
IO::Zlib module.......................... OK
Compress::Zlib module.................... OK
Net::SMTP module......................... OK
Cache::Cache module...................... OK
SOAP::Lite module........................ OK
XML::Simple module....................... OK
Time::HiRes module....................... OK
Image::Magick module..................... OK
WebGUI modules........................... OK

Found config rows........................ WebGUI.conf
Verifying rows........................... OK
Uploads folder........................... OK
Database driver.......................... OK
Database connection...................... OK

Latest version........................... 6.5.0-beta OK

Testing complete!

You notice at the end of the script, the check, from the website of WebGUI, of the last released version and the comparison with the local configuration.

We pass therefore to adapt the configuration of our web server. In the first place we must change the variable DocumentRoot in order to setyp for the directory of WebGUI. We find therefore in httpd.conf the line that shapes the directory publishes of our server web and modify it in

DocumentRoot /data/WebGUI/www

We then go to find the Directory directive associated to the old DocumentRoot type

<Directory /var/www/html>

and we change it like

<Directory /data/WebGUI/www>

Within this directive, we add the code in order to make to run WebGUI under mod_perl with the followed lines:

<IfModule mod_perl.c>
<Files ~ "\.(pl)$">
SetHandler Perl-script
PerlHandler ModPerl::Registry
</Files>
</IfModule>
Options +ExecCGI

In place of the line PerlHandler ModPerl::Registry it goes used the line PerlHandler Apache::Registry if we are not using the Apache2.

Finally, we add, if already not present, index.pl inside the directive

DirectoryIndex.... index.pl

and preload all the modules demands from WebGUI so that several the processes of Apache can share such modules without having to load them everyone

PerlRequire /data/WebGUI/sbin/preload.perl

In order to complete the installation it is necessary to create the log files of WebGUI

touch /data/webgui.log

giving the writing permissions to the user of Apache

chown apache:apache /data/webgui.log

and giving the same permissions also to the directory of upload of way that the Apache can save the uploaded files by the users

chown apache:apache /data/WebGUI/www/uploads

At this point our installation would have to be completed. Opening the home page of our local box we would have to be in a position to seeing our installation working.

General characteristics of WebGUI

We begin to take familiarity with our future website navigating a few between the already present pages in the website of example.

The first time an eye expert notes is that all the visited pages have an URL that contains the string index.pl and in fact, you will have already been able to observe as this file is practically the only present in the public document root of WebGUI. The file index.pl is also called gateway and is just use its as gateway that it confers to all our website a more homogenous layout. Output of all the demanded pages will have to always be processed by this gateway that will stretch to conform their style to the general style of  website.

An other thing that leaps to the eye is that several pages are called without to pass parameters in the query string that is in that part of the URL that some times you will have seen present after the address and separated from this from an interrogative point.

In fact, contrary to other products, the parameters that define the page you wish to visualize in the browser, do not have pass through the query string producing to not mnemonic addresses like

http://www.example.com/index.pl?pagina=id_mia_pagina

but simulating an effect "at directory" for which a page of our website could be

http://www.example.com/index.pl/mia_pagina

This sure produces URLs more canonical and mnemonic and not cause moreover problems to the search engines that succeed to index pages of our website.

On the top, unnoticed the fields for the input of the username and password, symptom that, like pointed out previously, WebGUI allows the access to the resources.

A visitor, until it has not been authenticated, always has associated to a particular user to privileges zero called, not at random visitor. This user, as also all the other users, has associated automatically to a group called Everyone.

Once authenticated users belong to a group of the Registered users.

It's therefore possible to be associate also to more groups simultaneously like, as an example, to content managers that is the group of users who, by default, can change the contents of the website, or to admins group to which belong all whom have a complete access to the resources and the managements of the website.

Therefore, if as an example, a page is configured for being visible from everyone group wants to say that it is public and it is therefore visible from everyone, also from who has not been authenticated, because these users belong also to everyone group. If it is set up for being visible to the group of registered users then only who has already authenticated it will be able to see.

Other groups exist pre configurated with different privilege but, following the Unix philosophy, it is always possible to create others in order to define the permissions of access.

Always taking to loan the Unix-like philosophy, all the password are saved in the system in MD5 so, in the case that a password comes lost, not even WebGUI will be able to recover it and it will generate one another and sending it an to the e-mail configurated  in the user profile.

The user profile moreover does not contain only the e-mail but it can contain any information is desired to save. It in fact is completely personalized and hierarchized until defining what it is obligatory and what not and what type of data contains the single element. It's therefore possible to generate one user profile in the most selective way.

From theory to practical.

We begin therefore to use our new website entering in the world of WebGUI like administrator. A user with these privileges already exists and has always username admin and password 123qw. Obviously, above all on a accessible website from Internet, it is a good pratical  to change immediately this password.

As soon as authenticated, famous endured that, beyond to the classic link for the logout and link to the management of user profile, appears an other link with the label turn admin on. This link, than does not only appear only because we are administrators  but it appears also to those who have the permission to manage the content of the page, switch the layout of the page from view only to edit mode.

In such mode, we see to appear all a series of elements that, in the normal mode  do not appear. In particular there are two characteristics on which now we want to be focused.

The first is they are the two menu that appeared up and they will allow us, the one on the left to add new elements (assets) to the page while that other on the right collects all the possible instruments of administration.

The latter item is represented from those bars of buttons that divide the center of the page in distinguished elements.

We analyze the buttons that compose these bars. The first button from left is not in truth an active element, but only an identifier that characterizes a particular resource the bar belongs. As an example the first bar on the top is the bar of management of the page in its globality while the other bars are the bars for the configuration of the single assets with which the page it is composed.

Excluded this first button, the others execute operations on the corresponding element. As an example, the second buttons delete, after confirmation, the element putting it but in a basket from which it is always possible to recover it. In order to make this and, in any case, in order to manage the trash, an item is available in the administrative console.

The third button is used to change the contents of the asset while next two allow you to move it towards up or down relative to the others assets. The "cut" and "copy" cut or copy this element in the clipboard while the next one creates, in the clipboard, a shortcut of the element. The last button is used in order to move the element with the drag&drop of the mouse.

We analyze, for a moment, the clipboard of WebGUI in order to better understand the differences between the three buttons that have to do with it. Available from the left menu, once it is not empty, the clipboard is a memory zone where it is possible to move elements that they will be, in a some way, copied on an other page.

Pressing any button cut, paste or shortcut one will obtain that going in the clipboard menu we will find the correspondent asset identified with the same title it has the source asset.

Moving on another page and by clicking this element of the clipboard we will create one copy of the source element on this new page. The difference between cut and copy is in the obvious fact that the copied element disappears from the page begins them in the first case. The difference between copy and shortcut is light thinner. With copy, source and destination are at the beginning identical but it is possible to modify both subsequently without that the other endures modifications. With shortcut, the destination element is not modifiable in the content but, if we change the source, the destination is brought up to date automatically.

The clipboard is also available from the administrative console and here it is possible to execute more operations on it which, as an example, the cancellation of eventual copied elements here but never used.

General concepts on assets and WebGUI pages.

In the attempt to add one new page to our website, we have to discover one of the characteristics that makes WebGUI great. Every element authors can use is an asset.

Assets, a series of visual HTML elements, are just configured and ready to use. The page itself, is a type of asset that we will see it is called layout. An image is another asset called image, an element to execute poll is another asset called poll and so on.

We will see in the next article in detail everyone of these resources and what advantages carry the fact that all are "related" one another but now we can divide assets in two categories: those that can be containers others assets and those elements isolate  that they cannot be a container for others assets.

Only two resources belong to the first category : layout and folder. These two resources can in fact contain "childs" asset and they are only distinguished by the way in which they show these "childs". While layout  directly shows the HTML produced by every single child, folder print a page with links to every single child.

From a point of view of an user, layout it is substantially a page with different items, folder can instead be seen like a folder that links to subpages with a single item.

Obviously, being layout and folder an asset, it is possible that a folder can be a child of a layout or of another folder or a  layout to be a son of a folder. Moreover a layout can be a child of another layout but in this case the page becomes a subpage of the previous so to create a hierarchical structure of navigation of the pages evidenced in the site map and in the left menu. WebGUI in fact groups the pages in a hierarchical structure for which, being on a given page, if we add another one, this will be added as child of the previous page and this will be evidenced in the left menu and in the site map by the indent of the new page regarding the previous.

We go therefore to dealing the main container of WebGUI: a web page or, in other words, a layout. This is added in the website, through the item layout in the top left menu.

Click on such voice one page will be showed with a series of tabs. We take endured familiarity with it in how much, inasmuch as all it is a asset and that the same page is asset, some elements of this page will be common also to others assets.

The first one tab contains the general properties of the page. In the first place it is possible to set up the title of the page that will generate tag <TITLE> and <H1> of the HTML. The title of the menu can therefore be set up by the text that will be automatically inserted in the left menu and it is possible to specify a more mnemonic value that will be passed to the gateway index.pl for navigation to this page. The field title will be set like value of default if the title of the menu is not defined. If the URL will not be defined, WebGUI will generate one coherently with the position of the new page and using the title like base for the construction of the URL.

In the second tab it is defined the way in which this page will be visualized. The page does not be added, as an example, in the left menu and in the site map if it is active the flag hide from navigation.

Obviously the item open in new window will create a link to this page that open it in a new window of the browser. We can then assign the default layout for the page. Like already pointed out in fact, one of the characteristics of the C.M.S. it is that the graphics is defined in some predefined models and these are then apply to all the elements in order to obtain a more homogenous graphical aspect. The style template defines so which layout it will be embedded in the page that is what is, for this page, the layout of what them it is around the lateral elements, the top, the bottom and the cascade style sheet. Usually, in a website, all the pages use only one style template but nothing prohibits of having sections with different layout. To these pages another style template can therefore be applied.

The second combobox defines which style template to use in the printable mode. Every page can in fact contain a link that shows the page that is formatted in such way to be printed publication "without serif" from the user. The printable style will have therefore to head to template that it defines "more simple" a graphical context.

The template item in this tab defines the rows and the columns sections where you could added assets. The standard is a single vertical column but more complex models with two and three columns of various width or models with different horizontal and vertical sections are predefined. Obviously it is very simple to extend these models according with your own requirements.

The third party tab, called security, contains possible ties for this page. Therefore you can define the date of publication and automatic cancellation of the page, the definition of who is the author, which is the group that can see these pages and who can, beyond to the author, to edit it.

The last tab contains some property that influence the header of generated HTML page. In the first place in the field synopsis a short textual description of the content of the page can be given that is, as an example, read from the search engines and that it will be shown to the navigators which a "summary" of the page. In field Extra HEAD it is possible then to add whichever personalized headers you will require to be sent to browser untouched.

[ the explanation what is prototipe and a package is missing]

Notes on the inner operation of WebGUI

We see what macrocospically happens in WebGUI when a browser required a page from our website.

All requests for pages of the website are intercepted by the script index.pl that, for this reason, it has been identified like gateway. This script route the request to the WebGUI module (lib/WebGUI.pm) that it analyzes it and redirect it to the required assets.

Supposing that the request is just to obtain a page of the website, this is redirected from the WebGUI module to WebGUI::Asset::Wobject::Layout module (lib/WebGUI/Asset/Wobject/Layout.pm) that it obtains by database the lists and the content of all childs assets inserted in the page by the author.

The content of the pages, the assets, and the property of the same assets are not save on the filesystem but on tables of the database. Therefore, for every assets of the page it is the relatie WebGUI::Asset::XXX (lib/WebGUI/Asset/XXX.pm) that, based on the data available on the database, will return the specific HTML block. All these blocks, together with the skelethon of the page are passed to a module of templating called WebGUI::Template (lib/WebGUI/Template.pm), that it supplies to assemble all and to return the BODY of the page. This, encapsulated in the HEAD is returned to the browser with the defined style.

Conclusions

In this article we have analyzed some general characteristics  of C.M.S and in particular of WebGUI. We have seen like installing it and a panoramic of the properties of the object layout that is the object that is to model in the creation of every page in WebGUI.

In the next article we will see like filling up such pages with the instruments offers from WebGUI: the assets.