Hi guys,
I'd like to use custom entity classes for drupal users and nodes, but some contrib modules restrict those objects to be of type stdClass, for example, pathauto module, which uses stdClass directly in function arguments, like this:

function pathauto_node_update_alias(stdClass $node, $op, array $options = array()) {
  ...
}

They have an issue with relaxing function arguments policy here https://www.drupal.org/node/2117209, but as you can see it's there for 3 years. I wrote in that issue for pathauto for about 7 months ago, you can see my comments there and it's still "needs review" status, and I'm sure there are many such "oldschool" modules, which developers do not use entities or custom classes for users/nodes/other entites.

Finally, I gave up to ask contrib module developers to fix their "mind".

But seems I've found a great solution which will not require changing a lot of contrib modules, but requires a VERY SMALL change in Entity module. All we need to do is to use stdClass as base class for Entity class in includes/entity.inc like this:

class Entity extends stdClass implements EntityInterface {
  ...
}

It will not break anything while it will solve a lot of contrib modules misbehaviors (I mean modules which rely on stdClass in function arguments for base entities like user/node/vocabulary/term, etc.)

Sorry, I don't provide a patch because the change is obvious.
Thanks a lot

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Mav-im created an issue. See original summary.

Mav-im’s picture

Issue summary: View changes
Mav-im’s picture

Hi Guys,

I'm using this "extend stdClass" for 6 years already and it has no issues, so may be apply it?

Thanks

TR’s picture

Version: 7.x-1.7 » 7.x-1.x-dev
Issue summary: View changes
Priority: Major » Normal
Status: Active » Needs review
Issue tags: -custom entity classes
FileSize
385 bytes

The first step is to provide a patch to see if this change breaks anything in the Entity API and to allow people to test and review the changes. I have attached a patch here.

With so many users, and with so many major modules that depend on the Entity API, and with D7 nearing its end-of-life, I think making a change like this requires a high standard of proof that it won't break existing code. Simply passing the Entity API tests isn't enough - I would need to be sure that this didn't break the tests for any of the major modules that depend on Entity API. And I would need to have reviews from more than one person; this change would affect about 50% of all Drupal sites, so if this caused even a minor problem that's still thousands of sites that could break.

PHP deliberately does not subclass objects from stdClass, and it seems to me that what pathauto does (using stdClass as a type hint in function arguments instead of checking is_object() within the function) is simply a bad choice and a technically incorrect way to require the parameter to be an object. I think that the correct place to fix this is probably in pathauto, unless this practice is widespread. But changing the typing of function arguments is usually considered an API change, so I think it's unlikely to happen at this point in the pathauto lifecycle.

Perhaps it's best just to keep the patch here in the issue queue for anyone who encounters this problem and needs a solution.