eZ Publish 5 comes with built-in Varnish Cache support. Essentially this means that when content is published in the eZ Publish back-end, it notifies Varnish so that the Varnish cache is cleared. This feature is often called "purge-on-publish" and makes it so that you can cache your pages for a very long time, but that edits refresh the cache and thus appear immediately. To get this native support, you just have to use the "new stack" in eZ Publish. However, even if your legacy site is not ready to be fully upgraded to the new stack and you are running eZ Publish 5 in "legacy mode", you can take advantage of this native support.
Some time ago I wrote a blog post about integrating Salesforce and Marketo in a web marketing solution powered by a content management system (in this case, the eZ Publish CMS). Recently, Mugo had the opportunity to migrate one of our clients from Marketo to HubSpot. The decision to move to HubSpot was made for non-technical reasons; regardless, it is useful to review the technical differences and challenges when it comes to integrating the marketing systems with a content management system.
One of our customer websites sells research reports where all of the content is built and managed in the eZ Publish content management system. These reports are served via HTML through a gated website portal. They wanted to add a dynamic PDF report generation feature (based on content in the CMS); the PDF template was highly customized with nice layouts and styles, cover and back pages, custom page breaks, and much more. Over the years we've had good experiences with the ParadoxPDF extension. However due to its lack of HTML5 + CSS3 support and relatively high server load, we decided to look for an alternative solution. We found that wkhtmltopdf does a great job at producing highly styled PDFs, and we were able to integrate it nicely with eZ Publish.
Until some time ago, it was necessary to hack the eZ Publish legacy kernel in order to customize its generic error message, "Fatal error: The web server did not finish its request". This error occurs on all eZ Publish installations whenever there is an HTTP 500 status server error. It is a very common error; some examples of how it's triggered include: trying to access the value of a non-existent object attribute; the use of a non-existent PHP class or function; and too much memory usage.
Now, since this pull request from Mugo has been merged to the eZ Publish kernel, we have made it possible to customize the error page without hacking the kernel. In this post I will show you the new standard way to do this with a simple INI setting and your own PHP function.
We're a group of web experts who solve complex web problems.Learn more about us »
Many years of experience with complex websites allows us to offer total solutions.Learn more about what we can do »
We've solved problems across North America and around the world.Learn more about what we've done »
Follow us on Twitter for the latest Mugo happenings