As the title indicates, this is related to #1441488: Don't call entity_get_info() from inside hook_field_extra_fields(). The difference of course is the hook in question. The Redirect module appears to be calling entity_get_info() to see if the current $path matches the pattern of a known entity type. I suppose this is to accomplish the Global Redirect manner of going from the "machine" URL to an aliased path, e.g. from node/1 to about-us.

However, when this hook is invoked, the full Drupal bootstrap has not completed. Two tasks remain to be done in _drupal_bootstrap_full() after drupal_path_initialize() is called - the theme has to be initialized and hook_init() has to be invoked. We noticed a problem in #1518452: Payment method display titles with theme functions initialize the wrong theme with modules that use entity_get_info() early in bootstrap related to the seemingly more benign task, initializing the theme.

In Drupal Commerce, our payment transaction entity type has bundles for each of the defined payment methods. To find the defined payment methods, we invoke our own hook_commerce_payment_method_info(), whose returned info arrays may include 'display_title' properties that determine how a payment method should display on the front end - particularly with user focused names (e.g. Credit card vs. PayPal WPP) and images (e.g. credit card logos). In the case of PayPal, we use theme() to put the various icons in there representing enabled credit card options and the PayPal payment methods supported by the service.

When theme() is called, if the theme hasn't been initialized, it will do so then. And if nothing else says to use a different theme (say, the URL being an admin path), then the default theme will be initialized and used from there on out. On sites with Redirect enabled, this meant that the default theme was being used for admin pages instead of the admin theme, because the theme was being initialized through hook_url_inbound_alter().

I hope that all makes sense, and there are backtraces in that issue I linked if you need to see it listed out.

I talked this issue over with Damien, and he seemed to think we shouldn't be calling entity_get_info() prior to the full bootstrap process being completed. I don't have broad enough knowledge to be able to argue that point one way or the other. I can assume the "potential" for modules implementing hook_init() to be altering data on the page request that would result in other modules' entity info being altered, but I'd guess that's about as unlikely as us finding this problem in the first place. : )

Really in Drupal Commerce we need to change from using a 'display_title' property on payment method info arrays to using a 'display_title_callback' or some such feature so these titles can be dynamically generated. I can't do that until we open the 2.x branch up, so instead I've opted to temporarily change commerce_payment_methods() to not invoke the info hook until I'm assured the theme has been initialized. That may have side effects, may not.

I'll leave it up to you to decide if Redirect needs to do anything differently, perhaps using a look-up table instead of using the current matching approach. That said, if you look at the code in redirect_url_inbound_alter(), you'll see that the module currently doesn't do anything at all with the return value of the function it calls that in turn calls entity_get_info(). I assume there's something planned there, but perhaps it's just leftover code from something else that can simply be removed.

Whaddya think? : )

Comments

dave reid’s picture

Status: Active » Fixed

I've disabled the call to entity_uri() for now. Likely I'll need to move the code to redirect_init() if I want to keep it.

http://drupalcode.org/project/redirect.git/commit/b655757

rszrama’s picture

Suh-weet. I'm still trying to sort out my mess, too, if you have any ideas. I've tried hacking around to prevent the theme() calls when payment methods are loaded, but I fear I then end up caching incomplete payment transaction entity info that I can't go back and reset later. :-/

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

Issue summary: View changes

Editing.