None of the Drupal Commerce contrib modules will install at all, at all:

This includes Drupal Commerce contrib modules such as (no particular order or significance):

- Commerce Addressbook
- Commerce Ajax Basket Link
- Checkout Page - dc_co_pages
- Commerce Ajax Cart
- Commerce Backoffice
- and others

All such drupal commerce contrib modules fail to install, even on a clean fresh drupal 7.51 sandbox testing installation, and after installing a base Commerce Kickstart installation, if the site installation didn't already install the module, none of the additional drupal commerce contrib modules will install within the site.

Notably, while spending many, many hours, extensively diagnosing this critical problem, I was able to install other - none - Drupal Commerce related modules without any problem, including:

- Devel Module
- Inline Conditions Module (needed by some drupal commerce contrib modules)
---

The failed module installations do not generate any module page UI PHP error messages or dblog error/status messages.

TO REPRODUCE:
Starting from a clean drupal 7.51 base installation, with the latest versions of the required drupal commerce dependency modules installed, sequentially install drupal commerce core modules via the modules UI page..

Install all Drupal Commerce core modules (21 of them in that group), which install correctly)

Then - check the box to enable - any other drupal commerce contrib module, and click the install button.

The software remains busy momentarily and then refreshes the module installation UI page, without any indication of the result, except that the module is no longer "checked" to indicate installed and shows as not installed in the module list.

The top of the page does not display any PHP error messages or notifications of any kind.
(see .AVI video of this behavior at the link)
The modules simply refuses to install and do not provide any feedback whatsoever regarding the reason.

The failed Drupal Commerce contrib module installation does NOT produce any dblog messages either.

However success installation of other modules not related to Drupal Commerce produce installation messages in the dblog.

---

An avi screencast video of the behavior can be downloaded from my sandboxing domain at the following URL:

http://www.nettix.net/drupal-7.51-commerce-addressbook-install-failure.avi

---
I have setup multiple online sandbox drupal websites, where this problem can be duplicated.

These test sandbox sites include:

- a base Commerce Kickstart 2 installation.

- a pure base Drupal 7.51 installation with the 21 Drupal Commerce core modules installed.

Any listed Drupal Commerce module maintainer may happily obtain an admin login and password and reproduce this problem on the sandbox test Drupal websites on my testing domain, to see the behavior that is visible on the .AVI screencast video above.

I also have pairs of .zip files with the complete mysql database and the website file system of each sandbox website, so that it can be installed elsewhere for testing and reproduction of this problem.

I have basically spent two days working to find a way past the critical roadblock. Every other drupal module at installs, even if it might have a few bugs, but when a specific category of modules all related to Drupal Commerce won't even install, this is a serious problem that needs investigation, analyze, and repair.

I will have a significant attention focused on this problem, which is a roadblock to my development of a Drupal site that includes Drupal Commerce.

Comments

sprite created an issue. See original summary.

bojanz’s picture

Category: Bug report » Support request
Priority: Critical » Normal

There's something very wrong with your server, it seems.
Naturally, I was unable to reproduce this, otherwise we'd be having a thousand open issues by now.

Which OS is your server using? Which stack? Is there anything in your error log (the server one, not the one inside Drupal)? I'm wondering if it's caused by a low max_input_vars setting inside your PHP...

rszrama’s picture

Status: Active » Closed (cannot reproduce)

I sincerely doubt this is a problem with Drupal Commerce or Drupal itself. As Bojan suggested, give it a look elsewhere, as we've never seen nor heard of anything similar. Start perhaps with your memory limit.

sprite’s picture

Priority: Normal » Critical
Status: Closed (cannot reproduce) » Active

I have found the hack workaround for the Drupal Commerce "contributed" module installation problem.

It is apparently a bug that has existed in Drupal Core for years without being fixed.

For additional information, read the following Drupal bug reports:

Drupal Bug Report - Drupal Core - Commerce Contrib Module group names with brackets (parentheses) cause problems
https://www.drupal.org/node/2665152

Drupal Bug Report - Drupal Commerce - Commerce modules get disabled randomly
https://www.drupal.org/node/2448461

The hack workaround for this serious Drupal code bug, a bug that would surely stump the average Drupal user, is that every single .info module configuration file associated with every module wherein the "package" name uses parentheses, square brackets, or braces, to name the module group (called a "package") must be edited to remove the parentheses, brackets, braces, or whatever, from its "package name".

For example, if the package line in a module's *.info file contains the text"

package = Commerce (contrib)

that line must be changed to read:

package = Commerce contrib

This *.info file modification hack must be performed on every module where the problem occurs. There are dozens of them.

This problem in Drupal Core has apparently been known for years, but nobody involved in core has bothered to fix it.

For anyone who would like to see the problem in action and to see it duplicated for themselves, I have a sandboxing site at:

http://d7.nettix.net

to which I can provide an admin login by private message so that Drupal module maintainer can observe and replicate this problem. I can restore that sandbox site's original state from backup in a matter minutes afterward, so anyone interested need not worry about any changes made to it. It is just there for diagnosing this sort of problem.

rszrama’s picture

Priority: Critical » Normal
Status: Active » Closed (duplicate)

I'm going to close this as a duplicate of the core issue and the other documentation issue. There's simply no way for us to go ensure that hundreds of modules all use the correct package name.