All about the development of eZ Publish by Graham Brookins, 7x (formerly Brookins Consulting) and our think tank kracker.org.
A word today about the server requirements for an eZ Publish website. They may seem daunting but from years of experience let me assure you they are not in any way.
The most resource intensive part about installing eZ Publish is often the initial installation setup wizard usage to build your installation for the first time. This is where most shared hosting users with limited experience make their biggest mistake, building a eZ Publish website initially on shared hosting, it's often possible but not as pleasant as a box you can control yourself as root. It's better to upload a (mostly) complete built setup ready to run on production.
After which the cost of eZ Publish goes down dramatically and then depends upon the custom features you require for your website.
You'll find, with some work, if the hosting is designed for WordPress, you can alternatively host a complete ready to host eZ Publish on almost any kind of hosting with just enough memory being the key to a fully featured website. I remember hosting eZ Publish v2.x on 486 CPU with less than 256 MB of memory for both OS, Apache Web server and eZ Publish PHP.
With that in mind it is trivial to distribute a completely setup eZ Publish installation to the server hosting your website by transferring the files of eZ Publish and loading your database dump consisting of your setup eZ Publish website structure and content to the website server.
Warning: Skipping the setup wizard can lead to advanced troubleshooting of your web server / PHP environment to ensure the server itself is configured to support the base eZ Publish requirements. Also these lesser hosting packages are often best for hosting production installations of eZ Publish much more than they are suited for active eZ Publish extension or kernel development which is a common pitfall.
A word on cheaper hosting packages: They may be cost effective for production hosting but can be difficult and unstable for development use. This is where the wisdom and foresight of an effective website administrator comes in to leverage each hosting platform for it's advantages and avoid the more painful disadvantages.
Recently in preparation for the publishing of this blog I used an newer feature of the extension BC Generate Static Cache to by way of ini settings override exclude by parent node id the blog and this ensured static cache was not generated for this blog and it’s blog posts.
What is static cache? Well static cache is a thin layer of html pages served by web server rewrite rules bypassing php entirely thus speeding up the serving of web pages. With the BC Generate Static Cache extension command line script I can generate the whole static cache in just seconds.
Without static cache we are afforded faster updates to the blog itself and anonymous comments.
This feature worked great and my blog content is served now by php cache which is more than fast enough for this small blog's content.
If you have thought of speeding up your own website try static cache. Static cache works well with stable websites of all sizes and shapes.
Since static cache is simple to bypass for those who know using view parameters I try to enable it on all my eZ Publish websites in production.
What do you think? Static cache vs reverse proxy which is faster?
Add comment