MultiSite WordPress Kurulumu

 wordpress  3 Yanıt »
Şub 032015
 
3.228 views

MultiSite WordPress Kurulumu

Bu yazıyı standart wordpress kurulumu konusunda deneyimli kişiler için kaleme aldım. Elbette ilk denemede multisite wordpress kurulumu yapmak ta pekala mümkün. Ancak bir yerde takılınca, multisite ile ilgili yanıt bulmak epeyce sıkıntılı oluyor.

Öte yandan, standart wordpress siteler konusunda deneyimli olduğu halde, multisite konusunda en ufak bir bilgiye bile sahip olmayan çok sayıda webmaster var.

Aslına bakarsanız, multisite wordpress kurulumu, standart kurulumdan çok farklı bir yol izlemiyor. Sadece birkaç küçük ayrıntı var.

Subdomain ayarı: (eğer alt siteler subdomain olacaksa cPanelden aşağıdaki ayar yapılmalı.)

multisite wordpress subdomain

wp-config.php (aşağıdaki satırın wp-config.php dosyasına kurulumdan önce işlenmesi gerekiyor. Bu satır konmazsa, standart kurulum gerçekleşir.)

/* Multisite */
define( ‘WP_ALLOW_MULTISITE’, true );

Normal kurulumu yap.

Tools -> Network setup (Ayarlar -> Ağ ayarları):
Subdomain (alt alan) veya Subdirectory (alt dizin) olarak tanımla.

Ağ ayarları düzenlendiğinde wp-config.php dosyasına eklenmek üzere aşağıdaki satırlar oluşur.

define(‘MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL’, true);
define(‘DOMAIN_CURRENT_SITE’, ‘mydomain.com’);
define(‘PATH_CURRENT_SITE’, ‘/’);
define(‘SITE_ID_CURRENT_SITE’, 1);
define(‘BLOG_ID_CURRENT_SITE’, 1);

(Yukarıdaki satırlarda yer alan mydomain.com yerine kendi alan adınızı yazmalısınız. Alt sitelerinizin xyz.mydomain.com şeklinde çağrılmasını istiyorsanız,

define(‘SUBDOMAIN_INSTALL’, true);

eğer alt sitelerinizin www.mydomain.com/xyz şeklinde çağrılmasını istiyorsanız

define(‘SUBDOMAIN_INSTALL’, false);

satırlarını kullanmanız gerekir.

Son olarak, .htaccess dosyasına eklenmesi gereken temel satırlar şunlar olmalıdır:
.htaccess dosyası:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2[L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*.php)$ $2 [L]
RewriteRule . index.php [L]

# END WordPress

İşte hepsi bu kadar!..

Temel adımları yeniden özetleyecek olursak:
1. Wp-config.php dosyasına define( ‘WP_ALLOW_MULTISITE’, true );
satırını ekle
2. Ağ ayarları (Network setup) seçeneklerini düzenle
3. “Subdomain” veya “sub directory” yöntemini seç
4. Ağ adı (network name) bilgisini gir
5. Yönetici (admin) eposta adresini tanımla
6. wp-config.php dosyasını verilen kodlara göre düzenle
7. .htaccess dosyasına verilen kodları ekle
8. Siteye yeniden giriş yap

Multisite sistemi tarafından veritabanına eklenen tablolar şunlardır:
• wp_blogs
• wp_blog_versions
• wp_registration_log
• wp_signups
• wp_site
• wp_sitemeta

Ana site tabloları standart tabloların aynısıdır.

Yavru sitelere ait tablolar ise yavru site için verilen blog numarası eklenerek oluşturulur. İçerikler standart tabloların aynısıdır.

Yazımın başında da belirttiğim gibi, wordpress sistemini zaten tanıyor olduğunuzu varsaydım. Bu nedenle bir çok ayrıntıyı burada tekrar vurgulamaya gerek duymadım.

Eğer tek başınıza çok sayıda siteyi yönetmek gibi bir amacınız varsa, multisite wordpress sistemi sizin için güzel bir çözüm sağlayabilir. Ama bu sistemden mucizeler yaratmasını da beklemeyin!

Sorularınızı veya değerlendirmelerinizi yorumlar bölümünden bana iletebilirsiniz.

Ahmet Aksoy

Türkçe kaynaklar:
http://rooteto.com/wordpress/multisite
http://wpnotlari.com/wordpress-multi-site-kurulumu/
http://bimedya.com/multisite-kurulumu-ve-ayarlari

Yabancı kaynaklar:
http://www.wpbeginner.com/wp-tutorials/how-to-install-and-setup-wordpress-multisite-network/
http://www.elegantthemes.com/blog/resources/the-complete-guide-to-creating-a-wordpress-multisite-installation
http://mashable.com/2012/07/26/beginner-guide-wordpress-multisite/

Web Sitelerinin Güvenliği İçin Kali Linux

 forum, güvenlik, programlar, wordpress  Yanıt yok »
Oca 122015
 
2.557 views

Web Sitelerinin Güvenliği İçin Kali Linux

kali

Güvenlik, diğer alanlarda olduğu gibi, web siteleri için de önemli.

Kolayca alınabilecek önlemleri zamanında almamak, sonradan önemli zaman kayıplarına, emeğin boşa harcananmasına neden olabilir. Bu kayıplar bazan donanımsal veya kullanım hatasına bağlı kayıplar olabilir. Bazan da meraklı veya art niyetli kimi insanların farklı nedenlere bağlı girişimlerine…

Nedeni ne olursa olsun, risklerin varlığı, gelişimin itici motorlarından biridir. Önlem almak zorunda kalmadığımız alanlarda, yapılan çalışmaların geliştirilmesini sağlayan motivasyon ortadan kalkar. Gelişme durur. Gelişmenin durması ise çöküşün başlangıcıdır.

Elbette “Mükemmel Güvenlik” diye bir şey yoktur.

Bir yerde bir kilit varsa, onu açacak anahtar da mutlaka bulunur. Bunu unutmamak lazım. Buna karşın, “ne yaparsak yapalım, nasıl olsa onu aşacak birileri çıkacaktır” anlayışı da doğru değil. O zaman da yılgınlığa ve sonunda eylemsizliğe mahkum oluruz. Önemli olan, mevcut şartlarda alabileceğimiz önlemlerin en iyilerini almaktır. Sağlığımızı korumak nasıl ki hasta olmayı bekleyerek sağlanamazsa, web çalışmaları için de aynı mekanizmalar geçerlidir.

Web sitelerinin güvenliğini sağlarken dikkat edilmesi gereken noktalar bellidir. Buna rağmen, gözden kaçan zayıf noktalar da olabilir.

İşte bu noktaların “önlem” amacıyla “önceden” tespit edilmesi için yapılan tüm girişimler büyük bir önem taşır.

Kali Linux, elektronik iletişim denetimi amacıyla geliştirilmiş bir araçtır. Onu bir alet çantasına benzetebiliriz. Bu çantanın içinde elektronik iletişim sektörünün hemen her alanına ilişkin çeşitli araç-gereçler bulunur.

Benim en çok ilgimi çekenler web sitelerinin güvenliği ile ilgili olanlar.

Örneğin, sistem zayıflıklarını tespit eden programlar.
Ya da parola yapılarını denetleyenler.
Dikkatsizlik yüzünden silinmesi unutulmuş ve içinde kritik bilgiler bulunan dosyalar…

Önümüzdeki dönemde bu alanda yapmakta olduğum çalışmalardan bazı örnekler verecek ve deneyimlerimi sizlerle paylaşmaya çalışacağım.

İlk çalışmalarım özellikle “wordpress” kullanan sitelerle ilgili olacak. Daha sonra fırsat oldukça başka konulara da gireceğim.

Eğer siz de bir wordpress yöneticisi iseniz ve hele henüz öğrenme dönemindeyseniz, beni izlemenizi öneriyorum. Bu sitede yazdıklarımı mutlaka takip edin. Ayrıca WebKurnaz.net forumuna üye olun. Orada bu çalışmalarla ilgili çok güzel paylaşımlarımız olacak. Sorunlarınız ve sorularınızı bize yazabilirsiniz. Önerilerinizi, projelerinizi bizimle paylaşabilirsiniz.

Amacınız ister güvenli bir web sitesine sahip olmak, isterse web güvenliği konusunda uzmanlaşmak olsun; birlikte yapabileceğimiz pek çok şey bulabiliriz.

Bir sonraki yazımda Kali Linux kurulumunu ele alacağım.
Bu arada siz de http://hackertarget.com/wordpress-security-scan/ adresinden kendi sitenizle ilgili ön testleri yapabilirsiniz.

Unutmayın! Bilgi, paylaştıkça büyüyor.

ahmet aksoy

WordPress Yetkili Kullanıcılarına Reklam Göstermemek

 webmaster, wordpress  1 Yanıt »
Ara 282014
 
2.328 views

WordPress Yetkili Kullanıcılarına Reklam Göstermemek

google adsenseAdsense, insanların kendi sayfalarındaki reklamlara tıklamasını banlama nedeni sayıyor. Haklı elbet!

Ben de wordpress sayfalarımda Adsense reklamları kullanıyorum. Düne kadar, bu reklamlara tıklamamaya hep özen gösterdim. Zaten çoğu ilgimi çekmeyen reklamlardı.
Ancak -özellikle son bir aydır- bu konuda sıkıntı yaşamaya başladım. Çünkü bu son dönemde kendi sayfalarımda, benim ilgimi çeken reklamlar da yayınlanmaya başladı. Örneğin hosting konusunda bir internet araştırması yapıyorum; sonra bir bakıyorum kendi sayfalarımdaki reklamların konusu birdenbire hosting ağırlıklı hale gelmiş. Reklamı tıklamamak için kendimi zor tutuyorum. Üstelik, reklamdaki firmaların pek çoğunun erişim bilgilerine reklam üzerinden ulaşmak mümkün olmuyor. Bazılarında reklamı veren firmanın adı bile yok!…

Bana kalırsa, Google bu konuda bir ayrıntıyı atlamaya başladı, ya da bunu önemli bir sorun olarak görmüyor. Ama bana kalırsa, bu, oldukça önemli bir sorun. Adsense isterse, yetkili kullanıcılara onları doğrudan ilgilendirecek reklamlar göstermeyi engelleyebilir.

İşte bu nedenle ben de kendi sorunumu kendim halletmek istedim.

Yazıların içinde yayınlanan reklamlar için eklenti (plugin) kullanıyorum. Kullandığım eklentide “sisteme giriş yapanların açtığı sayfalarda reklam gösterimemesini sağlamak” için bir seçenek var. Onu işaretledim ve kendi sayfalarımda yayınladığım yazıların içindeki reklamlar bana görünmez hale geldi. Eğer sistemde çıkar ve yetkisiz biri olarak sayfayı açarsam, reklamlar tekrar görünür hale geliyor.

Sorunumun bu aşamasını çözmek kolay oldu.

Ancak bir de yan panelde metin kutusu içinde kendi tanımladığım reklamlar var. Bunları manuel olarak eklediğim için, Adsense plugin buraya müdahale edemiyor.

Bunun çözümü de kolay aslında. Basit bir PHP testi ile kullanıcılın yetkili girişi yapıp yapmadığını kontrol et; yetkili ise reklamı gösterme, yetkisiz ise göster.

Ancak, bileşen (widget) bölümlerinde PHP komutları işe yaramıyor. Daha doğrusu, normal kodlar gibi davranmıyor.

Bu durumu bile bile bir deneme yaptım:

reklam göstermemek

Pek umudum olmasa da kod çalıştı. Yetkili kullanıcı olarak sisteme giriş yaptığımda reklam alanı boş olarak görünüyor. Normal bir ziyaretçi gibi aynı sayfayı açtığımda ise reklamı görebiliyorum.

Ancak küçük bir sorun var. Çünkü yukarıdaki kodu metin kutusunun içine eklediğimde, reklam ister gösterilsin, ister gösterilmesin en sondaki “tırnak” karakteri ve sonraki karakterler metin kutusunun son tarafında yayınlanıyor. İşlevsel bir sorun yok ama, “sinek-mide bulantısı” meselesini unutmamak lazım.

Bu minik soruna bulduğum çözüm ise biraz mantık dışı: Tırnak işareti ve sonrasındaki karakterleri silmek.

Normal koşullarda burada bir sürü yazım hatası oluşması gerekirken, hiçbir sorun görünmüyor ve kod da olması gibi çalışıyor.

Umulmadık bir zamanda bir başka soruna yol açmamasını umuyorum.

ahmet aksoy

Resim ve Yazı Güncellemede Sorun

 temalar, wordpress  1 Yanıt »
Ara 072014
 
2.631 views

Resim ve Yazı Güncellemede Sorun

wp-cron.php sorununu çözmeye çalışırken bir başka problem ortaya çıktı.
Son yazıma resim eklemeye kalktığımda bir türlü media alanına erişemedim.
Bunun olası 2 nedeni var:
1- Multisite WordPress wp-cron-mu.php kullanarak 15 dakikada bir gerçekleştirilen cron işlemleri, normal işleyişi olumsuz etkiledi.
2- Yazıda pre veya code ile betimlediğim kod örnekleri, sistemle bir şekilde etkileşime girerek akışı olumsuz yönde etkiliyor.
Nedeni daha kolay bulabilmek için bu iki olasılığı birbirinden ayırmak gerekiyor.
Bu yazyı biraz da bu amaçla yazıyorum.
Bu yazıda her hangi bir kod örneği olmayacak. Resim de koymayacağım.
Eğer bu yazıyı kaydeder veya yeniden düzenlerken herhangi bir problemle karşılaşmazsam, yaşanan sorunun kaynağı olarak alıntı kodları görmek kolaylaşacak.
Aksi halde, bu soruna cron uygulamasının yol açtığını söylemek daha doğru olacak.
…
Yukarıdaki bölümü kaydetmek için “Güncelle” butonuna bastığımda, Chrome adres kutusunda
“http://webmaster.gamet.com.tr/wp-admin/post.php”
satırı belirdi ve orada kaldı. Normalde işlemlerini tamamlayıp, aynı ekrana dönmesi gerekirdi.
Bilgisayarımın ikinci ekranından siteyi kontrol ettiğimde yazının düzgün olarak kaydedilmiş olduğunu gördüm. Yani “post.php” dosyası kayıt işlemlerini düzgün olarak gerçekleştirmiş olmakla birlikte, süreci tamamlayıp geri dönemiyor.
Bu yazıda bir kod alıntısı olmadığına, ama davranışın da değişmediğine bakılırsa, asıl sorumlu cron için yaptığımız düzenleme gibi görünüyor.
(post.php dosyasının kayıt işlemlerini tamamladıktan sonra ekrana boş bir sayfa getirip orada takıldığını da belirteyim. Bu sayfa gerçekten de boş, çünkü kaynak kodlarını görmek istediğinizde de tamamen boş bir sayfa çıkıyor.)

Bir yandan interneti de taramaya başladım. Bu durumu bazıları “WordPress Beyaz Ölüm Sayfası” olarak adlandırmış. Çok yeni bir sorun gibi de görünmüyor.
Sistemimde W3 Total Cache kullanıyorum. Onun bir etkisi olup olmadığını sınamak için tüm keşleri boşaltmasını isteyince, aynı Beyaz Ölüm Sayfası yeniden karşıma dikildi.
Böyle zamanlarda en yararlı ip uçları hata log dosyalarında bulunur.
Ve işte bütün sorunlarımın kaynağı!…
Bu bir bileşen: WP-dTree. Aslında çok işime yarayan bir bileşendi. Gözümü kırpmadan kaldırdım.
Ama boşuna sevinmişim! Değişen bir şey olmadı. Sadece WP-dTree cach ile ilgili hata mesajları sonlanmış oldu.
Şimdi bir başka suçlu bulmalı!
Örneğin W3 Total Cache’in kendisi olabilir mi?
Ama diğer subdomain sitelerimde hiç bir sorun yaratmadan çalışıyor.
Peki başka ne olabilir?
İnternetteki yazışmalardan birinde, functions.php dosyasının sonunda kalmış boş bir satırdan bahsediliyordu. Acaba bende de olabilir mi? Hemen kontrol ediyorum. Önce post.php dosyasını kontrol ettim. Gerçekten de en sonda boş bir satır vardı. Hemen temizledim.
ANcak Beyaz Ölüm Sayfası tüm ihtişamıyla yine karşımda.
functions.php dosyasını da kontrol ettim ama, orada boş satır falan yoktu zaten.
…
Bu kez temayı sorguluyorum. WordPress orijinal teması yerine yavru tema kullanıyordum. Bu yüzden doğrudan ana temayı etkinleştirdim.
Voila!
Sorun çözüldü! Sorunu yaratan yavru temanın kendisiymiş.
…
Hemen bir önceki yazıya dönüp resim sorunu ne durumda kontrol edeceğim.
Orada da her hangi bir sorun yok.
Demek ki yavru temanın functions.php dosyasında bir sorun olma olasılığı çok güçlü. Daha düşük bir olasılık olsa da, diğer ihtimal style.css dosyası. Bunlarda da fazla bir değişiklik yok zaten.
Hedef iyice daraldığına göre, sorunu çözmek artık çok daha kolay!

ahmet aksoy

WordPress wp-cron.php Macerası Devam Ediyor

 Genel, wordpress  Yanıt yok »
Ara 072014
 
2.281 views

WordPress wp-cron.php Macerası Devam Ediyor

wordpress wp-cron.php
Evet! Bir önceki yazımda WordPress cron işlemini iptal edip, tetiklemeyi daha uzun bir periyot ile ve Cpanel üzerinden denediğimi, sonra da bütün işlemleri geri aldığımı yazmıştım.

Bir kaç gün önce hosting firmamdan bir mesaj aldım. İşlemci yoğunluk limitlerini aştığım ve tekrarlanması halinde önlem alınacağını bildiriyordu.

Böylesine durumlar yabancı hosting firmalarında genellikle çok daha kibarca hallediliyor. Bizimkiler, doğru dürüst bir inceleme yapmadan paldır küldür yasaklamaya gitmeyi tercih ediyor.

Bu durum büyük bir olasılıkla harici bir bot vb ile yaratılmış olmalı. Çünkü aynı sistem uzunca bir süredir sorunsuz çalışıyordu. Üstelik son günlerde başka işlerim nedeniyle web üzerinde herhangi bir çalışma yapmaya fırsatım bile olmamıştı.

Sonra bir mesaj daha geldi. Ancak bu mesajda incelik gösterip sorun kaynağını wp-cron.php olarak belirtmişlerdi.

Cron.php’nin işlemci yüküne sebep olabildiğini zaten bildiğim için doğrudan kendi önlemlerimi almaya karar verdim.

İnterneti bu amaçla yeniden taradım. Ve bu sefer, multisite wordpress uygulamalarında, her subdomain için wp-cron.php çağrısının ayrı ayrı tekrarlanması gerektiği bilgisine ulaştım. Gayet mantıklı bir açıklama. Çözüm olarak önerilen çeşitli scriptler var. Ben, aşağıdaki çözümü sadeliği ve kolay anlaşılırlığı açısından tercih ettim:

Yukarıdaki kodun 7. satırındaki ‘yoursite.com’ değerini kendi ana domain adınızla değiştirmeyi unutmamalısınız.

Bu scripti wp-cron-mu.php olarak isimlendirebiliriz. Bu script, ana domain de dahil olmak üzere aktif durumdaki tüm subdomain sitelerin wp-cron.php dosyalarını tek tek çalıştırıyor.

Cpanel cron komutu da şöyle değişiyor:

*/15 * * * * /usr/bin/php /var/www/yoursite/wp-cron-mu.php > /dev/null

Burada da yoursite.com adresini doğru adresle değiştirmeniz gerekiyor. Çağrılar 15 dakikada bir.

Bakalım işlemcilerin aşırı yüklenmesini bu önlem giderebilecek mi? Sanırım bir kaç gün içinde netleşir!

Eğer siz de multisite wordpress kullanıyorsanız, bu yönteme ihtiyacınız olabilir.

ahmet aksoy

Kaynaklar:

WordPress Cron.php Macerası

 wordpress  3 Yanıt »
Kas 112014
 
2.543 views

WordPress Cron.php Macerası

Her yaptığımız şey istediğimiz sonucu verecek değil ya! Bazan yanlışlıklar da yapıyoruz. Ne de olsa insanız!…

cron

Her ne olursa olsun, yaptığımız yanlışlar bile bize bir sürü şey öğretiyor. Cron macerası da aynen öyle oldu.

webmaster.gamet.com.tr sitesinin performansını geliştirmek için SEO uygulamalarına devam ediyorum. Bu amaçla internet üzerinde yaptığım araştırmalardan birinde, cron.php dosyasının her sayfa ve post hareketinde otomatikman çağrıldığı için site performansını düşürdüğünden söz ediliyordu.

Açıklama gayet mantıklı. Eğer ziyaretçi sayınız ve sayfalarınızın tıklanma sayısı fazlaysa, cron.ph dosyası da çok sık çağrılacak ve bir sürü işlem boş yere tekrarlanacak.

Önerilen çözüm de gayet açık ve pratik:

1- cron.php dosyasının otomatik çağrılmasını engelle
2- Aynı dosyayı Cpanel üzerindeki veya shell üzerinden sistem cron ile istediğin aralıklarla çalıştır.

Ben de aynen bunları yaptım.

Önce wp-config.php dosyasını açtım ve içine şu satırı ekledim:

Böylece cron.php dosyası her tıklamada çalışmak zorunda olmaktan çıktı. Şimdi de Cpanel cron üzerinden istediğim aralıkta çağrılmasını sağlamak gerekiyor.

Bu amaçla cPanel’e girip “Zamanlanmış Görevler” bölümünü açtım:

Her şey güzel görünüyor!

Ama kısa bir süre sonra admin olarak bazı sıkıntılar yaşamaya başladım. Örneğin yaptığım değişiklikleri normal bir kullanıcı olarak test etmek için logout seçeneğini kullandığım halde, admin çubuğu yine ekranın tepesinden bana bakmaya devam ediyor. Bütün çerezleri sildim. Hatta bilgisayarımı kapatıp açtım. Ne yaptıysam bir şey değişmedi! Yetkisiz bir kullanıcı olarak siteye giremiyorum.

İnternet araştırmalarımdan da işime yarayacak bir sonuca ulaşamadım.

Sonunda pes ettim! Cpaneldeki cron işlemini devredışı bıraktım. wp-config.php dosyasındaki otomatik cron iptal satırını da kaldırdım.

Öyle görünüyor ki, “logout” işlemi de cron.php üzerinden etkinleştiriliyor. Ya da multi-site wordpress kullandığım için bu öneri benim işime yaramamış olabilir.

Eğer siz de bu konuda denemeler yapmış iseniz, deneyimlerinizden yararlanmak beni de mutlu eder. Yorum alanına düşünce ve önerilerinizi ekleyebilirsiniz.

Eğer ben bu konuda yeni bilgilere ulaşırsam, onları da sizlerle paylaşacağım.

ahmet aksoy

Not: Eğer hosting sisteminiz cron üzerinden wget komutunu işletmenize izin veriyorsa aşağıdaki linkte yer alan yazıdan yararlanabilirsiniz. Benim hostum buna izin vermediği için ben doğrudan php komutunu kullanmak zorunda kaldım:

http://www.iceablethemes.com/optimize-wordpress-replace-wp_cron-real-cron-job/

 Daha eski girişler