contentLib.create and mixins

Enonic version: 6.4.2
OS: Mac and Linux

I have a content-type that uses several mixins, on several levels.

When I try to use contentLib.create with the same data as Content Viewer shows me for a manually added content,
properties from mixins fail with the following message:

No mapping defined for property somePropertyName with value someValue (com.enonic.xp.resource.ResourceProblemException)

Does not matter whether someValue is a string or a number.

You are able to create content of this type in the Content Studio, but not with contentLib.create? There are two ways to add mixins. If the mixin is “inline” then the fields will be created/accesses the same as if those inputs were physically next to the other inputs. But if the mixin is x-data then the contentLib.create() will need the mixin fields to be added as x-data.

In the example below, any one of the “data” fields could be an inline mixin. But x-data mixins must go in the “x” area.

var result1 = contentLib.create({
    name: 'mycontent',
    parentPath: '/a/b',
    displayName: 'My Content',
    draft: true,
    contentType: 'test:myContentType',
    language: 'es',
    data: { //Any of the data values could be inline mixin
        a: 1,
        b: 2,
        c: ['1', '2'],
        d: {
            e: {
                f: 3.6,
                g: true
    x: { // Everything from x is an x-data mixin
        "com-enonic-myapplication": {
            myschema: {
                a: 1
    "attachments": {}

If inline/x-data isn’t the problem, then could you post the content type?

All the mixins are inline. I can’t post the content type here… Two Enonic employees have access to the repo though. @bwe and @oda

If I replace the with the inputs from the mixin it works. So it definetly has something todo with using mixins. Even though its an inline mixin, I will try putting it in x now.

We’ll investigate. Something odd going on there with the mixins.

One of the mixins had the same name as the content-type.
I suspect that should not be allowed since the key syntax is the same

Renaming the mixin did not help though.

Make sure to do gradle clean install after changing names of files.

That is not the problem.

As said:

If I replace the <inline mixin="mixinname"> with the inputs from the mixin it works. So it definetly has something todo with using mixins.


There seems to be an issue here with using either same mixin multiple times, or using mixin inside a item-set, or something like this. We are investigating.

This issue is solved in 6.5.2 that we releases just now.

Full release info will be available tomorrow.