Yesterday I believe I hit what might be an upper limit on what a single feature can track. As the site I was building grew I was continually adding more entities, fields, permissions, etc. to a single site-wide feature. And, at a certain point, features stopped functioning correctly. The symptoms:

  • When recreating a feature, clicking the "Download feature" button does not offer up a tar file as you'd expect, but instead writes the feature's files straight to the filesystem (as if you'd clicked "Generate feature").
  • If you let the above process succeed (let features re-write its files directly), the resulting, generated feature is missing large swaths of data that it was told to track on the recreate page. In other words, a large amount of data is missing from the resulting feature.

Now, this feels to me like a limit on the number of items that can be tracked in a single feature, because when I unchecked the 40 (or somewhere around 40) new fields I was attempting to add into the feature, everything worked (download button worked, and the resulting feature included what I had checked off on the recreate screen).

The temporary fix was to break the single, large feature into multiple, smaller features (staying under the mysterious limit). The new fields I was attempting to add into the large feature (the fields that put me over the limit) were happily tracked by features once they were added into one of the smaller features - so I have a hard time imagining it had anything to do with those specific fields - more that those fields were putting me over this mysterious limit.

This bug presented on both 2.0-beta1 and 2.0-beta2.

CommentFileSizeAuthor
#2 features-feature-size-limit-1995590-2.patch1.12 KBchrisolof

Comments

arknoll’s picture

arknoll commented
Status: Active » Needs work

I too was having this problem and was receiving php error: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini.

To fix this problem I set (in .htaccess file):

php_value max_input_vars 3000
php_value suhosin.get.max_vars 3000
php_value suhosin.post.max_vars 3000
php_value suhosin.request.max_vars 3000

This can also be set in your php.ini file (but not in your settings.php file).

This should probably be added to the features documentation/readme file.

chrisolof’s picture

chrisolof
he/him
Primary language English
commented
Component: Code » Documentation
Status: Needs work » Needs review
StatusFileSize
new features-feature-size-limit-1995590-2.patch1.12 KB

Attached patch updates the readme file to include details on setting php configuration directives for working with very large features.

mpotter’s picture

mpotter commented
Status: Needs review » Fixed

Committed to 8335ed1.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

francewhoa’s picture

francewhoa
he/him
Primary language French
Location Sept-Îles, Québec, 🇨🇦
commented

Thanks arknoll :)

We hit the same limit. The following format worked for us.

max_input_vars = 3000
suhosin.get.max_vars = 3000
suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000

Using

  • Debian Wheezy 7
  • Apache 2.2.22
frankcarey’s picture

frankcarey commented
Status: Closed (fixed) » Active

Sorry to reopen this, but I don't think documenting this in a README is a sufficient fix. I'd propose that we read what the limit actually is set to and then warn the user when appropriate. Possible scenarios with the limit set to the default 1000 limit.

- (a) Warn when the form itself has more than 1000 possible items on it

- (b) Better: Use JS to keep track of the number of checked boxes and then warn when they approach the limit of things actually selected.

- (c) Prevent the user from saving (download or generate button) when the number of selected items exceeds the limit.

Thoughts?

mpotter’s picture

mpotter commented
Status: Active » Closed (fixed)

Because, as you can see above, this is a PHP setting. So adding code to Features to limit it to 1000 would be bad, because that's just a default number in php.ini. It still wouldn't work for people with a small setting, and it would annoy people with a larger setting.

I'm closing this again because anybody hitting this limit in Features needs to be splitting their Features into smaller pieces. Features is designed for modular config and is not a dumping ground for putting all your config in a single Feature.

WorldFallz’s picture

WorldFallz commented

Since this is probably the first place someone will hit when having issues with large features, I wanted to update it with an additional piece of info.

The size of the 'info' field in the 'system' table can also cause failures or, worse, incomplete feature implementation which may not become apparent while troubleshooting the weird issues it may cause.

Turns out changing the size to 'longblob' is also sometimes necessary. See #2580473: Increase size of info column in system table. for more info.