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...
Merhaba. PHP dizinizin içinde kimsenin görmemesi gereken bir veri yoksa dizinizi javascript'e iletmelisiniz. Böylece sayfa içinde dizinizdeki değerleri dilediğiniz gibi gösterebilirsiniz. (PHP dizinizdeki değerleri javascript'le değiştiremezsiniz. Javascript'le değiştirdiğiniz veriden PHP'nin haberi olmaz.)
<script>
const vary_info = <?=json_encode($vary_info)?>;
console.log(vary_info);
</script>
Eğer dizinizde çok büyük bir değer varsa bu yöntem performans kaybına neden olur. Söylediğiniz gibi sadece görüntüleneceği zaman ilgili veriyi ajax yardımıyla PHP'den istemek sayfanın açılış hızını olumlu etkileyecektir.
Ama yine söylediğiniz gibi bu sefer de aynı isteğin tekrar tekrar ajax ile PHP'den istenmesi sorunu olabilir. Bu da sunucuyu gereksiz yorar.
Sunucunun gereksiz yorulmasını önlemek için attığınız istekleri bir javascript değişkeninde tutabilirsiniz. Böylece aynı isteği yeniden atmanız gerektiğinde önce bu değişkeninize bakıp bu isteğin daha önce alınmış bir yanıtı olup olmadığını kontrol edersiniz ve gereksiz yere aynı isteği tekrar atmamış olursunuz. Yani attığınız her isteği cache'lemiş olursunuz.
Bunu yaptığınızda tarayıcının kullandığı ram miktarını bir miktar şişirmiş olursunuz. Eğer her bir istekten gelen veri çok büyük boyutluysa bu da çok ram harcamak demektir ama bence bu durum göz ardı edilebilir.
Eğer ram'in de çok şişmesini istemiyorsanız veriyi tarayıcının hafızasına kaydetmelisiniz. Yani bahsettiğiniz gibi local storage veya session storage burada size yardımcı olur. Tabi bunların 5'er mb sınırı (Chrome için) olduğunu da unutmamak lazım.
Eğer aldığınız veriyi session storage'a kaydedecekseniz önce string'e çevirmelisiniz çünkü bu storage'ler sadece string veri tutuyorlar.
<script>
sessionStorage.setItem("vary_info", JSON.stringify(<?=json_encode($vary_info)?>));
const vary_info = JSON.parse(sessionStorage.getItem(vary_info));
console.log(vary_info);
</script>
Bu örnekte session storage'ı kontrol ederseniz verinizin orada tutulduğunu görebilirsiniz. Veriniz json formatına uygun olduğu için tarayıcınız size veriyi json gibi gösterebilir ama aslında tutulan veri string'dir. Bu yüzden kullanmak istediğiniz zaman JSON.parse() fonksiyonu ile string'i json'a dönüştürmelisiniz.
Bu örnekte veriyi ram'da tutmak yerine storage'da tuttuk diyebilir miyiz? Diyemeyiz. Sonuçta veriyi okumak için yine bir değişkene aktarıyoruz ve aynı veri ram'da da yer kaplıyor. Burada session storage'ın bize sağladığı şey, sayfa yenilense bile bu veriyi kaybetmeyecek olamız. Ama tarayıcı kapatıldığı zaman bu veri kaybolabilir.
Tarayıcı kapatıldığı zaman da veri saklansın istiyorsak session storage yerine local storage kullanabiliriz. Kullanımı session storage ile birebir aynı. yine .setItem(key, value) ve .getItem(key) fonksiyonlarına sahip.
Bana göre; PHP ile tüm verileri sayfaya çağırmak yerine sadece sayfa ilk yüklendiğinde görünecek olan verilerin sayfaya çekilmesi daha uygundur.
Eğer kullanıcı diğer verileri görecekse ajax isteği atılır ve PHP'den gerekli veriler istenir. Aynı zamanda yapılan istek ve isteğin sonucu bir js değişkeninde (ram'de) tutulur.
Her ajax isteğinde önce bu değişken kontrol edilir ve yeniden istek atılıp atılmayacağı buna göre belirlenir. Daha önce atılmış istek tekrar atılmaz. (ta ki sayfa yenilenenene kadar)
Bunu nasıl yaparız? Mesela bir select'in change olayıyla PHP'den veri isteyeceğiz diyelim:
// Yaptığımız istekleri cache'leyecek olan değişkenimiz:
const requests = [];
// #my-select id'li select elementinin change olayı tetiklendiğinde çalışacak fonksiyon:
$("select#my-select").on("change", function() {
// Bu elemente kolayca (ajax fonksiyonu içinden de) erişebilmemiz için bir değişkene alıyoruz.
const $this = $(this);
// Ajax isteğimiz sonlanana kadar bu element'in kullanıcı tarafından tekrar değiştirilememesi gerekiyor. Elementi disabled edelim.
$this.prop("disabled",true);
// Kullanıcının seçtiği değeri alalım.
const value = $this.val();
// Ajax ile get isteği atılacak url'yi belirleyelim.
const url = "newdata.php?value="+value;
// Bu url'ye daha önce istek atılmış mı?
const lastRequest = requests.find(function(request) { return request.url === url });
// Eğer daha önce istek atılmışsa yeniden istek atmaya gerek olmadığı için veriyi direkt console'a yazdıralım.
if(lastRequest) {
console.log(lastRequest.data);
alert("Bu istek daha önceden atıldığı için yeniden ajax isteği atılmadı. Elimizdeki veri console'a yazıldı.");
// Bu adımdan sonra change olayının yapacağı başka bir işlem yok. select'in disabled değerini kaldırıp fonksiyonu return ile sonlandırabiliriz.
$this.prop("disabled", false);
return;
};
// Eğer buraya kadar geldiysek daha önce hiç istek atılmamış demektir. İsteği atabiliriz.
$.ajax({
url: url,
type: "get",
success: function(response) {
// Verimizi başarıyla aldıysak gelen veriyi console'a yazdıralım.
console.log(response);
alert("İlk kez istek atıldı ve veriler alındı. Console'a yazıldı.");
// Ayrıca bu veriyi cache'leyelim ki bi'daha bu istek atılmasın.
requests.push({url: url, data: response});
},
error: function(err) {
alert("Hata var!");
console.error("Ajax isteğinden hata döndü: ", err);
},
complete: function() {
// Olumlu veya olumsuz bir sonuç döndüğüne göre elementin disabled özelliğini kaldırabiliriz ki yeniden change edilebilsin.
$this.prop("disabled", false);
}
});
});
Kodları test etmeden yazdığım için hatalar olabilir. Ama aşağı yukarı kurgusal bir cevap yazdım sanıyorum. :)
Merhaba. Sorunuza varsayımsal bir cevap vermek istedim ama algoritmanızı nasıl kurduğunuzla ilgil çok fazla ihtimal var.
Sorunuzu biraz daha detaylandırmalısınız. "Bu şekilde bu sayfadan bu sayfaya veri gönderiyorum, bu şekilde işlemden geçirip bu şekilde sonlandırıyorum ve şu olsun istiyorum" şeklinde, kodlarınızdan da örnekler paylaşabilirseniz yardımcı olalım.
back-end dünyasında yeniyseniz bizim tahmin edemeyeceğimiz şekilde yanlış algoritma kurmuş olabilirsiniz.
Eğer bir input'un value'sini javascript ile değiştirmek istiyorsanız:
$myInput = $("#my-input");
const myInput_currentValue = $myInput.val(); // Input'un mevcuttaki value'sini aldık.
const myInput_newValue = myInput_currentValue.replaceAll(",",""); // Aldığımız değerdeki "," karakterlerini sildik.
$myInput.val(myInput_newValue); // Yeni oluşturduğumuz değeri input'un value'sine yazdık.
Veya bir input'ta bir değişiklik olduğu zaman bu işlemi yapmak istiyoruz diyelim:
$myInput = $("#my-input");
$myInput.on("input",function(){ // Input'a herhangi bir giriş olduğunda "input" adlı event çalışır.
const currentValue = $(this).val(); // Bu input'un value değerini aldık.
const newValue = currentValue.replaceAll(",",""); // Aldığımız değerdeki "," karakterlerini sildik.
$(this).val(newValue); // Bu input'un value'sine yeni değeri yazdık.
});
Ama mesela burada PHP kullanamazsınız. Sayfa kullanıcıya ulaştığı anda PHP ile bağlantısı sonlanır. Siz PHP'ye yeni bir istek atmadığınız sürece PHP sizin sayfanıza yapılan değişikliklerden haberdar olmaz.
Yani şöyle bir kullanımda verinin değiştiğini göremezsiniz:
<?php $myValue = "Merhaba, Dünya!"; ?>
<input type="text" value="<?=$myValue?>" />
<script>
$myInput = $("#my-input");
$myInput.on("input",function(){ // Input'a herhangi bir giriş olduğunda "input" adlı event çalışır.
<?php $newValue = str_replace(",","",$myValue); ?>
$(this).val("<?=$newValue?>");
});
</script>
Çünkü tarayıcı sizin PHP kodlarınızı göremez. PHP kodlarınız sunucu tarafında işlenip sayfanız dümdüz bir string'e dönüştürülerek istemciye gönderilir. İstemci (tarayıcı) sizin <?php ?> gibi ifadelerinizi veya php değişkenlerinizi görmez. PHP kendine ait olan işlemlerin hepsini sunucu tarafında halledip gönderir.
Yani siz yukarıdaki kodu yazdığınızda aslında tarayıcıya şu kod iletilmiş olur:
<input type="text" value="Merhaba, Dünya!" />
<script>
$myInput = $("#my-input");
$myInput.on("input",function(){ // Input'a herhangi bir giriş olduğunda "input" adlı event çalışır.
$(this).val("Merhaba Dünya!");
});
</script>
Gördüğünüz gibi sunucu tarafında PHP yapacağı her şeyi yaptı ve kendini yazdığınız koddan tamamen arındırdıktan sonra sayfayı tarayıcıya gönderdi.
Böylece input'unuzda her "input" event'i gerçekleştiğinde aslında input'un değerini direkt "Merhaba Dünya!" olarak değiştir demiş olduk.