Indirect modification of overloaded property in ECKEntity class

Same here. But with all types of fields.

Yes I'm trying to debug this issue at the moment. Its not just a date field. I believe its any field, or possibly fields that have an array of elements. I've found I get the same error with address fields.

It has something to do with the ECKEntity class' overloaded __set() function when a new ECK entity is being saved through the UI. I've been debugging for the last couple of hours, but have not pinpointed the source of the issue yet. Any help would be much appreciated as I have exhausted my hours I can spend on this for the week.

Changing the title again.

cheers.

@acrazy,

I have no idea how the debugging goes... I would love to help but I don't think I can be of any help. If debugging is not too much work I'd like to check it out though. I know PHP, Javascript and stuff, but not too much yet.

Let me know... I love this module.

Also getting this when saving a new entity.

@acrazyanimal you posted in the cache backport issue that you had a hunch that caching was related to this issue, but I think it is more likely that the magic methods __set and __get are causing the issues. I will try to take a look at it this weekend

same issue here with 3.x
another point is though the title property is selected we aren't getting title field

@fmizzle: The posting in the backport was to make people aware that the backport may contain this same issue. I want the backport to be tested to see if anyone gets the same errors. As I mentioned in comment #4 above I believe this issue is related to the magic methods exactly as you suggest. Think we're on the same page?

@EvilGenius: Enable the devel module. There are several php functions it adds including dsm(${some php variable}, 'something to call the output') that allow you to recursively output php variables on the page. Very good starting point for debugging.

@kaizerking: I believe the title not showing up is unrelated. I expect that you have selected the title behavior, but have not exposed the title property through the manage fields tab on the bundle. In 3.x property types, behaviors, widgets and formatters are all separate things. A property type defines the database fields and metadata for a property, a behavior controls only background functionality for a behavior (such as displaying a property value as the entity's title), widgets control form input and formatters control display of the property values.

This patch is not 100% correct, as fields that are set from code and not the UI might not have the suffix field, but I want to make sure it works for everybody before I do a final patch

Awe sweet you figured it out. Nice catch fmizzell. I couldn't see the big picture beyond __set() and it didn't occur to me that __get() is called first when trying to set a field array such as $entity->{$field_name}[$langcode] = $items; before $entity->{$field_name} has been instantiated.

I made a few adjustments to your patch to better identify if the $name in __get() is actually a field. I removed the getField() function; was there an extra purpose in mind for that function?

Seems to work so its been committed.

I hope this is not the wrong thing to do but I am reopening this issue.

I am getting this issue on my ECK object.

Notice: Indirect modification of overloaded property ECKEntity::$field_application_applicant_ref has no effect in entity_metadata_field_property_set() (line 437 of /Users/jucallme/Sites/systemseed/bahamas.com/source/sites/all/modules/entity/modules/callbacks.inc).

I have a ECK entity applicant that has a few fields on it, the reference as you see above and a date field are the two that throw this issue.

On my rule i set the data value from an entityform (same fields) onto this eck entity but its throwing "Indirect modification of overloaded property" errors on both field types of date and entity reference.

I have got the latest dev branch (7.x-3.x).

Here is a patch that fixes this issue correctly.

The exact reason for this can be found here http://stackoverflow.com/a/13186679

Still having the problem with latest dev (May 22), setting an integer field and a list field in code on a newly-created (unsaved) instance of a custom entity.

Patch at #15 fixes it, thanks @jucallme. RTBC again?

Aaand ... nope. I can set and save the field values, but get this watchdog notice:

Notice: Only variable references should be returned by reference in ECKEntity->__get() (line 620 of /drupal7/sites/all/modules/contrib/eck/eck.classes.inc).

Yep, the array is a variable, but the items within the array are not. I believe, in the past, I tried to fix the issue by creating each property and field dynamically as an actual variable in the object, but if I remember correctly, if you have an actual variable like "title", and you call $entity->title, then the magic __get won't be called, and we need it to be called to offer validation. I guess the first step would be to confirm that what I remember is right, otherwise that would be the solution. If, that is not the case, does anyone else have any ideas?

+++ b/eck.classes.inc
@@ -52,7 +52,7 @@ class DBObject implements Iterator{
+  function &__get($var){

Why do we need to return references from DBObject?

All that needs to happen is that rules cant access the magic __get how exactly that needs to be resolved im not to sure the above patch i posted fixes the issue I had with rules but as you state then the error in #17 happens...

clarify

I was going to submit a patch that fixed my specific case, but the patch is actually against Entity API and I'm not sure what the correct method is to handle this type of thing. So I'll explain what I changed and hopefully you all can help me figure out what to do. The fact that this doesn't involve the ECKEntity class itself makes me think I'm probably doing this the wrong way, but maybe it will at least give some information that could be helpful for the correct fix.

I currently have Entity API 7.x-1.5 installed, so the current dev may be a little different, but I went to line 468 of callbacks.inc (in the modules folder of Entity API) and changed this:

  $entity->{$name}[$langcode] = $items;

to this:

  if (property_exists($entity, $name)) {
    $entity->{$name}[$langcode] = $items;
  }
  else {
    $entity->{$name} = array($langcode => $items);
  }

If someone could help me understand what's going on here and why I'm doing it wrong (unless I somehow found the secret formula for fixing the whole thing), I would really appreciate it. I still don't understand what "overloaded" means, so I'm sure that's part of my problem.