Problem

I got the forementioned error trying to install the module. Marking as "Critical" as it prevents module installation.

Reason

According to https://www.drupal.org/node/542202#files , files[] autloading only works for enabled modules.

Solution

I am going to provide a patch, that adds manually requiring of all needed files.

Comments

PatchRanger created an issue. See original summary.

PatchRanger’s picture

PatchRanger’s picture

Status: Active » Needs review
perignon’s picture

Status: Needs review » Postponed (maintainer needs more info)

Can you give me the steps to reproduce this error and a description of your environment? I've installed this module many times and never saw this problem nor has it ever been reported. To be sure I just did an installation of Storage API against a clean Drupal 7.41 fresh install and I cannot replicate this error.

PatchRanger’s picture

@Perignon PHP 5.6, Drupal 7.41, Storage API 7.x-1.8+18-dev (datestamp = "1446678243"). I was installing the module via drush - and the problem persists: I've uninstalled & re-run the installation. Could be drush issue, as it seems it doesn't parse files[]-requirements, what do you think?

perignon’s picture

@PatchRanger I use Drush too. I have special scripts to testing all of my modules I maintain that allows me to install a vanilla Drupal and the modules at one time. So I don't think that is it.

This is just a weird problem because it should be something that a lot of people are reporting if it really exists. The files[] loading doesn't matter because the module does not create field instances on install.

Status: Postponed (maintainer needs more info) » Needs work

The last submitted patch, 2: 2628920-storage_api-fix_error_during_installation.patch, failed testing.

PatchRanger’s picture

The files[] loading doesn't matter because the module does not create field instances on install.

Correct about field instances - but the issue is about StorageClass, which is not found during installation. And the patch fixes the issue in my case by manually requiring necessary files. Here is one-liner to reproduce - it totally works in my case (I've checked twice):
drush dis storage -y && drush pm-uninstall storage -y && drush en storage -y

perignon’s picture

And if I do the same commands. I get no errors related to the storage class problem.
No errors on install

Tested on AWS Linux, Fedora 21, and Mac 10.10 (via Homebrew). Running PHP 5.5 and 5.6.

You can also launch an install here: https://simplytest.me/project/storage_api/7.x-1.8

Has the PHP.ini been altered? Also, you did not mention which OS you are running.

I do believe the issue is specific to your installation and environment. This type of issue, there would have been many other people reporting problems and it should be very easy to replicate it as well.

EDIT: This is Drush 8.x

jonhattan’s picture

Which version of drush are you using?

PatchRanger’s picture

And if I do the same commands. I get no errors related to the storage class problem.

As I could see, the use-case was not fully reproduced as there was no uninstallation of storage module before running drush en. Please try this one:
drush dis storage -y && drush pm-uninstall storage_core_bridge -y && drush pm-uninstall storage -y && drush en storage_core_bridge -y
I've managed to reproduce it once again: it fails without the patch & works within.

Has the PHP.ini been altered?

max_execution_time and memory_limit were increased - that's it.

Also, you did not mention which OS you are running.

Sorry, missed it: Ubuntu 14.04.

Which version of drush are you using?

I thought it is Drupal-major-version-specific, isn't it? I am using Drush 7.x.

perignon’s picture

Drush is not major version specific anymore. Drush 8.x works on Drupal 8 and Drupal 7. Drush 7.x does not support Drupal 8 though. For the hell of it, try upgrading to 8.x. If you use composer it is easy.

Still no error even when I enable the core bridge module.

So no changes to PHP.ini.

PatchRanger’s picture

I am sorry to report - but it didn't help either.
Here's what done:
1) sudo composer self-update: Successful.
2) Changed drush version to 8.x in ~/.composer/composer.json
3) composer global update: Successful.
4) drush version: Displays 8.0.1.
5) drush cc all: Successful.
6) Running drush dis storage -y && drush pm-uninstall storage_core_bridge -y && drush pm-uninstall storage -y && drush en storage_core_bridge -y leads to the same error.

For now it's clear that it is totally my own issue which is very much specific to my installation and environment - but I have no clue what could be the reason, have you? Anyway thank you for your time and attention - and for the great module!))

perignon’s picture

Next thing to do is to check the PHPinfo report. The only possible thing I can think of is the PHP.ini while unchanged has something different in it from the vendor. I am assuming it was installed with apt-get from the main Ubuntu repo?

PatchRanger’s picture

I am assuming it was installed with apt-get from the main Ubuntu repo?

Correct. I've checked phpinfo() report and found no eye-catching anomalies.
That is neither urgent nor important as I can workaround it and it is just one-time issue - so I am going to just leave it. Again, thank you for the help! Good luck with further developing!

jonhattan’s picture

As a last resort I think it may be a filesystem permissions issue.

perignon’s picture

Status: Needs work » Closed (cannot reproduce)

Thanks for at least documenting this none-the-less. Might help someone else out having the problem in the future. Wish we knew what causes it though.

PatchRanger’s picture

My error is still present for unknown reason.
That's why I am updating the patch.
Not re-opening as it is not reproducable anywhere besides my environment and in fact is useful only for my make-file.
Nonetheless.

perignon’s picture

Thanks for the update!

mrP’s picture

Not sure why, but I was running into this issue as well. Tried the patch in #18 and was able to enable/install without errors. Thanks @PatchRanger

FWIW, I'm running this under a multisite configuration with the module installed at sites/example.com/modules/storage_api

mrP’s picture

Just a follow-up, the module location was causing the installation error in my case. Moving the module to sites/all/modules prevents the install problem without any patch.

mrP’s picture

Re-rolling patch against latest dev snapshot and new storage.test filepath.

dureaghin’s picture

I was running into this issue as well. Patch # 22 works for me. Thanks.