[regression] Themes unable to implement hook_element_info_alter()

First one.

+++ b/core/lib/Drupal/Core/Render/ElementInfoManager.php
@@ -67,7 +78,7 @@ public function getInfo($type) {
     // Get cached definitions.
-    if ($cache = $this->cacheBackend->get('element_info_build')) {
+    if ($cache = $this->cacheBackend->get('element_info_build' . $this->themeManager->getActiveTheme()->getName())) {

Missing ':', I would appreciate a $this->getCacheId() function ...

No comment to the PHP error ;)

, I would appreciate a $this->getCacheId() function ...

Sure.

There we go.

+++ b/core/lib/Drupal/Core/Render/ElementInfoManager.php
@@ -119,5 +132,14 @@ public function clearCachedDefinitions() {
+    return 'element_info_build:' . $this->themeManager->getActiveTheme()
+      ->getName();

Put this on one-line please.

The issue summary should mention the caching changes too (which are essential!)

Does this still need non-unit tests?

Hm. Can you explain how this meets the definition of critical? https://www.drupal.org/node/45111

Critical bugs include those that:

Render a system unusable and have no workaround.
Cause loss of data.
Expose security vulnerabilities.
Cause tests to fail in HEAD on the automated testing platform, since this blocks all other work.

Note especially this part:

Regressions in functionality are not automatically considered critical. Even if the bug existed before, it should be prioritized according to its impact.

I find it a bit difficult to believe that it's impossible to theme at all without this being fixed, but it sounds solidly major since it falls under "Issues that have significant repercussions but do not render the whole system unusable (or have a known workaround) are marked major."

I discussed this with markcarver in irc a bit.

As I understand it, these two hooks block a port of the bootstrap theme, which has > 50,000 users (which puts it in top four themes on d.o, AdaptiveTheme, Omega and Zen are above, I don't know if they also implement these hooks).

We discussed between branch maintainers last week that 1. regressions definitely aren't always critical (has been documented for a while now) 2. contributed project blockers aren't necessarily critical (is not really documented anywhere either way).

However I don't think we've sorted out what the criteria are for contributed blockers that are critical.

It's probably going to come down to a combination of how much of a blocker the blocker is, usage, and whether other projects depend on the project (so that they'd also not be able to port). So I suggested open as critical for now. I'm personally borderline on this, although if lots of themes rely on these two hooks that'd put me strongly towards keeping it a release blocker.

@markcarver: could you provide (or point to) a concrete example, to clarify what exactly this enables? That makes it much easier to understand what this is about for everybody :)

#2351731: hook_element_info_alter() does not always get invoked in themes suggests that this never worked properly in D7 in the first place.

#13: That is however only true for contrib behaving badly, but not a core limitation.

Hence this is a regression from core, but yes the fix here (add to the cache key) could and should be backported to D7.

#16: Yes, there is, the solution in this patch is back-portable and should be back ported.

That is what I said in #14, hook_element_info_alter() worked properly for themes in D7 - except when contrib modules misbehave.

The 7.x static cache could still key by theme name.

We should also key the internal static cache by the active theme probably.

I tried to key by theme name, but this did not fixed the failure.

This could be it.

Nice work! **RTBC** from me - if tests pass.

Thank you for your RTBC, but I think we want to have a proper integration test first, let me work on that.

There we go.

Yes, that is good, but should we not check if the alter is actually called?

Forgot the test file.

Back to RTBC indeed :).

Committed/pushed to 8.0.x, thanks!

Moving back to 7.x for the static cache fix.

Hello,

This bug is fixed for D8.
Is there a solution for D7 ? If not, until the problem is committed to D7, should I use this patch :
https://www.drupal.org/node/2351731#comment-9701387

Thanks for your replies.

@kumkum29 It is necessary for someone to post a patch on this issue. This is the patch by @markcarver

I pinged @markcarver on IRC and #34 isn't a backport of what was committed to D8, so we should start from #28.

The patch mentioned in #34 didn't work for me. I tried to create node editing form using Panels. The stacktrace looks like this:

Fatal error:  Call to undefined function _bootstrap_process_element() in /var/www/myproject/includes/form.inc on line 1850, referer: http://localhost/najemce/1772/edit
Stack trace:, referer: http://localhost/najemce/1772/edit
 1. {main}() /var/www/myproject/index.php:0, referer: http://localhost/najemce/1772/edit
 2. drupal_bootstrap() /var/www/myproject/index.php:20, referer: http://localhost/najemce/1772/edit
 3. _drupal_bootstrap_full() /var/www/myproject/includes/bootstrap.inc:2262, referer: http://localhost/najemce/1772/edit
 4. menu_set_custom_theme() /var/www/myproject/includes/common.inc:5243, referer: http://localhost/najemce/1772/edit
 5. menu_get_custom_theme() /var/www/myproject/includes/menu.inc:1772, referer: http://localhost/najemce/1772/edit
 6. menu_get_item() /var/www/myproject/includes/menu.inc:1757, referer: http://localhost/najemce/1772/edit
 7. _menu_translate() /var/www/myproject/includes/menu.inc:474, referer: http://localhost/najemce/1772/edit
 8. _menu_load_objects() /var/www/myproject/includes/menu.inc:763, referer: http://localhost/najemce/1772/edit
 9. call_user_func_array() /var/www/myproject/includes/menu.inc:592, referer: http://localhost/najemce/1772/edit
10. pm_arg_load() /var/www/myproject/includes/menu.inc:592, referer: http://localhost/najemce/1772/edit
11. _pm_arg_load() /var/www/myproject/profiles/cartaro/modules/contrib/ctools/page_manager/page_manager.module:1004, referer: http://localhost/najemce/1772/edit
12. ctools_context_get_context_from_argument() /var/www/myproject/profiles/cartaro/modules/contrib/ctools/page_manager/plugins/tasks/page.inc:548, referer: http://localhost/najemce/1772/edit
13. ctools_node_edit_context() /var/www/myproject/profiles/cartaro/modules/contrib/ctools/includes/context.inc:803, referer: http://localhost/najemce/1772/edit
14. ctools_context_create() /var/www/myproject/profiles/cartaro/modules/contrib/ctools/plugins/arguments/node_edit.inc:49, referer: http://localhost/najemce/1772/edit
15. ctools_context_create_node_edit_form() /var/www/myproject/profiles/cartaro/modules/contrib/ctools/includes/context.inc:607, referer: http://localhost/najemce/1772/edit
16. drupal_build_form() /var/www/myproject/profiles/cartaro/modules/contrib/ctools/plugins/contexts/node_edit_form.inc:70, referer: http://localhost/najemce/1772/edit
17. drupal_process_form() /var/www/myproject/includes/form.inc:385, referer: http://localhost/najemce/1772/edit
18. form_builder() /var/www/myproject/includes/form.inc:885, referer: http://localhost/najemce/1772/edit

Did you see what I wrote in #35? The patch in #34 is invalid. We must proceed with backporting #28.

Also re #36, did you implement hook_element_info_alter()?

Is there a D7 patch for this?

See #33.

Ok so #33 redirect at the end to this issue and has the same patch as #34. So there's no fix for this issue ?
Cause I applied the patch and same problem.
I am using a custom layout with DisplaySuite on user and node displays and now I'm having the Call to undefined function _bootstrap_process_element... on my node displays but not on the user ones everytime I try to place a field on a region of the display. Any help on this ?

Thank you

I have just encountered this issue, it occurs when I submit a form inside a block. I am using bootstrap theme. I followed other threads and per recommendation, set my admin theme to match my main bootstrap derived custom theme. This error goes away for a while, then recurs after I clear caches, browser history, etc. But even when the error does not occur, it seems that ajax/javascript fails silently and my form submit callback never gets called.

I am on Drupal 8.0.5. The whole patch history here is pretty confusing, it is unclear to me at this point if this is or is not fixed in Drupal 8.0.X. Any help would be enormously appreciated, this is the only item that is blocking the launch of my site.

My call stack is below:

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'bootstrap_form_process' not found or invalid function name in Drupal\Core\Form\FormBuilder->doBuildForm() (line 984 of core/lib/Drupal/Core/Form/FormBuilder.php).

Drupal\Core\Form\FormBuilder->doBuildForm('donate_form_vehicle', Array, Object) (Line: 560)
Drupal\Core\Form\FormBuilder->processForm('donate_form_vehicle', Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder->buildForm('Drupal\donate\Form\DonateFormVehicle', Object) (Line: 217)
Drupal\Core\Form\FormBuilder->getForm('Drupal\donate\Form\DonateFormVehicle') (Line: 34)
Drupal\donate\Plugin\Block\DonateBlock->build() (Line: 116)
Drupal\panels\Plugin\DisplayBuilder\StandardDisplayBuilder->buildRegions(Array, Array) (Line: 133)
Drupal\panels\Plugin\DisplayBuilder\StandardDisplayBuilder->build(Object) (Line: 281)
Drupal\panels\Plugin\DisplayVariant\PanelsDisplayVariant->build() (Line: 34)
Drupal\page_manager\Entity\PageVariantViewBuilder->view(Object, 'full') (Line: 101)
Drupal\Core\Entity\Controller\EntityViewController->view(Object, 'full')
call_user_func_array(Array, Array) (Line: 128)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 577)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 129)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 102)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 139)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 62)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 62)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 103)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 55)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 637)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Thanks to all for tackling this painful ongoing issue!

I was able to resolve this by updating to the latest Drupal Bootstrap theme. This was a painful choice however, the theme update has caused a lot of layout problems. But I did want to report that the issue is resolved for me in 8.0.5 by updating to the latest Bootstrap module in case it helps someone else.

This was fixed in 8.0.x, moving back to 7.x

@catch -- my apologies -- I thought the version would only pertain to my comment. Thank you for fixing it.

However, I do have an issue I need help with. I am on Drupal 8.0.5 but my site was built on a prior version of the Bootstrap module that has the bug. I attempted to update my bootstrap theme, but that was a disaster, the navbar collapse broke and all my template overrides would have to be redone. So I had to revert to my originally installed Bootstrap module/theme.

The less invasive solution for this site would be for me to patch my Bootstrap theme with the specific fix for this issue. Is there an existing patch for Bootstrap 8.x-3.0-alpha1 to fix this issue? Or if not, could one be provided?

This is causing my multi-part form to be completely unusable and I am unable to launch my site as a result. A fix would be greatly appreciated. Thank you.

@catch, @markcarver I just read through this history again carefully to see if I could possibly decipher how to apply a patch or series of patches to resolve this issue without having to update Bootstrap on my existing site, but given the comments in #36, #39 and #43, I don't see a clear path. I have updated core, so I only need the part that would apply to bootstrap. Please advise, and thank you for your efforts on this.

I don't think it makes sense to keep this open for Drupal 7 - first because it's not the same bug (this was a critical problem in Drupal 8 but is only triggered in edge cases in Drupal 7), plus there is debate about the best fix for Drupal 7 - with the latest patch here literally not even being a backport at all (and none of the possible other solutions really looking like an actual backport either).

I will reopen #2351731: hook_element_info_alter() does not always get invoked in themes instead, with a pointer to this issue.