Document Commerce contrib install issues when the server has Suhosin

Maybe not a kickstart issue at all,

Having almost the same issue, trying to enable/disable module by the ui disables several mostly commerce_ modules. No commerce kickstart here, just custom drupal commerce installation. I confirm that Those modules can't be activated any more. If I set the checkbox and save, they remain disabled. I can only enable/disable modules by drush without side effects.

Strange thing is that in my local copy I can enable/disable modules through the UI just fine.

I did registry rebuild, but the problem remains.

Could be some kind of hardware failure? (memory, disk, etc)

I use drupal 7.33, php-fpm, PHP Version 5.4.38, FreeBSD, lighttpd, mysql 5.5.42

Also using filecache module for caching

These are my enabled modules:

admin_menu
admin_menu_toolbar
admin_views
module_filter
ajaxblocks
blockcache_alter
ctools
clientside_validation
clientside_validation_form
colorfield
commerce_cart
commerce_checkout
commerce
commerce_custom_order_status
commerce_google_analytics
commerce_ui
commerce_customer
commerce_customer_ui
commerce_line_item
commerce_line_item_ui
commerce_order
commerce_order_ui
commerce_payment
commerce_payment_ui
commerce_price
commerce_product
commerce_product_pricing
commerce_product_pricing_ui
commerce_product_reference
commerce_product_ui
commerce_tax
commerce_tax_ui
commerce_cart_expiration
commerce_cod
commerce_couponprodref
commerce_email
commerce_feeds
commerce_feeds_example
commerce_moa
commerce_fieldgroup_panes
commerce_price_components
commerce_price_savings_formatter
commerce_pricing_attributes
commerce_custom_product
commerce_paypal
commerce_paypal_wps
commerce_flat_rate
commerce_shipping
commerce_shipping_ui
commerce_coupon
commerce_coupon_fixed_amount
commerce_coupon_pct
commerce_coupon_ui
commerce_product_attributes
commerce_option
commerce_option_set_reference
context
context_layouts
date
date_api
date_popup
reroute_email
ds
ds_extras
ds_format
features
feeds
feeds_ui
feeds_import
feeds_jsonpath_parser
feeds_tamper
feeds_tamper_ui
feeds_et
addressfield
entityreference
field_group
field_group_multiple
filefield_sources
inline_entity_form
node_reference
physical
references
title
hansel
hansel_taxonomy
pathologic
htmlmail
mailsystem
void_menu
metatags_quick
entity_translation
entity_translation_i18n_menu
entity_translation_upgrade
i18n_block
i18n_field
i18n
i18n_menu
rules_i18n
i18n_string
i18n_translation
i18n_variable
back_to_top
checklistapi
entity
entity_token
faq
job_scheduler
libraries
pathauto
redirect
token
transliteration
variable_email
globalredirect
filecache
rules_conditional
rules
rules_admin
greekstemmer
page_title
wsclient
wsclient_soap
honeypot
googleanalytics
taxonomy_manager
taxonomy_menu
delta
delta_blocks
termpath_token
chosen
options_element
superfish
variable
variable_realm
variable_store
vt_commerce_image
draggableviews
views
views_bulk_operations
views_data_export
views_field_view
views_php
views_slideshow
views_slideshow_cycle
views_ui
webform
webform_localization
xmlsitemap
xmlsitemap_engines
xmlsitemap_i18n
xmlsitemap_menu
xmlsitemap_node
xmlsitemap_taxonomy

Brain, can you recall if the modules disabled when you enabled some other module? That's happen to me. I suspect module filter + caching settings (Minimum Cache Lifetime and Expiration of Cached Pages had high values) + browser (Chrome) could led to this.

I was able to enable/disable through drush just fine, thats why I suspect something in the UI caused this.

Could be module_filter or even core https://www.drupal.org/node/2371113.

Brian, can you recall if you had changed drupal's default cache settings /admin/config/development/performance especially Minimum Cache Lifetime and Expiration of Cached Pages?

I have the same problems too, seems not only happen on commerce modules, other modules like Views UI, Rules UI, String translation, Module filter etc are also disabled after clicking "save configuration" in modules admin page.
I've tried on both version 7.x-2.21 and 7.x-2.22 of Commerce Kickstart. It's a strange problem!

I think this issue is related: https://www.drupal.org/node/2371113
It's not only a commerce kickstart problem.

@phoenix, I agree with you. This happens that if the new willing enabled module have dependencies. My temporary solution is firstly enabling the dependencies one by one, then enable the module you need.

Had this problem with my Kickstart 2 install for about half a year, glad to see I'm not alone. Haven't found a solution yet.

I have a local install of the same site on a synology device that doesn't show any problems. When I disable or enable modules via UI, especially the following modules get disabled:

• commerce_autosku
• commerce_fieldgroup_panes
• commerce_backoffice
• commerce_backoffice_content
• commerce_backoffice_order
• commerce_backoffice_product
• commerce_add_to_cart_confirmation
• commerce_discount
• commerce_discount_date
• commerce_discount_usage
• commerce_fancy_attributes
• date restrictions + date restrictions weekdays

Tried disabling module_filter to no avail. Only way to enable of disable is changing the status in the system table. Furthermore, when I install a new module, it tends to get schema version -1, meaning it looks as if it's not installed to drupal. I have to change it manually to 0 or 7000 before it's recognized and its install script runs. Now running on commerce kickstart 2.25, problem still persists.

I've never seen or heard of anything like this. There's certainly nothing in the Commerce codebase that would cause modules to be disabled. The only time I've been bit by modules being force disabled was when an unwitting user used Admin Menu's "Disable development modules" menu item, which resulted in all of the Commerce related UI modules being disabled. Nasty trick, that.

I'll leave this open here for now in case someone has a thought that spares you future issues, but you really need to be looking elsewhere. I'll close this eventually unless someone comes up with a way to reproduce this.

I have a suspicion that Features might have something to do with it. Can someone check if Features is part of the affected installs?

Also, for those looking for a quick solution to this: I tried changing the status of newly installed modules in PHP My Admin to 1 and schema version to 0/7000, but for some reason this does not run the install.php of the new modules. Instead, just enable new modules in the admin interface, which created the necessary tables. After that, just run a list of modules that have been disabled before through an sql query in PHPmyadmin:

UPDATE system SET status='1' WHERE name='commerce_autosku';

one line per module, just change the name. Quick and dirty.

It shouldn't make a difference (enabling simply changes the status of the module from 0 to 1), but in my install it does. The module.install doesn't run when I install it via admin/modules/install, so enabling the module via phpmyadmin puts it on status 1, but schema version is often still -1, and necessary tables/columns aren't created, leading to fun errors such as PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table. Enabling the module via admin/modules does run the script, but disables other modules. I even tried running the module.install a few times via devel php code, but it didn't do anything. So just letting the system create the tables and enabling disabled modules via a sql query afterwards proved to be the lesser of two evils.

I have features also in my infected installation, but one copy works the other not. Just to remind that I can perfectly fine enable/disable modules through drush.

FYI: problem still persists in Commerce Kickstart 2.27...

Update to my issue with the same type of problem…

https://www.drupal.org/node/2621370#comment-10636588

Hope this helps.

Thanks,

•• matt

@mattlt: this is my server configuration (shared hosting, so this is just what I can get from phpmyadmin:

• MySql: 5.5.31
• Php: 5.5.30

Hope this helps.

Just got hit by this and the problem is definitely related to PHP versioning.

I have one development and one local test site, both on LAMP with PHP 5.6.16, MySQL 5.5.47. Both sites worked perfectly for weeks.

Staging and Production servers are Virtual Servers with PHP 5.6 and MySQL 5.5.47. It will keep on crashing the same modules over and over again, whenever something is enabled or disabled on the module page.

Now the catch: Our hosting provider has one standard Legacy PHP Version (currently 5.3) and two recommended alternatives (one is the 5.6 that I chose for us).

If I choose any of the two alternatives for our server, I will lose the exact same set of modules on next enable / disable. If I choose the legacy version, the module page works without a glitch.

I'll be contacting the provider to see what's going on, but I have a hunch it has nothing at all to do with Drupal modules or with PHP Version and everything to do with the version selection system that they are using.

In other words - different provider than mattlt above, but it seems to be the same underlying problem.

The Day After:

Further research shows that the modules disabled are always those that have brackets in name - for instance Commerce (Stock), similar to what this comment here states. That's why it seems to mostly pop up with commerce modules, albeit it's not related to them specifically in any way.

TLDR: If you have an environment where you can choose your PHP version, you choose a non-standard PHP version and then have modules that belong to a group with brackets, enabling or disabling a module will also disable all modules in brackets.

Solution

Simply change the names of the module groups with brackets to no brackets or set the PHP version on your hosting server to default.

I suggest we also come up with a naming standard for module groups to avoid this kind of issue in the future.

Wow, that's really bizarre - is it just causing a parse error of the .info file?

Do we need to remove the parentheses or just update the module package names to use quotation marks?

Just tested parentheses in quotation marks - sadly they're a no-go.

I have a whole commerce site where I globally replaced all parentheses with a simple - using the script I posted here. Everything worked fine.

Then I set the commerce - shipping package back to original commerce (shipping) and added quotation marks. Every other adapted package remained active, but the entire shipping group was disabled.

The script can be a temporary solution until we find out why this is happening.

EDIT: Parent Issue in Core here, according to my research yesterday it affects even Drupal 8 Core modules:
#2665152: Simplify module form structure and fix bugs when Suhosin is used

Ok, no worries. Let's go ahead and get patches rolling then. : )

I was having the same issue. I was unable to enable any commerce contrib modules like backoffice etc...

After wasting the whole day I did the following, I am not sure which of the following Resolved my issue.

# 1 From my cpanel I selected php 7 (Not sure why I did that)

# 2 Since I was getting the ctools error after upgrading to php 7 so I upgraded ctools to latest dev release

# 3 I also during checking the log messages found an error related to Rules so I also updated that to latest dev release

and guess what? The issue is resolved

since I did all of these changes simultaneously so I am not sure which of the above step resolved this issue. But my best guess is upgrading rules resolved it for me.

Just had this same issue on my site with Drupal Commerce and Several Shipping modules. If I switch to drupal 5.6 or 5.5 I had the error, but 5.5 Native works perfect (Using Cpanel)

I too have experienced the problem described herein.
It took me nearly a week to track down this bug report!
Thank goodness this serious problem has at least been brought to the attention of Drupal Core's maintainers.

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.

Okay, so the problem is caused by Suhosin.

On the Commerce side we should document this problem on docs.drupalcommerce.org
On the Core side we need to either add a warning via hook_requirements (telling people to reconfigure suhosin.request.array_index_blacklist) or forbid parenthesis in package names. To be discussed in #2665152: Simplify module form structure and fix bugs when Suhosin is used.

The simple immediate solution is to remove the brackets in the package line. My host provider doesn't want to hear about exceptions, so I have to remove brackets. Why should there be resistance to this?

Because there are hundreds of modules that use parentheses, making it near impossible for any such solution to address all affected projects. Better to find a more centralized solution, imo.

The bug was already fixed in D8, now it just needs to be backported to D7.

Thanks to this thread, much frustration has been alleviated.. I wanted to toss in what I observed, might help someone else. I have a godaddy cpanel hosting that was running php 5.5 (but noted 5.4 native). I had attempted to install D7 commerce kickstart 2 and every time I tried to enable the commerce ups module, everything went haywire. The module would not enable and menu items like "add product" would disappear. Also product variations vanished. Prior to this situation, I had tried a D7 core install and every single module with parenthesis ( ) which included ubercart core (optional) modules were unable to be turned on. After reading this thread and simply switching my PHP version from 5.5 to 5.4 native, everything seems to be working again. Hopefully that helps someone googling this down the road or possibly with killing the bugs - thanks!