Toplu İşlem ve Çoklu Seçim Tablosu

Bu proje ne yapıyor?

Bir bülten abone listesi üzerinde satırları işaretleyip toplu durum değiştirme ve toplu silme yapabilirsiniz. Ama asıl anlattığı şey bir arayüz hilesi değil:

Sunucu taraflı bir tabloda “seçili” kelimesinin iki farklı anlamı vardır ve bu iki anlamı birbirine karıştıran kod, kullanıcının onayladığından fazlasını siler.

Proje bu ayrımı kurar, iki anlamı tek bir doğru yoldan geçirir ve aradaki her boşluğu ölçüp kapatır.

---

“Seçili”nin iki hâli

Neden ikinci moda ihtiyaç var? — Gmail benzetmesi

Sunucu taraflı bir DataTables’ta kullanıcı asla tüm satırları aynı anda görmez; yalnızca o anki sayfayı görür. 50.000 kayıtlık bir listede “tümünü seç” dendiğinde 50.000 id’yi tarayıcıya indirip sonra sunucuya geri göndermek hem yavaştır hem anlamsızdır.

Gmail’de bir arama yaptığınızda üstteki kutucuğu işaretlersiniz ve şu çıkar: “Bu sayfadaki 50 konuşmanın tümü seçildi — bu aramaya uyan 4.312 konuşmanın tümünü seç.” İkinci bağlantıya bastığınızda Gmail size 4.312 kimlik göndermez; sunucuya “aynı arama koşulunu tekrar uygula, eşleşen herkese bu işlemi yap” der.

Bu proje tam olarak aynı deseni kurar:

resolve_bulk_scope()                             (system/ajax.php)
   scope=selected  →  WHERE id IN (:id0, :id1, :id2, …)
   scope=filtered  →  WHERE (name LIKE :s_name OR email LIKE :s_email
                             OR segment LIKE :s_segment) AND status = :status

Kritik nokta: koşul TEK YERDE üretilir

scope=filtered koşulu, ekrandaki listeyi üreten koşulla birebir aynı fonksiyondan gelir: subscriber_filter().

Bu koşul eskiden üç ayrı yerde (listeleme, sayaç, toplu işlem) kopyalanmıştı. Biri güncellenip diğeri unutulduğunda ortaya çıkacak hata sessizdir ve yıkıcıdır: kullanıcı ekranda 12 kişi görür, “tümünü seç” der, toplu işlem 15 kişiyi siler. Bu yüzden kopyanın kaldırılması burada bir temizlik değil, doğrudan bir güvenlik önlemidir.

---

Yanlışlıkla silmeye karşı iki ayrı fren

1. Fren — Gerçek sayıyla onay (bulk_preview)

Toplu işlem tetiklendiğinde önce bulk_preview uç noktasına gidilir. Sayı, işlemi yapacak olan resolve_bulk_scope()’un ta kendisinden gelir; önizlemenin ayrı bir hesap yolu olsaydı gösterdiği sayı bir süsten ibaret kalırdı.

Sayı her zaman veritabanından sayılır. Eskiden seçili kapsamda istemcinin gönderdiği id adedi döndürülüyordu; var olmayan 10 id gönderildiğinde pencere “10 kayıt SİLİNECEK” diyor, gerçekte 0 kayıt siliniyordu. Onay penceresinin tek varlık sebebi gerçeği göstermek olduğuna göre, o sayının kaynağı istemci olamaz.

2. Fren — Onaylanan sayı denetimi (expected_count)

Önizleme ile onay arasında geçen sürede liste değişebilir. Ölçülen senaryo: kullanıcı 8 kayıt için onay verdi, başka bir sekme araya bir kayıt ekledi, silme 9 kaydı götürdü.

Artık istemci, onay penceresinde gördüğü sayıyı işlem isteğiyle birlikte geri gönderir (expected_count). Sunucu kendi saydığı sayıyla karşılaştırır:

expected_count eksik              → 422, işlem yapılmaz
expected_count ≠ gerçek sayı      → 409, işlem yapılmaz, güncel sayı döner
yazma sırasında sayı kayarsa      → transaction geri alınır (rollback), 409

Arayüz 409’u bir hata olarak değil, bir fren olarak karşılar: listeyi tazeler ve onayı güncel sayıyla yeniden sorar.

“8 kayıt silinecek” onayı, 9 kaydı silmeye yetki vermez. Bu cümle projenin tamamının özetidir.

---

Mobil: tablo, telefonda tablo olmamalı

Sekiz sütunlu bir tablo telefona sığmaz. Yaygın çözüm overflow-x: auto ile yatay kaydırmadır — ve bu projede de öyleydi. Teknik olarak çalışıyordu; pratikte kullanılamıyordu:

Kullanıcı ad-soyadı görürken durumu ve işlem düğmelerini göremiyordu. Seçim kutucuğu ile “Sil” düğmesi arasında iki kere sağa-sola kaydırmak gerekiyordu.

Toplu işlemin ön koşulu satırı tanıyabilmektir. Hangi kaydı işaretlediğini görmeden onay veren bir kullanıcı, aslında onay vermiş sayılmaz. Yatay kaydırma bunu imkânsızlaştırıyordu.

Çözüm: aynı HTML, iki yerleşim

< 768px altında her `` bir karta dönüşür. Sunucu tarafında “mobil mi?” diye bir karar verilmez — tek bir HTML çıktısı iki yerleşimi de besler:

Etiketleri table.js içindeki rowCallback ekler; yerleşimi tamamen CSS kurar. PHP tarafında tek satır değişiklik gerekmedi.

Toplu işlem çubuğu ekranın altına sabitlendi

Çubuk akış içinde, tablonun üstündeydi. Telefonda kullanıcı listeyi aşağı kaydırıp 12. satırı işaretlediğinde çubuk ekranın çok yukarısında kalıyordu.

Seçim yaparken ekranda görünmeyen bir eylem çubuğu, olmayan bir eylem çubuğuyla aynı şeydir.

Mobilde çubuk artık position: fixed ile ekranın altına — başparmağın doğal olarak durduğu yere — sabitlenir. Üç eylem ızgaraya dizilir (“Durumu Değiştir” + “Seçilenleri Sil” yan yana, “Seçimi Temizle” tam genişlik), hepsi en az 44px yüksekliğindedir. Sayfanın son satırı çubuğun altında kalmasın diye `’ye seçim varken alt boşluk eklenir (body.cy-bulk-active), çentikli telefonlar için env(safe-area-inset-bottom)` hesaba katılır.

Bildirimler (toast) bilerek üstte bırakıldı: iki sabit öge alt kenarda çakışırdı.

Diğer mobil düzeltmeler

---

Arayüz geliştirmeleri (v1.1.0)

Shift + tık ile aralık seçimi. 40 satırlık bir sayfada 30 satırı tek tek işaretlemek kullanıcıyı yorar ve yanlış tıklamaya davet eder. Aralık, ekrandaki sıraya göre hesaplanır (lastPageIds). Olay change yerine click dinlenir — change olayı shiftKey bilgisini taşımaz.

Seçili satır artık görünüyor. Masaüstünde ince bir zemin rengi, mobil kartta sol kenarda marka mavisi bir şerit (.cy-row-selected). Kutucuğa bakmadan da hangi kartların seçili olduğu anlaşılır.

Esc seçimi bırakır. Toplu işlem modundan çıkmanın en hızlı yolu. Bir modal açıkken Esc Bootstrap’e bırakılır; iki davranışın çakışması “pencereyi kapatmak istedim, seçimim de gitti” şaşkınlığına yol açardı.

Açık / koyu tema düğmesi. Tasarım sistemi (cilginyazilim.css) zaten iki yoldan koyu temayı destekliyordu: prefers-color-scheme (işletim sistemi) ve ` (kullanıcı). Düğme yalnızca ikincisini yazar ve localStorage’a kaydeder; hiç dokunulmazsa karar işletim sistemine kalır. Tercih, sayfa çizilmeden ` içindeki satır içi betikle uygulanır — sonradan uygulansaydı koyu temada bir kare boyunca beyaz ekran görünürdü (FOUC).

ÖLÇÜLEN SORUN — “Seçimi Temizle” yarım çalışıyordu. İç durumu (selectedIds) boşaltıyor ve çubuğu gizliyordu, ama ekrandaki kutucuklar işaretli kalıyordu: seçim temizlendikten sonra tablo hâlâ “10 satır seçili” gibi görünüyordu. resetSelection() artık kutucukları da eşitliyor (syncPageCheckboxes()).

---

Ölçülen ve kapatılan sorunlar

Aşağıdakilerin hepsi çalışan kurulumda HTTP üzerinden ölçüldü, düzeltildi ve yeniden ölçüldü.

Denenip sorun çıkmayan noktalar

Bunlar da ölçüldü; burada bir açık bulunamadı ve kod olduğu gibi bırakıldı:

• SQL enjeksiyonu — sıralama sütunu: İstemci sütun adı değil, bir dizi indisi gönderir; tanınmayan indis id’ye düşer. order[0][column] alanına SQL parçası gönderildi, sorgu normal çalıştı.
• XSS: ` ve "> yükleri kayıt olarak eklendi; listede <script> olarak kaçışlı döndü. table.js metinleri .text() ile yazar, .html() ile değil.
• LIKE joker karakterleri: Arama kutusuna % yazıldığında 0 sonuç döndü (escape_like() çalışıyor) — aksi hâlde tek karakterlik bir arama tüm tabloyu “filtreye uyan tümü” kapsamına sokardı.
• BULK_MAX_IDS = 500: 501 id gönderildi → HTTP 422. Sınır gerçekten uygulanıyor.
• CSRF anahtarı oturuma bağlı: Başka bir oturumun anahtarıyla istek 403` aldı.

Bilinçli olarak değiştirilmeyen davranış

Filtre boşken scope=filtered tüm tabloyu hedefler. Ölçüm: bulk_preview → count: 60 (60 kayıttan 60’ı). Bu, Gmail’in “tüm konuşmaları seç” davranışının aynısıdır ve kaldırılmadı — “filtreyi temizleyip hepsini seçmek” meşru bir istektir; yasaklamak kullanıcıyı 500’er kayıtlık turlara zorlardı.

Yeterli koruma olduğu kanaatine şu gerekçeyle varıldı: bu işlem artık üç ayrı kapıdan geçiyor. Önizleme gerçek sayıyı yazıyor (“60 kayıt kalıcı olarak SİLİNECEK”), onaylanan sayı sunucuda doğrulanıyor, ve arayüzde bu moda geçmek ayrı bir bilinçli tıklama gerektiriyor. Sayının kendisi zaten en güçlü uyarıdır: tablonun tamamı olduğunda kullanıcı bunu okuyarak görür.

Transaction: neden var, neden tek başına gerekmezdi

bulk_status ve bulk_delete tek bir SQL ifadesi çalıştırır — tek ifadeli DML zaten atomiktir, bu hâliyle transaction tek başına gereksiz olurdu. Buradaki gerçek gerekçe, yazma sonrası yapılan “onaylanandan fazlasına dokundum mu?” denetimidir: sayım, yazma ve geri alma kararı ancak transaction içinde tek bir bütün olur. Transaction olmasaydı farkı görsek bile silinen kayıtları geri getiremezdik. (system/ajax.php execute_bulk())

---

Güvenlik katmanları ve her birinin nedeni

---

Dosya yapısı

bulk-actions-table/
├── index.php                  ← Arayüz: tablo, toplu işlem çubuğu, üç modal, tema betiği
├── .env.example               ← Veritabanı bilgileri (isteğe bağlı) — .gitignore içinde
├── cy_bulk.sql                ← Veritabanı kurulumu (cy_bulk, 60 örnek abone)
├── .htaccess                  ← Dizin listeleme kapalı, .sql/.md engelli, güvenlik başlıkları
├── system/
│   ├── .htaccess              ← Beyaz liste: yalnızca ajax.php dışarı açık
│   ├── config.php             ← Ayarlar, durum tanımları, PDO bağlantısı
│   ├── function.php           ← Çıktı/CSRF/doğrulama + subscriber_filter() (TEK doğruluk kaynağı)
│   └── ajax.php               ← 8 uç nokta + resolve_bulk_scope() + execute_bulk()
└── assets/
    ├── css/cilginyazilim.css  ← Marka tasarım kalıbı (ortak)
    ├── css/style.css          ← Sayfaya özel stiller + MOBİL KART GÖRÜNÜMÜ
    └── js/table.js            ← Seçim durumu: selectedIds / selectAllMatching

Hangi fonksiyon ne yapıyor?

Seçim durumu nerede tutulur?

Tamamen istemcide: table.js içinde bir Set (selectedIds) ve bir bayrak (selectAllMatching). Sunucu her zaman işaretsiz checkbox döndürür; hangi satırın işaretli görüneceğine istemci karar verir (restoreCheckboxState()).

Arama veya durum filtresi değiştiğinde seçim otomatik sıfırlanır: “filtreye uyan tümü” seçimi belirli bir filtreye bağlıdır, filtre değişince o seçimin ne anlama geldiği belirsizleşir.

İki sekme açıksa: her sekmenin kendi selectedIds’i vardır; birbirlerini görmezler ve görmeleri de gerekmez, çünkü seçim bir kullanıcı niyetidir, paylaşılan bir durum değil. Sekmeler arası asıl risk seçimin değil, sayının kaymasıdır — onu da expected_count denetimi kapatır (ölçüldü: HTTP 409, veri değişmedi).

---

API uç noktaları

Hepsi system/ajax.php adresine POST ile gider ve JSON döner. action=list dahil tümü csrf_token ister.

Kapsam alanları: scope=selected → ids[] · scope=filtered → search, status_filter

HTTP durum kodları

419 bilerek kullanılmaz: resmî bir kod değildir ve bu Apache kurulumunda sessizce 500’e dönüşerek istemciyi yanıltır.

---

Veritabanı şeması

cy_bulk · tek tablo: subscribers (60 örnek kayıt — aktif 47, pasif 9, engelli 4)

İndeksler neden bu sütunlarda? (123.000 kayıtla ölçüldü)

Arama neden hâlâ ~300 ms? Arama LIKE '%metin%' kullanır; baştan joker içeren kalıp hiçbir indeksten yararlanamaz. Bunun çözümü indeks eklemek değil FULLTEXT indekse ya da ayrı bir arama motoruna geçmektir — örneğin sade tutmak için bilinçli olarak yapılmadı.

---

Özelleştirme

Yeni bir durum eklemek — tek yer yeterli, config.php:

define('SUBSCRIBER_STATUSES', [
    'aktif'   => ['label' => 'Aktif',   'css' => 'success'],
    'pasif'   => ['label' => 'Pasif',   'css' => 'secondary'],
    'engelli' => ['label' => 'Engelli', 'css' => 'danger'],
    'beklemede' => ['label' => 'Beklemede', 'css' => 'warning'],   // ← yeni
]);

Form açılır listesi, filtre kutusu, rozetler, toplu işlem menüsü ve doğrulama hepsi buradan beslenir. Ayrıca cy_bulk.sql içindeki ENUM değerini genişletmeyi unutmayın.

Arama kapsamını değiştirmek — yalnızca subscriber_filter() içindeki koşul. Listeleme ve toplu işlem otomatik olarak aynı anda güncellenir; ikisinin ayrışması yapısal olarak mümkün değildir.

Seçim sınırını değiştirmek — config.php içindeki BULK_MAX_IDS.

Yeni bir toplu işlem eklemek (örn. “toplu segment değiştir”) — execute_bulk()’a bir SQL şablonu vermek yeterlidir; sayı denetimi, transaction ve parametre bağlama hazır gelir:

[$affected] = execute_bulk(
    $db,
    'UPDATE subscribers SET segment = :segment WHERE {where}',
    [':segment' => $segment]
);

Kendi tablonuza uyarlamak — subscribers yerine kendi tablonuzu, SUBSCRIBER_STATUSES yerine kendi alan tanımlarınızı koyun. Toplu işlem altyapısı tabloya değil, koşula bağlıdır.

---

Örnek kullanım alanları

• Bülten / e-posta pazarlama panelleri — “Bu segmentteki herkesi pasife al”, “sert dönen adresleri toplu engelle”.
• E-ticaret yönetimi — “Stoğu biten tüm ürünleri yayından kaldır”, “bu kategorideki 400 ürüne toplu indirim”.
• Yorum / içerik denetimi — “Bu kullanıcının tüm yorumlarını gizle”, “onay bekleyen 250 yorumu toplu onayla”.
• Üyelik ve CRM sistemleri — “Bir yıldır giriş yapmamış üyeleri toplu arşivle”.
• Sipariş / talep yönetimi — “Bugünün kargolanan siparişlerini toplu ‘tamamlandı’ yap”.
• Veri temizliği — “Doğrulanmamış kayıtları filtreleyip toplu sil” — burada expected_count freni en çok işe yarayan yerdir.

Ortak nokta: hepsinde kullanıcı gördüğünden fazlasını seçebilir ve işlemlerin çoğunun geri dönüşü yoktur.

---

Sürüm geçmişi

v1.1.0 — Mobil deneyim ve seçim ergonomisi

• Mobil kart görünümü — < 768px altında her satır bir karta dönüşür; yatay kaydırma tamamen kalktı.
• Ekranın altına sabitlenen toplu işlem çubuğu — seçim yaparken her zaman görünür, tüm eylemler ≥ 44px.
• Mobil sıralama listesi ve mobil “sayfadaki tümünü seç” — gizlenen `’in kaybettirdiği iki denetimin karşılığı.
• Shift + tık ile aralık seçimi.
• Seçili satır göstergesi (.cy-row-selected).
• Esc ile seçimi bırakma.
• Açık / koyu tema düğmesi — FOUC’suz, localStorage’a kayıtlı.
• Düzeltme: “Seçimi Temizle” ekrandaki kutucukları işaretli bırakıyordu.
• iOS Safari otomatik yakınlaştırması, dokunma hedefi boyutları, güvenli alan (safe-area-inset`) ve mobil sayfalama düzeni.

v1.0.0 — İlk sürüm

Sunucu taraflı DataTables, iki kapsamlı toplu işlem (scope=selected / scope=filtered), gerçek sayıyla onay (bulk_preview), onaylanan sayı denetimi (expected_count) ve ölçülüp kapatılan 10 güvenlik/başarım sorunu.

---

Lisans

MIT — dilediğiniz gibi indirip kullanabilir, değiştirebilir ve ticari projelerde kullanabilirsiniz. Ayrıntılar için LICENSE.

---