A lot of developers starting out with eZ Publish have a hard time and this is generally attributed to a steep learning curve. Whilst this is true, a lot of the initial issues are terminology related, unless you know what it is called, you can’t search for it – and in technical documentation like that of eZ Publish, if you can’t name it then you won’t find it.

One common issue is trying to work out the difference between a node and an object. Everyone knows that screen – in the details pane on the admin interface, where you see “Node ID” and “Object ID”. But what do they mean and why do they get used?

Objects

Every piece of content in eZ Publish is an object. Many of these are defined by your content classes, but suffice to say that objects actually contain content and by themselves are the single place in which 99% of your content actually resides.

Objects themselves have no hierarchy, you could imagine these are blobs of data just floating around in your database. In order to actually give our site structure, hierarchy, navigation we need to associate these objects (pieces of content) to a node.

Nodes

Nodes exist for one reason, to provide hierarchy to those objects that we just covered. In giving an object a node id, we in turn place it within the node hierarchy, it has a parent, could have children and from this we can base our navigation and other structures.

Objects have a one to many mapping with nodes, meaning that a single piece of content can be referenced by more than one node id. A single node cannot reference multiple pieces of content. The benefit this provides is locations or cross-pubishing in eZ Publish talk, allowing you to have the same piece of content multiple times within your structure, and editing any of those locations edits that single piece of content, the effect of course being that those edits are shown in all locations at once.

Summary

Object IDs are used when referencing a piece of content directly.

Node IDs are used when referencing a specific location in the node tree/hirerarchy of your website.

You will find these terms used througout the documentation and depending on the operations and functions you are calling will determine whether you need to provide a node id or object id for your operation.

At the recent eZ Publish conference in January it was announced that eZ Newsletter would be phased out in support for CJW Newsletter, a new system to be certified by eZ Systems and built by several eZ Partners.

This is certainly good news as support and maintenance for eZ Newsletter has been sorely lacking for a couple of years now.

Whilst not yet released, the presentation slides from CJW Newsletter are promising and I am looking forward to giving this extension a thorough workout in the coming weeks.

Also only this week, NV Newsletter has been released onto http://projects.ez.no/nvnewsletter which is also something worth giving a go if you are looking for new newsletter options.

Newsletters are something that I know have been on a lot of minds over the past 18 months and it is great to see some good work coming out of it.

Ok, this one seems to popup in the forums just all too often, and it’s not an easy one to address – because a lot depends on your server environment and setup.

Removing index.php is done through Apache mod_rewrite which in turn interprets your URLs and passes them through index.php silently while everything looks pretty in your browser address bar. In order to get this working on your site you need to do the following.

1. Locate .htaccess_root in your root eZ Publish directory, this helpful file has a default set of htaccess rules to set you on your way.

2. Rename .htaccess_root to .htaccess, or paste the contents of the file into your VirtualHost configuration.

At this point in time your new URLS should hopefully work, but in many cases won’t. eZ Publish is meant to detect your virtual hosting configuration but this doesn’t always work. Never fear, we can force that option through the eZ Publish configuration files.

3. Edit settings/override/site.ini.append.php and under the [SiteAccessSettings] block add the line

ForceVirtualHost=true

Now you should hopefully be seeing much nicer URLs.

What about my old URLs?

If you have been using your eZ Publish installation already then search engines may have already indexed your content with the index.php in the URL. In this case all those existing records will bounce as errors. This is never good for your search rankings, so with some extra mod_rewrite magic in your .htaccess you can fix that up at the same time.

RewriteRule ^/index\.php/(.*)$ /$1 [L,R=301]

This should hopefully get you up and running with nice URLs. This guide is specifically for those running Apache, which is recommended for eZ Publish installations. If you choose to run a different webserver then modify the mod_rewrite rules and configuration to specifically suit your own webserver options.

Daniel Dilger wrote a brilliant post on why Flash for the iPad and iPhone are simply not viable, ignoring hardware, battery and other constraints – it simply isn’t possible from a gesture perspective.

Hooray, finally someone is talking sense.

Read the post here

As the title indicates this post is specifically targeted at the ongoing discussions that swept twitter yesterday regarding whether or not designers should have a hand in coding their designs.

Initially this was started by Elliot Jay Stocks who tweeted:

Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No execuse.

Since I spend a lot of time working closely with designers I thought it would be interesting to weigh in on some of the points which have been floating around.

Should designers be able to code their own designs? Yes, no, maybe… I mean actually it has less to do with code and more to do with understanding the medium. In all the time I have worked with designers, the one thing I have found refreshing is to work with designers who actually understand the medium in which they are working. Unlike print, which is a very controlled medium, moving into the web is very much a different experience for designers. Without properly understanding the medium in which they work you are destined for hard to implement designs which do not make use of benefits of the web.

In order to make things pretty on the web designers need to first understand principally what is possible, how their design will work, that what they are designing can actually be implemented without too many browser limitations and that it will look as good on the web as it did in Illustrator when they were making it.

I am not advocating that designers should go out and learn HTML, CSS and Javascript and do it all themselves, unless of course you are a sole-trader, but in understand the medium you will in turn work quicker, smarter and produce designs that are easy to implement, manage and maintain over longer periods.

For those who have come from print backgrounds, this is what you already know, it’s what you have done in print for years. You first learnt the medium, its constraints and how to deal with them. Now you need to learn the new medium you find yourself working in.

Something that every technology person comes across is budget and time overruns. Something like 80+% of technical projects run over time.

Really? Are you surprised? I’m not. No matter how much pre-planning and thought you put into a project, no matter the resources, staffing and waterfall diagrams to back it up, technical projects are at best a guess.

There is no finite timeline on which you can measure how long it will take to implement payment gateway ‘x’. And of course during such an implementation you will uncover problems ‘y’ and ‘z’, which are not in your waterfall diagram.

As technologists we need to communicate to our clients better that timeframes are mere goals – not guarantees.

Auto updates in Wordpress are great. They make it so easy it’s actually enjoyable to update, well for some people it is. For those of us who want to override one specific thing in the Wordpress core with an enhancement, such as my archive listing, we have our changes overriden with each update. In my case my archives page is broken until I go and reapply my patches again.

Thank god eZ Publish made some great design decisions and made overriding internal functionality easy… now we just have to simplify the upgrade process a little and we can have the best of both worlds.

I’ve been thinking recently I should publish some dev tips on my blog, preferrably as a series of tips and hints about working with eZ Publish. I would like to commit to doing it daily, but I don’t think about my blog that often – so perhaps every couple of days.

We shall see what happens.

For those keeping up with eZ Publish and their new development schedules you will know of course that the next release, 4.3, is just around the corner. Among it are a number of updates and perhaps one of those most eagerly awaited would be an administration interface refresh, something which hasn’t happened since eZ Publish 3.

For those who work frequently with eZ Publish there is probably not much doubt in your mind that the admin interface requires a refresh, could do with a good dose of javascript/ajax and some speed enhancements. And to be honest, that is what you have to look forward to in 4.3.

Unfortunately however the new admin2 design doesn’t really come with many usability enhancements in mind. The javascript additions simplify some operations to remove page loads – but all in the all the admin interface does look very very similar to its predecessor.

I wonder then is it that the eZ Publish admin is at its best layout and optimised design considering the functions and features available, or could it be improved even further with some thoughts about design and usability? Perhaps improving the code base to make it easier to extend and override specific areas of the admin interface, perhaps making things like the top tabs ACL dependent so they don’t appear if you don’t have access to them..

There are mixed reactions to the 4.3alpha1 release on twitter, it should be interesting to see how things go prior to launch.

After years of searching the best Macbook Pro cooling solution I have come across is a glass topped desk sitting directly underneath a refrigerated cooling unit. That keeps the temp down – and keeps the room cool as well.

Possibly not the most appropriate solution for cooling your laptop, but I’ll take whatever works.