Skip to content

BRAMPP 1.7

Choose a tag to compare

View all tags
@macitkaraca macitkaraca released this 12 Aug 13:04
· 60 commits to main since this release
v1.7
c3cb2d2

Dört düzeltme, dördü de aynı sınıftan: uygulama size bir şeyin olduğunu söylüyor, oysa olmamış. En ciddisi paylaşımda — sildiğiniz sitenin herkese açık adresi ölmüyor, başka bir siteyi yayınlamaya başlıyordu.

Düzeltildi

  • Paylaşımdaki bir alan adını silmek, yeniden adlandırmak ya da devre dışı bırakmak tüneli açık bırakıyordu — ve adres başka bir siteyi yayınlamaya başlıyordu. Tünel 127.0.0.1'e bağlanıp alan adını Host başlığında taşıdığı için, vhost silinince istek hiçbir sunucu bloğuyla eşleşmiyor ve varsayılan vhost'a düşüyordu. Sonuç: rastgele bir trycloudflare.com adresi, kapattığınızı sandığınız hâlde ~/Sites/localhost kökünüzü — /phpmyadmin ve /adminer dahil — internete açıyordu. İstek loopback'ten geldiği için Apache'nin Require local kısıtı da devreye girmiyordu. Yeniden adlandırmada daha da kötüydü: tünel kaydı eski adla saklandığından arayüzdeki rozet "kapalı" görünüyor, çalışan tüneli durdurmanın hiçbir yolu kalmıyordu. Artık vhost'a dokunan üç yolun üçü de önce paylaşımı kapatıyor ve konsola neden kapatıldığını yazıyor.
  • Asistan üzerinden veritabanı geri yükleme, tamamen başarısız bir işi "aktarıldı" diye bildiriyordu. PostgreSQL yolunda ON_ERROR_STOP verilmediği için psql, dökümdeki her ifade hata verse bile sıfırla bitiyordu; hata metni de yutuluyordu. Aynı iş arayüzde yıllardır doğru yapılıyordu — MCP yolu geride kalmıştı. Artık --single-transaction ile birlikte: yarıda kalan bir geri yükleme tamamen geri alınıyor, yeniden deneme yarım veritabanının üstüne yazmıyor.
  • Uygulama logunu "Temizle" ile boşaltmak, o koşu boyunca logu tamamen kaybettiriyordu. Dosya siliniyordu, oysa sarmalayıcının yönlendirmesi süreç başlarken bir kez kurulur: silinen dosyanın yerine yenisi doğmuyor, uygulama görünmez bir dosyaya yazmaya devam ediyordu. Log penceresi kalıcı olarak boş kalıyor, tek çare uygulamayı yeniden başlatmaktı. Artık dosya silinmiyor, içi boşaltılıyor.
  • Devre dışı bırakılan bir PHP uzantısı "kurulu değil" görünüyor ve arayüzden geri açılamıyordu. Kurulu olup olmadığı yalnızca php -m çıktısından çıkarılıyordu; devre dışı bırakma uzantıyı o listeden düşürdüğü için satır kurulmamış sayılıyor, onay kutusunun yerine "Kur" düğmesi geliyordu. Ona basınca da PEAR kaydı hâlâ durduğu için kurulum "zaten kurulu" hatasıyla düşüyordu — uzantıyı Finder'da elle yeniden adlandırmadan geri açmak mümkün değildi.

Ayrıntı: Değişiklikler

Apple Silicon, macOS 14+.

In English

Four fixes, all of one kind: the app told you something had happened when it had not. The worst was in sharing — deleting a site did not kill its public address, it repointed it at a different site.

Fixed

  • Deleting, renaming or disabling a shared domain left the tunnel running — and the address began serving a different site. The tunnel connects to 127.0.0.1 and carries the domain in the Host header, so once the vhost was gone the request matched no server block and fell through to the default one. A random trycloudflare.com address then published ~/Sites/localhost — /phpmyadmin and /adminer included — while you believed you had shut it down. Apache's Require local did not help either, because the request arrives from loopback. Renaming was worse still: the tunnel record kept the old name, so the badge read "off" and there was no way left to stop a running tunnel. All three paths that touch a vhost now close the share first and say in the console why.
  • Restoring a database through the assistant reported a completely failed job as imported. The PostgreSQL path passed no ON_ERROR_STOP, so psql exited zero even when every statement in the dump failed, and the error text was swallowed on the way. The same work has been done correctly in the interface for a long time — the MCP path had fallen behind. It now runs with --single-transaction as well: a restore that breaks midway rolls back entirely, and the retry no longer writes over a half-applied database.
  • Clearing the application log lost that run's log entirely. The file was deleted, but the wrapper's redirection is set up once when the process starts: no new file took its place and the app kept writing into one nothing could open. The log window stayed empty until you restarted the app. The file is now emptied rather than removed.
  • A disabled PHP extension looked "not installed" and could not be switched back on. Installed state was read only from php -m, and disabling drops the extension from that list — so the row fell back to an Install button. Pressing it failed with "already installed", because the PEAR registration was still there. Short of renaming the file by hand in Finder, there was no way back.

Details: Changelog

Apple Silicon, macOS 14+.

Assets 4
Loading