Sık sorulan sorular¶
Bu SSS, açık ve kapalı MRBS destek issue'larında tekrarlanan soruları özetler. Yanıtlar MRBS 1.12.2 için doğrulanmıştır; eski bir geçici çözüm yalnızca bir issue'da geçmiş olması nedeniyle eklenmez.
Bu SSS nasıl seçildi?¶
İnceleme şu etiketlerden en az birini taşıyan sorunları kapsıyordu: Help, Help from scratch, LDAP help need, Problems with room's capacity, support, spanish help, support request, help wanted, ve custom view help.
26 Temmuz 2026'da yalnızca support request etiketi 3.076 issue içeriyordu: 1.590'ı açık ve 1.486'sı kapalı. Birçoğu içe aktarılmış geçmiş vakalar, tek seferlik özelleştirmeler, özellik istekleri veya onaylanmış yanıtı olmayan sorulardır. Aşağıda yalnızca yanıtı 1.12.2 için hala yararlı olan yinelenen sorular yer almaktadır. Sorun bağlantıları, geçerli yapılandırma referansının yerine geçmez, kaynak sağlar.
Kurulum ve teşhis¶
Neden boş bir sayfa veya HTTP 500 görüyorum?¶
Önce web sunucusunu ve PHP hata günlüklerini okuyun. Boş bir sayfa yalnızca görünür belirtidir; yararlı hata normalde bir günlükte bulunur. Ardından şunları kontrol edin:
- desteklenen PHP sürümü ve gerekli uzantılar;
config.inc.phpilephp -l config.inc.php;- veritabanı bağlantısı ve eşleşen PDO sürücüsü;
- dosya izinleri ve etkin PHP yapılandırması; ve
- başarısız olan isteğin amaçlanan MRBS kurulumuna ulaşıp ulaşmadığı.
Bir üretim sisteminde genel PHP hata görüntülemeyi etkinleştirmeyin ve kimlik bilgilerini bir soruna yapıştırmayın. Bakınız Sorun giderme. Orijinal destek vakası #1007'de ürüne özel onaylanmış bir düzeltme yoktu, bu nedenle bu yanıt yerel günlüklerden elde edilen kanıtlarla başlıyor.
Veritabanına giriş cPanel'de veya paylaşılan barındırmada neden başarısız oluyor?¶
Barındırma kontrol paneli tarafından oluşturulan veritabanını ve kullanıcı adını tam olarak kullanın. cPanel genellikle her ikisine de barındırma hesabı adının önüne eklenir. Ayrıca kullanıcının bu veritabanında ayrıcalıklara sahip olduğunu doğrulayın. SQLSTATE[28000] veya "Kullanıcı için erişim reddedildi", bir MRBS tablo hatası değil, bir veritabanı kimlik doğrulama veya izin hatasıdır.
$db_database, $db_login ve $db_password değerlerini kontrol paneli değerleriyle tutarlı tutun. Şemayı yalnızca bağlantı başarılı olduktan sonra oluşturun. Bkz. issue #3801 ve Kurulum.
Yapılandırma değişikliğinin neden hiçbir etkisi olmuyor?¶
Bu dağıtım ve site tarafından yüklenen config.inc.php dosyasını düzenlediğinizi kontrol edin. Daha sonra atanan değerler daha önceki değerleri geçersiz kılar. Mevcut alanlar için kaydedilen ayarlar veritabanında bulunur; areadefaults.inc.php'yi değiştirmek yalnızca yeni alanlar için varsayılanları değiştirir. Çoklu saha modunda seçilen sahayı ve konfigürasyonunu onaylayın. Son olarak, uygun olduğu yerde PHP opcode önbelleğe almayı temizleyin veya yeniden başlatın.
Bkz. config.inc.php derinlemesine ve Sorun giderme.
Giriş yapın ve LDAP¶
Kullanıcıların takvimi görmeden önce oturum açmasını nasıl zorunlu kılabilirim?¶
Ayarla:
Oturum kapalı görünümünü özel bir tarayıcı penceresinde test edin. Bu ayar genel takvim erişimini engeller; kimlik doğrulama arka ucunu seçmez veya yapılandırmaz. Bkz. issue #3979 ve Kullanıcılar ve izinler.
MRBS neden PHP LDAP uzantısının eksik olduğunu söylüyor?¶
Web sunucusunun kullandığı PHP ortamında LDAP uzantısını yükleyin veya etkinleştirin, ardından bu ortamı yeniden başlatın. Komut satırındaki PHP ile web sunucusundaki PHP farklı php.ini dosyaları yükleyebilir; bu nedenle yalnızca php -m sonucuna güvenmeyip web ortamını kontrol edin. Paketin tam adı ve yeniden başlatma komutu işletim sistemine ve PHP kurulumuna bağlıdır.
Bkz. issue #1022 ve LDAP ile kimlik doğrulama.
Doğru LDAP temel DN'yi ve kullanıcı DN'sini nasıl bulabilirim?¶
Dizin ağacını bir kuruluş adından çıkarmayın. MRBS'nin kullanacağı aynı sunucuyu, TLS modunu, temel DN'yi, arama kimliğini ve kullanıcı adı özelliğini kullanarak, ldapsearch gibi bir LDAP istemcisiyle sorgulayın. Active Directory genellikle sAMAccountName'yi kullanır; OpenLDAP genellikle uid kullanır, ancak dizin şeması yetkilidir.
Arama kimliğini son kullanıcı bağlamasından ayrı olarak test edin ve bağlama parolalarını asla yayınlamayın. issue #1083'nın temel nedeni yanlış DN idi.
LDAP erişim bir grupla nasıl sınırlandırılabilir?¶
Kullanıcıların hangi dizine erişebileceğine karar vermek için $ldap_filter tuşunu kullanın MRBS. Üyeliğin kullanıcı nesnesinde saklandığı bir Active Directory düzeni için bir filtre memberof ile eşleşebilir. Üyeliğin grup nesnelerinde depolandığı OpenLDAP tarzı bir düzen için $ldap_filter_base_dn, $ldap_filter_user_attr ve uygun bir $ldap_filter öğesini yapılandırın.
Dizindeki tam DN'yi ve öznitelik adlarını kullanın; izin verilen ve reddedilen hesaplarla iç içe grupların davranışını test edin. Bu erişim filtreleri, MRBS yöneticilerini tanımlayan $ldap_admin_group_dn ayarından ayrıdır. Bkz. issue #2033 ve LDAP ile kimlik doğrulama.
LDAP giriş çalışmaları; kullanıcı neden MRBS yönetici değil?¶
$ldap_admin_group_dn ayarlandığında, MRBS, $auth['admin'] yerine bu grubu kullanır. Onaylamak:
- tam grup DN'si;
$ldap_group_member_attrib—memberofvarsayılan olarak;- LDAP arama kimliğinin kullanıcının üyelik özelliklerini okuyabileceğini; Ve
- dizinin doğrudan mı yoksa iç içe üyelik mi döndürdüğü.
LDAP tanılamalarını yalnızca korumalı bir test ortamında geçici olarak etkinleştirin ve daha sonra kaldırın. issue #3943'da, arama kimliği başlangıçta gerekli grup bilgilerini okuyamadı.
Parola bağlama çalışmasına rağmen MRBS yükseltmesinden sonra neden LDAP başarısız olabiliyor?¶
Mevcut MRBS'nin bir kullanıcının DN'sini ve görünen ad veya e-posta gibi nitelikleri araması gerekebilir. Anonim arama kullanılamıyorsa şunları yapılandırın:
$ldap_dn_search_attrib = 'sAMAccountName'; // use the directory's real attribute
$ldap_dn_search_dn = 'search-account@example.org';
$ldap_dn_search_password = 'read-from-a-protected-secret';
Arama kimliğine yalnızca ihtiyaç duyduğu okuma izinlerini verin. Parolasını belge kökünün dışında tutun ve korumalı bir yapılandırma dosyasından ekleyin. Bakınız issue #3895.
MRBS birden fazla LDAP dizininde arama yapabilir mi?¶
Evet. $ldap_host, $ldap_port, $ldap_base_dn ve arama nitelikleri dahil olmak üzere birçok LDAP ayarı dizi olabilir. Dizi özellikli bir LDAP parametresi bir diziyse, dizi özellikli her parametre, dizin başına bir tane olmak üzere aynı sayıda öğeye sahip olmalıdır.
Her dizin için oturum açmayı, özellik aramayı, erişim filtrelerini ve yönetici eşlemesini test edin. issue #3981 ve systemdefaults.inc.php'deki LDAP bölümüne bakın.
Rezervasyonlar, odalar ve izinler¶
Özel bir ayırma alanı neden bir ayırma için çalışıyor ancak bir seri için başarısız oluyor?¶
Her özel ayırma sütunu, hem entry hem de repeat tablolarında aynı ad, tür, uzunluk, null değeri ve varsayılan değerle bulunmalıdır. Her iki sütuna da tek bir şema değişikliği gibi davranın.
Bkz. issue #3986 ve Özel alanlar.
Oda kapasitesi çok katılımcılı rezervasyona engel olur mu?¶
Hayır. Oda capacity değeri, MRBS tarafından görüntülenen oda meta verileridir; bir rezervasyonun katılımcı sayısıyla otomatik olarak karşılaştırılmaz. Bir sitenin bu kuralı uygulaması gerekiyorsa, entry ve repeat'ye aynı katılımcı sayısı özel alanını ekleyin, ardından sunucu tarafı doğrulamayı uygulayın ve sürdürün. İstemci tarafı doğrulaması tek başına yeterli değildir.
Kayıt etkinleştirilirse etkinlik kapasitesi, söz konusu etkinliğe ilişkin kaydı kontrol eder; otomatik olarak uygun büyüklükteki bir odayı seçmez. Bkz. issue #1055, Alanlar ve odalar ve Özel alanlar.
Bir bölge sabah 30 dakikalık, daha sonra ise 15 dakikalık slotları kullanabilir mi?¶
Standart alan konfigürasyonu aracılığıyla değil. Bir alanın tek seferlik çözünürlüğü vardır. Tüm gün boyunca gereken en küçük çözünürlüğü kullanın veya kaynaklar ve işletim modeli izin verdiğinde ayrı alanlar oluşturun. Zamana bağlı bir çözüm, bakımlı bir kod özelleştirmesi gerektirir.
Bakınız issue #4011.
Rezervasyon yaratıcısı neden Düzenle veya Sil'i göremiyor?¶
Mevcut bölgenin rezervasyon politikasını Salonlar aracılığıyla kontrol edin. Geçmiş rezervasyonlara ilişkin ileri/gelecekteki düzenleme sınırları ve kuralları, bu eylemleri yaratıcının bile kaldırabilmesine neden olabilir. Ayrıca oturum açan kimliği, sahipliği, yönetici durumunu ve öğenin tek bir örnek mi yoksa bir seri mi olduğunu doğrulayın.
areadefaults.inc.php öğesinin değiştirilmesi mevcut bir alanı güncellemez. Bkz. issue #3994 ve Rezervasyon politikaları.
Çok odalı bir rezervasyonda seçilen odalar kalıcı olarak bağlantılı mı?¶
No. MRBS ayrı rezervasyon girişleri oluşturur. Biri daha sonra düzenlenir veya silinirse diğerleri kalıcı, bağlantılı bir grup değildir. Site aynı zamanda oluşturma, düzenleme ve silme işlemleri boyunca bu listeyi muhafaza etmediği sürece, seçilen tüm odaların oluşturulmuş listesini her açıklamaya kopyalamayın.
Bakınız issue #2223.
Daha fazla erişim düzeyi ekleyebilir miyim veya özel bir role yalnızca rapor erişimi verebilir miyim?¶
Standart MRBS, 0, 1 ve 2 erişim düzeylerini kullanır. Ek sayısal roller ve sayfaya özel izinler, her yükseltmeden sonra yerel yetkilendirme özelleştirmesi, testler ve inceleme gerektirir. Eski bir soruna ait yama, desteklenen bir yapılandırma seçeneği değildir.
Gereksinimi karşıladıklarında standart alan/oda yetkilendirmesini ve dar izin verilenler listesine sahip genel raporları tercih edin. Bkz. issue #3999 ve Kullanıcılar ve izinler.
E-posta, dil ve saat¶
E-posta hata ayıklaması neden "Alıcı yok" raporunu veriyor?¶
En az bir amaçlanan alıcı rolünü etkinleştirin:
$mail_settings['admin_on_bookings'] = true;
$mail_settings['area_admin_on_bookings'] = true;
$mail_settings['room_admin_on_bookings'] = true;
$mail_settings['booker'] = true;
İlk seçenek için $mail_settings['recipients'] değerini ayarlayın. Alan ve oda yöneticilerinin e-posta adreslerini MRBS'de tutun. LDAP Kullanıcıların, rezervasyon yapan kişiye bildirimde bulunulduğunda okunabilir ve doğru şekilde eşlenmiş bir e-posta özelliğine ihtiyacı vardır. Daha sonra etkinlikleri ayrı ayrı oluşturmayı, düzenlemeyi ve silmeyi test edin.
Bkz. issue #3795 ve E-posta bildirimleri.
$override_locale için hangi değeri kullanmalıyım?¶
İşletim sistemi yerel ayar dizesi değil, en, en-GB, de, fr veya es gibi bir BCP 47 dil etiketi kullanın. Sunucunun hâlâ uygun yerel ayar verilerine sahip olması gerekir. Unix benzeri sistemlerde locale -a yüklü yerel ayarları gösterir.
MRBS otomatik seçimi kullanmak için $override_locale alanını boş bırakın. Bkz. issue #3984 ve Metin ve çeviriler.
Görüntülenen saatler neden tam olarak bir saat yanlış gösteriliyor?¶
Sırayla kontrol edin:
- oda ve alanın saat dilimi;
- küresel
$timezone; - PHP'nin saat dilimi ve saat dilimi veri paketi;
- etkilenen tarihin yaz saati uygulamasına geçişi; ve
- saklanan zaman damgasının mı yoksa yalnızca gösteriminin mi yanlış olduğu.
Sabit bir UTC farkı değil, Europe/Berlin gibi bir IANA saat dilimi kullanın. Eski sayılarda sürüme özel biçimlendirme geçici çözümlerinden bahsediliyor; $force_strftime, MRBS 1.12.2'deki bir ayar değildir ve issue #3967'den kopyalanmamalıdır. Bakınız Sorun giderme.
Yardım sayfasını ve arayüz metnini nasıl kişiselleştirebilirim veya çevirebilirim?¶
Uygulama içi Yardım sayfası web/site_faq/ adresinden yüklenir. Örneğin İspanyolcada site_faq_es.html kullanılır; Dilin açıkça seçilmesi gerektiğinde $faqfilelang = 'es' ayarını yapın. Desteklenen her dil için eksiksiz bir çevrilmiş dosya tutun.
Kısa arayüz değişiklikleri için web/lang/lang.*'yi düzenlemek yerine config.inc.php'de $vocab_override[LANG][TOKEN] kullanın. Özel veritabanı alanları entry.catering gibi belirteçler kullanır.
Bkz. issue #2432 ve Metin ve çeviriler.
Raporlar, çoklu site ve özelleştirme¶
Zamanlanmış bir iş, bir raporu veya iCalendar verilerini nasıl dışa aktarabilir?¶
Kimliği doğrulanmamış GET raporları varsayılan olarak devre dışıdır. Bilgilerin bu şekilde açığa çıkması ihtimali varsa, bunları bilinçli olarak etkinleştirin ve aşağıdakilerle sınırlandırın:
$report_unauthenticated_get_enabled = true;
$report_keys_enabled = true;
$report_keys = ['a-long-random-secret'];
$report_open_areas = [1];
$report_open_rooms = [];
Tahmin edilemeyen bir anahtar, dar bir alan/oda izin verilenler listesi, HTTPS ve korumalı bir planlayıcı kullanın. Çıkış yaparken tam çıktıyı test edin. Bir rapor URL'si etkili bir şekilde bir kimlik bilgisidir ve günlükler veya geçmiş aracılığıyla sızabilir.
Bkz. issue #3742 ve Arama ve raporlar.
Birden fazla MRBS site bir tablo grubunu paylaşabilir mi?¶
Hayır, rezervasyonlarının ve ayarlarının ayrı olması gerekiyorsa hayır. Her sitenin, ayrı bir veritabanında veya paylaşılan bir veritabanında benzersiz bir $db_tbl_prefix içeren kendi MRBS tablolarına ihtiyacı vardır. Kod paylaşılabilir ancak tablo kümeleri çakışmamalıdır.
MRBS şema komut dosyalarıyla her sitenin tablolarını oluşturun ve önekini tutarlı bir şekilde uygulayın. Bkz. issue #3917 ve Çok bölgeli.
İstenilen her görünüm veya tema yapılandırma yoluyla mevcut mu?¶
Hayır. Belirli bir takvim düzenine ek oda metni eklenmesi, bağımsız rezervasyonların bağlanması, erişim düzeylerinin eklenmesi veya tema mimarisinin değiştirilmesi gibi talepler kod değişiklikleri gerektirebilir. Bir destek sorunundan yamayı uygulamadan önce:
- 1.12.2'nin zaten bir ayar veya uzatma noktasına sahip olup olmadığını kontrol edin;
- değişikliği oluşturulan ve satıcı dosyalarının dışında tutun;
- oluşturma, düzenleme, silme, gizlilik ve izinler için testler ekleyin; Ve
- Bir sonraki yükseltme için özelleştirmeyi kaydedin.
Örnekler arasında özel görünüm sorunu #2223 ve tema isteği #22 yer alır.