Does eZ Publish have its own blue screen of death? Yes, it does! It is the setup wizard on a production site. And how do you make go off? Well, it's quite enough to have anything about site.ini global override messed up: transmission error, solid syntax error, etc... Over thirty eZ installations and deployments, I was calm enough to figure it out just in seconds, but it still made me sweat... And imagine a beginner... ;)
An interesting topic emerged among suggestions in the ez.no forum, regarding themes for eZ Publish. I thought it was an interesting theme, so here's the link: http://ez.no/developer/forum/suggestions/provide_new_themes
And here's what I think:
I have to agree that easier theme management and exchange would help to widespread eZ Publish. Personalization seems like the big thing right now and even if it's not about that, ability to implement selected themes easily might be one of the key factors when deciding on a particular CMS.
However, we need to realize what theme engines we're talking about when trying to incorporate that idea into eZ Publish. Most themes that I know of are prepared for systems that have a very isolated and precise functionality due to the kind of system they are (CMS blogs, forums, shops, web galleries, CRMs, or CMSs with preexisting module sets, etc..), and whose content model, internal structure etc. do not change.
Meanwhile, with eZ Publish we have a content engine that makes it possible to handle most of the above functionalities and nearly everything can be customized. With the system we don't have preset roles for a forum, for a blog etc - we have to arrange that ourselves, minding all the implementation details. There's entire list of other dimensions that have to be taken under consideration (sections, access rules, caching, custom overrides, class modifications, structure...). Many of those things are handled or reach to the presentation layer (*.tpl), many of them in a customized way, again.
If some of the themes available for those other, isolated systems, have to be versioned along with the core (for example: theme for version 2.0, theme for version 2.1, etc..), how do we want to handle the change with eZ Publish and its complexity? Would that be possible without limiting of what's one of eZ's key features - extensibility? Wouldn't that concrete the development of the core in some ways?
If I look at ezwebin, I see an intelligent GUI, not a skin. This interface is crucial for developers to ease the learning curve and also pick up some good practices, but with around 40 eZ Publish implementations, we haven't yet had a customer who would fit into ezwebin precisely (or sometimes - at all).
Much as I appreciate the marketing goals, I don't think they are that important for this level of CMS (and ezwebin versions do just fine for that matter), and nowhere near as important as the core of the system. And there's only so much time eZ people have. I believe we're all much better off getting solutions such as eZ toolbar or eZ Flow (or bug-free stability and security) rather than color variations of backgrounds...
To be continued... here:
Well, I gave up my variable caching ideas, even if just for a while. I wanted to master the standard caching techniques (there had always been an excuse, some extension to write...). And I am very glad now because it starts to feel like having real control over my eZ implementations ;)
Among things that I've discovered were persistent variables, recommended by Gaetano in response to my var cache struggling, and completely unknown to me before. Even if not a complete substitute, still a very nice solution, one of those that you ask yourself how you could have lived without...
So what's so great about persistent variables without going into much detail?
They don't require any additional control. Persistent variables are compiled as part of viewcache, which means that they only expire when the viewcache expires, and they naturally follow the smart viewcache clear rules as well. What more control needed than that?
They seem to be available at all times, if not cached before, calculated upon request for the full view that stores them.
This also means that expiry times of cache-blocks that depend on that data do not have to be synchronized in any way (not that it is even possible...). Gaetano mentioned the relationship between viewcache and cache-block clear being an important issue, but I haven't been able to spot any unwanted or problematic link, yet.
Persistent variables can indeed store a variety of data useful for further generating parts of the pagelayout. Even if the singular cost of viewcache generation goes slightly up, this is usually benefitial: once generated, the variables are simply there as long as needed. And in most cases all I need is some $node-related operations.
Even if some more expensive data is to be fetched, once you're through the effort of composing you persistent hash, it's there!
Since the variables are physically serialized, it is impossible to pass complex objects, such as $node directly. You have to precisely choose which simple data you want (numbers, strings, arrays, hashes...). Luckily, arrays do just fine in most cases, so that's probably as much as one may need before going straight to a fetch outside of a full view.
Then, some includes seem to be able to damage a persistent var that had been generated few lines before, so you have to carefully test if the persistent var set is available in all the full views required. Haven't found an exact rule, yet.
If you're interested if a very nice use example, look here in the comments.
A busy week expected in the fourth week of June this year:
Tutorials, break-out sessions, talks and presentations, barcamp... some topics announced till now include: performance and testing, improving usability & accessibility in eZ publish, web 2.0, OpenID, integration between ez publish and Ajax frameworks, Open office integration, eZ Components, eZ Find, TinyERP integration, microformats...
The annual eZ Conference & Awards is the largest Open Source CMS event in Europe. This year marks the 6th annual eZ Conference and new this year is that it will be run together with the Open Nordic Conference and the Open Nordic Mobile event. This is without doubt, the biggest event ever held in Europe with main focus on Free Software.
All together more than 1000 people are expected to join during these days. The program will include keynote sessions, panel discussions and valuable exhibiting.
PHP Vikinger is an unconference directed towards everyone who wants to learn more about PHP and likes to discuss and meet with new people. Unlike normal conferences, the talks at conferences are determined by the attendees, and not a program committee.
This year will be my first time to join eZ Community during this series of events.
Just as I'm struggling with cache optimization for one of the current projects, I discovered that it would be great if cache-block functionality had one more parameter - a user-defined and user-readable identifier. Being able to clear all the cache by calling this identifier would be a great enhancement. It would be enough if it was implemented at eZ API level, so that users were able to create their own actions (views) to handle it. This would be especially benefitial for caching of custom modules and views, outside content and content tree itself.
Life example: Imagine expensive custom views that require couple of hundreds of SQL queries per view or view/param combination, and can be accessed/managed by a) the owner (of something), b) all other users. Now, leaving these views uncached would be suicidal, and cache-blocks would be quite handy, and there would be only two cache blocks per view (since you either are the owner or not). Now, the additional expectation is that the owner will always have his view up-to-date, which means we can't really cache it for him. Wouldn't it be great to be able to create a button named "Refresh my view", which would cause one particular cache-block (or cache block group) be cleared? In that way, we could cache the owner's view as well, making it possible to let a manual clear only when needed ;)