Upgrading Old Sites

The 2.0 release introduced major changes to RXML, tag modules, the port handling as well as the administration interface. Though most of the changes are backwards compatible, it is possible to move a 1.3 site to a newer release with no or very minor changes.

The configuration files have changed. It is therefore not possible to just upgrade an 1.3 site, you need to reinstall it. The same, or compatible, modules are available. Loading an 1.3 configuration with the old RXML parser will

RXML Changes Between 1.3 and 2.0

Roxen 2.0 uses a new XML compliant RXML parser, which means that RXML tags must now always be terminated with an end tag or a /. For example <roxen />. Output tags, (formoutput, sqloutput, ldapoutput, etc) have been replaced with the <emit> tag and variable entities. Many simple tags have been replaced with entities instead. <realfile> is now &page.realfile;.

The new RXML is simpler to use and less prone to errors. Especially the more complex uses of RXML, such as databases, are much simpler and safer. It is therefore important to convert existing sites to RXML 2.0.

However it is not necessary. By enabling the Old RXML compatibility module, Roxen will be compatible with the old RXML parser, both in features and misfeatures (one of the many reasons for the upgrade was to fix design bugs present in 1.3 and previous versions of Roxen).

RXML Changes Between 2.1 and 2.2

In 2.2, the font rendering engine was heavily upgraded and bugfixed, which led to <gtext> and <gbutton> images suddenly being correctly rendered, respecting the font sizes given in the font files. Unfortunately, this means that a <gtext> tag that rendered images of one size in Roxen 2.1 or earlier typically renders to a different size or with different spacing in 2.2. How much you have to alter the fontsize (or scale, if you aim for a somewhat rough result) attribute to get your preferred size depends on the font in question.

Gradual Upgrade

Since the changes to RXML are so great it might be necessary to gradually move from RXML 1.3 to RXML 2.0. This can be achieved in several ways. The safest way is to keep the 1.3 release running in parallel with a 2.0 server, and switch when everything works. By using the HTTP relay module the web site can still seem like one, although two servers handle it. For more details of how to do this, consult the article "Transparent Roxen Migration" at http://community.roxen.com/articles/008_migration/.

Another way to handle the gradual upgrade is to use two sites: one new RXML 2.0 site and one with the Old RXML compatibility module installed. The compatibility site could be run on an URL of the new site, for example http://my-site/old/. By using the HTTP Redirect module it is then possible to overload the two sites so that it seems like one site.

Modules and Pike Scripts

The module API is backwards compatible with previous releases. Minor differences in the inheritance as well as in Pike's class library might cause compatibility problems with a few modules or scripts. If you site relies on third-party modules or scripts from releases previous to 2.0, you might want to wait until they have been tested with your release. If you have programmed any modules or scripts yourself you should test them on a fresh server before upgrading a live site. The compatibility errors should be found when compiling the modules or scripts and thus be easy to locate.

		Upgrading Old Sites The 2.0 release introduced major changes to RXML, tag modules, the port handling as well as the administration interface. Though most of the changes are backwards compatible, it is possible to move a 1.3 site to a newer release with no or very minor changes. The configuration files have changed. It is therefore not possible to just upgrade an 1.3 site, you need to reinstall it. The same, or compatible, modules are available. Loading an 1.3 configuration with the old RXML parser will RXML Changes Between 1.3 and 2.0 Roxen 2.0 uses a new XML compliant RXML parser, which means that RXML tags must now always be terminated with an end tag or a `/`. For example `<roxen />`. Output tags, (formoutput, sqloutput, ldapoutput, etc) have been replaced with the <emit> tag and variable entities. Many simple tags have been replaced with entities instead. `<realfile>` is now `&page.realfile;`. The new RXML is simpler to use and less prone to errors. Especially the more complex uses of RXML, such as databases, are much simpler and safer. It is therefore important to convert existing sites to RXML 2.0. However it is not necessary. By enabling the Old RXML compatibility module, Roxen will be compatible with the old RXML parser, both in features and misfeatures (one of the many reasons for the upgrade was to fix design bugs present in 1.3 and previous versions of Roxen). RXML Changes Between 2.1 and 2.2 In 2.2, the font rendering engine was heavily upgraded and bugfixed, which led to `<gtext>` and `<gbutton>` images suddenly being correctly rendered, respecting the font sizes given in the font files. Unfortunately, this means that a `<gtext>` tag that rendered images of one size in Roxen 2.1 or earlier typically renders to a different size or with different spacing in 2.2. How much you have to alter the fontsize (or scale, if you aim for a somewhat rough result) attribute to get your preferred size depends on the font in question. Gradual Upgrade Since the changes to RXML are so great it might be necessary to gradually move from RXML 1.3 to RXML 2.0. This can be achieved in several ways. The safest way is to keep the 1.3 release running in parallel with a 2.0 server, and switch when everything works. By using the HTTP relay module the web site can still seem like one, although two servers handle it. For more details of how to do this, consult the article "Transparent Roxen Migration" at `http://community.roxen.com/articles/008_migration/`. Another way to handle the gradual upgrade is to use two sites: one new RXML 2.0 site and one with the Old RXML compatibility module installed. The compatibility site could be run on an URL of the new site, for example `http://my-site/old/`. By using the HTTP Redirect module it is then possible to overload the two sites so that it seems like one site. Modules and Pike Scripts The module API is backwards compatible with previous releases. Minor differences in the inheritance as well as in Pike's class library might cause compatibility problems with a few modules or scripts. If you site relies on third-party modules or scripts from releases previous to 2.0, you might want to wait until they have been tested with your release. If you have programmed any modules or scripts yourself you should test them on a fresh server before upgrading a live site. The compatibility errors should be found when compiling the modules or scripts and thus be easy to locate.