WordPress.org’da Eklenti Yayınlama ve İnceleme Süreci

Yazar:komut.io ekibi WordPress Eklentisi Geliştirme ve Yönetimi
0 Yorum

Yıllar önce ilk eklentimi wordpress.org’a göndermeden önce ne kadar hazırlıksız olduğumu düşünüyorum. Readme dosyası eksikti, kod standartlarına uymuyordum ve inceleme ekibinden gelen ilk yanıt beni gerçekten şaşırttı. O günden bu yana onlarca eklenti geçirdim bu süreçten ve şunu söyleyebilirim: wordpress.org inceleme süreci, göründüğünden çok daha sistematik ve öğretici bir deneyim.

WordPress.org Eklenti İnceleme Sürecine Genel Bakış

WordPress.org’a eklenti göndermek, bir Pull Request açmak gibi düşünülebilir, sadece çok daha geniş bir kitleye yönelik. İnceleme ekibi (Plugin Review Team) gönüllülerden oluşuyor ve her gün onlarca başvuruyu değerlendiriyor. Bu insanlar hem WordPress güvenlik standartlarını hem de kullanıcı deneyimini göz önünde bulundurarak kodunuzu inceliyor.

Sürecin genel akışı şöyle işliyor:

  • Eklentiyi zip olarak gönderiyorsunuz
  • Otomatik ön denetimden geçiyor
  • Manuel inceleme sırası bekleniyor (ortalama 1-3 hafta)
  • İnceleme sonucu email ile geliyor: ya onay, ya düzenleme talebi
  • Düzenleme yapıp tekrar gönderiyorsunuz
  • Onay sonrası SVN erişimi açılıyor ve yayına alıyorsunuz

Şimdi bu adımların her birinin içine girelim.

Gönderim Öncesi Hazırlık: Kod Standartları

İnceleme ekibinin en çok takıldığı nokta, WordPress Coding Standards’a uyum. Bu standartlara uymadan gönderdiğiniz eklenti büyük ihtimalle geri gelecek.

Öncelikle PHPCS (PHP CodeSniffer) ile WordPress standartlarını yerel ortamınıza kurun:

composer global require wp-coding-standards/wpcs
composer global require phpcompatibility/phpcompatibility-wp
phpcs --config-set installed_paths ~/.composer/vendor/wp-coding-standards/wpcs,~/.composer/vendor/phpcompatibility/phpcompatibility-wp

Eklentinizi taramak için:

phpcs --standard=WordPress --extensions=php /path/to/your/plugin

Otomatik düzeltme yapabilmek için phpcbf kullanın:

phpcbf --standard=WordPress --extensions=php /path/to/your/plugin

Burada dikkat etmeniz gereken önemli bir nokta var: phpcbf her şeyi otomatik düzeltemez. Özellikle sanitizasyon, validasyon ve nonce kontrolleri gibi güvenlik odaklı düzeltmeler manuel müdahale gerektirir.

readme.txt Dosyasının Doğru Hazırlanması

Bu dosyayı küçümsemeyin. İnceleme ekibinin baktığı ilk şeylerden biri bu. Yanlış ya da eksik bir readme.txt, eklentinizin kategorize edilmesini zorlaştırıyor ve zaman zaman reddedilmesine neden oluyor.

Standart bir readme.txt şöyle görünmeli:

cat > readme.txt << 'EOF'
=== Eklenti Adı ===
Contributors: kullaniciadi
Tags: tag1, tag2, tag3
Requires at least: 5.8
Tested up to: 6.4
Requires PHP: 7.4
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Kısa açıklama buraya gelecek. 150 karakteri geçmemeli.

== Description ==

Detaylı açıklama buraya.

== Installation ==

1. Eklentiyi yükleyin.
2. Aktif edin.
3. Ayarlar menüsüne gidin.

== Frequently Asked Questions ==

= Soru burada =

Cevap burada.

== Changelog ==

= 1.0.0 =
* İlk sürüm yayınlandı.
EOF

Tags alanına dikkat edin. İnceleme ekibi “premium”, “best”, “free” gibi pazarlama kelimelerini kabul etmiyor. Teknik ve açıklayıcı taglar kullanın.

Güvenlik Kontrolleri: İnceleme Ekibinin En Hassas Olduğu Alan

Gerçek dünyadan bir örnek vereyim: Bir müşteri için WooCommerce siparişlerini harici bir sisteme aktaran bir eklenti geliştirdim. İlk gönderimde inceleme ekibi üç ayrı güvenlik sorunu tespit etti. Bunların hepsini biliyordum ama “production’da zaten kimse erişemez” diye geçiştirmiştim. Yanılıyordum.

Nonce Kontrolü

Her form işleminde nonce kullanmak zorunlu:

// Form oluşturulurken
function my_plugin_settings_form() {
    ?>
    <form method="post" action="">
        <?php wp_nonce_field( 'my_plugin_save_settings', 'my_plugin_nonce' ); ?>
        <input type="text" name="my_option" value="<?php echo esc_attr( get_option( 'my_option' ) ); ?>" />
        <input type="submit" value="Kaydet" />
    </form>
    <?php
}

// Form işlenirken
function my_plugin_save_settings() {
    if ( ! isset( $_POST['my_plugin_nonce'] ) ) {
        return;
    }
    
    if ( ! wp_verify_nonce( $_POST['my_plugin_nonce'], 'my_plugin_save_settings' ) ) {
        wp_die( 'Güvenlik doğrulaması başarısız.' );
    }
    
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Yetkiniz bulunmuyor.' );
    }
    
    $my_option = sanitize_text_field( $_POST['my_option'] );
    update_option( 'my_option', $my_option );
}

Veri Sanitizasyonu ve Escape

Bu konuda inceleme ekibi çok net bir çizgi çiziyor. Gelen veriyi sanitize edin, çıkan veriyi escape edin:

// Veri kaydetmeden önce sanitize
$email = sanitize_email( $_POST['user_email'] );
$text  = sanitize_text_field( $_POST['description'] );
$html  = wp_kses_post( $_POST['content'] ); // HTML içerik için
$url   = esc_url_raw( $_POST['website'] );

// Veri gösterilmeden önce escape
echo esc_html( $text );
echo esc_attr( $attribute_value );
echo esc_url( $url );
echo wp_kses_post( $html_content );

Doğrudan Veritabanı Sorguları

Eğer $wpdb kullanıyorsanız, prepared statements zorunlu:

global $wpdb;

// YANLIŞ - asla böyle yapmayın
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}posts WHERE post_author = " . $_GET['user_id'] );

// DOĞRU - prepared statement kullanın
$user_id = absint( $_GET['user_id'] );
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->prefix}posts WHERE post_author = %d",
        $user_id
    )
);

Prefix Kullanımı: Çakışmaları Önleyin

İnceleme ekibinin mutlaka kontrol ettiği bir diğer konu, fonksiyon, sınıf ve global değişken isimlerinin benzersiz prefix kullanması. Birden fazla eklenti aynı fonksiyon adını kullanırsa çakışma kaçınılmaz olur.

// YANLIŞ - genel isimler çakışmaya yol açar
function get_data() { ... }
function save_settings() { ... }
$options = array();

// DOĞRU - benzersiz prefix kullanın
function myplugin_get_data() { ... }
function myplugin_save_settings() { ... }
$myplugin_options = array();

// Sınıf kullanıyorsanız bu da geçerli bir yaklaşım
class MyPlugin_Settings {
    public function get_data() { ... }
    public function save() { ... }
}

Prefix seçerken eklenti adınızı ya da firmanızı temsil eden bir kısaltma kullanın. “wp_”, “woo_” gibi WordPress ve WooCommerce rezerve prefixlerini kesinlikle kullanmayın.

Harici Servisler ve Lisans Uyumluluğu

Eklentiniz harici bir API’ye bağlanıyorsa, bunu readme.txt’te ve kod içinde açıkça belirtmeniz gerekiyor. Ayrıca bu servisin kullanım şartlarına bir link vermeniz bekleniyor.

/**
 * Harici API'ye bağlan.
 *
 * Bu fonksiyon ExternalService.com API'sini kullanır.
 * Kullanım şartları: https://externalservice.com/terms
 * Gizlilik politikası: https://externalservice.com/privacy
 *
 * @param string $endpoint API endpoint.
 * @param array  $data     Gönderilecek veri.
 * @return array|WP_Error API yanıtı.
 */
function myplugin_call_external_api( $endpoint, $data ) {
    $api_key = get_option( 'myplugin_api_key' );
    
    $response = wp_remote_post(
        'https://api.externalservice.com/v1/' . $endpoint,
        array(
            'headers' => array(
                'Authorization' => 'Bearer ' . $api_key,
                'Content-Type'  => 'application/json',
            ),
            'body'    => wp_json_encode( $data ),
            'timeout' => 15,
        )
    );
    
    if ( is_wp_error( $response ) ) {
        return $response;
    }
    
    return json_decode( wp_remote_retrieve_body( $response ), true );
}

Lisans konusuna dikkat: WordPress GPL lisansıyla dağıtılıyor ve eklentinizin de GPL uyumlu bir lisansla yayınlanması gerekiyor. GPLv2 ya da later seçeneği genellikle tercih edilen yaklaşım.

SVN ile Eklenti Yayınlama

Onay aldıktan sonra SVN üzerinden eklentinizi yönetiyorsunuz. Bu, Git’e alışmış geliştiriciler için biraz garip gelebilir ama mantığı aynı.

# SVN repository'yi checkout edin
svn checkout https://plugins.svn.wordpress.org/eklenti-adiniz/ ~/eklenti-adiniz

# Dizin yapısını inceleyin
ls ~/eklenti-adiniz
# trunk/  tags/  assets/

# Eklenti dosyalarınızı trunk'a kopyalayın
cp -r /path/to/your/plugin/* ~/eklenti-adiniz/trunk/

# Değişiklikleri SVN'e ekleyin
cd ~/eklenti-adiniz
svn add trunk/*
svn add trunk/includes/*  # Alt dizinler için ayrıca ekleyin

# Durumu kontrol edin
svn status

# Commit edin
svn commit -m "İlk sürüm yayınlandı - v1.0.0"

Yeni sürüm yayınlarken tag oluşturmanız gerekiyor:

# trunk'tan yeni bir tag oluşturun
svn copy https://plugins.svn.wordpress.org/eklenti-adiniz/trunk 
         https://plugins.svn.wordpress.org/eklenti-adiniz/tags/1.0.0 
         -m "1.0.0 sürümü etiketlendi"

# readme.txt'teki Stable tag'i güncelleyin
# Stable tag: 1.0.0
svn commit -m "Stable tag güncellendi"

Assets klasörü, eklenti sayfanızda görünen görseller için kullanılır:

# Eklenti banner ve ikon görselleri ekleyin
cp plugin-banner-772x250.png ~/eklenti-adiniz/assets/
cp plugin-banner-1544x500.png ~/eklenti-adiniz/assets/
cp plugin-icon-128x128.png ~/eklenti-adiniz/assets/
cp plugin-icon-256x256.png ~/eklenti-adiniz/assets/

svn add assets/*
svn commit -m "Eklenti görselleri eklendi"

Banner boyutları 772×250 ve yüksek DPI için 1544×500 piksel olmalı. İkon boyutları ise 128×128 ve 256×256.

İnceleme Ekibinden Geri Bildirim Geldiğinde

Bu noktada pek çok geliştirici panikliyor. Aslında geri bildirim bir red değil, bir düzeltme talebi. Emailde belirtilen sorunları düzeltin, yanıt olarak düzelttiğinizi bildirin ve beklemeye devam edin.

Geri bildirim emailine yanıt verirken dikkat etmeniz gerekenler:

  • Yaptığınız değişiklikleri maddeler halinde listeleyin
  • Hangi dosyada, hangi satırda ne değiştirdiğinizi belirtin
  • Eğer bir geri bildirimi anlayamadıysanız nazikçe açıklama isteyin
  • Savunmacı olmayın, bu bir kod incelemesi, kişisel değil

Gerçek bir örnek: İnceleme ekibi bir keresinde bana “eklentiniz kullanıcı girdisini doğrudan JavaScript’e yazıyor” dedi. Aşağıdaki kodu kastetmişlerdi:

// YANLIŞ - XSS açığı
echo '<script>var userData = "' . $_POST['username'] . '";</script>';

// DOĞRU - wp_json_encode ve esc_html kullanın
$safe_username = sanitize_text_field( $_POST['username'] );
echo '<script>var userData = ' . wp_json_encode( $safe_username ) . ';</script>';

// Daha iyi yaklaşım - wp_localize_script kullanın
wp_localize_script(
    'my-plugin-script',
    'myPluginData',
    array(
        'username' => sanitize_text_field( $_POST['username'] ),
        'ajaxUrl'  => admin_url( 'admin-ajax.php' ),
        'nonce'    => wp_create_nonce( 'my_plugin_nonce' ),
    )
);

Plugin Check Aracını Kullanın

WordPress, resmi bir Plugin Check eklentisi yayınladı. Bu araç, gönderim öncesi otomatik testleri yerel ortamınızda çalıştırmanıza olanak sağlıyor.

# WP-CLI ile Plugin Check çalıştırın
wp plugin check eklenti-adiniz

# Belirli kategorileri kontrol edin
wp plugin check eklenti-adiniz --categories=security,performance

# JSON çıktı alın
wp plugin check eklenti-adiniz --format=json > check-results.json

Bu araç, inceleme ekibinin kullandığı otomatik kontrollerin bir alt kümesini çalıştırıyor. %100 aynı değil ama gönderim öncesi ciddi bir süzgeç işlevi görüyor.

Süreç Boyunca Sık Yapılan Hatalar

Deneyimlerimden derlediğim, insanların en çok takıldığı noktalar:

  • Doğrudan dosya sistemi erişimi: file_get_contents() yerine WP_Filesystem API kullanın
  • Hardcoded URL’ler: home_url(), admin_url() gibi WordPress fonksiyonlarını tercih edin
  • Gizlenmiş kod: Base64 ile şifrelenmiş kod kesinlikle kabul edilmiyor
  • Gereksiz yetki kontrolleri: is_admin() kontrol etmek yeterli değil, current_user_can() kullanın
  • Error suppression: @ operatörünü kullanmak yerine hataları düzgün ele alın
  • jQuery gereksiz yükleme: WordPress zaten jQuery yüklüyor, tekrar yüklemeyin, wp_enqueue_script ile bağımlılık bildirin
  • README’siz commit: Her sürümde changelog güncellemesi zorunlu

İnceleme Sonrası: Eklentinizi Canlı Tutmak

Onaylandıktan sonra iş bitmiyor. WordPress.org politikası, güvenlik açığı bulunan veya 2 yıldan uzun süre güncelleme almayan eklentileri kapatabiliyor.

Düzenli güncelleme rutini oluşturun:

#!/bin/bash
# update-check.sh - Bağımlılıkları ve uyumluluk durumunu kontrol et

# WordPress son sürümünü kontrol et
LATEST_WP=$(curl -s https://api.wordpress.org/core/version-check/1.7/ | python3 -c "import sys,json; print(json.load(sys.stdin)['offers'][0]['version'])")
echo "Son WordPress sürümü: $LATEST_WP"

# PHP uyumluluk kontrolü
phpcs --standard=PHPCompatibilityWP --runtime-set testVersion 7.4-8.2 --extensions=php /path/to/plugin

# Güvenlik açığı kontrolü (Composer bağımlılıkları varsa)
composer audit

Sonuç

WordPress.org inceleme süreci, ilk bakışta büyük bir engel gibi görünebilir ama aslında kaliteli eklenti geliştirme alışkanlıkları edinmenizi sağlayan değerli bir süreç. Yıllar içinde fark ettim ki, inceleme ekibinin taleplerine uygun yazmaya başladıktan sonra yazdığım tüm PHP kodu genel olarak daha temiz ve güvenli hale geldi.

Gönderim öncesi kontrol listeniz şu şekilde olsun: PHPCS ile WordPress standartlarına uyumu doğrulayın, Plugin Check aracını çalıştırın, readme.txt’i eksiksiz doldurun, güvenlik kontrollerini (nonce, sanitizasyon, escape, yetki) gözden geçirin, harici servisleri belgeleyin ve SVN iş akışını öğrenin.

Süreci bir kez içselleştirdiğinizde, sonraki her eklenti gönderimi çok daha akıcı ilerliyor. İlk eklentimde üç düzeltme turu geçirmiştim; sonrakilerinde çoğunlukla ilk gönderimde onay aldım. Sabır ve dikkat, bu sürecin en değerli iki bileşeni.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir