Skip to content
Wordpress

WordPress Javascript Dosyalarını Footer’a Taşıma

WordPress alt yapılı bir siteniz varsa geliştirirken takıldığınız noktalardan birisinin de <head> etiketleri arasında yer alan javascript dosyalarının otomatik olarak footer’a taşınmamasıdır. Malesef bunu elinizle yapmanız gerekiyor.

Bu noktada devreye WordPress tarafından geliştirilmiş ve çok güzel şekilde çalışan bir fonksiyon giriyor. wp_enqueue_scripts() fonksiyonu içerisine girdiğiniz dosyaları otomatik olarak footer’a taşıma işlemini yapıyor. Ben bunu kendi kullandığım yöntem ile anlatacağım. Öncelikle bir fonksiyon oluşturarak içerisine bazı veriler girmem gerekiyor. Bu veriler ilk olarak daha önceden tanımlı bir dosya için geçerliyse onu iptal etmek ve yeniden footer’da gösterilmek üzere tanıtmak oluyor. Functions.php dosyamızı açarak aşağıdaki gibi kodlarımızı giriyoruz.

// Javascript'leri Footer'a taşıma Kodu
function footera_tasi() {
 
	// Tanımlı dosyaları tanımsız hale getiriyoruz.
	wp_deregister_script( 'jquery' );
	wp_deregister_script( 'jquery-migrate' );
 
	// Dosyaları kodlarımız arasında kaldırıyoruz.
	wp_dequeue_script( 'jquery' );
	wp_dequeue_script( 'jquery-migrate' );
 
	// Kendi dosyalarımızı tanımlıyoruz.
	wp_register_script( 'jquery', get_stylesheet_directory_uri() . '/js/jquery.js', '', '', true );
	wp_register_script( 'jquery-migrate', get_stylesheet_directory_uri() . '/js/jquery-migrate.js', '', '', true );
 
	// Dosyaları kodlarımız arasına ekliyoruz.
	wp_enqueue_script( 'jquery' );
	wp_enqueue_script( 'jquery-migrate' );
 
 
}
add_action('wp_enqueue_scripts', 'footera_tasi', PHP_INT_MAX);

Bu kodu kullanarak WordPress tarafından default olarak gelen ve eklentilerden kaynaklanan javascript dosyalarınızı footer’a taşıyabilirsiniz. Burda kullandığımız wp_register_script() fonksiyonu içerisine 5 parametre alır. Bunlar sırayla, ('dosya-ismi', 'dosya-yolu', 'dizisi – default olarak array() alır – ', 'versiyonu', 'footera taşınsın mı?') şeklinde olmalıdır. Biz kodumuzda dosya adı ve dosya yolunu girdikten sonra 3. ve 4. parametrelerimizi boş bırakarak default değerlerini almasını sağladık ama 5. parametremize true değerini vererek kodlarımızı footer’a gönderdik.

wp_register_script() fonksiyonunun Codex‘te yer alan sayfasına göz atarsanız WordPress’in içerisinde otomatik olarak tanımlı olan javascript dosyalarının isimlerini görebilirsiniz.

Bunun dışında bu kod nerede işimize yarar diye soracak olursanız, benim oldukça fazla kullandığım yapılar arasında yer alır. Bu kod sayesinde istediğimiz javascript kodunu istediğimiz sayfa veya yazıda aktif edebiliriz. Mesela ben eğer Jetpack eklentisini ve ya Contact Form eklentisini anasayfa içerisinde hiçbir yer kullanmıyor, sadece bir sayfada veya yazı içerisinde kullanıyorsam, bunların anasayfa için yüklenmesi benim sitemi yavaşlatacaktır ki bu hiç istemediğimiz bir durum. Bunun önüne geçmek için aşağıdaki gibi bir yapı kullanabiliriz.

// Javascript'leri Footer'a taşıma Kodu
function footera_tasi() {

	// Tanımlı dosyaları tanımsız hale getiriyoruz.
	wp_deregister_script( 'jquery' );

	// Dosyaları kodlarımız arasında kaldırıyoruz.
	wp_dequeue_script( 'jquery' );

	// Kendi dosyalarımızı tanımlıyoruz.
	wp_register_script( 'jquery', get_stylesheet_directory_uri() . '/js/jquery.js', '', '', true );

	// Sadece yazı içerisinde jquery dosyamızı kodlarımız arasına ekliyoruz.
	if(is_single()){
		wp_enqueue_script( 'jquery' );
	}
}
add_action('wp_enqueue_scripts', 'footera_tasi', PHP_INT_MAX);

WordPress Tarafından Eklenen Javascript’ler

Son olarak, sitemizde yer alan eklentiler veya WordPress tarafından otomatik olarak eklenen javascript dosyalarının neler olduğunu veya adını bilmiyorsanız görünmesini istediğiniz yere

<?php global $wp_scripts; var_dump($wp_scripts); ?>

yazarak sitenizde bulunan bütün javascript dosyalarını ayrıntılı olarak görebilirsiniz. Sizin kullandığınız dosyalar ise en alt taraflarda bulunan dosyalar olacaktır. Buradan dosyanıza tanımlı kısa isimi öğrenip onu önce o ismi kullanarak tanımsız hale getirip daha sonra istediğiniz şekilde aktif edebilirsiniz. Eklentilerden kaynak dosyaları tekrar aynı isimle aktif ederseniz eklenti ile ilgili problemlerin önüne geçmiş olursunuz.

PSR Nedir? Türkçesi PHP Standartları Tavsiyeleri Nedir?

Eğer hırslı bir PHP Geliştirici iseniz, yolunuz mutlaka PSR kısaltması ile kesişmiştir. Bu yazı hazırlanırken PSR-0, PSR-1, PSR-2, PSR-3, PSR-4 ve PSR-7 olmak üzere kabul edilmiş 6 standart tavsiyesi bulunuyor. Bunlara ilave olarak PSR-6 Caching Interface (Önbellek Arayüzü) standardı onay ve PSR-5 PHPDoc Standard (PHPDoc Standardı), PSR-8 Huggable Interface (Sarılabilir Arayüzü), PSR-9 Security Disclosure (Güvenlik Bilgilendirmesi) ve PSR-10 Security Advisories (Güvenlik Önerileri) standartları taslak aşamasında bekliyor.

Bu yazıda kabul edilmiş standartların neler olduğunu ve neden dikkate almanız gerektiğini incelemeye çalışacağım.

Kısa Özet

PHP kod yazmak için hiçbir zaman tam anlamıyla merkezileşmiş bir standarta sahip olmadı. Büyük yazılım ekiplerine sahip şirketler ve birden fazla kod tabanını idame ettiren kişiler projeleri için isimlendirme ve kodlama stilleri hazırladılar. Bazıları PEAR veya Zend Framework gibi iyi dökümante edilmiş standartları baz almaya çalışırken, diğerleri sıfırdan birşeyler üretmeye çalıştılar.

The Framework Interoperability Group (PHP-FIG)

2009 yılındaki php|tek konferansında, çeşitli projeleri temsil eden kişiler projeleri arasında ortaklaşa çalışmanın yollarını tartıştılar. Bunun üzerine kod tabanları arasında bir grup standarda uyulması gündeme geldi.

Bir süre kendilerine “PHP Standards Group” dedikten sonra, bu ismin grubun amacını doğru yansıtmadığını düşündükleri için Framework Interoperability Group (FIG) olarak yollarına devam ediyorlar. Grubun ismi kod çatılarına atıfta bulunsa da çeşitli projeleri temsil eden birçok geliştirici oylayıcı üye olarak gruba kabul edildi.

PHP-FIG’in Amacı

PHP-FIG proje temsilcileri arasında bir dialog ortamı oluşturarak, beraber çalışmanın yollarını aramaktadır. Bu zamana kadar oluşan dialoglar sonucunda 6 tavsiye kabul edilmiştir. Bu tavsiyeler isteyen herkes tarafından uygulanabilmekle birlikte, kimse için zorunlu değildir.

PSR-0: Autoloader Standard (Otomatik Yükleme Standardı) ve PSR-4 Improved Autoloading (Gelişmiş Otomatik Yükleme)

PSR-0 tekrar kullanılabilir kod için büyük bir adımdır.

Her dosyanın başında ihtiyaç duyduğunuz tüm dosyalar için include veya require tanımlaması yaptığınızı hatırlıyor musunuz? Çok şükür bu kullanım PHP 5 ile birlikte gelen sihirli __autoload() fonksiyonu sayesinde değişti. PHP 5.1.2 ‘nin bize tanıştırdığı spl_autoload() ve spl_autoload_register() sayesinde otomatik yükleme çok daha kolay ve dinamik hale geldi.

Otomatik yükleme fonksiyonu ne kadar iyi olsa da, mevcut kod yapılarında nasıl uygulanması gerektiğini tanımlamıyordu. A kütüphanesi ile B kütüphanesinin klasör ve sınıf adı yapısına bakış açısı birbirinden farklı olabiliyor. Fakat siz iki kütüphaneyi de kullanmak istiyorsunuz.

Tüm olasılıkları kapsayacak üzgün bir otomatik yükleme (autoloader) sınıfı yazmak hızlı bir şekilde kaosa dönüşüyordu. Sınıf isimlerini ve nerede olmaları gerektiğini tanımlayan bir standart olmadan otomatik yükleme bir rüyadan ibaretti.

PSR-0 “Ortak çalışan otomatik yükleme için uyulması gereken zorunlu gereksinimler” i tanımlayan bir standart önerisidir. PSR-4‘ün yayınlanması ile birlikte 21 Ekim 2014’de miladını doldurmuştur.

Eğer bir proje PSR-0 veya PSR-4 standardını izliyorsa ve serbest bileşenleri varsa, kolayca ihtiyaç duyduğunuz bileşenleri alıp, vendor klasörünüze koyabilir ve PSR-0 veya PSR-4 uyumlu bir otomatik yükleyici ile o bileşenleri yükleyerek kullanabilirsiniz. Hatta daha iyisi izin verin bunu sizin yerinize Composer yapabilir.

PSR-4, PSR-0’a ilave olarak kütüphane ile gelen dosyaların nereye koyulacağını da belirtmektedir.

PSR-1: Basic Coding Standard (Temel Kodlama Standardı)

PSR-1 en basit düzeyde kodlama standartlarına odaklanmaktadır. Çok detaylı olmaktan kaçınmakta, bu sayede daha büyük bir kitle tarafından benimsenmesi hedeflenmektedir.

PSR-1 kapsamındaki maddelerden bazıları;

  • Dosyalar sadece <?php ve <?= kullanmalıdır.
  • PHP dosyaları sadece UTF-8 without BOM kodlamasına sahip olmalıdır.
  • Dosyalar ya bir sembol tanımlamalı (Sınıf, Fonksiyon, Sabit vs.) ya da bir yan etki ( çıktı üretmek, .ini ayarlarını değiştirmek vs.) üretmelidir. Fakat ikisini birden yapmamalıdır.
  • Namespace ve sınıflar PSR-0 veya PSR-4 standardını izlemelidir.
  • Sınıf isimleri StudlyCaps şeklinde tanımlanmalıdır.
  • Sınıf sabitleri tamamı büyük harf olacak şekilde tanımlanmalıdır.
  • Metod isimleri camelCase şeklinde tanımlanmalıdır.

Bu temel kurallar isimlendirmelere ve dosya yapısına odaklanmaktadır. Bu sayede paylaşılan PHP kodları görünüm ve davranış bakımından aynı olacaktır.

PSR-2: Coding Style Guide (Kodlama Stil Rehberi)

PSR-2, PSR-1 tarafından tanımlanmış temel kodlama standartlarını genişletir. Amacı paylaşılan kodların tek bir şekilde yazılmasını sağlayan bir rehber olmaktır.

Grup üyelerinin temsil ettikleri projeler üzerinde yapılan detaylı inceleme sonucunda en büyük kitleyi kapsayan özellikler temel olarak alınmıştır.

PSR-2 kapsamına genel bakış;

  • Kod PSR-1 kapsamında belirtilen kurallara uymak zorundadır.
  • Girintiler için 4 boşluk kullanılır. Tab değil
  • Satır uzunluklarında katı sınır olmamalıdır. Yumuşak sınır 120 karakterdir. Satırlar mümkünse 80 karakter veya daha kısa olmalıdır.
  • namespace tanımlamasından sonra bir boş satır bırakılmalıdır. use tanımlamalarından sonra da bir satır boşluk olmalıdır.
  • Sınıfların açılış ve kapanış parantezleri alt satırda olmalıdır.
  • Metodların açılış ve kapanış parantezleri alt satırda olmalıdır.
  • Tüm metodlarda görünürlük ( public, protected, private ) tanımlaması bulunmak zorundadır abstract ve final tanımlamaları görünürlük tanımlamasından önce, static ise görünürlük tanımlamasından sonra olmalıdır.
  • Kontrol yapısı anahtar kelimelerinden sonra bir boşluk olmalıdır. metod ve fonksiyon çağrılarında boşluk olmamalıdır.
  • Kontrol yapılarının açılış parantezleri aynı satırda, kapanış parantezleri alt satırda olmalıdır.
  • Kontrol yapılarının açılış parantezlerinden sonra ve kapanış parantezlerinden önce boşluk olmamalıdır.

PSR-2 kurallarının tamamına fig-standards reposundan ulaşabilirsiniz.

PSR-2 standartları günümüzde özellikle github üzerindeki açık kaynak repolarda aktif şekilde kullanılmaya başladı. Bunun en büyük avantajı repo’ya katkıda bulunan kişilerin gönderdiği kodların diff görünümlerinin daha düzgün olması ve herkesin özel kod formatı yüzünden kodun gereksiz yere değişmemesi olduğunu düşünüyorum. Hali hazırda popüler olan tüm editörler PSR-2 uyumlu kod formatlama seçenekleri sunuyorlar. Bu sayede geliştiriciler tek bir seçenek ile evrensel formata uygun kod yazabiliyorlar.

PSR-3: Logger Interface (Loglayıcı Arayüzü)

PSR-3 paylaşılmış bir loglayıcı arayüzünü tanımlar ve The Syslog Protocol (RFC 5424) tarafından belirlenmiş 8 seviyeyi (debug, info, notice, warning, error, critical, alert, emergency) içermektedir.

Bu sekiz Syslog seviyesi metod adı olarak tanımlanmıştir ve her biri $mesaj ve $içerik olmak üzere iki parametre kabul etmektedir. $içerik parametresi, $mesaj parametresi ile düzgün aktarılamayan değerleri taşımaktadır.

PSR-3 gibi bir ortak arayüz standartı; frameworkler, kütüphaneler ve diğer uygulamaların bu ortak arayüze tür dayatma (typehint) yapması sayesinde, geliştiricilerin tercih ettikleri uygulamayı seçmelerine olanak sağlamaktadır.

Başka bir deyişle, PSR-3 uyumlu bir loglama bileşeni, rahatlıkla PSR-3 uyumlu başka bir bileşen ile değiştirilebilmektedir. Bu loglayıcı entegrasyonları ile log çağrıları arasında maksimum ortak çalışmayı garanti altına almaktadır.

Hali hazırda birçok popüler framework’le birlikte gelen Monolog PSR-3 destekli olarak çalışmaktadır.

PSR-7: HTTP Message Interface (HTTP Mesaj Arayüzü)

HTTP mesajları internetin en temel bileşenidir. Bir web sayfasını yüklemek için bir talep (request) yapar ve karşılığınca bir cevap (response) alırsınız. Bir php sitesinin çalışabilmesi için de aynı şekilde gelen talebin anlamlandırılması ve talebe uygun cevabın hazırlanarak müşteriye ulaştırılması gerekir. PSR-7 ile birlikte frameworklerin ve harici bileşenlerin tek bir mesaj arayüzü kullanması ve bu sayede frameworkler ve bileşenler arasındaki tekrar kod kullanılabilirliği arttırılması hedeflenmiştir.

PSR-7 paylaşılmış HTTP mesaj arayüzlerini tanımlar. Bu PSR kapsamında 7 adet arayüz sağlanmaktadır.

Bu arayüzlerden ve kullanım amaçlarından kısaca bahsetmek gerekirse;

  • MessageInterface: Gelen ve giden mesajların tanımlandığı temel arayüzdür.
  • RequestInterface: MessageInterface’i genişleterek talep mesajlarının arayüzünü oluşturur.
  • ResponseInterface: MessageInterface’i genişleterek cevap mesajlarının arayüzüdür.
  • ServerRequestInterface: RequestInterface’i genişleterek sunucu tarafından yapılan taleplerde kullanılan mesaj parametrelerinin tanımlanmasını ve kullanılmasını sağlayan bir arayüzdür.
  • StreamInterface: Mesajların gövdesini oluşturur. Evrensel ve esnek bir yapı olması için, düz bir metin bile olsa akış olarak tanımlanır ve kullanılır.
  • UploadedFileInterface: Mesajlarla birlikte yüklenen dosyaları tanımlayan arayüzdür. $_FILES değişkeni yüklenen dosyanın yükleme metoduna göre farklılık gösterebildiğinden, bu nesne dosya içeriğini standart hale getirir.
  • UriInterface: Talebin yapıldığı URI’yi yönetmek için kullanılır.

Hali hazırda, Pek çok bileşen tarafından kullanılan Guzzle, versiyon 6 ile birlikte PSR-7 altyapısını kullanmaya başladı. Ayrıca Symfony, bünyesindeki popüler HttpFoundation bileşenin PSR-7 uyumluluğunu sağlamak için PSR-7 Bridge adında ek bir bileşen yayınladı.