I use paragraph items inside of other paragraph items. Since latest Version 7.x-1.0-rc3 I can't do this because every time when I try to add a new paragraphs item an error occurs (See screenshot).

CommentFileSizeAuthor
#106 paragraphs-host_entity_problems-2564327-106.patch1.68 KBloopduplicate
#106 interdiff-2564327-100-106.txt772 bytesloopduplicate
#100 paragraphs-host_entity_problems-2564327-100.patch1.68 KBjstoller
#91 paragraphs-host_entity_problems-2564327-91.patch1.68 KBidflood
#85 interdiff-2564327-73-85.txt1.73 KBrecrit
#85 paragraphs-host_entity_problems-2564327-85.patch1.74 KBrecrit
#73 paragraphs-host_entity_problems-2564327-73.patch648 bytesseanB
#54 interdiff-2564327-51-54.txt2.39 KBjeroen.b
#54 paragraphs-rewrite-host-entity-2564327-54.patch25.29 KBjeroen.b
#53 paragraphs-skip-access-check-2564327-53.patch774 bytesmanu manu
#51 paragraphs-rewrite-host-entity-2564327-51.patch24.31 KBjeroen.b
#51 interdiff-2564327-47-51.txt1.14 KBjeroen.b
#48 paragraphs-rewrite-host-entity-2564327-47.patch24.04 KBjeroen.b
#48 interdiff-2564327-46-47.txt259 bytesjeroen.b
#47 paragraphs-rewrite-host-entity-2564327-46.patch23.86 KBjeroen.b
#47 interdiff-2564327-33-46.txt5.18 KBjeroen.b
#40 paragraphs-revision-delete-fields.png149.54 KBjstoller
#40 paragraphs-revision-delete-node.png59.52 KBjstoller
#33 paragraphs-rewrite-host-entity-2564327-33.patch21.27 KBjeroen.b
#33 interdiff-2564327-32-33.txt2.41 KBjeroen.b
#32 paragraphs-rewrite-host-entity-2564327-32.patch20.04 KBjeroen.b
#32 interdiff-2564327-31-32.txt673 bytesjeroen.b
#31 interdiff-2564327-27-31.txt3.69 KBjeroen.b
#31 paragraphs-rewrite-host-entity-2564327-31.patch20.01 KBjeroen.b
#12 nested-paragraphs-deletion.png68.59 KBjstoller
#9 paragraphs-fix-nested-paragraphs-2564327-9.patch1.28 KBjeroen.b
#2 paragraphs-ensure_hostentity_method-0-0-7.39.patch464 byteslucastockmann
Monosnap 2015-09-07 11-46-53.png35.66 KBlucastockmann
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lucastockmann created an issue. See original summary.

lucastockmann’s picture

Status: Active » Needs review
FileSize
464 bytes
jeroen.b’s picture

Status: Needs review » Postponed (maintainer needs more info)

Can you please test the patch in #8 from https://www.drupal.org/node/2562875#comment-10301299
The hostEntity should always be available. Are you using any custom stuff or special modules?

jeroen.b’s picture

Update: can you please test latest dev?

thomas.claes’s picture

I still have this issue while using the dev version of 11 September for 7.x.

Fatal error: Call to a member function hostEntity() on a non-object in sites/all/modules/contrib/paragraphs/paragraphs.module on line 263

I do think the patch, supplied by lucastockmann, still is needed.

jeroen.b’s picture

Please try to find out why this is caused. The patch from @lucastockmann is a workaround, it disables access checking, so I'm not going to commit that.

jstoller’s picture

Title: No method "hostEntity" while paragraphs inside of paragraphs » Nested paragraphs are broken
Version: 7.x-1.0-rc3 » 7.x-1.x-dev
Priority: Normal » Major
Status: Postponed (maintainer needs more info) » Active

I'm having a similar problem and I can't help but think they're related, though my error is different. If you think I'm wrong, let me know and I'll move this to a separate issue.

I have a Body Content paragraphs field that includes several bundles. One of those bundles is a Highlight Box, which itself contains a paragraphs field linking to several of the same bundles. When I add a highlight box to the Body Content field it seems to work. However, when I go to add a bundle within the highlight box's paragraphs field it spins for a bit and then the whole paragraphs field disappears, leaving the highlight box bundle there, but with nothing inside it (including the select list to add more bundles). Looking in the log I see this error:

Notice: Undefined index: entity keys in paragraphs_paragraphs_item_access() (line 267 of /path/to/paragraphs/paragraphs.module).

Now's the really weird part. If I first add some other bundle type to the Body Content field and then add a highlight box, it lets me add a nested bundle within the highlight box. However, if I then try to remove the first bundle I added, without saving first, the highlight box collapses and displays the error "You are not allowed to edit this content item item."

Reverting to Paragraphs RC1 fixes all of this.

jeroen.b’s picture

Nested paragraphs are not broken, I'm sure of that. On a vanilla install nested paragraphs work fine.
There must be some other issue here. Can you try to find out why entity keys is empty in (line 267 of /path/to/paragraphs/paragraphs.module)?
Either your hostEntityType is empty, or Drupal couldn't fetch the entity info.

jeroen.b’s picture

Ah, I think I found the bug. When the host entity is not saved yet, nested paragraphs seem broken.
Please test attached patch.

jeroen.b’s picture

Status: Active » Needs review
jstoller’s picture

I'll test the patch later today. For what it's worth, I saw this error on two different sites. The first is a real website, which is quite a complicated beast, to be sure. However, the second was a vanilla demo website from my Paragraphs session at last last month's DrupalCamp LA (spreadin' the word). The only "fancy" thing it has is Display Suite.

Also, I don't know if it matters, but I was seeing these errors when editing an existing node. So the node entity existed, though I suppose the outer paragraph bundle entity did not.

jstoller’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
68.59 KB

I tested the patch and it does seem to solve the immediate problem. I'm now able to add nested bundles as expected and I don't see any errors showing up in my log.

I am still seeing some weirdness when removing unsaved paragraphs, as seen in this screenshot, though this may be a completely unrelated issue.

Nested pararagraphs deletion weirdness

This is what I did to get to what you see in the image:

  1. Add Body copy bundle to Body Content field
  2. Add Highlight box bundle to Body Content field
  3. Add Body copy bundle to Highlight Content field, within the Highlight box bundle
  4. Remove the first Body copy bundle

The first bundle is removed as intended, but it also restricts access to the bundle within the Highlight box for no apparent reason.

The one other comment I'll make, which is really a separate issue, is that there is now a significant lag when adding new items to a paragraphs field when compared to RC1. I assume this is because of the additional access checking. On my local test environment it takes 10-12 seconds every time I add or remove an item, compared to about 1.5 seconds with RC1. It's long enough to be frustrating.

jstoller’s picture

I posted the performance issue at #2569807: Performance degredation.

CB’s picture

I'm also getting this error when just trying to access a node edit form.

I'm not sure if this is exactly the same as the current issue but its the same error.

Fatal error: Call to a member function hostEntity() on a non-object in /sites/all/modules/contrib/paragraphs/paragraphs.module on line 243

The following;

function paragraphs_paragraphs_item_access($entity, $op, $account) {
  $permissions = &drupal_static(__FUNCTION__, array());
var_dump($entity);
var_dump($op);

returns

null
string 'create' (length=6)

Seems to be no check that the entity actually exists.

jstoller’s picture

@cbiggins: Did you try the patch from #9 above?

CB’s picture

I did, but it didn't help.

Line #263 remains unchanged;

if ($entity->hostEntity()) {

That is the problematic line for me.

Note that this is a full page error on node edit form. At this stage I am unable to see any forms at all to test the ajax part. To test that I need to manually (via db) remove the paragraph items from the node.

jstoller’s picture

If you haven't already, I would also apply the patch from #2569807: Performance degredation. It seems to be fixing a wide variety of problems. Not sure if it'll solve yours, but I know hostEntity() is specifically implicated in that issue.

jeroen.b’s picture

Status: Reviewed & tested by the community » Needs work

Yeah, I'm going to rewrite the whole hostEntity stuff, it's just so confusing right now and even I don't really know what it's doing exactly at this point.

jeroen.b’s picture

Title: Nested paragraphs are broken » Host entity problems (ajax errors / nested paragraphs / UI speed)
CB’s picture

Can I help at all? I really need to get this resolved and willing to do whatever it takes (heh, within reason.)

jeroen.b’s picture

If you're not using private files in paragraphs, it's safe to rollback to an older version.
If you still like to help, sure. I'm willing to accept that completely rewrites the hostEntity behaviour to something that makes sense, hehe.

CB’s picture

Hi @jeroen.b what version do you recommend?

jeroen.b’s picture

@cbiggins 7.x-1.0-rc1 is fine.

I think I will start on the rewrite tonight.

jstoller’s picture

@jeroen.b Great! I'm happy to help test whatever you've got.

On behalf of those of us using content moderation, please remember that you can never assume a paragraphs item is attached to the default revision of its host entity.

jeroen.b’s picture

Status: Needs work » Needs review

All right, here is the first attempt.
While the previous code relied on loading the host entity whenever we felt like it, the new code makes sure the host entiity is set in all cases, widget and formatter. Only when it's really needed, it will attempt to load the host entity once. Like when the file module is doing a file access check by loading referenced entities.

jeroen.b’s picture

Oh woops, here is the file.

jeroen.b’s picture

Small addition.

jeroen.b’s picture

FileSize
669 bytes

Proper interdiff.

jstoller’s picture

Status: Needs review » Needs work

I've started testing this and it mostly seems to work. Except that it explodes when I try to delete a revision. When I go to the moderate tab and delete an old revision I get a white screen displaying:

Error
The website encountered an unexpected error. Please try again later.

Looking in watchdog, I see the php error: EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7844 of /path/to/www/includes/common.inc). I can also see that the associated paragraphs field and paragraphs items revisions haven't been deleted from the database tables, though the node revision is deleted, as I would expect.

CB’s picture

Thank you @jeroen.b. rc1 worked fine.

jeroen.b’s picture

Thanks @jstoller, I found the problem, stupid mistake. Here is the updated patch.
Also added some extra caching so it only checks access on the parent entity once.
Added some extra checks in fetchHostDetails().
Fixed revision saving.

@cbiggins, would you mind testing the patch if you have some spare time?

jeroen.b’s picture

Small updated patch, to make sure we don't mess with $items in paragraphs_field_delete_revision.

jeroen.b’s picture

Found an issue where it's not creating a new paragraphs revision when you revert an node revision. Which causes breaking when you later on remove that specific revision. Not sure if related to this patch.

jstoller’s picture

I just tested #33 and it's still not working with revisions. I created a node with three revisions, then deleted the middle one. After that, I got a 404 error when trying to access the node, or any of it's associated tabs. Looking in the database I see that {node}.vid is set to the revision number that was deleted, as is {field_MY_PARAGRAPHS_FIELD}.revision_id. It also looks like the module deleted not just the paragraphs items associated with the deleted revision of the paragraphs field, but also all newer revisions.

jeroen.b’s picture

Did you try this on a existing node or a new one?
When trying this on a new node, this seems to work fine (with the fix from #33).

jstoller’s picture

It was a new node, but an existing site. Maybe there was still some cruft in the database from yesterday's testing? I'll sync with my production DB and try again.

jeroen.b’s picture

Weird, can you describe your exact steps?

jstoller’s picture

I'm working on it, but have to go into a meeting for a couple hours. I should be able to get you more details later this afternoon.

jeroen.b’s picture

Yay for time difference this time, I'll see it in the morning. 23:41 here now.

jstoller’s picture

OK. I took a copy of my latest production site and updated to 7.x-1.0-rc3+4-dev with the patch from #33 applied. Then I went through the steps outlined below. The way this site is built, the page content type has a body_content paragraphs field on it, with body_copy being one of the available bundles for that field. The body_copy bundles have a couple of fields on them, but the main one is a text area called field_body_copy.

  1. Create new node (nid=497; vid=6257) with one body_copy paragraphs item (entity_id =1861) in the body_content paragraphs field.
  2. Save a new revision of the node (vid=6258), adding another body_copy paragraphs item (entity_id =1862) to the body_content paragraphs field.
  3. Save a new revision of the node (vid=6259), removing the second body_copy paragraphs item (entity_id =1862), but adding a third one (entity_id =1863) to the body_content paragraphs field.
  4. Delete the second revision of the node (vid=6258).

The images below show what was in the relevant database tables before and after the deletion. I highlighted the stuff I expected to be deleted in yellow. You can see more field data was deleted than should have been. The revision references that changed, but were not supposed to, are highlighted in red.

node table data

field table data

tapscolaM’s picture

@jeroen.b I have just tested #33 on 7.x-1.x-dev as i couldn't apply the patch on 7.x-1.0-rc3 and i am getting the same fatal error that cbiggins is experiencing.

Fatal error: Call to a member function hostEntity() on a non-object in /sites/all/modules/contrib/paragraphs/paragraphs.module on line 255

This happens when i try to edit a node. Could it be that i am applying it on the wrong version?

jeroen.b’s picture

Hi @tapscolaM, patches generally apply to the git development branch and the latest dev version from the project page. Not on the latest release. That you're still seeing that error surprises me. Could you check what's the value of $entity on line 255 of sites/all/modules/contrib/paragraphs/paragraphs.module?

Can you also check your version of the entity module?

Thanks @jstoller for the details. I'll look into it tonight.
It's weird though, can't imagine that the paragraphs module would mess with the revisions from the node table.

CB’s picture

Hey @jeroen.b, just FYI, @tapscolaM and I are working together here.

jeroen.b’s picture

Hehe yeah, I figured when I looked at @tapscolaM's profile.

jeroen.b’s picture

Maybe it would help to insert this piece of code on line 254 of sites/all/modules/contrib/paragraphs/paragraphs.module:

if (!is_object($entity)) {
  dpm($entity);
  dpm(debug_backtrace());
}
jstoller’s picture

@jeroen.b, yesterday I was just testing new nodes, but today I went to edit an existing node and came across more problems. The "Add another content item" button appears at the bottom of the Paragraphs field, but the select list is missing. If I push the button, then it adds one of my highlight_box paragraphs bundles to the field. Not sure why it's adding that particular bundle, as it's in the middle of my list of available bundles for this field. That said, highlight_box happens to contain a nested paragraphs field, but that field just displays the message "You are not allowed to add any of the bundles." Interestingly though, if I edit an existing highlight_box bundle on the same node, the paragraphs select list is available as expected.

But wait! There's more! Several of my bundles contain a nested "Link" paragraphs field that can contain either an internal_reference, or external_reference paragraphs bundle instance. When I look at all those Link fields, the "Add External reference" button is there, but the "Add Internal reference" button is missing.

I suspect that all of this is due to an access bug of some sort.

jeroen.b’s picture

Ah, thanks! That was due to permission caching issues.
Because I wrote the default permission (deny) to cache before checking the entity host, the entity host thought it was already checked and denied.
Also rewrote the entity handling inside the form a bit.

jeroen.b’s picture

@jstoller, I think I figured out your bug from #40.

jstoller’s picture

Yay! I've been playing around with #48 and everything seems to work.

@cbiggins and @tapscolaM, does this one fix your error? Can we mark it RTBC?

tapscolaM’s picture

I have just applied and tested patch #48 and doesn't seem to have fixed the problem.

Fatal error: Call to a member function hostEntity() on a non-object in sites/all/modules/contrib/paragraphs/paragraphs.module on line 257

The value of the $entity is NULL and the backtrace dump is here
@jeroen.b FYI the version of Entity module we are using is Version: 7.x-1.6

jeroen.b’s picture

@tapscolaM, thanks! That seems to be an issue related to the brightcove_field module.
But I think I found the issue:
http://www.drupalcontrib.org/api/drupal/contributions!entity!entity.modu...
Optionally an entity to check access for. If no entity is given, it will be determined whether access is allowed for all entities of the given type.

I did not know the entity was optional. Here's a patch that checks.

tapscolaM’s picture

jeroen.b patch #51 has solved the issue, I have just been playing around with both existing and new nodes with the brightcove_field, all looks great, thanks indeed!

manu manu’s picture

Regarding #51:

But I think I found the issue:
http://www.drupalcontrib.org/api/drupal/contributions!entity!entity.modu...
Optionally an entity to check access for. If no entity is given, it will be determined whether access is allowed for all entities of the given type.

I did not know the entity was optional. Here's a patch that checks.

I was about to submit a patch about this issue, I think the patch in #51 doesn't not fully resolve the problem..

How to reproduce:

entity_access('view', 'paragraphs_item');

Will result (with devel/php) to:

Notice: Trying to get property of non-object in paragraphs_item_access() (line 179 of /vagrant/www/sites/all/modules/contrib/paragraphs/paragraphs.module). Backtrace:

paragraphs_item_access('view', NULL, NULL, 'paragraphs_item') entity.module:657
entity_access('view', 'paragraphs_item') devel.module(1362) : eval()'d code:1
eval() devel.module:1362
...

Real world use case: Rules executes some generic access checks (I don't know why) on overview page:

Notice: Trying to get property of non-object in paragraphs_item_access() (line 179 of /vagrant/www/sites/all/modules/contrib/paragraphs/paragraphs.module). Backtrace:

paragraphs_item_access('view', NULL, NULL, 'paragraphs_item') entity.module:657
entity_access('view', 'paragraphs_item') entity.rules.inc:115
entity_rules_integration_event_access('event', 'paragraphs_item_insert') 
call_user_func('entity_rules_integration_event_access', 'event', 'paragraphs_item_insert') ui.core.inc:1223
RulesUICategory::getOptions('event', NULL) ui.core.inc:848
RulesPluginUI::getOptions('event') rules_admin.inc:51
rules_admin_reaction_overview(Array, Array, 'admin/config/workflow/rules/reaction') 
call_user_func_array('rules_admin_reaction_overview', Array) form.inc:841
drupal_retrieve_form('rules_admin_reaction_overview', Array) form.inc:350
drupal_build_form('rules_admin_reaction_overview', Array) form.inc:130
drupal_get_form('rules_admin_reaction_overview', 'admin/config/workflow/rules/reaction') 
call_user_func_array('drupal_get_form', Array) menu.inc:519
menu_execute_active_handler() index.php:21

Given that it seems that no permissions are defined to filter direct access to paragraph items, how about to purely skip access checking in paragraphs_item_access()?

I'm not quite comfortable with the idea, but just for the example attaching the patch I was about to submit about the specific entity_access() issue.

jeroen.b’s picture

All right, here's an updated patch that returns PARAGRAPHS_ITEM_ACCESS_IGNORE when the entity is missing or the host entity is missing. Also added some code to create a proper cache id when no entity is given.

I could not really reproduce those notices but this patch should fix them.

@tapscolaM, @manu manu, @jstoller, mind testing one more time? I really appreciate you guys testing!

tapscolaM’s picture

@jeroen.b i have just tested patch #54 and it looks good to me, @manu manu i couldn't reproduce the notices too using #51.

manu manu’s picture

@jeroen.b Thanks, I will test #54 later today.
@apscolaM Weird, did you run entity_access('view', 'paragraphs_item'); in devel/php ?

manu manu’s picture

#54 works well for my use cases, but I didn't tested with nested paragraphs.

Thanks @jeroen.b!

jstoller’s picture

Status: Needs review » Reviewed & tested by the community

@jeroen.b I just ran through some tests with #54 and it seems to work for me as well, so marking RTBC.

  • jeroen.b committed 135809e on
    Issue #2564327 by jeroen.b, lucastockmann, manu manu, jstoller: Host...
jeroen.b’s picture

Status: Reviewed & tested by the community » Fixed

Thanks all! Committed to dev!

CB’s picture

Great work all, thanks!

michaellander’s picture

I'm having a problem with this when used on a flag entity.

I have a paragraph on a flag entity, and the flag entity relates to the corresponding node.

When someone flags the node(hence creating a flag entity with a paragraph field), the permissions are denied because even though the user has access to create a flag, they do not have access to create the parent node. If paragraphs are nested, shouldn't they only be concerned with access on their immediate parent and not all parents above?

jeroen.b’s picture

Did you try the patch?
What kind of access does flag use?

It makes more sense that it looks up the "tree" to see the actual access, because the paragraph item does not actually have any access control by itself.

michaellander’s picture

I did try the patch, which returns an array('deny', 'allow'), the deny being the parent node. I'll look into the flag access thing.

jeroen.b’s picture

And what was the $op being passed?

michaellander’s picture

I'm assuming 'create', because the user has permissions to 'create' a flag, but not the node.

I had to switch to field collection to get passed this hurdle, but I'll switch it back now to debug.

One thing I was curious, what if access only looked up the tree if the parent is a paragraph. So each paragraph is basically responsible for checking it's own parent, but then we don't have to assume entity access relations for other modules? I might not be fully understanding how it's all connected, so let me get this setup and I'll look into it.

jeroen.b’s picture

That's weird. The flag module should not check for 'create' access on the entity that you want to flag. I'd rather assume 'view'.

If we would only check the parent access if the parent is a paragraph, you would end up with no access checking at all, because as soon as the parent is a real entity (like a node), it won't check it's parent entity. Paragraphs items have no direct access control (unless you use something like Paragraph Bundle Access).

The way it now works:
In the paragraphs item access, lookup the parent entity to see if you have 'update' (create/update/delete on the paragraph item) or 'view' (view on the paragraph item) access on the parent entity. If that parent entity happens to be a paragraph item, it will just execute the same code again until it finds an entity that actually implements entity_access, like nodes.

jeroen.b’s picture

@michaellander, are you using the flag_entity module or the flag module?
Can you write up specific reproduce steps in a separate issue?

michaellander’s picture

@jeroen.b

Sorry, I haven't been able to get to this.

I'm starting to think it's how the flag module handles entity access so this might not actually be on paragraphs, though I'm interested as to how field_collections gets around it.

You do not need flag_entity.

  1. First create a content type or use basic page.
  2. Create a flag for that content type, and use the 'Confirmation form' Link Type on the flag settings page. Make sure you also set the appropriate access on this page so that all authenticated users may flag/unflag content of this type.
  3. Then go to 'Manage fields' on the flag you just created and add a Paragraphs field and configure appropriately.
  4. Lastly, create a test user and visit that page and click the flag link, this should show you the entity add form for the flag, where you'll see the paragraph inaccessible.
michaellander’s picture

It looks like flags might not implement an access callback in hook_entity_info, which means any calls to entity_access would return null. I'm wondering would it be the responsibility of paragraphs to return PARAGRAPHS_ITEM_ACCESS_IGNORE if it returns null, or is this purely a flag module issue?

jeroen.b’s picture

Returning PARAGRAPHS_ITEM_ACCESS_IGNORE when the host entity doesn't implement access control seems like a bad idea.
I think it's best if flags just implements entity access or just always return TRUE.

Why would they not implement entity_access?

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

seanB’s picture

Version: 7.x-1.x-dev » 7.x-1.0-rc4
Status: Closed (fixed) » Needs review
FileSize
648 bytes

I think there is still an issue somewhere in rc4. When using nested paragraphs, I get an error: EntityMalformedException: Missing bundle property on entity of type paragraphs_item.. The function entity_extract_ids() seems to receive the node as entity and 'paragraphs_item' as type.

In the file paragraphs.field_widget.inc on line 410 you do a setHostEntity(). You get the entity from $element, but the entity type from $field_state. This allows a mismatch between the entity type and the entity. Not sure why this is done, but fetching both the entity and the entity type from $element seems to fix the issue.

I add a patch to fix this.

jeroen.b’s picture

I think the actual problem is in #entity. See #2262929: field_attach_form for paragraph item may not use $element directly. In D8 I prevented such issues by adding all Paragraphs information in a second level ($element['subform']). I think that should be backported to D7.

manu manu’s picture

Agree with #74, @jeroen.b, is that quite a big change?

jeroen.b’s picture

It's not really a big change, but D7 relies on it way more than D8 so it needs good testing. I'll might take a swing at it tonight.

seanB’s picture

Sounds good, I have a couple of sites to test the changes.

jstoller’s picture

I've come across a strange AJAX error and I'm wondering if it's related to this issue. I've defined a Bean bundle, called Custom Block, with a couple paragraphs fields on it. If I edit an existing Custom Block that has a paragraphs item in a collapsed state, then attempting to add another paragraphs item to either of my paragraphs fields will trigger the AJAX error shown below. If I expand the existing paragraphs item then I am allowed to add more paragraphs items to the fields. However, trying to collapse the paragraphs item again triggers the same error.

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /system/ajax
StatusText: n/a
ResponseText: 
Error  
Error message
Notice: Undefined index: value in csc_get_field_value() (line 103 of /path/to/www/sites/all/modules/custom/csc/csc.module).
Warning: array_flip(): Can only flip STRING and INTEGER values! in EntityAPIController->load() (line 219 of /path/to/www/sites/all/modules/contrib/entity/includes/entity.controller.inc).
EntityMalformedException: Missing bundle property on entity of type paragraphs_item. in entity_extract_ids() (line 7879 of /path/to/www/includes/common.inc).
The website encountered an unexpected error. Please try again later.    

ReadyState: undefined

If it matters, the csc_get_field_value() function referenced here is a simple wrapper around field_get_items(). The 'value' index it says is undefined allows me to specify the array key that holds a particular field's value. I mostly use it in templates, so I can change how things are themed based on field values.

jsacksick’s picture

Hi, for some reasons, I started to get the following message " EntityMalformedException: Missing bundle property on entity of type paragraphs_item" on a site I've been working on for weeks... It's happening on quite a few nodes and so far I can't really explain it... I don't know if it's related but I didn't enable the revisions from the beginning. The patch in #73 doesn't help.

jstoller’s picture

Version: 7.x-1.0-rc4 » 7.x-1.x-dev
Status: Needs review » Needs work

Just checking in on this and, actually, Paragraphs development in general. No pressure or anything, but it seems like development of Paragraphs 7.x has effectively stalled for the last 4-5 months, with several RTBC issues sitting in the queue and others awaiting maintainer input. Anything we can do to help? I've got a lot invested in Paragraphs on D7 and am happy to do a little testing to move development forward.

jeroen.b’s picture

Hi @jstoller,

Yes, you are right. This is mostly because I just can't find the time to focus on Paragraphs next to everything else I have to do.
It would be great to have a co-maintainer for the 7.x branch.

jstoller’s picture

@jeroen.b, thanks for replying and I completely understand. My little Publication Date module has maybe a fifth of your install base, but it's still hard to keep up with its minimal demands sometimes. I'd volunteer to help, but honestly I don't think my developer-fu is strong enough for a complex module like Paragraphs. Maybe post a call for help on the project page?

Any chance you'll be at DrupalCon New Orleans and, if so, have you considered a sprint?

jeroen.b’s picture

I'm from The Netherlands so it's sadly not possible for me to visit non-EU events.
I changed the Project Status to let people know we are looking for co-maintainers.

Another "problem" is that the module works fine for the company I'm working at, and thus there is no real need to invest time in it. The only time I currently spend on it is in my personal time.

jstoller’s picture

Anyone here have the expertise to implement what's proposed in #74? Maybe we can get a patch to RTBC. I'm happy to help test and do what I can to move the module forward.

recrit’s picture

The subform would be a cleaner way of doing this, it would cause a lot of re-work and break other widget altering that wouldn't know to check subform.
The patch in #73 has been working for me and the field collection module does it the same way with $element['#entity_type'], $element['#entity'] in its field_collection_field_widget_form.

The one issue that remains is that after field_attach_form('paragraphs_item', $paragraph_item, $element, $form_state, $language); is called the host entity data is lost if some one pulls the entity or form from cache on a new node / entity.

Fix: The attached patch sets the incoming host entity information on the $element. This data will not be overridden by field_attach_form and can be accessed in the form state and form cache.

recrit’s picture

Status: Needs work » Needs review
aschiwi’s picture

@recrit: Thank you so much for this patch! We have been having this problem for quite a while on a site with nested paragraphs and never found a way to fix it. I applied your patch to our rc4, which worked great and finally solved our problem. <3

jeroen.b’s picture

Status: Needs review » Needs work

@recrit, great, thanks!
Are you able to create a unit test for this?

NancyDru’s picture

Patch does not apply on fresh clone for me.

NancyDru’s picture

idflood’s picture

This patch also fixed an EntityMalformedException on one of our website. Here is a reroll of the patch in #85.

idflood’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 91: paragraphs-host_entity_problems-2564327-91.patch, failed testing.

pbuyle’s picture

I had issue when building content with 3 levels of nested paragraphs (paragraphs inside paragraphs inside paragraphs inside nodes). When editing a existing node with two paragraph items , I got an EntityMalformedException exception. Tracing the exception, ParagraphsItemEntity was called with $entity_type node, while the $entity itself was a ParagraphsItemEntity instance. So somewhere the top-most host entity was used for the widget of a nested host entity. I didn't fully trace the issue, but this seems to be what the patch in #91 address by storing the host entity and its type in the $element to prevent it to be overridden by field_attach_form().

Pol’s picture

Status: Needs work » Reviewed & tested by the community

Hi,

This patch should be included in paragraphs indeed. It's needed for other patches.

klokie’s picture

+1

klokie’s picture

+1 [doubled-posted due to momentary hiccup @drupal_infra]

emmanvazz’s picture

+1 for #85, worked great.

CatherineOmega’s picture

The fix works; can someone reroll a patch so it can be committed?

jstoller’s picture

Here's a re-roll of #85 against the current dev.

Pol’s picture

@jstoller: this is _exactly_ the same patch as in #91.

jstoller’s picture

Sorry. My bad. It looks like this is being blocked by #2562463: Parent entity access check throws PHP notice because $nid nor $vid are set. None of the Paragraphs patches are going to pass until that gets committed.

jeroen.b’s picture

Are we sure that $element['#bundle'] is always set? Also on users for example?

jstoller’s picture

@jeroen.b I just confirmed that $element['#bundle'] is always set. A user entity's bundle is "user."

maxdev’s picture

Hi

I can confirm, that latest patch #100 fixes the problem with edit nested paragraphs.
In our case, when paragraph with another embedded paragraphs has less weight than others it throws exception:

EntityMalformedException: Missing bundle property on entity of type paragraphs_item. in entity_extract_ids() (line 7929 of /var/www/drupal/bvn7/htdocs/includes/common.inc)

Debugging of line 7929 shows, that error occurs, because variable $entity in entity_extract_ids() is node object, but $entity_type is 'paragraphs_item'

loopduplicate’s picture

herved’s picture

Hello,

I also encounter an EntityMalformedException with nested paragraphs.
Maybe the same issue reported in #105 and 29?

Basically on my side it seems to come from Display Suite ds_entity_variables() which cannot find the entity at this line:
$entity = isset($vars[$entity_type]) ? $vars[$entity_type] : (isset($vars['elements']['#' . $entity_type]) ? $vars['elements']['#' . $entity_type] : NULL);

I believe \ParagraphsItemEntity::view() should provide the entity in the render array. Something like this at paragraphs/ParagraphsItemEntity.inc:534:

$build = entity_get_controller($this->entityType)->view(array($this), $view_mode, $langcode, $page);
$build['paragraphs_item'][$this->item_id]['#paragraphs_item'] = $this;
return $build;

Should we open a new issue for this?

Thank you,
Hervé

herved’s picture

Just an update on my last comment.
I debugged a bit more and the issue seem to be coming from the theme I am using which messes with the theme registry and somehow removes the template_preprocess_entity() preprocess function from theme_entity().
So you can discard my last comment.

Regards,
Hervé

kevinquillen’s picture

Confirming that the patch from #106 fixes this issue.

Prior to that, I could not add paragraphs of the same type to an entity without getting "Missing bundle property on entity of type paragraphs_item".

geoffray’s picture

Confirming patch #106 fixes the issue.

I was also getting the AJAX error described in the issue when trying to add new paragraphs in a nested paragraphs configuration.

capellic’s picture

Confirming patch #106 fixes the issue.

@maxdev's report of their symptom tipped me off:

In our case, when paragraph with another embedded paragraphs has less weight than others it throws exception:

Thanks all!

jkopel’s picture

Another report that the problem is real and the patch in #106 fixes it!

jstoller’s picture

The patch from #106 still applies on the latest dev release.

DamienMcKenna’s picture

This solved problems for me too.

DamienMcKenna’s picture

This needs to be in the next release.

  • jstoller committed 52c2fcb on 7.x-1.x authored by loopduplicate
    Issue #2564327 by jstoller, recrit, loopduplicate, seanB, idflood, Pol:...
jstoller’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.