WebsiteBaker Community Forum
WebsiteBaker Support (2.11.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: ThatsMe on May 01, 2018, 06:28:09 PM
-
Einige Links werden nicht mehr aufgelöst von WB-Link „[wblinkxx]“ in die entsprechende Linkadresse bzw. Dateinamen *.php nach dem Upgrade auf 2.11.0 R79 (inkl. Fixes).
In der WebsiteBaker-Version 2.10.0 funktionierte es noch bestens:
z.B. http://www.ergo-loga.de/ergo/_kurse.php mit Klick z.B. auf „MKT“: http://www.ergo-loga.de/ergo/_kurse/_mkt.php
Hier habe ich auf 2.11.0 R79 (inkl. Fixes) upgegradet: http://upgradetest.ergo-loga.de/ergo/_kurse.php. Wenn ich hier auf z.B. auf „MKT“ klicke habe ich: http://upgradetest.ergo-loga.de/ergo/[wblink16] was natürlich zu keiner Seite führt.
Anmerkung: Ich arbeite seit einiger Zeit immer erst einmal in einer Test-Subdomain, bevor ich komplett umstelle, damit die Website - während der Umstellung oder wenn es Probleme gibt - trotzdem weiter funktioniert. Daher habe ich jetzt beide Versionen zur Verfügung.
Die PHP-Version lautet 7.1.
Bei dem Upgrade auf 2.11.0 R79 bin ich wie folgt vorgegangen:
- Datensicherung des aktuelles FTP-Verzeichnisses (komplette Website) auf Festplatte.
- Datensicherung in neues FTP-Verzeichnis kopiert.
- Subdomain „upgradetest.ergo-loga.de“ auf neues FTP-Verzeichnis verwiesen.
- Datensicherung MySQL relevante Tabellen „prefix2100_*“
- sql-Datei Suchen / Ersetzen: prefix2100_ => prefix2110_ (Nur Tabellennamen)
- Geänderten Datensatz in MySQL-Datenbank importiert (zusätzliche Daten).
- config.php Änderung:
define('TABLE_PREFIX', 'prefix2100_'); => define('TABLE_PREFIX', 'prefix2110_');
define('TABLE_PREFIX', 'prefix2100_'); => define('TABLE_PREFIX', 'prefix2110_');
define('WB_URL', 'http://www.websitename.de‘); => define('WB_URL', 'http://upgradetest.websitename.de');
- Modifizierte config.php in neues FTP-Verzeichnis kopiert (überschrieben).
- Website unter „upgradetest.websitename.de“ gesichtet/getestet (ist jetzt eine gespiegelte Version der Originalwebsite).
- Updatedaten 2.11.0 (aus WebsiteBaker-2_11_0_r79_incl_Fix.zip) in neues FTP-Verzeichnis eingespielt.
- Als Admin unter „upgradetest.websitename.de“ eingeloggt.
- „upgradetest.websitename.de/upgrade-script.php“ gestartet (“Restart Programm”-Button geklickt und dann auf folgender Seite Haken für „confirm“ und „Start upgrade script“ geklickt).
- Meldung „WebsiteBaker Upgrade This script upgrades an existing WebsiteBaker 2.10.0 (r66) installation to 2.11.0 (r79) .
- The upgrade script alters the existing WB database to reflect the changes introduced with WB 2.8.x …“
[Anmerkung: Überall “OK“. Ich könnte auch noch die komplette Meldung ergänzen.] - Website unter „upgradetest.websitename.de“ gesichtet/getestet.
- Bei Sichtung festgestellt, dass einige Links nicht mehr funktionieren ([wblinkxx] statt Link-Dateiname).
Fehlen noch Infos? Was kann hier schief gelaufen sein? Wie kann ich das beheben?
Ich bin leider ratlos und habe auch nichts dazu im (deutschen) Forum gefunden - im englischen Forum habe ich die Beiträge nur überflogen, aber dabei auch nicht passendes gefunden.
Kann mir jemand weiterhelfen?
---- Ergänzung ---
Was ich noch vergessen hatte zu erwähnen:
Das Menü unten rechts (Impressum etc.) wird nicht mehr angezeigt nach dem Upgrade. Ich verwende show_menu2 v4.9.15.
-
Hi,
nebenbei: hast schon mal versucht ohne Punkt 5 zu arbeiten?
zum Problem: ich sehe keienrlei JS Dateien bei dir geladen.
Schau mal was unter Admin Tools > Output Filter Frontend angehakt ist. Sollte ziemlich viel sein (außer Opf und RelUrl und evtl. Emailfilter)
-
Ich habe unter Admin-Tool > Output Filter Frontend v1.1.8 alle Filter angehakt außer JqueryUI und RelUrl.
Was bedeutet "ohne Punkt 5 zu arbeiten"?
Stimmt, die ganzen JS-Dateien sind nicht geladen. Woran liegt das?
-
Was bedeutet "ohne Punkt 5 zu arbeiten"?
Du importierst es in die gleiche Datenbank? Vergiss meine Frage.
Obwohl bei dir alle Filter aktiv sind ist kein Javascript zu sehen.
Wurden wirklich alle Dateien übertragen?
-
Ja, ich importiere in die gleiche Datenbank. Das mit den verschiedenen Prefix-Tabellen mache ich einfach sicherheitshalber, damit ich alles rückgängig machen kann.
Ich meine ja, dass ich alle Dateien übertragen habe. Ich hatte das Upgrade schon zweimal gemacht. Immer wieder mit den ursprüglichen Daten (Version 2.10.0) wieder komplett neu aufgesetzt, aber der Fehler war leider noch da.
-
Ich habe jetzt mal den Haken bei OpF heraus genommen und danach dann den Filter bei JqueryUI gesetzt (Output Filter Frontend), aber jeweils keine für mich sichtbare Änderung.
-
Ist in deinem Template in der index.php die Zeile im Head?
<?php register_frontend_modfiles('css'); ?>
-
Mit css nicht, aber mit js:
<?php register_frontend_modfiles('js');?>
-
Die CSS-Dateien habe ich wie folgt eingebunden:
<link href="<?php echo TEMPLATE_DIR; ?>/style/ergo-loga-style.css" rel="stylesheet" type="text/css"/>
-
Mach mal die Zeile mit register css über die mit js.
Hat mit deinen CSS Einbindungen nichts zu tun.
Durch register_frontend_m odfiles('css') wird noch mehr als css aufgerufen.
-
Gerade habe ich es noch einmal neu gemacht:
- FTP-Daten von Version 2.10.0 auf Festplatte gesichert
- Daten in neues FTP-Verzeichnis kopiert
- usw.
Ergebnis: http://upgradetest2.ergo-loga.de
Leider mit genau dem gleichen Fehler...
Dabei ist mir aufgefallen, dass FileZilla mir drei nicht übertragbare Dateien gemeldet hat:
\include\jquery\i18n\jquery.ui.datepicker-rm.js
\modules\ckeditor\ckeditor\plugins\wbdroplets\log\LOCK
\modules\ckeditor\ckeditor\plugins\wblink\log\LOCK
Die erste Datei (jquery.ui.datepicke r-rm.js) wird mit den Upgrade-Daten neu übertragen (überschrieben) und daher meiner Meinung nach zu vernachlässigen.
Die beiden anderen LOCK-Daten bekomme ich nicht übertragen. Sind auch wie die oben genannte js-Datei mit Dateigröße 0 auf FTP aufgeführt.
-
Upps, da haben sich die Posts überschnitten...
Unter Kurse sieht das Template jetzt in dem Abschnitt so aus:
<?php register_frontend_modfiles('css'); ?>
<?php register_frontend_modfiles('js'); ?>
<link href="<?php echo TEMPLATE_DIR; ?>/style/ergo-loga-style.css" rel="stylesheet" type="text/css"/>
Habe ich online gebracht:
http://upgradetest.ergo-loga.de/ergo/_kurse.php
und
http://upgradetest2.ergo-loga.de/ergo/_kurse.php
Leider noch das gleiche Phänomen, aber es sind zumindet schon ein paar der JavaScript-Dateien/-Daten eingebunden.
Unter 2.10.0 sind diese:
<script src="http://www.ergo-loga.de/include/jquery/LoadOnFly.js" type="text/javascript"></script>
<script src="http://www.ergo-loga.de/include/jquery/jquery-min.js" type="text/javascript"></script>
<script src="http://www.ergo-loga.de/include/jquery/jquery-insert.js" type="text/javascript"></script>
<script src="http://www.ergo-loga.de/include/jquery/jquery-include.js" type="text/javascript"></script>
<script src="http://www.ergo-loga.de/include/jquery/jquery_theme.js" type="text/javascript"></script>
<script src="http://www.ergo-loga.de/modules/output_filter/js/mdcr.js" type="text/javascript"></script>
Unter 2.11.0 jetzt immerhin diese (vor dem neuen Eintrag im Template gabe es gar keine):
<script src="http://upgradetest2.ergo-loga.de/include/jquery/domReady-min.js"></script>
<script src="http://upgradetest2.ergo-loga.de/include/jquery/LoadOnFly-min.js"></script>
Ehrlich gesagt, sagt mir das jetzt noch nicht so viel, aber Dir vielleicht...
-
Ergänzende Info zu den "Output Filter Frontend"
Folgende Filter sind zurzeit aktiviert (Haken):
Droplets
Email
FrontendBodyJs
FrontendCss
FrontendJs
Jquery
LoadOnFly
OpF
RegisterModFiles
ScriptVars
SnippetBodyJs
SnippetCss
SnippetJs
Folgende deaktiviert (kein Haken):
JqueryUI
RelUrl
Falls das wichtig ist. Mir sagt das leider (noch) wenig. Ich mache jetzt erst einmal Schluss für heute.
-
Das sieht mir nach einem Problem mit dem output_filter aus. Überprüfen, ob beim upload alle Dateien überspielt worden sind. Hat in letzter Zeit öfter Probleme gegeben.
Sonst mal eine manuelle Neutinstallation des output_filter ausführen, was kein Problem ist, da es sich um statische Einträge in der Datenbank handelt. Evtl nur die Einstellung neu vornehmen.
Dietmar
-
Wie schon oben geschrieben, hatte der Download (von Version 2.10.0) der folgenden Dateien nicht geklappt:
\include\jquery\i18n\jquery.ui.datepicker-rm.js
\modules\ckeditor\ckeditor\plugins\wbdroplets\log\LOCK
\modules\ckeditor\ckeditor\plugins\wblink\log\LOCK
Die erste Datei (jquery.ui.datepicke r-rm.js) wird mit den Upgrade-Daten neu übertragen (überschrieben) und daher meiner Meinung nach zu vernachlässigen.
Die beiden anderen LOCK-Daten bekomme ich nicht übertragen. Sind auch wie die oben genannte js-Datei mit Dateigröße 0 auf FTP aufgeführt.
Beim Upload hatte ich keine Meldung von FileZilla.
Wie führt man eine manuelle Neuinstallation des output_filter aus?
-
Bevor du irgendwas neu machst...
Im Output Filter den Haken bei RegisterModFiles rausnehmen, damit die anderen angehakten Filter funktionieren.
-
OK, habe ich. Sieht jetzt so aus (beide Subdomains) - Filter aktiviert (Haken):
Droplets
Email
FrontendBodyJs
FrontendCss
FrontendJs
Jquery
LoadOnFly
OpF
ScriptVars
SnippetBodyJs
SnippetCss
SnippetJs
Folgende deaktiviert (kein Haken):
JqueryUI
RegisterModFiles
RelUrl
-
Gut so.
Jetzt geh mal zu Erweiterungen > Module > Erweitert
Wähle dort bei install Output Filter Frontend
Dir werden keine Fehler angezeigt bei Klick auf das X (oben im Menü)?
-
Habe ich gemacht (Erweiterungen > Module > Erweitert: Datei "install.php" Output Filter Frontend v1.1.8"ausführen"; danach auf X oben).
php_error.log:
"created: [2018-04-26T13:02:37+02:00]"mehr nicht
-
Wird schwieriger mit der Ferndiagnose.
statt install Otput Filter kannst gern auch mal upgrade versuchen in den erweiterten einstellungen von modulen.
auch nochmaliges WB upgraden schadet nicht (info button oben im menü, dort upgrade WB).
-
Und in WB Optionen > Erweitert > Server Einstellungen > PHP Fehlerberichte auf Produktion stellen.
Dann im Frontend irgendwas machen und wieder nach dem X Button schauen.
-
Habe ich gemacht unter "upgradetest2":
- Output Filter Frontend v1.1.8 - upgrade
- WB - upgrade
- WB Optionen > Erweitert > Server Einstellungen > PHP Fehlerberichte auf Produktion gestellt
-
Das [wblinkxx]-Link-Problem ist gelöst. Die Links funktionieren wieder. :-)
Zur Info: Vielleicht funktionierten die Links auch erst, nachdem ich an dem Menü unten rechts in der index.php Korrekturen eingefügt hatte. Unter show_menu2 v4.9.11 funktionierte es noch. Unter show_menu2 v4.9.15, welches mit Upgrade 2.11.0 eingeführt wurde, gab es beim Menü unten rechts eine Fehlermeldung. Wahrscheinlich war auch das im Endeffekt das Problem? Allerdings habe ich einiges dazu gelernt und auch andere geänderte Inhalte (JavaScript) waren mit Sicherheit entscheidend, um dieses Problem gelöst zu haben.
Vielen, vielen Dank für die ganze Mühe an @dbs und auch @Luisehahne! Wahnsinn, wie schnell ich Antworten bekommen habe und wie hilfsbereit Ihr seid.
Jetzt bastle ich noch am Menü unten rechts (Problem: show_menu2 v4.9.15, welches mit Upgrade 2.11.0 eingeführt wurde). Da muss ich mich erst einmal wieder reindenken. Es hat sich einiges geändert seit dem Seitenaufbau. Aber das ist ein anderes Problem. Danke @jacobi22 für Deine Unterstützung. Wahrscheinlich kannst Du mir dabei noch helfen.
Ich danke Euch allen, dass Ihr mir hier schon so toll weiter geholfen habt.
Heike
-
Zur Info: Vielleicht funktionierten die Links auch erst, nachdem ich an dem Menü unten rechts in der index.php Korrekturen eingefügt hatte. Unter show_menu2 v4.9.11 funktionierte es noch. Unter show_menu2 v4.9.15, welches mit Upgrade 2.11.0 eingeführt wurde, gab es beim Menü unten rechts eine Fehlermeldung. Wahrscheinlich war auch das im Endeffekt das Problem? Allerdings habe ich einiges dazu gelernt und auch andere geänderte Inhalte (JavaScript) waren mit Sicherheit entscheidend, um dieses Problem gelöst zu haben.
Heike
Genau an der Scriptunterbrechung wird der Fehler liegen, dann nämlich kann das wblink nicht mehr aufgelöst werden, weil das Script garnicht weiter ausgeführt wird..
Danke für die Info
Dietmar