I have upgraded the 2.x as far as I can, yet I am still getting repeated errors like the one below. Nothing apparent in the issue queue. I didn't set up this site so I am loathe to update to 3.x without greater knowledge on this. A google search reveals plenty of similar results - all pointing to error ridden web pages :(

Please advise?

Unknown column 'drupal_term_node.nid' in 'on clause' query: SELECT COUNT(*) FROM drupal_term_node t INNER JOIN drupal_node n ON t.vid=n.vid INNER JOIN drupal_node_access na ON na.nid = drupal_term_node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 0 AND na.realm = 'content_access_author') OR (na.gid = 1 AND na.realm = 'content_access_rid') OR (na.gid = 0 AND na.realm = 'og_public') OR (na.gid = 1 AND na.realm = 'term_access'))) AND ( n.status=1 AND n.type='ed_classified' AND t.tid=181 ) in /home/******/domains/*****.co.uk/public_html/sites/all/modules/ed_classified/ed_classified.module on line 663.

Comments

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Active » Postponed (maintainer needs more info)

You really do /not/ want to use branch 2.x, which only has a few 3.x backports over the original broken multi-version code base.

Can you reproduce the problem on 3.x ?

FWIW, this specific problem results from the automatically generated count query within pager_query(). Defining an explicit count query OR reordering the join (node first, term_node second) so that the automatic access control generation performed by db_rewrite_sql() does not happily use a .nid column on whatever column comes first in the query /might/ fix this specific issue.

Did I already say you should not be using 2.x ?

niklp’s picture

niklp commented

Thanks for the update Fred, I inherited this site so it is not my initial mistake that the site uses 2.x. I will investigate this. Didn't want to upgrade without checking that it wouldn't cause me serious issues. Assume under these circumstances it's safe to go ahead! :)

Will report back.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Three weeks later, any news ?

niklp’s picture

niklp commented

No but will have in the next few days no doubt, have a note to do this.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

No problem, note that 6.3/7.3 RC2 has been released in the meantime, though. No upgrade path from 6.2, though, and it do not plan on writing one. But if you feel like doing it ... :-)

niklp’s picture

niklp commented

Woah, so... I've just updated to 6.x-3.x-RC2 from 6.x-2.x, what's going to happen? :/

Can probably just delete the ads and start again to be honest but wasn't aware of any of the above. Any info appreciated! :)

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Probably not much good after an upgrade. I would rather advise

  • writing down the categories
  • deleting existing ads
  • disabling, then uninstalling 6.2
  • deleting the directory
  • installing 6.3
  • recrete the categories
  • recreate ads

That, or - better - write an upgrade path :-) I know you can do it.

niklp’s picture

niklp commented

In the case of how I did things, rather than how I _should_ have done them (as I will do with the live upgrade), drush simply told me the module was incompatible and disabled it... is there a reasonable way to rectify this, or just "do it right next time"? I doubt it will matter that the dev version is borked, frankly.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

I think the somehow-right way to do it would be the one described at #7, and the actually right way would be to write an update hook to convert from one branch to the next.

The "incompatible" probably stems from classified.install#classified_requirements(), which makes sure both modules are not enabled at the same time, to ensure a modicum of data safety.

niklp’s picture

niklp commented

Server I'm on is only running PHP 5.1 (and I cannot change this currently) - is there anything I can do to retrofit PHP compatibility into the 3.x module or is it tantamount to idiocy/suicide/etc? I know you know I know better than this Fred, but my back's against the wall for now. It's either that or go back to 2.x...

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

5.2 is not /that/ different from 5.1, unlike 5.3. It's probably worth it to make a DB files backup, change the ed_classified.info to say 5.1 instead, and try it that way.

niklp’s picture

niklp commented

I see - is that more an attempt to stop people going up to 5.3 rather than staying below 5.2??

Thanks Fred!

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

More like an attempt to keep people off of PHP 5.1 as it is way too old to be secure these days. I use it only of 5.3 myself, probably soon 5.4.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

6.x-2.x and 7.x-2.x is now obsolete.