This blog post is about how eZ Publish serves content images -- also called image aliases -- in a DFS cluster setup. The eZ DFS setup is the recommended and most common solution for high traffic eZ Publish sites that are run off multiple servers. However, it still has some room for improvement when it comes to serving images. In this post, we describe how eZ Publish currently serves image aliases, along with its downsides and some alternative approaches. At the end, we describe a possible implementation with some example performance gains.
We've worked with clients who use multi-server, fully redundant, clustered environments, and we've worked with clients in unique shared environments. If you are trying to determine the suitability of a LAMP web hosting environment for eZ Publish, there are a few simple requirements, which are well documented. In a dedicated or virtual hosting environment with full shell access, setup can be a breeze. However, sometimes the client has a specific shared web server that they must use, whether due to contractual limitations or various other internal constraints. Here is a list of extra eZ Publish requirements and complications that we've seen in shared hosting environments -- something you can check before proceeding!
In eZ Publish 4.3 and higher, the default Administration Interface landing page after a user has logged in is the dashboard. On this dashboard is a listing of widgets, such as a list of the latest edited content. It is very simple to add a new widget to this dashboard, and we've built an example widget -- showing the server's disk space information -- to illustrate this.
Among the many advantages of hosting multiple sites on the same eZ Publish installation is the ability to create internal links. eznode:// and ezobject:// links preserve the accuracy of the generated URL links even when content is moved around or renamed within any of the sites. (Of course, you can also use such links even when you host only one site.) However, out of the box, eZ Publish is not siteaccess-aware when generating cross-siteaccess links. For example, if your site sitea.com is contained within the subtree /sitea and your site siteb.com is contained within the subtree /siteb, internal links from sitea.com to siteb.com would end up linking to "sitea.com/siteb/article" instead of "siteb.com/article". While the user can be redirected with rewrite rules, it still creates a confusing user experience. Here's a simple solution jointly developed with another eZ Partner Granite Horizon that results in generated links that are siteaccess-aware.
For us, the introduction of the HST in BC means more complex cross-province tax rules. For our software service judgmentcalculator.com we previously charged all Canadians 5% GST. Now we must charge our customers a different tax rate depending on the province that they live in. Thankfully, with eZ Publish as our webshop platform, we were able to quickly implement a custom VAT (value added taxes) handler.
eZ Publish is well-known as a Content Management System with built-in multi-language features. To present different translations of pages, eZ Publish uses 3 major components: content translation, content class translation, and template / script translation. In this post, we will explain these 3 components and introduce a script to help translate strings in templates.
It is a reasonably common use case to fetch a list of content objects based on a common attribute implemented across multiple content classes. For example, to fetch all articles, blog posts and comments published by a given author. Certainly one could do multiple fetches and then massage the result sets together, but that's a lot of work. In this post I'll create a custom template operator (which is not the same as a custom fetch function, although the latter might be a better extension if one were a fan of doing things 'semantically') The operator will do the fetch with one SQL query. And I hope to shine some light on the eZ Publish db schema around objects, along the way.