When the context_layouts module is enabled, blocks disappear from the available context reactions.
The current patch clears all caches in hook_install(). This addresses the issue. However, some outstanding questions remain:
if (!drupal_installation_attempted()) to avoid unnecessary cache flushing, since caches will be flushed on install anyway?_context_registry(NULL, TRUE) to flush the context registry cache? Do we need to call cache_clear_all('ctools_plugin_files:', 'cache', TRUE);? Flushing these two didn't address the issue.hook_modules_enabled() to flush specific caches when a module is enabled that implements hook_context_plugins() or hook_context_registry_alter()?Temporary workaround: flush caches.
none
none
Hi there,
The blocks reactions are missing from contexts when I enable the "context layouts" module.
Once I disable it they reappear in the dropdown list.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | context-blocks_missing_from_reactions_when_layouts_enabled-1297776-9.patch | 415 bytes | tekante |
| #7 | context-layouts-blocks-1297776-7.patch | 334 bytes | nedjo |
Comments
Comment #1
idflood commentedSame issue still exists in the dev version.
Comment #2
steveburge commentedCan confirm the bug - tested on two plain installs.
When context layouts is enabled, blocks disappears from reactions. When Views and context layouts are both enabled, blocks appears in reactions but nothing happens when clicking on Conditions or Reactions.
Comment #3
jkthng commentedFacing the same issue.
Comment #4
EvanDonovan commentedI also experienced this issue (in beta2). Clean install, have Views & Context Layouts enabled, and Blocks doesn't appear in Reactions.
Comment #5
nedjoClearing caches works as at least a temporary workaround.
#1202354: fusion_core_block_list causes fatal error with Context module is triggered by this bug.
Comment #6
nedjoWhich cache needs to be cleared?
I tried
_context_registry(NULL, TRUE)andcache_clear_all('ctools_plugin_files:', 'cache', TRUE);but neither did the trick.Comment #7
nedjoCalling
drupal_flush_all_caches()on enabling context layouts fixes the issue--patch attached. I'd rather though be able to determine just which cache or caches need to be flushed.Comment #7.0
nedjoCreate summary.
Comment #8
tekante commentedAdding tag for tracking
Comment #9
tekante commentedIt appears there is either a race condition or potentially some caching interaction between how Drupal 7 builds the class registry and how ctools tries to automatically register files that contain classes used in plugins. When ctools_registry_file_alter runs on initial enabling of the context layouts module it looks like the list of plugins for context may have been cached (and since context layouts provides a new plugin that is used to override the normal block handling) the class file doesn't get added to the registry until after a cache clear. This results in a failure when checking if the class exists within the ctools_plugin_get_class() function.
To make a long story short, it appears that adding the name of the class file to the .info file has no ill effects and resolves the problem and should be much less invasive than triggering full cache clears or trying to poke around in the ctools system or registry system.
The attached patch does that, please test it out and update if it resolves the problem for you.
Potentially related #1679546: ctools_plugin_get_class incorrectly returns NULL until cache cleared
Comment #10
nedjoWow, nice sleuthing! Haven't tested but this looks like a great fix.
Comment #11
willieseabrook commented@tekante
Although this doesn't apply as the drupal packaging info messes with the patch application, the patch fix works.
I manually added "files[] = plugins/context_layouts_reaction_block.inc" and blocks are available again.
Thanks for the patch, I was stumped.
Comment #12
tekante commentedCommitted to 7.x-3.x branch. http://drupalcode.org/project/context.git/commit/7d5e4795a343485385eb28f...
Thanks for the bug report.
Comment #14
Kim A. Jakobsen commentedI just got this bug again. I use context modules 7.x-1.1.
The problem was resolved by clearing caches.
As easy it is to solve this problem can be quite confusing.
Comment #15
rylynchen commentedGot the same issue in 7.x-3.0-beta7.
Does anyone have a solution ?
Comment #16
aleck_wi commentedGet the same/
problems with JS. avoided by using FireFox
Comment #16.0
aleck_wi commentedUpdated issue summary.
Comment #17
mareks commentedSame problem over here. No blocks at all under context Reactions. Using 7.x-3.1
Comment #18
mareks commentedIn my case, it helps if I turn off "Context UI" and flush the cache.
Comment #19
falc0 commentedThe only way I was able to fix this was to completely disable, uninstall and reinstall the module. I had a backup of my context items on a different server, so I could import them one by one.
Comment #20
themic8 commentedWe are using 7.x-3.2 and are having the same issue. Comment #19, falc0s, solution has restored blocks for us.
Solution, to completely disable, uninstall and re-install the module. Then we re-imported all of our context items.
Comment #23
clemens.tolboom[edit]Drupal 7.41 + Context 7.x-3.6[/edit]
We just migrated a site and the block reaction disappeared. Exporting the context shows the correct settings still but the blocks don't display on the targeted pages. Rebuilding the registry / cache did not help.