Features UI /create page chokes on sites with BIG variable table, possible issue with Strongarm as well

Whoa, can you give me the count of your variable table?

mysql> SELECT COUNT(*) FROM variable;

3,128 rows it seems

We may want to do a 500/page pager

Experienced the same issue. Disabling strongarm fixed the problem. Though disabling strongarm once it's baked into your feature is no easy task :(

Do you know what is polluting your variable table so badly? Drupal caches and loads all the rows of the variable table on every single page load so it is an extremely bad idea for a module to grow this table so large... I'm curious what's causing your bloat.

Do you know what is polluting your variable table so badly?

Not sure but I'll look into it and report back...

I have some 2500 rows in the variable table. I'm sure many are left overs from poorly written modules, but even if it's 1/4 (unlikely) that leaves around 1900 variables.

My site has 25 content types, and around 80 contrib modules. Perhaps that has something to do with it....

I've been able to find a system table cleanup module -- but no module that does the same for variables table.

I am experiencing the same thing. I will try disabling strongarm but I am using atrium so I can't really.

Edit:
I had to rebuild my variable table. It was extremely bloated. Seems to have helped

Curious to know how you went about rebuilding your variable table?

Thanks

Very slowly

1. install a fresh install. In my case it was open atrium
2. save the variable table from the new install
3. save the entire db of the site whose variable table is huge if I screw up
4. save my current variable table
5. empty my current variable table
6. upload the variable table from #2
7. go through the admin > settings page and reconfigure each module again.
8. save the new variable table

I hope it helps.

ouch. there's gotta be an easier way...

I'm experiencing this too. 3306 rows in this variable table

http://drupal.org/project/variable_clean

3200 entries or not, I think the JS really needs to be optimized in some way. Selecting checkboxes in a UI should not spike my browser to 50% CPU..

Some ideas I think will mitigate the problem..

- Queue redraw requests to artificially limit framerate, instead of redrawing whenever a selection returns? That might be for the Features queue.

- Include a regexp-style filter to the strongarm variable list, with select all/none options -- this would let me limit to all variables that mention my content type, for example.

- Use a pseudo-tree navigation representation of the variable table.

This could be represented as:

  regexp filter: 
  select all - none

  ---------------------------------
  [ ]  + pathauto_
  [x]    - pathauto_max_
  [ ]     + pathauto_node_
              [x] pathauto_node_post_pattern
              [ ] pathauto_node_story_pattern
  [x] - site_
  [x] - superfish_
  ---------------------------------

Where all of pathauto_max_* is selected, all of site_* is selected, all of superfish_* is selected, etc ..

.. am I sort of describing regedit? ugh.

I would love to be able to do a simple .*_post_.* filter to minimize my time swimming through variables on big builds.

Best Regards,
Jason

This is also an issue for drupal 7 too, by the way

The way around all these issues is to simply use Drush. See https://drupal.org/node/960926 for some good documentation. This method works like a charm.

True, drush is useful for avoiding the problem. However, you can only use it to update your features (ie: fu-all), but not add new components to it.

Updating with a better title. I found that disabling Strongarm sped up the UI. Of course that's ironic as you need it for Features to really be of any value.

I am completely creating, managing and updating my Features with Drush now and will have a blog post forthcoming in the next day or so. I don't see this issue getting fixed in Drupal 6.

I think this is a general Features module problem. The page is unresponsive because all feature types with its sub-items are rendered.

However Strongarm loads a huge amount of items, the problem is that the form is generated for all the components and all it's children at once. This form is generated by the features module.

On a really large commerce kickstart installation I have to wait 10 minutes for the page to be rendered.

It could be worth to use an AJAX approach and don't render checkboxes until a Component is selected by the user in the combobox.

It's just an idea, I'm not sure how much work is it yet.

We're running into the same problem. I used to be able to get around this by using Safari, but a recent update to Safari seems to have made it susceptible as well.

I wrote a blog post about completely creating, managing, and updating Features via Drush and this is the method we use all the time now, at the very least, it's a huge time saver not to mention not having to go out of your workflow if you're in code / terminal mode.

http://highrockmedia.com/blog/features-drush-drupal-goodness

@highrockmedia: You are right!
I have to mention that finally I exported my features from drush, and this way I didn't have to wait 10 minutes...so I suggest to use the drush version also.