eZ Community » Forums » eZ Publish 5 Platform » Could not find 'Content' with...
expandshrink

Could not find 'Content' with identifier 'array ( 'id' => x, 'languages' => NULL, 'versionNo' => y,)'

Could not find 'Content' with identifier 'array ( 'id' => x, 'languages' => NULL, 'versionNo' => y,)'

Friday 12 July 2013 8:13:07 am - 12 replies

Hi,

I'd like to move our webpage form legacy to eZp 5.1. Homepage is already working with a twig based pagelayout and inclusion of legacy templates. But as soon as I try to open another page I do always get this error:

Could not find 'Content' with identifier 'array ( 'id' => 79, 'languages' => NULL, 'versionNo' => 12,)'

id and versionNo differ from page to page of course.

I had this problem once before when I was trying to load content by using

$contentService->loadContent( 666 )

This is not working until you specify the language like so

$contentService->loadContent( 666, array( 'ger-DE' ) );

I think it's the same problem with the first call. It do not like NULL as language parameter. But how can I provide the function with this parameter, when my content include just looks like this?

{% block content %}
   {% if module_result %}
      {{ module_result.content|raw }}
   {% endif %}
{% endblock %}

Greetings Dirk

Friday 12 July 2013 8:18:36 am

Sorry this is the log entry...

CRITICAL - Uncaught PHP Exception eZ\Publish\Core\Base\Exceptions\NotFoundException: "Could not find 'Content' with identifier 'array ( 'id' => 79, 'languages' => NULL, 'versionNo' => 12, )'" at /vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Repository/ContentService.php line 337

Friday 12 July 2013 9:25:11 am

Found the problem...

"xrowmetadata" extension is not compatible with ezPublish 5.

Need to delete all occurences in the database manually, to remove it completly from system sad.gif Emoticon

Friday 12 July 2013 11:50:53 am

Alternative to deleting it is to define it as a Null Field type.

Tuesday 18 March 2014 5:17:46 pm

Hi André,

is there any doc for upgrading datatypes?

Tuesday 18 March 2014 7:12:29 pm

Not directly upgrade, but we just launced a tutorial for making FieldTypes: http://share.ez.no/blogs/core-dev...sh-5-fieldtype-tutorial-is-available

Wednesday 19 March 2014 3:50:55 pm

Tx!

Friday 30 January 2015 12:06:05 am

Guys,

 

We just upgraded our system from 4.7 to 5.1 and are having a smimilar issue sad.gif Emoticon

Can you guys please help me on steps to resolve this issue. Its kind off urgent and we have a tight go-live date sad.gif Emoticon

[2015-01-29 15:40:36] request.CRITICAL: Uncaught PHP Exception eZ\Publish\Core\Base\Exceptions\NotFoundException: "Could not find 'Content' with identifier 'array (  'id' => 28025,  'languages' => NULL,  'versionNo' => 5,)'" at /var/www/prj/vendor/ezsystems/ezpublish-kernel/eZ/Publish/Core/Repository/ContentService.php line 337 [] []

Friday 30 January 2015 9:16:04 pm

Hi,

 

if you upgrade a bit further you should be able to get more information around the exception.

Otherwise you need to enable more debugging so you get info from nested exception as well, and double check that the content is actually in database. If it is, you might just have to configure some FieldType (datatype) as a NullType (means: making the system accept a field type which has not been migrated to new stack yet).

Friday 30 January 2015 11:43:11 pm

Hi Andre,

 

Thank you for your comments, yes i found that we have a custom datatype ObjectRelationBrowse and hoping that is creating the issue, i will try to nullyfy the filed, but my concern now is how can we migrate the data from that field to new data type defined in 5.1 sad.gif Emoticon

 

We have lot of data associated to that field, and since we cannot use it, we need to define new ones as per the 5.1, but how to migrate the same from old to new ?

Please point me to right source to data migration steps pls

Sunday 01 February 2015 7:11:31 am

Hello Dushyanth,

The legacy ObjectRelationBrowse datatype is very similar to the default ezobjectrelationlist datatype.

The ObjectRelationBrowse datatype's key difference is it's UI. It's ajax based and in it's prime much more user friendly to use than the default ezobjectrelationlist datatype which was not ajax based.

Although I don't know this for certain, at the time it was created people would very commonly extend (via renamed copies) default datatypes to provide unique, new features (often UI based), leaving the backend very similar to the default datatype.

Notice that if you do a detailed code review and comparison the actual storage format is nearly identical.

Re: https://code.google.com/p/objectrelationbrowse/source/browse/trunk/datatypes/ezobjectrelationbrowse/ezobjectrelationbrowsetype.php#920

Re: https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/classes/datatypes/ezobjectrelationlist/ezobjectrelationlisttype.php#L817

 

My key point in pointing this out is that you need not worry about the 'data storage' format (although this is xml based) because the data storage structure (today) is the same between legacy and new stack. So no data migration is required.

What I think you should do is create a brand new FieldType based on the RelationList FieldType provided by default.

This should be very very simple to do since most of the hard work has already been done for you! All you have to do is modify a copy of the RelationList FieldType implementation within a custom bundle! 

Re: https://github.com/ezsystems/ezpublish-kernel/tree/master/eZ/Publish/Core/FieldType/RelationList

https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Persistence/Legacy/Content/FieldValue/Converter/RelationList.php

 

If you need more help in creating a custom FieldType study this tutorial: http://share.ez.no/blogs/core-development-team/the-ez-publish-5-fieldtype-tutorial-is-available

Another time saver is that you only need to implement copy RelationList FieldType for your new stack use in the user siteaccess. The datatype still provides the custom UI frontend for use in the legacy admin siteaccess.

EDIT: You may need to implement more than basic FieldType support (based on the default RelationList) to support the REST api or other more involved apis. 

Let us know how this works out for you!

In fact if you create this custom FieldType bundle for the objectrelationbrowse datatype would you please consider sharing it with other users who also use this custom datatype via GitHub?

It could prove to be an invaluable resource for other new users with this same problem (and or other users looking for examples of this kind of solution.

I hope this helps!

Cheers,
Heath

Modified on Sunday 01 February 2015 7:23:28 am by // Heath

Sunday 01 February 2015 8:28:43 pm

Hi Heath,

 

Really appreciate your response in such detail manner. Will definetly work on it and share once done. Will comebac if i have any questions. Thanks once again for such a detailed post.

Monday 02 February 2015 4:52:11 am

Hello Dushyanth,

Your very welcome! I'm happy to help.

I look forward to getting to review your new FieldType bundle.

Best wishes

Cheers,
Heath

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from