ugradee von 2.8.3 - stell mich dumm an

[jacobi22]

Du könntest  natürlich gerne den datenbankbackup und die Dateien haben, aber nicht die  setup.ini.php

bräuchte ich nicht
Am Ende ist es deine Entscheidung - für mich brauch ich das nicht

[hgs]

Hallo!
Also wie gesagt ich möchte von 2.8.3 auf 2.12.1 upgraden, was ja gehen soll, eigentlich.

Kann es sein das du eine WB 2.8.4 da im Einsatz hast? Eine "setup.ini.php" gibt es in den offiziellen Versionen 2.8.3 bis 2.12.1 nicht.

[gottfried]

Hi!

Ja klar, hab dir die downloadlinks als PM geschickt.

[gottfried]

@hgs

ääh - ja - eine 2.8.4 - ich seh nicht sonderlich gut trotz brille und hab mich wohl vertippt.

[hgs]

Ja klar, ...

Heist, es ist eine 2.8.4?
Dann bin ich raus, keine Erfahrung mit dieser Experimental Version, Sorry

[gottfried]

Hi!

Ich hab also gar keine offizielle Version ?

Spaßig.

 

[gottfried]

Hallo!

HGS gat mir nun schonend beigebracht, daß ich ja eine inoffizielle 2.8.4 als Basis für paar Kundenprojekte genommen hab.
Da bin ich ja selber schuld. Die hat mir aber gut gefallen und war jahrelang recht stabil.

Auf jeden Fall hilft mir diese Information aber weiter.
Bin froh, daß hgs das gesehen hat!
Auch vielen Dank an Jakobi22 für seine Unterstützung.

Ich sag, wenn ich weitergekommen bin.

[jacobi22]

eine inoffizielle 2.8.4

es gibt keine "inoffizielle" 2.8.4
Sie wurde damals veröffentlicht, war also offiziell - wenn auch nur für Stunden

das Upgrade geht über die 2.10.x oder 2.11.x - oder über manuelle Eingriffe wie manuelles Anlegen einer korrekt befüllten config.php auch mit 2.12.x

[jacobi22]

das Upgrade geht über die 2.10.x oder 2.11.x - oder über manuelle Eingriffe wie manuelles Anlegen einer korrekt befüllten config.php auch mit 2.12.x

Hier eine Anleitung zum Upgrade der WB 2.8.4. auf WB 2.12.1

Das Vorhandensein einen Dateien- und Datenbank-Backups setze ich voraus

1. Lösche diese Ordner der Version 2.8.4 komplett

account
admin
framework
include
search

sowie unter modules die Ordner
- captcha_control
- code
- droplets (ggf Sicherung der vorhandenen Droplets vorher durchführen und in einen anderen Ordner legen)
- fckeditor
- form
- jsadmin
- menu_link
- MultiLingual
- news
- output_filter
- SecureFormSwitcher
- show_menu2
- wrapper
- wysiwyg

außerdem im WB-Hauptverzeichnis die Dateien

index.php
upgrade-script.php

Benenne die Datei setup.ini.php vorerst um, der Name ist beliebig, Dateiendung sollte .php bleiben. Dies dient nur dazu, die Werte der aus dieser setup.ini.php in die config.php zu übertragen. Danach kann und sollte die setup.ini.php gelöscht werden

Es empfiehlt sich, eine möglicherweise vorhandene Datei .htaccess für die Dauer des Upgrades umzubenennen, z.b. in htaccess.txt

##############################

2. du benötigst eine funktionierende Datei config.php. Überschreibe dazu den Inhalt der in WB 2.8.4 enthaltenen Datei mit diesen Inhalt oder lege, wenn nicht vorhanden, eine solche Datei mit einem editor wie Notepad an

Inhalt der Datei
Der Code kann so direkt kopiert werden. Die jeweiligen Werte sind anzupassen (siehe Kommentare). Die Datei config.php wird im Upgrade-Prozess neu geschrieben. Die von mir eingefügten deutschsprachigen Kommentare sind dann verschwunden, die englischen bleiben stehen, sie enthalten jeweils Datum und Versionsangaben des zuletzt durchgeführten Upgrades.


<?php  // gehoert zum Script, muss mit kopiert werden
/*
 *** auto generated config file for 2.12.1
 *** WebsiteBaker upgrade from 2.8.4 to 2.12.1
 *** created at 2019-01-16 02:00:15 Europe/Berlin
 */
// define('DEBUG', false);
define('DB_TYPE',         'mysqli');
define('DB_HOST',         'localhost'); // ggf anpassen (siehe auch Datei setup.ini.php)
define('DB_PORT',         '3306');
define('DB_NAME',         'xxxxxxx');  //  (siehe auch Datei setup.ini.php)
define('DB_USERNAME',     'xxxxxxx');  //  (siehe auch Datei setup.ini.php)
define('DB_PASSWORD',     'xxxxxxx');  //  (siehe auch Datei setup.ini.php)
define('DB_CHARSET',      'utf8_unicode_ci');  // wer Emoticon im CKEditor benutzen möchte, benötigt hier utf8mb4_unicode_ci
define('TABLE_PREFIX',    'wb_');      //  (siehe auch Datei setup.ini.php)

define('WB_URL',          'https://...........'); // no trailing slash or backslash!!  - ist anzupassen
define('ADMIN_DIRECTORY', 'admin'); // no leading/trailing slash or backslash!! A simple directory name only!! - anpassen, wenn anderer Name für das Verzeichnis erwünscht ist, der admin-Ordner muß dann manuell umbenannt werden

require __DIR__.'/framework/initialize.php';
// --- end of file ----------------------------------



P.S.: ein schließendes ?> ist nur notwendig, wenn nach dem PHP-Code noch anderer Code wie HTML erscheint, in reinen PHP-Dateien wie dieser config.php ist es nicht notwendig



3. Sichere ein ggf im Root-Ordner von WB enthaltenes Favicon

4. Übertrage nun die WB 2.12.1 in diese WB-Installation - alles überschreiben

5. Logge dich ins Backend ein. Du wirst von dort entweder direkt zum UpgradeScript geleitet oder siehst auf der Startseite des Backend einen Link zum Starten des Upgrade-Scripts.
   Aktiviere im Upgradescript alle drei Checkboxen und Klicke auf START.

6. Angezeigt wird das Protokoll des Upgrade-Scripts. es sollte am Ende die zwei Buttons "Kick me to Frontend/ Kick me to Backend" zeigen und keine roten Warnmeldungen enthalten. Bleibt das Upgrade unterwegs stecken und die genannten Buttons werden nicht gezeigt, starte das Upgrade erneut mit einem Reload der Seite (F5-Taste). Der Vorgang kann beliebig oft wiederholt werden. Ursache wäre, das das Script zu Beginn die benötigten Teile der Datenbank ausliest und damit feste Vorausetzungen hat. Im Verlauf schreibt es dann neue Settings in die Datenbank. Kommt es nun an einen Schalter, der beim ersten einlesen "falsch" steht, weil dieser beim Auslesen der alten WB-Version z.b. nicht gesetzt war, bricht das Script ab. Durch den Reload liest es nun das neu geschriebene ein und geht weiter im Script

7. Wechsel nun ins Backend und lade die Seite nach Anzeige erneut, wenn das obere Menü nicht komplett oder miniklein dargestellt wird. In dem Fall befindet sich noch altes kram im BrowserCache, der durch den Reload überschrieben wird. Eine korrekte ansicht wäre dies hier


8. Gehe zu Optionen -> erweiterte Optionen anzeigen -> Servereinstellungen -> PHP-Fehlerberichte und wähle dort "Production"- Speichere diese Einstellungen

9. Gehe in die Seitenübersicht und kontrolliere Seite für Seite, Section für Section

10. Schaue, ob du für Module, die nicht mit dem WB-Paket geliefert wurden, im Addon-Bereich eine neue Version bekommst, z.b. Foldergallery. Das gern genutzte SimplePageHead wäre zu testen, keine Ahnung, ob es da was neues gibt. Ich selbst nutze es nicht mehr, weil ich keine Module dieser Art nutze und für meine eigenen eine andere Methode verwende

11. Module wie wblib, libraryAdmin, lib_jquery wurden meines Wissens nicht mehr weiter gepflegt. User dbs kann da eventuell Tips für Alternativen geben, ich habe aber vielfach hier gelesen, das man sich von diesen Addons verabschiedet hat. Bitte korrigieren, wenn ich hier falsch liege

12. Kontrolliere deine Droplets. Vorhandene, in der Datenbank gespeicherte Droplet werden im Upgrade nicht überschrieben und nicht verändert. Es ist aber möglich, das dafür im Ordner modules/droplets/example eine neue Version vorhanden ist.
    Verwendet ein Droplet oder auch ein Modul eine Zeile mit dem Code $wb->preprocess(), ist diese Zeile auszukommentieren oder zu löschen. Diese Funktion war der Vorgänger des heutigen OutputFilters und wurde 2011 schon in WB entfernt. Bis WB 2.12 wurde aber keine Fehlermeldung dafür gesetzt

13. Kontrolliere unter AdminTools -> OutputFilter die dort gesetzten Einstellung. Im Normalfall ist dort bis auf JQuery UI, OPF und RelUrl alles gesetzt. Wer das Modul OPF nutzt, muß dies natürlich aktivieren.
Beachte auch die Einstellungen für das Ersetzen von @ und Punkt in Mailadressen, Standard ist [at] und [dot]

14. Kontrolliere in den WB-Optionen zuerst die Einstellung für die Datenschutzrichtlin ie und wähle bei aktivierter Datenschutzrichtlin ie eine Section mit der Datenschutzerklärun g aus, die dann in der Zustimmungsfrage der Formulare in Form und Newskommentare verlinkt wird.

15. das alte Backend-Theme der WB 2.8.4 (WbTheme) und ggf davon erstellte eigene Theme-Kopien sind nicht zu WB 2.12.x kompatibel. Der bzw die Ordner kann nach Abschluß des Upgrades gelöscht werden. Bitte aber nicht vor dem Start des UpgradeScripts löschen, da dies die Anmeldemaske zum Backend-Login enthält.


Ende der Anleitung


getestet mit WB 2.8.4 Rev 1866 (war nur für den Community-Test) und Rev 2101 (offiziell für 6Std (?) oder so) - es gab noch eine Rev 2103, die die Reparaturen zu 2101 enthielt, aber (warum auch immer) damals nicht zeitnah veröffentlicht wurde. Beide liefen bei mir bis PHP 7.1, aber nicht mehr ab 7.2
Upgrade durchgeführt von diesen beiden Versionen auf WB 2.12.1 Rev 188 (Version aus dem Download ohne Fixes) mit PHP 7.2.3 und PHP 7.3.0

@ gottfried - Punkt 15 hatte ich in der Mail vergessen. Das WbTheme ist auch noch im Zip enthalten, bitte löschen, wenn fertig

[astricia]

Ein grundsätzlicher Tip von mir für die, die noch mit latin1 arbeiten (Blick in die Datenbankverwaltung / Übersicht der Tabellen reicht):
Erst die Konvertierung auf UTF8 abschließen und dann erst upgraden.
Ich weiß, das viele Leute diese Zeichenkonvertierun g im Upgrade erwarten, dem ist aber nicht so, zu komplex, zu gefährlich.

Habe heute das zweite Update gemacht - und dabei auch extra darauf geachtet, dass wirklich UTF8 eingestellt war. Auch in der Datenbank bei wb settings stand utf-8.

Leider waren die Umlaute nach dem Upgrade trotzdem alle verhackstückelt. Hat mich jetzt gerade 1,5 Stunden gekostet, das alles wieder zu richten, weil es viele einzelne Abschnitte und Seiten gab.

Interessanterweise gab es dann auch ganz vereinzelt einige Abschnitte, bei denen es OK war - ich habe aber keine Ahnung, was bei denen anders war als bei den anderen. Kannst du mir kurz einen Überblick geben, wie genau ich so etwas VOR dem Upgrade feststelle und ändere, damit mir das beim nächsten Mal nicht wieder passiert?

Danke,
Astrid

[jacobi22]

Habe heute das zweite Update gemacht - und dabei auch extra darauf geachtet, dass wirklich UTF8 eingestellt war. Auch in der Datenbank bei wb settings stand utf-8.

Leider waren die Umlaute nach dem Upgrade trotzdem alle verhackstückelt. Hat mich jetzt gerade 1,5 Stunden gekostet, das alles wieder zu richten, weil es viele einzelne Abschnitte und Seiten gab.

bitte nicht persönlich nehmen, aber ich denke, du hast die Problematik noch nicht richtig verstanden.

Früher war es üblich, das Webseiten im deutschen Sprachraum den Zeichensatz latin1 oder einer seiner Abwandlungen wie z.b. latin1_swedish benutzt haben.
Mit diesem Zeichensatz werden Sonderzeichen wie unsere Umlaute usw innerhalb der Datenbank kodiert.
Über den in der Auslesedatei (i.d.R der Browser) eingestellten Zeichensatz wird dann der SQL-Code wieder zurück in für uns lesbare Zeichen decodiert.
Einzig möglicher Zeichensatz in WB ist der Standard-Zeichensatz von PHP, also UTF8. Da in deiner Datenbank aber keine UTF8-Zeichen vorhanden sind, sondern mit latin1 kodierte, kann der Browser dies nicht übersetzen, denn der soll und kann ja nur UTF8. Und darum kommt es dann zur Darstellung dieser UTF-Zeichen wie z.b. hier Grüße im Wort "Grüße"

UTF8 ist eine andere Form der Codierung. Mit dieser ist es möglich, alle Schriftzeichen der Welt darzustellen, egal, ob chinesisch, arabisch oder kyrillisch. Latin1 hat dagegen nur einen begrenzten Zeichensatz.  Zudem ist ein UTF8-Zeichen ist mit seinen 2 Stellen auch kürzer als die meist 5-stelligen HTML-Special-Chars in Latin1

Heutzutage verfügen auch die Editoren über interne Konverter, um SQL-Code in lesbare Buchstaben umzuwandeln, sichtbar z.b, wenn man eine reine SQL-Datei in Notepad++ öffnet

Hier ein Bild davon aus einem Backup in Notepad++



und nun das Gleiche in reinem SQL-Code aus einer per utf8 kodierten Datei  (gleiche Stelle der Datei) in einem SQL-Editor



das Gleiche noch einmal in Latin1 mit HTML-Special-Chars (siehe etwa mittig im Feld "name")




Um nun eine alte per Latin1 kodierte SQL-Backup-Datei nach UTF8 zu kodieren, braucht es eigentlich einen Konverter. Im begrenztem Rahmen reicht dafür Notepad++
Sollte es da nicht automatisch geschehen (ist abhängig von den Einstellungen), geht es dort auch über search&replace. Für deutsch-sprachige Seiten sind es ja meist nur ä, ö, ü, ß bzw &auml; &ouml; usw, und das für Groß- und Kleinbuchstaben getrennt. Die Kodierung sollte auf UTF8 stehen. Zu ersetzen wären die Specialchar's mit Buchstaben in Reinschrift, also &auml; mit ä ersetzen, &Auml; mit Ä

Irgendwo habe ich auch mal ein Konvertertool gesehen, hier oder in den Downloads, finde es aber nicht auf die Schnelle.
Dies hat dann auch gleich die Tabellen umgeschrieben, z.b. so etwas hier

  `ftp_server` varchar(255) character set latin1 collate latin1_general_ci NOT NULL,

Als Vorlage zum Abschauen dient z.b. eine Backup-Datei einer WB-Installation ab WB 2.10.0
Dies läßt sich aber auch in PHPmyAdmin per (vielen) Mausklicks erledigen (theoretisch für jede Tabelle und jedes Text-Feld einmal)

Nach dem Ersetzen wird diese dann in PHPmyAdmin oder Adminer usw wieder in die Datenbank importiert.

Die Änderung der sogenannten Table Collation bzw Field Collationen legen fest, mit welcher Kodierung Daten in die Tabelle geschrieben werden, es wirkt also nur beim Speichern neuer und geänderter Datensätze



 

[astricia]

bitte nicht persönlich nehmen, aber ich denke, du hast die Problematik noch nicht richtig verstanden.

Da hast du wohl recht und ich nehme das auch gar nicht persönlich - ich mag es gar nicht und fühle mich sehr unsicher dabei, auf SQL-Ebene rumzuhantieren. Aber wenn ich dich jetzt richtig verstanden habe, komme ich da nichtdrum herum.

Nur noch mal zum Verständnis. Die Vorgehensweise wäre wie folgt:
- Datenbank runterladen
- Sicherheitskopie machen (sicher ist das...)
- Datenbank mit dem Notepad++ Editor öffnen
- Überprüfen ob das reine Öffnen bereits die Umlaute bereinigt hat
- Falls nicht, hier ein manuelles Bereinigen über die Suche und Ersetze Funktion (so hatte ich das in den einzelnen Textabschnitten hinterher gemacht..)
- Datenbank dann wieder speichern
- Geänderte Datenbank hochladen

Ich habe jetzt mal eine gespeicherte Datenbank mit dem Notepad++ geöffnet. Da wird bei mir nichts konvertiert. Ich finde sowohl HTML Entities (also &auml; für ä) als auch diese Hieroglyphen (ä für ä). Muss ich dann beides über Suchen+Ersetzen ändern, oder nur die Hieroglyphen?

Ersetze ich also ä durch ä oder ä durch &auml; ? Und muss ich noch irgendwas ersetzen außer ä,ö,ü,Ä,Ö,Ü,ß ?

Und mache ich das Ganze VOR Upgrade auf 2.12.1 oder nachher?

Sorry für die doofen Fragen, aber bei SQL bin ich echt raus. Gibts da nix in WB, was man installieren kann, dass das dann automatisiert gemacht wird?

[jacobi22]

Sorry für die doofen Fragen

es gibt keine doofen Fragen   

Und mache ich das Ganze VOR Upgrade auf 2.12.1 oder nachher?

spielt keine Rolle
Wenn du es vorher machst, könntest du es sogar in der alten Version schon testen, die noch die Zeichensatzeinstell ungen in den WB-Optionen haben

Ersetze ich also ä durch ä oder ä durch &auml; ? Und muss ich noch irgendwas ersetzen außer ä,ö,ü,Ä,Ö,Ü,ß ?

kommt auf die Einstellungen in Notepad an (Kodierung soll auf UTF8 stehen)
dann aber ä durch ä und &auml; durch a - wobei Letzteres nicht ganz so wichtig wäre

Ich finde sowohl HTML Entities (also &auml; für ä) als auch diese Hieroglyphen (ä für ä). Muss ich dann beides über Suchen+Ersetzen ändern, oder nur die Hieroglyphen?

Ja, wenn man einmal dabei ist, beides. Zwingend wäre aber ä für ä
Ursache ist hier entweder eine Umstellung in der Datenbank, vielleicht wurde manuell das Charset geändert oder vom Anbieter beim Upgrade der Serversoftware
Auch möglich: diese Textteile wurden mit älteren FCK- oder CKEditor-Versionen eingefügt. Dort wurde beim Speichern noch mal ein htmlspecialchars() benutzt. Dies stammt noch aus den Zeiten unterschiedlicher Zeichensätze. Die Browser können mit Zeichensatz UTF8 alle diese HTMLSpecialChars (like &auml;) lesen und "übersetzen" und einige ältere Module

[gottfried]

Hallo Jacobi !

Ich hab den upgrade meiner 2.8.4 auf die aktuelle 2.12.1 nach deiner Beschreibung selber durchgeführt.
Mit einer config.php
Alles ist grün .....
Ich kann mich danach in das Backend einloggen und mir das alles ankucken.
Nur wenn ich aus dem Backend die aktuelle Seite aufrufe, lande ich immer auf der Startseite.
Auch wenn ich das Frontend aufrufe, komme ich nicht über die hinaus.

Dann habe ich die Seite, die du upgegradet hast auf den Server gelegt. Wenn ich da versuche in den admin zu kommen, kommt eine weiße Seite.
Aber ich komme im Frontend genau soauch nicht über die Startseite hinaus.

(ich hab momentan auf dem Server 3 Versionen und 3 Datenbanken, die sich nicht überschneiden)

Die Startseite läuft quasi in Schleife.

Das kann ja nur noch eine Kleinigkeit sein?

php ist immer noch 5.6 ?

 

[jacobi22]

Hast du zufällig in den WB-Optionen -> erweiterte Optionen oben unter allgemeine Einstellungen den Punkt URL Umleitung zur Homepage aktiviert?

der macht nämlich genau das

Werde mir deine Installation noch einmal "auflegen" - die war nach dem PC-Crash schon wieder fort. Wird aber heute nix mehr, hab zuviel aufzuholen

[gottfried]

Hallo Jacobi!

nö - die Url Umleitung zur Homepage ist deaktiviert.

Foldergallery, Libraryadmin u.s.w sind nur zufällig drin, weil ich einfach eine andere Anwendung kopiert habe.
Die Seiten sind eigentlich ganz einfach.

Bis auf die erste. Die hat ein eigenes Template ohne Menü und leitet nach 3 sec auf die zweite weiter. (Künstlerminimal)

Das Standardtemplate ist aber das ohne Weiterleitung

Da ist ein Sectionpicker auf der zweiten Seite (mit Menü) auf die erste , das Menü soll also quasi verzögert auftauchen.

eilt nicht rasend.

 

[gottfried]

Hallo! 

Ich hab nun etwas weiter "gebastelt". Das Backend funktioniert mit nun php 7.3 bisher störungsfrei.

Ich habe im Frontend immer noch den Effekt, daß immer die erste Seite aufgerufen wird, was ich auch (vom Backend aus) ansehen will.

Ich hab nun kapiert, daß die Seiten nur nicht mit Ihren zugewiesenen oder dem StandardTemplate aufgerufen werden sondern immer mit dem Template der ersten Seite.

Es steht zwar der link auf die richtige Seite in der Adressleiste des Browsers aber im Sourcecode ist klar das Template der ersten Seite erkennbar, das nur für diese verwendet wird.

Nur bei dieser ersten Seite ist eigentlich das Template schon die Seite. Also  klar identifizierbar.

ist die Beobachtung hilfreich?

[hgs]

Ich glaube, das deine Aussage so nicht richtig ist.

Ich hab nun kapiert, daß die Seiten nur nicht mit Ihren zugewiesenen oder dem StandardTemplate aufgerufen werden sondern immer mit dem Template der ersten Seite.

Denn diese Einstellung wird im BackEnd unter "Optionen-->Standardeinstellung-->Template" gemacht.
Jede neue Seite wird dann erst mal mit diesem Template verknüpft.
Um einer Seite ein anderes Template zuzuweisen gehst du über "Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen" ändern für genau diese Seite.
Kann leider keine Bilder mit anhägen,Sorry

[gottfried]

Hallo HGS!

Denn diese Einstellung wird im BackEnd unter "Optionen-->Standardeinstellung-->Template" gemacht.
Jede neue Seite wird dann erst mal mit diesem Template verknüpft.
Um einer Seite ein anderes Template zuzuweisen gehst du über "Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen" ändern für genau diese Seite

Ja genau so sollte es sein, so mach ich das seit Jahren, wenn ich verschiedene Templates verwende, so ist es bei mir aber nach der Umstellung eben nicht mehr.

Normal wähle ich unter Optionen-->Standardeinstellung en_Template jenes, das ich am häufigsten verwende
und suche mir unter Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen das gewünschte besondere heraus falls die Seite ein anderes haben soll.

Ich habe nun bei mehreren Seiten, bei denen ich Standard eingestellt habe das dedizierte gewählt, das funktioniert aber eben auch nicht.

das habe ich ja  versucht zu formulieren.

ich meine damit auch wenn ich

Um einer Seite ein anderes Template zuzuweisen gehst du über "Seiten-->dort auf den Stift-->Template (steht auf Standarttemplate-->Auswahl treffen" ändern für genau diese Seite

mache ruft der wb aus dem Backend diese Seite nicht mit dem so gewählten Template auf sondern immer mit dem der ersten Seite.

[jacobi22]

Nur mal als Übersicht, wie es sein sollte

Voraussetzungen bei mir gerade: Unter WB-Optionen ist das DefaultTemplate als Standard eingestellt.
Seite 1 nutzt in den Seiteneinstellungen -> Template die Einstellung "Standardeinstellung en"
Seite 2 nutzt in den Seiteneinstellungen -> Template die Einstellung "ResponseBlue"

WB-Top-Menu oben in der Mitte
- geht immer auf die Startseite, wenn man nicht gerade eine andere Seite als die oberste im Seitenbaum bearbeitet. Bearbeite ich meine Seite 2 in "Seite verändern", "Einstellungen bearbeiten" oder "Abschnitte verwalten", verlinkt auch das Haus im Top-Menü auf diese Seite

Seitenübersicht
geht immer direkt auf die Seite, die gerade angewählt wurde,

Vorausetzungen sind immer eine entsprechende Sichtbarkeit (nicht "delete", nicht "none"), sowie die erforderlichen Berechtigungen
Verwendet wird auf jeder Seite immer das Template, das in dessen Seiteneinstellungen eingestellt ist, genauer: das, was in der pages-Tabelle der DB für diese Seite eingetragen ist.

Als Fallback gibt es eine Absicherung, die für den Fall eintritt, das ein hinterlegtes Template nicht erreichbar ist (Ordner entfernt oder umbenannt). In diesem Fall wird das Standard-Template unter WB-Optionen verwendet. Ist auch das nicht erreichbar, crasht das Dingen.

Was sich zuletzt geändert hat, ist die Unterbindung von Verzeichnis- oder Templatenamen mit Bindestrich. Ein neues Template mit Bindestrich ließe sich dann nicht mehr installieren, es würde aber, per FTP auf den Server kopiert und unter Erweiterungen -> Erweitert eingelesen, auch funktionieren.
Wurde solch ein Template aber nun umbenannt und der Bindestrich mit Unterstrich ersetzt in Ordnername und info.php, steht auch nach dem Einlesen dieser Informationen das alte Template mit Bindestrich in der Datenbank und muß hier neu eingestellt werden. So etwas in der Art vermute ich auch bei dir.

Geht es um die Seite, die ich vor kurzem hatte?

[gottfried]

Hallo Jakobi!

Ich bin gottfried, nicht astricia, die sich auch in dieser thread meldet.

Ich denke aber du antwortest auf den vorhergehenden Eintrag von mir.

Du hattest zwar meine Seite über PM aber die erste bzw Kopfseite nutzt nicht Standardeinstellung en sondern
rued_intro

Die meisten anderen Seiten benutzen Standardeinstellung en rued_pages_1

Response Blue taucht gar nicht auf.

die templates sind mit Unterstrichen.

Ich habe nun bei z.B impressum das template von Standard auf rued_pages_1 gesetz,
die Seite wird aber immer noch (aus dem Backend) mit template rued_intro aufgerufen,
wobei der link in der adressleiste des Browsers richtig wäre.

läuft deine Kiste wieder !?

find das super, daß man von euch so schnell eine Antwort bekommt! 

[jacobi22]

Ich bin gottfried, nicht astricia, die sich auch in dieser thread meldet.

??   

hab nix von der Astrid gesagt, oder?
Hab nur dargelegt, wie es in WB funktioniert und dies an einem Beispiel mit zwei verschiedenen Templates

Ich habe mir jetzt in jedem deiner Templates den Templatenamen oben hin geschrieben und alles läuft so, wie es in der Datenbank hinterlegt ist

Standard ist rued_pages_1
Alles unterhalb von "Werke" und Unterhalb von "Im Raum" benutzt das Template rued_bilder_1, inkl der genannten Hauptseiten

In der Datenbank (in der ich nix verändert habe) haben 6 von 34 Seiten keine Templates in der Pages-Tabelle eingetragen, nutzen also das Standard-Template "rued_pages_1". Das sind, bis auf die zwei eben genannten Seiten "Werke" und "Im Raum" alle anderen Seiten des oberen Hauptmenüs

Alle Seiten werden vom Backend aus mit dem korrektem Template angezeigt, analog der Schaltung im Frontend und analog zu den in der pages-Tabelle hinterlegten Templates für jede Seite.
Ich tippe jetzt mal auf ein Cache-Problem, denn bei mir funktioniert es ohne Probleme. Gern auch per Teamviewer als "Beweis" 
Ich könnte die Seite auch mal online auf einem Testserver laufen lassen

P.S.: Die Schaltung, die ich im Beitrag davor beschrieben habe, ist seit Jahren und zig WB-Versionen unverändert

läuft deine Kiste wieder !?

ne, "diese" Kiste nicht mehr. Meine Frau hat den Stecker gezogen und festgelegt, das hier was Neues ran muß, zwei Wochen Streß und schlechte Laune haben gereicht. Und natürlich lief danach die alte Kiste wieder. Memtest hat mich angelogen und meinte, die Arbeitsspeicher wären okay. Mit einem einzelnem läuft der Apperat wie geschmiert, mit einem zweiten drin komm ich nicht mal zum Passwort eingeben, dann ist er eingefroren.

[gottfried]

Hi!

Ist irgendwie abstrus.

Ich glaub dir schon, daß das bei dir funktioniert.
wie testest du ? xampp?

Ich leg die Geschichte jetzt mal auf einen "stratoserver" statt 1&1.

Vielleicht hab ich noch einen Gedankenblitz.

Bin 2 Wochen weg in Prag. Danke vorab! 

Das mit den Rams kommt mir bekannt vor. u.U hat memtest ja gar nicht gelogen, nur zu wenig
Ram auf ok getestet? Ist mir mal passiert, daß memtest nur 1/2 Ramriegel erkannt und getestet hat.
Der war natürlich defekt - aber ohne Fehlermeldung.

P.S.
"1und1" baut gerade um zusammen mit "IOS" . u.U liegt es daran. nix funktioniert gerade flüssig, find ich. 

[gottfried]

Hallo Jacobi!

Da bin ich wieder!

Echt abstrus. Ich habe die besagte Seite mal auf Strato gelegt und es ist das gleiche.

Mein mich in der Situation (nervöser Kunde) rettender Gedankenblitz war der, daß ich die erste Seite, die quasi ohne menü vorgeschaltet sein soll und nach ca 10 Sekunden Verzögerung eine ähnliche nur mit Menü aufruft nun mit Template "Standardeinstellung" eingestellt habe und nun funktioniert das, wie es soll. (Leider ohne die Verzögerung des speziellen Templates rued_intro und mit menü)

Sicher nervt mich die Kundin solange bis das geht (künstlerischer Minimalismus) - sollte ja eigentlich auch.


Ich kann dir gerne über PM einen Testzugang geben falls du dir das anschauen willst ?

[jacobi22]

da gibt es doch schöne JQuery Effekte     (auch, wenn ich davon wenig halte, weil ich als Besucher ja nicht weiß, das ich hier 10 Sec warten soll)

Nur mal, um es gesagt zu haben
Beispiel auf dieser Seite -> http://thisinterestsme.com/jquery-display-element-5-seconds/

blendet einen Block, hier message, nach 5 Sekunden wieder aus. Das geht natürlich auch anders herum

hier ein einfaches Beispiel,

Code: [Select]

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>Show Message For 3 Seconds and Menu after 5 seconds</title>
    </head>
    <body>
        <div class="w3-right w3-hide-small" id="topmenu" style="margin-right:20px!important;display:none;">
            <!-- show_menu2 -->
             <ul id="header_menu" class="menu w3-white">
                <li class="#"><a href="#" class="#"><span>DE</span></a>
                 <ul style="max-width:250px;">
                    <li class="#"><a href="#" class="#"><span>Gallery</span></a>        </li>
                 </ul>
                </li>
                <li class="#"><a href="#" class="#"><span>IT</span></a>
                 <ul style="max-width:250px;">
                    <li class="#"><a href="#" class="#"><span>IT 1</span></a>
                     <ul style="max-width:250px;">
                        <li class="#"><a href="# class="#"><span>test3-it</span></a>            </li>
                     </ul>
                    </li>
                    <li class="#"><a href="#" class=""><span>IT 2</span></a>        </li>
                 </ul>
                </li>
             </ul>
         </div>
       
        <!--Our div is hidden by default-->
        <div id="message" style="display:none;">Hello!</div>
       
        <script src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
        <script>
        //When the page has loaded.
        $( document ).ready(function(){
            $('#message').fadeIn('slow', function(){
               $('#message').delay(3000).fadeOut();
            });
            $('#topmenu').hide(0).delay(5000).fadeIn('slow');
        });
        </script>
    </body>
</html>