12

I'm running into a problem in a Magento system where saving a large number of attributes either doesn't work at all, or only partially works. It appears to be a javascript related issue, and I was hoping someone on Stack Overflow had some "known science" for dealing with this situation, or could point me in the right direction.

The basic problem is, the Magento system in question has over 250 color attribute option labels. If an admin user attempts to manage these by doing the following

  • Navigating to Catalog -> Attributes -> Manage Attributes
  • Selecting the color attributes
  • Clicking on the Manage Label/Options tab
  • Editing the last Label Option
  • Clicking "Save and Continue Edit"

One of two things happens.

In Google Chrome on OS X, the button sticks in the "depressed" state, and after a period of time Google Chrome's "This page is not responsive" kill dialog comes up.

In a mozilla based browser on OS X, clicking the button makes the browser "think" for a bit, but it eventually submits the form. However, only a partial list of attribute labels is posted to the admin controller. This means the user can only edit the first 75 - 100 labels, since the other labels are never submitted.

I have reports from windows users describing the second behavior as well (browsers are non-specific)

The obvious answers are to either investigate the poorly performing javascript, or (Grouch Marx style) "don't do that". Before I spend the time profiling/excavating the javascript on that page, I was hoping there was some known fix for this, or specific knowledge as to what was causing the problem.

Magento CE 1.7.x, if it maters.

Update: The Javascript performance issues are a red herring. They're caused by the massive number of input fields being iterated through in

js/prototype/validation.js

Specifically in this try catch block

    try {
        if(this.options.stopOnFirst) {
            result = Form.getElements(this.form).all(function(elm) {
                if (elm.hasClassName('local-validation') && !this.isElementInForm(elm, this.form)) {
                    return true;
                }
                return Validation.validate(elm,{useTitle : useTitles, onElementValidate : callback});
            }, this);
        } else {
            result = Form.getElements(this.form).collect(function(elm) {
                if (elm.hasClassName('local-validation') && !this.isElementInForm(elm, this.form)) {
                    return true;
                }
                return Validation.validate(elm,{useTitle : useTitles, onElementValidate : callback});
            }, this).all();
        }
    } catch (e) {
    }

However, even if I short circuit this and have the function return true, the behavior of not saving all the labels persists.

Alana Storm
  • 164,128
  • 91
  • 395
  • 599

6 Answers6

18

You can try the variable max_input_vars (introduced in PHP 5.3.9), by default it's 1000 so that should be enough, but maybe your configuration uses a lower amount. But I imagine the form just doesn't get through due to the major performance issues you're experiencing.

About the option labels: do they by any change have an uploader for an attribute-image? We had the exact same problem when we installed the GoMage Advanced Navigation extension on a shop with over 300 manufacturer options (the extension uses Magento's built-in Flash-uploader).

We didn't have the extension for that feature so I disabled the uploader, but the extreme performance decrease was definitely in the 300 Flash-movies being loaded. Maybe you can try lazyloading the uploader on a per-option basis by inserting a button or link instead of the movie.

Hope this points you in the right (or exact) direction.

Marco de Vries
  • 296
  • 1
  • 3
  • Looks like this was the problem. If I flatten the POST array and count it, it has exactly 1000 elements. Future folks who come by should read this bug report as well, as the documentation for max_input_vars is slightly inaccurate. https://bugs.php.net/bug.php?id=62921&edit=1 – Alana Storm Nov 29 '12 at 22:49
  • This fixed my issue as well (same problem as Alan Storm's). The max_input_vars was already set to a 1000 but did not work with my 380 attribute values. When setting to 3000, the button remained pressed in chrome, but the values did save correctly. – Raphael Rafatpanah Oct 03 '13 at 23:58
12

[Working SOLUTION]

Hello as Alan Storm mentioned, this ussue is related with the JS logic, that handles the validation of the option label inputs. I had this problem on a project of one of my clents and I wrote simple extension, that solves it.

You can dowload the exntesion for here: https://github.com/Jarlssen/Jarlssen_FasterAttributeOptionEdit

Basically the extension replaces the original option template with mine template. In my template I rewrote most of the JS in the bottom of the template and replaced the form inputs with div elements ( pseudo inputs ), so when the administrator click on the pseudo input, then its replaced with the real input. In this way we avoid validating all the inputs and we validate only edited and the new added entries. The extension works well if you add options on chunks, for example 500 entries per attribute save.

Hope, that helps.

Additional information: http://www.jarlssen.de/blog/2014/05/07/magento-timeout-saving-attribute-options-type-multiple-select-and-dropdown

Quick look at the pseudo generation code:

<tr class="option-row">
<?php foreach ($this->getStores() as $_store): ?>
    <td>
    <div class="replace-content pseudo-input input-text <?php if($_store->getId()==0): ?> required-option<?php endif; ?>" id="option[value][<?php echo $_value->getId() ?>][<?php echo $_store->getId() ?>]"><?php echo $_value->getData('store' . $_store->getId()) ?></div>
    </td>
    <?php endforeach; ?>
    <td>
        <div class="replace-content pseudo-input" id="option[order][<?php echo $_value->getId() ?>]"><?php echo $_value->getSortOrder() ?></div>
    </td>
    <td class="a-center default-checkbox">
        <div id="option_<?php echo $_value->getId() ?>" class="checkbox-radio-container replace-content">
        <?php if($_value->getChecked()) : ?>
            <input class="input-radio" type="<?php echo $defaultChooserInputType; ?>" name="default[]" value="<?php echo $_value->getId() ?>" checked <?php if ($this->getReadOnly()):?> disabled="disabled"<?php endif;?>/>
        <?php else : ?>
            <?php if('radio' == $defaultChooserInputType) : ?>
                <span class="fake-radio"></span>
            <?php else : ?>
                <span class="fake-checkbox"></span>
            <?php endif; ?>
        <?php endif; ?>
        </div>
    </td>
    <td class="a-left actions-column" id="delete_button_container_<?php echo $_value->getId() ?>">
        <div id="option[delete][<?php echo $_value->getId() ?>]" title="<?php echo $this->__('Delete') ?>" class="scalable left pseudo-delete-option">
        <span class="pseudo-delete-button" option_id="<?php echo $_value->getId(); ?>">
            <span>
                <span><?php echo $this->__('Delete') ?></span>
            </span>
        </span>
        </div>
    </td>
</tr>
ceckoslab
  • 1,189
  • 1
  • 9
  • 19
3

I had exactly this problem (POST truncated) and it comes from a suhosin patch that has a too little POST limit. (or the standard PHP post_max_size)

In your php.ini check these values and increase their values if needed (and restart apache) :

post_max_size
suhosin.post.max_vars
suhosin.request.max_vars

For your second probleme (JS performance issue), I can't help you

Jscti
  • 14,096
  • 4
  • 62
  • 87
  • +1 for valuable information, but it doesn't look like suhosin or post_max_size are that culprits here. Thanks though! – Alana Storm Nov 29 '12 at 21:03
  • I also run into this suhosin issue couple times. Note it also kills longer GET lines that are sometimes used in Magento – macki Nov 29 '12 at 21:49
  • Yep, check carefully all your phpinfo() vars, you should find something related – Jscti Nov 29 '12 at 22:22
1

Sorry!!

I went through this same problem , solution follows below.

Explanation of the problem

problem

A customer has a very large base of tires that also have many cars added to the same , thereby to migrate moorings between tires and vehicles only 255 characters of the attributes of ids were inserted into the table with it causing error in the migration.

The magento inserts a string with ids separated by ,

The problem occurred in the table "catalog_product_entity_varchar" in the value field which by default is 255 characters if I put text and resolved .

Note : I know you modify the DB is not nice but unfortunately had to perform this operation.

Example product

Tire 175 / 65R14

-> Make ( + - 200 options)
-> Model (+ - 4mil options)
-> Series (+ - 15mil options)
-> Year -> ...

att,

1

Same problem here. I solved with BELVG module "Attribute Pagination" : http://blog.belvg.com/attribute-admin-page-pagination-in-magento.html

It works properly.

Hope that helps.

1

Open your server's php.ini, search for max_input_vars and set its value to greater than 2500 will solve your problem

; How many GET/POST/COOKIE input variables may be accepted
max_input_vars = 5000
Adnan
  • 1,379
  • 2
  • 17
  • 24