Gyakran ismételt kérdések¶

Ez a GYIK a nyitott és lezárt MRBS-támogatási hibajegyekben visszatérő kérdéseket foglalja össze. A válaszokat az MRBS 1.12.2 alapján ellenőriztük; egy régi kerülő megoldás nem került be pusztán azért, mert egyszer szerepelt egy hibajegyben.

Hogyan választották ki ezt a GYIK-et¶

A felülvizsgálat a következő címkék közül legalább egyet tartalmazó problémákra terjedt ki: Help, Help from scratch, LDAP help need, Problems with room's capacity, support, spanish help, support request, help wanted, és custom view help.

A support request címkéhez 2026. július 26-án 3076 hibajegy tartozott: 1590 nyitott és 1486 lezárt. Sok közülük importált történeti eset, egyszeri testreszabás, funkciókérés vagy megerősített válasz nélküli kérdés. Az alábbiakban csak azok a visszatérő kérdések szerepelnek, amelyek válasza az 1.12.2-es verzióhoz is hasznos. A hibajegyekre mutató hivatkozások a válasz eredetét jelzik, de nem helyettesítik az aktuális konfigurációs dokumentációt.

Telepítés és diagnosztika¶

Miért látok üres oldalt vagy HTTP 500-at?¶

Először olvassa el a webszerver és a PHP hibanaplóit. Az üres oldal csak a látható tünet; az érdemi hibaüzenet általában valamelyik naplóban található. Ezután ellenőrizze:

a támogatott PHP verzió és a szükséges bővítmények;
config.inc.php és php -l config.inc.php;
adatbázis-kapcsolat és a megfelelő PDO illesztőprogram;
fájlengedélyek és az aktív PHP konfiguráció; és
hogy a sikertelen kérés a megfelelő MRBS-telepítést éri-e el.

Ne engedélyezze a nyilvános PHP hibaüzenetet éles rendszeren, és ne illesszen be hitelesítő adatokat a problémába. Lásd: Hibaelhárítás. Az eredeti támogatási eset #1007 nem tartalmazott megerősített termékspecifikus javítást, ezért ez a válasz a helyi naplókból származó bizonyítékokkal kezdődik.

Miért sikertelen az adatbázis-bejelentkezés a cPanel vagy a megosztott tárhelyen?¶

Pontosan a tárhely vezérlőpultján létrehozott adatbázisnevet és felhasználónevet használja. A cPanel gyakran mindkettő elé a tárhelyfiók nevét illeszti. Ellenőrizze azt is, hogy a felhasználó rendelkezik-e jogosultságokkal az adott adatbázishoz. A SQLSTATE[28000] vagy az „Access denied for user” adatbázis-hitelesítési vagy jogosultsági hiba, nem pedig MRBS-táblahiba.

A $db_database, $db_login és $db_password legyen összhangban a vezérlőpult értékeivel. A sémát csak a csatlakozás sikeressége után hozza létre. Lásd: #3801 hibajegy és Telepítés.

Miért nincs hatása a konfiguráció módosításának?¶

Ellenőrizze, hogy az adott telepítés és webhely által betöltött config.inc.php fájlt szerkesztette-e. A később hozzárendelt értékek felülírják a korábbiakat. A meglévő területek beállításai az adatbázisban vannak; az areadefaults.inc.php módosítása csak az új területek alapértékeit változtatja meg. Többwebhelyes módban ellenőrizze a kiválasztott webhelyet és annak konfigurációját. Végül szükség esetén ürítse vagy indítsa újra a PHP bájtkód-gyorsítótárát.

Lásd: config.inc.php részletességgel és Hibaelhárítás.

Bejelentkezés és LDAP¶

Hogyan kérhetem meg a felhasználóktól, hogy jelentkezzenek be, mielőtt látnák a naptárat?¶

Beállítás:

$auth['deny_public_access'] = true;

Tesztelje a kijelentkezett nézetet egy privát böngészőablakban. Ez a beállítás blokkolja a naptár nyilvános elérését; nem választja ki és nem konfigurálja a hitelesítési módot. Lásd: #3979 hibajegy és Felhasználók és engedélyek.

Miért mondja az MRBS, hogy a PHP LDAP kiterjesztés hiányzik?¶

Telepítse vagy engedélyezze az LDAP-bővítményt a webszerver által használt PHP-környezetben, majd indítsa újra ezt a környezetet. A parancssori PHP és a webszerver PHP-je eltérő php.ini fájlokat tölthet be, ezért a webes környezetet ellenőrizze, ne csak a php -m kimenetére hagyatkozzon. A csomag pontos neve és az újraindítási parancs az operációs rendszertől és a PHP telepítésétől függ.

Lásd: #1022 hibajegy és LDAP hitelesítés.

Hogyan találhatom meg a megfelelő LDAP alap DN-t és felhasználói DN-t?¶

Ne következtessen a címtárfára a szervezet nevéből. Kérdezze le egy LDAP ügyféllel, például ldapsearch, ugyanazt a szervert, TLS módot, alap DN-t, keresési azonosítót és felhasználónév attribútumot használva, amelyet az MRBS fog használni. Az Active Directory általában a következőt használja: sAMAccountName; Az OpenLDAP általában a uid kódot használja, de a címtárséma a mérvadó.

Tesztelje a keresési identitást a végfelhasználói kötéstől elkülönítve, és soha ne tegye közzé a kötési jelszavakat. A #1083 hibajegy fő oka egy rossz DN volt.

Hogyan korlátozható az LDAP hozzáférés egy csoportra?¶

A $ldap_filter segítségével adhatja meg, hogy a címtár mely felhasználói férhetnek hozzá az MRBS-hez. Ha az Active Directory a tagságot a felhasználói objektumban tárolja, a szűrő a memberof attribútumra illeszkedhet. Ha egy OpenLDAP-stílusú elrendezés a tagságot csoportobjektumokban tárolja, állítsa be a $ldap_filter_base_dn, $ldap_filter_user_attr és a megfelelő $ldap_filter paramétert.

Használja a címtárból a pontos megkülönböztetés- és attribútumneveket, teszteljen egy engedélyezett és egy elutasított fiókot, és ellenőrizze, hogyan viselkednek a beágyazott csoportok. Ezek a hozzáférési szűrők elkülönülnek a $ldap_admin_group_dn szűrőtől, amely az MRBS rendszergazdákat azonosítja. Lásd: #2033 hibajegy és LDAP hitelesítés.

LDAP bejelentkezés működik; miért nem MRBS rendszergazda a felhasználó?¶

Ha a $ldap_admin_group_dn be van állítva, az MRBS ezt a csoportot használja a $auth['admin'] helyett. Erősítse meg:

a teljes csoport DN;
$ldap_group_member_attrib — memberof alapértelmezés szerint;
hogy az LDAP keresési azonosság beolvassa a felhasználó tagsági attribútumait; és
hogy a címtár közvetlen vagy beágyazott tagságot ad-e vissza.

Átmenetileg engedélyezze az LDAP diagnosztikát csak védett tesztkörnyezetben, majd távolítsa el őket. A #3943 hibajegy-ben a keresési identitás kezdetben nem tudta beolvasni a szükséges csoportinformációkat.

Miért hibásodhat meg az LDAP az MRBS frissítés után, bár működik a jelszó-kötés?¶

Előfordulhat, hogy az aktuális MRBS-nek meg kell keresnie a felhasználó DN-jét és attribútumait, például a megjelenített nevet vagy az e-mail címet. Ha az anonim keresés nem érhető el, állítsa be:

$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';

Csak azokat az olvasási engedélyeket adja meg a keresési identitásnak, amelyekre szüksége van. A jelszavát tartsa a dokumentum gyökérkönyvtárán kívül, és adja meg egy védett konfigurációs fájlból. Lásd: #3895 hibajegy.

Kereshet az MRBS egynél több LDAP könyvtárban?¶

Igen. Számos LDAP beállítás, köztük a $ldap_host, $ldap_port, $ldap_base_dn és keresési attribútumok, tömb is lehet. Ha egy tömbképes LDAP paraméter egy tömb, akkor minden tömbképes paraméternek ugyanannyi elemet kell tartalmaznia, könyvtáronként egyet.

Tesztelje a bejelentkezést, az attribútumkeresést, a hozzáférési szűrőket és az adminisztrátori leképezést minden egyes könyvtárhoz. Lásd: #3981 hibajegy és LDAP részt a systemdefaults.inc.php dokumentumban.

Foglalások, szobák és engedélyek¶

Miért működik az egyéni foglalási mező egy foglalásnál, de miért nem egy sorozatnál?¶

Minden egyéni foglalási oszlopnak szerepelnie kell az entry és a repeat táblában is, azonos névvel, típussal, hosszal, NULL-kezeléssel és alapértelmezett értékkel. A két oszlopot egyetlen sémamódosításként kezelje.

Lásd: #3986 hibajegy és Egyéni mezők.

A terem kapacitása megakadályozza a túl sok résztvevővel történő foglalást?¶

Nem. A szoba capacity értéke az MRBS által megjelenített metaadat; a rendszer nem hasonlítja össze automatikusan a foglalás résztvevőinek számával. Ha a webhelynek érvényesítenie kell ezt a szabályt, adjon azonos résztvevőszám-mezőt az entry és a repeat táblához, majd valósítsa meg és tartsa karban a szerveroldali ellenőrzést. Az ügyféloldali ellenőrzés önmagában nem elegendő.

Ha a regisztráció engedélyezve van, az esemény kapacitása szabályozza az adott esemény regisztrációját; nem választ automatikusan megfelelő méretű helyiséget. Lásd: #1055 hibajegy, Területek és szobák és Egyéni mezők.

Használhat-e egy terület a 30 perces időközöket reggel és a 15 perceseket később?¶

A szabványos területbeállításokkal nem. Egy területhez egyetlen időfelbontás tartozik. Használja egész nap a legkisebb szükséges időegységet, vagy hozzon létre külön területeket, ha az erőforrások és a működési modell ezt lehetővé teszi. Az időponttól függő felbontás karbantartandó kódmódosítást igényel.

Lásd: #4011 hibajegy.

Miért nem látja a foglalás készítője a Szerkesztés vagy a Törlés lehetőséget?¶

Tekintse meg a meglévő terület foglalási szabályzatát a Tárgyalók címen. Az előzetes/jövőbeni szerkesztési korlátok és a korábbi foglalásokra vonatkozó szabályok még az alkotótól is eltávolíthatják ezeket a műveleteket. Ezenkívül erősítse meg a bejelentkezett személyazonosságot, a tulajdonjogot, a rendszergazdai állapotot, valamint azt, hogy az elem egy előfordulás vagy sorozat.

A areadefaults.inc.php módosítása nem frissít egy meglévő területet. Lásd: #3994 hibajegy és Foglalási szabályzat.

A többszobás foglalásban kiválasztott szobák tartósan össze vannak kapcsolva?¶

Az MRBS külön foglalási bejegyzéseket hoz létre. Ha az egyiket később szerkesztik vagy törlik, a többi nem marad tartósan összekapcsolt csoport. Ne másolja be automatikusan az összes kiválasztott szoba listáját minden leírásba, kivéve, ha a webhely a létrehozási, szerkesztési és törlési műveletek során is karbantartja ezt a listát.

Lásd: #2223 hibajegy.

Hozzáadhatok több hozzáférési szintet, vagy csak egy egyéni szerepkörnek adhatok hozzáférést a jelentésekhez?¶

A szabványos MRBS a 0., 1. és 2. hozzáférési szintet használja. További numerikus szerepkörök és oldalspecifikus engedélyek helyi jogosultsági módosítást, teszteket és minden frissítés utáni felülvizsgálatot igényelnek. Egy régi hibajegyből származó javítás nem támogatott konfigurációs lehetőség.

Előnyben részesítse a szabványos terület/helyiség delegálását és a szűk engedélyezési listákkal rendelkező nyilvános jelentéseket, ahol megfelelnek a követelményeknek. Lásd: #3999 hibajegy és Felhasználók és engedélyek.

E-mail, nyelv és idő¶

Miért jelzi az e-mail hibakeresés „Nincs címzett”?¶

Engedélyezzen legalább egy címzett szerepkört:

$mail_settings['admin_on_bookings'] = true;
$mail_settings['area_admin_on_bookings'] = true;
$mail_settings['room_admin_on_bookings'] = true;
$mail_settings['booker'] = true;

Az első beállításhoz adja meg a $mail_settings['recipients'] értékét. A terület- és szobaadminisztrátorok e-mail-címét az MRBS-ben kell karbantartani. Az LDAP-felhasználóknál olvasható és helyesen leképezett e-mail-attribútum szükséges, ha a foglaló értesítést kap. Ezután külön tesztelje a foglalások létrehozását, szerkesztését és törlését.

Lásd: #3795 hibajegy és E-mail értesítések.

Melyik értéket használjam a `$override_locale` esetén?¶

Használjon BCP 47 nyelvi címkét, például en, en-GB, de, fr vagy es, ne pedig operációs rendszer területi beállításait. A szervernek továbbra is rendelkeznie kell megfelelő területi adatokkal. Unix-szerű rendszereken a locale -a mutatja a telepített területi beállításokat.

Hagyja üresen a $override_locale mezőt az MRBS automatikus kiválasztás használatához. Lásd: #3984 hibajegy és Szöveg és fordítások.

Miért pont egy órás idő jelenik meg rosszul?¶

Ellenőrzés, sorrendben:

a szoba és a terület időzónája;
a globális $timezone;
PHP időzónája és időzóna-adatcsomagja;
az érintett dátum nyári időszámítási átállása; és
hogy a tárolt időbélyeg vagy csak a megjelenítése hibás-e.

Használjon IANA-időzónát, például Europe/Berlin, ne rögzített UTC-eltolást. Régi hibajegyek verzióspecifikus formázási kerülő megoldásokat említenek; a $force_strftime nem beállítás az MRBS 1.12.2-ben, ezért ne másolja át a #3967 hibajegyből. Lásd: Hibaelhárítás.

Hogyan szabhatom testre vagy fordíthatom le a Súgó oldalt és a felület szövegét?¶

Az alkalmazáson belüli súgóoldal a web/site_faq/ könyvtárból töltődik be. A spanyol például a site_faq_es.html fájlt használja; állítsa be a $faqfilelang = 'es' értéket, ha a nyelvet kifejezetten kell kiválasztani. Minden támogatott nyelvhez teljes lefordított fájlt tartson karban.

A kezelőfelület rövid módosításához használja az $vocab_override[LANG][TOKEN]-t a config.inc.php-ban a web/lang/lang.* szerkesztése helyett. Az egyéni adatbázismezők tokeneket használnak, például entry.catering.

Lásd: #2432 hibajegy és Szöveg és fordítások.

Jelentések, több webhely és testreszabás¶

Hogyan exportálhat egy ütemezett feladat jelentést vagy iCalendar-adatokat?¶

A nem hitelesített GET jelentések alapértelmezés szerint le vannak tiltva. Ha az információ így nyilvánosságra kerülhet, szándékosan engedélyezze, és korlátozza az alábbiakkal:

$report_unauthenticated_get_enabled = true;
$report_keys_enabled = true;
$report_keys = ['a-long-random-secret'];
$report_open_areas = [1];
$report_open_rooms = [];

Használjon nehezen kitalálható kulcsot, szűk terület- és szobaengedélyezési listát, HTTPS-t és védett ütemezőt. Kijelentkezve ellenőrizze a pontos kimenetet. A jelentés URL-je gyakorlatilag hitelesítő adat, és naplókon vagy böngészési előzményeken keresztül kiszivároghat.

Lásd: #3742 hibajegy és Keresés és jelentések.

Megoszthat több MRBS webhely egy táblázatkészletet?¶

Nem, ha a foglalásokat és a beállításokat külön kell tartani. Minden webhelynek saját MRBS-táblákra van szüksége, külön adatbázisban vagy egyedi $db_tbl_prefix előtaggal egy közös adatbázisban. A kód megosztható, de a táblakészletek nem fedhetik át egymást.

Hozzon létre minden webhely tábláit az MRBS sémaszkriptekkel, és alkalmazza következetesen az előtagot. Lásd: #3917 hibajegy és Több webhely.

Minden kért nézet vagy téma elérhető a konfiguráción keresztül?¶

Nem. Az olyan kérések, mint például további szobaszöveg beillesztése egy adott naptár-elrendezésbe, egyébként független foglalások összekapcsolása, hozzáférési szintek hozzáadása vagy a téma architektúra cseréje, kódmódosítást igényelhet. Támogatási probléma miatti javítás alkalmazása előtt:

ellenőrizze, hogy az 1.12.2 rendelkezik-e már beállítási vagy bővítési ponttal;
tartsa a változást a generált és szállítói fájlokon kívül;
adjon hozzá teszteket a létrehozáshoz, szerkesztéshez, törléshez, adatvédelemhez és engedélyekhez; és
rögzítse a testreszabást a következő frissítéshez.

Ilyen például a egyéni nézet, 2223. szám és a témakérés #22.