Warning message regarding hook_update_last_removed() is not displayed

I think the original bug has been fixed because I don't get such a error.

However, the *actual* warning message is not displayed at all because the definition is completely wrong, there is no such thing as an #item property.

The attached patch attempts to fix this but it stills looks a bit ugly... help is welcome. See before/after screenshots.

I think this classifies as major because the hook is pretty much useless as of now. You only get a message that something is wrong but there is no way to to even tell which module is outdated.

Note: There is a huge mess in update.inc and update.php, many strings are just pasted together and are not using t() at all. I did not attempt to fix this.

PS: Screenshots will follow in separate comments, uploading multiple files is totally broken right now...

The patch..

Before...

Wrong file, real before...

And after applying the patch...

I like the "after" much better :)

Oh ... and the patch in #4 looks good to me.

Wow, at the rate it finds weird bugs, we might just have to move privatemsg module into core for D8!

(I kid, I kid...)

Can we do this without this change?

+        '#title' => $module . ' module',

Because that should really be written as st('@module module') and that would break strings.

Oh lucky you. ;) You get a pass because user module uses '@module module' on the permission page.

Nevertheless, we need that wrapped in t() methinks.

Hah, I was actually surprised that nobody else noticed/tested this (or care enough to open an issue/write a patch). hook_update_last_removed() is a must for every module that is upgraded from 6.x and removes update functions...

Regarding the string, I know it's wrong. The reason I did it like this is that it's the same just a few lines below for normal entries:

      $form['start'][$module . '_updates'] = array(
        '#theme' => 'item_list',
        '#items' => $update['pending'],
        '#title' => $module . ' module',
      );

The problem is that there are tons of such untranslatable strings in update.php and update.inc, for example the hook_update_last_updated string is just pasted together too:

      $last_removed = module_invoke($module, 'update_last_removed');
      if ($schema_version < $last_removed) {
        $ret[$module]['warning'] = '<em>' . $module . '</em> module can not be updated. Its schema version is ' . $schema_version . '. Updates up to and including ' . $last_removed . ' have been removed in this release. In order to update <em>' . $module . '</em> module, you will first <a href="http://drupal.org/upgrade">need to upgrade</a> to the last version in which these updates were available.';
        continue;
      }

Since this is a new feature in D7, I don't understand why this was ever commited like this :)

Not sure what to do, your call... :)

Dear lord.

Well we might as well fix the one you're touching now and file a follow-up bug for the rest. I can't imagine why that isn't wrapped in st(). I guess maybe a trip to CVS annotate is in order.

Ok, the string was added in #194310: Check / run updates of disabled modules and t() was explicitly *not* used, see #194310-112: Check / run updates of disabled modules. No idea *why* t() can't be used, maybe that is outdated somehow now.

Maybe Gabor can explain to to us why and if that is still true.

One way or another, this needs to be fixed I think (either remove all t() calls or add them).

Two reasons to not use t() in updates:

1. The database under t() might have changed as well. We try to avoid calling API functions because we don't know their underlying database / data structure is already in the form they expect it. In Drupal 6 -> 7 the context column is added to the database, so for example, if a t() in update uses context, but the locale update did not run yet, it will break in an invalid SQL query.

2. Drupal still works with the (the outdated) translations from the previous version. Translations for the new version are not yet loaded. In fact, Drupal itself will only load .po files on module install not up update (to avoid overwriting your customizations to translations). The contributed http://drupal.org/project/l10n_update module covers tracking your customizations, so it can import .po files for updated modules and themes. Anyway, using t() in most of the updates is pointless as well, since the new translations are not there, so a t() you use in an update function for example will not have translations loaded yet by definition. (This can be solved in l10n_update by loading translation updates before running module updates, but (1) is still a possible problem even in that case).

Setting back to review, as I'm not sure if this needs a re-roll or not. According to #13, t() shouldn't be used in the update process, but...

1. The context column is added in http://api.drupal.org/api/drupal/includes--update.inc/function/update_fi...

2. This is not only about the 6 -> 7 upgrade path. In fact, it is primarly about contrib updated which follow later on. At this point, it is very possible that the new strings are available. Especially the warning message contains important information which might be hard to understand for those that don't understand english (well). On the other site, it is impossible to translate everything because the update descriptions are extracted directly from the source code and are therefore impossible to translate.

I am not sure..

It seems we've gotten away from the thrust of this problem, as per #1 "there is no way to to even tell which module is outdated."

I'm just upgrading a site from D5. I get the dreaded "Some of the pending updates cannot be applied because their dependencies were not met." and don't know if it's core or contrib. Not sure where to start chasing down the problem.

I can't find anything yet in admin/reports/dblog and haven't dug through the apache logs yet. However, I know that Drupal can give better results for failure to improve the experience.

i just ignored it and D7 is mostly working except if a node has an associated menu item it seems to get deleted when I save it. Also, none of the toolbar menus are showing up. I can see the shortcuts, can navigate everywhere by manually sticking in the URL, but there seems to be something wrong with the menus.

I commented on a bug mentioning the error message which was closed fixed, and that bug was subsequently marked as a dupe of this one. So here's the main part of my comment from there:

I've got a Drupal 5.23 site I'm attempting to update to Drupal 7.0. I'm staging the update on an alternate copy so I can revert to a copy of the production site and start over at any time to help test it. I'm upgrading from 5.23 to 6.20, running all updates on 6.20, then updating from there to 7.0.

As mentioned in the comments above, the Webform module appears to be at fault. Removing that module makes the error go away. However, the update system is still not giving any indication what the unmet dependencies are, or even which module is claiming it has unmet dependencies. Tracking down the errant module is quite difficult without at least an indication of which module is reporting the error. There's not even a log entry that I can find (and if there was something in the log, the error message should link to the log viewer for more details).

I've since discovered that the Webform module had a feature branch update during D6. The available updates page didn't flag it as needs update, because I was at the tip of the older feature branch. However, the D7 module only upgrades from the newer feature branch from D6. It shows up under the "Also available" tag under the "up-to-date" listing for Webform on D6. Upgrading the D6 module to the newer feature branch before continuing to D7 got rid of the error in D7.

umm, didn't mean to change the component there, apparently the one it used to be doesn't exist anymore. I'm guessing "update system" became "update.module" and setting it there.

Not sure what happened with the update system (upgrade.php basically) component, that is imho not the same thing as update.module (which is the module that looks for module updates and can install them).

Anyway, can you please try the attached page with your old setup and see if it shows up correctly?

@#15: The associated menu thing is not related to this, you need to enable these menus in the node type settings. There are issues open about that already I think...

@Berdir: It was renamed to 'database update system' at dww's request. I forget which issue it happened in.

Confirmed, with the patch in #4 applied and my D6 database restored to a version that still had Webform 6.x-2.10 in it (rather than 6.x-3.6), I get this on the D7 upgrade inside the "pending updates" section if I expand it:

webform module:
webform module can not be updated. Its schema version is 6205. Updates up to and including 6313 have been removed in this release. In order to update webform module, you will first need to upgrade to the last version in which these updates were available.

Without the patch, I get nothing (except the "Some of the pending updates cannot be applied because their dependencies were not met." message at the top).

*I* knew I should expand that section to be thorough, but the "cannot be applied" message at the top should probably say that you need to expand the pending updates section for details, otherwise a lot of people may never look there and still be confused.

If you don't expand the pending updates section before running the update, and run it anyway, there is no message on the results screen to indicate the problem either (may not be an issue), *but* if you go an run update.php again (because the status page says you still have updates to apply), you only get the "Some of the pending updates cannot be applied because their dependencies were not met." with "No pending updates" right underneath it. So if you fail to expand the Pending Updates section to read it on the first pass, the indication of which module is at fault is still missing if there are no other available updates pending to be run at the same time.

Apply the patch and try again. It should then print which modules are the problem. There might be others too.

Note that you don't need to uninstall them, it should work fine if you update them to the most recent version.

I just started having this issue too after installing webforms. I upgraded from D5 to D7 and everything's been going swimmingly until I tried to install webforms. Status report says I have updates available but I get the "dependencies were not met/no available updates" message when I run update.php. I tried to install the patch, but I don't get any extra explanation in my error messages. I also don't see a list of pending updates. I'm 97% sure I'm soing something wrong, but I can't figure out what. Any help/suggestions?

@pthite: You need to go back to D6, and upgrade the webforms module there to the most-recent version (it's an optional update, not a security update, so it'll still show green in the status page, you have to pick it from the "Also available" link underneath). After that upgrade is done, then you can upgrade to D7 and it'll upgrade properly.

Ack! I thought I was getting close to done with this upgrade! Thanks for the help. (I also did finally get the detailed error message; just needed another update to download).

Moving to the 8.x queue and tagging for possible backport.

+subscribing

subscribe - I'm having this issue in 7x despite starting with 6x core and never having had 5x. Would love to put it behind me.

starminder, have you tried the patch at http://drupal.org/node/834848#comment-3823174 ?

If you're not familar with patches, there are instructions at http://drupal.org/patch/apply

That should then give you a useful error message, and you can find the module that's causing the error.

Thanks Catch! This is my first patch using cygwin so bear with me. Am getting "missing header for unified diff at line 5 of patch" so I'm not convinced I'm doing it right. Is the syntax different for a core file vs. a module? (I know this isn't the place to learn to do patches, but would be really helpful to know if it is working or not).

I used patch update.php < display_last_updated_warning_1.patch -p1 in cygwin. Do I need all of core in there for this to work or just the file to be changed?

In any case, I still get the same bloody generic message on the "Review Updates" page: Some of the pending updates cannot be applied because their dependencies were not met. No pending updates.

Try

patch -p0 < http://drupal.org/files/issues/display_last_updated_warning_1_0.patch

instead. It shouldn't be necessary to specify update.php, and this patch predates the git migration so applies with p0 instead of p1.

This is as good a place to learn how to do patches as any, million times better than posting 'subscribe'. If you can get into #drupal-contribute on freenode that's better for realtime help though.

Edit:

It works! :) My (possibly not unique) additional issue was a Notice: unserialize() [function.unserialize]: Error at offset 44 of 45 bytes in variable_initialize() (line 748 of includes/bootstrap.inc) described in #1114304: unserialize: Error at offset 446 of 23435 bytes in variable_initialize() . I had one of those left and a bunch to choose from as to what was causing it. (dang ubercart). Once I got rid of that, this now displays properly.

So now....drumroll please...here is the offender:

1 pending update
performance module

    7001 - Harmonize notations for milliseconds to "ms". @return array

xmlsitemap module xmlsitemap module can not be updated. Its schema version is 6151. Updates up to and including 6201 have been removed in this release. In order to update xmlsitemap module, you will first need to upgrade to the last version in which these updates were available.
xmlsitemap_taxonomy module xmlsitemap_taxonomy module can not be updated. Its schema version is 6113. Updates up to and including 6198 have been removed in this release. In order to update xmlsitemap_taxonomy module, you will first need to upgrade to the last version in which these updates were available.

Edit: Found this #953846: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table xmlsitemap_sitemap doesn't exist , working on it...
Edit: Got XMLSitemap out, now this #1054104: Update failure: performance module Update #7001: DatabaseSchemaObjectDoesNotExistException

OK, removed that and no more pending updates. Thanks for the patch and the instructions, I learned a lot!

Now...my remaining concern is schema showing a bunch of mismatches on core stuff. Ugh.

Marking #4 rtbc again six months later. Agree that t() should not be used in update functions. Please open core issues for each schema module discrepancy, I'm not sure if schema module was ready when we released, even if it was I'm pretty sure no one did that test.

@catch - will do re: schema mismatches

When trying to apply this patch, I get the following error on both 7.x and 8.x:

deimos:drupal-head dries$ git apply ../f.p 
fatal: git diff header lacks filename information when removing 1 leading pathname components (line 5)

Investigating that now.

Here is a re-roll that seems to work. However, let's see what the testbot(s) say.

Committed to 7.x an 8.x. Thanks!

Even after this fix is applied, there is still a situation where error messages can be generated, and not displayed: If there are modules that haven't set their schema version properly, a message is generated but not displayed *unless there is ALSO a schema update that needs to be applied*.

I have raised #1159160: Error messages from update.php sometimes hidden.