Download & Extend

Node Radioactivity fatal error on cached pages when using i18n

Project:Radioactivity
Version:6.x-1.2
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

When a registered user views a page there is no error, but when an anonymous user views a page that page is cached and for some reason I get the following error at the bottom of the page (and only after the rest of the page has fully loaded):

Fatal error: Call to undefined function drupal_schema_fields_sql() in C:\testingserver\pixelclever\modules\node\node.module on line 729

I traced this to the radioactivity module and tested it on two separate sites by disabling the node radioactivity. When node radioactivity is disabled the error disappears. I know the error is related to caching because when I clear the site cache the error disappears for one page load then reappears on the second page load. If you are running the site on the same browser that you use as a registered user you have to clear the browser cache to see the error, as the default is to load the code from the non-cached pages.

I have tested this on both IE and Firefox on a LAMP server and a WAMP server with the same results.

I suspect that the problem is somewhere in either radioactivity_node_exit( ), radioactivity_node_user_node_view( ) or radioactivity_add_energy( ).

Comments

#1

Hmmmh... the line you mentioned is in node_load() function. The funny thing is that radioactivity does not contain any calls to node_load(). I did a brief glance in the code and I didn't find anything which would indirectly make an invocation to node_load. In this case, I'd suspect that radioactivity_node reveals bug somewhere else, e.g., template or another module implementing hook_exit(). (I still wouldn't rule out radioactivity completely...)

To see, whether the message is bug in radioactivity or not, please add something to the very end of radioactivity_node_exit(), maybe something that writes a line in some temp file. If radioactivity_node_exit() completes, the bug is not in radioactivity.

For a quick workaround, you could try changing drupal bootstrap phase from DRUPAL_BOOTSTRAP_PATH to DRUPAL_BOOTSTRAP_FULL in radioactivity_node_exit() and see if that fixes your issue. Anyways, the issue is very likely related to bootstrap phase.

#2

Status:active» closed (won't fix)

#3

Version:6.x-1.0» 6.x-1.2
Status:closed (won't fix)» active

It is indeed related to the Drupal bootstrap in hook_exit. When used together with i18n, we get the error in i18n.module, but the culprit is in radioactivity_node_exit(). We can solve it as you say by adding DRUPAL_BOOTSTRAP_FULL, but that really doesn't fix the issue.

I'll investigate some more.

#4

So, I traced this a bit more:

radioactivity_node_radioactivity_info() calls node_get_types(), which calls _node_types_build(), which calls hook_db_rewrite_sql(), and i80n calls menu_get_object in a sub function, which isn't loaded when DRUPAL_BOOTSTRAP_PATH is used.

The only way to solve this as I see it is to use DRUPAL_BOOTSTRAP_FULL, but I wonder what the performance issues we might see with that.

#5

This is one of the reasons, why hook_db_rewrite_sql() was not the brightest idea of them all. AFAICT, D7 does not even have it anymore. Anyways, if you happen to bounce into this, the workaround is as in comment #4 (i.e., edit radioactivity_node.module a bit).

Currently, I'm thinking about two possible solutions:

  1. Get node types using different means, thus bypassing the hook_db_rewrite_sql call altogether
  2. Make a configuration option into admin pages, so that people can enable this workaround when needed

I'm going to aim for option 1, if it does not turn out to be an exceptionally ugly solution.

It'll be a while before I have the time for making a new release. In the meanwhile, patches are welcome!

#6

Title:Node Radioactivity fatal error on cached pages» Node Radioactivity fatal error on cached pages when using i18n
Status:active» needs review

Updated title.

As you say in #5, the purpose of this code is really to get a list of node types and it doesn't matter what the users permissions are. The attached patch should fix the problem by doing a direct query and it doesn't really increase the code much (it does increase comments to explain why we avoid more typical approaches).

AttachmentSize
364965_fatal_error_cached_i18n.patch 800 bytes

#7

Status:needs review» fixed

Ok, tested the above and it seems to fix this issue. Thus, committed. The commit also removes loading node.module, as it shouldn't be needed anymore.

#8

Status:fixed» closed (fixed)

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

nobody click here