it-swarm.asia

WordPress geliştirme için hangi süreci kullanıyorsunuz?

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 düzenleyici bunu kesmiyor. Şu anda, sadece IDE ile PHP eklentisi (NetBeans) kullanıyorum, geliştirme web dizini sunucumdan aşağı çekiyorum, orada düzenleme yapıyorum, test etmeye başladım ve sonra yaşamaya geçmek.

Diğer insanların, 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. Başkaları 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 belirli WordPress geliştirmeyi destekleyen yazılım araçları 'yı tartışmaktadı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.

37
Thomas Owens

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, tüm yeni bir vhost kurma ve en son WordPress etiketini (svn'yi takip eden kendi git depomuzdan) kontrol etme işiyle ilgilenen bir Shell scriptim 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ı ( http://github.com/dxw/wp-capistrano ) içerir. Ayrıca bu havuzun içine temayı ve eklentileri git alt modüller olarak ekliyorum (evet, üçüncü parti eklentiler için de git depolarını koruyoruz - bizzat 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, kademelendirme/üretim makinelerinde capistrano tarafından ayarlanır, bu nedenle arama/değiştirme yapılmaz).

Bu senaryolarla kaç saat tasarruf ettiğimi hayal edemiyorum.

20
tomdxw

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 varyasyonunda yerel bir Apache web sunucusu ile başlamaktır.

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

Eklentinizi IDE öğenizde düzenlerken, yaptığınız değişiklikler, açıkça her wordpress kurulumunda gösterilecektir, bu nedenle birden fazla wordpress varyasyonunu 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.

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

Bir IDE Coda benim için yapıyor ama ben 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.

5
leetagg

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

Gelişen

Tüm gelişimimi SSH üzerinden yapıyorum, Vim inside GNU screen . Vim eklentileri şunları içerir:

Dikey bölmeler ve :set hidden esastır. Ayrıca railscasts color şemasıyla 256 renkli terminali ( iTerm Mac OS X'te) tercih ediyorum.

Ayrıca ihtiyaçlarımızı karşılamak için dBug 'yi yavaşça değiştiriyoruz. Değişkenin bir dizi veya nesne olduğunu bildiğiniz zaman print_r() ve var_dump() için hoş bir seçenek.

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.

3
Annika Backstrom

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 yardım için div {outline:1px solid red;} ekleyin.

  • 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

3
Chris_O

İş 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ı konumlarda 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 soru 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ı ile istemciyi Textmate ve GittiApp uygulamasında biraz kullanıyorum.
3
Ryan Gibbons

Bana yardımcı olan bir şey (özellikle birden fazla istemci temasında çalışırken), dev sunucumda bir WordPress Multisite kurulumu kullanmak. Bu şekilde, ihtiyaç duyduğum kadar açık işim olabilir ve A müşterisini görmek için B müşterisinin temasını merak etmeyin. 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.

1
Keith S.

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 bildiriyorum.

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

0
hakre

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

  • Web sitesinin gereksinimlerini ve tasarımlarını alır almaz projenin dizinini oluşturmaya başlıyorum.
  • git'i kullanarak Static Klasörlerinde Dynamic ve theme/plugin klasörlerinin sürümlerini kullanın.
  • proje için sanal Host oluşturun. Bu sözleşmeyi takip ediyorum:

    http://project1.dev/

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

  • Genellikle 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 güne build__ aracı kullanmadığımı biliyorum, bu da beni kötü hissettiriyor.

Ancak, ANT'nin yapı aracını, Sprite2CSS projem için ANT'nin tüketimi için birkaç PHP betiği ile birlikte kullanıyorum.

Araçlar


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

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

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

0
Junaid Qadir

Denver , FileZilla, Notepad ++, Firefox Firebug ve diğer denetçilerle (bağlantılar yukarıda), cPanel ve dSForge Studio for MySQL ile çalışıyorum

0