Update from 7.x-1.2 to 7.x-1.5 => PHP Fatal error: require_once(): Failed opening required

I had the same problem i just used hook_update_dependencies() to update entitycache first and that fixed it for me.

I know this is not a good solution but it worked to update everything

Did you try running the database updates after downloading the newer module?

temporary manual fix:

you can copy everything from entitycache/includes folder to entitycache folder

this will prevent the error and will allow you to update the other modules correctly

you should than uninstall entitycache, manually delete the folder from your ftp and than install it again the latest version.

Same issue here on Drupal 7.41, updating entitycache from 1.2 to 1.5. Temporary manual fix in #5 changes the fatal error to
Fatal error: Class 'EntityCacheControllerHelper' not found in entitycache/entitycache.taxonomy.inc on line 47

I could solve this only by downgrading entitycache to 1.2.

After DB-Update:

require_once(<PATH>sites/all/modules/contrib/entitycache/includes/entitycache.comment.inc): failed to open      [warning]
stream: No such file or directory bootstrap.inc:3211
PHP Fatal error:  require_once(): Failed opening required '<PATH>sites/all/modules/contrib/entitycache/includes/entitycache.comment.inc' (include_path='.:/usr/share/php:/usr/share/pear') in <PATH>includes/bootstrap.inc on line 3211
Drush command terminated abnormally due to an unrecoverable error.                                                                          [error]
Error: require_once(): Failed opening required
'<PATH>sites/all/modules/contrib/entitycache/includes/entitycache.comment.inc'
(include_path='.:/usr/share/php:/usr/share/pear') in <PATH>includes/bootstrap.inc, line 3211

(Drupal 7.41, Entitycache 7.x-1.5)

Solution:
cd MODULE_FOLDER
ln -s . includes
drush cc all
rm includes

@Matroschker: Are you able to log in as user 1 and load the admin/modules page? That may perform the same fix, but I've not tried it.

Without drush, you can use https://www.drupal.org/project/registry_rebuild

The problem is that Drupal 7's classloader is very brittle and does not deal well with files moving.

Unfortunately the upgrade issue was introduced by files being moved in order to solve a different problem with class loader brittleness. So there should in the end be less brittleness, once people have managed to upgrade.

I've added additional instructions to the release notes: https://www.drupal.org/node/2602352

Moving this to documentation, this is really a core bug, so I re-opened #2097189: Add a rebuild script for backport to Drupal 7.

@Matroschker: the best solution is to use registry_rebuild vom command line:

download http://ftp.drupal.org/files/projects/registry_rebuild-7.x-2.2.tar.gz in your modules-folder and untar
cd registry_rebuild
php registry_rebuild.php

see: https://www.drupal.org/project/registry_rebuild

@Matroschker: Strange. Please try to run the registry-script two or three times times.

Same problem here, updating from 1.12 to 1.15.

drush rr fixed it and allowed me to complete the updb.

[EDIT] Same site, re-running update on a different server required running the registry rebuild 5 times.

I do not have command line access. How else can I fix this issue?

@hockey2112 the latest -dev tarball has a workaround for this issue.

If you try that, you shouldn't need the registry rebuild.

I'll likely tag a new release once that's been confirmed as working.

Latest dev still produces the same errors for me.

We have the same problem as @ibullock; latest dev still produces the same errors. I agree with @catch that this is a core bug. But because I suspect #2097189: Add a rebuild script will require a big effort - if possible at all - to backport to Drupal 7. Instead, I choose to support #412808: Handling of missing files and functions inside the registry to throw warnings instead of fatal errors when the old include files can not be found until entitycache_update_7003() can run and Drupal's registry gets updated.
With that change, the patch from #2441965: Broken updates due to Classes living in .module files, that got into 7.x-1.x-dev, is redundant.

That's how we succeeded updating from 7.x-1.2 to 7.x-1.5

Let me explain the easiest workaround to get going what several users mentioned as the drush approach.

Disable the entity cache module without a Drupal bootstrap in the database:

Using drush this can be easily done by

drush sql-cli

or you enter MySQL the way you usually do and type

UPDATE system SET status = 0 WHERE name="entitycache";

exit

Then enable the entitycache module again using the regular Drupal module activation methods (like on the admin/modules page). With drush:

drush en entitycache

Do also enable all modules that may had dependencies on entity cache in case they have been disabled by the system. Then continue your database update process:

drush updatedb

It should run normally then.

I'v faced with the same error using registry rebuild too by drush.
See screenshot https://gyazo.com/81a77de8288450f7dce964182f0b4470

Steps from comment #14 helped me

@catch What you think about adding this steps to release page?

Just ran into this error for the first time. #14 worked for me since I don't have access to drush on this site. I just ran this after I uploaded the new files, but before I ran the database updates. Took away the errors and the site loaded fine.

So if you're like me and don't have access to drush, but can do command line, those instructions work great.

The query from #24 helped me, and I haven't seen any side effects.
( UPDATE system SET status = 0 WHERE name="entitycache"; )

Lots of great discussion and ideas in this thread. I believe there are a few other issues in the queue on this topic so it seems OK to me to close this issue.