eZ Community » Forums » Setup & design » [SOL] eZOE - Unable to embed images...

[SOL] eZOE - Unable to embed images after upgrade to 4.1.1

[SOL] eZOE - Unable to embed images after upgrade to 4.1.1

Wednesday 13 May 2009 11:45:01 pm - 19 replies

Hi Guys,

Yesterday I did the update from eZ 4.1.0 to 4.1.1.
Before I did the update, i was able to add embedded images over the ezOE Editor.

Now, if i try to select an image in from the media section, i only get a grey list with the image name and no option box. It looks like if you try to link an non-valid object.

I've the following override settings in <b>/setting/override/content.ini.append.php</b>:


Besides: "artikelfoto" is another image class in my system.

To be sure that there are no overloading problems, I've added these lines directly in <b>/settings/content.ini</b> in the "[RelationGroupSettings]" section:


All caches are cleared, i've enough permissions in CMS (admin) but I'm not able to add the images - they are not shown as related objects.

Does anyone know, if this is a bug in the new version? Or how I'm able to fix this problem?

Thanks in advance,

Modified on Friday 15 May 2009 3:39:10 pm by Michael Fürst

Thursday 14 May 2009 8:10:37 am

if you click on the object button (paperclip) do you get access to select the images then?

Thursday 14 May 2009 11:03:21 am

Hi Andre,

Yes, inserting as object (paperclip icon) works...
If I try to insert it as Image, I get the grey-text list and no option-field to select the image.

Thursday 14 May 2009 4:25:30 pm

Hm, I've tried different ways now, but no chance to get it to run...
Is there a way to debug the eZOE response?!

Thursday 14 May 2009 5:48:26 pm

it's not the response that is making the selections grayed out (firebug is THE tool for debugging ajax responses btw).

In the source of the upload image dialog its the 'classFilter' javascript parameter.
It comes from $class_filter_array template variable set in ezoe/upload.php :

$contentTypeCase = ucfirst( $contentType );
if ( $contentIni->hasVariable( 'RelationGroupSettings', $contentTypeCase . 'ClassList' ) )
    $tpl->setVariable( 'class_filter_array', $contentIni->variable( 'RelationGroupSettings', $contentTypeCase . 'ClassList' ) );
    $tpl->setVariable( 'class_filter_array', array() );

$contentType is set by view parameter set from javascript:

$contentType   = 'objects';

if ( isset( $Params['ContentType'] ) && $Params['ContentType'] !== '' )
    $contentType   = $Params['ContentType'];

So that parameter should be 'images', and it is set to that in design/standard/javascript/themes/ez/editor_template.js in:

        _mceImage : function(ui, val)
            var ed = this.editor, e = ed.selection.getNode(), eurl = 'images/', type = '/upload/', el;

            if ( ui.nodeName === 'IMG' )
                e = ui;

            if (e !== null && e.nodeName === 'IMG')
                type = '/relations/';
                eurl = 'auto/'; // need to set to auto in case this is attachment icon
                el = e;
                eurl += e.getAttribute('id') + '/' + e.getAttribute('inline') + '/' + e.getAttribute('alt');
            this._generalXmlTagPopup( type, eurl, 500, 480, el )

Start by checking source of image dialog to see what classFilter is set to (look for classFilter.push lines).
If it is empty, then move on to check waht values you have in modules/ezoe/upload.php showed in the two first code blocks above.

Hope that helps.

Thursday 14 May 2009 6:43:51 pm

Hi Andre,

Thanks... I'm going to start debuging later at night...
Another question:
Is it called

ImagesClassList[] or
ImageClassList[] (without "s"blunk.gif Emoticon

I've seen both values already...


Modified on Thursday 14 May 2009 6:44:15 pm by Michael Fürst

Thursday 14 May 2009 6:52:52 pm

With s, see settings/content.ini:

# A list of defined relation groups, each entry
# will have a class definition setting suffixed with ClassList
# e.g. a group called images would have the setting ImagesClassList

# The group were all non-match classes are placed
# this is usually related folders and articles

# A list of class identifiers that should be placed in the
# related image group

# A list of class identifiers that should be placed in the
# related files group

In admin, go to setup -> ini -> content.ini + your siteaccess, and check that the settings are ok and not overwritten somewhere.

Thursday 14 May 2009 8:23:21 pm


Hm.. everything looks pretty good if I inspect the ini settings in backend -> setup:

<b>For my Backend (site "cms"blunk.gif Emoticon:</b>

default [0]
default [1] artikelfoto
default [2] image
override [3] artikelfoto
override [4] image

<b>For my Frontend (site "site"blunk.gif Emoticon:</b>

default [0]
default [1] artikelfoto
default [2] image
override [3] artikelfoto
override [4] image

I'm sure, it's only a small mistake... but i can't find it.
I'm going to start debuging of OE now, maybe then we know more...


Thursday 14 May 2009 8:26:17 pm

besides - maybe that's interesting:
I'm also unable to embed objects of class "image" in OE (the standard class)... So it can't depend on the new "artikelfoto" class...

Thursday 14 May 2009 8:41:47 pm

Ok, what I found out till now:
The object response on the GET request looks good (class_type of the images is "artikelfoto" as it should be).

And (whats also really interesting):
If I'm going to add an Image via direct upload in the editor, it works, but the image is not show in the article in the related objects list. There is the entry, but i can't see the image (that worked in 4.1.0).

If I'm trying to select the image over the "select" tab and browse to the media - images tree, it's the same as ever and i can't select the images. But we have to do it that way, cause our editors have to add the images as objects of class "artikelfoto" first to the media library and then add it to the article. The reason is, that we have much more attributes for our photos like "copyright" or "tags"...

Is it possible, that there is a policy problem depending on related objects?

Thursday 14 May 2009 9:01:52 pm

I think we can be sure, that it's not a configuration problem of the ini files.
I've added a debug notice in upload.php as you told me:

print_r($contentIni->variable( 'RelationGroupSettings', $contentTypeCase . 'ClassList' ));

And the output is correct:
<b>Array ( [0] => artikelfoto [1] => image )</b>
So the classes are set correct. I've no more ideas now... sad.gif Emoticon

Thursday 14 May 2009 9:34:21 pm

I found the reason, why the items are always greylisted. I debuged the file <b>/design/standard/templates/ezoe/upload_images.tpl</b>.

There I found the if statement which decides if an item can be selected or not in the "browse" view. And the variable "hasImage" is ALWAYS unset / undefined, also if the object is from class "image" or "artikelfoto". So always "node_not_image" is returned by this JS function.

Here is the part of the function with my debug output:

if ( contentType === 'images' )
{	alert('Content Type is images');
    eZOEPopupUtils.settings.browseClassGenerator = function( n, hasImage ){
    	alert('Start Function');
    	alert('n: ' + n);
    	alert('hasImage: ' + hasImage);  // <------ ALWAYS "undefined"
        if ( hasImage && classFilter.indexOf( n.class_identifier ) !== -1 ) {
            return '';
        if ( n.children_count ) {
            alert('2');  // <------ ALWAY EXITS HERE
            return 'node_not_image';
        return 'node_not_image node_fadeout';

Do you know, where and how "hasImage" is set? Maybe the system doesn't recognize, that "image" and "artikelfoto" are of type "image"??

Friday 15 May 2009 10:09:51 am

hasImage is set to true if node is considered to be image in design/standard/javascrpt/ezoe/popup_utils.js

                   if ( n.image_attributes && n.data_map[ n.image_attributes[0] ] && n.data_map[ n.image_attributes[0] ].content['small'] )
                       tag = document.createElement("span");
                       tag.className = 'image_preview';
                       tag.innerHTML += ' <a href="#">' + ed.getLang('preview.preview_desc')  + '<img src="' + ed.settings.ez_root_url + n.data_map[ n.image_attributes[0] ].content['small'].url + '" /></a>';
                       td.appendChild( tag );
                       hasImage = true;

So look in the json response for the image_attributes array, this is generated in classes/ezoeajaxcontent.php, and the lines there to debug is 241 - 246 and 266, for instance is site.ini [ImageDataTypeSettings] AvailableImageDataTypes properly setup? (used for $params['imageDataTypes'] in ezoeajaxcontent.php)

Friday 15 May 2009 2:37:56 pm

Hi Andre,

First: Thanks for you support happy.gif Emoticon
Ok, I've checked the site.ini (override), and everything seems ok:


Then I've analysed the <b>json response</b> from the server during browsing the categories in the embedded window. If i click on a category I get the following Item-List. I copied three different object types, so maybe you'll see an error:


"name":"Ford Fiesta",

"name":"Novak Djokovic (SRB) Rom Finale ",

As you can see, the image_attributes are set.
Do you see any other strange thing in here?

Beside: How do you debug the ajax response? Is there an option to enable a debug window (as in xajax for example)?


Modified on Friday 15 May 2009 2:41:51 pm by Michael Fürst

Friday 15 May 2009 2:46:39 pm

the 'small' size is missing, you don't have this size do you?


                  if ( n.image_attributes && n.data_map[ n.image_attributes[0] ] && n.data_map[ n.image_attributes[0] ].content['small'] )

A bit hardcoded, so probably the cause of the issue.

Modified on Friday 15 May 2009 2:47:31 pm by André R

Friday 15 May 2009 3:00:20 pm

I see, but where can i declare it? I don't really understand the dependencies at the moment... sorry!

Friday 15 May 2009 3:38:26 pm


Ok, after three days I've found the solution:
In <b>/settings/siteaccess/site/image.ini.append.php</b> the AliasList is new declared, and thats the reason, why the alias "small" (wich is hardcoded in ezOE) cannot be found and the images are not listet.

Here we go (image.ini.append.php):

AliasList[] <------ RESET ALIAS LIST

Solution: Just remove the AliasList[] declaration:

#AliasList[] <------ COMMENT OUT

<b>What I'm wondering:</b>
In ez 4.1.0 / ezOE 5.0.0 I had the same declaration as here in ez 4.1.1 / ezOE 5.0.1, and there I had no problems....

Andre, thanks a lot for your support!!


Friday 15 May 2009 4:18:40 pm

No problem. I'll try to move the small out into a setting and document this in the FAQ.
But I'm not sure why it worked for you in 5.0.0, it has been like this in ezoe since the start.

Friday 15 May 2009 8:16:30 pm

Yeah, or just a some debug output if the "small" alias is missing...
In 5.0.0 the small alias is also missing, but there it works... no idea why.

Thursday 27 October 2011 12:26:20 pm

Thanks Michael for solving this issue - it still exists in eZOE 5.3.


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

36 542 Users on board!

Forums menu

Proudly Developed with from