Using keyword attribute is a very convenient method of improving the site's navigation system and leading users to the content of their interest.
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:
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.
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 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:
Two methods of autoload regeneration are provided: a command-line version and through the Administration Interface (for example in the Setup/Extensions).
Certain features have been deprecated. These will gradually be removed in a future release, when better replacements are ready.
Deprecated datatypes:
Deprecated views:
Deprecated kernel libraries:
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:
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
I might have started working on this site back around eZ Publish 3.9.0 or so. But there's always something of greater priority and you end up putting it off endlessly...
Well, not any more! There's still things to prepare and enhance, probably some bugs, too. But I made up my mind to get it running this year and here you go ;)
A blog? Not sure... probably a blog-form developer's notepad. We'll see... I've never run a blog before, don't know what to expect ;) I believe, stable version 4 plus my first steps with extensions are good enough reason to have it on. So it's on!