Bu Sayfaya Erişim İzniniz Yok Hatası: Yönetici Yetkisini Geri Alma

Kullanıcı adınızı ve şifrenizi yazdınız, giriş başarılı oldu, /wp-admin açıldı. Ama ekranda tanıdık panel yok: sol menüde yalnızca "Kontrol Paneli" ve "Profil" duruyor, belki bir de "Yazılar". Eklentiler, Görünüm, Ayarlar, Kullanıcılar — hepsi kayıp. Adres çubuğuna elle /wp-admin/plugins.php yazdığınızda ise WordPress net bir cevap veriyor: "Bu sayfaya erişim izniniz yok." İngilizce kurulumlarda aynı satır Sorry, you are not allowed to access this page şeklinde çıkar ve sunucu HTTP 403 döner.

Bu tablo, "panele giremiyorum" senaryosuyla karıştırılmaya çok müsaittir ama teknik olarak tam tersidir. Kimlik doğrulaması başarılı olmuştur; WordPress sizin kim olduğunuzu biliyor, oturumunuz açık, çerezleriniz yerinde. Başarısız olan şey yetkilendirmedir: WordPress sizi tanıyor ama "bu kullanıcı yönetici mi?" sorusuna hayır cevabını veriyor. Şifre sıfırlamak, çerez temizlemek, tarayıcı değiştirmek bu durumda hiçbir şeyi değiştirmez — çünkü hiçbiri rol kaydına dokunmaz. Gerçekten giriş ekranını geçemiyorsanız bu yazı sizin için değil; doğru adres WordPress yönetici paneline giremiyorum yazısıdır.

Aşağıda önce bir dakikada sorunu daraltan ayırıcı teşhis var, sonra dört gerçek kök neden: taşıma sonrası tablo öneki uyuşmazlığı (vakaların büyük çoğunluğu ve en çok zaman kaybettireni), rol düzenleyici eklentisinin administrator rolünden yetenek silmesi, user_roles seçeneğinin bozulması ve çok siteli kurulumda süper yönetici olmama. Her çözümü hem phpMyAdmin hem WP-CLI hem de panele hiç giremediğiniz senaryo için geçici mu-plugin yöntemiyle veriyorum.

Yetki Hatasını Giriş Hatasından Ayıran Üç Belirti#

Yanlış tanı bu arızada en pahalı hatadır: insanlar saatlerce şifre sıfırlamayla uğraşır. Aşağıdaki üç soruya vereceğiniz cevap sorunu bir dakikada doğru rafa koyar.

1. Profil sayfanız açılıyor mu? /wp-admin/profile.php adresini deneyin. Açılıyorsa oturumunuz sağlamdır — WordPress sizi giriş yapmış bir kullanıcı olarak görüyor, sadece yönetici yetenekleriniz yok. Bu sayfa da 403 veriyorsa kullanıcı kaydınızın kendisi bozulmuş olabilir.

2. Yönetici çubuğunda adınız görünüyor mu? Sitenin ön yüzüne gidin. Üstteki siyah çubukta "Merhaba, [adınız]" yazıyorsa kimlik doğrulama tamamdır. Hiç çubuk yoksa sorun oturumda olabilir ve bu farklı bir arızadır.

3. Menüde ne kaldı? Kalan menü öğeleri, hangi rolde sıkışıp kaldığınızı doğrudan söyler.

Bu tabloda "hiç rol yok" satırı özellikle önemlidir. WordPress, rol kaydı okunamayan bir kullanıcıyı hata vererek reddetmez; sessizce yeteneksiz kabul eder. Ekranda gördüğünüz şey bir çökme değil, kasıtlı bir reddediştir — ve tam da bu yüzden debug.log dosyasında hiçbir iz bırakmaz. Hata ayıklama kaydını açıp beklemek burada zaman kaybıdır.

WordPress Yöneticiyi Nereden Anlıyor: capabilities ve user_level#

Çözüme geçmeden mekanizmayı bilmek gerekiyor, çünkü onarım tam olarak bu iki satırı yeniden yazmaktan ibaret.

Bir kullanıcının rolü users tablosunda tutulmaz. Kullanıcı adı, e-posta ve şifre özeti wp_users tablosunda durur; rol ise wp_usermeta tablosunda, önek taşıyan bir meta anahtarında saklanır:

• {önek}capabilities — serileştirilmiş PHP dizisi. Yönetici için değeri a:1:{s:13:"administrator";b:1;} şeklindedir.
• {önek}user_level — WordPress 2.0'dan kalma sayısal seviye. Yönetici için 10. Çekirdek artık buna dayanmaz ama bazı eski eklentiler ve menü kayıtları hâlâ okur.

Buradaki {önek} ifadesi kritiktir: wp-config.php içindeki $table_prefix değeridir. Öneğiniz wp_ ise anahtar wp_capabilities, sitem_ ise sitem_capabilities olur. WordPress her istekte kendi öneğini wp-config.php dosyasından okur ve tam olarak o anahtarı arar. Bulamazsa yetenek dizisi boş kalır ve kullanıcı hiçbir işlem yapamaz.

Rollerin kendisi — yani hangi rolde hangi yeteneklerin bulunduğu — ayrı bir yerde, wp_options tablosunda {önek}user_roles adlı tek bir satırda durur. Yani sistem iki parçalıdır:

Teşhisin belirleyici adımı bu ikisini ayırmaktır: sorun tek bir kullanıcıda mı, yoksa tüm yöneticilerde mi? Başka bir yönetici hesabıyla girip panelin tam açıldığını görürseniz sorun atamadadır. Tüm yöneticiler aynı eksik ekranı görüyorsa sorun rol tanımlarındadır. Bu tek soru, aşağıdaki bölümlerin yarısını atlamanızı sağlar.

Herhangi bir veritabanı müdahalesinden önce yedek alın. Bu yazıdaki UPDATE ve DELETE komutları geri alınamaz; WordPress yedekleme yazısındaki mysqldump adımı bir dakikanızı alır ve sizi saatlerce kurtarır.

Taşıma Sonrası Tablo Öneki Uyuşmazlığı#

En sık karşılaşılan ve en çok zaman kaybettiren neden budur. Senaryo hep aynıdır: siteyi başka bir sunucuya taşıdınız, bir yedekten geri yüklediniz ya da güvenlik önerisine uyup tablo öneğini wp_ yerine başka bir şeye çevirdiniz. Ön yüz kusursuz çalışıyor, giriş de yapılıyor — ama panel boş.

Sebep şudur: önek değişikliği yapan araçların çoğu tablo adlarını yeniden adlandırır ve wp-config.php dosyasını günceller, ama verinin içindeki önek taşıyan anahtarlara dokunmaz. Sonuçta wp_usermeta tablonuzun içinde hâlâ wpxy_capabilities yazan bir satır durur, WordPress ise wp_capabilities arar. İki taraf da kendi içinde tutarlıdır, sadece birbirini bulamazlar.

Öneği tahmin etmeyin, okuyun#

wp-config.php içinde şu satırı bulun:

$table_prefix = 'wp_';

Sunucuya SSH erişiminiz varsa daha hızlısı:

grep table_prefix wp-config.php
wp config get table_prefix
wp db prefix

Şimdi veritabanındaki gerçek duruma bakın. phpMyAdmin'de sitenizin veritabanını seçip SQL sekmesinden çalıştırın:

SELECT umeta_id, user_id, meta_key, meta_value
FROM wp_usermeta
WHERE meta_key LIKE '%capabilities'
   OR meta_key LIKE '%user_level'
ORDER BY user_id;

Bu sorgu % joker karakteri sayesinde önek ne olursa olsun tüm eşleşmeleri getirir. Çıktıda meta_key sütununa bakın: wp-config.php dosyasındaki önekle birebir aynı mı? Değilse teşhis kesinleşmiştir.

Satırları doğru öneke taşıyın#

İki yolunuz var. Eski satır duruyorsa yeniden adlandırmak en temizidir, çünkü mevcut rol bilgisini korur:

UPDATE wp_usermeta
SET meta_key = 'wp_capabilities'
WHERE meta_key = 'wpxy_capabilities';

UPDATE wp_usermeta
SET meta_key = 'wp_user_level'
WHERE meta_key = 'wpxy_user_level';

Buradaki wp_ yeni öneğiniz, wpxy_ ise veritabanında gördüğünüz eskisidir; ikisini de kendi değerlerinizle değiştirin. Eski satır hiç yoksa — bazı taşıma araçları usermeta tablosunu kısmen aktarır — doğrudan yenisini yazın. 1 yerine kendi kullanıcı kimliğinizi koyun:

INSERT INTO wp_usermeta (user_id, meta_key, meta_value)
VALUES (1, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');

INSERT INTO wp_usermeta (user_id, meta_key, meta_value)
VALUES (1, 'wp_user_level', '10');

Serileştirilmiş dizideki s:13 sayısı administrator kelimesinin karakter uzunluğudur. Bu değeri elle düzenlerken bir harf bile eklerseniz PHP diziyi çözemez ve satır tamamen yok sayılır — kopyalayıp yapıştırın, üzerinde oynamayın. Aynı sebeple, önek değiştirirken serileştirilmiş verinin içinde arama-değiştir yapmak da tehlikelidir: wpxy_ yerine wp_ yazmak dizgenin uzunluğunu değiştirir ve s: sayacını bozar.

Aynı hatanın ikinci kurbanı: user_roles#

Önek uyuşmazlığı yalnızca usermeta tablosunu vurmaz. wp_options tablosundaki rol tanımı satırı da önek taşır:

SELECT option_id, option_name FROM wp_options WHERE option_name LIKE '%user_roles';

Çıkan option_name yine eski öneği taşıyorsa aynı yöntemle düzeltin:

UPDATE wp_options SET option_name = 'wp_user_roles' WHERE option_name = 'wpxy_user_roles';

Bu satırı düzeltmeden sadece usermeta tarafını onarırsanız kullanıcıya "administrator" rolü atanmış olur ama o rolün hiçbir yeteneği tanımlı olmadığı için panel yine açılmaz. İkisi birlikte gider ve insanların "veritabanını düzelttim ama olmadı" dediği nokta genellikle tam burasıdır. Taşımanın tamamını doğru sırayla yapmak isterseniz WordPress manuel site taşıma yazısındaki kontrol listesi bu iki satırı da kapsıyor.

Rol Düzenleyici Eklentisi Administrator Rolünden Yetenek Sildi#

İkinci sık neden şudur: sitede User Role Editor, Members ya da PublishPress Capabilities gibi bir rol yönetim eklentisi kuruludur ve biri — çoğu zaman "müşteri eklenti kurmasın" niyetiyle — administrator rolünden activate_plugins, manage_options veya edit_themes yeteneğini kaldırmıştır.

Bu durumun ayırt edici belirtisi nettir: panel neredeyse tamdır, sadece belirli bölümler kayıptır ve sitedeki tüm yöneticiler aynı eksikliği görür. Rol ataması sağlamdır, eksik olan rolün içeriğidir.

Kontrol için kullanıcının rolüne değil, rol tanımına bakın:

wp role list
wp cap list administrator | wc -l
wp cap list administrator | grep -E "manage_options|activate_plugins|switch_themes"

Tek siteli standart bir WordPress kurulumunda administrator rolü 60'ın üzerinde yeteneğe sahiptir. Bu sayı 40'ın altına düşmüşse birileri budamış demektir. Eksik yeteneği tek tek geri eklemek yerine rolü fabrika ayarına döndürmek daha sağlıklıdır:

wp role reset administrator

Bu komut yalnızca WordPress'in varsayılan rol tanımını geri yükler; eklentilerin kendi eklediği özel yetenekleri de temizleyeceği için WooCommerce gibi rolü genişleten bir eklenti kullanıyorsanız işlem sonrası o eklentinin ayar sayfasını bir kez açıp yeteneklerini yeniden yazdırmakta fayda var. WP-CLI yoksa aynı işi eklentinin kendi arayüzünden yapabilirsiniz — ama panele giremiyorsanız bu bir kısırdöngüdür ve aşağıdaki mu-plugin yöntemine geçmeniz gerekir.

user_roles Bozulduğunda Rollerin Tamamen Kaybolması#

Üçüncü senaryo daha nadirdir ama en ürkütücüsüdür: {önek}user_roles satırı ya silinmiştir ya da içindeki serileştirilmiş veri bozulmuştur. Bu genellikle yarım kalan bir SQL içe aktarımından, max_allowed_packet sınırına takılan bir import işleminden ya da serileştirilmiş diziyi düz metin gibi işleyen bir arama-değiştir operasyonundan kaynaklanır.

Belirti: sitedeki hiç kimse yönetici değildir. Kullanıcılar listesinde rol sütunu boş görünür ya da "Yok" yazar. WordPress bu satırı bulamazsa varsayılan rolleri kendiliğinden geri getirmez; çekirdekte böyle bir otomatik kurtarma yoktur.

Bozukluğu görmek için:

SELECT option_name, LENGTH(option_value) AS uzunluk
FROM wp_options
WHERE option_name = 'wp_user_roles';

Sağlıklı bir kurulumda bu değerin uzunluğu birkaç bin bayttır. Sonuç hiç satır dönmüyorsa kayıt yok demektir; birkaç yüz bayt görünüyorsa muhtemelen kırpılmıştır. Onarım, WordPress'in kendi populate_roles() fonksiyonunu çalıştırmaktır — bu fonksiyon varsayılan beş rolü ve tüm yeteneklerini yeniden kurar, mevcut özel rollerinize dokunmaz. Tabloların fiziksel bütünlüğünden de şüpheleniyorsanız önce onarım adımlarını uygulayın; bozuk bir tabloya yazmak sorunu büyütür.

Panele Hiç Giremiyorsanız: Geçici mu-plugin ile Kurtarma#

phpMyAdmin erişiminiz yoksa ama FTP ya da dosya yöneticiniz varsa, WordPress'e tek seferlik bir kurtarma kodu çalıştırtabilirsiniz. wp-content/mu-plugins/ klasörünü oluşturun (yoksa) ve içine rol-kurtarma.php adıyla şunu koyun:

<?php
// GECICI KURTARMA DOSYASI - IS BITINCE SILIN
add_action( 'init', function () {
    $kullanici_id = 1; // kendi kullanici kimliginizi yazin

    if ( ! function_exists( 'populate_roles' ) ) {
        require_once ABSPATH . 'wp-admin/includes/schema.php';
    }

    // Varsayilan rolleri ve yeteneklerini yeniden kur
    populate_roles();

    // Kullaniciyi yonetici yap
    $kullanici = new WP_User( $kullanici_id );
    if ( $kullanici->exists() ) {
        $kullanici->set_role( 'administrator' );
    }
} );

mu-plugins klasöründeki dosyalar otomatik olarak ve panelden kapatılamayacak şekilde çalışır; kilitli bir sitede tam da bu yüzden işe yarar. Sitenin herhangi bir sayfasını bir kez açın, sonra /wp-admin adresine gidin.

Panel açıldığı anda dosyayı mutlaka silin. Yerinde bırakırsanız her sayfa isteğinde rolleri yeniden yazar; bu hem gereksiz bir veritabanı yazma yüküdür hem de o kullanıcı kimliğini kalıcı bir arka kapıya çevirir. Kod bir dosyada durduğu için sunucuya erişebilen herkes kimliği değiştirip kendini yönetici yapabilir.

WP-CLI ile Yetkiyi Saniyeler İçinde Geri Vermek#

Sunucuda kabuk erişiminiz varsa en hızlı ve en az riskli yol WP-CLI'dir; serileştirilmiş veriyle elle uğraşmadığınız için yazım hatası riski de ortadan kalkar. Komutları WordPress kök dizininde çalıştırın:

# Mevcut durumu gor
wp user list --fields=ID,user_login,user_email,roles

# Tek bir kullanicinin ham yetki kaydini oku
wp user meta get 1 wp_capabilities

# Rolu yeniden ata (mevcut rolleri temizler)
wp user set-role 1 administrator

# Rolu silmeden ek olarak ver
wp user add-role 1 administrator

# Hicbir yonetici kalmadiysa yeni bir tane olustur
wp user create kurtarma [email protected] --role=administrator --user_pass='UzunVeRastgeleBirSifre'

Son komut, hiçbir hesabın kurtarılamadığı durumlar için gerçek bir çıkış kapısıdır: yeni yöneticiyle girip eski hesabı panelden düzeltir, sonra kurtarma hesabını silersiniz. Kurulum ve temel kullanım için WP-CLI kullanımı yazısına bakabilirsiniz.

Bir uyarı: wp user set-role komutu kullanıcının tüm mevcut rollerini kaldırıp yenisini atar. Üyelik veya e-ticaret eklentilerinin ikinci bir rol atadığı kurulumlarda add-role daha güvenlidir, çünkü müşteri kaydını ya da abonelik rolünü silmez.

Çok Siteli Kurulumda Süper Yönetici Olmama#

Multisite (ağ) kurulumlarında iki ayrı yetki katmanı vardır ve bu ayrım sürekli karıştırılır. Bir alt sitenin yöneticisi olabilir ama ağ yöneticisi olmayabilirsiniz. Belirti çok tipiktir: alt sitenin paneli normal açılır, ancak /wp-admin/network/ adresi 403 verir ve üst çubukta "Ağım" menüsü hiç görünmez.

İki teknik fark vardır:

• Alt sitelerde yetki anahtarı {önek}capabilities değil, site kimliğini içeren {önek}{site_id}_capabilities biçimindedir. Ağdaki 3 numaralı site için anahtar wp_3_capabilities olur. Ana sitede sayı yoktur, bu yüzden "ana sitede yöneticiyim, alt sitede değilim" durumu son derece normaldir.
• Süper yöneticiler kullanıcı meta'sında değil, wp_sitemeta tablosunda site_admins seçeneğinde, kullanıcı adlarından oluşan bir dizide tutulur.

Kontrol için:

SELECT meta_id, meta_key, meta_value FROM wp_sitemeta WHERE meta_key = 'site_admins';

SELECT user_id, meta_key FROM wp_usermeta
WHERE meta_key LIKE '%capabilities' AND user_id = 1;

En temiz çözüm yine WP-CLI'dir; site_admins dizisini elle serileştirmek gereksiz bir risktir çünkü dizi kullanıcı adı uzunluklarını da kodlar:

wp super-admin list
wp super-admin add kullaniciadi
wp user list --network --fields=ID,user_login,roles

Ağ genelindeki yetki mantığının tamamı ve alt site yöneticisinin neden eklenti kuramadığı için WordPress multisite yazısına bakın.

Düzeldikten Sonra: Aynı Hatanın Tekrarlamaması İçin#

Yetki geri geldiğinde iş bitmiş sayılmaz; aynı arızayı üreten koşullar yerinde duruyor olabilir.

1. Kullanıcı listesini baştan sona kontrol edin. Beklemediğiniz bir yönetici hesabı varsa bu bir yetki arızası değil, güvenlik olayı olabilir. Kayıt tarihine ve e-posta adresine bakın; rol kaybının nedeni bazen bir saldırganın kendini tek yönetici yapmasıdır.
2. Rol düzenleyici eklentisini gözden geçirin. Rolleri budayan bir eklenti kuruluysa kimin neyi kısıtladığını yazılı tutun. Aksi hâlde aynı kesinti birkaç ay sonra tekrar yaşanır ve teşhis sıfırdan başlar.
3. Öneği bir daha elle değiştirmeyin. Önek değişikliği üç yerde eşzamanlı düzenleme gerektirir: tablo adları, usermeta anahtarları, options anahtarları. Bunu bir aracın yapması gerekir; elle yapılan her denemede en az biri unutulur.
4. İkinci bir yönetici hesabı bulundurun. Farklı bir e-posta adresine bağlı, güçlü şifreli yedek bir yönetici, bu yazıdaki tüm veritabanı müdahalelerini gereksiz hâle getirir.
5. Yedeğin geri yüklenebilirliğini test edin. Yedek almak yetmez; bir kez deneme ortamına geri yükleyip panelin açıldığını görmek, taşıma kaynaklı yetki sorunlarını canlıya taşımadan yakalar.

Son olarak, giriş adımının kendisiyle ilgili bir şüpheniz kaldıysa — şifre kabul edilmiyor, sıfırlama maili gelmiyor gibi — o ayrı bir konudur ve WordPress şifremi unuttum sıfırlama yazısında ele alınıyor. Buradaki hatanın şifreyle hiçbir ilgisi olmadığını unutmayın: WordPress sizi zaten tanıyordu, sadece ne yapabileceğinizi bilemiyordu.

Sıkça Sorulan Sorular#

Giriş yapabiliyorum ama menüler eksik, şifremi sıfırlamalı mıyım?#

Hayır. Giriş yapabiliyor olmanız kimlik doğrulamanın çalıştığını kanıtlar; sorun yetkilendirmededir. Şifre sıfırlamak wp_users tablosundaki şifre özetini değiştirir, rol bilgisiyse wp_usermeta tablosundaki capabilities satırında durur. Şifreyi kaç kez sıfırlarsanız sıfırlayın rol satırı aynı kalır ve panel yine eksik açılır. Doğru müdahale rol kaydını onarmaktır.

Bu hata bir eklenti çakışmasından kaynaklanabilir mi?#

Klasik bir çakışmadan nadiren kaynaklanır. Ancak rol yöneten eklentiler administrator rolünden yetenek kaldırabilir ya da kullanıcının rolünü değiştirebilir. Ayırt edici test şudur: sorun tüm yöneticileri etkiliyorsa rol tanımına, yalnızca sizi etkiliyorsa rol atamanıza bakın. Eklentileri FTP üzerinden kapatmak, rol tanımı zaten bozulduysa yetkiyi geri getirmez çünkü değişiklik veritabanına kalıcı yazılmıştır.

user_level satırı olmadan yönetici olabilir miyim?#

Modern WordPress sürümlerinde evet; çekirdek yetki kontrollerini capabilities üzerinden yapar ve user_level geriye dönük uyumluluk için tutulur. Yine de bazı eski eklentiler ve tema menü kayıtları bu değeri okur, bu yüzden yönetici için 10 olarak yazmak zararsız ve önerilir. Eksikliği tek başına 403 üretmez ama bazı ekranların eksik görünmesine yol açabilir.

Tablo öneğini değiştirmek gerçekten güvenlik sağlıyor mu?#

Etkisi sınırlıdır. Önek değiştirmek yalnızca tablo adını tahmin etmeye dayanan kaba SQL enjeksiyon denemelerini zorlaştırır; hedefli bir saldırıyı durdurmaz. Buna karşılık bu yazının konusu olan kilitlenmenin en yaygın sebebidir. Zaten çalışan bir sitede öneği değiştirmenin getirisi genellikle getirdiği riskin altında kalır; farklı bir önek seçmek için doğru an, yeni kurulum anıdır.

Veritabanına hiç dokunmadan bu sorunu çözebilir miyim?#

Evet, iki yol var. Sunucuda kabuk erişiminiz varsa WP-CLI ile set-role ve role reset komutları işi doğrudan halleder. Sadece FTP erişiminiz varsa mu-plugins klasörüne geçici bir PHP dosyası koyup populate_roles fonksiyonunu çalıştırabilir ve kullanıcınıza yönetici rolü atayabilirsiniz. Her iki yolda da işlem bittikten sonra kurtarma dosyasını silmeyi unutmayın.

Kullanıcı kimliğimi nasıl bulurum?#

En kesin yol veritabanıdır: users tablosundan kimlik, kullanıcı adı ve e-posta sütunlarını listeleyen basit bir sorgu tüm hesapları gösterir. WP-CLI varsa user list komutu aynı bilgiyi verir. Panele kısmen girebiliyorsanız Profil sayfasını açtığınızda adres çubuğundaki user_id parametresi de kimliğinizi söyler. İlk kurulan hesap genellikle 1'dir ama silinip yeniden oluşturulmuş sitelerde bu garanti değildir.