Closed (cannot reproduce)
Project:
Storage API
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Dec 2015 at 14:20 UTC
Updated:
21 Mar 2017 at 20:45 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
PatchRanger commentedComment #3
PatchRanger commentedComment #4
perignon commentedCan 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.
Comment #5
PatchRanger commented@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?
Comment #6
perignon commented@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.
Comment #8
PatchRanger commentedCorrect 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 -yComment #9
perignon commentedAnd if I do the same commands. I get no errors related to the storage class problem.

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
Comment #10
jonhattanWhich version of drush are you using?
Comment #11
PatchRanger commentedAs 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 -yI've managed to reproduce it once again: it fails without the patch & works within.
max_execution_timeandmemory_limitwere increased - that's it.Sorry, missed it: Ubuntu 14.04.
I thought it is Drupal-major-version-specific, isn't it? I am using Drush 7.x.
Comment #12
perignon commentedDrush 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.
Comment #13
PatchRanger commentedI 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 -yleads 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!))
Comment #14
perignon commentedNext 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?
Comment #15
PatchRanger commentedCorrect. 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!
Comment #16
jonhattanAs a last resort I think it may be a filesystem permissions issue.
Comment #17
perignon commentedThanks 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.
Comment #18
PatchRanger commentedMy 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.
Comment #19
perignon commentedThanks for the update!
Comment #20
mrP commentedNot 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_apiComment #21
mrP commentedJust 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.Comment #22
mrP commentedRe-rolling patch against latest dev snapshot and new storage.test filepath.
Comment #23
dureaghin commentedI was running into this issue as well. Patch # 22 works for me. Thanks.