If you are reliant on node IDs in your code it can lead to issues when moving your code between your dev, stage and live environments. Since your live site will have content added much more often, node IDs will tend to be much higher on that compared to your dev and stage environments. It is possible to use other alternatives in your override.ini file and in your templates to prevent this from happening.
Alternatives to node IDs in override.ini
If you need extra details apart from the content type, I would recommend using url_alias. There are a couple of ways this can be used:
Match path directly
To base it on the path, copy the path after the site access and add this as the url alias. Subfolders are added in exactly the same way (no trailing slashes are required). For example, http://www.mysite.com/sport/news would have the url alias sport/news.
Source=node/view/full.tpl
MatchFile=full/folder_news.tpl
Subdir=templates
Match[class_identifier]=folder
Match[url_alias]=news
There are a couple of things to note with this example:
- All folders below the news folder will also use this override, for example news/fashion would also be overridden (you can limit the level using the depth match
- Folders called news but in a different folder within home will not, for example sport/news would not work with this override.
Match children based on path
Since the override also works on the children, we can use this to uniquely identify children beneath a specific node, even if we are looking at a different type to the parent. Continuing the example above, we may want to use a different template for news articles within our fashion folder. This can be done with the following override:
Source=node/view/full.tpl
MatchFile=full/article_fashion.tpl
Subdir=templates
Match[class_identifier]=article
Match[url_alias]=news/fashion
The complete list of aliases can be found on the eZ Publish website. Another match which can be useful is the parent_class_identifier, for specifying children under a specific type.
Alternatives in template files
More often than not, rather than using the node id statically, you can access the node id of the object directly using the node, there are also a number of other items which are of use to do this. Here are some solutions you can use to pull out the node ids for use in fetches, as well as the parent and child nodes (these have performance benefits over carrying out additional fetches):
Node url: {$node.url_alias}
Parent Node ID: {$node.parent_node_id}
Parent Node: {$node.parent}
Child Nodes: {$node.children} (this is an array sorted as the children are in the eZ Publish admin, changing the order in the back will also be reflected in the front. This is also faster than running an additional fetch statement)
Child Nodes: {$node.children_count}
Related Object Array: {$node.object.related_contentobject_array}
Related Object Count: {$node.object.related_contentobject_count}
Node ID of the first related Object: {$node.object.related_contentobject_array[0].main_node_id}
Other Options
Another key point is to ensure that you regularly sync your stage and dev environments with your live database. By doing this, and by ensuring the var folder is copied from live to stage and dev when you do this, it should ensure your environments are as similar as they can be and there should be as few nasty surprises as is possible when moving code between environments.
If your site already has a system in place which uses different IDs across your different platforms, you can create a custom .ini file and then add references in this to your IDs on the specific server. This means you can use names rather than node IDs in your code, although it does mean more work when you update your database across servers as the custom .ini file will also need updating.
Hi,
You may also use this extension: http://projects.ez.no/noveniniupdate