All static pages are transferred from the staging server platform to the dissemination server platform. FTP is used for these transfers. In principle these transfers are only executed after approval of DG PRESS (for EUROPA) or DG ADMIN (for IntraComm). This approval can be delegated to the information provider, as is the case for most of the contents.

Procedure description

4 files are used by the automatic procedure, and for each 'sub-site' these files have to be located in the root directory of that 'sub-site' on the staging server. All file names used inside these 'request' files are relative to this root directory (metacharacters (* or .) are not allowed).
I will (try to) clarify this later with an example.

• .request.delete lists all files and/or directories that are to be deleted from the production server.
• .request.update lists files and/or directories that have to be added or updated from the staging server to the production server.
  • files are copied only if a newer version exists on the staging server (based on the last modification date).
  • directories include recursively all sub directories. All files found in the production directories that do not have a counterpart on the staging site any longer will be deleted from the production site.
  • "<ALL>" can be specified as the only entry in order to copy the whole hierarchy. Even if this is the easiest way to proceed, this must be avoided as much as possible, because it implies a much longer processing time. By the way ... ALL really does mean: ALL.
  • The files are first copied to a temporary environment where checks are made. Missing files or files containing errors (absolute links, etc.…) might stop the procedure and none of the files will be copied to the production server at all.
• .request.lock is created at the start of the automatic procedure meaning that no one should modify any of the files from the staging directory until this file has been removed by the procedure.
• .request.output contains the results of the procedure. All the files which have been deleted and copied are listed. Error and warning messages can be found.

Sample .request.update file:

Let's go back to the example from the chapter on "Data Structure for Web Pages":

Suppose Mr Grimm has updated the pages under "http://europa.eu.int:8082/comm/fairy_affairs/". He has updated the staging version of the home page "index.html" and added a few GIF files in the sub-directory "images". The file index.html is located in "/europa/public/htdocs/comm/fairy_affairs", and the directory is located under that same directory. In order to have the file "index.html" and the contents of the sub-directory "images" copied in to production the ".request.update" file should look like this:

index.html
images

The automated procedure to update the production site will copy the file "index.html" and the files that have been changed or added in the sub-directory "images", and eventual sub-directories of that sub-directory, to the production site.

The ".request.update" file has to be uploaded into the directory "/europa/public/htdocs/comm/fairy_affairs" because this is where the automated update procedure will look for it. The "request" files at that location can be used to maintain information that is located in the directory "/europa/public/htdocs/comm/fairy_affairs" and its' sub-directories.

Important remarks:

• The .request.update and .request.delete files should be created only after all modifications on the staging site have been completed, because the presence of these files means that the listed data are ready to be copied.
• The presence of .request.lock file means that the procedure has started and has not completed yet. No one should modify any of the transferred data on the staging server until this file has been removed by the procedure.
• .request.delete, .request.update and .request.lock are always deleted at the end of the procedure.
• .request.output contains only the result of the latest execution of the procedure. This file is overwritten at each execution, so the preceding results will be lost. If you want to keep a history of your modifications, then you will need to save this file under another name. The contents of the .request.output can be sent to you automatically by e-mail.

Procedure triggering

The procedure can be triggered in different ways :

• automatically every night (starting at 22:00 hours).
• automatically at set times of the day (for example: at 13:00 and 22:00 hours).
• immediately through the staging manager web interface.

The EUROPA team at DG Press manages who can trigger updates, when updates are triggered, and for which data on the EUROPA main contents web server. For IntraComm these tasks are still performed by the DC web dissemination team.

Important remark:

In an effort to accelerate the updates and to reduce the clutter on the production servers, we decide to not copy some (useless) files/directories.

Here is a list of files that are not copied (where '*' represents one or more characters)

• .* (file names starting with a period)
• ~$*
• finder.dat
• ws_ftp.log
• *.$$$
• *.backup
• *.bak
• *.bck
• *.bk!
• *.old
• *.tmp
• lost+found

Files/directories with file paths containing the following patterns are not copied either:

• _vti_*
• _derived
• _private
• resource.frk
• lost+found

Empty files and directories are not copied.

Another important remark:

Any updates of the production servers impact their performances. This is why Admin-DI-DC avoids as much as possible the execution of transfers into production during the day time. To avoid repetitive transfers of a set of data (especially due to errors), you are kindly requested to check in depth and carefully your site locally before requesting the transfer into production.