Recently I've been playing about on the eZ Publish projects site
and have joined a couple of projects. One that I've previously has some involvement in is Kristof's xajax plugin.

I quite like xajax as it's takes care of most of the javascript and allows you to manipulate the browser DOM via PHP.

I've joined the project as a member, updated the xajax libraries to 0.5 beta 4 ( they were on beta 2) and created a download.

Initially I was going to upgrade the extension to work with eZ 4.0, however there was nothing to do. It works fine in eZ 4.0 and my changes are simply an upgrade to the xajax library.

Given the extension basically exposes the xajax libraries and is unlikely to change too much I wonder it it's worth linking the version of the extension to the xajax library version?

Happy xajaxing!

Home.pl is Poland's largest hosting provider. Despite the fact that they do not have eZ Publish-dedicated services and their machines do not exactly match its standard requirements (FreeBSD, PHP in CGI mode), it is possible to successfully deploy eZ 4.0 installation in their shared hosting environment. Since many people seem to have problems getting through the installation wizard, here's some tips.

Organization

Put the files in a subdirectory and use the subserver functionality (in other words: point the domain to that subdirectory). This is not only because of some possible namespace conflicts (0:/bin is reserved by the system), but also for good organization and easy management. Since a subserver cannot reach above its own root, remember to create a /tmp dir for any temporary files.

Wizard problems

If you try to install version 4.0 from scratch, you may encounter some early problems. This is due to the fact that some systems functions are called during setup tests that cannot handle an error in this environment (which is FreeBSD-like by the way). You can easily cope with that by simply commenting out a line in /kernel/setup/ezsetuptests.php:

This is practically never used again, so don't worry, you may revert the changes after installation, or even leave it like that.

Limitations

For a number of reasons, this hosting will only serve a number of use scenarios. The major problem is a script-like CRON, which works on PHP rights, which means it has the same limitations. It will be impossible to safely run large, exhausting notifications or maintenance scripts... Lack of CLI makes it even harder, and can only be partially compensated by enabled system() PHP function. Still, with a little practice it is possible to tame it, especially with servers' above-average efficiency.

Today, I have learned that my eZ Publish extension Video FLV Datatype is now used in a real site : Zenaba . It's a french community and shopping site dedicated to women. Video FLV Datatype is used to provide FLV conversion so that user's videos can be viewed by anyone having the flash plugin installed. I'm very happy to see that even I don't need to braid my hair :-)

In addition, thanks to my interview in the first issue of Share magazine , Bruce Morrison has reported some problems. He also proposed interesting ideas in the project's forum. So, he's now a member of the team .

Just looking at the priority that the settings files follow:

Gunnstein wrote at http://ez.no/doc/ez_pub...site_management

It seems like the main/siteaccess/override model for settings files and its advantages weren't introduced to extensions' engine. Here's some issues I see:

1) Let's call it convenience and flexibility: One great feature of the three-step system (and - as far as I understand - one of its key functions) is that we have untouched original *.ini files with all/default settings present, the rest are siteaccess-dedicated or global overrides. This is a great in case of any upgrades, modifications, or simply for reference. I don't see this possibility for extension settings (unless we move the overrides of custom *ini files to the global overrides, but that isn't that convenient we have 10 or 20 extensions...).

2) Security: This actually results from the above. If there is no general override, all your general custom settings will most probably be kept in the main *.ini file. That may include project-dedicated values, passwords, options, etc. The file should then always be called *.ini.append.php, which is easy to forget about.

3) Rules: While with the general settings siteaccesses overrule general files and global overrides overrule all of them, the rules seem less clear with extension settings... that includes both the priorities and the names (look at the security point).

Here's what it could look like (just a quick idea):

1. Default settings [/settings/*.ini]
2. Default extension settings [/extension/EXT/settings/*.ini] (only for custom *.ini files)
3. Extension siteaccesses [/extension/EXT/settings/siteaccess/SITEACCESS/*.ini.append.php]
4. Siteaccesses [/settings/siteaccess/SITEACCESS/*.ini.append.php]
5. Extension overrides [/extension/EXT/settings/override/*.ini.append.php] (for custom *.ini files as well as other *.ini files)
6. Global overrides [/settings/override/*.ini.append.php]

Of course, that would require little changes to directory structure, might be difficult.

I put this on the forum, haven't given this as much thought as I would like to, so... let's see what happens ;)

Version 1.2 of the Workflow component that is part of the eZ Components introduces a plugin system that allows developers to hook into the workflow engine at well-defined extension points.

For now, plugin code can be called

• after an execution has been started
• after an execution has been suspended
• after an execution has been resumed
• after an execution has been cancelled
• after an execution has successfully ended
• before a node is activated
• after a node has been activated
• after a node has been executed
• after a service object has been rolled back
• after a new thread has been started
• after a thread has ended
• before a variable is set
• after a variable has been set
• before a variable is unset
• after a variable has been unset

ezcWorkflowExecutionListenerPlugin and ezcWorkflowExecutionVisualizerPlugin are two workflow execution engine plugins that will ship with Workflow 1.2. The former is a refactored version of the execution logging code of Workflow versions 1.0-1.1.

The latter is new and can be used to visually log the execution of a workflow as shown below.

The ezcWorkflowExecutionVisualizerPlugin generates a series of DOT files that can be rendered into single pictures using GraphViz. For the animation above, I crudely joined the single images to an animated GIF.

The before hooks are special as they allow the plugin to change (or even prevent) the current execution step. This will eventually allow for Aspect-Oriented Programming on the workflow level.

I started liveblogging Adaora Onyia’s, “Hello, Can Anyone Hear Me?” session, but after a few moments abandoned the attempt – the presentation left me too conflicted to easily commit notes on it to text.

Adaora’s presentation described survival tactics for a workplace that I’d prefer never to enter, along with gender roles that I’d rather not find myself or others constrained to.

The SCALE organizers should be posting video from the presentation shortly; I’d recommend viewing it, but also taking it with a grain of  salt in the form of books, “Maverick“, “Why We Lie“, “First, Break All the Rules” and anything by Pema Chödrön

Related posts SCALE 6x LiveBlogging: Linux in Early Education (1) Conference Report: OpenMind & MindTrek 2007 (5) Sharing information (0) Scale 6x: Stormy Peters: What is a Community Manager? (0) SCALE 6x: Getting There (3)

By Sunday morning, SCALE had wound down. Various participants were scattered around the hotel lobby – chatting about the previous days, waiting for shuttles with their bags and napping after a few to many late night discussions. Outside the hotel, a small army of police had gathered in the wake of an unfortunate window-washer falling to his death.

Early in the afternoon, Josh and I drove back up to the Bay. Traffic wasn’t bad, but there was a massive, low-intensity dust storm that was spread over a few hundred miles of farmland outside of LA. As dusk neared, the haze in the air magnified and reddened the sun until it was a great fiery disk looming over the horizon.

The trip back (and the following visit to the Mozilla Corporation offices) was lighter and less expensive than it could have been. I car-pooled most of the time and stayed with friends in Santa Clara and San Francisco rather than in hotels.

I’m happy to have been able to cut out four short-hop flights, seven nights of individual hotel stays, six restaurant meals and eight taxi rides. Along the way I had a lot of great conversations and companionship. All in all, the traveling was great – I’ll write more about the conference itself shortly.

Related posts Mozilla Foundation Report for January 2008 (0) Mozilla Foundation Report for 2008 Week 5 (0) SCALE 6x: Getting There (3) Planning my SCALE 6x Attendance (4) php|works: Mozilla agenda (0)

Inspired by Bruce Morrison's post in his blog: http://suffandnonsense.blogspot.com/2008/02/is...

eZ Publish 4.0

I kind of understand the disappointment with minor revolution of the current big version 4.0, although I had known (more or less) what to expect when I was awaiting it few months back. You can ask yourself: was PHP5 more of an improvement, or maybe a necessity? If the latter, the smaller was the step ahead, indeed. Nevertheless, I am very glad this step was made, no matter what the version is called, for reasons that must be obvious. Back to the expectations, I can only imagine how 3.x introduction was different (greater) to 4.x, because I've only known eZ Publish since 3.8.x or so (BTW: have to admit I gave up after several attempts with 3.5... it beat me!).

eZ Publish 4.0 maintenance mode, 5.0 eZ Components-based rebuild

Bruce's suggestion is to put eZ Publish 4.0 at its rather stable state into feature freeze mode, while concentrating efforts on taking full advantage of the maturing eZ Components to produce the next big version (5.0) from scratch. I have to say that I like this idea for similar reasons:

• There's always a risk of ending up with Vista-like model,
• It will probably take equally long (or even longer) to incorporate majority of eZ Components into eZ Publish (with compromises possible/necessary on the way), than it would have taken to build a completely fresh thing,
• Past limitations and problems will probably become even more concreted,
• I believe that eZ Components with all their features would prolong the application's lifespan, secure its potential and make future port to PHP6 easier (I'm not sure if another platform "rewriting" would be a good idea).

There's another thing, but it deserves to be covered in its own paragraph.

Solid content model vs. feature richness

In my comparatively short experience with eZ Publish, I have already dug deep enough to see its few weaknesses, especially regarding the content and storage models. Don't get me wrong, by no means would I call eZ Publish weak, it's just that it has its limitations defined and there are only so many things you can do with it without hacking or severely extending.

Now, I do understand how big part various "rich" features play in the eZ business model and in those of many eZ partners. For example, extensions such as eZ Flow or Web interfaces that make it possible to have an advanced out-of-the-box product with time required for implementation significantly reduced. Having seen how business-oriented eZ people are, I do not expect this direction to be given up at any stage (and I like that).

However, I hope that that direction does not prevent from improving the application at its core, that is the foundation for all eZ business after all. Unlike presentation layer or even more advanced extensions, which can be developed independently, core upgrades would be rather difficult to be introduced by means of hacking the kernel. I'd like to be optimistic, but don't see alternative storage models or advanced class features coming any time soon. New rebuild could be an ideal opportunity to make eZ Publish even more versatile and fit to solve even more advanced content management tasks (and not only!).

Summing up

It doesn't seem like this issue is up for a discussion, but I haven't heard anything official on eZ Publish 5.0, yet. So, maybe it is not too late ;)

If you ask me, I think I could live in this 4.0 feature freeze mode... if what I was waiting for was a completely new eZ Publish 5.0 in a year or two, with even greater core features and as few compromises as possible.

For me it's probably one of the most waited feature in eZ Publish after the PHP5 port with eZ Publish 4 ! It's only a beta release but it looks very promising. There's a document in the SVN repository or in the archive explaining new features.

It's based on Tiny MCE rich text editor , so Internet Explorer (including IE7 under Windows Vista), browsers based on Gecko (Firefox ...), Opera and Safari are now supported and unlike the old one, there are not two code bases for two navigator families ! It's also more flexible as we can add or remove buttons and functionnalities (like an underline button). After reading the document and a small test, there is one feature I would like to see, it is the hability to easily customize the drop down list (paragraph, preformatted, headings) with others styles / tags like the style configuration in FCKEditor . It can probably be done with a Tiny MCE plugin but a simple setting in eztinymce.ini file would be a simple but very useful tool !

The first day of SCALE 6x, I camped out in the Women in Open Source track. One of the sessions that I caught during this day was Stormy Peters’ excellent, “What is a Community Manager?” presentation. My notes - in point form rather than prose - follow.