Başkalarının WordPress için nasıl tema ve eklenti geliştirdiği ile ilgileniyorum. Bana göre, yönetici panelindeki tarayıcı içi editör bunu kesmiyor. Şu anda, sadece bir PHP eklentisi (NetBeans) içeren bir IDE kullanıyorum, geliştirme web dizinimi sunucumdan aşağı çekiyorum, orada düzenlemiyorum, test etmek için zorluyorum ve daha sonra yaşamak için geçiyorum.

Diğer kişilerin, WordPress'in en son sürümlerini bunlara karşı geliştirmek, test etmek ve dağıtmak için iş akışlarını yönetmek için tercih ettikleri araçları nasıl kullandıklarını ve bunlara karşı test edilmelerini arıyorum.

Bunu bir topluluk wiki yaptım, böylece başkalarının orada gelişim sürecini paylaşabilir. Burada tekil bir doğru cevap bulmayı beklemiyorum - süreç senin, ve sadece kendin ya da başkası için çalışmanı beklemiyorum. Diğer insanlar için neyin işe yarayıp yaramadığını görerek eklentiler ve temalar geliştirme yeteneğimi geliştirmekle ilgileniyorum.

Buradaki başka bir soru, WordPress geliştirmeyi desteklemek için özel yazılım araçlarını ele almaktadır . Burada, yalnızca belirli bir araç ailesinde gerçekleştirilebilecek bazı görevler haricinde, araçlardan bağımsız olarak uygulanabilecek daha fazla işlem ve metodoloji arıyorum.

Kayıt için ağırlıklı olarak tüm Web sitelerini ve eklentileri oluşturuyorum ve dağıtıyorum. İş akışım çok Ruby ve git-heavy.

Yeni bir projeye başlamak için, yeni bir vhost kurma ve en son WordPress etiketini (svn'yi takip eden kendi git depomuzdan) kontrol etme işini yürüten bir kabuk betiğim var.

Bütün bir Web sitesinin temel şekli wp-içerikte bir git repsotory. Bu bir Capfile (capistrano'nun Makefile eqiuivalent) ve birlikte dağıtımı sağlayan bir YAML yapılandırma dosyası içerir ( http://github.com/dxw/wp-capistrano ). Ayrıca bu havuzun içine temayı ve eklentileri git alt modülleri olarak ekliyorum (evet, üçüncü parti eklentileri için de git depolarını koruyoruz - kişisel olarak test ettiğimiz en son sürümü kullanmak istiyoruz).

Tema için kod oluşturma aracım / çerçevem ​​var ( github.com/dxw/wp-generate ). Kodun nereye gitmesi gerektiği hakkında daha az düşünmek anlamına gelir ve Görünüm ile Model / Denetleyici arasında doğal bir ayırma yöntemi vardır.

Eklentileri yazarken, test odaklı geliştirme yapmak için salatalık / webrat kullanıyorum ( github.com/dxw/cucumber-wordpress ).

Geliştirme veritabanlarını üretime geçirmek için genellikle bu yalnızca dökümü kopyalamak için bir durumdur (WP_SITEURL ve WP_HOME, aşamalandırma / üretim makinelerinde capistrano tarafından ayarlanır, bu nedenle arama / değiştirme yapılmaz).

Bu senaryolarla kaç saat geçirdiğimi hayal edemiyorum.

@Thomas Owens Bu soru, " WordPress tema / eklenti geliştirme için yazılım? " Sorusunu biraz örtüşür ve çoğaltır . Kapatmamız gerekip gerekmediğinden emin değiliz ama biraz farklı bir odaklanma gibi görünüyor. Yani...

Mac OS X

İşte şu anda Max OS X için temel araç setim (her zaman daha iyisini arıyorum.) Not NetBeans'ı denedim ve bundan vazgeçtim. Çok halsiz ve çok az özellik.

• PhpStorm + XDEBUG - Hata ayıklama IDE (MAC'de daha iyi bir şey yok)
• VirtualHostX - Apache Sanal Konaklarını Yerel Olarak Yönetir (Bunu SEVİYORUM )
• FileZilla - FTP İstemcisi
• Firefox Firebug - jQuery Hata Ayıklama
• MySQL için Navicat - Ticari MySQL istemcisi
• Unfuddle.com - Müşteri projeleri için SVN Havuzu ve Görev Yönetimi
• HTTP Scoop - Makul HTTP hata ayıklayıcı
• Fraise - Hafif Metin Düzenleyici ( Smultron Çatal )

Windows Vista

Ben iken Windows Vista benim temel araç grubu oldu:

• FileZilla - FTP İstemcisi
• Firefox Firebug - jQuery Hata Ayıklama
• MySQL için Navicat - Ticari MySQL istemcisi
• Unfuddle.com - Müşteri projeleri için SVN Havuzu ve Görev Yönetimi
• PhpED - Hata ayıklama IDE (Windows'ta daha iyi bir şey yok, 'belki de PhpStorm + [XDEBUG] [24] cept)
• HeidiSQL - Harika açık kaynaklı MySQL istemcisi
• Notepad2 - Mükemmel hafif ve kullanışlı Notepad alternatifi
• KaplumbağaSVN - SVN İstemcisi
• Fiddler 2 - Rakipsiz HTTP hata ayıklayıcı

Etki Alanlarını Değiştirmek İçin Kod Dağıtımı / Veri Geçişi

Tam olarak aradığınız şeyin bu olup olmadığından emin değilim, ancak yerel dev sunucu, test sunucusu ve dağıtım sunucusu arasındaki geçişleri kolaylaştırmak için bir eklenti geliştiriyorum. Bu konuyu burada yazdım:

• WP'yi geliştirmeden üretime kolayca nasıl taşıyabilirim?

Bu yardımcı olur umarım

Mike

Bu, bir IDE veya eklentiye özgü olmayan bir iş akışı yanıtıdır.

Eklenti geliştirme için gerçekten işe yarayan bir çözüm, bir alt klasörde kurulu her wordpress varyasyonuyla yerel bir apache web sunucusu ile başlamaktır.

Yerel sunucu kökünün dışındaki ayrı bir yerde, wordpress eklenti / tema çalışma kopyalarınızı saklayın. Her wordpress varyasyonunun / wp-content / plugins klasöründe uygun trunk / tag / dal ile bir bağlantı oluşturun.

IDE'nizdeki eklentiyi düzenlerken yaptığınız değişiklikler, açıkça her wordpress kurulumunda gösterilecektir, böylece wordpress'in çoklu varyasyonlarını test etmek kolaylaşacaktır.

Temel olarak, her bir yerel wordpress varyasyonu için açık bir tarayıcı sekmesine sahip olabilir ve her birini tek bir proje ve tek bir dosya tabanında çalışırken test edebilirsiniz.

Yapmanız gereken tek şey SVN ve FTP'yi destekleyen bir IDE kullanmak, çalışma kopyanızı düzenlemek ve değişikliklerinizi depoya geri göndermektir.

Bir IDE Coda'nın benim için yaptığı gibi, ancak NetBeans ve Eclipse'i de seviyorum.

Eklentinizin çalıştığından ve bu değişiklikleri havuzunuzda yaptığınızdan memnun olduğunuzda, wordpress projenizi açabilir ve değiştirilen eklentiyi doğrudan canlı sitenize yayınlayabilirsiniz.

~ 2.5 yıl önce bugünkü işime başladığımdan beri gelişen nispeten karmaşık olmayan bir kurulumum var.

gelişen

Ben kullanarak, SSH üzerinden tüm geliştirme yapmak Vim içindeki GNU ekranında . Vim eklentileri şunları içerir:

• zencoding-vim
• FuzzyFinder

Dikey böler ve :set hiddenesastır. Ben de demiryolu renk düzeni ile 256 renk terminalini ( Mac OS X'te iTerm) tercih ediyorum .

Ayrıca dBug'u yavaşça gereksinimlerimize uyacak şekilde değiştirdik . Değişkenin bir dizi veya nesne olduğunu print_r()ve var_dump()ne zaman değiştirildiğini bilmek hoş.

dağıtma

Şu anda pek çok genel eklenti / tema üzerinde çalışmıyorum, bu yüzden WordPress'in çoklu sürümleriyle eklenti uyumluluğunu test etmiyorum. Dev sunucuyu kodluyorum ve bu kodu Subversion aracılığıyla üretime taşıyorum.

WordPress Tema Geliştirme Süreci

• Mock Flow kablo çerçevesini temel XHTML ve CSS'ye dönüştürün

• XHTML'yi master.php şablon dosyasına takın ve Template etiketlerine ve WP işlevlerine dönüştürün

• Master.php dosyasını çeşitli şablon dosyalarına bölün: yani header.php, index.php, sidebar.php ve footer.php

• Gerekli olabilecek her türlü özel sorguyu ve işlevi yazın

• CSS mizanpajını takın ve mizanpajı div {outline:1px solid red;}düzeltmek için ekleyin4.

• Sınama ve daha fazla gelişme için Theme klasörünü WordPress'e yükleyin

WordPress Geliştirme Araçları

• Aptana Studio WorkPlace dahili FTP ile kod editörü

• Macun

• tarayıcı açıkken, diğerinde kod editörlü çift 1920 x 1200 monitör

• Wacom Intuis 4 tablet

• Yslow ve Google Page hızında Firebug

İş akışım oldukça basit. 4 ortama ayak uyduruyorum. Test, Geliştirme, Aşama ve Üretim.

İş Akışı

Revizyon kontrolüm için git kullanıyorum; Wp-config.php dosyasını görmezden geliyorum, bu yüzden farklı konumlar arasında itip çekerken bu dosyanın üzerine yazılmıyor. Başkalarının itip çekmesi için ortak / merkezi depo olarak unfuddle'ı kullanıyorum.

Bu oldukça iyi çalışıyor gibi görünüyor. Testler üzerinde çalışırken hatırlayabildiğim kadar çok söz vereceğim. Günde en az bir kez, daha fazla değilse, unfuddle ile senkronize olur ve Geliştirme sunucusunun değişiklikleri çekmesini sağlarım. Sunucu üzerinde herhangi bir doğrudan çalışma yapmamaya çalışıyorum, bu yüzden çoğunlukla sadece değişiklikleri yapıyorum. Önemli veritabanı değişiklikleri yapıldıysa (yeni eklentiler, güncellenmiş içerik, vb.), O zaman onu Test'imden çıkaracağım; Geliştirme'nin bir yedeğini alın ve çöplüğü alın.

Aynı işlemi Staging için de kullanıyorum. Evreleme, aynı üretim sunucusunda oturur; cilayı iki kez kontrol edin ve tüm ayarların ve modüllerin üretim sunucusunda çalıştığından emin olun. Hazır olduğumda, tüm üretim dosyalarını ve veritabanını yedeklerim ve dosyaları ve veritabanını aşamalı olarak kopyalarım.

Wp-config.php gitmediğinden, etrafta itme ve çekmeyi oldukça kolaylaştırır. Üretime geçişten itibaren taşınırken dosyaları kopyalarım ve git kullanmam, bu yüzden wp-config.php dosyasının doğru olduğundan emin olmalıyım.

Bir simliar sorusu sordum ve bu eklentiyi kullanmaya çalışacağım.

Capistrano'yu kullanmayı da düşündüm; ve dosya yollarını ve URL'leri güncellemenin yanı sıra tüm dosyaları ve veritabanı yedeklerini / geçişlerini gerçekleştirecek ve işleyecek çok ayrıntılı bir geçiş komut dosyası oluşturma.

Araçlar

• Editörüm için Textmate, MacVim'i kullanmaya başlıyorum. Linux olduğunda vim kullanıyorum.
• Veritabanı manipülasyonu için Sequel Pro. Bağlanamazsam PHPMyAdmin kullanacağım
• İhtiyacım olursa FTP için ilet.
• revizyon kontrolü için git. Çoğunlukla komut satırıyla, istemciyi Textmate ve GittiApp uygulamasında biraz kullanıyorum.

Bana yardımcı olan bir şey (özellikle birden fazla istemci temasında çalışırken), dev sunucumda bir WordPress Multisite kurulumu kullanmak. Bu şekilde, gerektiği kadar açık işe sahip olabilirim ve müşteri A'yı gören müşteri B'nin teması hakkında endişelenmeyin. Bunu, her yeni bir site oluşturduğumda yüklediğim kapsamlı bir örnek içerik paketi ile birleştirin ve harika bir geliştirme sisteminiz var.

Sürüm kontrol sistemlerini ve otomatik testleri kullanarak, bir yaşam sisteminin bağırsaklarında sunucuya hacklemekten daha yapılandırılmış geliştirme / test / sahne / yaşam döngüsüne kadar yapıyorum. Bu sadece işe bağlı.

Bunun yanında, onları çalıştırdığımda, hataları wordpress projesine geri bildiriyorum.

Eklenti geliştirme için, tekerleği her zaman yeniden icat etmemeye çalışıyorum;

İşte benim iş akışım:

• Web sitesinin gereksinimlerini ve tasarımlarını alır almaz projenin dizinini oluşturmaya başlıyorum.
• versiyon Staticve theme/pluginklasör DynamicGit kullanarak klasörler.

• proje için sanal ana bilgisayar oluşturun. Bu sözleşmeyi takip ediyorum:

  http://project1.dev/

  http://project1.static.dev (isteğe bağlı olarak)

• Genelde bu klasör organizasyonunu izlerim:

  Projects
         Project1Name
                     Docs //Requirements docs, emails, other related documents. 
                          //This directory may contain directories with  names as dates
                          //(e.g 2014-01-01) to stay super organized :)    
                     Designs //All PSDs go here  
                     Data  //Database backup for the project,
                     Site
                         Dynamic //WordPress generally
                         Static //I don't always create a static version. I did a couple  
                                //of times in the past. I use the same structure inside
                                //the theme or plugin I'm developing
                               js
                               css
                               img
  
         Project2Name and so on ...
  

Günden buildgüne henüz bir alet kullanmadığımı biliyorum , bu da kendimi kötü hissettiriyor.

Ancak Sprite2CSS projem için ANT oluşturma aracını , ANT tüketimi için birkaç PHP betiği ile birleştim.

Araçlar

Windows veya Ubuntu'da olsam da, aşağıdakileri kullanıyorum:

• NetBeans + SublimeText2 + Notepad ++
• WAMP - (PHP)
• fakemail
• Git
• Test için Firebug ve Safari + IE içeren Chrome ve DevTools + Firefox
• YSlow!
• Filezilla / WinSCP / NB'nin dahili FTP'si
• Cygwin + Komut istemi
• Besteci
• DüğümJS + NPM
• SQLYog Topluluğu Sürümü + PHPMyAdmin

İş akışımı iyileştirme konusunda önerilere açığım.

Birlikte Windows üzerinde çalışmak Denver , FileZilla, Notepad ++, Firefox Kundakçı ve diğer müfettişler (bağlantılar yukarıda idi), cPanel ve dbForge Studio MySQL için