Sevgili bazı prototurk.com soru-cevap bölümü kullanıcıları,
Bir soruya doğru yanıtınızı aldığınızda yanıtı "Doğru Cevap" olarak işaretleme nezaketi gösterirseniz aynı sorulara tekrar tekrar girip bakmamış oluruz.
Sorunuza çözüm bulamadıysanız da neden çözüm bulamadığınıza dair bi'şeyler yazıp konuyu ilerletin veya kendi başınıza çözdüyseniz kendi çözümünüzü yazıp doğru cevap olarak işaretleyin en azından.
Bi'başlık açıyorsanız cevap verenlere saygı gösterip başlığınızın takibini de yapmanız pek güzel olur.
for/foreach döngüsü işinizi görmüyor mu?
$hedefler = [
'https://www.ornekLink1.com/a-1',
'https://www.ornekLink1.com/a-2',
'https://www.ornekLink2.com/b-1',
'https://www.ornekLink3.com/b-1',
'https://www.ornekLink4.com/b-2'
];
$sonuclar = [];
foreach($hedefler as $hedef) {
$ct = curl_init();
curl_setopt($ct, CURLOPT_URL, $hedef);
curl_setopt($ct, CURLOPT_HEADER, 0);
$sonular[] = curl_exec($ct);
curl_close($ct);
echo "<div>$hedef için curl isteği tamamlandı.</div>";
}
Denemek lazım... Sırayla tüm isteklerin sonuçları $sonuclar array'ına işlenecek.
O zaman sanırım veritabanında tuttuğunuz verilerle ilgili bir sorun olabilir.
emlakci tablonuzda premium_1, premium_2 ve premium_3 adında sütunlarınız var.
Ayrıca premium_uyelik tablonuzda da bu alanlar var.
Hem emlakci hem de premium_uyelik tablolarından kayıt çekerken tek bir id değeri kullanıyorsunuz. Sanırım bir üye kaydı yaptığınızda üyenin 2 tabloda da kaydını oluşturuyorsunuz ve id'lerin böylece aynı olmasını sağlıyorsunuz. Burada bir sorun var gibi geldi bana.
Eğer premium üyelikleri ayrı bir tabloda tutacaksanız, emlakci tablonuzda 3 adet premium durumu tutmak yerine premium_uyelik tablosuyla ilişki kurabileceğiniz 1 adet premium_uyelik_id adlı sütununuz olmalı. Yani:
emlakci tablosu sütunları: id, kayit_tarihi, premium_uyelik_id şeklinde olmalı.
Buradaki premium_uyelik_id sütunu, kullanıcının premium üyeliği varsa premium_uyelik tablosuna kaydedildiği id değerini tutmalı. Kullanıcı premium üyelik almamışsa bu değer 0 olmalı.
Siz ilk kez sisteme kaydolan kullanıcıya direkt 1 haftalık premium paketlerini hediye ettiğiniz için kullanıcı kayıt olduğu anda iki tabloda da kullanıcıya kayıt açmalısınız ve premium_uyelik tablosunda kullanıcının id değerini alıp emlakci tablosundaki premium_uyelik_id sütununa yazmalısınız.
Böylece artık emlakci tablosunda sadece üyenin herhangi bir premium paketi olup olmadığını tutmuş olacaksınız. Premium detaylarını da premium_uyelik tablosunda tutuyorsunuz zaten.
Daha sonra bir premium paketinin bitiş tarihini nasıl hesaplayacağınızı kurgulamak lazım. Burada hesaplamayı "+1 week" şeklinde yapmamalısınız.
premium_uyelik tablosunda kayıt oluştururken zaten ne süreyle premium üyelik verdiğinizi biliyorsunuz. Bu yüzden bu tabloda paketin bitiş tarihini tutmalısınız. Mesela premium_1 sütununda, bu üyenin 1. premium paketinin hangi tarihte sona ereceği bilgisi direkt tutulabilir. Eğer kullanıcı bu paketi hiç almamışsa buranın değeri NULL olur.
Böylece örneğin şöyle bir veritabanı yapısına kavuştuk:
emlakci
id: 123
kayit_tarihi: '2022-06-23 15:55:24'
premium_uyelik_id: 23
premium_uyelik
id: 23
premium_1: '2022-06-30 15:55:24'
premium_2: '2022-06-30 15:55:24'
premium_3: '2022-06-30 15:55:24'
Bu üye sisteme 23 Haziran'da kaydolmuş. Biz de kayıt tarihinden itibaren 1 hafta sonra sonlanmak üzere 3 premium paketi de vermişiz.
Sonra mesela bu üye paketleri incelemiş ve premium_2 paketini beğenip 1 aylığına almak istemiş olsun.
O zaman bu üyenin premium_uyelik_id sütununa bakarak 23 değerini elde ederiz.
premium_uyelik tablosundaki id=23 olan sütunun premium_2 sütunundaki tarihi alırız.
Bu tarih geçmiş bir tarih mi?
EVET: O zaman premium_2 alanına bugünün şu anından itibaren 1 ay sonrasının tarihini yazarız.
HAYIR: O zaman premium_2 alanındaki tarihi alır, bu tarihe 1 ay ekler, yeni tarihi buraya yazarız.
Böylece premium_uyelik tablosunun id=23 satırının son hali şöyle olur:
id: 23
premium_1: '2022-06-30 15:55:24'
premium_2: '2022-07-30 15:55:24' (1 hafta + 1 ay)
premium_3: '2022-06-30 15:55:24'
Kontrollerimizi yaparken artık işimiz çok kolay. Üyenin herhangi bir premium üyeliği var mı diye emlakci tablosundaki premium_uyelik_id değerine bakarız. Bu değer NULL veya 0 değilse belli ki premium üyeliği var veya daha önce en az bir kere premium üyelik almış. (Tabi siz kaydolan her müşteriye premium verdiğiniz için bu mecburen olacak)
Sonra bu değer ile premium_uyelik tablosuna gider, her bir premium paket için kayıtlı tarihi kontrol ederek günü geçmiş mi diye bakarız.
Günü geçmemiş olanlar aktiftir. Günü geçmiş olanları umursamamıza gerek yok.
Uzun bir cevap oldu. Umarım anlaşılır olmuştur. Kurgu yazması kolay. Kodlamasında kolay gelsin... :)
PHP ile bir yönetim paneli yapıp güncelleyemediğiniz yer neresi?
1) Kurgunuz şu şekilde mi?
Sizin 1 adet premium üyelik özelliğiniz var. Paketler, bu premium özelliklerine ne kadar süreyle sahip olunacağını belirtiyor.
1.paketi seçerlerse 1 haftalık premium üyelik kazanmış oluyorlar.
2.paketi seçerlerse 1 aylık premium üyelik kazanmış oluyorlar.
3.paketi seçerlerse 1 yıllık premium üyelik kazanmış oluyorlar.
2) Yoksa kurgunuz şu şekilde mi?
Sizin 3 adet premium üyelik özelliğiniz var. Paketler, hangi premium özelliklerine sahip olunacağını belirtiyor.
1.paketi seçerlerse 1.premium üyelik özelliklerini almak için 1 hafta, 1 ay, 1 yıl seçenekleri mevcut.
2.paketi seçerlerse 2.premium üyelik özelliklerini almak için 1 hafta, 1 ay, 1 yıl seçenekleri mevcut.
3.paketi seçerlerse 3.premium üyelik özelliklerini almak için 1 hafta, 1 ay, 1 yıl seçenekleri mevcut.
Anladığım kadarıyla 2. kurgu sizin için geçerli çünkü kayıt tarihinden itibaren 1 hafta boyunca 3 paketi de hediye ediyorsunuz.
Yani 3 farklı premium üyelik özelliklerini kayıt tarihinden itibaren 1 hafta boyunca kullanıcıya hediye etmek istiyorsunuz.
2 kurgu da üzerine ayrı ayrı düşünelecek kurgular. Sizinki hangisiyse ona göre ilerleyelim.
NOT: "dahi" anlamındaki tüm -de'leri bitişik, hal eki olan tüm -de'leri ayrı, ayrı yazılması gereken tüm soru eklerini bitişik yazıyorsunuz. Bu TDK'ye bir tepki mi diye düşündüm bi'an.
@kartal, local storage ile ilgili sorularınıza yanıt vereyim.
- local storage için domain başına 5mb alan ayrılır. Bu alanı açmak için sizin yapmanız gereken bi'şey yok. Bu alan hep açıktır.
- Başka sitelerin local storage'yi doldurması mümkmün değildir. Tarayıcı, local storage'yi her domain için ayrı ayrı tutar.
- Başka bir sitenin sizin local storage'ınıza ulaşma şansı yoktur. Dizin domain'inize ayrılmış local storage'a sadece sizin domain'inizle erişilebilir.
- Eğer bir tarayıcının sizin siteniz için ayrılan local storage'ı dolmuşsa yeni veri ekleyemezsiniz. Eklemek istediğinizde konsolda QUOTA_EXCEEDED_ERR hatası fırlatıldığını görürsünüz. Daha doğrusu o kullanıcı bu hatayı görür. Bu hata çıktıysa tarayıcı local storage'a veriyi yazmaya çalışmaz. (yani verinin yarısı yazıldı, geri kalanı yazılamadan kota doldu gibi bir durum olmaz. yeni veri yazıldıktan sonra kota dolacaksa tarayıcı local storage'ı değiştirmeyecektir.)
- Bazı tarayıcılar local storage'ın alanının artırılmasına izin verebiliyor (Opera, Firefox) sanırım ama tabi bunun bir anlamı yok çünkü kullanıcılardan tarayıcı ayarlarına girip bizim için düzenleme yapmalarını bekleyemeyiz.
Bu durumda herhangi bir input'un input olayı tetiklendiğinde tüm input'ları kontrol etmelisiniz.
Kodunuzda şu değişikliği yapabilirsiniz:
$inputRequired.on("input", function() {
let buttonWillBeActive = true; // kontrolümüzden sonra bu değer halen true kalırsa butonu aktif edeceğiz.
for(i=0; i<$inputRequired.length; i++) { // tüm input'ları tek tek dolaşıp değerlerini kontrol edelim.
const val = $inputRequired.eq(i).val().trim(); // şu an baktığımız input'un değerini alalım.
if(!val) { buttonWillBeActive = false; break; } // değer boşsa buttonWillBeActive değerini false edip döngüden çıkalım.
}
if(buttonWillBeActive) buttonActived(); // buttonWillBeActive değeri kontrolden sonra halen true kalabilmişse buton aktif olacak.
else buttonDisabled(); // buttonWillBeActive değeri kontrol sırasında false edilmişse buton pasif olacak.
});
$data = $db->prepare('INSERT INTO orders SET note=?,supplier_id=?,order_number=(SELECT order_number FROM orders ORDER BY order_number DESC LIMIT 1)+1, price=?, username=?');
$data->execute([$note, $_POST["supplier_id"], $price, $username]);
Şeklinde deneyebilirsiniz. Her insert işleminizde, tablonuzdaki en büyük order_number değerini select ile alıp üstüne 1 eklemiş olurusunuz.
Ajax isteği sonucunda size input'a yazacağınız yeni değerler geliyorsa success fonksiyonunuz içinde şu şekilde input'un value'sini güncelleyebilirsiniz:
success: function(response) {
const newToken = response.token; // yeni token verisi böyle geliyor diyelim.
$('[name="_token"]').val(newToken);
});
Eğer gelen veriyi tam olarak nasıl alacağınızdan emin değilseniz console.log() fonksiyonu ile gelen veriyi konsola yazdırıp çıktıyı buraya yazarsanız javascript ile bu veriyi tam olarak nasıl alıp <input name="_token" /> inputuna value olarak gönderebileceğinizi yazabiliriz.
success: function(response) {
console.log(response);
});
hepsiburada'nın attığı sık istekler de büyük ihtimalle sunucu taraflı tutulan cache mekanizmasından yanıt alıyordur. Siz de benzeri şekilde cache mekanizmasını sunucu taraflı kurabilirsiniz.
Diyelim ki select elementinin her change olayında newdata.php dosyasına get isteği atıyorsunuz.
/newdata.php?productid=123&value=1
Normalde newdata.php bu isteğe şöyle bir kurguyla cevap verir:
1) Bu istekle gelen parametreleri al.
2) Güvenlik için parametrelerin doğru formatta gelip gelmediğini kontrol et.
3) Veritabanına bağlanıp gerekli SELECT sorgusunu yapıp cevap al.
4) Veritabanından gelen verileri istemciye göndermek üzere organize edip json'a dönüştür.
5) Verileri istemciye gönder.
Burada veritabanından direkt sorgulama yaptığınız için en güncel veriye ulaşmış oluyorsunuz.
Bir de cache mekanizmalı bir kurgu belirleyelim ve aynı istek newdata.php'ye atılmış olsun:
1) Bu istekle gelen parametreleri al.
2) Güvenlik için parametrelerin doğru formatta gelip gelmediğini kontrol et.
3) Bu isteğe karşılık gelen bir cache dosyası oluşturulmuşsa bu dosyanın içeriğini direkt gönder ve işlemi sonlandır.
4) Cache dosyası elimizde olmadığı için veritabanına bağlanıp gerekli SELECT sorgusunu yapıp cevabı al.
5) Veritabanından gelen verileri istemciye göndermek üzere organize edip json'a dönüştür.
6) Json'a dönüştürdüğün bu verileri bir cache dosyasına yazıp kaydet.
7) Verileri istemciye gönder.
Bu kurguda da eğer sunucuda cache'lenmiş bir dosya varsa sunucu o veriyi gönderir ve 3 adımda işlemi bitirir. Hem veritabanını hem kendini çok yormamış olur.
Cache'lenmiş bir dosya yoksa normal kurgusundaki gibi verileri oluşturur ve istemciye göndermeden önce cache dosyasını da oluşturur. Böylece sonraki isteklerde bu kadar uğraşmaz.
Cache dosyalarını nasıl isimlendireceğiniz size kalmış. Birbiriyle çakışması mümkün olmayacak ve sizin de manuel aradığınızda belli bir dosyası kolayca bulabileceğiniz dosya adları tercih etmeniz güzel olur.
Örneğin: /cache/active/product~id-1234~color-buz mavisi~beden-34.json gibi bir dosya adı hem göz yordamıyla aradığınızda bile kolayca bulabileceğiniz, hem ~ karakterlerinden explode etmenin kolay olması, hem de belli bir istek için benzersiz olması açısından güzel görünüyor. Ama bu sefer de dosya adı çok uzayabilir veya Türkçe karakter sorunları yaşayabilirsiniz. Verilerinizi nasıl bir dosya adıyla saklayacağınız tamamen size kalmış. İlle de göz yordamıyla bulmanın kolay olması gerekmiyor tabi. Belli bir şifreleme yöntemiyle benzersiz bir dosya adı da oluşturabilirsiniz. O zaman da dosyanın adı product-asdf123abc.json gibi bi'şey olur mesela.
İyi ama bu cache dosyaları bir kez oluştuktan sonra sunucu artık hep cache dosyalarının yanıtlarını döndürecekse veritabanında sonradan meydana gelen bir değişiklik olduğunda nasıl yeni veri istemciye iletilecek?
Bunun için cache dosyalarını silen bir mekanizmamız olması gerekiyor. Yani veritabanında bu cache dosyalarını etkileyecek bir güncelleme yapıldığında cache dosyaları sistemden silinecek. Böylece istemcilerin yaptıkları ilk istekte yeni cache dosyaları oluşturulmuş olacak.
Cache dosyalarını silen mekanizma da 2 türlü yapılabilir:
1) Yönetim panelinden veritabanında bir değişiklik yapıldığında, mesela bir ürünün fiyatı değiştiğinde, ilgili ürünle ilgili bütün cache dosyaları silinebilir. Yani bu UPDATE sorgusundan sonra bir de ilgili cache dosyalarını bulup silecek kodlar eklenir.
2) Yönetim paneline bir buton: "Cache Sil". Benim favorim bu. Sistenin tüm cache dosyalarını silen bir buton da olabilir, ürün ürün veya sayfa sayfa silen birkaç silme butonu da olabilir. Ama başlangıç için tüm siteyi temizleyen buton iyidir. Bu butona basmak yönetim panelindeki kullanıcının sorumluluğundadır. Panelde yapacağı tüm değişiklikleri yaptıktan sonra Cache Sil butonuna basar ve bütün cache dosyalarının silinmesini sağlar. Sonra siteye giren ilk istemciler yavaş cevap alsa da sonraki istemciler cache'ten cevap alacakları için hızlı yanıt alırlar.
Back-end tarafında böyle bir cache mekanizması kurarsanız sunucunuz çok yorulmaz. Veritabanınız da normalde yorulduğundan çook çok daha az yorulur. Veritabanına yapılan istekler azaldığı için sunucu maliyetleriniz de düşer.
Back-end taraflı bu önlemleri aldıktan sonra bir de üstüne front-end temelli önlemlerinizi alır, PHP'ye hiç istek atmadan döndürülebilecek verileri de istemci harafında dönebilirseniz (verileri tarayıcının ram'inde tutma yöntemiyle) iyiden iyiye hem çok performanslı hem de mininum sunucu maliyetli bir sistem geliştirmiş olursunuz.
Elbette back-end tarafında tüm bu işlemleri yaparken kendinize ayrı bir php dosyasında fonksiyonlar hazırlamalısınız. Kod tekrarına düşmemelisiniz.
Mesela addCache($key, $value) adında bir fonksiyon ile cache eklemelisiniz. Burada $key dediğim değişken, json uzantılı cache dosyanızın adı, $value da bu json dosyasına yazacağınız içeriktir.
removeCache($key) adında bir fonksiyonunuz da olmalı ve bir cache dosyasını sileceğiniz zaman hep bu fonksiyonu kullanmalısınız. Fonksiyonunuz, $key adıyla aldığı dosya adını cache dosyaları içinde bulup silecek.
Bu arada bir cache silme işleminde tabii ki cache dosyasını ille de silmek zorunda değilsiniz. Onun yerine silinecek dosyayı dosyayı mesela cache/archive/2022-06-21 09:35:32/ adlı bir klasöre de taşıyabilirsiniz. Böylece bir hata durumunda mesela undoLastCache() gibi bir fonksiyonunuz olur ve son arşivlenen cache dosyalarını bulup geri yükleme şansınız olur. Başlangıçta gerekmese de ilerleyen zamanlarda böyle tedbirler kriz yönetimi açısından iyidir.
Tabii getCache($key) gibi bir fonksiyon ile cache dosyasının içeriğini alabileceğiniz fonksiyonunuz da olmalı.
Bunun haricinde bir cache dosyasının oluşturulup oluşturulmadığını kontrol edebileceğiniz bir issetCache($key) fonksiyonunuz da olsa pek hoş olur.
Eğer bir json dosyasını cache'lerken json içine dosyanın oluşturulduğu tarihi de eklerseniz sunucu üzerinde bir cron tanımlayıp belli zamanlarda removeOutOfDateCaches() gibi bir fonksiyonla tarihi geçmiş cache dosyalarının silinmesini sağlayabilirsiniz. Veya bir cache dosyasını okuduğunuzda isCasheOutOfDate($cacheData) gibi bir fonksiyonla tarih kontrolü yapıp tarihi geçmiş bir cache dosyasının kullanıcıya gösterilmesini engelleyebilirsiniz. Örneğin bir kampanya tanımlanmıştır ve bu kampanya 3 gün geçerli olacaktır. Bu durumda bu kampanyadan etkilenen ürünlerin cache dosyaları 3 gün sonra sıfırlanmalı ve yeni cache dosyaları oluşturulmalıdır.
Muhakkak düşündükçe pek çok senaryoya göre pek çok yeni fonksiyona ihtiyaç olduğu görünecektir ama başlangıç için sadece ekleme-silme-okuma işlemleriyle başlamak uygun olur.
Yani bir cache.php dosyanız olmalı ve içinde cache klasörünüzü yönetebileceğiniz fonksiyonlarınız olmalı.
Gibi gibi şeyler...