WordPress.org’a Eklenti Gönderme Rehberi: Adım Adım Yayınlama

WordPress için geliştirdiğiniz bir eklentinin kendi sitenizde çalışması, WordPress.org eklenti dizininde yayımlanmaya hazır olduğu anlamına gelmez. Herkese açık biçimde dağıtılacak bir eklentinin farklı sunucu yapılarını, WordPress sürümlerini, güvenlik kurallarını, lisans koşullarını ve diğer eklenti veya temalarla oluşabilecek çakışmaları dikkate alması gerekir.

WordPress.org’a eklenti gönderme süreci iki ayrı aşamadan oluşur. İlk aşamada eklentinin eksiksiz ZIP paketi inceleme için gönderilir. Eklenti, WordPress.org Eklenti Ekibi tarafından onaylandıktan sonra geliştiriciye bir SVN deposu açılır. İlk yayımlama ve daha sonraki güncellemeler bu SVN deposu üzerinden gerçekleştirilir. Dolayısıyla ZIP dosyasını başvuru ekranına yüklemek ile eklentiyi kullanıcıların indirebileceği şekilde yayımlamak aynı işlem değildir.

Bu rehberde anlatılan hazırlık, kontrol, başvuru ve SVN işlemlerini önce OZD Katalog Eklentisi’ni, daha sonra OZD ImageFileX Eklentisi’ni WordPress.org’a gönderirken uyguladım. İki eklenti de otomatik kontrollerden ve manuel inceleme sürecinden geçti; istenen düzenlemeler tamamlandıktan sonra WordPress.org’un sağladığı SVN depoları üzerinden yayımlandı. OZD Katalog, WooCommerce gerektirmeden ürün ve katalog yönetimi sağlayan bir çözüm; OZD ImageFileX ise görsel dönüştürme işlemlerini WordPress yönetim paneline taşıyan farklı kapsamda bir eklentidir. Böylece rehberdeki adımlar yalnızca tek bir eklenti türüne değil, birbirinden farklı iki gerçek yayın deneyimine dayanmaktadır.

Buradaki amaç eklentileri tanıtan bir liste hazırlamak değil; uygulanmış süreçler üzerinden WordPress.org’a eklenti gönderme adımlarını teknik ve doğrulanabilir biçimde açıklamaktır. OZD Katalog Eklentisi ve OZD ImageFileX Eklentisi sayfaları, anlatılan başvuru ve yayımlama sürecinin WordPress.org üzerindeki gerçek sonuçları olarak ayrıca incelenebilir.

WORDPRESS.ORG EKLENTİ DİZİNİ NEDİR?

WordPress.org eklenti dizini, GPL veyaGPL2 ile uyumlu bir lisansla dağıtılan WordPress eklentilerinin yer aldığı resmî dizindir. Burada yayımlanan eklentiler WordPress yönetim panelindeki “Eklentiler > Yeni Eklenti Ekle” ekranından bulunabilir, kurulabilir ve güncellenebilir.

WordPress.org yalnızca dosya barındıran bir indirme alanı değildir. Eklentilerin ayrıntılı eklenti dizini kurallarına uymasını, kaynak kodlarının incelenebilir olmasını ve kullanıcıların özgürlüklerini kısıtlamamasını bekler. Gönderilen her yeni eklenti otomatik kontrollerin yanında manuel incelemeden de geçer. Plugin Check sonucunun temiz olması önemli bir hazırlıktır; ancak tek başına onay garantisi vermez.

EKLENTİ GÖNDERMEDEN ÖNCE WORDPRESS.ORG HESABI OLUŞTURUN

Eklenti gönderebilmek içinWordPress.org hesabınızın bulunması gerekir. Hesabınızı oluştururken sürekli erişebildiğiniz, gelen kutusunu düzenli kontrol ettiğiniz bir e-posta adresi kullanın. Bir şirket adına eklenti gönderiyorsanız kurumsal e-posta adresi kullanılması önerilir.

İnceleme ekibi başvuruyla ilgili soruları ve düzeltme taleplerini WordPress.org hesabınıza bağlı e-posta adresine gönderir. Bu nedenle plugins@wordpress.org adresinden gelen iletilerin spam klasörüne düşmediğinden emin olun. İnceleme devam ederken yeni bir başvuru açmak yerine, gönderilen inceleme e-postasını yanıtlayarak iletişimi aynı yazışma üzerinden sürdürün.

SVN erişiminde kullanılan kullanıcı adı da WordPress.org kullanıcı adınızdır. Kullanıcı adında büyük ve küçük harf ayrımı önemlidir. WordPress.org hesap ayarlarından SVN için ayrı bir parola oluşturabilirsiniz. Normal hesap parolanızı komut satırında kullanmak yerine SVN parolası kullanmak daha doğru bir yöntemdir.

EKLENTİ ADINI VE KLASÖR ADINI DOĞRU BELİRLEYİN

Eklenti adı, eklentinin yaptığı işi açıklamalı; başka bir eklentinin veya markanın kullanıcılarını yanıltacak biçimde seçilmemelidir. WordPress.org bazı marka adlarının ve çok genel ifadelerin eklenti adı veya kalıcı bağlantı adı olarak kullanılmasına izin vermeyebilir.

Başvuru sırasında eklentinin kalıcı bağlantısı, ana PHP dosyasındaki “Plugin Name” değerine göre oluşturulur. Örneğin “Örnek Form Yöneticisi” adlı bir eklenti için ornek-form-yoneticisi kısa adı oluşturulabilir.

Eklenti onaylandıktan sonra dizin bağlantısındaki kısa ad, yani slug değiştirilemez. Görünen eklenti adı daha sonra ana PHP dosyasındaki başlık bilgisi değiştirilerek güncellenebilir; fakat kalıcı bağlantı aynı kalır. Bu nedenle eklentiyi göndermeden önce adı, klasör adı, metin alanı ve olası WordPress.org kısa adı birlikte düşünülmelidir.

Gönderilecek ZIP paketinin içinde yalnızca bir ana eklenti klasörü bulunmalıdır:

ornek-form-yoneticisi.zip
└── ornek-form-yoneticisi/
    ├── ornek-form-yoneticisi.php
    ├── readme.txt
    ├── uninstall.php
    ├── includes/
    ├── admin/
    ├── public/
    └── languages/

ZIP dosyasının içine geliştirme sırasında kullanılan gereksiz dosyaları eklemeyin. Git klasörü, test çıktıları, kaynak haritaları, kişisel notlar, yedek dosyalar, başka ZIP paketleri ve dağıtım için gerekmeyen geliştirme araçları pakette bulunmamalıdır.

ANA EKLENTİ DOSYASININ BAŞLIK BİLGİLERİNİ HAZIRLAYIN

WordPress, bir PHP dosyasını eklenti olarak tanıyabilmek için dosyanın başındaki eklenti başlık bilgilerini okur. Zorunlu olan tek alan “Plugin Name” olsa da WordPress.org’a gönderilecek bir eklentide sürüm, açıklama, lisans, PHP gereksinimi ve metin alanı gibi bilgilerin eksiksiz yazılması gerekir.

Örnek başlık:

<?php
/**
 * Plugin Name:       Örnek Form Yöneticisi
 * Plugin URI:        https://example.com/ornek-form-yoneticisi/
 * Description:       WordPress için sade ve güvenli form yönetimi sağlar.
 * Version:           1.0.0
 * Requires at least: 6.5
 * Requires PHP:      8.0
 * Author:            Ad Soyad
 * Author URI:        https://example.com/
 * License:           GPL v2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       ornek-form-yoneticisi
 * Domain Path:       /languages
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

Bu alanları belirlerken şu noktalara dikkat edin:

Plugin Name: WordPress yönetim panelinde gösterilecek eklenti adıdır.

Plugin URI: Eklentiye özel tanıtım veya dokümantasyon sayfasıdır. WordPress.org adresi yazılmamalı ve aynı adres farklı eklentiler için tekrar kullanılmamalıdır.

Description: Yönetim panelinde gösterilen kısa açıklamadır. WordPress geliştirici belgesine göre 140 karakterden kısa tutulmalıdır.

Version: Eklentinin gerçek sürüm numarasıdır. Yeni sürüm yayımlarken buradaki değer güncellenmelidir.

Requires at least: Eklentinin çalışabildiği en düşük WordPress sürümüdür. Tahmine göre değil, yapılan testlere göre belirlenmelidir.

Requires PHP: Eklentinin ihtiyaç duyduğu en düşük PHP sürümüdür. Kodda kullanılan PHP özellikleriyle uyumlu olmalıdır.

License ve License URI: Eklentinin lisansını ve lisans metninin adresini belirtir.

Text Domain: Çeviri fonksiyonlarında kullanılan metin alanıdır. WordPress.org’da barındırılan eklentilerde genellikle eklentinin dizin kısa adıyla aynı olmalıdır.

Domain Path: Çeviri dosyaları eklenti içindeki languages klasöründe tutuluyorsa bu yolu belirtir.

“Requires at least” veya “Requires PHP” değerlerini gereksiz yere düşük göstermek daha fazla kullanıcıya ulaşmanızı sağlamaz. Eklenti eski sürümde çalışmıyorsa yanlış gereksinim bilgisi kullanıcıların sitesinde kritik hataya yol açabilir.

GPL UYUMLU LİSANS KULLANIN

WordPress.org dizinindeki eklentilerin GPL veya GPL ile uyumlu bir lisansla dağıtılması gerekir. Bu koşul yalnızca sizin yazdığınız PHP dosyalarını değil, paket içinde dağıttığınız JavaScript ve CSS kütüphanelerini, yazı tiplerini, görselleri ve diğer üçüncü taraf varlıkları da kapsar.

Eklentide dışarıdan alınan bir kütüphane kullanıyorsanız şu soruların yanıtı açık olmalıdır:

• Kütüphanenin lisansı GPL ile uyumlu mu?
• Kaynağı ve lisans bilgisi belgelenmiş mi?
• Küçültülmüş JavaScript veya CSS dosyasının okunabilir kaynak koduna erişilebiliyor mu?
• Dosyanın eklenti paketinde dağıtılmasına izin var mı?

Kaynağı veya lisansı belirsiz dosyaları pakete eklemek incelemeyi geciktirebilir. Lisans bilgisini ana eklenti dosyasında vereadme.txt içinde belirtmek; üçüncü taraf bileşenlerin kaynak ve lisanslarını ayrıca belgelemek gerekir.

WORDPRESS GÜVENLİK KURALLARINI UYGULAYIN

eklentilerin en sık onaylanmama nedenleri açıkça belirtilir: temizlenmemiş giriş verileri, güvenli biçimde kaçışlanmamış çıktılar, nonce olmadan işlenen form verileri ve eklenti yönergelerine aykırı kodlar. Bu nedenlegüvenlik kontrolü başvurudan hemen önce yapılan yüzeysel bir işlem değil, geliştirme sürecinin parçası olmalıdır.

Kullanıcı girdisini doğrulayın ve temizleyin

Form, URL, AJAX isteği, REST API veya dosya yükleme alanından gelen hiçbir veriye doğrudan güvenmeyin. Önce verinin mevcut olup olmadığını kontrol edin, gerekiyorsa wp_unslash() uygulayın ve veri türüne uygun bir WordPress temizleme fonksiyonu kullanın.

Örnek:

$product_name = '';

if ( isset( $_POST['product_name'] ) ) {
    $product_name = sanitize_text_field(
        wp_unslash( $_POST['product_name'] )
    );
}

Her veri için sanitize_text_field() kullanmak doğru değildir. E-posta adreslerinde sanitize_email(), dosya adlarında sanitize_file_name(), anahtarlarda sanitize_key(), çok satırlı metinlerde sanitize_textarea_field() gibi veriye uygun fonksiyonlar seçilmelidir. Sayısal değerlerde absint() veya uygun tür dönüşümü kullanılabilir.

Temizleme ile doğrulama aynı şey değildir. Örneğin sanitize_email() değeri temizler; is_email() ise değerin geçerli bir e-posta biçiminde olup olmadığını denetler. Eklentinin iş kuralı belirli seçeneklere izin veriyorsa gelen değer bir izin listesiyle de karşılaştırılmalıdır.

Çıktıyı kullanıldığı bağlama göre güvenli hâle getirin

Verinin kaydedilirken temizlenmiş olması, her yerde doğrudan ekrana yazılabileceği anlamına gelmez. WordPress güvenlik yaklaşımında çıktı mümkün olduğunca geç, gösterildiği noktada ve kullanıldığı bağlama uygun olarak kaçışlanır.

Örnekler:

echo esc_html( $product_name );

echo '<a href="' . esc_url( $product_url ) . '">Bağlantıyı aç</a>';

echo '<input value="' . esc_attr( $field_value ) . '">';

İzin verilen sınırlı HTML içeriği gösterilecekse wp_kses() veya wp_kses_post() kullanılabilir. HTML metni için esc_html(), bağlantı için esc_url(), HTML özelliği için esc_attr() kullanmak bağlama göre kaçışlamanın temel örnekleridir.

Nonce kullanın ancak nonce değerini yetki kontrolü sanmayın

Nonce, form ve URL isteklerini CSRF türü kötüye kullanımlara karşı korumaya yardımcı olur. Yönetim panelindeki bir formda wp_nonce_field() ile alan oluşturulabilir:

wp_nonce_field( 'ozdfm_save_settings', 'ozdfm_nonce' );

İşlem sırasında nonce kontrol edilmelidir:

if (
    ! isset( $_POST['ozdfm_nonce'] ) ||
    ! wp_verify_nonce(
        sanitize_text_field( wp_unslash( $_POST['ozdfm_nonce'] ) ),
        'ozdfm_save_settings'
    )
) {
    wp_die( esc_html__( 'Güvenlik doğrulaması başarısız oldu.', 'ornek-form-yoneticisi' ) );
}

AJAX isteklerinde check_ajax_referer(), yönetim ekranlarındaki işlemlerde check_admin_referer() kullanılabilir. Ancak nonce kimlik doğrulama veya yetkilendirme aracı değildir. Geçerli nonce değerine sahip bir kullanıcının ilgili işlemi yapmaya yetkili olup olmadığı ayrıca denetlenmelidir.

Kullanıcı yetkisini kontrol edin

Yönetim ayarını değiştiren, veri silen, dosya yükleyen veya özel bir işlemi çalıştıran fonksiyonlarda current_user_can() ile yetki kontrolü yapılmalıdır:

if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( esc_html__( 'Bu işlem için yetkiniz bulunmuyor.', 'ornek-form-yoneticisi' ) );
}

Kullanıcı rolünü doğrudan kontrol etmek yerine yapılacak işe uygun yeteneği, yani capability değerini kontrol etmek daha esnek ve WordPress yapısına daha uygundur.

Veritabanı sorgularını güvenli hazırlayın

WordPress API’sinin get_posts(), WP_Query, get_option() ve update_option() gibi hazır fonksiyonları kullanılabiliyorsa doğrudan SQL yazmak yerine bu fonksiyonları tercih edin. Özel SQL sorgusu gerekiyorsa değişken değerleri sorgu metnine doğrudan eklemeyin; $wpdb->prepare() kullanın.

Örnek:

$table_name = $wpdb->prefix . 'ozdfm_entries';
$entry_id   = absint( $entry_id );

$entry = $wpdb->get_row(
    $wpdb->prepare(
        "SELECT * FROM {$table_name} WHERE id = %d",
        $entry_id
    )
);

Tablo adı gibi doğrudan yerleştirilen değerlerin de eklenti tarafından güvenilir biçimde oluşturulduğundan emin olun. Kullanıcıdan alınan bir tablo veya sütun adını sorguya doğrudan eklemeyin.

PHP dosyalarına doğrudan erişimi engelleyin

Tek başına çalıştırılmaması gereken PHP dosyalarında WordPress’in yüklenip yüklenmediği kontrol edilebilir:

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

Bu kontrol tek başına bütün güvenlik sorunlarını çözmez. Yine de WordPress bağlamı dışında doğrudan çağrılmaması gereken dosyalar için temel bir korumadır.

BENZERSİZ ÖN EK VEYA NAMESPACE KULLANIN

WordPress sitesinde aynı anda çok sayıda eklenti ve tema çalışabilir. Genel isimli fonksiyonlar, sınıflar, sabitler ve seçenekler başka bir yazılımla çakışabilir. WordPress.org; fonksiyon, sınıf, namespace, sabit, global değişken ve option adlarının eklentiye özgü olmasını ister.

Yanlış örnekler:

function save_settings() {}
class Admin_Settings {}
update_option( 'settings', $settings );

Daha doğru örnekler:

function ozdfm_save_settings() {}
class OZDFM_Admin_Settings {}
update_option( 'ozdfm_settings', $settings );

İki veya üç harfli kısa ön ekler yeterince benzersiz kabul edilmez. WordPress.org’un ortak sorunlar belgesinde, çok sayıdaki eklenti nedeniyle daha uzun ve ayırt edici ön eklerin kullanılması önerilir. “wp_”, tek alt çizgi veya çift alt çizgi gibi WordPress tarafından ayrılmış ön ekler kendi fonksiyon ve sınıflarınız için kullanılmamalıdır.

Modern nesne yönelimli bir yapı kullanıyorsanız eklentiye özel namespace de çakışmaları önleyebilir. Namespace kullanmak; veritabanı seçenekleri, hook adları veya global sabitler gibi diğer adlandırmaları benzersiz yapma gereksinimini ortadan kaldırmaz.

ÇEVİRİYE HAZIR KOD YAZIN

WordPress.org’da yayımlanacak bir eklentinin kullanıcıya gösterilen metinleri çeviri fonksiyonlarından geçirilmelidir. Metinler PHP değişkenlerinden veya farklı parçaların kontrolsüz biçimde birleştirilmesinden oluşmamalıdır.

Örnekler:

__( 'Save settings', 'ornek-form-yoneticisi' );

esc_html_e( 'Settings saved.', 'ornek-form-yoneticisi' );

printf(
    /* translators: %s: Product name. */
    esc_html__( '%s has been updated.', 'ornek-form-yoneticisi' ),
    esc_html( $product_name )
);

Yer tutucu içeren metinlerde çevirmenin bağlamı anlayabilmesi için “translators” açıklaması eklenmelidir. Çeviri fonksiyonundaki text domain değeri ana eklenti dosyasındaki Text Domain ve WordPress.org kısa adıyla uyumlu olmalıdır.

Eklentinin ilk sürümünde yalnızca tek dil kullanılsa bile kodun çeviriye hazır hazırlanması daha sonra bütün metinleri yeniden düzenleme ihtiyacını azaltır.

HARİCİ SUNUCU BAĞLANTILARINI VE GİZLİLİĞİ AÇIKLAYIN

Eklenti bir API’ye, haricî servise veya uzaktaki sunucuya bağlanıyorsa bunun ne amaçla yapıldığı readme.txt içinde açıklanmalıdır. Kullanıcının açık izni olmadan kullanım verisi toplamak veya takip isteği göndermek WordPress.org kurallarına aykırıdır.

Haricî servis kullanılıyorsa şu bilgiler açıkça belirtilmelidir:

• Hangi servise bağlanıldığı
• Hangi verilerin gönderildiği
• Bağlantının neden gerekli olduğu
• Servisin kullanım şartları ve gizlilik politikası
• Kullanıcının hangi işlemle onay verdiği

Bir hizmetin parçası olmayan JavaScript ve CSS dosyalarını yalnızca kolaylık amacıyla üçüncü taraf CDN üzerinden yüklemek de sorun oluşturabilir. Dağıtılması gereken varlıkların uygun lisansla eklenti paketinde yerel olarak bulunması beklenir.

ETKİNLEŞTİRME, DEVRE DIŞI BIRAKMA VE KALDIRMA İŞLEMLERİNİ AYIRIN

Eklenti devre dışı bırakıldığında geçici görevler veya zamanlanmış olaylar durdurulabilir; fakat kullanıcı verileri otomatik olarak silinmemelidir. Devre dışı bırakma geçici bir işlemdir. Kullanıcı eklentiyi yeniden etkinleştirdiğinde ayarlarına ve verilerine ulaşmayı bekleyebilir.

Kalıcı veri temizliği gerekiyorsa uninstall.php dosyası veya register_uninstall_hook() kullanılabilir. Silme işlemi yalnızca gerçekten eklentiye ait verileri hedeflemeli ve başka eklentilerin ya da WordPress çekirdeğinin kayıtlarına dokunmamalıdır.

Kullanıcıya “eklenti kaldırılırken verileri sil” seçeneği sunmak çoğu proje için güvenli bir yaklaşımdır. Bu seçenek kullanılacaksa varsayılan davranış ve silinecek veriler açıkça belgelenmelidir.

READMe.TXT DOSYASINI HAZIRLAYIN

Ana PHP dosyasındaki başlık WordPress yönetim paneline bilgi verir. readme.txt ise WordPress.org’daki eklenti sayfasının büyük bölümünü oluşturur. Açıklama, kurulum, sık sorulan sorular, ekran görüntüleri ve değişiklik kaydı bu dosyadan okunur.

Dosyanızı hazırladıktan sonra WordPress.org’un Readme Validator aracıyla biçim ve alan kontrollerini çalıştırabilirsiniz.

Temel bir readme.txt örneği:

=== Örnek Form Yöneticisi ===
Contributors: wordpress_kullanici_adi
Tags: form, contact form, form manager
Requires at least: 6.5
Tested up to: 7.0
Stable tag: 1.0.0
Requires PHP: 8.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

WordPress için sade ve güvenli form yönetimi sağlar.

== Description ==

Eklentinin ne yaptığını, kimler için uygun olduğunu ve temel kullanım biçimini açıklayın.

== Installation ==

1. Eklenti dosyalarını yükleyin.
2. WordPress yönetim panelinden eklentiyi etkinleştirin.
3. Ayarlar ekranından gerekli yapılandırmayı tamamlayın.

== Frequently Asked Questions ==

= Eklenti nasıl yapılandırılır? =

Eklentiyi etkinleştirdikten sonra ilgili ayarlar sayfasını açın.

== Screenshots ==

1. Eklentinin ayarlar ekranı.
2. Örnek ön yüz görünümü.

== Changelog ==

= 1.0.0 =
* İlk kararlı sürüm yayımlandı.

readme.txt hazırlanırken şu ayrımlar önemlidir:

Contributors: Görünen adlar değil, büyük-küçük harf duyarlı WordPress.org kullanıcı adları yazılır.

Tags: Eklentiyi gerçekten tanımlayan etiketler kullanılmalıdır. Rakip eklentilerin adlarını etiket olarak kullanmak veya anahtar kelime doldurmak yasaktır. WordPress.org en fazla 12 etiketi arama amacıyla dikkate alır; eklenti sayfasında ise yalnızca ilk beş etiket gösterilir. On ikinci etiketten sonraki değerler yok sayılır. Yalnızca sizin eklentinizde kullanılan aşırı özel etiketler de kullanıcıların benzer eklentileri bulmasına yardımcı olmayacağı için görünmeyebilir.

Requires at least: Desteklenen en düşük WordPress sürümüdür.

Tested up to: Eklentinin gerçekten test edildiği en yüksek WordPress ana sürümüdür. “WP 7.0” yerine yalnızca “7.0” biçiminde yazılır.

Stable tag: WordPress sürümü değil, yayımlanan eklenti sürümüdür. Örneğin 1.0.0 yazılmışsa SVN deposunda tags/1.0.0 klasörü bulunmalıdır.

Requires PHP: Gerekli en düşük PHP sürümüdür ve yalnızca sayı biçiminde belirtilir.

Kısa açıklama: İşaretleme içermemeli ve 150 karakteri aşmamalıdır.

readme.txt dosyasını gereksiz ölçüde büyütmeyin. WordPress.org belgesine göre 10 KB’tan büyük readme dosyaları sorun çıkarabilir. Uzun sürüm geçmişi ayrı bir changelog.txt dosyasında, kapsamlı belgeler ise eklentinin kendi dokümantasyon sayfasında tutulabilir.

SÜRÜM BİLGİLERİNİN BİRBİRİYLE UYUMLU OLMASINI SAĞLAYIN

WordPress.org’da sürüm bilgisi üç ayrı yerde karşınıza çıkar:

1. Ana eklenti PHP dosyasındaki Version değeri
2. trunk/readme.txt içindeki Stable tag değeri
3. SVN deposundaki tags/sürüm-numarası klasörü

1.0.0 sürümü yayımlanacaksa üçü de aynı sürümü göstermelidir:

Version: 1.0.0
Stable tag: 1.0.0
tags/1.0.0/

WordPress.org, indirilecek eklenti sürümünün numarasını ana PHP dosyasındaki Version alanından okur. trunk/readme.txt içindeki Stable tag ise dizine hangi tags klasörünün kararlı sürüm olarak kullanılacağını söyler. Stable tag 1.0.0 ise WordPress.org eklenti sayfasındaki açıklamaları tags/1.0.0/readme.txt dosyasından okur.

Bu nedenle yalnızca trunk/readme.txt dosyasını güncellemek, kararlı etiket başka bir klasörü gösteriyorsa eklenti sayfasını değiştirmeyebilir. “Stable tag: trunk” kullanımı yeni eklentiler için önerilmez ve WordPress.org tarafından engellenmektedir. Her kararlı sürüm için numaralı tag oluşturun.

EKLENTİYİ FARKLI ORTAMLARDA TEST EDİN

Eklentiyi göndermeden önce yalnızca geliştirildiği sitede test etmek yeterli değildir. Mümkün olduğunca temiz bir WordPress kurulumunda aşağıdaki durumları kontrol edin:

• Eklenti sorunsuz kuruluyor ve etkinleşiyor mu?
• Etkinleştirme sırasında PHP uyarısı veya kritik hata oluşuyor mu?
• Yönetim ekranları farklı kullanıcı rollerinde doğru yetkilendiriliyor mu?
• Form ve AJAX işlemlerinde nonce ve yetki kontrolü çalışıyor mu?
• Eklenti devre dışı bırakılıp yeniden etkinleştirildiğinde veri kaybı oluşuyor mu?
• Kaldırma davranışı belgelendiği gibi çalışıyor mu?
• WordPress debug modu açıkken uyarı, notice veya deprecated mesajı oluşuyor mu?
• Desteklendiği belirtilen en düşük PHP ve WordPress sürümlerinde çalışıyor mu?
• Güncel WordPress sürümünde test edildi mi?
• Başka tema veya eklentilerle ad çakışması oluşuyor mu?
• Kullanıcıdan gelen veriler güvenli işleniyor ve çıktılar doğru kaçışlanıyor mu?

wp-config.php içinde geliştirme ortamında WP_DEBUG etkinleştirilerek PHP uyarıları izlenebilir. Hata ayrıntıları üretim sitesinde ziyaretçilere gösterilmemeli; test işlemleri yerel veya uygun bir hazırlık ortamında yapılmalıdır.

PLUGIN CHECK İLE RESMÎ KONTROLLERİ ÇALIŞTIRIN

Plugin Check , WordPress.org tarafından geliştirilen ve bir eklentinin dizin gereksinimleriyle geliştirme iyi uygulamalarına uygunluğunu denetleyen resmî eklentidir. WordPress.org’a gönderilen yeni eklentilerde kullanılan kontrollerin önemli bir bölümünü başvurudan önce çalıştırmanızı sağlar.

Plugin Check kullanımı:

1. Test sitenizde “Eklentiler > Yeni Eklenti Ekle” bölümünü açın.
2. “Plugin Check” eklentisini arayın.
3. Eklentiyi kurup etkinleştirin.
4. “Araçlar > Plugin Check” ekranına girin.
5. Kontrol edilecek eklentiyi seçin.
6. Özellikle “Plugin repo” kategorisindeki kontrolleri çalıştırın.
7. Bildirilen hata ve uyarıları tek tek inceleyin.

WP-CLI kullanılıyorsa temel kontrol şu komutla çalıştırılabilir:

wp plugin check ornek-form-yoneticisi

Yerel dosya yolu veya ZIP paketi de kontrol edilebilir:

wp plugin check /dosya/yolu/ornek-form-yoneticisi.zip

Plugin Check çıktısındaki her uyarıyı anlamadan bastırmak doğru değildir. Önce uyarının hangi koddan ve hangi WordPress.org kuralından kaynaklandığını belirleyin. Araç zaman zaman yanlış pozitif sonuç üretebilir; ancak “araç yanılıyor” sonucuna varmadan önce kodun gerçekten güvenli ve yönergelere uygun olduğunu kanıtlayabilmelisiniz.

WordPress.org’a kabul edilmek için genel olarak “Plugin repo” kategorisindeki kontrollerin geçilmesi beklenir. Diğer performans, erişilebilirlik ve iyi uygulama kontrolleri her durumda zorunlu olmayabilir; buna rağmen kaliteli ve sürdürülebilir bir eklenti için dikkate alınmalıdır. Plugin Check’in temiz sonuç vermesi manuel incelemenin yerini tutmaz ve eklentinin kesin onaylanacağı anlamına gelmez.

WORDPRESS.ORG MCP SUNUCUSU İSTEĞE BAĞLI OLARAK KULLANILABİLİR

WordPress.org, 2026 yılında eklenti geliştiricileri için bir MCP sunucusu kullanıma sundu. Uyumlu bir yapay zekâ istemcisine bağlanabilen bu sunucu; readme.txt doğrulama, gönderilmiş bir eklentinin inceleme durumunu öğrenme ve inceleme devam ederken güncellenmiş paketi gönderme gibi işlemler için resmî araçlar sağlar.

MCP kullanımı zorunlu değildir. Eklenti, klasik WordPress.org başvuru ekranından da gönderilebilir. Bu araç geliştirme sorumluluğunu, güvenlik incelemesini veya Plugin Check denetimini ortadan kaldırmaz. Yapay zekâ tarafından önerilen değişikliklerin geliştirici tarafından anlaşılması, kodun test edilmesi ve bütün WordPress.org yönergelerine uyulması gerekir.

MCP sunucusundaki eklenti gönderme aracı yalnızca yeni başvurular ve henüz inceleme altında bulunan eklentilerin güncellenmiş paketleri için kullanılabilir. Eklenti onaylandıktan sonraki normal sürümler yine SVN deposu ve WordPress.org sürüm yönetimi üzerinden yayımlanır. Bu özelliği kullanmak isteyen geliştiriciler WordPress.org MCP Sunucusunu Kullanma belgesindeki güncel kurulum ve yetkilendirme adımlarını izlemelidir.

PHPCS İLE WORDPRESS KODLAMA STANDARTLARINI DENETLEYİN

PHP_CodeSniffer ve WordPress PHP kodlama standartları, kod biçimiyle birlikte güvenlik, çeviri ve WordPress uyumluluğuna ilişkin çok sayıda kuralın denetlenmesine yardımcı olur. WordPress.org başvuru formunda PHPCS çalıştırmak ayrı bir zorunlu adım olarak belirtilmez; ancak gönderimden önce hataları yakalamak için güçlü bir kalite kontrol yöntemidir.

Composer bulunan bir geliştirme ortamında paketler proje gereksinimine göre kurulabilir:

composer require --dev squizlabs/php_codesniffer wp-coding-standards/wpcs phpcompatibility/php-compatibility

Kurulum yapınıza bağlı olarak PHPCS’ye standart yolunu tanıtmanız gerekebilir. Ardından eklenti klasöründe kontrol çalıştırılabilir:

vendor/bin/phpcs --standard=WordPress ornek-form-yoneticisi

Yalnızca otomatik düzeltilebilen biçim sorunlarının bir bölümü PHPCBF ile düzeltilebilir:

vendor/bin/phpcbf --standard=WordPress ornek-form-yoneticisi

PHPCBF komutunu çalıştırdıktan sonra değişiklikleri mutlaka inceleyin ve eklentiyi yeniden test edin. Otomatik düzenleme, uygulamanın doğru çalıştığını garanti etmez. Kod standardı uyarılarını topluca yok saymak yerine, gerekli ve gerekçeli durumlarda en dar kapsamlı istisnayı kullanın.

GÖNDERİLECEK ZIP PAKETİNİ HAZIRLAYIN

İncelemeye göndereceğiniz ZIP dosyası, WordPress yönetim panelinden kurulabilecek eksiksiz eklenti paketi olmalıdır. İnceleme için boş bir taslak, yalnızca ana PHP dosyası veya daha sonra tamamlanacak bir demo göndermeyin.

Doğru paket yapısı:

ornek-form-yoneticisi.zip
└── ornek-form-yoneticisi/
    ├── ornek-form-yoneticisi.php
    ├── readme.txt
    └── diğer gerekli dosyalar

ZIP paketini göndermeden önce yeni bir WordPress kurulumunda şu yöntemle test edin:

1. “Eklentiler > Yeni Eklenti Ekle” ekranını açın.
2. “Eklenti Yükle” düğmesini kullanın.
3. Hazırladığınız ZIP dosyasını seçin.
4. Eklentiyi kurun ve etkinleştirin.
5. Yönetim ve ön yüz işlevlerini yeniden kontrol edin.

Bu test, yanlış klasör yapısı, eksik dosya, büyük-küçük harf uyuşmazlığı veya yalnızca geliştirme bilgisayarınızda bulunan bir bağımlılık gibi paketleme hatalarını ortaya çıkarabilir.

WORDPRESS.ORG’A YENİ EKLENTİ GÖNDERİN

WordPress.org hesabınızla giriş yaptıktan sonra WordPress.org eklenti gönderim ekranını açın. Güncel eklenti yönergelerini ve geliştirici sık sorulan sorularını okuyun. Hazırladığınız ZIP dosyasını seçin, istenen kısa bilgileri doldurun ve başvuruyu gönderin.

Gönderimden sonra eklenti manuel olarak incelenir. WordPress.org başvuru sayfası, incelemenin genellikle 1 ile 10 gün arasında sürebildiğini ve başvuruların yaklaşık beş iş günü içinde ele alınmaya çalışıldığını belirtir. Eklentinin karmaşıklığına ve inceleme yoğunluğuna göre süre değişebilir; incelemeyi öne alma seçeneği bulunmaz.

İnceleme devam ederken şunlara dikkat edin:

• WordPress.org hesabınıza bağlı e-postayı kontrol edin.
• plugins@wordpress.org adresinden gelen iletilerin spam klasörüne düşmediğinden emin olun.
• Düzeltme istendiğinde yalnızca belirtilen satırı değil, aynı sorunun eklentinin diğer dosyalarında bulunup bulunmadığını da kontrol edin.
• Düzeltilmiş eksiksiz ZIP paketini başvurunun yönetim alanından gönderin ve inceleme e-postasını yanıtlayın.
• Aynı eklenti için yeni bir başvuru açmayın.
• İnceleme ekibi onay vermeden eklentinin yayımlandığını varsaymayın.

İnceleme mesajındaki her maddeyi ayrı ayrı ele alın. Yapılan değişiklikleri kısa ve teknik bir yanıtla açıklayın. Anlaşılmayan bir nokta varsa tahmin ederek değişiklik yapmak yerine, aynı e-posta zincirinde açıklama isteyin.

EKLENTİ ONAYLANDIKTAN SONRA NE OLUR?

Onay e-postası geldiğinde eklenti henüz otomatik olarak kullanıcılara sunulmuş olmayabilir. WordPress.org eklentiniz için aşağıdaki yapıya benzeyen bir SVN deposu oluşturur:

https://plugins.svn.wordpress.org/eklenti-kisa-adi/

Bu depoya eklenti dosyalarını ve readme.txt dosyasını göndermeniz gerekir. İlk kararlı sürüm SVN’e işlendiğinde WordPress.org gerekli ZIP paketlerini oluşturur ve eklenti dizinindeki sayfayı yayımlar.

Yeni gönderim ekranı yalnızca ilk başvuru ve inceleme sürecindeki paketler içindir. Onaylanmış eklentinin normal güncellemeleri SVN üzerinden yayımlanır.

SVN DEPOSUNDAKİ KLASÖRLER NE İŞE YARAR?

WordPress.org eklenti SVN deposunda temel olarak üç klasör bulunur:

trunk/
tags/
assets/

trunk: Eklentinin güncel geliştirme veya bir sonraki yayıma hazır kodlarını içerir. Ana eklenti dosyası trunk altında doğrudan bulunmalıdır. “trunk/eklenti-adi/eklenti.php” biçiminde fazladan ana klasör oluşturmak indirme paketini bozabilir.

tags: Yayımlanan kararlı sürümlerin numaralı kopyalarını içerir. Örneğin 1.0.0 sürümü tags/1.0.0 klasöründe bulunur.

assets: WordPress.org eklenti sayfasında kullanılan simge, kapak ve ekran görüntülerini içerir. Bu klasördeki dosyalar kullanıcının indirdiği eklenti paketine eklenmez. Böylece tanıtım görselleri eklenti ZIP dosyasını gereksiz yere büyütmez.

WordPress.org SVN deposu bir geliştirme deposu değil, yayımlama deposudur. Her küçük değişikliği buraya göndermek yerine geliştirmeyi Git gibi ayrı bir sistemde sürdürebilir, testleri tamamlanmış yayıma hazır sürümleri SVN’e aktarabilirsiniz. SVN’e yapılan her işlem WordPress.org tarafında paketlerin yeniden oluşturulmasını tetikleyebilir.

İLK SÜRÜMÜ SVN İLE YAYIMLAYIN

Bilgisayarınızda Subversion istemcisinin kurulu olması gerekir. Windows’ta komut satırı SVN istemcisi veya TortoiseSVN gibi bir grafik arayüz kullanılabilir. WordPress.org’un Subversion kullanım belgesi depo yapısını ve temel yayımlama işlemlerini açıklar. Aşağıdaki örnekler komut satırı içindir.

Önce WordPress.org tarafından açılan depoyu bilgisayarınıza çekin:

svn checkout https://plugins.svn.wordpress.org/eklenti-kisa-adi/ eklenti-kisa-adi-svn

Kısa biçimi de kullanılabilir:

svn co https://plugins.svn.wordpress.org/eklenti-kisa-adi/ eklenti-kisa-adi-svn

Oluşan klasöre girin:

cd eklenti-kisa-adi-svn

Eklentinin çalışması için gerekli dosyaları trunk klasörüne kopyalayın. ZIP dosyasının kendisini SVN’e yüklemeyin. Eklentinin içindeki dosyalar doğrudan trunk altında bulunmalıdır:

trunk/eklenti-kisa-adi.php
trunk/readme.txt
trunk/includes/
trunk/languages/

Yeni dosyaları SVN takibine ekleyin:

svn add trunk/*

Gereksiz bir dosya eklendi mi, doğru dosyalar takip ediliyor mu kontrol edin:

svn status

Değişiklikleri göndermeden önce farkları inceleyin:

svn diff

İlk trunk sürümünü açıklayıcı bir mesajla gönderin:

svn commit -m "Add version 1.0.0"

Kısa biçimi:

svn ci -m "Add version 1.0.0"

Kimlik doğrulama gerekirse WordPress.org kullanıcı adınızı ve SVN parolanızı kullanın. Kullanıcı adının büyük-küçük harf biçimi hesapta göründüğü şekliyle aynı olmalıdır.

Kararlı sürüm etiketini normal dosya kopyalama komutuyla değil, SVN kopyalama komutuyla trunk üzerinden oluşturun:

svn copy trunk tags/1.0.0

Ardından etiketi depoya gönderin:

svn commit -m "Tag version 1.0.0"

İsterseniz trunk dosyalarını ekleme ve tag oluşturma işlemlerini aynı çalışma kopyasında hazırlayıp tek açıklayıcı commit ile de gönderebilirsiniz. Önemli olan, tag’in test edilmiş trunk içeriğinden oluşturulması ve sürüm değerlerinin birbiriyle eşleşmesidir.

Sürümü WordPress.org üzerinden onaylayın

Yeni sürüm etiketi SVN deposuna gönderildiğinde WordPress.org eklenti yetkililerine bir sürüm onay e-postası gönderir. Aynı işlem, eklentinin WordPress.org yönetim alanındaki Release Management ekranından da tamamlanabilir. Sürüm, yetkili geliştirici tarafından onaylandıktan sonra paket oluşturma ve kullanıcılara dağıtma süreci başlar.

SVN commit işleminin başarılı olması, sürümün otomatik olarak yayımlandığı anlamına gelmez. Commit sonrasında e-postayı ve Release Management ekranını kontrol edin. Onay bağlantısı gelmediyse WordPress.org hesabına bağlı e-posta adresinin ve spam klasörünün kontrol edilmesi gerekir.

Yayımlanmış bir sürüm etiketinin içeriği daha sonra değiştirilmemelidir. Örneğin tags/1.0.0 kullanıcılara sunulduktan sonra bu klasördeki kodu düzeltmek yerine 1.0.1 gibi yeni bir sürüm hazırlanmalı, yeni tag oluşturulmalı ve yeni sürüm ayrıca onaylanmalıdır. Bu yaklaşım yayımlanmış paketlerin değişmezliğini ve sürüm geçmişinin güvenilirliğini korur.

SVN deposuna hiçbir zaman eklenti ZIP dosyasını yüklemeyin. WordPress.org ZIP paketini trunk ve tags içeriğinden kendisi oluşturur.

WORDPRESS.ORG EKLENTİ SAYFASI İÇİN GÖRSELLERİ EKLEYİN

Eklenti simgesi, kapak görselleri ve readme.txt içinde açıklanan ekran görüntüleri assets klasörüne eklenir. WordPress.org’un eklenti görselleri belgesinde dosya adları, ölçüler ve konumlandırma ayrıntıları açıklanır. Genel dosya adları şöyledir:

assets/icon-128x128.png
assets/icon-256x256.png
assets/banner-772x250.png
assets/banner-1544x500.png
assets/screenshot-1.png
assets/screenshot-2.png

Yüksek çözünürlüklü simge ve kapak dosyaları uygun adlandırmayla eklenirse WordPress.org farklı ekran yoğunluklarında doğru görseli kullanabilir. Ekran görüntülerinin sıra numarası, readme.txt dosyasındaki Screenshots bölümünün sırasıyla eşleşmelidir.

Yeni görselleri ekledikten sonra:

svn add assets/*
svn status
svn commit -m "Add plugin directory assets"

Görseller eklenti kodunun parçası olmadığı için trunk klasörüne konulmamalıdır. Eklentinin çalışması için gerçekten gerekli olan arayüz görselleri ise eklenti paketinde uygun bir klasörde tutulabilir; assets klasörü yalnızca WordPress.org listeleme sayfasına ait tanıtım varlıkları içindir.

YENİ BİR EKLENTİ SÜRÜMÜ NASIL YAYIMLANIR?

Eklenti onaylandıktan sonra normal güncellemeler için yeniden ZIP başvurusu yapılmaz. Yeni sürümü kendi geliştirme ortamınızda tamamlar, test eder ve SVN deposuna gönderirsiniz.

Örneğin 1.1.0 sürümü yayımlanacaksa şu sıra izlenebilir:

1. Ana PHP dosyasındaki Version değerini 1.1.0 yapın.
2. readme.txt içindeki Stable tag değerini 1.1.0 yapın.
3. Tested up to ve Requires PHP gibi alanları yalnızca gerçek durum değiştiyse güncelleyin.
4. Changelog bölümüne 1.1.0 değişikliklerini ekleyin.
5. Eklentiyi güncel ve desteklenen en düşük ortamlarda test edin.
6. Plugin Check ve kullandığınız diğer kod kontrollerini yeniden çalıştırın.
7. SVN çalışma kopyasını svn update ile güncelleyin.
8. Yeni dosyaları trunk klasörüne aktarın.
9. svn status ve svn diff ile değişiklikleri inceleyin.
10. Yeni veya silinen dosyaları SVN’e doğru biçimde bildirin.
11. trunk üzerinden tags/1.1.0 etiketini oluşturun.
12. Açıklayıcı commit mesajıyla değişiklikleri gönderin.
13. WordPress.org sürüm onay e-postasını veya Release Management ekranını açın.
14. Yeni sürümü onaylayın ve dizindeki güncellemeyi kontrol edin.

Örnek komutlar:

cd eklenti-kisa-adi-svn
svn update
svn status
svn diff
svn add trunk/yeni-dosya.php
svn delete trunk/kaldirilan-dosya.php
svn copy trunk tags/1.1.0
svn commit -m "Release version 1.1.0"

Commit tamamlandıktan sonra WordPress.org tarafından gönderilen sürüm onay bağlantısını kullanın. Sürüm onaylanmadan yalnızca SVN’de tag oluşturulmuş olur; yeni paket kullanıcı güncellemelerine açılmaz.

Dosyayı işletim sisteminden silmek yerine svn delete kullanmak, silme işleminin SVN tarafından takip edilmesini sağlar. Yeni dosyalarda svn add kullanılmazsa dosya yerel klasörde bulunsa bile WordPress.org deposuna gönderilmez.

Sürüm gönderildikten sonra WordPress.org’un paketleri ve eklenti sayfasını yenilemesi zaman alabilir. Aynı dosyaları peş peşe yeniden commit etmek yerine önce SVN deposundaki sürümü, Stable tag değerini ve WordPress.org sayfasını kontrol edin.

SVN KULLANIRKEN SIK YAPILAN HATALAR

ZIP dosyasını SVN’e yüklemek: SVN’e ZIP değil, eklentinin dosya ve klasörleri gönderilir.

Ana eklenti klasörünü trunk içine tekrar koymak: “trunk/eklenti-adi/eklenti.php” yapısı yerine ana dosya “trunk/eklenti.php” biçiminde olmalıdır.

Tag oluşturmamak: Stable tag sürüm numarasını gösterdiği hâlde karşılık gelen tags klasörü yoksa WordPress.org doğru sürümü sunamaz.

Sürüm numaralarını eşleştirmemek: Ana PHP dosyası, Stable tag ve tags klasörü aynı kararlı sürümü göstermelidir.

Yeni dosyaya svn add uygulamamak: Dosya bilgisayarda bulunur fakat commit sırasında sunucuya gönderilmez.

Silinen dosyayı SVN’e bildirmemek: Yerel klasörden silmek tek başına merkezi depodaki dosyayı kaldırmayabilir. svn delete kullanılmalıdır.

Güncelleme öncesinde svn update çalıştırmamak: Merkezi depodaki daha yeni değişikliklerle çakışma yaşanabilir.

Her küçük geliştirmeyi SVN’e göndermek: WordPress.org SVN’i geliştirme deposu değil, yayımlama deposudur. Yalnızca dağıtıma hazır değişiklikler gönderilmelidir.

Belirsiz commit mesajları kullanmak: “Update” yerine “Release version 1.1.0” veya yapılan düzeltmeyi açıklayan bir mesaj kullanılmalıdır.

WORDPRESS.ORG İNCELEMESİNDE SIK KARŞILAŞILAN SORUNLAR

Başvurudan önce aşağıdaki sorunların bulunmadığından emin olun:

• Kullanıcı girdisinin doğrudan kaydedilmesi
• Değişkenlerin kaçışlama yapılmadan HTML çıktısına yazılması
• Nonce bulunmayan form, AJAX veya yönetim işlemleri
• Nonce kontrol edilip kullanıcı yetkisinin kontrol edilmemesi
• Çok kısa veya genel fonksiyon, sınıf ve option adları
• wp_ gibi WordPress’e ayrılmış ön eklerin kullanılması
• Hazırlanmamış özel SQL sorguları
• Kullanıcı izni olmadan haricî sunucuya veri gönderilmesi
• Haricî hizmetlerin readme.txt içinde açıklanmaması
• Lisansı belirsiz JavaScript, CSS, görsel veya yazı tipi dosyaları
• Okunabilir kaynak kodu bulunmayan derlenmiş ya da küçültülmüş dosyalar
• Eklentinin çalışması için gerekli olmayan uzak JavaScript ve CSS dosyalarının CDN’den çağrılması
• Yönetim panelinde kapatılamayan veya ilgisiz reklam ve bildirimler
• Rakip eklenti adlarıyla anahtar kelime doldurma
• Eklenti devre dışı bırakılırken kullanıcı verilerinin izinsiz silinmesi
• Eksik veya yanlış readme.txt alanları
• Ana PHP sürümü ile Stable tag değerinin uyuşmaması
• ZIP paketinin WordPress yönetim panelinden kurulamaması

Bu maddeler yalnızca incelemeden geçmek için değil, eklentinin farklı sitelerde güvenli ve kararlı çalışması için önemlidir.

GÖNDERİM ÖNCESİ SON KONTROL LİSTESİ

Eklentiyi WordPress.org’a göndermeden önce aşağıdaki listeyi baştan sona kontrol edebilirsiniz:

• Eklenti adı ve olası WordPress.org kısa adı kontrol edildi.
• Eklenti başka bir markayı veya projeyi yanıltıcı biçimde kullanmıyor.
• Ana eklenti dosyasındaki başlık bilgileri eksiksiz.
• Version, Requires at least ve Requires PHP değerleri gerçek testlerle uyumlu.
• GPL uyumlu lisans belirtildi.
• Üçüncü taraf dosyaların kaynak ve lisans bilgileri belgelendi.
• Fonksiyon, sınıf, sabit, namespace ve option adları benzersiz.
• Kullanıcı girdileri doğrulanıyor ve uygun fonksiyonlarla temizleniyor.
• Bütün çıktılar kullanıldıkları bağlama göre kaçışlanıyor.
• Form, AJAX ve yönetim işlemlerinde nonce kontrolü bulunuyor.
• Hassas işlemlerde current_user_can() ile yetki denetleniyor.
• Özel SQL sorguları güvenli hazırlanıyor.
• Kullanıcıya gösterilen metinler çeviriye hazır.
• Haricî servisler ve veri kullanımı readme.txt içinde açıklanıyor.
• Etkinleştirme, devre dışı bırakma ve kaldırma davranışları test edildi.
• readme.txt alanları ve bölümleri tamamlandı.
• Stable tag ile ana PHP dosyasındaki Version değeri eşleşiyor.
• Eklenti temiz WordPress kurulumunda test edildi.
• WP_DEBUG açıkken uyarılar kontrol edildi.
• Plugin Check’in “Plugin repo” sonuçları incelendi.
• PHPCS veya kullanılan diğer kod kalite kontrolleri çalıştırıldı.
• Gönderilecek ZIP dosyası yönetim panelinden kurulup test edildi.
• ZIP içinde yalnızca dağıtım için gereken dosyalar bulunuyor.
• WordPress.org hesabına bağlı e-posta adresine erişilebiliyor.
• Yeni sürüm için numaralı SVN etiketi oluşturuldu.
• WordPress.org sürüm onayı tamamlandı ve yayımlanan paket kontrol edildi.

SONUÇ

WordPress.org’a eklenti göndermek yalnızca bir ZIP dosyasını yüklemekten ibaret değildir. Başarılı bir gönderim; doğru dosya yapısı, güvenli veri işleme, benzersiz adlandırma, GPL uyumlu lisans, çeviriye hazır metinler, eksiksiz readme.txt ve farklı ortamlarda yapılan testlerin birlikte tamamlanmasını gerektirir.

Plugin Check ve PHPCS gibi araçlar gönderim öncesinde birçok sorunu yakalayabilir. Yine de otomatik kontroller, geliştiricinin güvenlik değerlendirmesinin ve WordPress.org Eklenti Ekibinin manuel incelemesinin yerine geçmez. Araçların bildirdiği sonuçları anlamak, aynı sorunları bütün eklenti genelinde aramak ve kodun neden güvenli olduğunu açıklayabilmek gerekir.

Eklenti onaylandıktan sonra süreç SVN ile devam eder. trunk güncel kodu, tags yayımlanmış sürümleri, assets ise WordPress.org sayfasına ait görselleri barındırır. Ana PHP dosyasındaki sürüm, readme.txt içindeki Stable tag ve tags klasörünün aynı sürümü göstermesi güncellemelerin doğru yayımlanması açısından kritik öneme sahiptir. Yeni tag SVN’e gönderildikten sonra WordPress.org sürüm onayının tamamlanması ve yayımlanmış etiketin sonradan değiştirilmemesi de güncel yayın sürecinin önemli parçalarıdır.

OZD Katalog Eklentisi ile OZD ImageFileX Eklentisi’nin WordPress.org’a gönderilmesi, inceleme geri bildirimlerinin uygulanması ve ilk kararlı sürümlerinin SVN üzerinden yayımlanması sırasında bu hazırlık adımları kullanıldı. Farklı amaçlara sahip iki eklentide de edinilen en önemli sonuç şudur: Eklentiyi incelemeye göndermeden önce güvenlik, dosya yapısı, readme, lisans ve sürümleme kontrollerini ne kadar dikkatli tamamlarsanız inceleme ve yayımlama sürecini o kadar sağlıklı yönetirsiniz.