By slazenger on

**** I posting an upgrade issue here, discussed in http://drupal.org/node/56107. This problem is also happening with upgrading to 4.6.5 and hence I am escaling it to a new post and it has new details also ****

Folks,

I had a running system for a new site using 4.6.3. I copied it to a test site and got that up, as part of getting it ready for upgrade to 4.7RC3. To be safe, I thought I'd upgrade this to 4.6.6 first and then move it to 4.7. To make the upgrade to 4.6.6, I use the "Upgrading from 4.6.3 to 4.6.5" page here: http://drupal.org/node/41534

Everthing seemed to have gone all right, except all the teasers from the front page are GONE.
They come back ONLY when I log in as site admin. None of the already published, promoted teasers are visible to anonymous users or when logged in as a regular user. Likewise, the teasers on the category/term pages (all public) are not showing up. I get a 'there are no posts' message there.

All this, even though public teasers are listed there in the current 4.6.3 installation. I then downgraded this to 4.6.5 thinking this may be an issue in 4.6.6, and that did not work either.

Can anyone advise? Any help appreciated.

⋅ Categories: Drupal 4.6.x

Comments

slazenger’s picture

slazenger commented

To add: the PHP version on both the test site and the regular site is 4.4.2.
They are identical environments as far php, apache, and mySQL are
concerned.

-S

slazenger’s picture

slazenger commented

The problem was avoidable had I been more rigorous in my update.
After creating a replica of the site (4.6.3) I had disabled organic
groups, and then migrated to 4.6.6.

I assumed that because I had disabled og, the new node.module
file that came 4.6.6 will work, (og requires a node_access patch
to be applied to node.module, and I had made this change in my
4.6.3 node.module.)

That's when the failure (of all public teasers not being displayed)
happened. I compared the node_access tables between my running site
and new test site for a given node whose access was being denied,
and found that the DB entry itself was identical - i.e. no corruption.

The FIX: I suspected by og installation had something to do with this,
and a) made the og patch to 4.6.6 node.module, b) enabled organic groups,
and c) went into og settings, and did an explicit disable/enable.

That fixed it.

I think the problem is that disabling og in Drupal does not automatically
mean that node_access related changes voided. I still don't have a
clean hang of this, and still glad I fixed it though.