By mhawker on
Status Report is listing all the modules I need to update like it normally does. I've downloaded then uploaded (FTP) the updates to the correct place, but when I run update.php it doesn't recognize any module updates (upgrading 0 of 0). This is the way I've always updated modules, never had a problem before.
Before trying to update my modules I updated from 6.19 to 6.20. Status report lists this correctly. The site seems to be working fine, update.php isn't listing any errors, but this can't be good. How do I approach fixing this?
Comments
Not all updates require
Not all updates require update.php to be run. update.php is used for database updates, and sometimes modules only update the code and don't change the database at all. If you aren't seeing anything, it probably means that no database changes are required.
If you feel like a specific update hasn't been performed, backup your database, then manually select that update on the second page after going to update.php.
Contact me to contract me for D7 -> D10/11 migrations.
I can try manually updating,
I can try manually updating, just need to figure out which version to pick, it's not obvious to me.
But, even if a database update isn't needed, shouldn't the Status Report stop reporting the need to update a module? I've uploaded module updates, but my drupal installation isn't registering it.
Yes, it should stop reporting
Yes, it should stop reporting a need to update. Although I believe it will not report the need for an update if you have uploaded the files but not yet run update.php, so it sounds to me like you have maybe improperly uploaded your files.
Contact me to contract me for D7 -> D10/11 migrations.
I've re-downloaded then
I've re-downloaded then re-uploaded the module updates about half a dozen times now. Nothing seems to indicate the the modules have been uploaded improperly. Strange things is, I've uploaded new (not used before) modules and those show up in the modules list ready to be activated.
One of the module updates is views 2.12, I'd think it would require some modification of the database that update.php would detect?
I'm trying to tread carefully and be patient so I don't really screw things up. Anymore ideas?
All I can say is that you
All I can say is that you need to make sure you are uploading them to the same place as you are looking at. Maybe you are uploading the files to a different installation than the one you are looking at. Or you are looking at a local installation and uploading the files to a remote installation.
If the files are uploaded, then the page you are looking at won't show them as not being uploaded. You need to figure out where you are going wrong. The site isn't going to show the files as not being uploaded if you have uploaded the newest version of the files.
Contact me to contract me for D7 -> D10/11 migrations.
I am uploading the modules to
I am uploading the modules to the correct place. I know this because each upload is successful and any new modules I add (as a way of testing) appear in the modules list ready for activation. The existing modules listed still show the previous version, even though the new version was uploaded. Update.php doesn't show any updates, but Status Report continues to list all the modules I'm trying to update.
The modules I'm trying to update to include: backup_migrate 2.4, views 2.12, image 1.1, captcha 2.3, imagefield 3.9, and 4 more. Shouldn't update.php register something on at least a few of these? In the case of views, the manual update lists: 6000, 6001, 6003, 6004, 6005, 6006, 6007, 6008, 6009. Which would be right?
In short, it is doing exactly what you and I know it shouldn't do and that's why I'm posting for help. Not sure where to go from here.
You were right
But I wasn't completely wrong... I finally decided to just delete all the modules that weren't updating and re-upload rather than overwrite, like I usually do. I decided to do this through the cPanel File Manager (not my usual way). In going about selecting the modules I came across a folder named "modules".
I use Coda for editing locally then uploading, if you're editing a file it doesn't matter where the built-in ftp is pointed to, but if you're uploading folders your remote location has to match your local location. So at some point (I assume) when I thought I was uploading a module or two I must have actually uploaded the entire modules folder to the modules folder. Drupal then started looking at this folder rather than the top-level modules folder (modules/modules). That's the only explanation I can think of, feel like an idiot at this. Live and learn.
Crappy! That's a bit of a
Crappy! That's a bit of a head scratcher. Glad you figured it out. Turns out I was right, but looking at it the wrong way. I said that you had to make sure you were looking at the same place you were uploading the modules to (which was right, as you weren't), but I didn't realize that the place you were looking at wasn't where you were expecting it to be.
Glad you got it figured out.
Contact me to contract me for D7 -> D10/11 migrations.
" I finally decided to just
Well, actually you're supposed to do it this way.
Glad that you got your problem resolved though!
Just so nobody elses falls like I did...
...I have a local copy of the website files, with a local Drupal installation running OK. When it is time for updates:
* I first get a recent backup copy of the live site,
* I load it in my local installation,
* I do the update locally, moving obsolete module directories out of the Drupal installation, unzipping the new module versions in the right place and running update.php
and, after everything is right,
* I put the live site into maintenance mode,
* I upload the files using rsync,
* I run update.php in the live site,
and if everything is right, both sites should end with the same update status (hopefully green). But I run into the same problem and I discarded the overwrite thing because I assumed rsync took care of removing old files, adding new ones and replacing modified files in the modules. Wrong, I've just moved the module directories out of the Drupal installation also in the live site, re-run rsync to upload missing module files and re-run update.php and everything is OK now.
So, don't blindly trust rsync or similar tools if other hints in this topic don't help. :-)
Same thing here
I have the exact same problem.
I've looked around, I don't think I have a 'modules' duplicates. Still, even if I rename the specific modules' folders, they still show up in the modules list (with the old version).
It only happens for CCK , Date and ImageAPI - for other modules update worked!
I there a way to find out where Drupa thinks a specific module is located at?
...a bit later that night
Ok, so I realized what happened (took about 2 nights!)
For some reason I had backed up the previous versions of the modules I was going to replace in a folder in sites/all/modules named 'z old modules'.
But Drupal, in its higher wisdom always looked there instead of getting the newest versions installed in sites/all/modules
it would consider sites/all/modules/z old modules/cck instead of sites/all/modules/cck!!
I was lucky to get and pay attention to an db update error and see the path
sooo funnny. not.
I know you've already figured
I know you've already figured this out, but for future reference, you can find out the path at which Drupal expects the module to reside by looking in the {system} table of the database.
Contact me to contract me for D7 -> D10/11 migrations.
I had the same problem
I had the same problem. What I found is if you use the link from reports update page to down load the updated module for some reason it is not downloading the correct file. If you go to the Module's home page and down load it from there it will work fine.