Nur eine kurze Information – ich mache mich aktuell ein wenig rar. Wegen der Performance-Probleme bei HostEurope habe ich am Freitag ein entsprechendes Webpaket bei all-incl.com gebucht und versuche seit Montag den Umzug zu wuppen.
Anzeige
Entgegen den landläufigen Hinweisen "ist mit dem WordPress Duplicator-Plugin" in wenigen Minuten erledigt, klappt das bei Born nicht. Auch ein Import mit dem phpAdmin scheitert. Fluch von 17 Jahren bloggen – meine zwei SQL-Datenbanken, die ich für die WordPress-Blogs verwendet, sind so groß, dass die oben genannten Methoden scheitern.
Im Moment habe ich den Support von all-incl.com gebeten, den SQL-Import aus meinem Backup der SQL-Datenbanken zu versuchen. Ich hoffe, das klappt.
Erst danach kann ich daran gehen, die WordPress-Blogs samt Infrastruktur umzuziehen und dann auch noch den Domain-Umzug anzustoßen. Es kann also die kommenden Tage immer mal wieder ruckeln – wobei ich den Blog hier aktuell einfach bei HE laufen lassen.
Ich wusste schon, warum ich den Umzug des Hosters nicht ohne Not anstoße. Die wilde Idee, die Blogs neu mit WordPress und anderen Templates aufzusetzen, habe ich aktuell auch verworfen. Erste Versuche mit einem Spiel-Blog haben mir gezeigt, dass die WordPress-Entwickler zwar arg mit dem Gutenberg Blog-Editor aasen. Aber ich bräuchte ein Responsible Design mit Seitenleiste, was so gut wie mein altes TwentyTen rendert.
Anzeige
Mit TwentySixteen bekomme ich zwar etwas ähnliches hin – aber es gibt einfach zu viele Feinheiten, die arg stören. Ob ich mir dieses Template vornehme und entsprechend als Child-Theme anpasse, muss ich sehen. Irgendwie zweifle ich aktuell an den Designern – von denen wohl keiner mal einen größeren Blog betrieben hat.
Anzeige
Ähnliches gilt leider auch für die meisten WordPress Core Entwickler.
phpmyadmin: Man kann beim export einstellen, dass er alle X einträge (ich empfehle 1000 / 10000, je nach server performance) seperate queries erstellen soll. die kann man danach relativ einfach in seperate sql files splitten und dann schrittweise auf dem neuen system inserten.
Grüße
wäre eine Option, wobei ich in der aktuellen Datenbank des IT-Blogs schon arg Tabula Rasa veranstaltet, und dabei die Werte in der Tabelle für die Seitenabrufe gelöscht habe. Brachte zwar 0,5 GB, aber wenn ich die alte Sicherung importieren kann, wäre das smoother. Ein Datenbank Reimport aus einer Sicherung ist bei HE kostenpflichtig.
Weiterer vorschlag: phpmyadmin lokal ausführen und dort die (php) timeouts deaktivieren oder auf 32 tage oder so ändern. (z.B. mit xampp und angepasster config)
probiere es doch mal damit:
https:**www.akeeba.com*products**akeeba-backup-wordpress.html
Mit Akeeba machen wir auch die Transporte von System zu System. Damit einfach ein Backup erstellen, die Dateien samt Akeeba Restore Php auf dem neuen Server per SSH oder FTP in das entsprechende Unterverzeichnis hochladen und die URL im Browser aufrufen. Es macht dann den DB Import und alles weitere interaktiv und hat bei uns bisher immer funktioniert.
Mir half damals das,
(ist aber schon wirklich lange her):
https://www.ozerov.de/bigdump/
Bigdump hatte mir auch einmal geholfen, der Name wäre mir jedoch heute nicht mehr eingefallen ;)
Ich schlag vor, die Datenbanken zu bereinigen. Wordfence und und einige andere konsorten müllen die Datenbanken mit vielen Megabytes and Plunder zu. Kann man rauswerfen. Dann könnte es klappen.
Habe selber nur shared bei all-inkl, aber wenn ich mal etwas mit der DB machen möchte (sql export und import, z.B. Shop clonen):
Datenbank temporär extern freigeben, den Rest mache ich dann auf dem PC lokal mit HeidiSQL und nicht mit irgendwelchen PHP-Tools auf Webserver.
Genau so mach ich das mittlerweile auch, ebenfalls mit HeidiSQL. (Bin ebenfalls bei All-Inkl)
Arme Windows-User. :(
Kam auf die Schnelle mit HeidiSQL nicht weiter – habe aber mit SQLDump die Möglichkeit gefunden, meine Datenbanken bei all-incl.com zu exportieren und zu importieren.
Und der all-incl.com-Support hat mir die gesicherten SQL-Datenbanken von Hosteurope in neue Datenbanken importiert (ich selbst bin wegen Fehlermeldungen da gescheitert).
Jedenfalls habe ich meine Daten bis zum 2.9.2024 aus allen Blogs in Datenbanken auf all-incl.com – muss die aber noch prüfen.
Zudem teste ich aktuell einiges, bevor ich die Blogs neu auf all-incl.com aufsetze. Ich muss wissen, ob eine Design-Entscheidung in Richtung Multisite-Blog mit meinem Windows Live Writer funktioniert. Und ich nutze die Gelegenheit, die Blogs frisch aus einer Installation neu aufzusetzen, um einfach die Altlasten aus 15 Jahren auf Hosteurope weg zu bekommen.
Da ich nebenbei auch noch ein wenig blogge, sowie essen und auf's Klo muss, kann das halt dauern. Also nix mit zwei Klicks und ich bin drüben ;-).
PS: Einen Kommentar hier zu arme Windows-User habe ich gelöscht, da nichts mit dem Thema zu tun hat.
Wenn ich dann noch eine bescheidene Bitte dranhängen darf…. Beim an/abschließenden Aufräumen und Anpassen dann vielleicht ein Blick in die .CSS für Mobilgeräte und dort die Schriftgröße um ein oder zwei (oder fünf) Punkt größer einstellen?
Für uns alte Säcke, denen bald selbst die Lesebrille nicht mehr reicht.
Dank im voraus!
Die minimale Schriftgröße kann man im mobilen Firefox einstellen:
Die 3-Punkte anklicken, Einstellungen, Barrierefreiheit, Schriftgröße, Schieber etwas nach rechts auf 120 Prozent oder noch mehr.
Im Chromium:
Die 3-Punkte anklicken, Einstellungen, Bedienungshilfe, Text-Skalierung, Schieber nach rechts auf 120 Prozent oder noch mehr.
Danke für den Tipp, Bolko!
Allerdings sind jetzt auch alle anderen Seiten größer in der Darstellung, auch die, die gar nicht vergrößert werden müssten. Aber das ist schon okay.
Bleibt nur das Problem, dass wir beide das jetzt wissen, aber etliche andere eben nicht und die müssen sich weiterhin mit einer relativ kleinen Schrift rumplagen.
Naja, mir ist erstmal geholfen. Danke nochmals!
Nur um viele Diskussionen hier ab- und einzufangen – ich kann nichts an den .css für Mobilgeräte tun – bis vor kurzem lief eine Weiche, die bei Mobilgeräten auf eine andere Vorlage umgeschaltet hat. Das werde ich beim Umzug aber umstellen (dank eines Lesers kann ich die Vorlage TwentyTen responsive gestalten).
Dark-Modus, ein "Aufpolieren des altbackenen Designs" etc., wie hier angeregt, wird es eher nicht geben. Ich habe in den letzten 15 Jahren einige WordPress-Templates getestet – bin aber immer wieder zu TwentyTen zurück gekehrt. Der Grund: Da sind die Design-Elemente, die ich brauche. Die Schriftartendarstellung sind so, dass ich sie für den Großteil der Leser als gut lesbar einstufe – und die bestehenden Beiträge werden mit ihren Bildern vernünftig gerendert.
Bei jedem abweichenden Design muss ich genau diese Punkte berücksichtigen – und bin jedes Mal zum Schluss gekommen, dass es an allen Ecken nicht passt. Was nutzen mir neue Schnörkel, wenn die Texte farbig und kaum noch lesbar sind, die Kommentierung neue Hürden aufwirft, oder die Altbeiträge nur noch zum Brechen gerendert werden. Und da wieder mit Anpassungen in den Templates rumzufummeln, so dass es passt, dazu fehlen mit a) die Erfahrungen und b) auch Motivation und Zeit.
Zudem musste ich bei Kurztests die Tage feststellen, dass neuere WordPress Templates oft auf die Block-Editor-Geschichte a la Gutenberg zugeschnitten sind. Gutenberg ist im Blog abgeschaltet, ich brauche die saubere Oberfläche des Klassik-Editors, um Beiträge korrigieren zu können.
Von daher: Der Blog wird immer ein Zwischending zwischen "Fefe-Design" und Augenkrätze im Modern-Design bleiben. Hoffe, die Leserschaft versteht das. Sind alles Aspekte, die ich hier berücksichtigen muss – denn am Ende des Tages will ich auch noch ein wenig bloggen – und zwar im Workflow, der sich hier seit 15 Jahren bewährt hat.
Vorschlag wegen Fontgrösse etc – Design ist Chefsache und es gibt hier nur einen Chef.
(War ja auch nur als Vorschlag gemeint)
Alles okay soweit.
Größenbeschränkung bei phpMyAdmin oder beim WordPress-Duplicator-Plugin?
Bei phpMyAdmin ist die Datenbankgröße standardmäßig als Sicherheitsfeature auf 2 MegaByte limitiert.
In der php.ini von phpMyAdmin kann man die Größen anpassen.
memory_limit = 60M
post_max_size = 60M (würde 60 MegaByte bedeuten)
upload_max_filesize = 60M
(eventuell muss auch noch eine absteigende Größe von oben nach unten eingestellt werden)
Diese Werte müssen größer sein als deine SQL-Datenbank.
Speichern und Apache neustarten.
introserv[.]com/docs/phpmyadmin-restriction-on-the-size-of-the-uploaded-file/
Du kannst auch 128M einstellen, dann sollte es für die Datenbank reichen.
Ich weiß aber nicht, ob der Server auch 128 MB bereitstellen kann.
Nur mal so: Wenn das Verwerfen der Zugriffszahlen die Datenbank um 0,5 GB verschlankt, dürfte die Gesamtgröße /etwas/ über 128 MB liegen 😉
Ich empfehle den MyOOS Dumper, Nachfolger vom MySQLDumper der arbeitet in chunks. Als Theme Enfold, hochflexibel.
Ich hab meinen server vor 1 Woche umgezogen, ale files rüber mit rsync und mysql import fertig.
Also kein plugin kein import einfach Komplettumzug, hat super funktioniert, manchmal ist Handarbeit am besten.
Eben, es sollte wirklich so einfach sein. Kurz die services anhalten damit nichts zum schreiben geöffnet ist und mit transportkomprimierung rüberziehen.
Und schon sind die tollen """services""" der hostingprovider ausgeblasen!
Das die echt alles zum Geschäftsmodell machen wollen.
Drücke die Daumen für den Umzug!
Wird einige Tage dauern – entgegen den "ist alles so einfach – mal kurz …" – Datenbanken sind umgezogen (aber mit den alten Inhalten), sind hier viele Fragen zu klären. Beim Umzug der WordPress-Instanzen habe ich einige Kardinalfehler gemacht, die ich aber beim nächsten Versuch vermeiden möchte.
Parallel dazu experimentiere ich auf der neuen Plattform mit einigen Fragestellungen, die die Struktur der Blogs betreffen. So war sich der Supporter von All-Incl. beim gestrigen Gespräch nicht sicher, ob meine Last deren Webhosting-Paket nicht total überlastet (so viel zu "mal eben mit ein paar Klicks zu einem anständigen Hoster wechseln"). Das will ich in Ruhe testen. Wenn ich das alles glatt gezogen habe, will ich auf einer anderen Domain auch einen Lasttest mit der Leserschaft fahren.
Danke an dieser Stelle an die Leser, die mir Hilfe angeboten haben. Auf einige Leute werde ich mit Fragen zukommen. Mir ist klar: Leute, die das täglich machen, haben das fix erledigt. Ich möchte das aber weitgehend selbst wuppen, damit ich halbwegs das Wissen habe, was wo passiert. Wenn mir der Blog Nachts um 24:00 Uhr steht, weil ein Plugin-Update schief gegangen ist (wäre nicht das erste Mal), muss ich selbst eingreifen können.
An dieser Stelle ein Dank an einen weiteren Blog-Leser, der mir ein abgewandeltes Twenty Ten-Template angeboten hat, welches ein Responsives Design unterstützt. Was ich so gesehen habe, ist vielversprechend – würde es mir ermöglichen, das alte Design weiter zu verwenden, aber die ganzen "Mobile-Klimmzüge", die ich als Notnagel eingebaut habe zu kicken.
Und ich muss mir darüber klar werden, ob ich nicht einige Nischenblogs (Bücher, eScooter, Japan) komplett schlachte oder zu WordPress.com als Bestand umziehe.
Hallo Günter,
auf jeden Fall alles Gute! So kurz mal den Provider wechseln funktioniert auch mit kleinen Websites nicht, wie ich selbst gemerkt habe. Aber es bietet die Chance für Änderungen (und Bereinigungen).
Gruß, Patrick
WordPress.com ist nicht DSGVO konform nutzbar.
Die sehen das wohl anders – habe da aber keinen Druck, notfalls schließe ich betreffenden Blogs.
Dagegen könnte der Weiterverkauf von Inhalten für KI-Zwecke sprechen, wie Fefe im Blog schreibt: https://blog.fefe.de/?ts=9b21c64c
Das mit dem Lasttest liest sich gut; ich bin dabei! Und die Erfahrung mit dem Provider hat mir gezeigt, dass auf fachliche Hinweise zügig reagiert wird. So gehe ich davon aus, dass alles in den grünen Bereich kommt.
"So war sich der Supporter von All-Incl. beim gestrigen Gespräch nicht sicher, ob meine Last deren Webhosting-Paket nicht total überlastet" …
Dann brauchen wir einen Leistungstärkeren Server… Nein, im Ernst hier im Blog läuft nichts, was gegen die Regelen von All-Inkl. verstösst.
Und je nach Paket teilen sich 50(Priv+/Prem) oder 30 (Bussi) Kunden den Server.
Ich hatte es bisher nur einmal das das ganze im Kriechgang lief – anruf beim Support und das war ruck-zuck behoben!
Denke übringens daran, das du auch dein Backup selber machen must! Nicht auf All-Inkl. verlassen.
Deine NischenBlogs, könntest du auch software-seitig (sub-/Domain) trennen durch eigene Instanzen.
Platz für DBs und Speicher ist ja genug ;-)
Und wenn es nicht klappt, hast du 3 MOnate Zeit aber kein Geld investiert und KnowHow aufgebaut. Kann man alles Positiv sehen – bisher läufts ja hier noch!
Aha, Du bist also Schuld lieber Günter!
Ich habe unsere Website + Ticketsystem bei All-Inkl – seit gestern grottenlangsam und hin und wieder "Server nicht erreichbar".
Hör auf deine X Petabyte hochzuladen ;))
LOL! Komm auf meinen Server rüber! Dort hatte ich auch mal einen leider unbekannten Bremser. Günter hat zum Glück einen anderen Server bekommen.
Anscheinend ist Günter feritg – oder der wirklich gute Support von All-Inkl hat den Bremser gefunden ;)
Viel Erfolg beim Umzug! Mit All-Inkl hast du wirklich eine gute Wahl getroffen. Deren Support hat uns oft bewiesen, dass er kompetent und engagiert ist.
Noch einen Wunsch:
Helle Schrift auf dunklem Hintergrund (Dark Mode) ist für mich viel besser lesbar und hier auf den Systemen Standardeinstellung.
Das lässt sich automatisch per CSS via '@media' und 'prefers-color-scheme' nach den Nutzereinstellungen des Betriebssystems bzw. im Browser steuern und ist vielleicht schon in den Layouts bei WordPress integriert.
(Auf zusätzliche Plug-Ins, die vielleicht sogar kosten, würde ich verzichten!)
Z. B. bei 'Tagesschau' und 'Der Spiegel' ist das bereits Bestandteil des Layouts.
Weil das nicht jedem gefällt, lohnt sich vorher vielleicht eine kleine Umfrage …
Patrick, mach das Licht aus, dann hast du DarkMode ;-)
Schwarze Schrift auf schwarzem Grund? Lach!
Die Umschaltung setzt sich als Standard immer mehr durch. Allerdings ist es auch ein wenig Umstellungsarbeit. Allerdings hat Günter nur mit dem Banner oben auf der Seite wohl eher weniger Arbeit mit Grafiken, die mit hellem und dunklem Hintergrund gut aussehen sollen.
Vielleicht könnte auch Adminer (siehe: https://www.adminer.org/de/) weiterhelfen, wobei ich mir jenes PHP-Script noch nicht angeschaut habe. Grundsätzlich wäre es allerdings vorteilhaft, wenn nicht auf einmal alle Tabellen des SQL-Dumps importiert werden, sondern dieser Vorgang gesplittet wird, also jeweils nur ein paar Tabellen auf einmal ex- und wieder importieren. Dies machte ich so 2008 bei meinem Webhoster-Wechsel, sofern ich mich noch korrekt entsinne.
Mit WordPress und dessen Datenbank-Struktur kenne ich mich allerdings überhaupt nicht aus, zumal es für meine Ansprüche als neues Backend-System viel zu umfangreich und wartungsintensiv gewesen wäre. Mir reicht ein Flat-File-CMS völlig, weshalb ich mein eigenes 2020 entwickelte, da mir die gängigen Flat-File-CMS ebenfalls zu umfangreich waren.
Du meintest sicherlich AdminerEvo. Weil Adminer tut sich seit ein paar Tagen nichts mehr. ;-)