Her ne kadar istemesem de, son zamanlarda web geliştiriciliğinden para kazanırken buldum kendimi. Bu süreç içerisinde farklı yazılımlar deneyerek OS X’in rahatlık çerçevesinden çıkmadan istediğim esnekliği sunan konfigürasyona ulaştığıma inanıyorum. Size işte bu kararlarımdan bahsedeceğim.

Öncelikle biraz ne tür geliştirme yaptığımdan bahsedeyim, çünkü işinize yaramayan bir şeyse eğer yazdıklarım, boşuna vakit kaybetmenizi istemem. Mesela, ASP.Net geliştiricilerine hiçbir faydam dokunmayacaktır. Sunucu taraflı programlama dili olarak PHP ağırlıklı çalışıyorum. Eğer yayınlama ağırlıklı bir yazılım geliştiriliyorsa WordPress (ve kardeşleri), tamamen alakasız bir yazılım isteniyorsa CodeIgniter framework’ünü kullanıyorum.

Sunucular

PHP ile çalıştığım için UNIX tabanlı bir işletim sistemi birçok açıdan tek pratik tercih. Zaten ucuz hosting ve VPS isteyenlerin de Linux’tan başka şansı pek yok. Üstelik Windows’ta ortaya çıkabilecek birçok hatayı da önceden elemiş oluyoruz.

Kolay yol: MAMP/MAMP Pro

Uzunca bir süre kullandığım ilk sunucu yazılımı MAMP Pro idi. MAMP Pro, ücretsiz MAMP‘ın oldukça gelişmiş versiyonu. İkisi de temelde Apache, PHP, MySQL ve phpMyAdmin kuruyor sisteminize.

MAMP sadece Apache ve MySQL portu, Apache ana klasörü (yani http://localhost/’a girince hangi klasörün açılacağı) ve PHP versiyonu ile Cache sistemini seçmeye izin veriyor. Bir nevi, sistemle gelen web sunucusunun PHP ve MySQL destekleyen versiyonu gibi.

MAMP Pro ise, bunların yanısıra, istediğiniz Apache modüllerini açıp kapatmanızı sağlıyor, Apache/MySQL için kullanıcı belirlemenize izin veriyor, Postfix ayarlarını yapmanız için arabirim sunuyor, hangi PHP hatalarının hata kaydına yazılacağını seçmenize izin veriyor. Fakat en önemlisi, virtual host desteği ile sizi localhost’a bağımlı kalmaktan kurtarıyor. Üstelik bunu çok basit bir arabirimle sağlıyor, ve /etc/hosts dosyasına gerekli girdileri de kendisi giriyor. Değişik projeler geliştiren bir geliştirici için olabilecek en rahat sunucu yönetim aracı.

Zor Yol: VMware Fusion & Ubuntu Server

Aslında doğru başlık “Sanal Makine & Linux” olurdu herhalde, zira VMware Fusion ve Ubuntu Server, sadece benim tercihlerim. Bunun yerine Virtualbox ve Arch veya Parallels Desktop ve CentOS da olabilirdi.

Bunun mantığı, temel olarak, bilgisayarınızın içinde bir VPS ortamı taklit etmek. VMware sizin sanal makinenize bir adet IP adresi veriyor, ve siz bir yer sağlayıcıdan aldığınız VPS’e nasıl SSH’le veya SFTP’yle ulaşıyorsanız, bu sisteme de aynı şekilde ulaşıyorsunuz.

Bu sunucu, tabii ki hiçbir şeyle gelmiyor. PHP’sinden Apache’sine, MySQL’inden phpMyAdmin’ine her şeyi sizin kendi ihtiyaçlarınıza göre kurmanız gerekiyor, tıpkı VPS’lerdeki gibi. Şu anda VPS kurulumu yapmayı anlatmayacağım, en azından bu yazıda. Zaten daha önce WordPress’i VPS’lerde sağlıklı bir şekilde çalıştırmak için gereken birkaç ayarın nasıl yapıldığını anlatmıştım, benzer yazılar da daha sonra gelecek. Ama şimdi, yazılım geliştirmek için bu sanal makine içerisinden sistemi Mac OS X’le nasıl uyum içinde kullandığımı anlatacağım.

Sunucuyu VMware içerisinde kurup çalışmaya bıraktıktan sonra arkaplanda çok güzel bir şekilde gizleyebiliyorum. Sistemle iletişime geçmek için iki yazılım yetiyor: Terminal ve Transmit.

Terminal, bildiğiniz Applications > Utilities içerisinde bulunan Terminal.

ssh 192.168.41.128¹ komutunu girerek sunucuma bağlanabiliyorum.² Bunun ardından sunucumu yönetmek adına gireceğim tüm komutları, virtual host aktive etmek için gereken a2ensite komutundan MySQL sunucusu kurmak için gereken apt-get install mysql-server komutuna her şeyi buradan yazıp halledebiliyorum.

Sunucuyu yönetmeyi hallettik… Peki ya dosyalara erişim? İşte Transmit de orada devreye giriyor. Aslında herhangi bir FTP yazılımıyla SFTP kullanarak sunucunuza bağlanabilir ve dosya aktarımı yapabilirsiniz, ama Transmit’in ek bir güzelliği var: Belirttiğiniz sunucudaki belirttiğiniz klasörü tıpkı bir USB bellek veya harici disk -veya harddiskinizdeki başka bir bölüntü- gibi Mac OSX’inize bağlayabiliyor. Böylece sunucunuzdaki dosyaları tıpkı bilgisayarınızdaki herhangi bir dosyaymış gibi görüntüleyip düzenleyebiliyorsunuz. Özellikle bir framework kullanarak birden fazla klasörde gezinip çok sayıda dosya düzenliyorsanız, bunu destekleyen metin editörleriyle kullanabilmek büyük rahatlık sağlıyor.

Editörler

Peki neden bu kadar kasıyorum? Yani, tercih ettiğim sunucu ortamı Linux’sa, neden Mac OS X içerisinde bir sanal makina yazılımıyla ikinci bir işletim sistemi açıyorum, RAM’imin ve işlemcimin bir kısmını ona ayırıyorum? Direkt Ubuntu kurup onun üzerinde geliştirme yapsam olmuyor mu?

Yazılım geliştirmenin tek bir bileşeni yok. Yazılan dil ve dilin çalıştığı ortam kadar önemli olan bir diğer bileşen de kodun yazıldığı metin editörü. Mac OS X, ister web geliştirme için olsun, ister diğer diller için olsun, çok güzel yazılımlarla kutsanmış bir işletim sistemi. Yıllardır kullandığım TextMate ile yeni kullanıp vazgeçilmezlerim arasına aldığım Espresso, kod düzenlemek için tercih ettiğim iki yazılım.

Espresso

Espresso, MacRabbit’in web geliştiricileri için ürettiği bir yazılım. Tamamen web yazılımı geliştirmek üzerine kurulmuş. Canlı önizleme, dosya aktarım araçları, gezinme yardımcısı, kod tamamlayıcı “şekerleri” ve daha pek çok özelliği web geliştiriciler için özel olarak düşünülmüş ve yaratılmış.

Espresso’nun en sevdiğim özelliğiyse, Espresso Mono ismindeki kendi içinde gelen yazıtipi. Okuması çok rahat, ve insanı kod yazmaya sürüklüyor. Yani, en azından beni.³

Özellikle Workspace özelliği çok hoş. Aslında, sekme kullanmak yerine alt alta dizmeyi tercih etmişler açık olan dökümanları sadece, fakat yıllardır sekmeli metin editörü kullanan biri olarak değişikliğe alışmakla kalmayıp, âşık olmayı da becerebildim. Ben meğerse metin editöründe sekme sevmiyormuşum. Hah, kim bilebilirdi ki?

Espresso’nun 79.95$’lık bir fiyatı var, 133.08TL’ye geliyormuş.⁴ Ben bu paraya almadım, satın aldığım bundle’lardan birinde gelmişti, ona rağmen de uzun bir süre kullanmadım. Tavsiyem önce 15 günlük demosunu indirip tercih ettiğiniz dilde ufak bir yazılımcık yapmaya çalışmanız.

TextMate

Espresso’dan önce uzunca bir süre TextMate‘le yaptım geliştirmelerimi. Fakat tek kullandığım özelliği soldaki dosya listesi ve seçtiğim dosyaları üstte sekme olarak açmasıydı. Espresso’nun aksine, seçilen dosyayı “yukarıya” dosya düzenlenmeye başlandığında değil, tıklandığı anda atması, bir yerden sonra sinir bozucu oluyordu. Hele “geri alma” özelliğini harf harf yapması var ki, insanı çileden çıkartır.

Fakat TextMate’i basit bir metin editörü olarak kullanmak, tabii ki sadece benim yaptığım bir hatadan ibaretti. TextMate’in çok güçlü bir “bundle” özelliği var ve kod tamamlama dahil birçok şey yaptırabiliyorsunuz. Öyle ki, Espresso’nun kod tamamlaması biraz oyuncak gibi kalıyor yanında. Twitter’ın geliştiricilerinden (ve BasÇek’teki şu yazımın asıl sahibi olan) Dustin Diaz’ın YUI temelleri ve Javascript DOM hijacking’i (gasp etmek?) anlattığı bu videoyu izlerseniz TextMate’in gücünü görmeniz mümkün.

TextMate’in 2.0 versiyonu sözde 2 yıldır çıkacak. 1.5 versiyonu 39Euro, ve 30 günlük deneme sürümü bulunmakta. İndirip denemenizi yine tavsiye ediyorum.

CSSEdit

CSSEdit aslında tam olarak bir metin editörü değil. Espresso ve TextMate’le her türlü dosyayı düzenleyebilirken, CSSEdit’te sadece CSS düzenleyebilirsiniz. Fakat X-ray özelliğiyle sitenizin düzenlemek istediğiniz elemanının ismini-cismini hemen bulabilirsiniz ve Inspector ile bu bulduğunuz elemanın CSS dosyasındaki konumuna hemen gidebilirsiniz, ve düzenlemeleri yaparken anında değişikliklerinizi görüntüleyebilirsiniz. Kod tamamlama ve CSS 2.1 özelliklerini içinde barındıran “görsel editörü” ile CSS düzenlemek çok kolaylaşıyor.

CSSEdit de, Espresso gibi, bir MacRabbit yazılımı. $39.95′e satılıyor, ki bu da yaklaşık 65TL’ye denk geliyor. Deneme sürümü, Espresso’nun aksine, zaman bazlı değil, sadece 2500 karakterden büyük CSS dosyalarını kaydetmenize izin vermiyor. Açıkçası, hangi dili kullanarak yazılım yazarsanız yazın, arabiriminiz için CSSEdit’i mutlaka denemek isteyeceksiniz.

Coda

Daha önce kullanmayı deneyip bir nedenden vazgeçtiğim bir yazılım. Coda, yukarıda bahsettiğim Transmit’i yapan Panic’in yarattığı bir yazılım ve Espresso’ya çok benziyor özellik olarak. Aslında Espresso’dan daha çok özellik barındırıyor fakat ben nedense kendisine bir türlü ısınamadım. 99$’a satılıyor. Deneme sürümü bulunmakta.

Sonuç

Aslında niye “sonuç” diye başlık attığımı bilmiyorum. İlkokuldan kalma alışkanlık herhalde, yazılarda “giriş-geliştirme-sonuç” olacak ya illa… Neyse.

Açıkçası, bu yazıda sadece çalışma alışkanlıklarımdan bahsetmek ve bilmeyenler için birkaç alternatif göstermek istedim. Her yazılımın, her yöntemin bir diğerine göre avantajları ve dezavantajları var. Kendi tercihleriniz ve alışkanlıklarınıza göre uygun gördüğünüz seçimi yaparak bazı işlemleri kolaylaştırıp baş ağrınızı minimuma indirmek elinizde.

1. O IP adresi, 192.168.41.128, VMware’ın Ubuntu Server için aldığı IP adresidir, sanal makine içerisinde ifconfig komutunu çalıştırarak öğrenebilirsiniz.
2. Mac OS X kullanıcı adımla Ubuntu Server kullanıcı adım aynı olduğundan girme gereksinimi duymuyorum, yoksa ssh cemk@192.168.41.128 olacaktı.
3. Beni nelerin kod yazmaya sürüklediğini liste yapıp yayınlasam şaşarsınız aslında.
4. MacRabbit’in satış sistemi otomatik olarak para birimini yerelleştiriyor. Zaten satın alma sayfası da Türkçe.

“Yemek söylemek” deyince akla neresi geliyor? Tabii ki yemeksepeti.com. Ferahevler’deki Aslı Börek sistemde var mı diye baktım, var. Ama 8′de açılıyor, 8.45′te getiriyor. Fakat sipariş verme aşamasında YemekSepeti’nin sunduğu seçenekler, sanki başka türlüsü mümkünmüş hissi veriyor.

İlk önce dükkanın sayfasına girince şu uyarıyla karşılaşıyoruz:

Bu restoran şu anda servis saatlerinin dışında olduğundan sadece ileriye yönelik sipariş verebilirsiniz.

Bana uyar. Sorun değil. “Sepeti Onayla” tuşuna basıp adresimizi de seçtikten sonra teslimat saati seçim ekranına geliyoruz. Peki seçili gelen seçenekler neler? “Bugün” ve “Hemen (~45 dak.)”.

“Hemen”in yanında “45. dakika”nın belirtilmesi, çok hoş mesela. Restoranın sayfasında belirtilen teslimat süresinin sipariş onay sayfasında bu şekilde belirtilmesini çok beğeniyorum. Fakat sorun, 45 dakika sonrasının hâlâ saat 8.00 etmiyor oluşuydu. Hani 8.00′de açılıyordu Aslı Börek? Aşağıya inip “Siparişi Ver” butonuna basıyorum.

Veriler gönderiliyor, veriler alınıyor, sayfa değişiyo— derken, aynı sayfa geri geliyor. Sonra hop, üzerinde bir uyarı:

Paketinizin gönderilmesi için belirttiğiniz zaman restoranın çalışma saatleri dışında kalıyor.

Adam haklı. Restoranın çalışma saati 8.00 olarak belirtilmişti. 7.55, 8.00′den daha önce haliyle. “Çalışma saatlerini deneyelim o zaman” dedik, çünkü malum, uyarı “çalışma saatleri dışında” diyordu bizim için seçilmiş olan saate.

8.15, çalışma saatleri içindeydi. Onu denemeye karar verdim.

Veriler gönderildi, veriler alındı, sayfa değiş— derken, yine aynı sayfa. Üzerine yeni bir uyarı:

Paketinizin gönderilmesi için belirttiğiniz zaman bu restoran için şu andan/restoran açıldıktan en az 45dk sonra olmalıdır.

Az önce “çalışma saati içinde değil” diyordun, e bu çalışma saati içinde? Ama öyle olmuyor işte. 8.45′e ayarlayınca saati, siparişimi verebildim.

Buradaki hatalar nelerdir?

Açıkçası, burada bir hata yok. En azından yazılımsal olarak. Sonuçta belli bir kural var, ve yapılan tercihlerin o kurala uyup uymadığı kontrol edilip duruma göre bir tepki veriliyor.

Fakat kullanılabilirlik açısından gösterilen ilk uyarıda büyük bir hata var: “Mesai saatleri dışında” hatasının teslimat süresi ile ilgili bilgiyi de içinde barındırması gerekiyor. Çünkü o uyarıya göre “8.00′dan sonraki herhangi bir zaman dilimi uygunmuş” havası veriliyor, fakat 8.45′ten öncesi aslında uygun değil.

Bir diğer hata da, zaten 8.45′ten öncesi ve gece belli bir saatten sonrası uygun olmayan bir dükkan ve sipariş için 24 saatlik bir dilimin seçilebilir olması. Ama benim tavsiye edeceğim iyileştirmeler bunu ortadan kaldıracağı için üzerinde durma gereksinimi duymuyorum.

Peki bu sorunlar nasıl düzeltilir?

• Bu restoranların belli çalışma saatleri bulunmakta. Hem restoranın sayfasında, hem de hata ekranında bunları görebiliyorsak, teslimat saati seçme aşamasında da sadece bunların arasından seçme şansımız olmalı. Sabah 8-akşam 10 çalışan bir dükkanın sipariş sayfasında gece 3′ü görmenin bir anlamı yok.
• “Hemen (~45 dak.)” seçeneği, o an açık bulunmayan restoranlar için farklı olmalı. Hem etiketi değişmeli, hem de yazan süre açılış saati ve teslimat süresini bir şekilde belirtmeli. “En yakın süre (~8.45am)” gibi bir seçenek uygun olabilir.
• Bunların hiçbiri olmadı, yanlış bir saat seçildiğinde “Siparişi Ver” butonu devre dışı olmalı, böylece kullanıcı siparişte bir hata olduğunu görebilmeli —tabii hatanın ne olduğu da belirtilmeli. Bu şekilde hem sayfanın tekrar tekrar yüklenmesi sorunu ortadan kalkacağı gibi, hem de oldukça sık rastladığım bir soruna¹ çözüm getirecektir.

Bu tarz iyileştirmeler genelde gözden kaçar, akla gelmez. Master programım bunun üzerine yoğunlaştığından ve son bir senemi bu tarz çözümler yaratarak geçirdiğim için daha önceden görmeme rağmen hiç dikkatimi çekmeyen bu sorunlar, Türkiye’ye döner dönmez verdiğim ilk siparişte gözüme battı. Umarım YemekSepeti bu değişiklikleri bir gün bir şekilde devreye sokar.

Tabii önce kahvaltımın gelmesini sağlaması tercihimdir. Zira 8.49 oldu, ve ben acıktım.

1. Bazı arkadaşlarım, iş yaparken acıkınca yemeklerini seçip “Siparişi Ver” düğmesine tıklar tıklamaz ya tarayıcıyı gizliyor, ya da başka sekmeye geçiyor. Bir hata olması durumunda da “nerede kaldı bu siparişim” demeden önce siparişi aslında veremediğini farketmiyor. Devre dışı bir düğme, kendisine bastırtmayacağı için, sorun önceden görünecektir. Bir taşla iki kuş, kısaca.

En son ilginçlik ise, Ocak’a kadar kalabileceğim ama yine de “sonunda ev buldum!” dediğim yere geçtiğim zaman, nook’umu çıkarıp kitap okuma isteğimle bunu yapamayacağımı farketmem oldu. nook, 3 hafta bavulda kapalı kal(mak zorunda kal)dığı için pilini yemiş, tüketmiş, bitirmiş, ve inatla açılmıyordu.

Şarja takarsın, pili doldurursun, düzelir, değil mi? Hayır. Şarja takınca açılıyordu, tamam, ama pilin yerinde bir soru işareti çıkıyor ve inatla dolmuyordu. Bütün bir gece beklettim, olmadı.

Ben de bunun üzerine yapılabilecek en büyük hatayı yaptım: Sorunun çözümünü Google’da aradım. Temel olarak şu yöntemi söylüyorlardı.

1. nook’u kapat.
2. Pili çıkar.
3. Cihazı prize bağla.
4. Açıldıktan sonra pili geri tak, şarjda bırak.

Bir gün de bununla geçtikten sonra, baktım hâlâ hareketlenme yok, alternatif yöntemler aradım. Pili çıkart, buna bas, şunu yap derken cihaz ilk aldığım yazılım sürümüne geri döndü. “Bu iyi olamaz” diye düşünürken bir de üzerine nereye girmeye çalışırsam çalışayım cihazın kendini kapatıp açması sorunsalı başladı. En sonunda ise e-mürekkepli ekranı karardı ve alttaki ekran açılmamaya başladı.

nook’u bozmuştum.

Küfrederek ne yapabileceğimi düşünmeye başladım. nook’u geri toparladım, kenara koydum, ve yöntemler aramaya başladım… Uyuyakalmışım.

Sabah kalkıp telefonumu elime alınca gördüğüm “pil bitiyor” uyarısı, “dün akşam şarja taktığım bu değil miydi?” sorusunu beraberinde getirdi. Meğerse nook’u şarja takmışım. Ve sabah kalktığımda, cihaz pili dolu bir şekilde açıktı.

Bundan çıkarttığım sonuçlar şöyle:

• Apple olmayan her elektronik ürün elbet birgün saç-baş yolduracak şekilde sorun çıkartıyor. Düzelip düzelmemesi kendi insafına kalmış.
• Android denen işletim sistemciği, iOS kadar stabil değil. En azından adam gibi bir fail-safe modu yok.
• nook (veya Kindle) alıp da kitap okumamak olmazmış. 3 hafta köşede yatırınca içten içe, kendi kendini yermiş alet.
• The Girl With The Dragon Tattoo fena kitap değilmiş.

Dipnot: İsveç’le ilgili bir fotoblog açmaya çabalıyorum. Alan adını aldım bile: itsaswedishthing.com. Sadece fotoğraflarımı işleyip yazılarını yazmam lazım. Bir de alan adını posterous’dan tumblr’a yönlendirmem. Bir de temayı elden geçirmem. (Of yoruldum.)

VPS’lerde ise bunun için kendimiz uğraşmamız gerekiyor. Birçok sorunun çözümü yokmuş gibi gözükse de, aslında çok basit bir şekilde tüm özellikler çalıştırılabiliyor.Öncelikle VPS’lerde başımıza gelebilecek hatalara bir göz atalım:

Dosya Yükleme: WordPress’in dosya yükleme sistemi süper çalışıyor. Özellikle fotoğraflar için mucizeler yaratıyor sistem. Otomatik olarak farklı boyutlar yaratıyor, tarihe göre klasörlere atıyor, hatta otomatik olarak galeriler yaratmanıza izin veriyor. Fakat VPS’lerde dosya izinleri nedeniyle bunların hiçbirini yapamıyor. Bunun için ya /wp-content/uploads dizinine 777 izni veriyorlar, veya kullanıcısını www-data yapıyorlar ki, birincisi büyük bir güvenlik açığı, ikincisi ise kullanıcının kendisinin dizini kullanamaması anlamına geliyor.

Otomatik güncelleme, eklenti/tema yükleme: WordPress’i 1.5 sürümünden beri kullanan biri olarak en başta ben sorabilirim “ananınızın karnından otomatik güncellemeyle mi doğdunuz” diye. Fakat sağladığı rahatlığı tattıktan sonra vazgeçemiyorsunuz. Ne yazık ki, dosya izinlerini tamir etseniz bile bu özellik inatla çalışmayabiliyor. FTP bilgilerini verince çalışabilme ihtimali olsa da, çoğu kullanıcı VPS’ine FTP sunucusu kurmamayı tercih ediyor.

Önemli not:

Ben 2 yıldır VPS kullanmama rağmen, Slicehost’ta Debian kullanırken Zerigo’da Ubuntu’ya geçtim. Kısaca kullanacağım kullanıcı isimleri ve terimler, özellikle www-data, Debian tabanlı dağıtımlara özgü olabilir. Başka dağıtımların sunucu grubu için apache veya nobody kullanabildiğini gözönünde bulundurup dağıtımınıza göre ayar yapmak isteyebilirsiniz.

Aşama Aşama VPS Tamiri

1. Aşama: Dosya İzinleri Belirleme

Bu, bu yazıda okuyacağınız en uzun, en hileli, en karmaşık, ve büyük ihtimalle beceremeyip yine bir güvenlik açığı verdiğim tek bölüm olacak. (Eğer bir hata bulursanız lütfen uyarın, na yorum kısmı aşağıda.)

Öncelikle, www-data grubunu kendi kullanıcımıza eklememiz gerekiyor. Burada, kendi kullanıcı adımın cemk olduğunu varsayıyoruz.

sudo usermod -a -G www-data cemk

Bunun geçerli olduğunu görmek için, çıkış yapıp tekrar girmeniz gerekiyor. Daha sonra test etmek için groups komutunu çalıştırabiliriz. Kendi kullanıcı adımızın yanında bir de www-data‘yı görmemiz gerekiyor.

c111 ~: groups
cemk www-data

Şimdi klasörlerimizin gruplarını değiştirmemiz gerekiyor. Eğer bilmiyorsanız, devam etmeden önce chmod, chown ve chgrp komutları hakkında detaylı bilgi almak isteyebilirsiniz.

Bu aşamada, bütün sitelerimizin grubunu www-data yapacağız. Apache www-data grubuna dahil olduğu, ve biz de kendi kullanıcımızı bu gruba dahil ettiğimiz için, chmod ile bu dizinlere verdiğimiz tüm grup izinlerini hem Apache kullanabilecek, hem de biz kullanabileceğiz.

Önce bir ek bilgi: Ben sitelerimi ev dizinimin altında “sites” isimli bir dizinde tutuyorum. Aynı şekilde “logs” ve “apps” diye ayrı dizinlerim de var. Fakat bizi şu anda ilgilendiren “sites” ve içindekiler. Burada varolan tüm öğelerin grubunu cemk‘dan www-data‘ya tek satırla çeviriyoruz.

sudo chgrp -R www-data /home/cemk/sites/

Peki ya yeni eklenecek klasörler? Onun için de bir satır komutumuz var. Normalde tüm dizinlere 750 (kullanıcıya yazma, gruba okuma, gerisine nanik) ve uploads dizinine 770 (kullanıcı ve gruba yazma, gerisine nanik) hakkı vermek mantıklı olan, fakat WordPress otomatik güncellerken tüm dizinleri ve dosyaları güncellediği için bütün sitelere olduğu gibi 770 veriyoruz.

sudo chmod -R 2770 /home/cemk/sites/

En baştaki 2, “set group ID” biti oluyor. Böylece o dizin altında sizin tarafınızdan yaratılan yeni dizin ve dosyalar da www-data grubuna dahil olurlar otomatikman.

Şimdi bir WordPress kurulumu yapın, ve dosya yüklemeyi deneyin. Et voilà! Çalıştığını göreceksiniz. Tabii belli bir boyuttan fazlasını yüklemeye çalışmazsanız.

2. Aşama: Dosya Boyutu Belirleme

Bunun için önce php.ini ayar dosyamızı bulmamız gerekiyor. Bunun nerede olduğunu phpinfo() komutuyla öğrenebiliyoruz. Loaded Configuration File kısmında yazan dizin, ayar dosyamız oluyor.

sudo nano /etc/php5/apache2/php.ini

Burada upload_max_filesize ve post_max_size ayarını bulup “2M”den istediğimiz değere çıkartıyoruz. Ben 64M yaptım. VPS’inizin RAM miktarına göre istediğiniz gibi arttırıp azaltabilirsiniz.

Ekleme (20.07.2010): memory_limit değeri de varsayılanda 16MB imiş. VPS’imdeki hiçbir WordPress kurulumunu 3.2 Beta’ya geçtikten sonra yükseltemediğimde farkettim ki, yeterli değil. 128M yapmak sorunu çözdü.

3. Aşama: Otomatik Güncelleştirme, Eklenti/Tema Yükleme

Diyeceksiniz ki “iyi güzel hoş, ayarı verdik, dizinlerimize artık sunucumuz da yazabiliyor, e zlib desteği de var PHP’mizin, peki biz neden hâlâ otomatik güncelleştirmeye veya eklenti/tema yüklemeye tıkladığımızda FTP bilgisi istiyor bu WordPress?”

Haklısınız. Ben de çok araştırdım. Meğerse son bir tanımlama yapmamız gerekiyormuş WordPress’e, bu özelliği kullanabileceğini anlatan. wp-config.php dosyasını açıp sonuna aşağıdaki satırı eklemek yetiyor.

define('FS_METHOD', 'direct');

Böylece artık bütün WordPress özelliklerini rahatça VPS’imizde, tıpkı paylaşımlı hosting’lerde olduğu gibi, ama daha fazla esneklikle kullanabiliyoruz.

Afiyet olsun!

Dipnot: Bu işlemleri yaparken sık sık yedek alın. Bunun için Slicehost veya Zerigo gibi “snapshot” almanıza izin veren VPS’leri tercih edebilirsiniz. (Hatta kendinizi cömert hissediyorsanız Zerigo’dan referrer kodumla bir paket alıp bana hosting desteğinde bulunabilirsiniz.)

Bunu çözmenin çok basit bir yöntemi var: gerçek flickr ID’niz. Bunun için, giriş yapmış durumdayken flickr’ın herhangi bir sayfasının kaynağını görüntülemeniz gerekiyor. Başta bir JavaScript alanı var, oradan “global_nsid” satırını bulup oradaki değeri kopyalamanız gerekiyor.

Daha sonra bunu facebook’umuzdaki profil ayarlarımızda, flickr kullanıcı adı alanına giriyoruz.

Et voilá! Sorunumuz çözülmüş durumda. Artık flickr’a yüklediğimiz resimlerin bildirileri anında facebook’umuzda da gözükecek –eskiden olduğu gibi.