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)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

openWeb’s picture

Issue tags: +block, +mongodb, +mongodb_block

Perhaps 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!

mattwmc’s picture

I 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:

function template_preprocess_block(&$variables) {
openWeb’s picture

Sorry, 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...

langworthy’s picture

You're right. We shouldn't patch core :)

langworthy’s picture

Title: Cannot redeclare template_preprocess_block » mongodb_block.module conflicts with block.module
Status: Active » Needs review
FileSize
0 bytes

I 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()

Status: Needs review » Needs work

The last submitted patch, block_conflict-1163584-5.patch, failed testing.

langworthy’s picture

Status: Needs work » Needs review
FileSize
6.44 KB

I made the last patch with other patches applied. Here's a new one.

langworthy’s picture

Forgot to $git add --all

langworthy’s picture

And the whole time I've forgotten $git diff --staged. I'm on a roll

Status: Needs review » Needs work

The last submitted patch, block_conflict-1163584-9.patch, failed testing.

langworthy’s picture

I know the testbot is broken but I do actually keep creating terrible patches. I'm pretty sure this is the one.

MiSc’s picture

@langworthy, could you give your five cents on this: http://drupal.org/node/1447806

MiSc’s picture

Delete

MiSc’s picture

MiSc’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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

langworthy’s picture

Status: Closed (fixed) » Needs work

I just ran into the reported problem with the latest dev release during the install process. Fatal error: Cannot redeclare template_preprocess_block()

MiSc’s picture

Status: Needs work » Needs review
FileSize
4.83 KB
4.24 KB

Micro patch attached.

7wonders’s picture

Just been getting the error:

Drush command terminated abnormally due to an unrecoverable error.                                                                                       [error]
Error: Cannot redeclare template_preprocess_block() (previously declared in
/data/disk/o1/distro/001/drupal-7.14.2-dev/sites/test.com/modules/mongodb/mongodb_block/mongodb_block.module:334) in
/data/all/001/drupal-7.14.2-dev/modules/block/block.module, line 985

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.

js’s picture

Thank 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.

js’s picture

It 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.

js’s picture

It 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.

fgm’s picture

Issue summary: View changes
Status: Needs review » Needs work
Related issues: +#1955528: mongodb_block_render_blocks does not act like _block_render_blocks

Looks 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 ?

  • fgm committed 3b772a7 on 7.x-1.x authored by MiSc
    Issue #1163584 by langworthy, MiSc: reduce mongodb_block.module...
fgm’s picture

I 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.

fgm’s picture

Status: Needs work » Needs review

It seems there would be a much simpler fix for this issue, which would be to just rename that function mongodb_block_preprocess_block instead of template_preprocess_block : it is also included in the registry as a preprocess callback, in second position after template_preprocess, just like template_preprocess_block is currently called.

Any reason not to use this mechanism ?

fgm’s picture

It is checkable as a PR https://github.com/fgm/mongodb/pull/47

And as the attached patch.

  • fgm committed d3b2322 on 7.x-1.x
    Issue #1163584 by langworthy, MiSc, fgm: mongodb_block.module conflicts...
fgm’s picture

Status: Needs review » Fixed

Merged in today's 7.x-1.x HEAD, thanks for the wait.

Status: Fixed » Closed (fixed)

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