Come valutare le estensioni 3a parte?

Question

Mentre Magento fa un bel po 'out of the box', abbiamo trovato ci sono caratteristiche inevitabilmente e le strutture necessarie per i negozi client che richiedono l'estensione 3rd party.

Tuttavia, data la natura del mezzo, può essere una proposta rischiosa per introdurre il codice 'straniero' per un sistema così complesso si tratta di transazioni commerciali.

Che cosa cercate quando si valutano le estensioni Magento? Quali sono le 'bandiere rosse' hai incontrato (maiali prestazioni, rischi per la sicurezza, cattive pratiche architettoniche)?

Answer 1

Ecco alcuni pensieri sulla valutazione 3 Moduli del partito:

Nozioni di base:

• attuale Magento Versione Support - Does It supporta l'ultima versione di Magento (compreso quello attuale che stiamo sviluppando per)

  ?

  Se un modulo non supporta l'ultima release di Magento, probabilmente sarà difficile farlo funzionare senza spendere prezioso tempo di sviluppo su di esso.

• Supporto -? Fate gli sviluppatori che hanno creato il supporto del modulo del prodotto

  Uno dei segni di un modulo sano è che gli sviluppatori sostengono attivamente. Se essi non lo supportano è una bandiera rossa, perché non hanno sostenere il prodotto se è buono?

  Inoltre, quando viene sostenuto un modulo, di solito può ottenere informazioni importanti da parte degli sviluppatori con una semplice e-mail (ad esempio, fa uso del modulo jQuery o Prototype).

• Recensioni - Quali sono gli altri utenti da dire? Come è stata la loro esperienza?

  Per leggere le recensioni che possiamo ottenere un miglior senso del quadro generale, c'è un problema di installazione? Fare rispondono agli sviluppatori in modo tempestivo e disponibile? Funziona come pubblicizzato?

• Il rimborso - Saranno in grado di dare indietro i vostri soldi se non funziona come previsto

  ?

  Molte volte ci vogliono provare il modulo in modo che possiamo provarlo, se funziona e soddisfi i requisiti richiesti grande! Ma se così non fosse, vogliamo la possibilità di tornare e ottenere un rimborso per esso.

intermedio:

• Classe Sostituzioni -? Fa l'override modulo di tutte le classi di base

  In linea generale un modulo buono non dovrebbe ignorare tutte le classi di base, piuttosto dovrebbe usare osservatori.

  Una ragione di ciò, è che può rendere l'aggiornamento Magento difficile. Inoltre, altri moduli possono essere a seconda di un'uscita da una data funzione, e questo modulo è fornire uno diverso.

  A volte questo non è possibile farlo, se questo è il caso, ci dovrebbe essere una buona ragione per cui è prevalente una classe principale.

• Aggiornamenti layout -? Fa il cambiamento del modulo alcune delle mie impostazioni di layout

  Alcuni moduli modificare le impostazioni di layout per il sito (per esempio: pagina del prodotto), assicurarsi che non si rompe il layout corrente, e se lo fa quello che sarebbe richiesto (leggi: quanto tempo ci vorrà noi) per risolvere il problema.

• Template cambia -? Il modulo comprende modelli che cambiano il mio progetto attuale

  Sarà questo modulo introdurre nuovi modelli? Se sì, faranno rompere il mio design? Quanto tempo ci vorrà per avere il disegno il modo in cui vogliamo?

• Dipendenze - Fa il modulo dipenderà da qualsiasi altro modulo

  ?

  Se il modulo dipende dagli altri, abbiamo bisogno di fare in modo che non vi e installato sono. Inoltre abbiamo bisogno di chiedere a noi stessi, stiamo andando a voler spegnere il modulo dipende in futuro?

Avanzate

• SQL script di aggiornamento -? Il modulo di aggiornamento del DB, in qualche modo

  Una volta che un modulo aggiorna il database abbiamo bisogno di fare in modo di alcune cose.

  Ha aggiornare una tabella di base? Se sì, questo non va bene, noi come i nostri database pulito e pronto per l'aggiornamento.

  Ha memorizzare le informazioni in modo sensato? Se vogliamo ottenere il grezzo dati dal database noi stessi, saremmo in grado di dare un senso di esso?

• Eventi -? Il modulo di osservare o la spedizione eventi

  Se un modulo di spedizioni o osserva gli eventi, vogliamo sapere:

  Quali eventi è vero osservando / dispacciamento? Questo influenzerà un altro modulo che lavora nel sistema. Ad esempio, se uno dei nostri moduli cambia il nome dei nostri prodotti sotto carico in lettere maiuscole, e questo modulo aggiunge la parola 'libero' per il nome del prodotto sotto carico, come funzionerà? Sarà la parola 'libero' anche uscito superiore con carter?

• Code Review -? Fa l'uso del modulo accettabile tecniche di codifica

  Questaha più a che fare con PHP tecniche di codifica di Magento.

  Se l'uso di codice try / catch blocchi?

  Fa l'input dell'utente codice di escape?

  Le specifiche di questo in realtà dipendono le nostre livello di abilità / requisiti.

• I potenziali problemi -? Quali problemi potenziali possono venire fino a seguito di installazione di questo modulo

  Provate ad immaginare i primi cinque problemi che potrebbero venire su se installare questo modulo, per quanto sorprendente possa essere, dà veramente una visione per il progetto nel suo complesso.

Bottom Line:

Tutte queste cose sono bello avere in un mondo ideale, in scenari del mondo reale abbiamo bisogno di fare questa cosa chiamata 'compromesso':)

Inoltre, queste linee guida sono destinate ad essere come un aiuto per noi, per non ostacolare noi, di conseguenza, se stiamo installando un solo modulo, diciamo un modulo condivisione sociale, ed è per un cliente che ha bisogno di un semplice sito messa a punto, non c'è alcun senso nel fare una tonnellata di ricerca.

In altre parole:. Si tratta di essere efficiente con il nostro tempo, se si usa questo (voce nella) guida mi aiuta a risparmiare tempo nell'utilizzo lungo andare, se non cadere e salvare la vostra sanità mentale

Answer 2

Alcuni Magento specifico "cattiva pratica" bandiere rosse sono:

• alcun codice in app/code/local/Mage
• modelli sovrascritti (file in app/design che già esistono nel nucleo)
• riscrive delle classi essenziali come catalog/product. In generale mi guardare con attenzione ad ogni riscrittura, per vedere se poteva essere evitata
• gravi violazioni del Zend / Magento standard di codifica. Mentre questo è solo sulla formattazione del codice, concludo che gli sviluppatori che sono incurante di norme sarà molto probabilmente incurante di altri, più importanti, le cose troppo.
• cambiamenti nella tabelle di database di base
• testo codificato duro nei modelli (non si utilizza il meccanismo di traduzione) e altrove
• logica di business nel template (regola empirica: qualsiasi occorrenza di Mage::getModel nella directory dei modelli di solito è un brutto segno)

Alcune bandiere rosse legate PHP (questa è una lista molto selettivo e incompleto):

• eventuali e avvisi con la segnalazione degli errori abilitato (E_STRICT)
• Utilizzo dell'operatore @
• non sanificazione dei dati utente prima uscita

Alcune bandiere rosse relativi alle prestazioni:

• query di database all'interno di loop
• il caricamento di una intera collezione solo per utilizzare una parte di esso

anche guardare fuori per generale Codice Odori , quelli che non sono necessari, ma le bandiere rosse aiuto per stimare la qualità complessiva.

Answer 3

Passo # 1 - Può il vostro cliente permettersi di sostenere questa estensione se lo sviluppatore va AWOL

?

Se no, non è possibile utilizzare l'estensione.

Se sì, procedere alla valutazione di estensione.

Answer 4

I genietti di Inchoo hanno un articolo sull'analisi codice del modulo 3rd party. L'articolo cita riscritture di classe, posti di lavoro cron, aggiornamenti di layout, e gli osservatori degli eventi.

Ho trovato il codice evento osservatore hanno il potenziale per il più alto calo di prestazioni. Guardare fuori per molte risorse, codice di terze parti che corre per spesso spediti eventi. Eventi come, carichi controller_action_predispatch, o di raccolta.

questo modulo utility da Prattski per avere una panoramica bella di riscritture e osservatori.

Answer 5

Avere tutti i modelli e le attività della pelle situate in default / default (o pro o impresa) invece di base / default è abbastanza fastidioso.

codice offuscato è qualcosa da guardare fuori per - cercare chiamate a eval (), base64_decode (), e simili. Questo viene spesso utilizzato per la convalida della licenza, ma può essere dannoso o paura - ho visto almeno un componente che eval'd di codice arbitrario da un feed RSS.

Cercare dl () chiama - almeno componente gateway un pagamento che ho visto richiede l'installazione di un'estensione PHP per fare le sue connessioni!

Answer 6

Hai ragione.

Non è, purtroppo, nessuna magia: bisogna provarli, controllare il codice per vedere se è ben sviluppato, avere un buon supporto per i moduli commerciali grazie al loro forum o rapidità per rispondere alle vostre domande ...

Ci sono alcune recensioni su Magento Connect e la popolarità di un'estensione possono aiutare a sapere se è importante o no, ma onestamente è possibile trovare i moduli molto popolare con un sacco di bug. Ho avuto un buon esempio la settimana scorsa con un modulo MailChimp, soprattutto ben fatto ma ho dovuto correggere alcuni bug e li fornito allo sviluppatore. Ci sono rischi sempre, bisogna prova.

WebShopApp ha avuto l'idea di spingere in questa direzione, voglio dire, per portare una piattaforma per ottenere buone informazioni sui moduli. L'idea era quella di spingere Magento in questa direzione. Così la qualità del modulo è una domanda reale.

Answer 7

Il mio consiglio:. Di paga estrema attenzione ai moduli che hanno installare / aggiornare gli script che cambiano i valori in tabelle di base, perché non è sempre facile far ritirare quel tipo di modifiche

Answer 8

Il # 1 test che posso venire in mente è di trovare una zero-day exploit nel loro codice (di solito non molto difficile con le estensioni Magento), riportare solo il danno risultante di un mock sfruttare a loro team di sicurezza (senza dare indicazione di quale parte del codice è vulnerabile), e avviare il cronometro - perché questo è esattamente ciò che sta per accadere quando il tuo sito viene hackerato. Quando il loro personale di supporto chiede FTP globale e l'accesso mysql, declino gentilmente affermando che è in violazione del PCI-DSS e l'offerta per far loro hanno accesso in sola lettura al repository del codice sorgente.

La prova # 2 che eseguo è chiamare il venditore e li prendere alla sprovvista. Chiedere loro che tipo di comportamento / unità di test che lo fanno, quale sistema di fonte di controllo che utilizzano, quali versioni di PHP mettono alla prova su, quali versioni di Magento sono testati, che web-server sono testati su, anche se non usano il browser impili per testare i componenti di front-end, ecc ... Se il venditore non sa cosa si sta parlando, va in silenzio o vuole "ottenere un esperto per la posta elettronica indietro", correre come l'inferno, perché molto probabilmente uso numerati zip file per "controllo di versione" e solo i bug fix 3 mesi dopo che i loro clienti li riportano.

A proposito del PCI-DSS, tutte le modifiche di sistema sono anche tenuti ad avere una strategia di reversione. Con moduli che aggiungono colonne non annullabili alle tabelle di base, questo diventa praticamente impossibile pur mantenendo una strategia reversione che passare un controllo. Run Like Hell da tutti i moduli che causerà problemi (leggi: Gli errori SQL). Quando è disabilitata

PCI-DSS v3

6.4.5.4 Back-out procedure.

Verifica che le procedure di back-out sono preparati per ogni modifica inserita nel campione.

Per ogni cambiamento, ci dovrebbe essere documentato back-out procedure nel caso in cui il cambiamento non riesce o riguarda la sicurezza di un'applicazione o sistema negativamente, per consentire al sistema di essere ripristinato al suo stato precedente

Questo, in aggiunta alle altre risposte. IMO ci dovrebbe essere un muro della vergogna per alcune delle stronzate pericoloso che è stato generato su questa piattaforma.