Since I installed the last update, in admin/reports/updates/list there is an ongoning warning that I should install 6.22. I have done so several times but the message keeps appearing.
In sites/all/modules I also have a a drupal-6.20 folder. I tried removing this folder but then I get a fatal error. After restoring from backup the problems remain. My site is functioning normally apart from the question to download 6.22 again.

Marijke

Comments

urbanus’s picture

urbanus commented
Status: Needs work » Active
dpearcefl’s picture

dpearcefl commented

What version shows in the status report (/admin/reports/status)? What is the fatal error message you get when you remove this subfolder?

dpearcefl’s picture

dpearcefl commented
Assigned: urbanus » Unassigned

You don't assign things to yourself unless you are taking responsibility for solving your own problem.

urbanus’s picture

urbanus commented

@ dpearceMN:
Version 6.20

fatal error message: Well I do not want to reproduce this at this time, yesterday the site was published for my client so I do not want any downtime right now.

What do you mean bij your last remark .... ?

Marijke

dpearcefl’s picture

dpearcefl commented
Status: Active » Postponed (maintainer needs more info)

If you don't want to help me help you, I'm going to postpone this issue. After a certain number of days, I will close this ticket. Sorry, but resources are limited.

"You don't assign things to yourself unless you are taking responsibility for solving your own problem."
When you opened the ticket, you assigned the ticket to yourself. That field is used to select a person who is volunteering to resolve your issue. So you (who is reporting the problem and by definition unable to resolve the issue) assigning yourself (to resolve the issue) doesn't make sense.

urbanus’s picture

urbanus commented

I'm very sorry, this is the first time I reported an issue and I did not know I made this mistake. By the way when I look at the field "Assigned" it says "Unassigned". Ofcourse I want help, otherwise I wouldn't have start the issue. So, again: I apologize for not following the rules. What do you want me to do, do I have to report a new issue?

dpearcefl’s picture

dpearcefl commented

No you are reporting this problem the right way. But if you are not able to work on this problem now, we can't help you.

If you want to answer my questions in #2, we could get a little further down the road.

heine’s picture

heine commented
Status: Postponed (maintainer needs more info) » Closed (won't fix)

This is not a bug; you have 6.20 modules installed, and those are used.

What you need to do is to restore the original installation on a test server and then

- remove the drupal-6.20 directory from sites/all/modules
- go into the database and edit any paths of modules and themes in the table system that point to sites/all/modules/drupal-6.20/[etc] to [etc] alone.

eg for the node module change

sites/all/modules/drupal-6.20/modules/node/node.module to
modules/node/node.module

urbanus’s picture

urbanus commented

Hello,

The fatal error message is:
"Fatal error: Call to undefined function user_access() in ...../sites/all/modules/admin_menu/admin_menu.module on line 82"
I was able to reproduce it by renaming the directory ..../sites/all/modules/drupal-6.20 for a few seconds.

I may try Heine's possible solution tomorrow, thank you for it.

Marijke

urbanus’s picture

urbanus commented

Solved (finally).
Solution:

- make a copy of the drupal-6.20 directory from sites/all/modules to your desktop
- remove the drupal-6.20 directory from sites/all/modules
- go into the "system" database and edit any paths of modules and themes in the table system that point to sites/all/modules/drupal-6.20/[etc] to [etc] alone. (33 entries)
- also edit any left 6.20 to 6.22 (33 entries)
- run update.php

This is a bug, but you can fix it yourself.

Marijke

urbanus’s picture

urbanus commented
Status: Closed (won't fix) » Closed (fixed)
Cyberflyer’s picture

Cyberflyer commented

I have Drupal 6.22 core code in place and ran all the update procedure as usual.

The status report says I am not secure and the Updates Available page says I am running 6.19.

I know that is not the case but Drupal does not. There are also bugs along the general line of 'unable to access' various modules, which are clearly there.

Nothing has changed from my installation, other than the update to 6.22.

There is no "drupal-6.20 directory" in sites/all/modules.

And I can find no paths in the System table of the DB with 6.20 in the name or info fields.

So I can't make sense of the 'fix'.

What am I missing?

This is driving me nuts.

Cyberflyer’s picture

Cyberflyer commented
Status: Closed (fixed) » Active

This is not fixed. At least not on my system.

Has anyone found a fix that will work?

heine’s picture

heine commented
Status: Active » Closed (won't fix)

There's no bug here.

brian_c’s picture

brian_c commented
Title: Cron keeps asking for 6.22 after 5 times installing 6.22 » Drupal not recognizing core update
Status: Closed (won't fix) » Closed (works as designed)

(Edited title as I think this will show up better in search results, also I think "Works as designed" is more appropriate here than "Won't fix")

I just ran into this too, I needed to fix a site that had been upgraded improperly; someone had copied all of the core modules into /sites/all/modules. (So I had sites/all/modules/block, sites/all/modules/blog, etc etc)

This makes it impossible to actually update core, as the older core modules in /sites/all/modules will take precedence over anything in /modules (this is a feature that allows users to cleanly override core modules, if necessary, without hacking the originals)

So to fix this situation (essentially a generalized re-stating of the steps in #10 above):

  1. As always, backup your files and DB first.
  2. Next, make sure you have updated all core files to latest.
  3. Now you need to delete all core modules (anything that exists in /modules) from /sites/all/modules. These may be in there directly, or in a subfolder like "drupal-6.20" or something else. THIS WILL COMPLETELY BREAK YOUR SITE TEMPORARILY.
  4. Each of these modules has a record in the system table, and both the filename and the version need to be corrected (normally Drupal would update this stuff automatically, but it's completely broken right now due to deleting where it's currently loading the core modules from). Since updating all 33 records by hand is a gigantic pain, here's a query to do it:

    UPDATE system SET filename=REPLACE(filename,'sites/all/',''), info=REPLACE(info, '6.8', '6.22') WHERE info LIKE '%6.8%' AND filename LIKE 'sites/all/modules/%'

    (you'll of course need to replace '6.8' and '6.22' according to the specific versions you are dealing with)

  5. The routing tables are still broken, this can be fixed by running update.php (which will also apply any pending DB updates)
  6. Site should be properly upgraded and running normally now.