Core pr 3 (merge with Artesis)#2
Conversation
We want this to be true: $first = empty($entity->var); $entity-var; $first === empty($entity->var); Which it wouldn't be before this change, if there was a getVar() method.
This reverts commit e8d8003.
…d _field_invoke_multiple in field_attach_prepare_view will go through all field and not only the ones specified in the view mode.
There was a problem hiding this comment.
Why have such debugging information been removed?
There was a problem hiding this comment.
I'd rather ask, why has it ever been committed? I don't think we want Drupal throwing backtraces in production.
There was a problem hiding this comment.
This only occurs if code hits an undefined property of a DingEntityBase object. Since it implements magic gettings we do not get warnings for undefined properties as would normally be the case for standard PHP objects.
It is primarily meant as a tool for developers. We should not reach this in production.
There was a problem hiding this comment.
I don't known why this have been removed, but I think that we should never have backtrace and trigger error in production code.
On another node I'm personally not to happy with the DingEntityBase object, but that might be because I don't know the reason behind it and the way it have been created. It just seams that all "hard" problems/errors always ends up in DingEntityBase.
There was a problem hiding this comment.
Of course we should not trigger ellers or have backtraces in production code but PHP will trigger errors if code tries to access an undefined property on an object no matter where it is run. It is the developers' responsibility to ensure that it does not happen.
The code above does that change that.
|
Looks good to me 👍 |
|
Ready for merge. The comments regarding debugging code is interesting but should not block progress. |
|
Merged. |
7 participants
This repository have been merged with the Artesis libraries.