WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: astricia on November 14, 2019, 08:19:48 AM
-
Ich bekomme bei einer neuen Installation (WB 2.12.2) im Zusammenhang mit OFA-Modulen neuerdings solche Fehlermeldungen im Error-Log:
Wed, 13 Nov 2019 19:38:31 +0000 [E_NOTICE] /modules/ansprechpartner/view_overview.php:[484] from /modules/droplets/droplets.php(36) : eval()'d code:[37] require "Undefined index: READ_MORE"
"ansprechpartner" ist hier das OFA-Modul. Da steht in Zeile 484 von view_overview.php das Folgende:
$general_values = array(PAGE_TITLE, $thumb, $thumbs, $image, $images, $title, $item_id, $item_link, $item_date, $item_time, $uid, $users[$uid]['username'], $users[$uid]['display_name'], $users[$uid]['email'], $TEXT['READ_MORE'], $MOD_ONEFORALL[$mod_name]['TXT_ITEM']);
Oder liegt es an Zeile 36 von droplets.php ? Da steht das folgende:
$sRetval = (eval($_x_codedata));
Kann mir einer sagen, wie ich das abstellen kann? Die Liste im Error-Log ist ziemlich lang - bei jedem Aufruf einer Seite im Frontend, wo das entsprechende Modul eingesetzt ist, werden da neue Einträge erzeugt.
LG,
Astrid
-
Wie wäre es erstmal mit einem freundlichen Hallo am Morgen? :)
Und wie sieht es in Zeile 164 der view_overview.php ($general_placeholders) aus? Die Reihenfolge und Anzahl dort sollte die gleiche sein wie in deiner Zeile.
Nur mit Droplets hat das nichts zu tun. Normalerweise würde ich dich zu den Droplets schicken, in einem davon sollte das READ_MORE Problem stecken.
-
Moin moin - sorry, bin noch etwas verschlafen.... ;-)
Du meinst Zeile 163? (Zeile 164 ist leer). Sieht so aus:
$general_placeholders = array('[PAGE_TITLE]', '[THUMB]', '[THUMBS]', '[IMAGE]', '[IMAGES]', '[TITLE]', '[ITEM_ID]', '[LINK]', '[DATE]', '[TIME]', '[USER_ID]', '[USERNAME]', '[DISPLAY_NAME]', '[USER_EMAIL]', '[TEXT_READ_MORE]', '[TXT_ITEM]');
Da habe ich aber nix verändert. An der Zeile 484 auch nicht.
Müsste in Zeile 484 also statt READ_MORE auch TEXT_READ_MORE stehen? Oder umgekehrt in Zeile 163 nur READ_MORE ?
-
so auf den ersten Blick, fehlt hier schlicht die globale Sprachvariable $TEXT['READ_MORE'], oder der Index 'READ_MORE' im Array $TEXT. (so behauptet es wenigstens die Fehlermeldung)
Dass die globale Sprachdatei selbst nicht geladen ist, halte ich für relativ unwahrscheinlich. Ich denke eher, dass die an dieser Stelle ausserhalb des Sichtbarkeitsbereic hes ist und deshalb importiert werden muss. $GLOBALS['TEXT']['READ_MORE'] sollte fast reichen...
Sollten noch mehr Sprachvariablen fehlen, das ganze Array $TEXT am Anfang der Datei per global $TEXT; importieren.
Eventuell fehlt auch nur der Eintrag $TEXT['READ_MORE'] in der globalen Sprachdatei.
-
Oder hast du im Loop statt [READ_MORE] ein [[READ_MORE]] irgendwo eingesetzt ?
-
Ich habe nirgendwo im Loop [READ_MORE] oder [[READ_MORE]] verwendet.
Wo genau muss ich denn jetzt was ändern? Bin doch kein PHP-Experte....
Ich habe versucht, in Zeile 484 der overview.php das READ_MORE durch TEXT_READ_MORE zu ersetzen (so wie es die placeholders aus Zeile 163 vorgeben), aber das führt dazu, dass die Fehlermeldung jetzt so heißt:
Thu, 14 Nov 2019 08:38:29 +0000 [E_NOTICE] /modules/ansprechpartner/view_overview.php:[484] from /modules/droplets/droplets.php(36) : eval()'d code:[37] require "Undefined index: TEXT_READ_MORE"
-
Zeile 525 der DE.php (also der WB Sprachdatei) lautet
$TEXT['READ_MORE'] = 'Weiterlesen';
Das ist es also nicht.
Wo genau schreibe ich global $TEXT; bzw. $GLOBALS['TEXT']['READ_MORE'] hin ?
-
Geh mal davon aus, dass das Problem nicht OFA ist.
Zig mal installiert und diesen Fehler noch nicht gesehen. Auch du hast vorher noch nie davon gesprochen.Könnte es an was anderem liegen?
-
Es tritt interessanterweise nicht bei allen OFA-Modulen in dieser Installation auf (sind inzwischen 7 insgesamt, der Fehler tritt nur bei 3 davon auf). Worin der Unterschied liegt, kann ich überhaupt nicht sagen - die sind alle aus dem gleichen OFA-Grundmodul abgeleitet (2.0.2.23) - haben alle zwischen 3 und 7 Felder (also auch die vier, bei denen der Fehler nicht auftritt), haben alle einen Loop nur für die Übersicht (Detailseiten werden nicht benötigt).
Ich habe auch schon versucht, die view_overview.php aus einem der OFA-Module, bei denen das NICHT auftritt in eins der betroffenen OFA-Module zu kopieren, falls sich da irgendein Fehler eingeschlichen hat. Nein - Fehlanzeige - der Fehler tritt dann weiter auf.
Die Website liegt auf einem Server mit besonderen Sicherheitsvorkehru ngen, hatte ich glaube ich vor zwei Wochen oder so geschrieben. Am Anfang konnte ich überhaupt keinen Loop abspeichern. Das hat irgendeine Firewall auf dem Server verhindert. Dies hat dann der Support beim Hoster abgestellt, sodass es jetzt wieder ging. Aber ich sehe jetzt nicht, wo eine Firewall diese Errorlogs provozieren könnte...? Oder meint ihr, es könnte wieder ein Hoster-Problem sein.... hmmmmm
-
Die Dateien werden ok sein. Was du tun könntest wäre die Loops mal zu tauschen.
Aber so richtig weiß ich auch nicht weiter aus der Ferne.
-
Guten Morgen zusammen! :-)
Die Loops sind es nicht. Mir ist da aber noch was eingefallen. Die drei betroffenen Module sind alle auf versteckten Eingabeseiten eingerichtet. Aufgerufen werden sie letztendlich über das SectionPicker-Droplet. Also scheint das Problem doch eher da zu liegen und nicht bei OFA.
Ich habe mal auf einer Testseite verschiedene Abschnitte mit dem SectionPicker-Droplet aufgerufen. Die Fehlermeldung tritt nur auf, wenn der aufgerufene Abschnitt ein OFA-Abschnitt ist. WYSIWIG, Miniform, Minislider oder Minihero können problemlos aufgerufen werden. Bei OFA-Abschnitten kommt dann immer diese Meldung und zwar für jeden Eintrag 1x:
Fri, 15 Nov 2019 07:13:49 +0000 [E_NOTICE] /modules/angebot/view_overview.php:[484] from /modules/droplets/droplets.php(36) : eval()'d code:[37] require "Undefined index: READ_MORE"
Habt ihr sonst noch eine Idee, was ich da machen kann?
LG,
Astrid
-
Guten Morgen und schön, dass du die Ursache finden konntest.
Jetzt müsste man mal testen was passiert, wenn die anderen Module auch so ein READ_MORE hätten.
Du siehst aber, dass es nicht ungedingt eine gute Idee ist solche Module mit Sectionpicker zu holen. Oft stehen nicht alle benötigten Dateien dann zur Verfügung. In Plaaaaanung ist aber ein universelles OFA zu bauen, dass je Seite und Section eigene Felder nutzen kann. Also ein zentraler Ort, aber trotzdem individuell. Mit Snippet dann an jeder Stelle aufrufbar.
Manu wird vielleicht erklären warum es in deinem Fall ein Problem gibt, ich werd es mal nachstellen.
edit: ist erstmal bestätigt. Ich bekomme noch dazu undefined index: NEXT, NEXT_PAGE, OUT_OF und OF
Unabhängig davon ob versteckt oder nicht, der Dropletaufruf verursacht es.
-
Die Ursache habe ich vielleicht, aber noch nicht die Lösung. Da bin ich auf eure Hilfe angewiesen...
Anders als mit Sectionpicker funktioniert das hier nicht. Der Sectionpicker wird ebenfalls in einem OFA-Modul aufgerufen. Also quasi OFA in OFA....
Das "äußere" OFA ist für verschiedene Accordion-Abschnitte auf den einzelnen Seiten, die sich mit Javascript-Toggle über Klick öffnen und schließen lassen.
Innen in diesen Abschnitten (also bei Öffnen) sind vom Kunden ganz unterschiedliche Inhalte gewünscht. Manchmal sind es nur Texte und Bilder, manchmal sind es eben aber auch Dinge, die am besten über ein eigenes OFA-Modul realisiert werden (z.B. ein Kontakte-Abschnitt, wo diverse Mitarbeiter mit Foto, Name, Telefon und Email aufgelistet sind). Sowas muss vom Kunden easy gepflegt werden können, da es sich sicherlich oft ändert - also brauche ich hier einen leicht zu findenden Abschnitt (separate versteckte Seite, ganz unten im Seitenbaum) mit jeweils einem Eintrag pro Mitarbeiter, der dann nach Belieben geändert werden kann.
Das andere sind Veranstaltungstermi ne, die sich logischerweise auch ständig ändern und gepflegt werden müssen. Das dritte sind Presse-Mitteilungen. Auch hier ist Pflegebedarf. Der Rest der Accordion-Abschnitte ist statischer Text/Bild-Aufbau ohne erhöhten Pflegebedarf.
Ich habe also im äußeren OFA ein Feld "Section-Picker-ID", in dem die ID des jeweils aufzurufenden Abschnitts der versteckten Eingabeseite steckt. Dies wird dann im Loop mit aufgerufen.
Der Fehler tritt aber auch auf, wenn das SectionPicker-Droplet mit dem OFA-Abschnitt einfach in einem WYSIWIG-Abschnitt aufgerufen wird. Habe ich getestet. Also am "äußeren OFA" bzw. an der "OFA-in-OFA-Konstruktion" liegt es nicht!
-
Erstmal Lösung: Im Droplet Sectionpicker fügst du ganz oben $TEXT dazu
global $wb, $TEXT;Das hat bei mir die Meldungen verhindert.
OFA oder Topics nur verwenden, wenn interne Unterseiten gebraucht werden. Ansonsten Members oder Itemz.
Oder eine Mischung aus beiden, habe ich aber noch nicht getestet. Aber ich verstehe warum du das so machst.
-
Jaaaaaaa.... das war's, das unterbindet die Meldungen. Perfekt, danke!!!!! :-D
-
yep, als 'Notlösung' geht das so lala.
Der Import der Variablen im SectionPicker ist in diesem Fall jedoch etwas deplaziert, da der SectionPicker ja X verschiedene Module laden kann, die alle ihre jeweils eigenen / unterschiedlichen Variablen benötigen.
Der 'richtige' Ort um Variablen zu importieren, ist grundsätzlich immer die Datei, in der diese benötigt werden.
Im vorliegenden Fall braucht der SektionPicker selbst das Array $TEXT nicht. Benötigt wird es dagegen in ofa/view_overview.php.
Also wäre es sinnvoll, das global $TEXT; in view_overview.php ganz oben, direkt nach der Zeile if (!defined('SYSTEM_RUN')).... einzufügen.
vielleicht auch interessant:
Eine weitere Möglichkeit wäre die Verwendung der Registry-Objekte, die WB seit 2.10.0 bereitstellt. Die Beschreibungen dazu gibt es im WB-Wiki.
Registry (WbAdaptor) (https://wiki.WebsiteBaker.org/doku.php/dev/284/registry)
Übersetzungen (Translate) (https://wiki.WebsiteBaker.org/doku.php/dev/284/translate)
zusätzlich stellt die Registry noch eine Reihe weiterer 'netter Features' bereit.
um zum ursprünglichen Problem zurück zu kommen:
in der view_overview.php oben die Registry importieren durch global $oReg;
oder, besser noch, einfach die Registry-Instanz holen: $oReg = \bin\WbAdaptor::getInstance();
danach kann nach dem Schema $sText = $oReg->Trans->TEXT_READ_MORE; auf jede beliebige Sprachvariable des Core zugegriffen werden.