WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => Topic started by: alexander@giebken.net on January 29, 2019, 12:08:56 PM
-
Ich habe auf 2.12 upgedatet.
Backend läuft.
Seitenstruktur (pages/sections/code) etc. scheint ok.
Mein Template habe ich eingespielt (läuft).
Wenn ich jetzt die Startseite aufrufe, kommt diese korrekt mit meinem Template.
Aber WB gibt sämtlíche Seiten des Seitenbaums untereinander auf der index.php aus.
Ich habe jetzt zwei Tage probiert und gesucht. Ich habe keine Ahnung, was ich noch machen kann.
Es wäre wirklich hilfreich, wenn jemand mir da weiterhelfen könnte.
-
Ich habe keine Ahnung, was ich noch machen kann.
Zuerst mal eine Gegenprobe mit dem mitgelieferten DefaultTemplate. Stelle dieses in den WB-Optionen als Frontend-Template ein.
Passiert hier das Gleiche, liegt es an WB, funktioniert alles, liegt es am Template
-
WB Default Template verhät sich genauso, wie meins.
-
wie lautet dein Menüaufruf von show_menu(2)?
-
show_menu2( $aMenu = 0, $aStart = SM2_ROOT, $aMaxLevel = SM2_CURR + 1, $aOptions = $options, $aItemOpen = '[if( level== 0 && class!=menu-first
&& sib!= 2
&& sib!= 3
&& sib != 11
&& sib != 12
&& sib != 13){
<li><hr class="menuDevider" /></li> } ]
<li class="menu-default">
<div class="[class]" id="menu_[page_id]">
<a href="[url]" target="[target]" class="menu-link"
title="[menu_title]">[menu_title]</a>
</div>', $aItemClose = '</li>', $aMenuOpen = '<ul class="menuUl">', $aMenuClose = '</ul>', $aTopItemOpen = false, $aTopMenuOpen = false );
Ok, ich geb zu - sieht etwas wild aus, lief aber bisher problemlos.
Im 'If' wird geprüft, wo die devider erscheinen sollen.
Kann bei Mondkalender-online.de (link in signatur) in Aktion betrachtet werden.
-
ich muß nochmal nachfragen: werden alle Inhalte der Seiten untereinander ausgegeben oder "nur" das gesamte Menü?
P.S.: bin erstmal zum doc, wird zwei, drei Stunden dauern
-
Das Menü erscheint nicht.
Nur alle Seiten untereinander. Abschnitt für Abschnitt, einer nach dem anderen.
Kann hier live erlebt werden:
http://mondkalender.giebken.net/
Irgendwo ist eine Seite mit einer Weiterleitung, die wird dann irgendwan ausgeführt.
Außerdem habe ich heraus gefunden, dass in "class.frontend.php" die DB-Abfrage
// Get default page
// Check for a page id
als Ergebnis alle Seiten zurück gibt. Ist das normal?
UND:
In der Abschnitts-Verwaltung haben alle Abschnitte im Feld "Ende Datum" "01.01.1970 02:00" drin stehen.
Das ist ein Problem, schätze ich.
Aber in der DB steht da überall eine "0".
Und wenn ich manuell das Datum in der Abschnitt-Verwaltung herausnehme, ändert sich das Verhalten nicht. Alle Seiten in einem Rutsch. Sieht lustig aus.
-
Du kannst den kompletten Inhalt des Ordners /framework löschen und diesen Inhalt aus dem Original-Paket -> https://wiki.WebsiteBaker.org/doku.php/en/downloads
wieder übertragen. All das, was im Frontend aufgebaut wird, baut sich in diesem framework-Ordner zusammen. Vielleicht gab es da beim Upgrade ein Übertragungsproblem .
-
Gute Idee, die hatte ich auch schon. Ändert nichts.
Ich habe bereits eine funktionierende 2.12 Installtion (diaet-rechner.net) und davon die WB-Dateien benutzt.
-
Hab grade getestet:
Wenn sämtlich Blöcke (page_content) Ausgaben in der index.php auskommentiert sind, dann kommen immer noch alle Seiten mit allen Blöcken/Abschnitten?!?!?
Uiuiui...
-
Ich bin nah dran...
2 Problme gefunden
framework/frontend.functiosn.php (ca. zeile 185)
1. Das SELECT zum Aufrufen alle Sectionen der Seite liefert viel zu viele Ergebnisse.
Ich hab das hier gebastelt, dass scheint zu funktionieren. Wäre lieb, wenn das mal einer durchtesten könnte;
// First get all sections for this page , `publ_start`, `publ_end`
$sqlSet = "SELECT ";
$sqlSet .= "`section_id`, `module` ";
$sqlSet .= "FROM `" . TABLE_PREFIX . "sections` ";
$sqlSet .= "WHERE `page_id`=" . $page_id . " ";
$sqlSet .= "AND `block`=" . $block . " ";
// $sqlSet .= "AND(" . $iNow . " BETWEEN `publ_start` AND `publ_end`) ";
// $sqlSet .= "OR (" . $iNow . " > `publ_start` AND `publ_end`=0) ";
$sqlSet .= "AND(" . $iNow . " > `publ_start` ";
$sqlSet .= "AND " . $iNow . " < `publ_end`) ";
$sqlSet .= "OR(`publ_start` != 0 AND " . $iNow . " > `publ_start` AND `publ_end` = 0 )";
$sqlSet .= "ORDER BY `position`; ";
2. Im Anschluss wird diese Prüfung durchgeführt:
if ( \is_numeric( $wb -> default_block_conte nt ) ) {
wobei ich überprüft habe, dass der Ausdruck "$wb -> default_block_conte nt )" true ist. Ist er.
Aber
var_dump( \is_numeric( $wb -> default_block_conte nt ) );"
liefert "false" zurück und der inhalt von if{} wird nicht durchlaufen.
und nu?
*achselnzucken*
-
So, also "default_block_conte nt" wird mit dem Wert "true" initialisiert. Weshalb er natürlich nicht numerisch sondern boolisch ist.
Also:
if ( $wb -> default_block_conte nt ) {
-schwups- läuft.
Ich suche dann mal weiter nach dem pub_end Bug....
-
Bug: publ_end
/admin/pages/section_save.php Zeile 146
if (\trim($_POST['end_date'.$section_id]) == '0' || \trim($_POST['end_date'.$section_id]) == '') {
$publ_end = 2147483647;
}
2147483647 ist der Timestamp vom 1.1.1970. Dieser Wert wird an mehreren Stellen im Code hart gesetzt. Ich verstehe nicht ganz, warum??
-
Nachtrag: das SQL von mir war doof.
Dieses ist besser:
$sqlSet = "SELECT ";
$sqlSet .= "`section_id`, `module` ";
$sqlSet .= "FROM `" . TABLE_PREFIX . "sections` ";
$sqlSet .= "WHERE `page_id`=" . $page_id . " ";
$sqlSet .= "AND `block`=" . $block . " ";
$sqlSet .= "AND(`publ_start` = 0 OR " . $iNow . "> `publ_start`) ";
$sqlSet .= "AND (`publ_end` = 0 OR " . $iNow . " < `publ_end`) ";
$sqlSet .= "ORDER BY `position`; ";
-
Hab soeben mal gescannt.
Habe den Eindruck bekommen, daß es für jacobi22 nützlich sein könnte, das Template durchzuschauen.
MfG. Evaki
-
was immer "gescannt" bedeutet - nix verstehen.
Abschließend:
Ich habe bei mir jetzt den Wert für "publ_end" im Code auf "0" gesetzt, wo zuvor der Timestampwert für 1970 stand.
Bisher geht alles.
Ich wäre dankbar, wenn mir das einer bestätigen könnte. Nicht dass da noch was dranhängt, was ich nicht weiß.
Evlt. triit das aber auc nur bei mir auf. Bei mir steht die Entwicklungsumgebnu ng auf "strict" (MySQL und PHP-Errors).
-
Bug: publ_end
/admin/pages/section_save.php Zeile 146
if (\trim($_POST['end_date'.$section_id]) == '0' || \trim($_POST['end_date'.$section_id]) == '') {
$publ_end = 2147483647;
}
2147483647 ist der Timestamp vom 1.1.1970. Dieser Wert wird an mehreren Stellen im Code hart gesetzt. Ich verstehe nicht ganz, warum??
Offensichtlich bastelst du gern und man bzw ich sollte hinterfragen, ob es Sinn mache, hier weiter zu helfen.
2147483647 ist nicht der Timestamp vom 01.01.1970. der wäre eine einfache Null. Mit diesem Datum begann die Zeitrechnung im Web.
2147483647 wäre Dienstag, Jan 19 03:14:07 2038 und der maximal mögliche Eintrag für das publ_end-Datum. Bis dahin geht die PHP-interne Timestamp-Berechnung. In 2038 rechnet man mit großen Problemen in der Zeitberechnung im EDV-wesen, Wieso, warum kannst du hier nachlesen -> https://de.wikipedia.org/wiki/Jahr-2038-Problem
Liest man 01.01.1970 irgendwo in der Ausgabe, bedeutet es, das das System den Auftrag bekommen hat, ein Datum zu ermitteln, daran aber gescheitert ist. Als Beispiel das filedate() in der Download-Gallery. Stimmt der Pfad zur Datei nicht, kann natürlich auch kein Datum gelesen werden. Damit wäre es Null oder eben 01.01.1970 00:00:00
Wenn bei dir nun das Datum des 01.01.1970 drin steht, gibt es dafür wenig Möglichkeiten.
1. das Feld publ_end in der sections-Tabelle wurde von Varchar(50) auf date umgestellt, irgendwann in der Vergangenheit. Bekommt solch Feld dann kein Datum, erscheint dieser 01.01.1970 und dies wird durch kein Upgrade-Script wieder korrigiert, weil es niemand auf dem Schirm hat, das irgendwer den Datumsfeldtyp ändern könnte
2. Der Code in der admin/section_save.php erwartet ein gültiges Datum im richtigem Format, wobei verschiedene Formate in den WB-Datumsformat-Einstellungen möglich sind. Dieses Datum wird dann in einen regulären Timestamp umgewandelt durch eine Javascript-Funktion (bedeutet: ohne JS auch kein Datum vom Kalender). Ist kein Datum gewählt, bleibt das Feld leer und wird dann mit oben zitiertem Code auf 2147483647 gesetzt, das ist die Berechnung aus (2 hoch 31)-1, somit bleibt das Datum unter der kritischen Grenze (siehe Wiki-Link)
Entweder, dein im JS-Kalender erzeugtes Datum hat ein ungültiges Format und kann daher nicht umgewandelt werden (wäre zu testen, wenn man deine DatumFormateinstell ungen in WB kennen würde) oder es wurde dran rum geschraubt, am Code direkt, mit einem anderem Backend-Theme, das vielleicht einen anderen Kalender benutzt, mit geändertem Datums-Format, das inkompatibel zum JS-Kalender ist, nur um ein paar Möglichkeiten zu nennen. Lt Google gibt es um die 1,4 Mio WB-Installationen, die seit der Einführung der Section-Zeitsteuerung alle die gleiche Technik nutzen. Die Begrenzung auf 2038 erfolgte in WB 2.11.0 und das sind auch schon wieder fast 2,5 Jahre. Wäre da ein grundsätzlicher Bug drin, sollte es dann nicht alle treffen??
Zum Code des Select sag ich nix, es ist OpenSource, kannst du ändern, wie du möchtest. Aus meiner Sicht sind die Bedingungen jetzt anders, Nebenwirkungen ungewiß. Habe aber wenig Interesse, mich da jetzt mit zu beschäftigen, denn ich bin mir ganz sicher, das ich hier nicht alles weiß.
Und nur um es mal gesagt zu haben: der WB-Code ist sicher kein Gott-Code, der nie und nimmer verändert werden darf, aber er hat eben in dieser Form und diesem Berechnungsprinzip über viele Jahre bei allen anderen funktioniert. Ich habe sicher einen ganz großen Teil der Postings hier gelesen über die Jahre und das wäre eines der wenigen Probleme, die hier (meines Wissens) noch nie aufgetaucht sind. Allerdings wurde jeder Buchstabe, jede Zahl im Code von Menschen getippt und von daher möchte ich auch einen möglichen Bug garnicht ausschließen, wenn der denn bestätigt ist. Und dann nehm ich auch gern ein Teil davon auf meine Kappe, weil ich den noch nicht entdeckt habe.
Habe den Eindruck bekommen, daß es für jacobi22 nützlich sein könnte, das Template durchzuschauen.
Ja, dachte ich bis zu meiner Abfahrt auch, weiß ja keiner, wie ich es im Template dann auslesen (Stichwort: Onepager)
Aber jetzt mit der Codeschrauberei nur noch live oder über ein komplettes Backup (Daten + Datenbank vor dem Upgrade)
-
Lieber jacobi22,
da ist wohl ein falscher Eindruck entstanden.
"Basteln" ist wirklich nicht mein Hobby und das mache ich nicht gerne.
Ich entwickele Software und bin da eher kreativ unterwegs.
Nun musste ich updaten, wegen php7 und da sind dann halt diese Schwierigkeiten aufgetreten.
Und ja, es macht viel Sinn jemandem zu helfen, auch wenn er sich grade mit irgendwelchen Problemen rumschlägt, die er womöglich irgendwann selber lösen kann.
Das Problem mit dem Datum kenne ich. Ich betreue den Mondkalender, da war das schon 2016 ein echtes Problem mit dem Datums-Bug.
"(...)diesem Berechnungsprinzip über viele Jahre bei allen anderen funktioniert.(...)"
-> In meiner vorherigen Version (2.8.3) war der Wert "2147483647" aber nicht für "publ_end" verwendet worden.
Und zum Schluss, mein guter jacobi22, vielen Dank für Deine ausführliche Erklärung. Es ging mir nicht um Schuldzuweisung, sondern um Problemlösung. Jeder ist Mensch und alle machen Fehler. Das ist nicht schlimm. Schlimm ist nur, wenn niemand hilft und die Probleme nicht gelöst werden.
Danke Dir.
-
Und ja, es macht viel Sinn jemandem zu helfen, auch wenn er sich grade mit irgendwelchen Problemen rumschlägt, die er womöglich irgendwann selber lösen kann
Ja, wenn man davon ausgehen kann, das man vom gleichem Kram spricht. Das ist hier aber nicht (mehr) der Fall
diesem Berechnungsprinzip über viele Jahre bei allen anderen funktioniert.(...)"
-> In meiner vorherigen Version (2.8.3) war der Wert "2147483647" aber nicht für "publ_end" verwendet worden.
siehe hier
Die Begrenzung auf 2038 erfolgte in WB 2.11.0 und das sind auch schon wieder fast 2,5 Jahre. Wäre da ein grundsätzlicher Bug drin, sollte es dann nicht alle treffen??
Es ging mir nicht um Schuldzuweisung
Ich zitiere nochmal
Bug: publ_end
/admin/pages/section_save.php Zeile 146
if (\trim($_POST['end_date'.$section_id]) == '0' || \trim($_POST['end_date'.$section_id]) == '') {
$publ_end = 2147483647;
}
Nehmen wir das Stück Code auseinander, um es zu verstehen. Die Erläuterung, warum hier kein unendlicher Wert mehr möglich ist, habe ich oben angerissen, den Rest der Erklärung liefert Wiki.
Wird eine Zeiteinstellung in der section-Verwaltung gemacht, egal, ob hinzugefügt oder entfernt, wird beim Übermitteln ein POST gesendet, dieser POST hat u.a. das Element "end_date" plus die zu jeder Section übermittelten section-ID
Wurde ein bereits vorhandenes Datum einer section gelöscht, ist end_date == 0, war noch nie ein Wert eingestellt, ist end_date == leer, also ''
Die Funktion trim entfernt aus diesem Wert mögliche Whitespaces (und eventuell festgelegte andere Zeichen) am Beginn oder am Ende des Wertes, so das nur die reine Null oder ein komplett leerer Wert und nicht etwa ein unsichtbares Zeichen übermittelt wird, eben der Whitespace.
zum Code: (auf "deutsch")
Wenn end_date.Section-ID gleich Null oder end_date.Section-ID gleich leer, dann ersetze dies mit der Zahl 2147483647, also dem Timestamp der letzten sicheren Zeitberechnung in PHP (zum aktuellem Zeitpunkt)
Wurde ein anderes Enddatum festgelegt, ist end_date.Section-ID weder Null, noch leer und dieser Code greift nicht, es wird dann also der Timestamp für das eingestellte Datum eingetragen.
Dieses Stück Code ist also kein Bug
Die Berechnung davor wäre aber schon verbesserungswürdig :oops: :oops: :oops:
Ich habe es mit ein paar alten Backups mal durch geschaut. Früher (vor WB 2.11.0) war es üblich, die Werte publ_end und publ_start als 0 (Null) zu speichern. Diese Null wurde dann beim Einlesen der Section-Daten auf leer gesetzt
admin/sections.php ~ Zeile 401 (aus WB 2.10.0)
// set calendar start values
if($section['publ_end']==0)
{
$tpl->set_var('VALUE_PUBL_END', '');
} else {
$tpl->set_var('VALUE_PUBL_END', date($jscal_format, $section['publ_end']+TIMEZONE));
}
ab WB 2.11.0 lautet der Code aber anders, da nun statt der Null die drin steht
sections.php ~ Zeile 427
if($publ_end==2147483647)
{
$tpl->set_var('VALUE_PUBL_END', '');
} else {
$tpl->set_var('VALUE_PUBL_END', \date($jscal_format, $section['publ_end']+TIMEZONE));
}
da hier aber statt der 2147483647 nach einem Upgrade von Version älter als WB 2.11 eine Null steht, wäre dies richtig
if(($publ_end==2147483647) || ($section['publ_end']==0));
{
$tpl->set_var('VALUE_PUBL_END', '');
} else {
$tpl->set_var('VALUE_PUBL_END', \date($jscal_format, $section['publ_end']+TIMEZONE));
}
das würde beide Sectionen abdecken.
Du kannst nun diesen code verwenden oder in der Sectionverwaltung jeder Seite die X-Buttons nutzen, um die Datumsangaben beim Enddatum zu löschen
Danach sollte alles normal laufen
Ich informiere Dietmar darüber