Gaetano Giunta

This is the first in a series of blog posts dedicated to installing eZ Publish on cheap hosting.

"Cheap hosting" in this context has no strict definition; it is a term used to denote the hosting solutions on shared servers which typically give to the user little control over the configuration of the LAMP stack: no cronjobs, no shell access, no access to php.ini, no choice of storage engine or charset for mysql databases etc...

There are many small quirks with such solutions which can make life of the eZ developer hard - often not documented well if at all in the descriptions of the offer itself. The upside is that they generally can be rented almost for free, making them attractive for the cash-strapped personal-blog type of users. And even if you find one which is really incompatible, it will not make a huge dent in your pocket.

Without further ado, this one concentrates on problems with the php.ini setting "magic_quotes_gpc".

The observable behaviour is: impossibility to add images to rich text fields, quotes in text fields which get replaced by backslash-quote.

Read on for the solution...

In the previous installment of this series, I have shown how easy it is to integrate data coming from external services in your eZ Publish website.

Now, it is time to delve in the possibility of using ajax to access the remote service, and have a look at the same-origin problem and the different tools at our disposal to solve it.

An interesting blog post from mugo web sparked my attention. It was about using the REST API exposed by the http://www.wunderground.com website to add weather info to your site.

I immediately set up to see how hard it would be to implement in eZ Publish the small weather widget they showcased. As expected, it was a matter of minutes :-)

So I got bored, and decided to write a blog post as well, showcasing how to integrate 3rd party webservices into your eZ sites.

Read on for a detailed tutorial...

In the previous installment in this series, we showed how to configure eZFind for high-availability.

Now we tackle the problem of load balancing...

A common question I encounter in my consulting work is: how can Solr be configured for achieving scalability and high-availability?

There seems to be a lot of confusion around this topic, and the solutions I find deployed vary a lot. Often they are far from optimal, and offer little in both availability and scalability.

I will present here a simple configuration that needs little else than stock Apache and Solr servers to achieve both high-availability scalability. Read on for the details...

Everyone loves cache blocks, right?

And I am sure everyone here can tell me the difference between usage of  and subtree_expiry and ignore_content_expiry (note for the casual reader: it is: "use the latter if you can, try to addalways use the former when you can not").

But what if I was to ask: "cache block expiration is triggered by content publishing. What happens with all other operations, such as assigning obj state or section?"

Bear with me to find out...

Why? Simple:

After a long wait, my pull request to enhance the stock looks of the debug output report has been merged: https://github.com/ezsystems/ezpublish/pull/240.

But there's more... read on for the details.

First post in a series of "crazy ideas to explore at nighttime", this is dedicated to a new friend of mine: jQuery.

I never used that framework very much (I remain a backend coder at heart), but having been recently involved in whipping up some interactive and cool-looking web pages, I was impressed by the ease with which it allows to select sets of html elements and retrieve / alter their values.

The next (il)logical step was asking myself: can we reproduce such conciseness and ease of use in the eZ template language, where fetch functions are a staple? After all the "content/list" fetch function is used to select a set of nodes from a tree, with some filters applied. And, hey, nodes have attributes too, just like html elements!

Read on for more senseless drivel, erm, detailed analysis...

The Debug Report is every eZ Publish developer's best friend. Alas, it is often underrated because its appearance is somewhat lacking, and the big amount of data it spews out is hard to decode for the uninitiated.

Interested in something easier on the eye, more accurate in its findings, and more detailed as well? please bear with me in a tale of improvement of very (very) old php code...

Every developer who has come in contact with eZ for even a short moment knows what you are talking about if you mention "settings hell": a vast number of configuration settings files that can be spread over many, many directories.

Who has not spent at least a couple of hours pulling hairs trying to understand why something was not working, only to find out that a contradicting setting was set in a file of higher priority?

Despair not, because we're here to help, with the definitive guide to settings priorities!