Come scrivere un'estensione personalizzata?

Dato che ultimamente ho avuto molti problemi con l'estensione gratuita e commerciale, ho deciso di porre questa domanda e di rispondere con i passaggi che di solito seguo quando scrivo un'estensione. Sentiti libero di modificare la risposta o di aggiungerne una nuova.
Nella maggior parte dei casi, quando installo un'estensione o un tema, devo dedicare alcune ore (a volte più, a volte meno) per farlo funzionare su tutti gli ambienti di cui ho bisogno:

• dev: di solito localhostdove il progetto si trova in una sottocartella
• preprod e live

Questo è successo anche con le estensioni di grandi fornitori di estensioni (che dovrebbero rimanere senza nome almeno fino a quando non diventerò davvero pazzo e aggiungerò i loro nomi qui)
Quindi la domanda principale è ... quali passi devo prendere quando scrivo un'estensione per garantire la qualità del codice e facilitare l'utilizzo da parte di una persona tecnica e non tecnica e la modifica da parte di una persona tecnica?

Ecco cosa faccio di solito:

1. Sviluppa sempre con error_reportingon.
2. Sviluppa sempre con isDeveloperModeset to true. Basta aggiungere SetEnv MAGE_IS_DEVELOPER_MODE 1al tuo httpd.conffile (o file corrispondente per Nginx o qualcos'altro)
3. Se l'estensione è collegata a una funzionalità principale, aggiungere la dipendenza nel file di dichiarazione <depends><Mage_Catalog /></depend>
4. Se il modulo è destinato alla comunità, utilizzare communitycome codepool per dare agli sviluppatori la possibilità di sovrascrivere alcune classi senza modificare direttamente il codice
5. Inserisci i tuoi file di progettazione del frontend app/design/frontend/base/default per renderli disponibili per tutti i temi.
6. Inserisci i file di progettazione dell'amministratore app/design/adminhtml/default/defaulte non modificare il tema dell'amministratore. Potrei volerlo cambiare in uno dei miei moduli.
7. Prefisso i nomi dei file di layout e il nome della cartella del modello con il nome dell'azienda per semplificarne l'isolamento. easylife_articles.xmleapp/design/.../easylife_articles
8. Inserisci le tue risorse statiche (JavaScript, CSS e immagini) in una cartella simile ai file modello easylife_articles/images/doh.png
9. Allegare un semplice file di testo con come disinstallare l'estensione: quali file devono essere rimossi, quali tabelle devono essere eliminate, quali impostazioni di configurazione devono essere rimosse dalla core_config_datatabella.
10. Non scrivere query direttamente in modelli, blocchi o helper, utilizzare un modello di risorsa per questo.
11. Non scrivere query utilizzando direttamente i nomi delle tabelle Select * from sales_flat_order where .... Usa a Zend_Selecte trasforma i nomi delle tabelle usando ->getTable('sales/order').
12. Utilizzare l'URL di base per includere i jsfile nel modello. Sbagliato <script type="text/javascript" src="../js/some.js"></script> . Giusto <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
13. Non riscrivere le classi se non è necessario. Usa gli osservatori e, se non è possibile usare metodi helper che ricevono come parametro e istanza di una classe che desideri sovrascrivere. Sbagliato : sovrascrivere Mage_Catalog_Model_Productper aggiungere il metodo getProductArticles(). Destra . Nel tuo aiuto aggiungi getProductArticles(Mage_Catalog_Model_Product $product)
14. Se si sovrascrivono le classi, inserirle in un readme.txtfile
15. Utilizzare il percorso admin predefinito per la sezione admin del modulo. URL amministratore errato articles/adminhtml_articles/index . URL di amministrazione corretto admin/articles/index
16. Aggiungi ACL per le sezioni di amministrazione. Potrei voler limitare l'accesso ad alcuni amministratori.
17. Non aggiungere un altro framework JavaScript (jQuery, MooTools, ecc.) Se non è necessario. Scrivi il tuo codice nel prototipo.
18. Rendi il tuo modello HTML W3C valido (questo è per gli sviluppatori OCD come me).
19. Non mettere le immagini nella mediacartella. Usa skin. La media cartella di solito non ha una versione e questo rende più difficile spostare il sito Web in ambienti diversi.
20. Metti alla prova la tua estensione con il catalogo flat on e off. Per non raddoppiare i tempi di sviluppo, usa Chaos Monkey .
21. Metti alla prova la tua estensione con cache one cache off.
22. Evita di usare lettere maiuscole nei nomi dei moduli e delle classi. Se non testato correttamente, ciò può causare problemi su diversi sistemi operativi. Questa è più una raccomandazione, non un "must".
23. Invia eventi nel tuo codice per rendere più semplice agli sviluppatori la modifica della funzionalità.
24. Segui gli stessi standard di codifica utilizzati da Magento e commenta il tuo codice.
25. Non utilizzare tag brevi PHP ( <? $this->doSomething() ?>). Usa tag completi ( <?php $this->doSomething()?>). Inoltre, non utilizzare ancora tag di eco brevi. ( <?="D'oh";?>). Usa ( <?php echo "D'oh";?>)
26. Traduci i tuoi testi usando $this->__e aggiungi il file di traduzione locale con i tuoi testi ( app/local/en_US/Easylife_Articles.csv) almeno per la en_USlingua. Non tutti i siti Web sono costruiti in inglese e l'identificazione dei testi da tradurre richiede tempo.
27. Se vendi un'offerta di estensione, almeno il supporto di base. O almeno rispondi alle e-mail di supporto che ricevi.
28. Non effettuare chiamate costanti ai server tramite l'estensione per la convalida della licenza. Una volta, all'installazione è più che sufficiente (non mi piace neanche questo approccio, ma è meglio che effettuare chiamate in qualsiasi momento). (Ispirato da questa domanda )
29. Sviluppa con il registro attivato e di tanto in tanto dai un'occhiata al var/log/system.logfile. Gli errori elencati qui non vengono visualizzati nemmeno con la modalità sviluppatore attivata. Se si verifica almeno un errore, si ottiene un file di registro di grandi dimensioni dopo alcuni mesi di esecuzione dell'estensione.
30. Se la tua estensione influisce in qualche modo sul processo di pagamento o sugli ordini, assicurati che funzioni con la spedizione multipla o se non dovrebbe funzionare con la spedizione multipla, assicurati che non influisca.
31. Non sostituire la barra di notifica dell'amministratore predefinita (o l'URL del feed). Se sono interessato a ciò che hai da offrire, mi iscriverò alla tua newsletter. Fammi vedere cosa ha da dire Magento. È più importante per me.
32. Se crittografi i tuoi file di codice con Ioncube (o qualcos'altro) ... beh ... ti odio e spero che la tua attività fallisca

Questo è ciò che hanno finora. Aggiungerò altro non appena penserò a qualcos'altro.

Sono un grande fan dell'utilizzo di modman in modo da poter sviluppare e controllare il codice sorgente solo della mia estensione e lasciare invariati i file core e la struttura delle cartelle. Inoltre, rende più agevoli i test su diverse installazioni.

Oh, e un grosso suggerimento cerca sempre di installare l'estensione del pacchetto localmente su un'installazione pulita di magento prima di caricarla su Magento Connect, ho perso così tanti file nel gestore dei pacchetti.

Andreas von Studnitz e la dott.ssa Nikolai Krambrock hanno tenuto una buona presentazione sulla qualità del codice in Meet Magento DE 2014. Si distinguono tra qualità del codice generale e qualità del codice specifica per Magento. In breve, ci sono le seguenti regole generali:

• L'uso di elementi di struttura - proprio come le classi e i metodi - dovrebbe essere organizzato in classi di sequenze centrali. Questi elementi della struttura hanno senso solo quando vengono utilizzati per la strutturazione. Pertanto devono essere di medie dimensioni. Si ritiene che utilizzi 100-200 righe di codice per le classi e 3-20 righe di codice per i metodi.
• A causa dell'uso di "if" o "while" il codice è rientrato. Se sono presenti più di 3 rientri, è meglio rivederli. Troppe rientranze sono la prova della complessità del codice e dovrebbero pertanto essere evitate.
• Il codice morto dovrebbe essere evitato ed eliminato. Le analisi statiche aiutano a trovarlo se ne esiste uno.

Ancora più importanti sono le regole specifiche di Magento:

• I moduli dovrebbero funzionare in modo indipendente. Dovrebbero avere solo poca dipendenza da altri moduli e nessuna dipendenza da modelli. Una soluzione consiste nell'utilizzare gli aggiornamenti del layout (base / predefinito) invece dell'adattamento ai file modello e un modulo che copre le funzioni aggiuntive del modello.
• Per mantenere la capacità di aggiornamenti in Magento core-hack e hack di moduli esterni dovrebbero essere evitati. Un modo migliore è invece l'uso di riscrittori o osservatori.
• Per le modifiche, è preferibile utilizzare gli script di installazione anziché le modifiche dirette del database o dell'amministratore. Grazie a loro i cambiamenti devono essere fatti solo una volta.

Ecco alcuni dettagli e un video della presentazione: http://www.code4business.de/code-quality-magento/

Se vendi la tua estensione o la condividi con altri, pensa a scrivere codice leggibile dall'uomo.

1. non rendere il metodo troppo complesso
2. aggiungi blocchi DOC ai tuoi metodi ^*
3. usa nomi di variabili appropriati, come $productIdsinvece di$ids
4. lo stesso vale per i metodi, public function myOnProductSaveMethod() {...}dice ... niente, ma tryDisableInternetOnProductSave()darà un suggerimento che è stato pianificato
5. usa i suggerimenti sul tipo dove ha senso someMethod(Varien_Data_Db_Collection $collection)
6. evitare numeri e stringhe magici ^**
7. se usi i modelli imposta $_eventPrefixproprietà (e $_eventObject) per renderli meglio accessibili agli osservatori
8. se si aggiungono campi di configurazione del sistema
   • impostare i valori predefiniti in config.xml
   • aggiungi <validate>nodi ai campi insystem.xml
   • aggiungere risorse ACL a adminhtml.xml
9. non aggiungere voci di menu di primo livello inutili / pubblicitarie nel back-end dell'amministratore, né nella barra superiore né nelle sezioni di configurazione
10. aggiungere risorse ACL per tutte le azioni del controller (anche le massazioni!)
11. assicurarsi che le query funzionino con i prefissi delle tabelle DB
12. pensare alla (no) comptibilità all'indietro (si basa davvero sull'opinione pubblica)
    • non supportano le Mysql4classi
    • non utilizzare metodi obsoleti
13. assicurati che la tua uscita funzioni come previsto in ogni caso - aggiungi UnitTests (ad esempio PhpUnit)
14. oltre a David Manners ... aggiungine un altro composer.jsonper rendere più semplice la distribuzione
15. poiché PHP5.6 è EOL, scrivi il tuo codice per PHP7. Utilizzare declare(strict_types=1);e definire i tipi di input e output
16. Magento2: controlla il tuo codice con strumenti di analisi del codice statico come phpstan . Supporto per metodi magici qui . (l'ultimo commit funziona con 2.3, prima per 2.1 / 2.2 - che richiede phpstan 0.8.5)

^{* Blocchi DOC:}

Se controlli il tuo codice Magento-1 con PHP_CodeSniffer per lo standard PSR2 o PHPMD, potresti voler aggiungere queste righe (dove ha senso) ...

• alle classi
  • @phpcs:disable PSR1.Classes.ClassDeclaration.MissingNamespace
  • @phpcs:disable PSR2.Classes.PropertyDeclaration.Underscore - proprietà ereditate
  • @phpcs:disable Squiz.Classes.ValidClassName.NotCamelCaps
  • @SuppressWarnings(PHPMD.CamelCaseClassName)
  • @SuppressWarnings(PHPMD.CamelCasePropertyName) - proprietà ereditate
• ai metodi
  • @SuppressWarnings(PHPMD.CamelCaseMethodName) - metodi ereditati
  • @SuppressWarnings(PHPMD.StaticAccess)- se usi Mage::o altre chiamate statiche

^{** Spesso usato:}

• ID store admin
  • 0 > Mage_Core_Model_App::ADMIN_STORE_ID
• Prodotto status
  • 1 > Mage_Catalog_Model_Product_Status::STATUS_ENABLED
  • 2> Mage_Catalog_Model_Product_Status::STATUS_DISABLED (non 0come forse previsto)
• Prodotto type
  • simple > Mage_Catalog_Model_Product_Type::TYPE_SIMPLE
  • bundle > Mage_Catalog_Model_Product_Type::TYPE_BUNDLE
  • configurable > Mage_Catalog_Model_Product_Type::TYPE_CONFIGURABLE
  • grouped > Mage_Catalog_Model_Product_Type::TYPE_GROUPED
  • virtual > Mage_Catalog_Model_Product_Type::TYPE_VIRTUAL
• Prodotto visibity
  • 1 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_NOT_VISIBLE
  • 2 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_CATALOG
  • 3 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_SEARCH
  • 4 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_BOTH

Lo stesso vale per l'ordine SQL ASCvs Zend_Db_Select::SQL_ASC (ad esempio) .

Dire "non è una causa essenziale perché non cambierà mai" ? Ad esempio, l'ID entità per gli catalog_productattributi è cambiato da Magento 1.5 a 1.9 da 1.9 10a 4, quindi ciò potrebbe interrompere l'estensione:

$collection->addFieldToFilter('entity_type_id', 10)

Usarlo invece aggiunge una query, ma sarai al sicuro ...

$entityTypeId = Mage::getModel('eav/config')
    ->getEntityType(Mage_Catalog_Model_Product::ENTITY)
    ->getEntityTypeId();

$collection->addFieldToFilter('entity_type_id', $entityTypeId)

@marius, per quanto riguarda gli standard di codifica (punto 24 dell'elenco).

Mi piace usare PHP_CodeSniffer insieme a EQP ed ECG CS per applicare automaticamente questi standard.

Utilizzando PHP_CodeSniffer non devi preoccuparti di dimenticare le cose come la sostituzione array()con [], evitare di utilizzare is_null, lasciare le variabili locali non utilizzati o anche un metodo senza blocco PHPDoc.

PHP_CodeSniffer te ne parlerà sempre.