Pages tagged with: "drupal"

Drupal: strange MySQL "table doesn't exist" error caused by CCK, Features and Strongarm

Ran into a bit of a strange error today; I was getting a Drupal "table not found" SQL error on my live site after pushing an updated feature from the dev site, and then reverting the feature to get the settings back to default.

The query was:

user warning: Table 'greyhead.node_field_instance' doesn't exist query:
SELECT * FROM node_field_instance nfi 
LEFT JOIN node_field nf ON nf.field_name = nfi.field_name 
WHERE = 1 AND nfi.widget_active = 1 
in <noodle foo bar>/sites/all/modules/cck/content.install on line 187.

... So I dived into the CCK module's content.install and line 187 called this function: content_instance_tablename(), which I tracked down to content.module, where the function calls this: variable_get('content_schema_version', 0);

On both dev and live sites, this returns 6009, so the content_instance_tablename() function should return a value of content_node_field_instance, but instead seems to be returning a value which is evaluating to < 6001; i.e. the function returns the old CCK schema table name of node_field_instance, and this breaks any queries which rely on this value.

Putting two and two together, my guess was that Strongarm is over-writing the content_schema_version value in the {variable} table at some point during the execution of certain pages, which is breaking CCK's variable_get call.

So I hopped over to the command line to look into the feature files for "content_schema_version"; cd'ing to the feature's directory, I ran:

grep -irn "content_schema_version" *

... which showed that the variable was defined in the feature:

That Strongarm value

... but that it was providing the right value of 6009. At this point I figured that I was likely to be running into a strange issue being caused by the variable_get running during a variable_set, or some other such voodoo-based weirdness. Easy solution? Remove the field's definition from the feature and allow CCK to look after provision of that variable au-naturel.

So, in the end I simply recreated the feature from the live site (admin > build > features > greyhead settings > recreate) and under the Strongarm drop-down, unticked the checkbox for content_schema_version. Then I re-exported the feature and unpacked it into my MAMP localhost install, did a git commit on the localhost followed by a git push, the over on the server did a git pull, followed by drush cc all and a drush updatedb, just for good measure. Finally, I had to run variable_set('content_schema_version', 6009); using the Devel module.

Touch wood, so far, I haven't seen that error since.

Very odd...


Attached files: 


Just a quick "hello" to anyone passing by who might for some inane reason be worried that this blog may actually be dead; it isn't! Huzzah, rejoice, etc.

The terrible truth of the matter is much more mundane; I've simply not been particularly motivated to write on here when microbloggage is so much more easy and accessible.

Anyway, I'd better get back to work - I'm currently in the middle of figuring out how to debug a strange Apache Solr/Drupal 6/Views 3 issue which is proving very odd...

Ttfn //Al

Looking for a London-based Drupal developer?

Heylo! Unfortunately, I'm not looking for work just now, but if you would like to chat, why not connect with me on LinkedIn?

To see a small selection of some of my previous work, please take a look at my portfolio and read about how I've put together.

Those options again...

Thanks for visiting =o) (this page was last updated on Monday 23rd February 2015)

Another geeky bootnote: Drupal's 'calendar popup' module breaks CSS in Internet Explorer

(I'm jotting a lot down here today, mainly work-related geeky notes to myself. Feel free to ignore... ;o)

This morning, while demo-ing the development site I'm working on at the moment, I was horrified to see that all the CSS had vanished, leaving me with a very bare and broken-looking site.

The problem turned out to be caused by Drupal's "calendar popup" module, and disabling that module seems to have returned everything to normal, but of course now I don't have a calendar popup on date fields. Very frustrating...

Geeky Drupal-related bootnote: 'HTTP status request fails' - fixed

I've been having a problem for the last couple of weeks with the Drupal website I've been working on where the webserver couldn't resolve any external URLs, which meant that the website couldn't check for updates, send e-mails, or access anything on the internet because it couldn't resolve web addresses through DNS.

Syndicate content