This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Forums » Setup & design » Using different sizes for the same...

Using different sizes for the same imagealias on different siteaccesses

Using different sizes for the same imagealias on different siteaccesses

Tuesday 22 November 2011 10:05:45 pm - 8 replies

I'm just learning the proper way to set up an eZ Publish installation, with as much placed into a custom extension as possible, and so on.

One question that the forums have not provided an answer for yet:

Can you re-use the same image alias name (say, "small" "medium" or "large" ) across different siteaccesses, and define the sizes and filters differently in each siteaccess?

More specifically, on a mobile version of our website, I want "large" images to be sized a bit smaller than on a desktop version of the site; but I don't want to have to tell my templates to use different image aliases.  I want "large" to be, say, a maximum of 400 pixels wide on the desktop site but a maximum of 250 pixels wide on the mobile site.

Put differently, I want the same image alias name to refer to different image sizes on different siteaccesses.

From my experimentation, you can configure it this way, by having different specifications for the same image alias names in each of the siteaccess versions of image.ini.append.php.  But what ends up happening is that the image gets converted back and forth by the different sites as you access them from the different siteaccesses.  In other words, when I visit the site on the desktop siteaccess, the image gets rendered/converted at 400 pixels, and served from a URL that looks like var/ezwebin_site/storage/images/media/images/elephant/12345-1-eng-US/elephant_large.jpg.  Later, when I visit the mobile siteaccess, I get served a 250 pixel image from the same URL.  (I think I cleared caches in between.)  When you factor caching in, the mobile site might see the desktop site's version, and vice versa.

I imagine eZ Publish does not distinguish between siteaccesses when storing generated versions of images or image aliases.  Is there any way to make it do that?  Or am I just going to have to settle for specifying alternative versions of my image aliases (e.g. "large" and "large_mobile" ) in a global override image.ini, and have my templates call the right one depending on the siteaccess?

Even further, am I violating the whole concept of an "image alias" with this question?  Is an image alias meant to be a single, globally available alternative version or "alias" of an image?  Or can it mean different things to different siteaccesses / channels?

UPDATE: There's another reason for this beyond just the trouble of specifying different image aliases in the templates.  It's the embedded images in content.  If an editor provides an embedded image in an XML block in a content item, and specifies to display it using the "large" image alias through the image dialog in eZOE, it will be too large for the mobile site.  There is no way for them to specify "use the 'large' alias for the regular site and the 'medium' alias for the mobile site."

Modified on Tuesday 22 November 2011 10:18:43 pm by A Fowler

Wednesday 23 November 2011 8:40:30 am

Hello AFowler,

You could use a fairly simple output filter for your mobile siteaccess to ensure only specific aliases are used in place of the defaults used outside of mobile context.

In eZ I'm always finding it's not a question of 'if' it's possible but 'how best' to provide for a feature request.


This is just one example. I'm not claiming it's the best (but anything is possible).


Theme song says .. they don't listen ..
Theme: Kreayshawn - Kittys X Choppas - Killin H**s ...

Modified on Wednesday 23 November 2011 8:41:16 am by // kracker

Wednesday 23 November 2011 9:41:03 am

Hello A Fowler,

While an output filter might help transform page contents like urls to images it would not create these aliases which you mean you would prolly have to do this in an automated way before you try to use / output the expected smaller replacement alias image variation url.

This is because in most cases image aliases are created on demand when called for use within the site templates per page request and not upon object creation, image upload or or any other way. If you don't create the variation files before you try to use them or output them to a user your user will get 404s within your mobile site page content.

Update: I've misspoke a bit in the above text. Depending on how you fetch /  use the aliases it is possible to run into a situation where the alias image variation files are not created before they are needed outside the context the main site.

But as I thought about your posts this afternoon I realized that if your using the alias variation file urls within templates in a separate siteaccess by default you may not have a problem, it's when you do a replacement of page urls which contain any one of an array of aliases with their replacements).

If you do not create the aliases variation files before you return the modified output buffer then the user receiving the modified buffer output could very possibly hit 404s when the page attempts to load files which do not yet exist, within the returned content as the images could exist but very well might not yet have been requested and created before that specific point in time.

I've spoken intently with a few eZ Publish developers working towards solutions along these lines recently and so I'm eager to share the problems they had encountered in similar situations.




Modified on Wednesday 23 November 2011 11:23:11 pm by // Heath

Thursday 24 November 2011 12:23:14 am

Thanks for your feedback, kracker and Heath!

How does the image alias variant get created on demand?  Is it when the template embeds the image, or is it when the image URL is requested by the client's browser?  I would expect the former-- given that if not using a cluster mode, the image files are served directly by Apache with no intervening PHP code.  Correct?

If anyone else has insights that would help me solve the problem, I'd be greatly interested and appreciative!

One idea I've had is to hack/override the image handling code to use the siteaccess as a key in addition to the image alias name.  However, that would generate a lot of duplicate images in cases where the image alias definitions were the same across siteaccesses.

A variation on that would be to add a key that is a hash built from the definition of the image alias (all of its key/value pairs) in the current siteaccess' image.ini.append.php.  If the definitions happened to coincide, they would generate the same hash and thus avoid the duplication.

A further variation would be to give the image aliases themselves another alias or mapping.  The image alias definitions would be shared across siteaccesses, but the extra alias mapping could be specific to each siteaccess. The image handling code would use the alias name given in the templates to look up the actual alias to be used in the current siteaccess.

Any feedback on these ideas?  Is there a better way that doesn't involve overriding kernel or lib code?

Thursday 24 November 2011 5:41:02 pm

I would go for using custom variations names, based on siteaccess:


you could make a custom template operator to make this a bit more nice on the eye - but you will still have to patch all existing templates that display content images in your site

Tuesday 29 November 2011 7:27:42 pm

I would go for using custom variations names, based on siteaccess:


you could make a custom template operator to make this a bit more nice on the eye - but you will still have to patch all existing templates that display content images in your site

I appreciate your response, and I could do this, but this doesn't really help with images embedded in XML blocks.  Their image alias is specified by the user.

If I used different VarDir settings for the different siteaccesses, could I set the image alias definitions separately for each siteaccess?

Tuesday 29 November 2011 10:27:20 pm

Hello A Fowler,

- No - 

Changing the VarDir setting will not help you reach your goal (at all, not even a little).

Image aliases are bound (by name and image size properties) to the image.ini AliasSettings

You can change the VarDir but it would not give you what you are really searching for here ...

First if you change the var dir, you loose access to all existing var dir content entirely. This is bad.

Alias Variations are generated upon request and when generated this info is stored back into the attribute content.

Assuming you got around the first problem (above), If you changed the VarDir the aliases would be re-generated the same as before. Now if you change the image alias settings for the aliases in question you could generate different image aliases with different sizes etc while retaining the same alias name. Note the urls for these aliases in theory would stay the same as other siteaccess (besides the different uri part for VarDir).

Another problem with this is that the normal (aka larger) image alias are already generated (in most use cases) by the time another user hits the mobile siteaccess. So when you do the above and hit the mobile siteaccess the page would return with missing images (404s) because to the system the aliases (bound by alias name mind you, which is why you 'have to' change the alias name used in this kind of use case key*).

It would not create the desired small aliases -ever- cause to the system they already exist (generated and stored by the main siteaccess). Sure you could clear the alias cache (which causes alias variations to be regenerated on pageload) but this only side steps the problem as then depending on which site and which content is loaded on either site you would essentially end up with inaccurate image alias attribute content depending on the siteaccess which loaded pages with the attribute aliases first ....

Remember also VarDir can only be one path. So you can't alter the system (by default) to store originals in more than one VarDir


Again the only way (short of some other api existing which I'm unaware of here ..) that I know to solve this use case is to use an output filter to detect the use of an image alias varation file, create the replacement smaller image alias variation image file (dynamically, using a different alias name) and replace the url part which contains the alias to use the smaller alias, return output filter content to user .... 




Theme Song: MC Lars - Indie Rocket Science - By the Time I Get Shot Up in Arizona (featuring Sole) ...

Monday 05 December 2011 1:04:08 pm

Hello A Fowler,


After some recent development I report the following with regards to clearing image alias cache, purging image alias files and creating image alias files.


  1. When using eZ Publish 4.6.x+ (As of Community Build, 2011.10), you can run the following command (but not before this version) to remove all image aliases image variation image files
    • php ./bin/php/ezcache.php --clear-id=imagealias --purge
    • php ./bin/php/ezcache.php --clear-id=content
  2. When using eZ Publish 4.x+, you can run the following command to remove all image alias cache (does not remove actual image variation image filesfiles, just causes them to be regenerated upon next usage)
    • php ./bin/php/ezcache.php --clear-id=imagealias
    • php ./bin/php/ezcache.php --clear-id=content
  3. With the latest version of the bcimagealias extension (using eZ Publish 4.x+) you can also remove all image alias image variation image files for all image aliases of the current siteaccess or all of the current siteaccess related siteaccesses.
    1. Learn more at
    2. You can also generate all image alias image variation image files for all image aliases of the current siteaccess or all of the current siteaccess related siteaccesses.
    3. It also includes a workflow event to generate all image alias image variation image files for all image aliases of the current siteaccess or all of the current siteaccess related siteaccesses on content publish trigger.


I hope this helps ...




Modified on Monday 05 December 2011 1:12:05 pm by // Heath

Sunday 11 December 2011 6:28:05 pm

Hello A Fowler,

 Today we have pushed a rather large set of improvements for bcimagealias extension to GitHub,


Also it's worth mentioning we added support to the bcimagealias script and class for the parameters '--classes', '--attributes' and '--aliases'. You can see examples of how to use these parameters reviewing the doc/USAGE file,

We also added admin siteaccess content structure and popup class menu links. These links allow for you to use the same features as the command line script to create, regenerate and remove image alias image variation image files using two new module views 'create' and 'remove'. This was the initial focus for this iteration of development.

This makes it possible for any user with the required role policies to create, regenerate and remove image alias image variation image files using the existing content structure and popup class menus with the bcimagealias extension using the admin siteaccess without any complications.


You can review the changelog (as we have made many improvements to 0.0.23 version)


We hope this helps ...





You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from