WebsiteBaker Support (2.12.x) > Hilfe & Support (deutsch)

Hilfe - Menulinks zerschossen

<< < (18/21) > >>

DarkViper:
Du hast die wblink-Patterns nicht vollständig ausgetauscht. ;)
Zwar hast Du die öffnende [ mit einem Backslash maskiert, nicht jedoch auch schließende ].
Setz der auch noch n Backslash davor, dann klappts auch  mit'm Nachbarn. *ggg

astricia:
Das stimmt zwar - aber das behebt das Problem leider nicht. Habe jetzt alle schließenden \ eingefügt. Leider immer noch die gleichen PHP-Fehlermeldungen und Menulink funktioniert eben auch immer noch nicht.... :-(

jacobi22:
Ich weiß doch wie solch Kram läuft. Nur ein kleines Beispiel: Ich hab mir die Foldergallery, schon eine 3er Version, umgebaut, zu jedem Bild gibt es die Möglichkeit, Keywords, ein von-bis Datum und eine Wysiwyg-Beschreibung auszugeben, Dazu eine search.php, die diese Felder entsprechend bedient. Hatte ich 2017 oder 2018  umgebaut, als PHP 7.2.1 noch was Neues war. Und natürlich verwende ich diese Version auch nicht nur bei mir.
Nun gibt es eine für PHP 7.3 angepasste Version der FG und ich müßte umbauen, um Gleiches wieder zu erreichen. Hab noch keine Zeit gefunden, also nehm ich meine Version weiter und das geht so lang, bis es eben nicht mehr geht.
War in diesem Fall mit Oneforall nicht anders. Irgendwann muß ich da durch wie auch die Astrid da durch muß


--- Quote ---Weiterhin scheint es immer wichtiger zu werden, den Server (http+php) und seine Umgebung vorab zu prüfen.
--- End quote ---

Grundprinzip ist richtig.
Ich hab das gleiche Problem bei meinem Doc, wenn ich nach einem MRT oder CT frage. Ich weiß, da sind wieder einmal ein paar Sehnen gerissen, er weiß es auch, sieht es ja. MRT kann ich sofort schreiben, kein Problem, aber was machen wir mit dem Ergebnis? Wieder eine OP? Willste??   Ähmm.... nö

Analog mit solchem Vorab-Tester. In der Regel hat man Webspace und die meisten haben darauf eine Webseite laufen. Man weiß, PHP 5.6 steht vor dem Abschalten, die ersten 7er Versionen auch und es wird danach nicht mehr viel laufen. Was mach ich also mit dem Ergebnis eines solchen Test's, wenn mir dieser etwas Negatives beschert?
Die Webseite zu? Nicht updaten?
Es gab und gibt eine Art Pre-Check, damals mal für die 2.8.4 gebaut, liegt hier irgendwo rum. Ist bei weitem nicht alles drin, hat auch keine 100 Zeilen, dieses Script. Aber was mach ich als User, wenn da etwas Rotes auftaucht?

Hab den Spaß auch gerade in einem vollkommen anderem System durch, Gambio-Shop, installiert in 2011, seit her nicht upgedatet. Macht 26 Updates, um auf den neuesten Stand zu kommen, alles sauber der Reihe nach. Das Verfahren analog. Nach jedem Upgrade bitte ein Backup von Datenbank und Dateien machen, um es einzuspielen, falls das nächste Upgrade schief geht. Nach 5 Stunden Arbeit hatte ich acht dieser Upgrades geschafft, das 9. ging schief. Der Kunde hat dann den Stecker gezogen, es waren ja nur zwei Artikel drin. Vielleicht hätte ich mit Umstellen der PHP-Version noch mehr erreicht, aber zum Zeitpunkt des Abbruchs stand ich eben vor einer Seite mit gefühlten 1000 Fehlermeldungen und einem Screenshot, das das zuletzt funktionierende Upgrade auch erfolgreich abgeschlossen wurde.
Am Ende gehts nicht anders, du mußt, egal wie das System heißt, per FTP oder Script etwas übertragen, das deine aktellen Dateien überschreibt und danach weißt du erst, ob es gut oder schlecht war.

Was die PHP-Fehlerberichte angeht... es wurde lange und viel drüber diskutiert, ob man diese mit einem Upgrade automatisch einschaltet oder nicht.
Gehen wir ein paar Beiträge nach oben und nehmen uns eine davon


--- Quote ---Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_anyitems_start/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[3] oneforall_anyitems_ start "unserialize(): Error at offset 0 of 69 bytes"
--- End quote ---

OFA legt die Info's zu verschiedenen Feldern in einem Serialize ab, wenn man diese Informationen denn benutzt. Serialize ist eine bestimmte Art der Datenaufbereitung, will ich nicht näher drauf eingehen.
Werden diese Extra-Infos in OFA nicht genutzt, ist der Serialize noch leer. Leer bedeutet in diesem Fall aber komplett leer, es steht also nichts im Datenbank-Feld.
Erwartet wird aber zumindest das Serialize-Format, in etwa so a:1:{}. Das würde in der DB stehen, wenn ich bereits solche Daten verwendet hatte und diese später lösche. Da nun nix vorhanden ist, hat das Script auch keine Werte für diesen Vorgang, wirft also obigen Fehler.

Ist es nun sinnvoll, das Frontend erst einmal "sauber" zu halten oder besser, alles gleich nach Upgrade anzuzeigen, um es gleich beheben zu können?
Solang es nur um Notices geht, ist die Antwort einfach. Bei einem Fatal Error geht eh nix mehr (hatten wir ja gestern)
Die Bitte, die PHP-Fehlerberichte einzuschalten bzw zu kontrollieren, kam mehrfach gestern und ich war schon überrascht, das sie im zugesendeten Paket dann doch aus waren. Vom Empfang der Daten bis zum ersten laufen der Seite sind 10 min vergangen. In diesen 10 min hab ich das Paket ausgepackt, einen Virtuellen Server erstellt, die Datenbank importiert und die config.php angepasst. Reine Arbeitszeit im laufendem WB vielleicht zwei Minuten.
Fehlerbericht einschalten, Fehlerberichte lesen, böse Zeile auskommentieren - und läuft. Reparieren kann ich dann schrittweise.
Ist schon ein prima Werkzeug, diese anklickbare error.log. Woanders wird mir vorgegaukelt, mein CMS hätte keine Fehler. Da ich aber zu jedem virtuellem Server auch separate Logs habe, weiß ich, das "Woanders" auch jede Menge Errors wirft. Nur, wenn ich sie auch sehe, kann ich was unternehmen. Und es ist ja nicht selten, das aus einer Notice, einem einfachen Hinweis, in einer der nächsten PHP-Versionen ein Fatal Error draus wird.





 

dbs:
Hast du denn am Anfang der include die function für __unserialize eingefügt?
Und weiter unten 2x ersetzt das alte @unserialize gegen __unserialize

jacobi22:
@Astrid:  wie stehen die PHP-Fehlerberichte jetzt??

Falls nicht auf Production, bitte dort hin stellen und auch lassen

genannte Zeilen betreffend dem unserialize

--- Quote ---Thu, 14 Feb 2019 10:29:39 +0000 [E_NOTICE] /modules/oneforall_anyitems/include.php:[146] from /modules/code/view.php(25) : eval()'d code:[2] oneforall_anyitems "unserialize(): Error at offset 0 of 69 bytes"
--- End quote ---
"

beziehen sich auf eine bewußte Fehlerunterdrückung mit dem @ in solchen Zeilen

--- Code: ---$unserialized      = @unserialize($values[$field_id]);
--- End code ---

Ich habe das im Beitrag davor schon einmal angerissen, allerdings als Antwort für Evaki.
Dieser @-Fehlerunterdrücker war und ist immernoch eine gültige PHP-Error-Handling-Methode

An dieser Stelle im Code möchte das Script die Daten zu Feld auslesen, z.b. eine Checkbox, Radio-button etc. Sie sind für deinen verwendeten Feldtyp aber nicht vorhanden, somit leer. Weil aber nie welche eingetragen wurden, ist auch das Datenbank-Feld leer. Der Code erwartet aber, das dort bereits serialisierte Daten vorhanden sind. Weil der Auto aber wußte, das diese Daten in der Regel nicht da sind, unterdrückt er die zu erwartene Fehlermeldung mit dem @ davor

Im Fehlerberichtsmodus "Developer" werden auch Fehler angezeigt, die durch dieses @ unterdrückt werden. Damit der Entwickler ("Developer") weiß, an dieser Stelle ist noch Potential zur Verbesserung. In der neuen Version von OFA hat Dietmar eine Methode eingebaut, wie dies umgangen werden kann.
Für einen Nicht-Entwickler reicht aber auch die Stufe "Production"

Navigation

[0] Message Index

[#] Next page

[*] Previous page