ibexa

Path

ez publish / technical manual / 3.10 / features / packages / package types


Caution: This documentation is for eZ Publish legacy, from version 3.x to 5.x.

Package types

The following package types are supported:

  • content class packages
  • content object packages
  • extension packages
  • site style packages (design packages)
  • site packages

Content class and content object packages

A content class package allows the storage of class definitions. If you create several classes and need to use them on other installations, you can export these class definitions into a content class package. The package itself can be then exported into ".ezpkg" file. This file can be then imported and installed on other eZ publish installations.

Content object packages are used for storing actual content objects. If you create some objects and need to use them on other installations, you can export these objects into a content object package.

The package creation wizard will ask you to select nodes and/or subtrees that will be included to the content object package that is being created. It is possible to include class definitions for the objects being exported and related templates from one or several siteaccesses to the package. The selected objects can be exported together with all their versions and languages or you can specify custom parameters. You may choose to keep all node assignments or only main nodes for the objects being imported and specify what to do with related objects.

Datatypes serialization support

In eZ publish 3.8 all the built-in datatypes are compatible with the package system. Both object and class serialization are supported. If you use an additional datatype that does not support serialization then you will see a warning when trying to export/import class definitions and/or content objects containing attributes of this datatype.

Extension packages

These packages store extension files. If you create an extension and need to use it on other installations, you can export it into an extension package. The administration interface makes it possible to create extension packages.

Design / site style packages

Site style packages store site design themes. Such packages make it possible to change the look and feel of the site easily. A site style package includes non-content specific images (logos, banners, graphical layout elements etc.) and two CSS files ("site-colors.css" containing styles like color codes and background image details for the pagelayout and "classes-colors.css" that determines styles for class templates).

Please note that site style packages can not be installed or uninstalled. If you import several design packages, you will be able to switch between them using the administration interface. The next subsection explains how this can be done.

Changing the site style theme

Let's say that you have imported a new site style package. To change the look and feel of your site according to the imported design theme, do the following:

  1. Click the "Design" tab in the administration interface and select "Look and Feel" from the menu on the left.
  2. Select the desired site style from the "Sitestyle" list.
  3. Click the "Send for publishing" button to save your changes.
  4. Go to the actual site and refresh the page. If you can't see any changes then you should clear eZ publish caches.

Site packages

The special packages provide basic site examples like "News", "Shop", "Gallery" etc. mostly for the purpose of demonstration and learning. Site packages do not contain any objects. However, they contain dependencies to other packages plus specific settings and scripts. These packages can not be installed or uninstalled. Site packages can be thought of as "meta packages" that are used only in the setup wizard when you are installing eZ publish. (If you remove a site package from internal repository, this will not affect the behavior of the installed system.) It is not possible to create site packages using the administration interface.

The setup wizard automatically fetches the list of available site packages from remote and internal repositories and asks the user to choose one. It will automatically download the selected site package and all its dependent packages, import them to the system and display a list of successfully imported packages. (This step will be omitted if all these packages are already stored under internal repositories.) All dependent packages except for the site style package will be automatically installed.

Example

The "Shop site" package v.2.0.6 contains dependencies to the following packages:

  • Three content object packages called "Products", "Multi-price products", "Dynamic VAT products".
  • A site style package called "Theme 04".
  • An extension package called "ezpaypal extension".

Choosing the "Shop site" package in the setup wizard will result in downloading this package and five dependent packages from http://packages.ez.no/ezpublish/3.10. The downloaded ".ezpkg" files will be unpacked into the "var/storage/packages/ez_systems" directory (i.e. these packages will be imported to the system). The wizard will then automatically install the "Products", "Multi-price products", "Dynamic VAT products" and "ezpaypal extension" packages. The "Shop site" and "Theme 04" packages will not be installed (as site package and site style package). When the setup wizard is finished, you can safely remove the "shop_site" package manually or using the administration interface. The removal of a site package will not affect any of its dependent packages.

Svitlana Shatokhina (16/06/2006 3:29 pm)

Julia Shymova (19/03/2008 4:56 pm)

Svitlana Shatokhina, Balazs Halasy, Julia Shymova


Comments

  • Matching of content class and content class attributes in content object packages

    For who's wondering how the matching work of content class and content class attributes works when content object packages are imported:

    - package system first tries to fetch content class with remote id
    - if previous step fails, it tries to fetch content class with the identifier
    - content class attributes are matched by identifier only (although the package format does contain their exported remote id)