Hilfe - Menulinks zerschossen

[evaki]

Evaki: "Das Thema ist für mich gegessen"

Ich bin (nach Rücksprache, stand ja schon länger zur Debatte) raus, und werde nur noch die Downloads für die Anwender machen. Bei Sicherheitsproblemen gibt's natürlich dennoch 'ne Rückmeldung an die DEV. Muß aber nicht von mir direkt kommen. 
Wünsch Euch was!

[evaki]

"Dann muß man eben auch mal die Anleitung lesen"
Eben...

"Steht ein Nicht-Core-Modul nicht in dieser White-List, muß es manuell upgegraded werden."
Eben...

"Hundertfach erklärt"
Eben...

"Es wird kein Alt-Modul beim großen-Upgrade-Script angepasst oder mit eingeschlossen"
Eben...

Diese Fähigkeit, den Kern der Vorschläge komplett zu ignorieren, daran vorbei zu lesen, ist nicht bemerkenswert, sondern nur ein Störfaktor in der Kommunikation, und es schadet der Kreativität eines jeden Projektes, was aber überhaupt nicht die Leistungen Deinerseits schmälert. Es ist nur grauselig für jeden phantasievollen Menschen.

"ihr fordert, ihr meckert, aber selbst etwas beitragen?"
Diese Rigidität scheint typisch für Deutsche zu sein. Immer wieder in Foren anzutreffen.
Vielleicht auch mal schauen, was Leute aus anderen Nationen zu diesem Gebaren sagen?
Guck die Ursprünge und deren Philosophie für Open Source an, die sich nicht nur auf Software beschränkte. Abgesehen davon sind Fragen meist sinnvoller, als auf alles eine Antwort zu haben.

Ist schon klat, Klein Kleckersdorf ist der Nabel der Welt.

Bevor das möglicherweise wieder ausartet: "Das Thema ist für mich gegessen"

[Gast]

Mittlerweile gibt's die "weisse Liste",

Nur zur Aufklärung... White- oder auch die früher verwendete Blacklist verhindern nicht, das man mit einer leeren config.php die Datenbank überschreibt, wie gestern passiert. Dann muß man eben auch mal die Anleitung lesen und sollte diese nicht verständlich genug sein, muß das gesagt werden.

Die Whitelist ist dafür gedacht, das man Module, die nicht zum Core-Paket gehören, in das große Upgrade-Script mit einschließt. Hundertfach erklärt, aber da geht es eher um Einzelfälle, vielleicht um Leute, die sich ein vorher zusammen gestelltes Upgrade-Paket reihenweise installieren. Z.B. weil ich von 100 Kunden 50 habe, die genau dieses Modul ebenfalls nutzen. Steht ein Nicht-Core-Modul nicht in dieser White-List, muß es manuell upgegraded werden.
Und auch hier gibt es keine Sicherheit. Wenn ich mir solch Paket zusammenstelle und dort z.b. eine veraltete Version von OFA verwende, die auch im manuellem Upgrade aussteigt, dann wird sie das auch im großen Upgrade machen.

Tja, und wenn jemand bestehende Alt-module vor einem Upgrade nicht deaktiviert, was früher immer zu einem Problem werden konnte, war das manchmal auf fehlende Informationen zurückführen.

Du bist ein Fake-News-Verbreiter
Es wird kein Alt-Modul beim großen-Upgrade-Script angepasst oder mit eingeschlossen, es sei denn, man hat es in sein Upload-Paket mit höherer Versionsnummer integriert, damit die Dateien auf dem Server überschrieben und dieses Modul in die WhiteList eingetragen. Deswegen ist es auch unmöglich, das ein Modul, das nicht zum Core-Paket gehört, ein WB-upgrade zerstört. Es muß kein Modul deaktiviert werden, seit Jahren nicht mehr, also hör auf, Stimmung mit Unwahrheiten zu machen.
Das einzige, was im Upgrade mit Nicht-Core-Modulen passiert, in die Protokollierung, das dieses Modul nicht im Upgradeprozess eingeschlossen wurde, nix mehr, nix weniger

Niemand bei uns will "unnötige" Arbeit leisten

die Welt dreht sich nicht nur um euch - ihr fordert, ihr meckert, aber selbst etwas beitragen?  Fehlanzeige...
Macht doch mal ein Konzept, das für alle funktioniert, weltweit, über alle PHP-, MySQL- oder WB-Versionen. So was richtig schönes mit kompletter Wiederherstellung der Ausgangsversion, falls was schief geht, aber kann ja nicht...   
Natürlich jedes Einzelmodul bis in die letzte Datei, den letzten Code hin prüfen, und sag, wie du verhindern willst, das einer beim FTP-Upload nicht irgendwo eine Datei vergißt.
Wie viele andere bereite ich meinen Kram zu Hause vor, komm ich jetzt nicht in den Himmel oder wie?

[evaki]

Fortsetzung wg Zeitlimit

Tja, und wenn jemand bestehende Alt-module vor einem Upgrade nicht deaktiviert, was früher immer zu einem Problem werden konnte, war das manchmal auf fehlende Informationen zurückführen.
Mittlerweile gibt's die "weisse Liste", die anscheinend nicht immer entsprechend gewürdigt wird. Kann man sich fragen, wofür die DEV sich dem Problem gewidmet haben, wenn's oft nur ignoriert wird. Die "normale" Konsequenz ist, dieses Verhalten zu stoppen.

[evaki]

Sorry, aber Quatsch mit Käse

Nö, höchsten Quatsch mit Soße

Es ist vollkommen unwichtig ob es sich um einen Einzelfall handelt, oder um eine Massenproblematik.
Es geht um Service- und Anwenderfreundlichkeit, und nicht um Profilierung beim Support. Niemand bei uns will "unnötige" Arbeit leisten (weil wir's auch nicht können), das ist einer der Gründe.

nun ein rot geschriebenes "Du kommst nicht in den Himmel" juckt?

Man kann's auch derart gestalten, daß bei fehlenden Voraussetzungen,  die Installation abgebrochen wird. Macht man auf Betriebsystemebene schon lange, und es wird akzeptiert. Aber nicht nur das, es wird auch als hilfreich gesehen - man spart sich nämlich Frust. Außerdem schaut man aktiv nach Lösungen, die auch angeboten werden. Es spricht also nicht dagegen.

Nun ja, dann sind wir mit diesem Thema halt auch durch.

Anscheinend muß man sich für derartige Voraussetzungen eigene Lösungen schneidern.
Der Anstoß für solche Vorgaben/Lösungen lag bei uns schon seit kurz nach dem WB-Urknall vor. Da aber der Anwenderkreis existiert, ließ sich für die Umsetzung bis dato niemand finden. Im Sinne von "WB-Einfach" wäre es weiterhin wünschenswert.

[Gast]

@jacobi22
Hier war die Telepromt ausgefallen, daher erst jetzt:

Aber was mach ich als User, wenn da etwas Rotes auftaucht?

1.) Vorher die Infos zur Installation (Voraussetzungen) lesen.
2.) Bei rot, gelb entweder Informationen dazu in der Onlinehilfe (Installation) oder das Forum nutzen.

Sorry, aber Quatsch mit Käse   
Mir ist kein Provider im deutschsprachigem Raum bekannt, bei dem WB nicht laufen würde. Ich kenn allerdings schon einige, wo du noch mit PHP 5.2 arbeiten kannst, und einige wenige, wo 5.3 das Neueste ist, Meist kleine Buden und oft hört man dann: die waren doch die ganze Zeit so lieb mit mir   
Sorry, da wink ich ab

Es geht in den allerwenigsten Threads um Neuinstallationen und wenn doch, kommt das i.d.R. von ein paar Usern, die in einer Neuinstallation eine WB 2.10 und nicht etwa die neueste WB-Version verwenden. Und sollte es in Einzelfällen zu Problemen kommen, das z.b. eine der SERVER-Variablen nicht in der üblichen Form ausgegeben wird (bei das bei mir und Strato der Fall ist),
1. ist das eher ein Einzelfall, für den es Lösungen gibt
2. hat der User an dieser Stelle garkeine Wahl mehr, weil er einen PreCheck erst laufen lassen kann, wenn er ein Paket XY schon gebucht hat
3. ist es unmöglich, jede einzelne in WB verwendete Variable vorab zu checken
4. wird er auf diesem Server mit jedem anderen CMS die gleichen Probleme bekommen

Und was Upgrades betrifft... ich sag mal, 90% der Problemchen hier beruhen entweder auf dem NICHT-Lesen der Upgrade-Instruktion, auf dem Bestätigen der Aufforderung zum Backup, auch wenn das garnicht gemacht wurde oder auch dem Benutzen alter Module, für die es oft sogar Upgrades gibt

Die einzige Chance, das problemlos für Alle über die Bühne zu bekommen, ist, wenn du jemanden Versiertes anstellst, der das erledigt. Und das von Anfang an, vom ersten Backup bis zum letzten Upgrade.

Man muß auch mal schauen, was für einen breit gefächerten Kreis von Benutzern es gibt, der eine kann es, der andere denkt, er kann es, der nächste probiert es, liest sich rein und zieht es durch, ein wieder anderer verdient sogar Geld damit, kann aber selbst die einfachen Dinge nicht beachten. Erfahrungsgemäß ist in einem Hilfeforum der Anteil derer gering, die solch Upgrade problemlos erledigt haben und dies auch bestätigen, also liest man nur Probleme.
Verhindern kann man das nicht, oder meinst du, das jemanden, den über 8 oder 10 Jahre aus welchen Gründen auch immer die vergangenen Upgrades und die Sicherheitswarnungen egal waren, nun ein rot geschriebenes "Du kommst nicht in den Himmel" juckt?

[evaki]

Aua, watn dat? 
Erneut:
(Ich selbst mach ja sowieso meist nur Testinstallation mit dem Original, und schmeiße sie anschließend wieder weg, weshalb ich bisher da noch nie genauer drauf geschaut habe).

[evaki]

Na, - mal wieder - nicht genau formuliert.
Die Frage sollte sein, ob jegliche/s Installation/Upgrade in den Logfiles mit Zeit und Datum geschrieben wird, und auch nach einer/m erfolglosen Installation/Upgrade + Deinstallation nicht gelöscht wird, weil in userem Kreis sowas schon mal vorgebracht wurde.
(Ich selbst mach ja sowieso meist nur Testinstallation mit dem Original, und schweiß sie anschließend wieder weg, wesahlb ich bisher da noch genauer drauf geschaut habe)
MfG. Evaki

[hgs]

Neben der php_error.log.php wird auch eine install.log.php geschrieben. Somit hast du schon mal diese 2 Ansatzmöglichkeiten

[evaki]

@jacobi22
Hier war die Telepromt ausgefallen, daher erst jetzt:

Aber was mach ich als User, wenn da etwas Rotes auftaucht?

1.) Vorher die Infos zur Installation (Voraussetzungen) lesen.
2.) Bei rot, gelb entweder Informationen dazu in der Onlinehilfe (Installation) oder das Forum nutzen.
Im Script ob nun Precheck oder Installscript auf diese Möglichkeiten verweisen.
Bei Nichtbefolgung Drohungen aussprechen, wie "Du kommst nicht in den Himmel", "Du wirst in der Hölle braten", "Ich küsse Deine Mutta"  -oda so 

Damit bekommt man u.U. schon mal die "leichten Fälle" nicht mehr Forum zu sehen.
Bei den "scherwiegenden" gibt dann konkrete Informationen für die Helfer, weniger Rätselraten die Folge.
Der Ansatz mit der "weissen Liste" ist schon ein guter. Wenn bei der Installation z.B. bei Uralt-Modulen einfach weitergeklickt wird, als wenn's keine Bedeutung hätte, rast man meist in die bekannte Schleife, wo all die Info's, die man schon vorher kennen könnte, nach und nach abfragt.

Ein weiterer Ansatz und Vorschlag für die DEV.
M.E. wäre es zumindest eine sinnvolle Ergänzung, wenn alle Installation und Updates den Verlauf und die Ergebnisse auch in ein (separates) Logfile schreiben würden, also nicht nur php-errors.

MfG. Evaki

[astricia]

Ja, danke - das wars dann. Jetzt auch in italienisch fehlerfrei..... 

[Gast]

Zeile 156/157 dieser include.php sind....

Offensichtlich sind da noch Leerzeilen im Script, die hier nicht mitgezählt werden. Der Fehler beschreibt es schon

preg_match_all(): Compilation failed: missing terminating ] for character class at offset 14

Es geht also um die Zeile mit dem preg_match_all bzw der Variablen, die darin verarbeitet werden, wie z.b. $pattern. Lt Fehlermeldung fehlt da eine schließende eckige Klammer ]
das wäre im alten Code hier in der Zeile 3

der ganze Block aus dem Backup

Code Select Expand

// For wysiwyg replace [wblinkXX] by real link (XX = PAGE_ID)
if ($types[$field_id] == 'wysiwyg') {
$pattern = '/\[wblink(.+?)\]/s';
preg_match_all($pattern, $values[$field_id], $ids);
foreach ($ids[1] as $page_id) {
$pattern = '/\[wblink'.$page_id.'\]/s';
// Get page link
$link              = $database->get_one("SELECT link FROM ".TABLE_PREFIX."pages WHERE page_id = '$page_id' LIMIT 1");
$page_link         = page_link($link);
$values[$field_id] = preg_replace($pattern, $page_link, $values[$field_id]);
}
}

eventuell koperst du diese Stelle aus einem der Snippets, die funktionieren, z.b. das Gleiche in deutsch

Ich muß jetzt erstmal mein Auto reparieren, ist der erste Sonnentag mit Plus-Graden in diesem Jahr

[astricia]

OK, zunächst mal habe ich das mit dem Menulink wieder hinbekommen, indem ich die any_start_it gelöscht habe und noch mal neu aufgesetzt habe. Anscheinend hatte ich vorher irgendeinen Fehler drin, denn jetzt tritt zumindest das mit dem Menulink nicht mehr auf.

Habe die Fehlerberichte jetzt auf Production gestellt. Die deutsche Seite läuft da fehlerfrei. Bei der italienischen Seite bekomme ich an zwei Stellen Fehler:

Zum einen die italienische Startseite sowie Seite Gemälde. Fehler:

Code Select Expand

Thu, 14 Feb 2019 12:44:41 +0000 [E_NOTICE] /modules/oneforall_anyitems_start_it/include.php:[153] from /modules/code/view.php:[25] eval "Undefined offset: 1"
Thu, 14 Feb 2019 12:44:41 +0000 [E_WARNING] /modules/oneforall_anyitems_start_it/include.php:[153] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()"

Zeile 153 der include.php ist wie folgt:

Code Select Expand

// For wysiwyg replace [wblinkXX] by real link (XX = PAGE_ID)

Dann die italienische Biographie sowie Seite Ausstellungen. Fehler:

Code Select Expand


Thu, 14 Feb 2019 12:45:43 +0000 [E_WARNING] /modules/oneforall_anyitems_it/include.php:[156] from /modules/code/view.php(25) : eval()'d code:[2] ofa_any_it "preg_match_all(): Compilation failed: missing terminating ] for character class at offset 14"
Thu, 14 Feb 2019 12:45:43 +0000 [E_WARNING] /modules/oneforall_anyitems_it/include.php:[157] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()"

Zeile 156/157 dieser include.php sind:

Code Select Expand

// For wysiwyg replace [wblinkXX] by real link (XX = PAGE_ID)
if ($types[$field_id] == 'wysiwyg') {


Was ist daran jetzt falsch???

[Gast]

Ich habe versucht, das @unserialize durch __unserialize zu ersetzen, wie von dir vorgeschlagen und habe auch die function in die include.php integriert, wie du gesagt hast (in den jeweiligen OFA ist sie ja jetzt drin, da diese jetzt alle aktuell sind). Aber dann bekomme ich trotzdem im Frontend den Fehler
Was ist daran nun wieder falsch?

dann bitte auch alles lesen...

jau, da war ich zu schnell
wenn man diese Zeile 139 ersetzt, wie vorgeschlagen, braucht man auch die Funktionen dazu (in jede include.php der einzelnen OFA-Module und auch der Snippets)

da du mehrere Snippets gleichzeitig verwendest, würden die sich dann gegenseitig blockieren, weil die vorgeschlagene Funktion überall extra definiert ist. Man kann es also nicht 1:1 übernehmen, müßte es vorher noch abfragen.
Wie gesagt, da war ich zu schnell, weil ich zufällig eine Seite hatte, auf der nur ein Snippet lief.

[Gast]

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

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

genannte Zeilen betreffend dem unserialize

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"

"

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

Code Select Expand

$unserialized      = @unserialize($values[$field_id]);

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"

[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

[Gast]

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ß

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

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

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"

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.

[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....

[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]

Hallo zusammen,

danke noch mal für eure Hilfe gestern.

Ich habe jetzt bei der Seite noch weitere AnyItems-Snippets eingesetzt, da ich das Ganze ja auch noch für Italienisch brauchte. Und nu.... funktionieren die Menulinks wieder nicht.

Dabei habe ich ganz sicher immer die

Code Select Expand

$pattern = '/[wblink(.+?)]/s'; durch

Code Select Expand

$pattern = '/\[wblink(.+?)]/s';
und

Code Select Expand

$pattern = '/[wblink'.$page_id.']/s'; durch

Code Select Expand

$pattern = '/\[wblink'.$page_id.']/s';
ersetzt. Habe extra noch mal alles überprüft.

Der Errorlog gibt mir jetzt auf der Biographie-Seite z.B. folgendes aus:

Code Select Expand

"created: [Thu, 14 Feb 2019 10:24:55 +0000]
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""
Und zwar 167 Zeilen davon, die sich nur bei der Zahl der Bytes am Ende unterscheiden obwohl das OFA-Modul, auf das sich das Anyitems bezieht, nur 49 Einträge hat...

Auf der Seite Gemälde bekomme ich dieses:

Code Select Expand

Thu, 14 Feb 2019 10:36:53 +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"
nur 2 Zeilen.

Auf der Seite Ausstellungen bekomme ich:

Code Select Expand

Thu, 14 Feb 2019 10:37:38 +0000 [E_NOTICE] /modules/oneforall_ausst/include.php:[148] from /modules/code/view.php(25) : eval()'d code:[2] oneforall_ausst "unserialize(): Error at offset 0 of 69 bytes"
und

Code Select Expand

Thu, 14 Feb 2019 10:37:38 +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 25 bytes"
jeweils unendlich viele Zeilen davon...

Auf der Seite Letterario (italienisch für Literarisches) bekomme ich:

Code Select Expand

Thu, 14 Feb 2019 10:38:58 +0000 [E_NOTICE] /modules/ofa_ai_buecher/include.php:[147] from /modules/code/view.php(25) : eval()'d code:[2] ofa_ai_buecher "unserialize(): Error at offset 0 of 16 bytes"
6 Zeilen.

Die angegebenen Zeilen sind jeweils die LEERZEILE zwischen

Code Select Expand

if ($query_item_fields->numRows() > 0) {
while ($item_fields = $query_item_fields->fetchRow()) {

$field_id          = $item_fields['field_id'];
$values[$field_id] = trim(stripslashes($item_fields['value']));
$unserialized      = @unserialize($values[$field_id]);


Ich habe versucht, das @unserialize durch __unserialize zu ersetzen, wie von dir vorgeschlagen und habe auch die function in die include.php integriert, wie du gesagt hast (in den jeweiligen OFA ist sie ja jetzt drin, da diese jetzt alle aktuell sind). Aber dann bekomme ich trotzdem im Frontend den Fehler

Code Select Expand

There was an uncatched exception
Call to undefined function __unserialize()
in line (146) of (/modules/oneforall_anyitems/include.php):

Zeile 146 ist die Leerzeile, wie oben beschrieben...

Was ist daran nun wieder falsch?

Ach so - und der Test, welcher Fehler auftritt, wenn ich auf das Logo klicke - gibt dieses hier 2x aus:

Code Select Expand

Thu, 14 Feb 2019 10:49:59 +0000 [E_WARNING] /modules/menu_link/view.php:[56] from /framework/frontend.functions.php:[209] require "Cannot modify header information - headers already sent by (output started at /homepages/18/d66137901/htdocs/wb/modules/oneforall_anyitems_start_it/include.php:1)"

Es scheint also vor allem an dem neuen Anyitems-Modul Start_it zu liegen. Interessanterweise rufe ich das nur auf der italienischen Startseite auf, nicht auf der deutschen - der Fehler kommt aber bei Klick auf das Logo, auch wenn ich im deutschen Bereich bin.

So langsam verzweifel ich ein wenig.....   

[evaki]

Freut mich ja auch, wenns funktioniert.
Bei der Installation von WB wird, soweit ich erinnere, auf ungeprüfte Module verwiesen, also welche nicht in der weissen Liste stehen. Vielleicht sollte an dieser Stelle eine Warnung ausgegeben werden, damit's auch ankommt bzw. entsprechende Schußfolgerungen gezogen werden können.
Weiterhin scheint es immer wichtiger zu werden, den Server (http+php) und seine Umgebung vorab zu prüfen.
Einige Variablen  ($_SERVER + Elemente) scheinen ja nicht auf jedem Server verfügbar zu sein.
Wenn dann auch die error.logs und access.log nicht aufzufinden sind, oder die php-errors nicht aktiviert sind, braucht man 'ne Glaskugel oder/und den Biß von jacobi22   

Einige CMS haben sowas schon in der Vergangenheit gemacht.

Benutzt jemand schon ein entsprechendes Script?

MfG. Evaki

[dbs]

Das problemlose Upgrade freut mich zu hören.

Ich hätte für später auch noch ein paar OFA Snippets, die mit Templates arbeiten.
Da wird header, loop, footer also nicht in die include fest geschrieben, sondern man kann viele verschiedene Templates angeben und jedes hat seinen eigenen header, loop, footer. Halt ein Parameter $template mehr beim Dropletaufruf.

[astricia]

Es hat mir ja jetzt doch keine Ruhe gelassen - also hab ich das mit dem Upgrade von OFA probiert. Erst bei dem kleinsten OFA-Modul mit nur zwei Einträgen. Hat fehlerfrei geklappt. Bei den beiden anderen dann auch.

Und jetzt ist die Errorlog fehlerfrei und die Seite funktioniert vollständig...

Tausend Dank an alle Helfer hier - allen voran natürlich Uwe!!!!! Ich weiß euren Support sehr zu schätzen.

Allerdings weiß ich auch, dass ich jetzt noch bei ziemlich vielen anderen Websites die OFA-Module upgraden muss.... das benutze ich eigentlich ständig.... naja, nützt ja nix. Für die Zukunft hab ich wieder was gelernt.

[astricia]

OFA upgrade würde ich nicht auf dem Produktivsystem machen. Lieber eine Testumgebung anlegen.

Das ist ja quasi noch eine Testumgebung auf der Subdomain - es fehlen ja noch Inhalte, bevor die Seite live gehen kann. Und besonders viele Inhalte sind da jetzt auch nicht drin... Ich werde das morgen mal an einem kleineren OFA-Modul testen mit dem Upgrade. Vorher ne Sicherheitskopie anlegen natürlich...

[Gast]

die hab ich allesamt nicht (mit PHP 7.3.1)

bei mir nur noch die Bildfehler aus RandowImage  oder den OFA-Snippets usw
ich denk mal, mit Bilder wäre ich schon fast ohne Meldungen in der error.log