WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => Modules => Topic started by: bbs2 on March 18, 2019, 12:18:44 PM
-
Hallo,
wenn ich auf der website einen Begriff suche (WB Search), löst die another imagegallery (Version 2.5) folgenden Fehler aus
Mon, 18 Mar 2019 11:10:50 +0000 [E_DEPRECATED] /modules/imagegallery/search.php:[73] from /framework/frontend.functions.php:[250] require "Function create_function() is deprecated"
Mon, 18 Mar 2019 11:10:50 +0000 [E_DEPRECATED] /modules/imagegallery/search.php:[74] from /framework/frontend.functions.php:[250] require "Function create_function() is deprecated"
Search bringt einwandfrei Suchergebnisse. Der Fehler wird im frontend nicht bemerkt.
imagegallery 2.5
WB 2.12.1, jedoch search aus 2.8.3, da search aus 2.12.1 nicht funktioniert (leere Seite)
PHP 7.2
Gruß
Heinz
-
WB 2.12.1, jedoch search aus 2.8.3,
kein Kommentar :-o :-o
-
Hallo,
ich habe Verständnis für den Kommentar. Aber man testet halt und versucht den Fehler zu finden.
Tatsache ist hat. dass die Suchenfunktion aus wb 2.12.x überhaupt nicht funktionierte und die Einbindung der alten
Dateien aus 2.8.3 nur ein Test sind. Siehe da, es funktioniert. Das soll so natürlich nicht bleiben. Evtl. ist der Fehler
nun in der imagegallery nur ein Folgefehler.
Liegt es in 2.12.x evtl. an einer geänderten Einbindung im Vergleich zu 2.8.x von search in die index.php, die ich nicht kenne?
Eine readme im Searchfolder wäre da nicht schlecht.
Meine Einbindung in das Template:
<form name="search" action="<?php echo WB_URL.'/search/index'.PAGE_EXTENSION; ?>" method="post">
<p class="searchform">
<input type="text" name="string" size="15" class="searchbox"/><br /><br />
<input type="submit" name="submit" value="<?php echo $TEXT['SEARCH']; ?>" class="searchbutton" />
</p>
</form>
<?php }
?>
Gruß
Heinz
-
Wie wär's denn mal mit "den gesamtem Schrott löschen"
Und das Wichtigste, keine Änderungen an WB selbst vorzunehmen.
Solche Operationen wie vorliegend sind ein "NoGo", nicht nur für das System, sondern insbesondere für jeden Helfer. Eine erfolgreiche Hilfe wird mit sowas vollkommen unmöglich.
Ist ja fast wie Automechaniker legt sich unters Auto, und Du nimmst den Wagenheber weg, weil Du den grad für was anderes brauchst. Prima.
MfG. Evaki
-
ich sag es mal bewußt überspitzt: du hast gerade Zündkerzen aus deinem 30 Jahre alten VW-Käfer in dein Elektroauto eingebaut :wink:
Ja, Quatsch mit Käse, aber vielleicht verstehst du den Sinn dahinter...
Die Suche in WB ist ne sehr komplexe Geschichte, sie zieht sich durch den halben framework-Ordner. Das Einzige, was sich praktisch nicht geändert hat in all den Jahren, ist die Definition des Suchformulars in den WB-Optionen
wenn du dicht dran bleiben willst und irgendetwas Relevantes möchtest, verwende die Dateien vom Downloadpaket der WB 2.12.1
Ich würde die Ordner /framework und /search davon nehmen
-
@Evaki: die Testseite wurde eigentlich nur zum Testen des Swiftmoduls angelegt. Unterschied zur öffentlichen Domain ist der letzte Corefix.
Wie an anderer Stelle schon gesagt, gehört diese Diskussion eher in den Testerbereich.
-
@Evaki: die Testseite wurde eigentlich nur zum Testen des Swiftmoduls
Das ist mir bewußt, aber ohne Systematik habt Ihr 'ne Woche mit Vollbeschäftigung.
Aber ist schon klar, eine neuer Film "Gegen die Wand" wär auch ein schöner schöner Film. Man muß ja nicht alles negativ sehen. :lol:
Dabei fehlen Handwerker an allen Enden und Kanten... :roll:
-
aus meiner Sicht mit Bezug auf das Swiftmodul war diese Testerei dort schon erfolgreich. Aktuell fehlt nur etwas Zeit, ein Wochenende hatte ich nicht.
Das man dann noch andere Sachen findet, umso besser, schließlich testet jeder auf seine Weise.
Die Suche habe ich z.b. in einen anderen Kundenprojekt intensiv getestet, weil das dort verwendete Gallery-Modul noch keine search.php hatte. Und als die dann lief, wollte der Kunde noch die Möglichkeit, nicht nur eine Namenssuche, sondern auch nach Image_ID zu suchen, das war schon eine intensive Testerei
und alles mit dem lertzten Corefix und der neuesten WB-Version. Deswegen bin ich jetzt schon etwas überrascht.
-
Was Du dort schon geleistet hast, weiß ich nicht, und kann es auch nicht beurteilen. Es wird von Dir wie üblich professionell erledigt werden, bzw. erledigt worden sein. Kennt man es anders? 8-)
Find's nur schade, daß dann so Dinger "von hinten durch die Brust ins Auge" kommen.
-
in Ergänzung zum vorherigem Beitrag: soll heißen: es gibt kein generelles Problem mit der Suche. Bekannt ist aber, das gerade Strato schon auch ein paar Eigenheiten hat, speziell was Pfade betrifft, Document_Root usw. Ich glaube, es nennt sich Smart-Url, dabei werden mit PHP ermittelte Pfade in ein schöner lesbares Format umgewandelt und intern umgeleitet. Verwendet man aber an anderer Stelle wieder den mit PHP ermittelten Pfad, stimmt er mit dem umgewandelten nicht überein und schon bekommt man einen 500er Fehler.
Wir hatten bei Strato allgemein z.b. schon desöfteren große Probleme, ShortUrl zu benutzen. So was in der Richtung vermute ich hier auch. Dann fehlt der Rückleitungspfad oder die internen Pfade sind anders. Kann man aber nur testen, wenn man es vor sich hat und z.b. Kontrollausgaben setzen kann. Dafür fehlen mir da die Möglichkeiten, muß ich auf meiner eigenen Testseite machen. Ist der Fehler erst gefunden, kann man ihn auch schnell reparieren.
Ich tippe mal grob darauf, das es ähnliche Probleme in anderen Modulen auch geben könnte, die Eingaben verarbeiten, Form, News-Comments, Gästebuch usw.
Was Du dort schon geleistet hast, weiß ich nicht, und kann es auch nicht beurteilen. Es wird von Dir wie üblich professionell erledigt werden, bzw. erledigt worden sein.
Um mich geht es nicht. Habe dort auch nicht viel gemacht, eine Swiftgallery angelegt und die Testergebnisse vom Heinz verarbeitet, aber eben nur für die Gallery. Im speziellen ging es eben darum, seine knapp 60 Galerien mit deren Einstellungen zu übernehmen. Bei den Seiten, die du oben genannt hattest, war das nicht der Fall, deswegen fehlen Breite des Hauptbildes und der Thumbs und dann wird nur der Titel angezeigt.
Wären es nur 3 oder 4, hätte ich gesagt, leg neu an, geht schneller und funktioniert dann auch, wäre aber für mich keine Lösung. Der Heinz hätte das wohl auch ohne Murren gemacht, aber morgen kommt der nächste User, der sich drauf verläßt, das ein Upgrade auch funktioniert.
Ob da der Rest des Outputs W3C-conform ist, weiß ich nicht. Dafür gabs keinen Auftrag ;-)
-
Verwendet man aber an anderer Stelle wieder den mit PHP ermittelten Pfad, stimmt er mit dem umgewandelten nicht überein und schon bekommt man einen 500er Fehler.
Wir hatten bei Strato allgemein z.b. schon desöfteren große Probleme, ShortUrl zu benutzen. So was in der Richtung vermute ich hier auch.
Mehr als interessant, weil ich gestern ein älteres Tool wieder zum Laufen bekommen habe, das mir im Gegensatz zu neueren tatsächlich mehr als zwanzig Broken Links anzeigte, Domainnamen mit Portangabe "Domain:80". Ob das damit in Verbindung gebracht werden könnte, weiß ich nicht, da mir die dortigen Server-Verhältnisse nicht vertraut sind. Ich wollte diese Ergebnisse nicht auch noch mitteilen, weil ich die Bevölkerung Anwender nicht beunruhigen wollte. :-D
Soll ich da nochmal drüberzuckeln, und gucken, ob sich das noch so verhält???
MfG. Evaki
Kurzer Versuch, test.domainname.de war wohl nix, leere Seite... 500error
-
Anscheinend läuft die Site wieder, und zuckel grad mal drüber.
Die Broken Links. Scripts, Forms, Comments - 404 - sind der Zahl im Moment 133 (forms 138, Comm. 139)
Ob nun pages oder Module, alle diese Broken sonstwas lauten test.domain.de:80/pages/sonstwas.....
Von woher kommt nun derartige Anfragen? Vom CMS wohl nicht.
Werde diesen Scan abbrechen und noch mit anderen wiederholen. Schaun wir mal...
MfG. Evaki
-
eine ganz simple Erklärung wäre z.b., das bei Anlegen der Test-Domain nicht alles Media "rüber geschoben" wurde,
eine andere, das in der Datenbank hard-coded Links auf die ursprüngliche Domain enthalten sind. Ich habe z.b. viel PDF's gesehen. Wenn die über die alte DownloadGallery laufen, wär das z.b. der Fall.
Da müßte man wirklich mal ein paar direkte Fälle nehmen und Adressen abchecken
-
Solange die anderen Scanner in dieser Hinsicht nix störendes bestätigen, kann man es auch liegen lassen.
Einen hab' ich aber möglichwerweise noch:
http://test.bbsiikl.de/pages/anmeldung/bs-anmeldung.php
Unexpected Redirect Response Body (Too Large)
Vulnerability Details
This generally indicates that after redirect the page did not finish the response as it was supposed to.
Impact
This can lead to serious issues such as authentication bypass in authentication required pages. In other pages it generally indicates a programming error.
Remedy
Finish the HTTP response after you redirect the user.
In PHP applications, call exit() after you redirect the user.
Im Moment erscheint alles bemerkenswert sauber.
Ergänz.: Zu früh gefreut. search/ bringt noch 'nen 500er error
Unsichere Frames zwar auch, gehe aber davon aus, wenn die Testseite übertragen wird, daß dann auch TLS aktiviert wird/ist.
XSS gibts auch noch, der wird mir aber auch mit WVS bestätigt werden, wenn's so sein sollte.
Gleich gibt's noch'n kickstart mit WVS, und dann wäre es das erstmal.
MfG. Evaki
ps. Die Scans laufen alle nicht bis zu Ende durch, da bei Grundchecks wie in diesem Fall auch noch viel zu viel abgegrast wird.
-
Noch'n kleinen Nachtrag:
Broken Links
http://test.bbsiikl.de/Include/jquery/jquery.min.js
http://test.bbsiikl.de/pages/banken.php
Beim default Template noch:
/templates/DefaultTemplate/TEMPLATE_DIR/druck.css
/templates/DefaultTemplate/TEMPLATE_DIR/screen.css
-
search scheint mir ein Templatefehler zu sein, funktioniert bei mir auf Strato mit dem DefaultTemplate ohne Probleme, in anderen Templates nicht. Da fehlen wohl Parameter.
was das Beispiel betrifft, da müßte man wohl genauer schauen. Ich persönlich würde eher ein mehrseitiges Formular verwenden, weil es die Fehlersuche eingrenzt, aber der Fehler passiert wohl schon früher
Broken Links
http://test.bbsiikl.de/Include/jquery/jquery.min.js
http://test.bbsiikl.de/pages/banken.php
Beim default Template noch:
/templates/DefaultTemplate/TEMPLATE_DIR/druck.css
/templates/DefaultTemplate/TEMPLATE_DIR/screen.css
hausgemacht
Include groß geschrieben, noch dazu unnötig, weil später über register_frontend_m odfiles() nochmal eingebunden
und bei /templates/DefaultTemplate/TEMPLATE_DIR/druck.css
sehr wahrscheinlich den Platzhalter TEMPLATE_DIR im HTML aufgerufen, muß PHP sein, also /templates/DefaultTemplate/<?php echo TEMPLATE_DIR; ?>/druck.css
-
Hallo,
bei der Suche tritt, wie bereits erwähnt, folgender Fehler, ausgelöst durch die another image gallery auf:
Fri, 22 Mar 2019 08:53:22 +0000 [E_DEPRECATED] /modules/imagegallery/search.php:[73] from /framework/frontend.functions.php:[250] require "Function create_function() is deprecated"
Fri, 22 Mar 2019 08:53:22 +0000 [E_DEPRECATED] /modules/imagegallery/search.php:[74] from /framework/frontend.functions.php:[250] require "Function create_function() is deprecated"
Der Fehler verschwindet natürlich, wenn ich Suchen für die entsprechende Seite ausschalte.
Sofern Suche eingeschaltet ist und auf php 5.x versuchsweise umgeschaltet wird, erscheint der
Fehler ebenfalls nicht. Also nur unter php 7.x.
Die installiert Version von imagegallery ist 2.5.
WB 2.12.1 core
PHP 7.2
Verwendet wb 2.12.1 oder imagegallery veralteten php-code??
Viele Grüße
Heinz
-
Verwendet wb 2.12.1 oder imagegallery veralteten php-code??
Steht ja dort modules/imagegallery/search.php:[73]
Die sollte "eigentlich" ohne Probleme sein.
Es gibt auch noch eine Version 2.6, wo das Teil auf strict gepatcht wurde (save.php).
Hat also nichts mit der search zu tun.
Der Fehler kommt erst mit php 7.2
Trotzdem im Forum mal suchen.
Es findet sich bestimmt irgendwer, der diese Funktion ersetzt.
Dann könnte es mit php7.2 ff und strict funktionieren.
MfG. Evaki
-
oder mal liest ab und an mal eine Fehlermeldung und läßt sie sich von Tante Google erklären
Datei: modules/imagegallery/search.php:[73]
Fehler: Function create_function() is deprecated
http://php.net/manual/de/function.create-function.php
-
Hallo und Danke für die replies,
der Fehler tritt nur im Zusammenhang mit der Durchsuchung der Homepage unter php 7.2 auf
und nicht mit save.php.
Dass es eine Version 2.6 der imagegallery gibt, ist mir nicht bekannt und mir auch nicht verfügbar.
Es wäre interessant zu sehen, ob der veraltete code in der search.php (Zeilen 73 ...) beseitigt ist.
Ich sah ebenfalls bereits unter google, dass es mit create-function Probleme gibt. Ich möchte nur Fehler melden,
kann und darf sie aber nicht beheben.
Gruß
Heinz
-
Es wäre interessant zu sehen, ob der veraltete code in der search.php (Zeilen 73 ...) beseitigt ist.
nein, ist er nicht, weil das bis dahin nicht bekannt war
und darum hat Evaki den Link zum Post auch schnell wieder entfernt (Y)
-
Dann nehme ich mal die Version 2.4 aus dem add-on-Bereich raus und warte auf eine bereinigte 2.6.x :-)
-
Hallo,
ich denke, der Fehler ist nicht dramatisch. Im Frontend wird er m.E.
nicht bemerkt.
Ich bemerkte ihn lediglich in der error-log nach einer Suche. Diese Suche zielte
jedoch nicht auf Inhalte in der imagegallery.
Ich müsste noch testen, ob die Suchergebnisse insgesamt durch den Fehler beeinträchtigt werden.
Ein anderes Problem besteht allerdings, wenn der neuerdings veraltete code im core oder in anderen
Modulen zu Problemen führen könnte.
Viele Grüße
Heinz
-
Ein anderes Problem besteht allerdings, wenn der neuerdings veraltete code im core oder in anderen
Modulen zu Problemen führen könnte.
genau darum gibt es ja ein Upgrade nach dem nächsten überall und wer dann als Webmaster noch verschiedene Systeme zu betreuen hat, wird da schnell Update-müde
Du kannst du aber sicher sein, das diese Funktion "create_function()" nirgend im WB-Paket verwendet wird
Ich müsste noch testen, ob die Suchergebnisse insgesamt durch den Fehler beeinträchtigt werden.
es gibt zwei mögliche Szenarien für solche Probleme
1. der ehler ist eher banal - DEPRECATED ist eher eine Info, das diese Funktion outdated ist
2. der Fehler ist gravierend und bricht die Suche ab. Im Worst-Case eine weiße Seite mit oder ohne Fehlermeldung
einfache Lösung: die Datei imagegallery/search.php umbenennen oder gleich löschen, wenn sie nicht mehr funktioniert
-
Hallo,
hier noch in Ergänzung meine Testergebniss:
1. Mit Suche auch in der imagegallery
a) es kommt zu den bereits genannten Fehlermeldungen
b) Die Suche selbst läuft fehlerfrei
c) Das mit Bild01.JPG benannte Bild wird bei Suche mit Bild01 auch als Suchergebnis ausgewiesen.
2. Mit deaktivierter Suche in der imagegallery
a) keien Fehlermeldungen
b) abbruchfreie Suche mit den gleichen Ergebnissen wie in 1b)
c) Das mit Bild01.JPG benannte Bild wird bei Suche mit Bild01 richtigerweise nicht als Suchergebnis ausgewiesen.
Fazit: Die Fehlermeldung bei aktivierter Suche in imagegallery-Seiten bleibt im frontend ohne Auswirkungen.
M.E. könnte das Modul durchaus online bleiben. Die PHP-Unverträglichkeit könnte bei nächster
Gelegenheit beseitigt werden.
Gruß
Heinz
-
Kaputte Module gehören nicht in Add-ons. Sollte eigentlich klar sein, warum sich das so verhält.
Man kann natürlich auch Winterreifen mit 1,6 Millimeter Profiltiefe verkaufen.
Auch Eigentore kann man schießen 8-)
Außerdem existiert nicht nur der Fehler in search, sondern auch einer in save:
[E_NOTICE] \modules\imagegallery\save.php:[112] from \modules\imagegallery\save.php:[112] bin\Exceptions\ErrorHandler::handler "Undefined index: PAGES"
Ist das "üblich", daß es keinen Galerie-Löschknopf gibt, also einem nur das Entfernen der Sektion als Lösung bleibt, oder sehe ich den gerade nicht? Soll ja auch schon vorgekommen sein :roll:
-
Siehe
https://forum.WebsiteBaker.org/index.php/topic,31354.msg219282.html#msg219282