WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: astricia on February 13, 2019, 11:01:58 AM
-
Hilfe! Ich hab mir bei einem Projekt irgendwie die Menulinks zerschossen und bekomme nicht raus, woran es liegt...
Also: WB 2.12.1 - bilingual
Die oberste Ebene sind zwei Menu-Links (DE / IT), die jeweils auf die Startseite der jeweiligen Sprachdatei verweisen.
Bis gestern hat das auch alles wunderbar funktioniert. Seit gestern abend nicht mehr. Jetzt wird leitet die Menu-Link Datei nicht mehr auf pages/de/start.php weiter, sondern ruft eine pages/de.php auf. Diese zeigt im Frontend nur den Header mit Menü, sonst nichts. Wenn ich mir den Quellcode anschaue, bricht dieser genau an der Stelle ab, wo der erste Abschnitt aufgerufen würde. Wenn man dann auf das Menü klickt, kann man die Seite ganz normal sehen. Allerdings auch nur auf dem großen Bildschirm - das responsive Menu am Handy wird nicht aufgeklappt.
Was habe ich gestern gemacht? Verschiedene OFA-Module und OFA-Anyitems/Topitems installiert. Zum Schluss noch Miniform installiert. Und ansonsten nur Inhalte eingepflegt. Kann irgendwas davon dazu geführt haben?
Ihr dürft auch gerne selber schauen, das macht die Fehlersuche vielleicht einfacher:
http://neu.ciriaco.de/
Danke schon mal...
LG,
Astrid
-
Moin, schau mal ob noch die richtigen Pagecodes zugewiesen sind in den jeweiligen Seiteneinstellungen .
-
Ja, sind sie. Ist man erst mal im Menü selbst drin, kann man ja auch problemlos zwischen den Sprachen hin- und herswitchen. Nur der Klick aufs Logo funktioniert nicht... da kommt man dann auf die jeweilige Sprachdatei, die ja eigentlich ein Menulink sein sollte.
-
Kommt mir bekannt vor, aber fällt im Moment nicht ein. Grübel ...
Wegen Logo-Klick müsstest du aber eine Abfrage nach Sprache einbauen um auf italienischen Seiten nicht auf die deutsche zu fliegen.
Dazu wäre es auch gut, wenn du <html lang="de"> tauschst gegen
<html lang="<?php echo strtolower(LANGUAGE); ?>">
-
Letzteres habe ich gerade geändert - bringt aber keine Änderung.
-
Für mich eher ein Template- als ein Menu-Link-Problem
Die Umschaltung zur anderen Sprache ist erfolgt, das sieht man am Menü und am Quellcode, der wechselt z.b. die Seitenbeschreibunge n beim Sprachenwechsel.
Wenn du mich fragst, lass dir mal die Page- und Section-ID ausgeben, da, wo Block 1 im Template dargestellt wird also page_content(1)
Ansonsten müßte man wohl die index.php mal anschauen
-
Doofe Frage - hast du mal die Menu-Link DE + IT neu eingestellt
vielleicht auch mal bewußt auf andere Ziele im jeweiligem Sprachzweig?
-
Ich habe die Linkziele bei DE und IT jetzt mal probeweise auf Biographie bzw. Biografia umgeleitet. Bringt keine Änderung. Hatte auch schon eine Testseite innerhalb des italienischen Menüs vom Typ Menu-Link angelegt, die woanders hinleitete. Auch diese leitete nicht weiter, sondern rief eine Seite pages/it/test.php auf.
Das Blöde ist - bis gestern funktionierte das ganz sicher noch einwandfrei. Ich krieg einfach nicht raus, was das verändert haben könnte....
Wenn du mich fragst, lass dir mal die Page- und Section-ID ausgeben, da, wo Block 1 im Template dargestellt wird also page_content(1)
Ansonsten müßte man wohl die index.php mal anschauen
Was meinst du damit? Wenn du dir den Quellcode der abgebrochenen Seite anschaust, endet der ja bei
<section class="full columns">
page_content1 kommt in der index.php direkt dahinter.
-
Mir zeigen die anderen Flaggen nur so einen verkürzten Link, wenn die entsprechende Gegenseite nicht vorhanden ist.
Die muss aber als Pagecode angegeben sein bei den andersprachigen Seiten, aber das hast du ja.
-
Die Gegenseiten sind alle vorhanden - und die Pagecodes sind auch überall richtig eingestellt. Daran kann es nicht liegen.
-
Mir zeigen die anderen Flaggen nur so einen verkürzten Link, wenn die entsprechende Gegenseite nicht vorhanden ist.
Die muss aber als Pagecode angegeben sein bei den andersprachigen Seiten, aber das hast du ja.
ist eine der Flaggen im Fähnchenmenü die Sprache aus den WB-Optionen und oberste Sprache im Seitenbaum, wird dort im Fähnchen nur die WB-URL angezeigt, wenn man zur Hauptseite möchte. Erst, wenn die angewählte Seite eine Unterseite ist, erfolgt im Fähnchenmenü auch die Anzeige des kompletten Links.
Funktioniert analog mit der startseite eines Menüs, erst nur WB_URL dann WB_URL / pages/ home.php
P.S.: Korrektur unten
Ich habe die Linkziele bei DE und IT jetzt mal probeweise auf Biographie bzw. Biografia umgeleitet. Bringt keine Änderung. Hatte auch schon eine Testseite innerhalb des italienischen Menüs vom Typ Menu-Link angelegt, die woanders hinleitete. Auch diese leitete nicht weiter, sondern rief eine Seite pages/it/test.php auf.
Das Blöde ist - bis gestern funktionierte das ganz sicher noch einwandfrei. Ich krieg einfach nicht raus, was das verändert haben könnte....
Wenn du mich fragst, lass dir mal die Page- und Section-ID ausgeben, da, wo Block 1 im Template dargestellt wird also page_content(1)
Ansonsten müßte man wohl die index.php mal anschauen
Was meinst du damit? Wenn du dir den Quellcode der abgebrochenen Seite anschaust, endet der ja bei
<section class="full columns">
page_content1 kommt in der index.php direkt dahinter.
ich vermute, das WB die Page-ID verliert nach Anklicken des Menu-Links
darum mal testweise diese einfügen, bei dir dann oberhalb dieser Zeile mit <section class="full columns">
<?php echo "Page-ID: ".PAGE_ID." Section-ID: ".$section_id; ?>
Ergebnis sollte die Ausgabe der angewählten Page-ID sein der Seite, auf die im Menu-link verlinkten Zielseite sowie dessen Section ID.
Im schlimmsten Fall ist beides leer
-
Habe ich eingefügt.
Ergebnis ist die Page-ID der Menulink-Seite (also nicht der Zielseite, sondern der eigentlichen Seite). Section-ID ist leer (weil oberhalb von page_content(1))
Und was sagt dir das jetzt?
-
Und was sagt dir das jetzt?
das ich mit meiner Vermutung falsch lag :oops: :oops:
ging nicht eben noch z.b. die italienische Biografie-Seite?
-
die Gegenprobe mit dem DefaultTemplate sollte das Template ausschließen - hast du sicher schon probiert, oder?
-
Mir zeigen die anderen Flaggen nur so einen verkürzten Link, wenn die entsprechende Gegenseite nicht vorhanden ist.
Die muss aber als Pagecode angegeben sein bei den andersprachigen Seiten, aber das hast du ja.
ist eine der Flaggen im Fähnchenmenü die Sprache aus den WB-Optionen und oberste Sprache im Seitenbaum, wird dort im Fähnchen nur die WB-URL angezeigt, wenn man zur Hauptseite möchte. Erst, wenn die angewählte Seite eine Unterseite ist, erfolgt im Fähnchenmenü auch die Anzeige des kompletten Links.
Funktioniert analog mit der startseite eines Menüs, erst nur WB_URL dann WB_URL / pages/ home.php
Hier muß ich mich wohl korrigieren.
Angezeigt wird der komplette Link zum im Menu-Link verlinktem Ziel, also so, wie von dbs gesagt
-
die Gegenprobe mit dem DefaultTemplate sollte das Template ausschließen - hast du sicher schon probiert, oder?
Hatte ich tatsächlich noch nicht probiert - habe ich aber soeben. Das verhält sich mit dem Default Template genauso. Geht man direkt auf eine Unterseite, kann man navigieren - klickt man aufs Logo, bekommt man beim Default Template eine komplett leere Seite. Also kein Redirect auf de/start.php, der Quellcode allerdings auch komplett leer, was wohl daran liegt, dass beim Default Template der Content1 ganz oben steht.
Also, Template kann es nicht sein (an dem hatte ich gestern auch gar nicht mehr geschraubt). Was denn dann?
-
ging nicht eben noch z.b. die italienische Biografie-Seite?
Die geht auch immer noch - die italienischen Seiten haben nur alle noch keine Inhalte, da warte ich auf die Übersetzung vom Kunden.
Dass eine Seite geht, siehst du, wenn unten das Fußzeilenmenü auftaucht. Bei Klick auf das Logo ist da unten nix mehr.
-
Was mir noch einfällt - ich hatte gestern wie gesagt diverse OFA-Module und OFA-Anyitems/Topitems installiert.
Bei einer OFA-Anyitems Instanz bekam ich ständig Fehler im Frontend, die ich mir nicht erklären konnte. Diese OFA-Anyitems kann man nicht über den Tab Module deinstallieren - wird da einfach nicht angezeigt. Also habe ich sie per FTP vom Server gelöscht. Danach sah das Frontend wieder vernünftig aus. Habe die gewünschte Funktion dann über ein TopItems Modul eingefügt.
Wenn ich jetzt aber auf Erweiterungen > Module gehe, und auf "Details zum Modul anzeigen", so sind da die physikalisch gelöschten Module noch aufgelistet. Details kann er natürlich nicht finden, da ja bereits gelöscht.
Kann es daran liegen? Muss ich die Einträge irgendwie anders löschen?
-
Wenn ein Modul/Snippet keine uninstall.php drin hat bekommst du es nicht zum Deinstallieren angezeigt.
Löschen per FTP ist richtig, aber in der DB steht es noch.
Lösung: Erweiterungen > Erweitert > Haken bei Module Neuladen
-
OK - Module Neuladen erledigt - bringt aber leider keine Änderung beim ursprünglichen Problem... :-/
-
Hab es mal fix nachgebaut und da funktioniert es natürlich :|
bin etwas ratlos...
Was ich jetzt machen würde (das meiste davon hast du sicher schon)
1.- WB-Optionen -> erweiterte Optionen
----- Mehrsprachigkeit eingeschaltet? (Wäre sie aus, erscheint das WB-eigene Fähnchenmenü nicht und in den Seiteneinstellungen jeder Seite entfällt das Feld Pagecode)
----- URL Umleitung zur Homepage soll ausgeschaltet sein
2. WB-Seitenübersicht
---- Kontrolle der Sprachzuordnungen der Unterseiten. Alles unterhalb von DE muß DE als Sprache haben, alles unterhalb von IT dann IT bzw italienisch.
Seitenbäume über das Plus öffnen und jede Seite kontrollieren
(https://i.gyazo.com/49bfa8dfa7071721a7877d4d855e29cf.png)
3. Templates
---- Kontrolle der Definitionen von $blocks. Wäre z.b. ein Tipfehler in der Definition von $menu, wird bis dahin gelesen, das, was danach steht aber ignoriert. Möglich, wenn man z.b. ein neues Menü hinzufügt
---- hat man an der info.php etwas geändert, egal, ob Template oder Modul, muß es neu eingelesen werden (Erweiterungen -> erweitert, alle Häkchen setzen)
Sectionverwaltung
----- stimmt die Zuordnung zu den gewünschten Blöcken noch?
WB-Infofenster
----- Klicke Link "Rebuild Accessfiles" und "Clear Translate Cache"
Bringt auch das noch nichts, würde ich die Ordner /framework und /modules/menu_link mal austauschen gegen die Originale aus dem WB-Paket
-
Das eigentliche Problem scheint nur zu sein, dass die WB_URL nicht zur ersten Seite DE führt.
Und die DE Seite leitet nicht zum Menülink Ziel. Danach geht alles korrekt seinen Weg.
http://neu.ciriaco.de/pages/de.php
There was an uncatched exception
Call to undefined function simplepagehead()
in line (14) of (/templates/ciriaco/index.php):
-
Was ich jetzt machen würde (das meiste davon hast du sicher schon)
Habe jetzt alles gemacht, inklusive Neu-Aufspielen von framework und modules/menu_link - keine Veränderung.
Uncatched exception? Bei mir nicht - vielleicht kam das gerade als, ich was neu hochgespielt habe.
Simlepagehead() ist installiert.
Es funktionieren sämtliche Menulinks nicht, nicht nur die WB_URL der ersten Seite. Ich habe jetzt gerade mal im italienischen Seitenbaum wieder eine Seite "test" eingebaut. Typ Menu-Link, sollte eigentlich auf die italienische Biografie-Seite umleiten. Tut es aber nicht...
Bin genauso ratlos. :-(
-
deaktiviere mal diese Zeile 14 in der index.php des Templates mit dem simplepagehead()
-
deaktiviere mal diese Zeile 14 in der index.php des Templates mit dem simplepagehead()
Erledigt. Jetzt funktioniert der Klick aufs Logo immer noch nicht. Dafür tritt bei den einzelnen Seiten der Fehler auf, der gestern auch bei dem Anyitems auftauchte. Oben ist so ein unschöner schwarzer Rand. Und guckt mal in den Quelltext, so wird plötzlich
</head>
<body class="site">
rot dargestellt - also irgendwie nicht beachtet.
.....
-
Jau, das liegt am halb auskommentierten
//<meta charset="utf-8">
ein doppel-slash geht wohl in PHP, aber nicht in HTML
Kommentier mal wieder ein bitte
*zu spät..
-
Hab ich dann auch gesehen. Habs jetzt kurzfristig komplett gelöscht, um zu sehen, ob sich was ändert. Dann sieht der Quellcode auf den Einzelseiten zwar wieder vernünftig aus, aber die Menulinks funktionieren trotzdem nicht.
Also an Simplepagehead liegt es definitiv nicht.
-
Also an Simplepagehead liegt es definitiv nicht.
weiß nicht, wo dbs die Fehlermeldung gesehen hat, ich hab sie noch nicht gesehen.
aber bei solchem Fehler bricht das Script dann ab, allerdings kenn ich das nur so, das es dann auch komplett abbricht an der Stelle. Da es bei dir oben im <head> sitzt, wäre dann praktisch alles leer bis auf diese Fehlermeldung.
Sagt denn die error-log etwas?
-
War wohl nur kurz ein Problem wie sie schon schrieb. Sehe die Meldung nicht mehr auf de.php
-
Auch mal doof gefragt, die start.php ist öffentlich?
-
betreff PHP-Fehlermeldung:
War wohl nur kurz ein Problem wie sie schon schrieb. Sehe die Meldung nicht mehr auf de.php
schade, ich hatte erhofft, es ist ein Resultat der nun eingeschalteten PHP-Fehlerberichte.
Der Validator (https://validator.w3.org/nu/?doc=http%3A%2F%2Fneu.ciriaco.de%2Fpages%2Fde%2Fbiographie.php&showsource=yes) gibt noch einiges zu korrigieren, viel Kleinkram, doppelte ID, script type usw.
Ich denke, es ist nichts, was eine Ausgabe verhindern würde
Für die Menu-Link-Seiten bekomm ich vom Validator einen I-O-Error, das mag mit dem angebrochenem Script zusammen hängen
-
Laß das mal durch 'nen Validator laufen ('DIV-Fehler u.a.)
ansonsten
broken link:
/pages/de/footermenu/[WBLINK12]
-
der BrokenLink ist Folge des Abbruch's in page_content(1)
Im Normalfall läuft der WbLink-filter einmal am Beginn des Ladens der Seite und einmal direkt kurz vor dem Ende
-
also von meiner Seite bleibt jetzt nur noch mod_secure
der Menu-Link macht ja einen header('Location: '.$target_url);
Wie die Kontrolle mit der Page-ID oben zeigte, ist das Ziel oder zumindest dessen Page-ID ja vorhanden. Von daher bleiben nur zwei Möglichkeiten
Entweder der Page-Link wird nicht ausgelesen (DB-Tabelle pages) oder mod_secure unterbindet header:location
mach doch zum Test mal einen Code-Abschnitt mit solchem Code
header('Location: http://www.example.com/');
exit;
nimm aber eine Domain, die du mit Sicherheit erreichen kannst und auf keinen Fall google.com
example.com würde so aussehen
(https://i.gyazo.com/2fa3f635ce501bd0ee21f2ea4b0dfc8b.png)
alternativ ginge auch der Wrapper,
-
mach doch zum Test mal einen Code-Abschnitt mit solchem Code
header('Location: http://www.example.com/');
exit;
Habe ich jetzt auf der Unterseite "Unterricht" so gemacht - und zwar als Code-Abschnitt vor dem eigentlichen Text.
Ergebnis, siehe hier: http://neu.ciriaco.de/pages/de/unterricht.php
Auch diese Seite bricht direkt vor dem Aufruf des ersten Abschnitts ab.
Ich glaube, du bist der Lösung auf der Spur ... nur, was mache ich jetzt?
-
Auch mal doof gefragt, die start.php ist öffentlich?
Logisch - das ist die Home-Seite, hab nur den Menütitel durch ein Font-Awesome-Icon ersetzt.
-
Sagt denn die error-log etwas?
Ist komplett leer.
-
Ich glaube, du bist der Lösung auf der Spur ... nur, was mache ich jetzt?
den Provider informieren, der soll mal eine Stufe runter stellen
Um WB komplett auszuschließen, könnte man als Gegenprobe auch eine einfache PHP-Datei erstellen, die außerhalb vom WB-System ins WB-Root-Verzeichnis gelegt wird. z.b. als test.php benennen und im Browser aufrufen, für diese Domain hier dann mit
http://neu.ciriaco.de/test.php
Normal wäre der Inhalt von http://www.example.com (Bild oben) oder eben nichts, wenn header: Location() unterbunden wird
Inhalt der Datei
<?php // gehoert zum Code - mit kopieren
/*
* nur zum Test
*/
$sTargetUrl = 'http://www.example.com';
header('Location: '.$sTargetUrl);
exit;
-
Provider ist 1&1 (Ionos). Bin etwas irritiert, das ist ja jetzt kein kleiner Hoster... Und wie gesagt, bis gestern funktionierte das auch. Ob die da gestern was umgestellt haben?
Probiere das nachher gleich aus mit der test.php - bin jetzt nur erst mit meinem Sohn beim Zahnarzt. Rückmeldung dauert also etwas.
-
Bei einem 1&1 Kunden mit Tarif "Homepage Perfect" (Vetragsbeginn 2009) klappt das Testscript.
-
So, bin zurück und habe die test.php in das WB-Stammverzeichnis gelegt.
Schaut hier: http://neu.ciriaco.de/test.php
Es scheint also doch nicht am Server, sondern irgendwo bei WB zu liegen.... :-(
Wer von euch hat das Kontaktformular ausgetestet und irgendwelche kryptischen Dinge darüber verschickt? Mein Kunde mailt mir gerade, dass er heute Mittag komische Mails bekommen hat..... ;-) Nun ja, das Formular funktioniert jedenfalls... ;-)
-
Provider ist 1&1 (Ionos). Bin etwas irritiert, das ist ja jetzt kein kleiner Hoster... Und wie gesagt, bis gestern funktionierte das auch. Ob die da gestern was umgestellt haben?
erstmal nur eine Vermutung...
aber technisch natürlich möglich, das man da gestern was aktualisiert hat, ist ja auch nur Software
aber die Problemchen mit zu scharfer mod_secure sind ja bekannt und auch hier in diversen Postings schon vorgekommen
https://forum.WebsiteBaker.org/index.php/topic,30507.msg212599.html#msg212599
Läuft man mal durch die Stadt, sieht mal überall Leute mit dem Handy vor'm Gesicht, da wird mit der Liebhaberin telefoniert oder ein Geschäftsabschluß gemacht, alles kein Problem. Kann man überall zuhören. Aber wehe, es geht um Websicherheit, dann wird aus der Homepage des Dackelvereins ein Hochsicherheitsbloc k. Früher hat man eigentlich nie etwas von mod_secure oder ModSecurity gehört, bei manchen Anbietern war es gar gegen Aufpreis mit drin, heute schaut das anders aus. Verhält sich analog zu MysqlStrict - wer hatte das denn vorher? Heut werden es immer mehr Leute, die davon berichten. Und i.d.R. sind es auch die gleichen Provider. Es ist ja auch nichts schlechtes, nur wissen muß man es halt. Im Falle von MysqlStrict reicht eine saubere Programmierung, aber bei einem header:Location(), zumal der noch auf der eigenen Domain bleibt, gibt es eigentlich nix, was man auf die Schnelle probieren kann, ohne sich das System und die spätere Upgradeverträglichk eit zu vermurksen.
Schau erstmal, was der Test ergibt.
Sollte das mit example.com funktionieren, ändere die Adresse mal in eine seite dieser Domain, die auf jeden Fall komplett angezeigt wird, ich glaube, die start.php war z.b. so eine Seite
Wrapper wäre dann analog, aber mit WB-System
-
Wer von euch hat das Kontaktformular ausgetestet und irgendwelche kryptischen Dinge darüber verschickt?
ich nicht - ich schwöööööre
probierst mal den Wrapper noch?
-
Muß eigentlich Multiple Choices (Apache) aktiviert sein? (IST AKTIVIERT!)
Wer von euch hat das Kontaktformular ausgetestet und irgendwelche kryptischen Dinge darüber verschickt?
Das könnte mein Scanner gewesen sein, kannst Du aber im LOG nachschauen, ob er das war.
Wenn das Teil mit Schutz (Captcha) versehen ist, sollte kein Absenden möglich sein, also bei Dir nix landen!
MfG. Evaki
-
Habe jetzt erst mal die test.php wie gewünscht auf die de/start.php umgeleitet. Funktioniert auch problemlos.
Wrapper kommt dann als nächstes.
-
Muß eigentlich Multiple Choices (Apache) aktiviert sein?
war das nicht die Alternativ-(Datei-)Suche, bei Adress-Tipfehlern? Wenn ja, würde ich das eher nicht aktivieren
-
Wrapper funktioniert auch. Habe ihn auf die Unterrichtsseite gelegt - und zwar in einen Abschnitt 1, der oberhalb des fehlerhaften Code-Abschnittes liegt.
Beim Code-Abschnitt
header('Location: http://www.example.com/');
exit;bricht er die Ausgabe ab.
-
Wer von euch hat das Kontaktformular ausgetestet und irgendwelche kryptischen Dinge darüber verschickt?
Das könnte mein Scanner gewesen sein, kannst Du aber im LOG nachschauen, ob er das war.
Wenn das Teil mit Schutz (Captcha) versehen ist, sollte kein Absenden möglich sein, also bei Dir nix landen!
MfG. Evaki
In welchem Log? In der Historie von Miniform, sehe ich 2 Einträge, z.B. folgendes:
Datenschutz: akzeptiert
Email: sample@email.tst
Message: 20
Name: lgomhavu
Timestamp: WEB-INF/web.xml?
Captcha ist eigentlich drin. Mail ist aber beim Kunden offensichtlich angekommen, und gespeichert ist es auch.
-
Wrapper funktioniert auch.
Verdammt........
Wrapper ist ein reiner IFrame, der, der Erfahrung nach oft eher unterbunden wird im Vergleich zum header:location(), was eine reine PHP-Umleitung ist
Rein von der Logik her gibt es doch nur wenige Stellen in WB
1. Datenbank liefert falsche Werte, entweder nicht eingetragen oder falsch verarbeitet
2. Das Modul wertet diese Daten falsch aus
3. es läuft im framework-Ordner falsch, wo die Seiten zusammengebaut werden.
4. Fehler im Template bei der Zuordnung der Page-Contents
2 und 3 können wir wohl ausschließen, hast du ja getauscht
Beispiel für Letzteres (4.)
definiert man die Blöcke über ob_start(), müssen sie wieder geschlossen werden, sonst überschreiben sie sich gegenseitig
ob_start(); //fetch MainContent
page_content(1);
$page_MainContent = ob_get_clean();
zum Einlesen und Schließen gäbe es mehrere Möglichkeiten
z.b. auch
ob_start();
page_content(1);
$page_MainContent = ob_get_contents();
ob_end_clean();
und als theoretisches Beispiel
wenn ich annehme, das auf den Seiten wie start.php nur ein Block aktiv ist, im Template aber mehrere geschalten werden, könnte das schon eine Ursache sein.
Was mir aber nicht gefällt, ist der Abbruch im Script, denn selbst wenn man hier einen Block überschreiben würde, wäre dieser vielleicht leer.
Ich kann dir anbieten, mit einem Zip der Dateien (ohne /media-Ordner) und einem Backup der Datenbank da mal rein zu schauen. Ist es ein WB-Problem, sollte es bei mir auch auftreten
Mailadresse: uwe@jacobi22.com
-
Sowas ist nicht vom Scanner, der nur auf XSS un son Krams guckt.
ICH WAR DAS NICHT :-D :-D :-D Das war'n die anderen 8-)
war das nicht die Alternativ-(Datei-)Suche, bei Adress-Tipfehlern? Wenn ja, würde ich das eher nicht aktivieren
Ist aktiviert!
Wobei ich mittlerweile glaube -oh Heiliger-, daß es allein der Serverkonfiguration geschuldet ist. Soviel kann man mit keinem CMS verkehrt machen. Gibts noch mögliche Fehlerquellen beim Multilanguage-Modul?
Vielleicht auch mal ein Rebuild (access-Files) machen?
Doof, daß man da nicht reingucken kann. Möglich wäre ja ein "Schuppen vonne Augen", un so...
MfG. Evaki
-
Beispiel für Letzteres (4.)
definiert man die Blöcke über ob_start(), müssen sie wieder geschlossen werden, sonst überschreiben sie sich gegenseitig
ob_start(); //fetch MainContent
page_content(1);
$page_MainContent = ob_get_clean();
zum Einlesen und Schließen gäbe es mehrere Möglichkeiten
z.b. auch
ob_start();
page_content(1);
$page_MainContent = ob_get_contents();
ob_end_clean();
und als theoretisches Beispiel
wenn ich annehme, das auf den Seiten wie start.php nur ein Block aktiv ist, im Template aber mehrere geschalten werden, könnte das schon eine Ursache sein.
Hmm... ja, ich definiere die Blöcke über ob_start. Mache ich eigentlich immer so - hat noch nie Probleme gegeben.
Die start.php hat 8 Blöcke! 5 verschiedene Blöcke, einer wird 2 mal und einer 3 mal aufgerufen.
Der erste Block sieht in der index.php konkret so aus:
<section class="full columns">
<?php
ob_start();
page_content(1);
$sContent1 = ob_get_clean();
if ($sContent1) {
echo PHP_EOL.$sContent1.PHP_EOL.PHP_EOL;
}
?>
</section>
Ist doch geschlossen, oder?
Was mir aber nicht gefällt, ist der Abbruch im Script, denn selbst wenn man hier einen Block überschreiben würde, wäre dieser vielleicht leer.
Der Abbruch geschieht offensichtlich nur beim Seitentyp Menu-Link oder wenn man einen Code-Block mit header Location einfügt. Da du ja sagtest, Menu-Link funktioniert auch über header-Location, muss es ja irgendwie damit zu tun haben...
Zip kann ich dir gerne fertig machen.
LG,
Astrid
-
<section class="full columns">
<?php
ob_start();
page_content(1);
$sContent1 = ob_get_clean();
if ($sContent1) {
echo PHP_EOL.$sContent1.PHP_EOL.PHP_EOL;
}
?>
</section>
Ist doch geschlossen, oder?
Jepp, ist geschlossen
Ist mir aber auch schon passiert, das ich bei Copy&Paste von einer anderen index.php eine Zeile vergessen hatte
Gerad, wenn man dann mehr als einen Block hat
-
Zip-Datei und Datenbank sind per Wetransfer unterwegs zu dir. Bin gespannt....
LG,
Astrid
-
ist angekommen - natürlich im Spam-Ordner :-D
gib mir mal 10 min
-
Du bist aber böse.... :wink:
hatten wir nicht gesagt: PHP-Fehlerberichte eingeschaltet lassen??
Wed, 13 Feb 2019 16:55:13 +0000 [E_NOTICE] \templates\ciriaco\index.php:[321] from \pages\it\biografia.php:[10] require "Undefined variable: follows"
Wed, 13 Feb 2019 16:55:13 +0000 [E_WARNING] \modules\socialbaker\include.php:[214] from \index.php:[78] require "Invalid argument supplied for foreach()"
-
Fehler im Menü unten, Zeile 318 und 321
nimmst das followBaker() raus, geht alles wieder
-
* hust...
hab nur einmal durch geklickt :oops: :oops: :oops: :oops: - 797 Fehlermeldungen oneforall, Code-modul, alle hervorgerufen von anyitems
-
Äh moment... followbaker ist draußen, geht trotzdem nicht.
Wo schalte ich die Fehlermeldungen ein??? Hab nix ausgeschaltet...?
Bei mir ist der errorlog leer..?
-
Autsch, gefunden.... ok, was heißt das jetzt - dass Anyitems und Topitems nicht mit WB 2.12.1 funktionieren?
"created: [Thu, 07 Feb 2019 09:28:40 +0000]
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"
Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_anyitems_start/include.php:[150] from /modules/code/view.php:[25] eval "Undefined offset: 1"
Wed, 13 Feb 2019 17:09:52 +0000 [E_WARNING] /modules/oneforall_anyitems_start/include.php:[150] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()"
Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 16 bytes"
Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 153 bytes"
Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Undefined offset: 1"
Wed, 13 Feb 2019 17:09:52 +0000 [E_WARNING] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()"
Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 16 bytes"
Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 202 bytes"
Wed, 13 Feb 2019 17:09:52 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Undefined offset: 1"
Wed, 13 Feb 2019 17:09:52 +0000 [E_WARNING] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()""
-
Habe die Fehlerberichte jetzt gerade mal bei einer anderen Kundenseite eingeschaltet, die ebenfalls mehrsprachig ist und wo ich Anyitems und Topitems intensiv mehrfach eingesetzt habe (ist allerdings noch eine 2.12.0). Auch hier gibt es zig ähnliche Fehlermeldungen. Aber das Menulink funktioniert da trotzdem. Und die Anyitems-Module tun trotz Fehlermeldung genau das, was sie sollen.
Da scheint zwar irgendein Reparaturbedarf nötig - aber der ist glaube ich nicht der Grund für die falsche Menulink-Zuordnung.
-
Wo schalte ich die Fehlermeldungen ein??? Hab nix ausgeschaltet...?
WB-Optionen -> erweiterte Optionen -> Servereinstellungen -> PHP Fehlerberichte
Production oder Development
Ich stell mal meine PHP-Version ein paar Stufen runter, bin grad bei 7.3.1
Habe die Fehlerberichte jetzt gerade mal bei einer anderen Kundenseite eingeschaltet, die ebenfalls mehrsprachig ist und wo ich Anyitems und Topitems intensiv mehrfach eingesetzt habe. Auch hier gibt es zig ähnliche Fehlermeldungen. Aber das Menulink funktioniert da trotzdem. Und die Anyitems-Module tun trotz Fehlermeldung genau das, was sie sollen.
lt Code ist es dort, wo in Wysiwyg-Abschnitten von OFA die WbLinks durch die realen Links ersetzt werden soll.
da geht die foreach-Schleife ohne Prüfung los und wenn kein WbLink drin ist, hat er natürlich keine ID in dieser foreach-Schleife
achso... Zeile 318 und 321 in der index.php des Templates hab ich mal komplett auskommentiert
-
bitte mal ersetzen in den Snippets
oneforall_anyitems_ start
oneforall_ausst
oneforall_top_buech er
jeweils um die Zeile 150 dies hier
Original
$pattern = '/[wblink(.+?)]/s';ersetzen mit
$pattern = '/\[wblink(.+?)\]/s';
und
$pattern = '/[wblink'.$page_id.']/s';ersetzen mit
$pattern = '/\[wblink'.$page_id.'\]/s';
idealerweise gleich die Versionsnummer hochsetzen
jetzt bekomme ich nur noch Bildfehler, weil ich die media's nicht habe
nun zum SocialBaker
-
Datei base.css im Template, Zeile 272
klein, aber feiner Vertipper,
a button, a:hover button, button a, button a:hover, .button a, .button a:hover, button a:visited, .button a:visited. button:hover, .button:hover, a:hover button {
color: #fff !important;
text-decoration: none !important;
}
ich schreib es mal größer - der rote Punkt gehört zu button:hover
.button a:visited. button:hover
-
layout.css // Zeile 340
das Komma vor der geschweiften Klammer
#menu li:hover > a, #menu li.menu-current, #menu li.menu-parent, {
color: #ffffff;
background: #ffb355;
}
-
bitte mal ersetzen in den Snippets
oneforall_anyitems_ start
oneforall_ausst
oneforall_top_buech er
jeweils um die Zeile 150 dies hier
Original
$pattern = '/[wblink(.+?)]/s';ersetzen mit
$pattern = '/\[wblink(.+?)\]/s';
und
$pattern = '/[wblink'.$page_id.']/s';ersetzen mit
$pattern = '/\[wblink'.$page_id.'\]/s';
idealerweise gleich die Versionsnummer hochsetzen
Habe ich gemacht - aber er nimmt die Änderungen nicht an... ??? Zumindest nicht über den CWSoft Addon File Editor, den ich dafür eigentlich sonst immer benutze.... Ich probiers mal über FTP.
-
Hab sie dir per Mail geschickt.
zum SocialBaker - ich kenn mich da nicht so aus, aber muß nicht $follows erst definiert werden??
Hab das jetzt so und funktioniert (nicht zutreffende Medias muß man dann halt entfernen))
<?php
$follows['twitter'] = 'mytwitter';
$follows['facebook'] = 'myfacebook';
$follows['googleplus'] = '+mygoogleplus';
$follows['linkedin'] = 'mylinkedin';
$follows['youtube'] = 'myyoutube';
$follows['vimeo'] = 'myvimeo';
$follows['instagram'] = 'myinstagram';
$follows['pinterest'] = 'mypinterest';
$follows['flickr'] = 'myflickr';
$follows['vk'] = 'myvkontakte';
if( LANGUAGE == "DE" ){
show_menu2(2, 26, SM2_ALL, SM2_ALL|SM2_NUMCLASS|SM2_PRETTY, false, false, '<ul id="footermenu">', followBaker($follows));
}
elseif( LANGUAGE == "IT" ){
show_menu2(2, 27, SM2_ALL, SM2_ALL|SM2_NUMCLASS|SM2_PRETTY, false, false, '<ul id="footermenu">', followBaker($follows));
}
?>
-
Hab es jetzt erst mal über FTP geändert - bekomme aber immer noch Fehlermeldungen für Zeile 139:
Wed, 13 Feb 2019 18:03:44 +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"
Wed, 13 Feb 2019 18:03:44 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 16 bytes"
Wed, 13 Feb 2019 18:03:44 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 153 bytes"
Wed, 13 Feb 2019 18:03:44 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 16 bytes"
Wed, 13 Feb 2019 18:03:44 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[139] from /modules/code/view.php(25) : eval()'d code:[2] ofa_top_buecher "unserialize(): Error at offset 0 of 202 bytes"
-
Hab sie dir per Mail geschickt.
zum SocialBaker - ich kenn mich da nicht so aus, aber muß nicht $follows erst definiert werden??
Das Followbaker brauche ich da überhaupt nicht - gibt keine Facebook-Seite oder ähnliches. Ich brauche nur das OpenGraph, was ja im index.php oben definiert war.
Nimm followbaker einfach ganz raus aus dem Menü.
-
Uff - aber nachdem ich diese pattern-Zeilen per FTP ersetzt habe, funktioniert ja das Menulink wieder.....!!!!!!!!! Sehe ich jetzt erst. Wow.... echt, daran lags? Was ist jetzt noch in Zeile 139?
-
Sach mal... die info.php von OFA sagt mir Version 1.0.9 :-o :-o :-o :-o
Aktuell ist 2.0.2.23
-
Sach mal... die info.php von OFA sagt mir Version 1.0.9 :-o :-o :-o :-o
Aktuell ist 2.0.2.23
Ummmmmmm..... ähhh... ja, also.... ups. OK, ich weiß, was ich morgen zu tun habe.... ;-)
-
Zeile 139 sollte das hier sein
$unserialized = @unserialize($values[$field_id]);
Wenn JA, ersetzt mal mit
$unserialized = __unserialize($values[$field_id]);
den hab ich bei mir aber nicht
-
da fehlt noch diese Funktion in der functions php
am besten, du schaust dir das von der aktuellen OFA-Version ab
function __unserialize($data) { // found in php manual :-)
$aRetval = $data;
if (is_serialized($data)){
$_ret = preg_replace_callback(
'!s:(\d+):"(.*?)";!',
function($matches) {return 's:'.strlen($matches[2]).':"'.$matches[2].'";';},
$data
);
if ($_ret) {$aRetval = @unserialize($_ret);}
}
return $aRetval;
}
-
Zeile 139 sollte das hier sein
$unserialized = @unserialize($values[$field_id]);
Wenn JA, ersetzt mal mit
$unserialized = __unserialize($values[$field_id]);
den hab ich bei mir aber nicht
Habe ich gemacht - liefert allerlei Fehlermeldungen im Frontend
There was an uncatched exception
Call to undefined function __unserialize()
in line (139) of (/modules/oneforall_anyitems_start/include.php):
Muss ich jetzt erst mal wieder rückgängig machen.
-
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)
-
Ich gehe das morgen alles durch, wird mir jetzt zu spät und ich werde unkonzentriert, macht gerade keinen Sinn mehr. Kann ich die OFA-Module einfach durch die neueste Version upgraden? Oder per FTP überschreiben? Bleiben dann die bereits angelegten Eingabefelder und Einträge oder fange ich dann von vorne an...?
-
Hast du die PHP-Fehlerberichte jetzt auf DEVELOPMENT??
Falls JA, stell mal auf Production - könnte das @ als Fehlerunterdrücker sein, d.h. da sind fehler eingeplant, sollen aber unterdrückt sein, z.b. wenn kein Serialize vorhanden ist
-
Hab ich jetzt auf Production umgestellt, jetzt kommen wieder Fehler in Zeile 150:
Wed, 13 Feb 2019 18:34:03 +0000 [E_NOTICE] /modules/oneforall_anyitems_start/include.php:[150] from /modules/code/view.php:[25] eval "Undefined offset: 1"
Wed, 13 Feb 2019 18:34:03 +0000 [E_WARNING] /modules/oneforall_anyitems_start/include.php:[150] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()"
Wed, 13 Feb 2019 18:34:03 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Undefined offset: 1"
Wed, 13 Feb 2019 18:34:03 +0000 [E_WARNING] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()"
Wed, 13 Feb 2019 18:34:03 +0000 [E_NOTICE] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Undefined offset: 1"
Wed, 13 Feb 2019 18:34:03 +0000 [E_WARNING] /modules/oneforall_top_buecher/include.php:[150] from /modules/code/view.php:[25] eval "Invalid argument supplied for foreach()""
-
OFA upgrade würde ich nicht auf dem Produktivsystem machen. Lieber eine Testumgebung anlegen.
-
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
-
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... ;-)
-
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. :-)
-
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.
-
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 :-D (Y)
Einige CMS haben sowas schon in der Vergangenheit gemacht.
Benutzt jemand schon ein entsprechendes Script?
MfG. Evaki
-
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
$pattern = '/[wblink(.+?)]/s'; durch
$pattern = '/\[wblink(.+?)]/s';und
$pattern = '/[wblink'.$page_id.']/s'; durch
$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:
"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:
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:
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
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:
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
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
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:
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..... :cry:
-
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
-
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.... :-(
-
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 (http://php.net/manual/de/function.serialize.php) 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.
-
Hast du denn am Anfang der include die function für __unserialize eingefügt?
Und weiter unten 2x ersetzt das alte @unserialize gegen __unserialize
-
@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
$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"
-
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.
-
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:
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:
// For wysiwyg replace [wblinkXX] by real link (XX = PAGE_ID)
Dann die italienische Biographie sowie Seite Ausstellungen. Fehler: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:
// For wysiwyg replace [wblinkXX] by real link (XX = PAGE_ID)
if ($types[$field_id] == 'wysiwyg') {
Was ist daran jetzt falsch???
-
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
// 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
-
Ja, danke - das wars dann. Jetzt auch in italienisch fehlerfrei..... :roll:
-
@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 :roll:
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
-
Neben der php_error.log.php wird auch eine install.log.php geschrieben. Somit hast du schon mal diese 2 Ansatzmöglichkeiten
-
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
-
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).
-
@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 :wink:
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 :roll: :roll: :roll:
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 Sicherheitswarnunge n egal waren, nun ein rot geschriebenes "Du kommst nicht in den Himmel" juckt?
-
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 Anwenderfreundlichk eit, 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.
-
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.
-
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... :-o :-o
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?
-
"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"
-
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 Sicherheitsprobleme n gibt's natürlich dennoch 'ne Rückmeldung an die DEV. Muß aber nicht von mir direkt kommen.
Wünsch Euch was! (Y)