[gelöst] Probleme bei Providerwechsel
Eingetragen von tetri999 (153)am 19.09.2016 - 15:18 Uhr in
Hallo,
ich habe eine D7-Installation von einem Provider zu einem anderen in eine Test-Domain (andere URL !) umgezogen (Wartungsmodus, alle Caches gelöscht).
Die Installation beinhaltet einige Custom-Fonts, außerdem das Advanced CSS/JS Aggregation-Modul, sowie etliche eigene Module.
Die Probleme:
1. Nach Anpassung der Installation an die neue Umgebung (DB, URL) lief die Site zwar, aber ohne die Custom-Fonts (JavaScript-Fehlermeldungen...)
Der empfohlene .htaccess-Eintrag
<FilesMatch "\.(ttf|otf|eot|woff)$">
Header set Access-Control-Allow-Origin "<URL>"
</FilesMatch>Nach Deaktivierung der CSS- und JS-Komprimierung und -Aggregierung waren die Fonts zwar da, aber Drupal brachte PageNotFound-Meldungen für die Fonts, die sich auf die alte URL bezogen.
Ich hab natürlich ständig die Caches gelöscht.
Nach endlosen Versuchen mit verschiedensten Einstellungskombinationen ging es dann schließlich doch.
2. Dasselbe Problem mit Clean URLs.
3. Das seltsamste: Eins der vielen eigenen Module ist überhaupt nicht mehr ansprechbar (das hatte ich - aber wie andere auch - mit Features übertragen)
Das war also ein blindes Rumstochern im Heuhaufen, und irgendwann hat sich die Nadel dann selbst gefunden...
Hat vielleicht jemand eine Idee, wie man das gezielt und verläßlich veranstalten kann?
Welche Dinge in welcher Reihenfolge abgeschaltet werden müssen, um mit clear-all-caches alles wieder zurechtzurücken - oder wie sonst?
mfG, Michael
- Anmelden oder Registrieren um Kommentare zu schreiben
Um die Arbeit und auch das Übertragungsvolumen zu reduzieren
am 19.09.2016 - 23:38 Uhr
sollten VOR dem Backup alle Caches geleert werden.
Am besten gleich, indem man alle Tabellen, die ein cache_ am Anfang des Namens haben (inkl cache selbst) leert.
das mach ich schon seit meinen ersten Drupal-Tagen so,
am 20.09.2016 - 10:08 Uhr
das Problem scheint eher bei dem AdvAgg-Modul zu liegen.
Ist es vielleicht sinnvoll, vor dem Backup die CSS/JS-Komprimierung und Aggregierung ganz abzuschalten? und die cleanURLs auch gleich?
Und die sessions-Tabelle leeren?
Ist denn hier niemand, der das Problem aus eigener Erfahrung kennt ... ?
Nein, ich hab das Problem
am 20.09.2016 - 13:05 Uhr
Nein, ich hab das Problem eigentlich nicht. Wenn ich eine D7 Installation von einem Hosting zu einem anderen umziehe (egal ob von und zu lokal oder von a nach b), bin ich eigentlich immer recht gut gefahren mit folgendem Vorgehen:
1. Am alten Standort den Drupal-Core und die Module auf den neuesten Stand bringen
2. Cache löschen (vgl. Ronald) und Datenbank exportieren
3. Am neuen Standort ganz normal Drupal installieren - damit passt dann alles mit den Ordner-Berechtigungen, ausserdem kann man damit die .htaccess testen und auch, ob CleanUrl läuft. Eigene Module und
Daten kommen einem so auch nicht in die Quere.
4. alles aus dem \sites-Ordner hochladen, ausser die settings.php (die ja am Ziel im übrigen schreibgeschützt ist)
5. Alle Tabellen der neuen Installation im Zielsystem aus der Datenbank löschen und den Export hier importieren
6. unter /admin/config/media/file-system kontrollieren, ob die Pfade noch so passen (=typische Fehlerursache nach Import).
7. Falls nötig, eigene Anpassungen in .htaccess / settings.php nachtragen
Wenn immer noch Fehler daherkommen, dann ev. deshalb:
- allfällige manuell eingetragene, absolute Pfade in Source-Code (was man eh vermeiden sollte): absuchen mit grep o.ä.
- absolute Pfade/Verweise mit der alten URL in der DB: Absuchen im Export-File oder über die Volltextsuche in phpmyadmin
schön,
am 20.09.2016 - 14:27 Uhr
das ist ja der übliche Weg, funktionierte auch alles soweit.
Was nicht ging, waren die custom-fonts, die scheinen irgendwo anders gecached zu werden.
Ich hatte ja das AdvAgg-Modul im Verdacht - nachdem ich das deaktiviert hatte, alle Caches gelöscht, und wieder aktiviert, hat er sie offenbar neu gesucht und gefunden!
Und was cleanURL betrifft: hier hab ich gefunden:
Clean-Urls Test - False Negatives
On some setups the Clean Urls test gives a false negative result. If you can visit Clean Url links like http://example.com/user/login and Drupal returns the user login page, then .htaccess and mod_rewrite are working. Visiting the Clean Urls admin page directly at http://example.com/admin/config/search/clean-urls, should give you a checkbox that lets you enable Clean Urls
D.h. wenn ich cleanURL über das Admin-Menü aufrufe (seven-Theme im Overlay), bekomme ich das "false negative result", bei direktem Aufruf geht's ...
Trotzdem vielen Dank für die Hinweise,
Michael
Ja, gut möglich, dass gewisse
am 20.09.2016 - 15:12 Uhr
Ja, gut möglich, dass gewisse Cache- und Temp-Files in einem Unterordner von \sites\default\files herumliegen und stören. Zum Beispiel xmlsitemap und fontyourface erzeugen manchmal solche Daten.
Und Du hast recht, ich hatte genau mal den Fall, wo ich so einen Ordner zuerst leeren musste :-)