December 2007

Introducing two new components: Tree and Webdav.

The Tree component enables to create, manipulate and query tree structures, with several back-ends available, each with different performance-related properties. Two tie-ins are available for this extension: TreeDatabaseTiein for storing tree structures in a database (which is recommended at this point) and TreePersistentObjectTiein.

The Webdav component brings easy setup if a WebDAV-enabled HTTP server, which results in users' ability to create and edit site content by uploading and downloading files to and from their desktop. The current implementation is compatible with RFC 2518. It also supports clients that do not conform to the standard and provides an interface to support these clients. This component does not have any other dependencies besides PHP (and the required extensions), nor does it require any Apache modules.

For both PHP 5.2.1 or higher is required.

This release also brings some changes, mainly to Cache, EventLog, Graph, and more.

Full details: http://ezcomponents.org/resources/news/news-2007-12-17

There's a completely non-invasive method of making eZ Components available for eZ Publish installation, which would be especially useful in shared hosting environment, where custom server changes are not allowed or possible. Simply place your eZ Components bundle wherever that eZ Publish'es PHP can reach. Then create a config.php file on the eZ installation's root, and set additional include paths for PHP:

Just adjust the path matching your environment, and that's it. eZ 4 already knows that it should look for it.

Using keyword attribute is a very convenient method of improving the site's navigation system and leading users to the content of their interest.

Limitations

If you're planning to use keywords attribute for anything that should behave as managed, then you shouldn't use the datatype for any other purpose within the same eZ Publish installation. Or, on physical level, you shouldn't have more than one keywords-datatype-based attribute per content class.

At this point keywords datatype stores all its values in one flat database model that does not provide any means of grouping or categorization on the attribute level (it is possible to fetch keywords based on the content class, but that's not exactly what's needed).

Example:
If in your article class definition you want to have two separate attributes for meta keywords and tag cloud tags respectively, then you should only choose keywords datatype for the tag cloud and another one, for example a text line, to collect data for meta tags. If you choose keywords datatype for both:

• You will often find yourself making decisions whether place given phrase in the first, in the latter, or maybe both, which means terrible management with little control...
• You will get duplicates in the content/keyword view as well as duplicate counts (tag cloud becoming less accurate),
• Your keyword index (and database table) will grow for no particular reason.

That text line is perfectly indexable for search and as long as you don't require any logical operations on the collected data, then it fits most needs just fine.

One possible solution

Now, I've mentioned that it is possible to fetch keywords by content class(es), but that is an answer to "where" question rather than "what question". What if you want to have 5 keywords attributes in your content class, for 5 different purposes?

Solution seems quite simple. Keywords datatype could have an additional ID, that would make it possible to group keywords on attribute level. This could be simply an integer/string typed by the user when defining a content class, or it could easily become a drop-down list of labeled options, if an extremely simple mechanism/manager for managing keyword groups was implemented.

eZ Publish 4 autoload generation (requires eZ Components installed)

eZ Publish 4 uses the PHP-5 autoload feature to load classes, which means that when new classes are introduced to the system, the autoload arrays need to be updated. There are several situations when a user might want to regenerate the autoload-arrays:

1. After upgrading eZ Publish, to recognise new classes in the eZ Publish kernel
2. When adding a new extension to the site, to make its classes available to eZ Publish.

Two methods of autoload regeneration are provided: a command-line version and through the Administration Interface (for example in the Setup/Extensions).

Other technical changes/issues:

• It is no longer possible to include template files from the override directory directly, and also override templates are only searched for within override directories. Details/background: http://issues.ez.no/IssueView.php?Id=9595&activeItem=25
• Code has generally been cleaned up, several constants were moved to suitable classes. This may be one of the key problems with extension's port to 4.0.
• Static class functions are now marked as static and some clean up where necessary on class functions that worked both as static and as member.
• Some methods where renamed to comply with PHP5 naming rules.

Deprecated features in eZ Publish 4

Certain features have been deprecated. These will gradually be removed in a future release, when better replacements are ready.

Deprecated datatypes:

• Enum (upgrade script available)
• Ini setting
• Subtree-subscription
• Multi-option (replaced with Multi-option2 in 3.10)
• Package

Deprecated views:

• PDF view
• PDF export
• Global settings
• kernel/form

Deprecated kernel libraries:

• ezxml
• kernel/common/ezoverride.php

Just few months back it seemed like this moment was never going to come...

eZ Publish 4.0 is out there, stable. For those, who don't understand the excitement, little summary. eZ Publish 3.x is (I don't think it's appropriate to say was just quite yet...) doing fine, with hundreds of extensions and thousands of production installations all over the world, but has been getting old for some time. It still only works with PHP4, whose official development and maintenance will seize in just moments. That includes the willingness of hosting providers to keep it running on their platforms. But PHP4 leads to at least two other major problems. One - it offers a very simplified, less efficient object model, and eZ Publish happens to be essentially object oriented, plus more and more so seem PHP developers right now. PHP5 takes that problem away. Two - PHP4 makes it impossible to make use eZ Components and that hurts.

These are the major changes in new version eZ Publish, according to the eZ Systems release announcement:

• Complete PHP5 compatibility
• Full support for using eZ Components, eZ’s PHP enterprise components library
• Performance improvements
• Improved internal XML handling for increased performance and reduced memory usage
• Updated Website Interface with new graphical design and enhancements

Don't expect a revolution, though. You'll see the same administration interface, same old good content management model, same file structure, same setup wizard... As a matter of fact, eZ Publish 4.0 is a PHP5-refactored 3.10.x. Besides, revolution was neither needed, nor demanded.

You can download latest eZ Publish version from http://ez.no/download