tarihinde yayınlandı tarafından — Yorum yapın

Vito’da Veritabanı Yedeklemelerinin Başarısız Olması

Harika bir günden herkese merhabalar,

Bildiğiniz üzere diye başlamak isterdim fakat tabii ki bilmiyorsunuz 🙂 Ben bir süredir sunucu yönetimi konusunda Vito kullanıyorum. Ne kadar başarılı, ne kadar başarısız, kişiden kişiye göre değişir. Hatta ne kadar güvenilir? Allah bilir. Fakat Laravel uygulamalar için son derece kullanışlı, basit ve verimli bir uygulama. Sadece tek başına ayrı sunucuda çalıştırılıyor olması maliyet açısından bir dezavantaj sanırım 🙂 Neyse konuyu dağıtmayalım.

Vito içerisinde veritabanlarınızın otomatik olarak belirli sürelerde yedeklerini aldırabiliyorsunuz. Bu konuda problem yok. Fakat büyük veritabanlarının backuplarını aldırmaya çalıştığınızda işlem süresi 600 saniyeyi geçtiğinde ne yazık ki Failed şeklinde bir uyarı ile karşılaşıyorsunuz. Aslında failed olmuyor fakat konuyu iyi analiz etmek için Vito’nun çalışma mantığını anlatayım.

Veritabanı yedeği almak istediğinizde Vito, queue’ya hemen bir job dispatch ediyor. Bu süre zarfında ilgili backup için bir Backup kaydı ve yedeği sakladığı dosya içinde bir File kaydı oluşturuyor. Bu görev queue’da hedef sunucuya ssh ile bağlanıp ilgili komutu çalıştırıyor. Queue’daki görev 600 saniyelik timeout sınırını aştığında görev TimeoutExceededException ile sonlanıyor ve Backup ve File failed durumlarını alıyor. Fakat çalıştırılan mysqldump komutu hedef sunucuda hala çalışıyor ve görevini tamamlıyor.

Buradaki problem şu, backup başarılı bir çalışıyor ise problem ne? Problem farkındalık! Ya gerçekten failed olmuşsa işlem ya failed olduğunu farkedemediysek? Ayrıca şıkır şıkır çalışmasını beklediğiniz işlerde her yer kıpkırmızı failed failed yazınca mental olarakta sizi olumsuz etkilen bir durum oluşuyor.

Bu durum için çözüm üretmeye çalıştım ve config dosyalarına doğrudan müdahale ettim ki bu aslında hiç istenmeyen bir durum çünkü güncellemeleri kaçıracaksınız. Vito için plugin yazılabildiğini farkettim ve benim ihtiyacımı kusursuz karşılayan şu plugini hazırladım: Vito Extended SSH Timeouts

Pluginin yaptığı işlem çok basit. ServiceProvider olarak çalışıyor bile diyebiliriz. boot metodu içerisinde config’lere müdahale ediyorum. Birde enable diye bir method var. Burada da config cacheleri temizliyorum ve horizon’ı terminate ediyorum, korkmayın, supervisor terminate edilen horizonu yeniden başlatacak 🙂

Kodun detaylarına Github reposu üzerinden ulaşabilirsiniz. Çok basit fakat ilk defa karşılaşıldığında uğraştırıcı bir derdi çözüyor. Kabaca ssh queuesunun timeout süresini 10 dakikadan 50 dakikaya çıkarıyor. Daha da yukarıya çıkarmayı çok isterdim fakat supervisor ayarlarındaki stopwaitsecs‘in üzerine çıkmak istemedim. Oradaki limit 3600 saniye idi.

DİKKAT!
Deployment süreçlerinde ssh queuesu yerine ssh-unique queuesunu kullanıyor. Buradaki limitleri artırmadım fakat deployment sırasında da backup alıyorsanız o zaman bunu artırmakta fayda var. Çünkü deployment timeout’larında queue’daki job sonlandırıldığından timeout’u aldığınız son komuttan sonrasına geçmiyor.

Umarım bir gün birilerinin işine yarar 🙂

Vito Extended SSH Timeouts Paketini İncele
tarihinde yayınlandı tarafından — 1 Yorum

Brew ile PHP Memcached Kurulumu

Merhabalar arkadaşlar,

Aslında bu yazı bir nevi kendime bir not. Brew ile PHP kurulumu yaptıktan sonra memcached eklentisini kurarken ne yazık ki bir hata alıyoruz.

Bash
pecl install memcached

Bu kurulum sırasında bir kaç soru promptu ile karşılaşıyoruz. Hepsine enter enter tıklamak ne yazık ki bu kurulumun hata vermesine sebep oluyor. Dip not, ben m3 işlemcili macbook kullanıyorum, dizinler farklı olabiliyor intel işlemcili macbook’larda. Bu prompt’larda aşağıdaki promptta duralım:

Bash
zlib directory [no] :

Bunu gördüğümüz anda zlib dizinimizi elle yazdırmamız gerekiyor:

Bash
zlib directory [no] : /opt/homebrew/opt/zlib

Artık kurulum sağlıklı bir şekilde tamamlanacak. Eğer bu dizini elle girmezseniz ne yazık ki kurulum sırasında aşağıdaki hata alınıyor:

Bash
checking whether to use system zstd library... no
checking for ZLIB... yes, shared
checking for pkg-config... /opt/homebrew/bin/pkg-config
checking for zlib location... configure: error: memcached support requires ZLIB. Use --with-zlib-dir=<DIR> to specify the prefix where ZLIB headers and library are located
ERROR: `/private/tmp/pear/temp/memcached/configure --with-php-config=/opt/homebrew/opt/php/bin/php-config --with-libmemcached-dir=no --with-zlib-dir=no --with-system-fastlz=no --enable-memcached-igbinary=no --enable-memcached-msgpack=no --enable-memcached-json=no --enable-memcached-protocol=no --enable-memcached-sasl=yes --enable-memcached-session=yes' failed

Faydası olur mu bilmem, kendime not alıyorum 🙂

tarihinde yayınlandı tarafından — Yorum yapın

MacOS’de Memcached Memory Değerini Artırma

Merhabalar,

MacOS’de brew install memcached ile memcached’i kurduğunuzda Memcached varsayılan olarak 64MB bellek ile çalışıyor. Eğer memcached kurulumu ile ilgili problem yaşarsanız daha önce yazdığım Brew ile PHP Memcached Kurulumu yazıma da bir göz atabilirsiniz. Normalde memcached’i durdururduk ve memcached -m 128 ... ile istediğimiz bellek miktarı ile hızlıca başlatırdık. Fakat brew service’lerini kendi kontrol ediyor. Önce brew servislerini listelemeyi denedim, orada servis ayar dosyasının konumunu listeliyordu çünkü.

Bash
brew services list

Bu komut şu çıktıyı veriyor:

Harika, mac’in arkaplan servis dosyası bu. Hemen o dosyayı açıp düzenlemeyi denedim:

Bash
vi ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist

Dosyanın şöyle bir içeriği var:

XML
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>homebrew.mxcl.memcached</string>
	<key>LimitLoadToSessionType</key>
	<array>
		<string>Aqua</string>
		<string>Background</string>
		<string>LoginWindow</string>
		<string>StandardIO</string>
		<string>System</string>
	</array>
	<key>ProgramArguments</key>
	<array>
		<string>/opt/homebrew/opt/memcached/bin/memcached</string>
		<string>-m</string>
		<string>512</string>
		<string>-l</string>
		<string>localhost</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>WorkingDirectory</key>
	<string>/opt/homebrew</string>
</dict>
</plist>

Burada <string>/opt/homebrew/opt/memcached/bin/memcached</string> satırından sonra şu satırları ekliyorum:

XML
		<string>-m</string>
		<string>512</string>

Bu şekilde kaydettikten sonra hemen brew services restart memcached çalıştırıyorum. O da ne!? Brew otomatik olarak benim değişikliğimi geri alıyor. Hmmm, demek ki bir yerden bu dosyanın içeriğini referans alıyor ve restart sürecinde burayı referans içerikle güncelliyordu.

Bunun için ufak bir arama taramadan sonra şu dizinde bu dosyayı buluyorum: /opt/homebrew/opt/memcached/homebrew.mxcl.memcached.plist

Yukarıda yaptığım değişikliği burada yaptım, tekrar yeniden başlattığımda artık 512MB belleğe sahip bir memcached buluyorum ellerimde. Yukarıdaki dizin apple işlemcili mac’lerde geçerlidir, intel işlemcili mac’lerin dizini farklı, onu bilmiyorum, google’dan veya yapay zekadan öğrenebilirsiniz.

Benzer yöntemle tüm servisleri farklı parametrelerle çalıştırabilirsiniz.

Kolay gelsin,

tarihinde yayınlandı tarafından — Yorum yapın

Scribe Laravel API Dökümantasyonu İçin Geliştirdiğim Auth Middleware Kütüphanesi

Merhaba arkadaşlar,

İlk API servisi geliştirmeye başladığım zaman, tabii tecrübesizim de, neyi nasıl yapmalıyım diye ciddi bir çalışma içerisindeyim. Her şeyi inceliyorum, standartları nelerdir, HTTP 201 yanıtını nedir, ne zaman dönülmeli gib gibi ciddi bir çalışma içerisindeyim. Laravel zaten bu konunda işin standartlarını benim yerime yapıyor ki bu harika.

Fakat bu end-pointleri front-end tarafında geliştirme yapan arkadaşla nasıl paylaşacağım sorunuyla karşılaştım ve adeta duvara çarptım. İlk başta slack üzerinden paylaşıyorum mesajla ama bu çok uzun sürmedi. Çünkü mesajlaşarak olacak gibi değil. Arkasından ben kendim end-pointleri, hangisinin ne işe yaradığını, hangi body ve query parametrelerinin gerekli olduğunu vs. elle yazmaya başladım. Fakat bu da gerçekten olacak gibi değildi. O kadar çok sıkıldım ki iki kelime yazmaya üşenir oldum.

Sonunda bunun için bir çözüm üretilmiştir eminim ki diyerek API dökümantasyonu için paket araştırmaya niyetlendim. Yukarıdaki süreç çok uzun sürmüş gibi hissettirebilir fakat 3-5 gün sürmedi paket arayışına geçmem.

O dönem bir kaç paket inceledim ve içime en çok sinen paket Scribe olmuştur. Kullanmaya başlar başlamaz da iyikim oldu. Bir kaç yıldır kullanıyorum ve %95 tüm ihtiyaçlarımı çok iyi bir şekilde karşıladı. Geçen sene geliştiricilerden dökümantasyon end-pointim için bir password protection istemiştim. Yani dökümantasyon end-pointim herkes tarafından erişilebilir olmasın, bu durum beni ufaktan rahatsız etmeye başlamıştı. Bunu kendin implement edebilirsin demişti.

Aradan geçen bir yılın sonunda bunun için bir yardımcı kütüphane paketledim. Bu kütüphaneyi Github üzerinden inceleyebilirsiniz: oralunal/scribe-auth

Kütüphane kısaca scribe dökümantasyonu için bir middleware oluşturuyor ve bu middleware’i scribe.php config dosyasında tanım, dökümantasyona erişmeye çalıştığınız zaman sizden bir şifre talep ediyor. İşleyişi basit, kullanımı basit ve entegrasyonu basit. Umarım bu paketle dökümantasyon end-pointinizin kısmi güvenliğini sağlayabiliriz.

Şu anda daha fazla geliştirir miyim emin değilim fakat geliştirirsem yetkilendirme yöntemine statik bir şifre ile yapmak yerine buraya alternatif olarak User model’ini de dahil etmeye niyetleniyorum. Bir ara sanırım hazırlayacağım.

Eğer talep olursa Laravel projelerinizin API end-pointleri için nasıl dökümantasyonlar hazırlayacağınızla ilgili bir video hazırlayabilirim. Bu yazıya 150.000 like gelirse, hahahha 😀

Kütüphaneyi İncele ve İndir
tarihinde yayınlandı tarafından — Yorum yapın

PHPStorm’un Route::prefix Metodu İçin Protected Uyarısı

Bu artık var olan bir sorun değil.

Bir kaç ay önce çıkmaya başladı, sanırım bir güncellemeden sonra bozdular ya da olması gerektiği gibi yaptılar diyebilirim. Bilemedim. Laravel’de Route’larınızı bir prefix altında gruplamak istediğimizde karşılaşıyoruz bu hatayla. Senaryomuz şu şekilde:

PHP
    Route::prefix('/me')->name('me.')->middleware('auth:sanctum')->controller(MeController::class)->group(function () {
        Route::get('', 'show')->name('show');
    });

Bu şekilde kullanımda hiç bir problem yok fakat PHPStorm inatla prefix’in altını çiziyor ve şu uyarıyı veriyor:

Member has protected visibility but can be accessed via ‘__callStatic’ magic method

Bu şekilde warning’leri görmek tabii benim tansiyonu oldukça düşürüyor. Ne zaman hayatımıza dahil oldu tam bilmiyorum fakat korkulacak bir şey yok diyebilirim. Uyarının sebebi ise Router sınıfında prefix metodunun protected olarak yer alıyor olması. Hal böyle olunca dışarıdan prefix metodunu çağırdığımızda Router sınıfındaki __call metodu bu görevi üstleniyor ve RouteRegistrar sınıfında attribute metodu ile hallediyor işini. Laravel Idea‘nın bu konuya en kısa sürede bir çözüm üreteceğine inancım sonsuz, gerçekten bu uyarıları görmeyi sevmiyorum, takıntılıyım diyim, siz anlayın.

Güncelleme (12 Mayıs 2025): Laravel Idea 10.2 güncellemesi ile bu sorun giderildi.

tarihinde yayınlandı tarafından — Yorum yapın

MySQL Kullanılan Projede ‘schema:dump –prune’ Sonrasında Test’lerin SQLite İle Çalışmaması

Merhaba arkadaşlar,

Bugün Laravel ile geliştirdiğim backend api servisinde ilginç bir durum ile karşılaştım. Bu hatayı tanımlamam gerekirse:

  • Üzerinde çalıştığım projede yüzlerce migration dosyası oluşmaya başladı. Her yeni migration oluşturduğumda database dizini altında yeni oluşturduğum migration dosyasına kaydırmaktan iyice bıkkınlık gelmişti.
  • Bunun için buradan görebileceğiniz üzere migrationları silip bir dump dosyası oluşturdum. Projemde MySQL kullanıyorum.
Bash
# Mevcut veritabanının bir dumpını oluşturur ve migration'ların hepsini temizler.
php artisan schema:dump --prune
  • Bu işlem sonrası migrations dizini uçuyor ve yerime schema isimli yeni bir dizin geliyor. İçerisinde de mysql kullandığım için mysql-schema.sql isimli bir dosya oluşuyor. Buraya kadar her şey harika.

Buraya kadar her şey güzel. Artık daha sade ve temiz bir database dizinim var. Fakat problem testlerimin çalışmasında başlıyor. Testlerimde her zaman veritabanını sıfırlıyorum:

PHP
<?php

use Illuminate\Foundation\Testing\RefreshDatabase;

uses(RefreshDatabase::class);

Evet, ben de Pest kullanıyorum. Test içinse veritabanı olarak olarak SQLite kullanıyorum. Bağlantımda :memory: olarak ayarlı. Problem burada başlıyor. Migration’larımızı sildiğimiz için ve veritabanı dumpımız mysql olduğu sqlite ile veritabanı oluşturulamıyor. Test sonuçlarımda düzenli olarak users tablosu bulunamadı hatası alıyorum. Ufak bir çakallık deneyip mysql-schema.sql dosyamın adını sqlite-schema.sql olarak değiştirsem yedirir miyim diye bir düşündüm, düşükte olsa umut fakirin ekmeğiydi ama tabii ki olmadı 🙂

Bunun için çözümler üretmeye çalışırken mysql dump dosyasını sqlite dumpa dönüştürmek aklıma geldi. Bunun için github’da dumblob/mysql2sqlite reposunu keşfettim. Bu toolu kullanarak mevcut mysql dumpımdan sqlite dump oluşturdum. Bu repodan mysql2sqlite dosyasını projemin ana dizininde oluşturdum ve sonrasında şu komutu çalıştırdım:

Bash
./mysql2sqlite database/schema/mysql-schema.sql > database/schema/sqlite-schema.sql

Voila! sqlite-schema.sql dosyam schema klasörünün altında oluşmuştu. Tabii şimdi test etmeye geldi.

Bash
php artisan test

Artık sağlıklı bir şekilde sqlite-schema.sql dosyasını sağlıklı bir şekilde kullanarak veritabanımı sıfırlayabiliyorum.

Umarım birinize ilaç olabilecek bir yaklaşım sunmuşumdur. Bu yazıyı yazarken neden şu konuları da açıklamam gerektiğini hissettim, bir ara bunlara da değineceğim, kendime not olması açısından:

  • Test nedir? PHPUnit ve Pest nedir?
  • Neden test yazmalıyız?
  • Neden testlerimizde sqlite kullanmalıyız ya da kullanmak zorunda mıyız?

Ölmez sağ kalır isek bir ara yazarız 🙂 Kalın sağlıcakla.

tarihinde yayınlandı tarafından — Yorum yapın

PhpStorm 2024.1 Güncellemesiyle Gelen Yapışkan Satırlar

Son bir kaç gündür IDE’de bir problem yaşıyorum. Tepede kapsayıcı elemanların önizlemesini gösteriyor. Böyle deyince tam anlaşılmadı ama PHP’de bir metot içerisinde kod yazarken hangi metotta olduğunuzu ve hatta hangi sınıf içerisinde yer aldığınızı görmenizi sağlayan bir önizleme. Görüntünün nasıl olduğunu daha detaylı aşağıdaki resimde görebilirsiniz:

Satır sayılarına bakarsanız ne demek istediğimi tam olarak görebilirsiniz.

Ayıptır söylemesi yakın zaman önce Macbook Pro aldım. Geçenlerde de Option tuşu ile farklı tuşlara basarak garip garip karakterler ortaya çıktığını farkettim. Örneğin option + j ikilisine basınca ∆ bu işaret geliyor, option + shift + v üçlüsüne basınca ◊ bu işaret geliyor gibi gibi. Bu simgeleri gözlemlemeye çalışırken istemeden bir kısayolu mu tetikledim acaba diye düşündüm. Fakat öyle değilmiş.

Sonra Settings’i açıp ayarları teker teker incelerken buldum bu özelliği. PhpStorm 2024.1 güncellemesi ile gelen ve default olarak açık olan bir özellikmiş. “Sticky Lines”. Settings -> Editor -> General -> Appearance altında bu ayarı bulabilirsiniz.

Benim gibi alışkanlarını hızlı terk edemeyenler için böyle özellikler çok fazla olabiliyor. jetbrains default olarak kapalı getirmeli böyle bir özelliği bence.

Jetbrains sticky lines tanımını şöyle yapıyor:

Sticky lines (yapışkan satırlar) veya sticky scroll özelliği, dosya içinde kaydırma yaparken üst elemanların görünürlüğünü koruyarak kodlama deneyiminizi geliştirir ve kodunuza hemen bağlam sağlar.

Ayrıca, herhangi bir yapışkan satıra tıklayarak düzenleyicide ilgili tanıma kaydırabilirsiniz.

jetbrains
tarihinde yayınlandı tarafından — Yorum yapın

Laravel’de URL Parametrelerinin Doğrulanması

Laravel, form verilerinin doğrulanmasını kolaylaştıran güçlü ve esnek bir doğrulama sistemine sahiptir. Ancak, bazen URL parametrelerini veya “route” parametrelerini doğrulamanız gerekebilir. Laravel, FormRequest sınıfları ile bu tür senaryoları kolaylıkla işleyebilir.

FormRequest Sınıflarının Kullanılması

Laravel’de HTTP requestlerinin doğrulanması genellikle bir FormRequest sınıfı ile yapılır. Bu, tüm doğrulama kurallarını ve yetkilendirme mantığını tek bir yerde toplamanıza izin verir.

Bir FormRequest sınıfı oluşturmak için Laravel’in artisan komutunu kullanabilirsiniz:

Bash
php artisan make:request VerifyUserRequest

Bu komut, app/Http/Requests/VerifyUserRequest.php adlı yeni bir dosya oluşturur. Bu dosyada iki ana metod bulunur: authorize ve rules.

  • authorize metodunda, isteği yapan kullanıcının bu isteği yapma yetkisi olup olmadığı kontrol edilir.
  • rules metodunda, request verilerinin karşılaması gereken doğrulama kuralları belirlenir.

URL Parametrelerini Doğrulama

Eğer bir URL şu şekildeyse: https://example.com/verify/{id}/{hash}, ve istemcinin bu endpoint’e id ve hash parametrelerini sağlaması gerekiyorsa, bu parametreleri FormRequest sınıfı ile doğrulayabiliriz.

Öncelikle, route tanımımızı belirtelim:

PHP
Route::get('/verify/{id}/{hash}', 'VerificationController@verify')->name('verify')->where('id', '[0-9]+');

Ardından, VerifyUserRequest sınıfımızda rules metodunu aşağıdaki gibi tanımlayabiliriz:

PHP
public function rules()
{
    return [
        'id' => 'required|integer|exists:users,id',
        'hash' => 'required|string',
    ];
}

Bununla birlikte, Laravel bu parametreleri doğrulayabilmek için URL’den gelen parametrelerin ve request verilerinin birleşimini kullanmalıdır. Laravel, varsayılan olarak yalnızca request verilerini doğrular. Bu nedenle, URL’den gelen parametrelerin doğrulanmasını sağlamak için, validationData metodunu FormRequest sınıfımıza eklemeliyiz:

PHP
public function validationData()
{
    return array_merge($this->route()->parameters(), $this->all());
}

Bu metod, route parametrelerini ve request verilerini birleştirir. Artık Laravel, id ve hash parametrelerini URL’den çeker ve belirlediğimiz doğrulama kurallarını uygular. Sonuç olarak, FormRequest sınıfı, route parametrelerini doğrulama ihtiyacımız olduğunda da oldukça kullanışlıdır. Doğru şekilde kullanıldığında, form verilerini ve URL parametrelerini doğrulama işlemlerimizi tek bir yerde organize edebiliriz.

Umuyorum ki bu rehber, Laravel ile URL parametrelerini nasıl doğrulayacağınıza dair size yardımcı olmuştur.

tarihinde yayınlandı tarafından — Yorum yapın

Laravel’da Foreign Key’ler İçeren Bileşik İndeksler Nasıl Kaldırılır?

Bir Laravel geliştiricisi olarak, veritabanı tabloları arasındaki ilişkileri yönetirken foreign key’ler ve indekslerle sıklıkla karşılaşıyoruzdur. Ancak, bileşik bir indeks oluştururken foreign key’leri içermesi durumunda bazı zorluklar yaşanabilir. Bu yazıda, Laravel’da foreign key’ler içeren bir bileşik indeksi nasıl kaldıracağımızı göreceğiz.

Bileşik indeksler birden çok kolonda oluşturulan indekslerdir ve genellikle veritabanı sorgularının performansını artırmak için kullanılırlar. Bununla birlikte, foreign key’lerle birlikte kullanıldıklarında bazen karışık durumlar ortaya çıkabilir.

Örneğin, contact_tags adlı bir tablomuz olsun ve bu tabloda tag_id ve contact_id adında iki foreign key’imiz olsun. Bu iki sütunu içeren bir bileşik indeks oluşturduk (tag_contact_unique adlı). Ancak, bu indeksi kaldırmak istediğimizde bir problemle karşılaşıyoruz.

İşte bu problemi çözmenin bir yolunu aşağıda bulabilirsiniz:

PHP
public function down() {
    Schema::table('contact_tags', function (Blueprint $table) {
        // Bu biraz garip gelebilir, ancak öncelikle eksik indeksleri eklememiz gerekiyor:
        $table->index('tag_id', 'tag_id_foreign');
        $table->index('contact_id', 'contact_id_foreign');
        // Şimdi bu "down" komutunun ana kısmına geçerek benzersiz indeksi kaldırabiliriz:
        $table->dropUnique('tag_contact_unique');
    });
}

Bu kodda neler olduğuna bir göz atalım:

  1. Öncelikle, tag_id ve contact_id sütunlarına indeks ekliyoruz. Burada dikkat edilmesi gereken önemli nokta, indeks isimlerinin foreign key isimleriyle aynı olması gerektiğidir. Bu, Laravel’in foreign key’leri ve indeksleri birbirinden ayırt etmesine yardımcı olur.
  2. Ardından, tag_contact_unique adındaki bileşik indeksi kaldırıyoruz. Bu, tag_id ve contact_id sütunlarında oluşturduğumuz benzersiz bileşik indeksi kaldırır.

Sonuç olarak, foreign key’ler içeren bir bileşik indeksi kaldırmak için bu yöntemi kullanabiliriz.

tarihinde yayınlandı tarafından — 2 Yorum

Class “finfo” not found

Laravel kullanmaya bu kadar geç kaldığım için duyduğum pişmanlığı tarif etmeme sanırım gerek yok. Üzerinde çalıştırdığım projede kullanıcıların gravatar üzerinde bir avatarı varsa bunu lokal olarak saklamak istiyorum. İlk defa dosya işlemleri yapacağım için tabii ki hemen dökümantasyonda File Storage sayfasını açtım, başladım incelemeye. “public” olarak saklamak mantıklı geldi ve web üzerinden erişilmesi için bir de symbolic linkini oluşturdum. Her şey mükemmel.

İlk resmimi aşağıdaki şekilde kaydetmeye çalıştım:

use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Facades\Http;

$avatar = Http::get('https://gravatar.com/blablabla');
if($avatar->status() == 200) 
     Storage::disk('public')->put('resim.png', $avatar->body());

ve zınk hata ile karşılaştım. Karşılaştığım hata şöyleydi:

Class “finfo” not found

Ne alaka diye düşündüm, sonuçta Laravel kullanıyorum, her şey nizami, neden hata verir, bu kütüphanede mi problem var falan filan… Bu sorular aklımda deliler gibi oradan oraya çarparken googlelayınca bunun bir PHP uzantısı olduğunu gördüm. Bu hatanın Laravel’le hiçbir alakası yokmuş.

Çözüm

PHP uzantısı php_fileinfo php.ini dosyasında aktif edilmelidir. cPanel kullanıcıları buraya tıklayarak cPanel’de bu sorunun nasıl çözüleceğini okuyabilirler.