2012-11-29 12 views
11

Sto riscontrando un problema in un sistema Magento in cui il salvataggio di un numero elevato di attributi non funziona affatto o funziona solo parzialmente. Sembra essere un problema relativo a JavaScript, e speravo che qualcuno su Stack Overflow avesse una "scienza conosciuta" per affrontare questa situazione, o potrebbe indicarmi la giusta direzione.Problemi nel salvataggio di un numero elevato di etichette di opzioni di attributo in Magento

Il problema di base è che il sistema Magento in questione ha oltre 250 etichette di opzioni di attributo colore. Se un utente amministratore tenta di gestire questi effettuando le seguenti

  • Navigazione al Catalogo -> Attributi -> Gestisci attributi
  • Selezione del colore attributi
  • Cliccando sulla etichetta Gestisci/scheda Opzioni
  • Editing l'ultima etichetta Option
  • Cliccando su "Salva e continua Modifica"

una delle due cose accada.

In Google Chrome su OS X, il pulsante rimane nello stato "depresso" e, dopo un certo periodo di tempo, compare la finestra di dialogo "Questa pagina non risponde" di Google Chrome.

In un browser basato su Mozilla su OS X, facendo clic sul pulsante il browser "pensa" per un po ', ma alla fine invia il modulo. Tuttavia,, solo un elenco parziale delle etichette degli attributi viene registrato nel controller di amministrazione. Ciò significa che l'utente può modificare solo le prime 75 - 100 etichette, poiché le altre etichette non vengono mai inviate.

Ho segnalazioni degli utenti di Windows che descrivono la seconda comportamento così (browser sono non-specifici)

Le risposte sono ovvie a uno indagare il javascript scarso rendimento, o (stile Groucho Marx) "non fanno quella". Prima di passare il tempo a profilare/scavare il javascript in quella pagina, speravo che ci fosse qualche soluzione nota per questo, o una conoscenza specifica di ciò che stava causando il problema.

Magento CE 1.7.x, se presente.

Aggiornamento: I problemi di prestazioni di Javascript sono una falsa pista. Sono causate dal massiccio numero di campi di input essere iterati attraverso

js/prototype/validation.js 

In particolare in questo blocco catch try

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) { 
    } 

Tuttavia, anche se questo corto circuito e hanno la funzione di ritorno vero, il comportamento di non salvare tutte le etichette persiste.

risposta

17

È possibile provare i max_input_vars variabili (introdotto in PHP 5.3.9), per impostazione predefinita è 1000 quindi dovrebbe essere sufficiente, ma forse la tua configurazione utilizza una quantità inferiore. Ma immagino che il modulo non riesca a superare a causa dei principali problemi di prestazioni che stai riscontrando.

Informazioni sulle etichette delle opzioni: sono state apportate modifiche a un uploader per un'immagine attributo? Abbiamo avuto lo stesso identico problema quando abbiamo installato l'estensione GoMage Advanced Navigation in un negozio con oltre 300 opzioni del produttore (l'estensione utilizza il Flash-uploader incorporato di Magento).

Non avevamo l'estensione per quella funzione, quindi ho disabilitato l'uploader, ma il calo delle prestazioni estreme era sicuramente nei 300 filmati Flash caricati. Forse puoi provare a scaricare l'uploader per opzione, inserendo un pulsante o un link al posto del film.

Spero che questo ti punti nella direzione giusta (o esatta).

+0

Sembra che questo fosse il problema. Se applico l'array POST e lo contiamo, ha esattamente 1000 elementi. I futuri che arrivano dovrebbero leggere anche questa segnalazione di bug, dato che la documentazione di max_input_vars è leggermente imprecisa. https://bugs.php.net/bug.php?id=62921&edit=1 –

+0

Ho risolto anche il problema (lo stesso problema di Alan Storm). Il max_input_vars era già impostato su 1000 ma non ha funzionato con i miei 380 valori di attributo. Quando si imposta su 3000, il pulsante è rimasto premuto in chrome, ma i valori sono stati salvati correttamente. –

3

Ho avuto esattamente questo problema (POST troncato) e proviene da una patch suhosin che ha un limite POST troppo basso. (o il PHP standard post_max_size)

Nel tuo php.ini controllare questi valori e aumentare i loro valori, se necessario (e riavviare apache):

post_max_size 
suhosin.post.max_vars 
suhosin.request.max_vars 

Per il vostro secondo probleme (problema di prestazioni JS), non posso aiutare a

+0

+1 per informazioni preziose, ma non sembra Suhosin o post_max_size sono che colpevoli qui. Grazie comunque! –

+0

Mi imbatto anche in questo problema di suhosin. Nota che uccide anche linee GET più lunghe che a volte vengono usate in Magento – macki

+0

Sì, controlla attentamente tutti i tuoi vassoi phpinfo(), dovresti trovare qualcosa relativo –

11

[Working SOLUZIONE]

Ciao come Alan Tempesta detto, questa ussue è in relazione con la logica JS, che gestisce la convalida degli ingressi di etichette. Ho avuto questo problema su un progetto di uno dei miei clan e ho scritto un'estensione semplice, che lo risolve.

È possibile scaricare l'exntesion per qui: https://github.com/Jarlssen/Jarlssen_FasterAttributeOptionEdit

In sostanza l'estensione sostituisce il modello di opzione di originale con il modello la mia. Nel mio modello ho riscritto la maggior parte del JS nella parte inferiore del modello e sostituito gli input del modulo con elementi div (pseudo input), quindi quando l'amministratore fa clic sullo pseudo input, viene sostituito con l'input reale. In questo modo evitiamo di convalidare tutti gli input e convalidiamo solo le modifiche e le nuove voci aggiunte. L'estensione funziona bene se si aggiungono opzioni su blocchi, ad esempio 500 voci per ogni attributo salvato.

Spero che sia d'aiuto.

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

rapido sguardo alla pseudo codice generazione:

<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> 
+1

Questo lavoro mi piace come un fascino, con qualcosa come 2000 valori di opzioni che risolve perfettamente il problema del salvataggio lento. – Guerra

+0

@Guerra fantastico! Si prega di aprire il problema in github, se si notano problemi con questa correzione. – ceckoslab

+1

Un altro utente felice! 4000+ articoli, nessun problema. Magento dovrebbe usare questo metodo per impostazione predefinita. –

0

dispiace !!

Ho affrontato lo stesso problema, la soluzione segue di seguito.

Spiegazione del problema

problema

Un cliente ha una grande base di pneumatici che hanno anche molte vetture aggiunti alla stessa, così migrare ormeggi tra pneumatici e veicoli solo 255 caratteri degli attributi di id sono stati inseriti nella tabella con esso causando errori nella migrazione.

Magento inserisce una stringa con ids separate da,

Il problema si è verificato nella tabella "catalog_product_entity_varchar" nel campo valore che di default è 255 caratteri se metto testo e risolto.

Nota: so che si modifica il DB non è bello ma purtroppo è stato necessario eseguire questa operazione.

prodotto Esempio

pneumatici 175/65R14

-> Marca (+ - 200 opzioni)
-> Model (+ - opzioni 4mil)
-> Serie (+ - Opzioni 15mil)
-> Anno -> ...

att,

1

Aprire php.ini del server, cercare max_input_vars e impostarne il valore a più di 2500 risolverà il vostro problema

; How many GET/POST/COOKIE input variables may be accepted 
max_input_vars = 5000 
+0

Questa è stata la soluzione facile per me. –

Problemi correlati