per "This code smells" by Larry Garfield @2012 DrupalCamp TC.

Comments

webchick’s picture

Status: Active » Postponed (maintainer needs more info)

Huh?

Crell’s picture

Title: Kill hook_node_load() » Kill hook_load()
Status: Postponed (maintainer needs more info) » Active

Correcting which hook should die. :-)

To clarify, hook_load and friends serve no purpose any more with field api, hook_node_load, etc. It also are not even working on nodes. They work on form state, mislabeled as nodes. Just let them die.

bfr’s picture

Sounds like bunch of keyplayers got drunk @ tc: "Dude, listen. I hate hook_node_load(). Let's kill it. Also, i love you man!". Anyway, sounds intresting, will follow :)

nevets’s picture

What would replace it?

xano’s picture

hook_entity_load(), I suppose?

nevets’s picture

Not really the same thing, hook_load() loads something based on the args value, hook_entity_load only loads entities

Crell’s picture

hook_load() (and its kind, hook_form, hook_update, etc.) is not a hook. It is a magic callback. It's the 2002 alternative to object methods, done badly. The API for it is fundamentally broken. It has already been replaced by fields and by hook_node_*. It is Drupal 4-era cruft we should eliminate.

I'll try to put together a better issue summary shortly. :-)

nevets’s picture

It is a magic callback but it covers more than hook_node_* (only applies to nodes) and I am not sure how fields apply here. It is part of the 'magic' of parameters in menu items and is useful

webchick’s picture

Status: Active » Postponed (maintainer needs more info)

Please don't move from this status until you folks can come up with an actual proposal here. :) You are confusing the crap out of me. :D

Crell’s picture

nevets, it has nothing to do with menu whatsoever.

eric_a’s picture

So poll_load() implements hook_load(). It takes $nodes as its parameter. Other load thingies load a single object as used in menu wildcard autoloading. (or whatever its official name is.) So, yes, clean up, please.

bojanz’s picture

Status: Postponed (maintainer needs more info) » Active

We are talking about this:
http://api.drupal.org/api/drupal/modules!node!node.api.php/function/hook...

To be honest, I didn't even know this hook existed.
As far as I've understood, it has nothing to do with the menu load pattern.

Moving back to active, because I don't see anything questionable in this proposal.

joachim’s picture

hook_load() is a magic callback that allows code-defined node types to have their own form builder for node forms.

It could be cleaned up to a property in hook_node_type_info().

xano’s picture

Don't we have an entity-level replacement for this already?

Crell’s picture

Issue summary: View changes

Was hook_load() finally removed during the big Entity API refactoring? I think it was, but can someone verify?

joachim’s picture

Looks like it's gone.

Drupal\node\NodeForm doesn't invoke any hooks or magic functions. node.api.php doesn't mention it.

This change record states it's gone: https://www.drupal.org/node/2029519

> The node pseudo-hooks (like hook_load(), hook_delete(), hook_insert(), hook_prepare(), hook_update(), hook_validate(), hook_view()) and functions invoking them: node_hook() and node_invoke() are removed. Modules should move their implementations into the corresponding hook_node_*() hooks and use hook_form_alter*() to modify node forms.

This is technically a regression, I suppose, as hook_load() allowed a module defining a node type to provide the form. Whether it's actually a problem is another matter. Certainly in the days of poll module, it was needed. Nowadays though, that sort of functionality should be made available to enhance any node type, and if you want that much control over the form, you should be defining an entity type.

Crell’s picture

Status: Active » Fixed

Good bye and good riddance!

Status: Fixed » Closed (fixed)

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