Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
After installing the mongodb-module i deactivated the core-block-module and activated the mongodb_block. Resulting in a white error-page containing:
Fatal error: Cannot redeclare template_preprocess_block() (previously declared in /var/www/beta.reinemuth.info/htdocs/sites/all/modules/contrib/mongodb/mongodb_block/mongodb_block.module:291)
Comment | File | Size | Author |
---|---|---|---|
#27 | 1163584-mongodb_block-conflict-27.patch | 593 bytes | fgm |
#18 | mongodb_block_conflicts_with_blck.patch | 4.83 KB | MiSc |
#11 | block_conflict-1163584-11.patch | 11.08 KB | langworthy |
#9 | block_conflict-1163584-9.patch | 13.21 KB | langworthy |
#8 | block_conflict-1163584-7.patch | 0 bytes | langworthy |
Comments
Comment #1
openWeb CreditAttribution: openWeb commentedPerhaps this happened, because i had the blocks-module activated at first. But even if i deactivate it, uninstall it, ... this message appears.
Dirty workaround: Comment out the function "template_preprocess_block" in the blocks-module.
After this: everything works as expected, but as i said: dirty workaround!
Comment #2
mattwmc CreditAttribution: mattwmc commentedI have the same problem.
How exactly do you do this?
I keep getting subsequent errors - Call to undefined function drupal_static() etc.
Here's the line:
Comment #3
openWeb CreditAttribution: openWeb commentedSorry, wasn't here for a long time... In the meantime i kicked the mongodb-module out completely because having other issues: the database for logs is bloated with one collection for every watchdog-entry, the site simply forgets about block-settings at all...
To fix this particular issue, i simply commented out the whole "template_preprocess_block"-function in core-block-module! I know that we should never-ever patch core, but this was the easiest and fastest solution...
Comment #4
langworthy CreditAttribution: langworthy commentedYou're right. We shouldn't patch core :)
Comment #5
langworthy CreditAttribution: langworthy commentedI ran into this problem as well. Another issue is that BLOCK_REGION_NONE constant is defined in block.module.
This patch renames BLOCK_REGION_NONE to MONGO_BLOCK_REGION_NONE and renames template_preprocess_block() to template_preprocess_mongodb_block()
Comment #7
langworthy CreditAttribution: langworthy commentedI made the last patch with other patches applied. Here's a new one.
Comment #8
langworthy CreditAttribution: langworthy commentedForgot to
$git add --all
Comment #9
langworthy CreditAttribution: langworthy commentedAnd the whole time I've forgotten
$git diff --staged
. I'm on a rollComment #11
langworthy CreditAttribution: langworthy commentedI know the testbot is broken but I do actually keep creating terrible patches. I'm pretty sure this is the one.
Comment #12
MiSc CreditAttribution: MiSc commented@langworthy, could you give your five cents on this: http://drupal.org/node/1447806
Comment #13
MiSc CreditAttribution: MiSc commentedDelete
Comment #14
MiSc CreditAttribution: MiSc commentedClosing this one, this should be solved by #1447806: Constant BLOCK_REGION_NONE already defined in require_once()
Comment #15
MiSc CreditAttribution: MiSc commentedComment #17
langworthy CreditAttribution: langworthy commentedI just ran into the reported problem with the latest dev release during the install process.
Fatal error: Cannot redeclare template_preprocess_block()
Comment #18
MiSc CreditAttribution: MiSc commentedMicro patch attached.
Comment #19
7wonders CreditAttribution: 7wonders commentedJust been getting the error:
Even though the block module is disabled. Happened after enabling ctools. The second patch in #18 seemed to do the trick though at least in recovering my site.
Comment #20
js CreditAttribution: js commentedThank you for integrating MongoDB. I need it.
I am having trouble with blocks. I have she same problems mentioned in #19. It is hard to coordinate disabling block (and dashboard) and enabling MongoDB Block because it seems that template_preprocess_block() is called by core and at least one of the modules needs to be active.
When I ran into problems (on 10 sites at the same time -- silly me), I found to recover I had to comment out the MongoDB cache settings from settings.php (an early return worked well) and moved the mongodb module out of the way, cleared the cache and refreshed the modules. I as then able to put things back and make the changes. It was easier to enable and disable from drush and could sometimes eliminate the steps.
I have not yet been able to get MondoDB Block working. I am running multiple web servers for the site and also accessing view two hosts (sub-domains) and something, either different hosts or the different servers is introducing a problem. I would get the new blocks working fine on a server but when I access view a different server I get WSoD and have to go through the above process again until I found myself repeating enough to call it quits and write this plea for help.
It is hard, for me, to debug this without errors. I am also wondering if the problem is Contex or with how I am sharing cache across the instances.
I would appreciate any tips on how to proceed? Also, is it worth the effort in terms of performance gains.
Comment #21
js CreditAttribution: js commentedIt looks like Context is a problem, and possibly the root of my problems.
http://drupal.org/node/1367358#comment-6417824
If so, it would be useful to note this in the readme of both projects.
Comment #22
js CreditAttribution: js commentedIt appears that Adsense
http://drupal.org/project/adsense
will not work with mongodb_block.module
does that make sense?
I can work around this by making some blocks or writing a bit of code, but I sure would appreciate hearing if it is worth it. Performance is the most important issue for me, but I have giving up Context and Adsense, and possibly more.
Thanks for helping me with this decision.
Comment #23
fgmLooks like this could be related to #1955528: mongodb_block_render_blocks does not act like _block_render_blocks. Can you check if the patch on that issue fixes the problem ?
Comment #25
fgmI checked again and could reproduce the problem with the template_preprocess redeclaration on today's HEAD, caused by context_theme during theme registry rebuild. It happens because context_theme() assumes it may include block.module even though it does not depend on it, which makes at least some sense since this is a core module which can therefore be assumed to be on disk. Regrettably, this also means that since it does not remove the redeclaration, #1955528: mongodb_block_render_blocks does not act like _block_render_blocks does not fix the issue alone: it also needs #1367358: Context hardcodes block.module dependency.
The problems mentioned in #19 and #20 with drush appear no longer to exist, tough.
There is however a missing key causing a warning in mongodb_block_requirements(), so I committed the requirements fix to remove that problem, but the issue remains active about the redeclaration.
Comment #26
fgmIt seems there would be a much simpler fix for this issue, which would be to just rename that function
mongodb_block_preprocess_block
instead oftemplate_preprocess_block
: it is also included in the registry as a preprocess callback, in second position aftertemplate_preprocess
, just liketemplate_preprocess_block
is currently called.Any reason not to use this mechanism ?
Comment #27
fgmIt is checkable as a PR https://github.com/fgm/mongodb/pull/47
And as the attached patch.
Comment #29
fgmMerged in today's 7.x-1.x HEAD, thanks for the wait.