Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
node system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
18 May 2012 at 21:36 UTC
Updated:
26 Dec 2014 at 22:24 UTC
Jump to comment: Most recent
per "This code smells" by Larry Garfield @2012 DrupalCamp TC.
Comments
Comment #1
webchickHuh?
Comment #2
Crell commentedCorrecting 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.
Comment #3
bfr commentedSounds 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 :)
Comment #4
nevets commentedWhat would replace it?
Comment #5
xanohook_entity_load(), I suppose?
Comment #6
nevets commentedNot really the same thing, hook_load() loads something based on the args value, hook_entity_load only loads entities
Comment #7
Crell commentedhook_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. :-)
Comment #8
nevets commentedIt 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
Comment #9
webchickPlease 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
Comment #10
Crell commentednevets, it has nothing to do with menu whatsoever.
Comment #11
eric_a commentedSo 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.
Comment #12
bojanz commentedWe 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.
Comment #13
joachim commentedhook_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().
Comment #14
xanoDon't we have an entity-level replacement for this already?
Comment #15
Crell commentedWas hook_load() finally removed during the big Entity API refactoring? I think it was, but can someone verify?
Comment #16
joachim commentedLooks 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.
Comment #17
Crell commentedGood bye and good riddance!