WordPress blogunuzun RSS kaynağına girdi görselleri eklemek

WordPress’in ön tanımlı gelen temlarındaki rss kaynaklarında sadece girdi detayları bulunur. Eğer sayfalarınızda girdilerinizi listelerken görsel olarak girdinize eklenen birincil imajı kullanıyorsanız (bir çok tema bu şekilde girdi görseli tanımlaması yapmaktadır), rsslerinize girdilerin birincil görselini (varsa) eklemek oldukça kolay olacaktır.

WordPress’in kanca mimarisi sayesinde tema klasörünüzdeki fonksiyon tanımlamaları yapılan dosyaya ekleyeceğiniz bir fonksiyonu, rss girdileri işlenirken çağırtabilirsiniz. Bu sayede rss çıktısında gösterilecek girdileri manipule ederek rss çıktılarına girdi görsellerini ekleyebiliriz.

Bunun için, tema klasörünüzde (muhtemelen var olan) functions.php’ye

kodunu ekleyelim. Rss girdilerini manipule edecek bir fonksiyon tanımladıktan sonra iki rss’i oluşturan methodların kancalarını kullanarak tanımladığımız fonksiyonu çağırtıyoruz. WordPress, fonksiyona, manipule edilecek girdiye ait bazı bilgileri parametre olarak gönderiyor. İlk parametre, işimize yarıyacak tek parametre aslında. Basitçe; girdiye ait eklentileri sorgulayıp eğer girdi görseli varsa, ilk parametreyle aldığımız girdi içeriğine html kodu olarak ekliyor ve fonksiyon cevabı olarak geri dönüyoruz. WordPress gerisini hallediyor zaten.

Yukarıda kodun son 2 satırında gördüğünüz rss kaynakları, yorumlar ve girdilere ait rss’ler. İsterseniz sadece girdilere ait rss kaynağına (the_content_rss) thumbnail eklemeyi tercih edebilirsiniz.

PHP SDK ile Facebook API hareketlerini izleme ve optimize etme yöntemleri

Eger php tabanlı bir facebook uygulamanız varsa facebook’u sadece kimlik doğrulama dışında kullanıyor olabilirsiniz. Çok basit bir uygulamada bile en azından düzenli yaptığınız facebook api çağrıları vardır. Basit bir örnek ile, kimlik doğrulama sonrası arkadaş listesini ekrana basan ve seçtiğiniz arkadaşınızın doğum tarihini kullanarak bir hesaplama yapan bir uygulamanız var diyelim (mesela: doğum günü takvimi uygulaması). Biliyorsunuz ki arkadaşlarınızın doğum tarihi bilgisini ancak ek bir izin ile sorgulayabilirsiniz. Dolayısıyla kullanıcınız, bir arkadaşını seçtiğinde, seçilen facebook kullanıcısı detaylarını sorgulamadan önce, uygulamanızı kullanan kullanıcıdan o izni alıp almadığınızı kontrol etmeniz gerekir.

Uygulamanızı gerekli kontrolleri yaparak hata vermeyecek şekilde hazırladınız diyelim. Performans problemleri yaşıyorsanız, önce performans probleminizin nereden kaynaklandığını tespit etmeniz gerekir. Gerekli veritabanı ve php kod optimizasyonu yapmanıza rağmen hala performans problemleri yaşıyorsanız problem yüksek ihtimalle sunucunuz ile facebook sunucuları arasındaki iletişimin uzun sürmesidir. Bunun da en büyük kaynağı facebook sdk’sının kaç çağrı yaptığı, bunların toplamda ne kadar zaman aldığı olacaktır ve bu konuda bir fikriniz yok diyelim.

Bu noktada ufak bir değişiklikle sunucunuz ile facebook sunucuları arasındaki trafiği monitöre edebilirsiniz. Bu gözlem, aslında her cağrıda yapmak zorunda olmadığınız ama bilmeden yapıyor olduğunuz veya geçici şekillerde ön bellekte saklayabileceğiniz bilgileri, kontrolleri gösterecektir size.

Şimdi ufak bir değişiklikle trafiği yakalayalım. Bunun için base_facebook.php dosyasında olan api methodunu:

aşağıdaki şekilde güncelliyoruz:

$facebookApiCalls = array();
public function api( /* polymorphic */)
{
$args = func_get_args();

$time_start = microtime(true);

if (is_array($args[0])) {
$result = $this->_restserver($args[0]);
} else {
$result = call_user_func_array(array($this, ‘_graph’), $args);
}

$time_end = microtime(true);
$time_elapsed = $time_end – $time_start;
$time_elapsed *= 1000; //convert to millisecs

if (isset($GLOBALS[‘facebookApiCalls’])) $GLOBALS[‘facebookApiCalls’][] = array(
‘duration’ => $time_elapsed,
‘args’ => $args,
);
return $result;
}

Yukarıdaki kodda yaptığımız değişiklik basitçe api methodu her cağrılışında, facebook sunucularına yapılan http isteğinin ne kadar sürdüğünü ölçüp global bir dizide toplamak. Bu şekilde sayfanızın sonunda ekrana $facebookApiCalls dizisini bir tablo şeklinde veya basitçe var_dump alarak kaç çağrı yapıldığını, yapılan cağrıların her sayfada tekrar edip etmediğini gözlemleyip eğer yapılabiliyorsa ön bellekte veya oturum değişkenlerinde tutularak sorgu tasarrufu yapılıp yapılamayacağına karar verebilirsiniz. Eğer sorgularınız çok zaman alıyorsa sunucu trafiğinizde optimizasyonlara gidebilirsiniz.

Bir çok amatör programcı, sdk methodlarını veya bilindik open graph methodlarını kullanarak sorgu yapıyor ve çoklu işlem yaparken ayrı ayrı sorgu yapıyorlar. Aslında facebook veri yapısını biraz anladıktan sonra FQL yazarak birden fazla sorguyu tek sorguda toplayıp önbellekleyebilir ve bu sayede çok büyük bir optimizasyon sağlayabilirsiniz.

Yukarıdaki doğum günü takvimi örneği için yapılabilecek optimizasyon senaryosu şöyle olabilir: uygulama, "arkadaşların doğum tarihi" iznini her halukarda gerektiriyorsa ilk sayfa açılışında kontrol edilerek kullanıcının bu izni vermesine zorlanabilir, bu sayede her arkadaş seçiminde ayrı ayrı kontrol yapılmak zorunda kalınmaz. İkinci bir optimizasyon, arkadaş listesinin önbelleklenmesi olabilir. Hatta doğum günleri de arkadaş listesiyle sorgulanarak tek oturumda sadece tek istek ile uygulamanızı çalıştırmış olursunuz.

Bu optimizasyonlar sadece uygulama hızı için değil, sunucu trafiğinizi azaltmak için de düşünmeniz gereken optimizasyonlardır.

PHP ile tekil anahtar oluşturmak

Türkçesini çok bulamadığım hash kelimesini anahtar olarak kullanacağım. Burada aslında bahsettiğim anahtar herhangi bir veri grubunuza atadığınız, sayısal olmayan kimliklerden bahsediyorum. Yani rasgele üretilmiş belirli bir uzunlukta olan kimlikleri her yerde kullanıyoruz.

Neden sayısal bir kimlik kullanmak yerine bu anahtarlara ihtiyaç duyacağınızı en açık şekilde şöyle anlatabilirim. Mesela tahmin ederek erişilmesini istemeyeceğiniz ama şifre veya kullanıcı girişi gibi herhangi bir sınırlama koyamayacağınız bir sayfanız var, örnek veriyorum yapılacak işler listesi veritabanı oluşturuyorsunuz ve her kayıt bir yapılacak iş listesi. Veritabanında sayısal bir kimliğe yani numaraya sahip bu kayıtlar. Hazırladığınız bir php sayfası da liste numarasına göre yapılacak iş listesinin detayını ekrana döküyor.

Eğer liste_detay.php?no=145 gibi basit bir şekilde tutarsanız url’i oynayarak başkalarının listelerine erişebilir, sadece erişmek değil sistemdeki tüm listeleri basit bir script ile tahmin edebilir veya tarayıp kaydedebiliriz. Böyle bir durumda listelerinizi sadece sayısal değil, tahmin edilemeyecek bir anahtar ile (örneğin: t34de6gx) tanımlamak istiyorsunuz.

Bu noktada rastgele bir anahtar üretebilirsiniz, bunu yapmak çok zor değil. PHP’deki rasgele sayı üretme fonksiyonunu kullanarak ve bir karakter dizisinden rastgele elemanlar çekerek bir kelime üretebilirsiniz.

Bunu daha pratik bir şekilde tek satırda bile yapabilirsiniz:

Bu satır size 6 karakterlik bir kelime üretecektir. Basitçe str_shuffle fonksiyonu ile özel karakter içermeyen ve rakamlarında dahil olduğu bir alfabeyi karıştırıyor ve başındaki ilk 6 karakteri alıyoruz.

Şimdi bu, işin basit kısmı. Eğer veritabanındaki bir veri set için bu anahtarı oluşturuyorsanız üretilen anahtarın veri setinde daha önce kullanılıp kullanılmadığını test etmek zorundasınız. Sonuçta tekil bir anahtar oluşturuyorsunuz. Bu arada veri setiniz mysql veya bir sql veritabanında olmak zorunda değil, bir xml, csv veya txt dosyasında saklı olan bir set için de benzer şeyi uygulayabilirsiniz.

Veritabanındaki veriyi test ederek bir anahtar oluşturmanın en kısa ve basit kodu şöyle:

Bu kod, veritabanında olmayan bir anahtar üretmenizi sağlayacaktır. Sonra verinizi hazırlayıp tablonuza yeni kayıdınızı ekleyebilirsiniz.

htaccess yardımıyla tüm trafiği tek merkezden yönetmek

URL şemaları, SEO amacıyla önem taşımakta. Bunun yanı sıra, her geliştirici ürettiği uygulamanın URL şemasının anlaşılır ve güzel görünmesinı ister. Eğer bir framework kullanıyorsanız muhtemelen bunu yönetebileceğiniz bir yer, yardımcı vs vardır. Fakat kendi kodunuzu yazıyorsanız htaccess ile mod_rewrite yardımıyla her url şema tipine göre bir rewrite kuralı yazmanız gerekecektir.

Basit bir proje örneği vereceğim, diyelim ki basit bir ürün katalogu hazırlıyorsunuz, katalog anasayfasında son ürünler ve kategoriler listeleniyor. Her her ürün de bir kategoride listeleniyor. Yani kategori sayfaları ve ürün detay sayfalarınız var. Basit bir php projesi ile bu uygulamayı 3 parçaya ayırdınız, anasayfa, kategori ve ürün detay. Her parçanın kendine ait kodu var. Normalde bu parçaları birer php dosyası olarak hazırladığınızı düşünürsek her parçayı birbirine

  • anasayfa.php
  • kategori.php?kategori_id=21
  • urun_detay.php?urun_id=2320

gibi linklerle bağlıyorsunuz.

URL şemasını su şekilde kurgulamak istediğinizi düşünelim:

  • /
  • /kategori/21
  • /urun/2320

Bunun için klasik yöntemlere göre htaccess dosyanıza her link şeması için bir kural yazıp gerekli yönlendirmeyi yapmanız gerekir. Fakat her kural için düzenli ifade (regex) yazmak hem yorucu olabilir hem de her yeni url şeması için yeni regex hazırlamanız ve htaccess dosyanızı güncellemek durumunda kalırsınız. Eğer url şemalarınız belirli bir mantığa göre hazırlıyorsanız -ki MVC frameworkleri genelde buna benzer kurallara sahiptir- bu kuralı algoritmaya çevirmeniz çok kolay.

Mesela Codeigniter kullanarak hazırladığınız aynı yapı için, anasayfa, kategori ve ürün detayı için ayrı controller ve ayrı view’lar yazmak durumunda olacaksınız. Gerçekten de olması gereken bu zaten. Ama controller’ı yazarken size bazı kurallar koyar Codeigniter. Verdiğiniz sınıf adı ve method’a URL üstünden doğrudan ulaşabilirsiniz eğer methodunuz public bir method ise. Atıyorum ürün detay controller’ının adını Urun koydunuz ve method adını da detay koydunuz. Bu methodu tetiklemek (ulasmak) için kullanacağınız url: /Urun/Detay/ekstra/parametreler şeklinde olabilir. Methodunuz içinde ekstra parametreleri yakalayabilirsiniz.

Kendiniz yazarak hazırlayacağınız kod ıle url şeması böyle ikili bir kurala sahip olmak zorunda değil. Tekil bir tanımlayıcı yeterli olacaktır, ama daha karışık bir mekanizma kurarak siz de çoğul (ikili veya üçlü) bir adresleme mekanizması oluşturabilirsiniz. Tekil bir adresleme için kurallı bir mekanizma olarak şöyle bir algoritmanız olabilir:
/Urun/3452/yazci-uyumlu-versiyon şeklindeki bir url’i, ilk parça controller adı, geri kalanlar da hem opsiyonel hem de controller tarafından yakalanıp işlenecek olan veri olarak düşünürseniz, ilk parçada gelen adda controller’a sahip olup olmadığınızı kontrol edebilirsiniz. Bunun için bütün controller’larınızı “Controllers” gibi bir dizinde toplu tutmanızda fayda var. Çok ilkel bir mekanizmayla controller’larınızın sınıf değil, düz php dosyaları olduklarını varsayıyorum ve böyle bir url çağırıldığında tek bir dosyadan gerekli controller’i tespit edip include ederek calıştırdığınızı düşünelim.

Peki bu url’ler nasıl tek merkezden geçecek?

Şimdi size önce anlatmam gereken kısma geldik, bütün trafiği tek dosyaya yönlendirmek. İşte bunun için htaccess’a oldukça genel bir kod koyuyoruz:

Yukarıdaki kod sitenize gelen tüm istekleri index.php dosyasına yönlendirir.

Örnek olarak:
http://example.com/
http://example.com/kategori/123
http://example.com/urun/8765
gibi istekleri index.php?path=/kategori/123 şeklinde tek parametre olarak index.php dosyasına iletilecektir. Ama yukaridaki kod teknik olarak eğer url’de geçerli bir dizin adresi veya dosya adresi yoksa istekleri index.php’ye yönlendirecektir. Yani “kategori” adında bir dizininiz varsa istek index.php’ye gitmez. Bunda da bir detay daha var. Eğer “kategori” adında bir dizininiz var ve url /kategori/sdjfhsdkfjshd ise bu URL’de aranan dosya orada olmadığı için istek yine index.php dosyasına aktarılır.

Burada ilk problemin çözümü için, controller adlarınız projenizin kök dizininde varolmayan bir klasör adı olmalıdır. İkinci problem ise, siz kullanmıyor olsanız bile herhangi bir dizin içinde bulunamayan istek index.php dosyasına yönlenecek ve siz bunu kontrol etmek zorunda kalırsınız. Olmayan dosyalara yapılan istekler web’in doğasında olan bir şeydir. En basit örneği, sitenizi tarayan botlar (google bot etc…) sitenize robots.txt, favicon.ico, sitemap.xml veya crossdomain.xml gibi sorgular yapacaktır. Olmadığı için 404 hatası almaları gerekir yaptıkları şeyi doğru yapmak için. Bunun yanı sıra siz de bu gereksiz istekleri işlemenize gerek kalmazsınız.

Bunun için, yani ikinci problemi çözmek için, projenizin asset dizinlerini (stiller, js, resimler, imges, files etc…) bu url ayrıştırma mekanizmasından ayırmak isteyebilirsiniz. Aşağıdaki satırları yukaridaki kodun üstüne yerleştirmeniz yeterli.

Böylece bu dizinler ve altındaki isteklere dokunulmayacaktır. Ama yine de kök dizindeki her spesifik isteği ya htaccess’da ya da index.php dosyanızda işlemeniz gerekmektedir.

index.php istekleri nasıl ayrıştıracak?

Artık sitenize gelen tüm istekler index.php’nin elinin altında. “path” parametresini “/” karakterine göre parçalayarak ilk parçayı controller adı olarak rezerve edebilirsiniz. Dizinin geri kalan elemanlarını global bir dizide tutarak controller’larinizin içinde yakalayabilirsiniz. Unutmayın hala $_GET dizisiyle soru işareti ve sonrasında kullanacağınız GET parametrelerini yakalayabilirsiniz. Yani /urun/67845?ref=facebook_campaign gibi bir url hala doğru şekilde calışacaktır.

Çok ilkel bir yapıda controller adını “Controllers” dizininde öyle bir dosya olup olmadığını kontrol ederek ve eğer dosya varsa o an include ederek basit bir yapı kurabilirsiniz.

Size biraz daha farklı bir yapı sunacağım şimdi

mfyz.com’un kodu çok eski sürümlerde Türkçe idi, sonrasında ilkel bir modüler yapıya evrimleşti, sonrasında dil değiştirdi, sonrasında ilkel bir MVC modeline evrimleşti, ve şu an oldukça gelişmiş bir MVC modeline sahip. Kod 95% İngilizce, çünkü hala Türkçe yazılmış ve refactor edilmeyi bekleyen eski kodlar duruyor hala derinlerde 🙂 Neyse, bu örneği çoklu dile sahip bir projede çalışma ihtimali için veriyorum. Kod, controller’lar ve method adlarınız hep ingilizce (veya başka bir dilde) olmak zorunda olabilir veya ölyle olmasını isteyebilirsiniz. Böyle bir durumda Türkçe bir domain altında yoresel-organik-sabun.com/product/detail/1231231 gibi bir url şemasından çok yoresel-organik-sabun.com/urun/1231231 gibi bir URL tercih edersiniz değil mi? Şimdi bunun için kuralsal bir yaklaşımdan çok bir yol haritasının yolu gösterdiği bir mekanizmayı anlatacağım. Bu mekanizmanin bir diğer avantajı da aynı controller ve method’lara birden fazla farklı url şemaları oluşturabilmenizdir. Yani örneğin bir iletişim formuna sahipsiniz ve example.com/contact ve example.com/callus gibi iki url hatta aynı zamanda example.com/iletisim gibi farklı dildeki adresleri oluşturabilirsiniz. Sonra otomatik dil değişimi yapıp yapmamak sizin controller’da yaptığınız hünerli kodlara kalmış.

Bir yol haritası oluşturmak aslında bu url şemalarını htaccess’da her şema için ayrı ayrı kural yazmaya benziyor, ama çok daha dinamik olabilir ve düzenli ifade yerine basit dizilerde tutulabilir. İlkel bir yol haritası dizisi yazacağım yukaridaki örnek proje için.

Gördüğünüz gibi ürün için iki farklı adresleme kullanabilirsiniz. Daha dinamik bir yol haritasını veritabanınızda saklayabilir hatta otomatik güncelleyebilirsiniz. Bunun en güzel örneği kullanıcı adı ile adresleme yapabilmektir. Yani example.com/mfyz ve example.com/mfyz/links gibi kullanıcınıza domain.com/kullanici_adi gibi bir sayfa adresleyebilmenizdir. Gelen isteğinizi, sitenizin ana yol haritası kontrollerinizi yaptıktan sonra, eğer istekte bulunulan adres yol haritanızda bir yeri işaret etmiyorsa kullanıcı dizininizde aratarak adresin bir kullanıcı profili veya kullanıcı sayfasını işaret ettiğini yakalatabilirsiniz.

PHP’de tarih karşılaştırma

Bir web uygulaması/sitesi geliştiriyorsanız verilerinizin eklenme, güncellenme tarihleri genelde uygulamanın işleyişinde büyük rol oynar.

Örnek bir senaryo olarak, bir günlük sitesi hazırladınız ve günlükte görünen yazılarınızın son güncellenme tarihlerine göre son güncellenen yazıları listelemek isteyebilirsiniz. Veya bir e-ticaret sitesinde ürünleri belirli günlerde yayına çıkarmak istiyorsunuz ama bütün ürünleri her gün tek tek ekleyememeceğinize göre her ürünün yayına çıkış tarihini ayarlamak isteyebilirsiniz. Bunun gibi bir çok örnek bulabilirsiniz verilerin tarihleri üzerinden işlem yapmak isteyeceğiniz.

Yani aslında tarihlerle çalışmak bu ısın her noktasında. Dolayısıyla tarih eşleştirmeleri yapmak veya iki tarih/zaman arasındaki farkı bulmak gibi birçok is yapıyor olacaksınız yukarıdaki veya benzer senaryoları kodlarken. Size bu dökümanda php ile tarih eşlestirmesi yapmayı göstereceğim.

Benzer şekilde tarih karşılaştırmasını mysql’de yapmak için yakında başka bir yazı yayınlayacağım.

Tarih karşılaştırması denince akla çok basit örnekler gelebilir, örneğin X tarihi Y’den önce mi sonra mi? gibi, bunu string karşılaştırması yaparak da yapabilirsiniz. MySQL’de sürekli gördüğünüz “Y-m-d H:i:s” formatı aslında tam olarak bu ihtiyacı karşılayabılır, Yani o tarih formatları string’e de çevrilse string karşılaştırmasında tarihsel sırayı doğru yansıtacaktır.

Ama tarih karşılaştırmaları her zaman böyle once/sonra karşılaştırması değil, 1 haftadan önce mi? veya son 1 aylık veriler… gibi daha karışık örneklere dönebilir. Böyle karışık tarih karşılaştırmaları eğer sihirli fonksiyonlar kullanılmazsa baş ağrısı olabilecek bir konu, çünkü tarihler arasındaki farklar sadece saat dakika saniye gibi matematiksel hesaplarla hesaplanması kısa kodlarla yapılacak bir şey değil. Tabi ki yapılabilir fakat tek satırda ya da tek fonksiyon ile bunu yapmak varken anlamsız. 1 ay öncesi demek her zaman son 30 gün demek değildir mesela. Veya Geçen hafta Pazartesi’yi hesaplamak kolay değildir.

Bu tarz karışık karşılaştırmalar için php’de her zaman kullandığım bir fonksiyon olan strtotime() fonksiyonunu tarih karşılaştırması yapmak için de kullanırım. Örnegin X tarihinin 3 günden önce olup olmadigini:

veya “3 days ago” stringini matematiksel tarih değeri yani timestamp’e çevirerek karşılastırabiliriz. Farkettiyseniz $X değişkenini de strtotime fonksiyonundan geçiriyorum çünkü o da string değeri olduğunu varsayıyorum. Strtotime fonksiyonunun güzel yanı, herhangi bir tarih formatını timestamp’e çevirebiliyor olması. Yani amerikan tarih formatı da yazsanız, bizim kullandığımız formatta da yazsanız php’nin bunu çeviriyor olması. Bundan daha değerli olarak gördüğüm, söylem olarak kullandığımız tarihleri de (2 gün önce, 1 saat sonra, geçen cumartesi, önümüzdeki pazar saat 2) gibi stringleri de doğru olarak timestamp’e çevirebiliyor olması. Bunu kullanarak istediğiniz tarih karşılaştırmasını yapabilirsiniz.

Mesela daha karışık bir örnek olarak:

Bu ufak kontrolle, bütün hafta yazdığınız yazıları bir sonraki hafta pazartesi öğlen 1’de herkese görünür hale getirir. Kontrol’de su anki tarihe göre bir önceki haftanın pazartesi saat öğlen 1’in zaman değeri ile yazıların tarihlerini kıyaslıyoruz. Örnek veriyorum Bugün salı ve siz bi yazı yazdınız, o tarih değeri o haftanın pazartesisinden küçük olmadığı için yukarıdaki kodda if’in içindeki ilk tarih bir sonraki pazartesiye kadar değişmeyecektir. Bir sonraki pazartesi saat 1’de o anın tarihine dönüşeceği için bu salı günü yazdığınız yazı görünür hale gelecektir.

Pharma hack (Google Cloaking Hack) nedir?

Pharma hack nedir?

Pharma hack bır çeşit SEO saldırısıdır. Asıl adı Google Cloaking Hack’dır. Sitenizi html çıktısını kullanıcıya göre manipüle etmek üzerine kuruludur. Pharma hack adını genellikle internette cinsel sağlık ürünleri veya besin takviyesi satan şirketlerin bu hack ile trafik kazanmaya çalışmasından almıştır. Yani bu hack sadece sitenizin arama motoru trafiğini kesmez. Tabi siz analitics yazılımlarda bir trafik kaybı görmezsiniz. Sadece bounce rate’iniz her gün yükselir ve dış trafiğiniz artar. Bu da pagerank’ınızı kaybetmeninizi sağlayabilir.

Büyük tehlike ise sitenizin sansürlenmesi. Türkiye’de son dönemde birçok sitenin/blogun sansürlerden dolayı engellendiğini görüyorsunuz. Bu filtreler genelde halka açık ortamlar, eğitim kurumları gibi alanlarda çok daha etkin. Yani zararsız bir siteye sahip olsanız bile bu hack ile MEB ve BTK’nın google indeksleri ile edindiği site bilgisi genelde cinsel sağlık ürünleri olacağı için muhtemelen siz o içeriğe sahip olmasanız bile okullar, internet cafe’ler gibi yerlerden otomatik olarak filtrelenmiş olacaksınız.

Nasıl oluyor?

Pharma hack sitenize doğrudan ziyaretle anlayamayacağınız bir saldırıdır. Siteniz doğrudan gelen ziyaretçilere normal çıktısını verir ve tarayıcıda doğrudan sitenize giren insanlar sitenizi görmeye devam ederler, böylece siz de anlamazsınız pharma hack altında olduğunuzu.

Ama arama motoru botları sitenizi taramaya çalıştığı zaman sitenizin hack kodu sitenizin sayfa başlığı, anahtar kelimeleri gibi meta etiketlerini değiştirip sayfa içeriğinde istedikleri anahtar kelimeleri de ekleyerek sitenizin çıktısını manipule eder. Böylece pagerank’ınızı kullanarak arama motorlarından gelen trafiğinizi çalarlar. Böylece sitenize ait tüm google indeksleri bir sonraki güncellemede o anahtar kelimeleri alır. Eğer siteniz yüksek page rankına sahipse o anahtar kelimelerde üst sıralarda çıkar ve kullanıcı linke tıkladıgı zaman sayfanızdaki ufak bir javascript kodu kullanıcıyı başka bir sunucuya yönlendirir. Arama motoru trafiğiniz yanlış içerikle sunulur ve kısaca arama motoru trafiğiniz başka bir siteye yönlendirilir.

Sitenizde pharma hack var mı?

Sitenizi sayfaları kontrol ederek pharma hack olup olmadığını anlayamazsınız. Birkaç yolu var;

1) Tarayıcınızın User Agent’ını GoogleBot olarak değiştirip sitenize girebilir, sayfalarınız öyle kontrol edebilirsiniz.

2) Google Webmaster Tools’a kayıt olup sitenizi ekleyip google botun sitenizi nasıl taradığını görebilirsiniz. Googlebot site sitenizin verdiği HTML çıktısını gösterecektir. Meta etiketlerinizi ve sayfa içeriğinizi kontrol edip fakrlı olup olmadığını görebilirsiniz.

Ne tür uygulamalarda yapıyorlar?

Benim gördüğüm örnekleri popüler php hostinglerde ya sunucu kontrolünü ele geçirdikten sonra tüm hesaplara ya da sadece sizin hesabınızı ele geçirdilerse sizin hesabınızda yapılan birkaç ufak php numarasıyla sayfalarınızı arama motoru botlarında farklı render etme üzerine kuruludur. Eğer bir wordpress bloguna veya joomla, drupal gibi bir CMS kullanıyorsanız muhtemel olarak tehlike altındasınız demektir çünkü ele geçirilmesi, gizlenmesi en kolay ve hackerların hedef kitlesidir.

Örnek bir pharma hack kodu göstermem gerekirse:

Bu kod wordpress bloglar için özellikle yazılmış bir pharma hack kodu. Genelde sitenizde her sayfada çalıştırılan bir dosyada yer alırlar. (bootstrap.php, common.php, db.php vs…)

PHP ile basit HTTP authentication

Authentication, yani kimlik dogrulama, daha anlasilir ifade ile bir sayfayi kullanicilara sinirlamak veya tek bir kullanici olan yoneticiye sinirlamak icin genelde birkac yontem izlenir, hangi web altyapisini yaziyor olursaniz olun bununla her calistiginiz projede karsilasabilirsiniz. Kullanicilar icin hazirlanmasi gereken authentication icin yapacak birsey yok, kayit, giris, cikis vs gibi seyleri yazmak zorundasiniz. Fakat yonetici gibi tek kullanici icin sinirlandirilmak istenen sayfalar icin en pratik cozum ve genelde tercih edilen cozum htaccess ile basic auth yapilmasidir, yani statik bir sifre ve belirli bir kullanici adi ile yapilan http authentication. Sunucu konfigurasyonunuza gore (belki cpanel gibi paneller yardimi ile) bir dizini veya bir sayfayi sinirlandirir ve bunun icin hic kod yazmadan halledebilirsiniz.

Ancak her zaman bu imkan elinizde olmayabilir (mesela sadece ftp erisimine sahip oldugunuz ve htaccess desteklemeyen bir hosting konfigurasyonu). Ya da authentication’u bir sekilde kodunuzda saklamak istiyor olabilirsiniz.

PHP’de sayfa header’lari ile tarayicidan authentication bilgisi isteyebiliyoruz. Bunu kullanarak http authentication yaptirabiliriz, bunun avantaji kullanici girisi icin herhangi bir arayuz yazmak zorunda kalmamamizdir. Tabi bir diger avantaji ise bu bilgi giris ekranlarini tarayicilar yonettigi icin sifre hatirlama, belki 1password gibi uygulamalar ile kimlikleri saklama gibi secenekler sunuyor ve kullaniciniz bu seceneklerden faydalanmak istiyor olabilir. Her zaman sayfa icindeki elementlerle bunu saglayamayabilirsiniz.

Son birkac projemde daha duzenli kullandigim bir kodu paylasacagim. Bu kodu tek bir dosyaya (mesela auth.php) yazip bu dosyayi tum uygulamamda include ediyorum en basta. Boylece eger birisi authenticate edilmeden ulasmaya calisirsa http auth ile karsilaniyor.

PHP siniflarinizi RESTful API’lere cevirin: Restler

Restler, multi-protocol ve acik kaynak kodlu, siniflarinizi otomatik olarak rest api’lere ceviren bir php kutuphanesi.

Cok ufak ve XML, JSON, Plist and AMF gibi populer tasinabilir veri formatlarini destekliyor ve neredeyse tum http methodlariyla calisiyor.

Eger iyi yapilandirilmis bir sinifiniz var ve icindeki butun public methodlar genellikle bagimsiz birer gorevi ifade ediyorsa bu kutuphaneyle, sinifinizi her yerden kullanilabilir hale getirebilirsiniz. Veya api uretmek icin ozel bir sinif hazirlayip bu kutuphane ile rest api’ye cevirebilirsiniz.

Restler

Htaccess ile adresinizdeki www’yu kaldirin

Herhalde milyon tane baslik acilmis ve bu soru cevaplanmistir fakat su an duzenleme yaparken daha dogru bir cozum buldum bu konuya ve sizinle paylasmak istedim.

Web sitenizin adresindeki www’dan kurtulmak icin htaccess’da mod_rewrite’i kullanabilirsiniz. Bircok farkli cozum var fakat icinde domain, hostname degisikligi yapmadan her yerde kullanabileceginiz ve bence en dogru cozum olarak su kodu kullanabilirsiniz:

Not: otomatik link olustugu icin kod icindeki link ve ikona takilmayin, kodu kopyaladiginizda dogru kopyalanacaktir.

Web projeleri icin Springloops

Yaklasik 1 yildir springloops’da denemeler yapiyordum 2-3 ay oncesine kadar. Ufak tefek projelerimin svn deposu idi sadece, sonra deployment ozelliklerini inceledim ve birkac projeyi springloops ustunden deploy yapmaya basladim. Ancak gecen ay mfyz.com’un svn deposunu paketleyip springloops’a tasidim. Son 2 haftada da on yuzde olmasa da altyapida cok fazla degisiklik yapiyorum. Otomatik deploymentlar ile dogrudan yayina aliniyor, su an sadece ben gelistiriyor oldugum icin manual deployment’a ihtiyac duymuyorum.

Bu benim hikayemdi, ama genel olarak neredeyse butun web projelerinizde kullanabileceginiz, kullanmanizi tavsiye ettigim bir servis springloops. Eger birden fazla proje ve 5 developerdan daha fazla, veya buyuk dosya boyutuna sahip bir projede calisiyorsaniz aylik $10 odeyerek en ufak paketini alabilirsiniz. Aktif calistiginiz proje sayisi birden fazla ise aylik $10 ~ yillik $120 boylesine guzel bir servis icin hicbirsey. Ayrica tek aktif proje ve belli bir disk alani limiti ile ucretsiz uyelik de sunuyorlar, servisin tum yeteneklerini sure siniri olmadan deneyebilirsiniz.

FTP veya SCP/SSH ustunden deployment’lar, version control’deki eventlara alert veya web-script atayabilmek de otomatize edilmis bir ortam olusturmak icin buyuk kolayliklar saglayabilir.

Buradan inceleyebilirsiniz: http://www.springloops.com/