Nach einem gestrigem Update hat das Fenster zwar den Fokus, reagiert aber weder auf ENTER oder TAB.
Habe auch den Wert in about:config dann suchen nach “widget.use-xdg-desktop-portal.file-picker” wieder auf 2 gesetzt. Bringt leider gar nichts, außer das das Speicherdialog-Fenster wieder den Fokus verliert und man im FF Fenster selber rum hantiert.
DANKE nochmal MOZILLA das dieser Effekt neulich auftauchte und auch nach mehreren FF Updates nicht mehr verschwindet. Denn KEINE ANDERES PROGRAMM ZEIGT DIESES VERHALTEN BEIM SPEICHER DIALOG !!!!
Das ist echt mal absolut nervtötend und man bekommt einfach nicht raus woran es liegt.
Nächster Tag
Im Mint-Forum gefragt, dort hat dieses mal scheinbar KEINER das Problem :/
Dann habe ich testweise einen neuen USER angelegt, oh FF ist schon drauf, der gleiche MIST (hmm vielleicht hätte ich den FF dort mal de/installieren sollen). Habe aber irgendwie Angst das das den FF auch beim echten USER tangiert.
Dann habe ich den FF im Save-Mode gestartet, der gleiche Driss.
Dann habe ich Cinnamon installiert (das ist ja eine optische Katastrophe) der gleiche Dreck mit dem FF.
Und ich habe mit zwei anderen Programmen deren Speicher-Dialog getestet, NULL PROBLEMO !
Ich krieg hier die Firefox-KRIESE was treibt MOZILLA hier ?!?!??!
Not Lösung
Zufällig stelle ich fest das wenn man ALT gedrückt hält bei allen Dialog-Objekten Buchstaben unterstrichen werden. Drückt man z.B. ALT + S wird gespeichert. Dann eben so, traurig MOZILLA.
Firefox 152.0.3
Keine Änderung, der gleiche MIST … WHY MOZILLA WHY ??
Nachdem es mit yaVDR 0.62 immer mehr bergab geht (Erklärung gleich) entscheide ich mich endlich meine 120GB yaVDR 0.7 Test-SSD mal eben auf die neulich (noch günstig) gekaufte 1TB SSD (yaVDR 0.62) zu clonen.
Warum yaVDR 0.62 nicht mehr brauchbar ist
Habe das alles hier schon einmal detailliert erklärt.
In Kürze :
Firefox uralt, konnte mich nur noch mit einem AppImage über Wasser halten. Und auch der lief nur bis zu einer bestimmten Version noch auf dem Ubuntu 14
Vor 2 Jahren dann auch bei dem FF der (von MOZILLA angekündigte) Supergau. Zertifikate wurden absichtlich deaktiviert, wodurch AddOns eiskalt deaktiviert wurden. Installation von AddOns werden im gleichen Atemzug mit Verweis auf neuste FF-Versionen abgelehnt.
Die YouTube-App (so nenn ich’s mal) lief auf einem uralten Chromium Browser, der immer mehr Probleme machte. Auch hier wurden von Google, remote, AddOns deaktiviert. Ich hatte gerade noch EIN AddOn laufen, das sehr gut YT Werbung unterdrückte. Das hatte aber den Nachteil das YT das detektierte und ständig diese “Werbe Blocker sind verboten”-Popups zur Folge hatten. Diese konnte ich nur mit x-mal F5 (Reload) überwinden. Das ging von 1x F5 bis über 10x F5. Macht einen irgendwann mürbe.
Rescuezilla
Eigentlich ja ein klasse Tool. Aber von neulich hatte hiermit und auch mit Clonezilla sehr schlechte Erfahrungen gemacht.
Egal, neustes Rescuezilla-Image auf USB-Stick bootbar Ge-Imaged.
Als erstes macht ich vom fetten 1TB Altsystem mal eine Sicherheits-Kopie (Sicherung). Die SSD steckte ich in meinen USB3.x SSD-Docking Station. Die Aktion dauerte recht lange, so ca. 2-3h.
Am nächsten morgen geht es frisch weiter. Ich erstelle auf die gleiche Weise eine weitere Sicherung der kleinen 120GB SSD wo yaVDR 0.7 testweise drauf ist. Das klappt recht zügig, sind ja auch nur 120GB.
Dann starte ich das Wiederherstellen der eben gesicherten 120GB yaVDR 0.7 SSD auf der 1TB SSD. Rescuezilla schreibt schön irgendwas an der Partitions-Tabelle herum. Dann eine Fehlermeldung bevor überhaupt der Schreibvorgang startet. Da ist die Rede von irgendeinem gemounteten Volume das nicht sein dürfte !! Ähhhm … ich nix Nerd, mach einfach, NÖ.
Nächste logische Entscheidung ich mache eine 1:1 Kopie von SSD nach SSD. Eine im USB3.x Dock, die andere SSD am PC SATA-Port.
Und JA, der Vorgang läuft, ist mir aber deutlich zu langsam mit 2GB/Minute. Ich unterbreche die Aktion brutal und klemme beide SSD’s an interne SSD-Port’s. Aha, 20GB/Minute ….. 2GB/Minute !!! Der gleiche Sch%&/$
Wie doof ist Rescuezilla eigentlich, geht wohl auf Nummer sicher und kopiert gemütlich Sektor für Sektor, lass laufen den Mist …
Immerhin läuft die 1TB SSD direkt beim ersten Versuch im TV-PC.
Rescuezilla Image Explorer
Nun möchte ich vom Original 1TB Image noch einige Video’s extrahieren, Pustekuchen !! Da steht ja auch BETA, AHA !!
Dieses dämliche Tool schafft es nicht mal ein eigens erstelltes Image
einzuhängen und einige Dateien zu extrahieren, OMG (2026) !
Ubuntu Logisches Volume DRAMA
Dann stelle ich fest, das bei EINER Aufnahme oben 43% voll steht, ähm da ist doch ‘ne 1TB SSD drin !! Ich stelle fest, das die Aufnahme Partition ein Logisches Volume ist und z.B. mit gparted oder dem Programm “Laufwerke” nicht mal eben logische Partitionen vergrößert werden können.
Wie diese Logische Partition drauf kommt ?? Tja, das passiert wenn in der Ansible Installations-Anleitung nicht die geringsten Informationen stehen wie man die dutzenden technischen Fragen bei der Ubuntu-Server Installation beantworten soll.
Ich erinnere mich nämlich vieles nach Gefühl beantwortet zu haben, was bleibt einem auch übrig.
Die nächsten Schritte mache ich mit der 1TB SSD direkt an meinem Arbeit-Rechner (SATA Docking-Station).
Also grundsätzlich wird die echte Partition zuerst tatsächlich mit gparted vergrößert. Das ist der Container in dem dann wieder das Logische Volume liegt.
Extend the logical volume :
sudo lvextend -l +100%FREE /dev/mapper/ubuntu–vg-ubuntu-lv
/dev/mapper/ubuntu–vg-ubuntu-lv so heißt bei mir dieses Logische Volume, abzulesen mit df -h
Resize the filesystem so the OS can recognize the new space :
sudo resize2fs /dev/mapper/ubuntu–vg-ubuntu-lv
Nach dem letzten Befehl blinkt die Activ-LED der Docking-Station immer weiter, als ob das Drive noch etwas macht … werde es nun Aushängen … in den TV-PC hängen.
ES KLAPPT !!!! 2% Belegung (1x Nuhr im Ersten 196:56 frei steht oben !!!
Windows eben mal ein Programm installieren, SETUP downloaden, installieren, fertig.
LINUX, hier gibt es die Anwendungsverwaltung, oder eben mal AppImages, wo man sagen kann “läuft” einfach.
Aber sehr oft ist es so, man hätte sehr gerne bestimmte Programme, aber auch nur deren Installation ist der Horror pur.
Ich erkläre :
Es sind oft extrem viele Konsolen-Kommando’s umzusetzen. Dabei werden sehr viele unbekannte Dinge installiert und das wer weiß wohin. Bei führen diese Installationen in der Regel ganz schnell zu Situationen wo ich dann keinen Bock mehr habe. Das sehr ungute Gefühl nun vieles am Rechner zu haben das man nie mehr weg bekommt bleibt. Und da dürfte auch kein “Timeshift” Wiederherstellung helfen.
Warum scheint es unmöglich zu sein das für LINUX mal EIN Installer oder was auch immer erscheint, der sich weltweit durchsetzt ?! So das JEDER jedes Programm installiert UND deinstalliert bekommt !
Das ist so dermaßen deprimierend, oft steht man frustriert da, hätte gerne bestimmte Programme, bekommt die aber nicht zum laufen und hat den Rechner noch zugemüllt.
Aktuell ist unter MINT der Firefox 149.0.2 drauf. Das Phänomen tauchte exakt eine Version davor auf. Nach einem Firefox Update war es dann plötzlich so. Geht man auf ein Bild und macht einen Rechts-Klick tippt ‘u’ für “Grafik speichern unter” geht wie üblich der Speicher-Dialog auf, ABER der Fokus bleibt offensichtlich auf dem Firefox-Fenster im Hintergrund. Betätigt man z.B. Cursor hoch/runter sieht man wie die Web-Seite im Firefox scrollt.
Es fiel natürlich dadurch auf, das der Cursor NICHT wie üblich im Speicher-Dialog beim Filenamen hängt und man diesen direkt umbenennen kann.
Und wie üblich schiebt wieder jede Abteilung das Problem auf den Anderen zwischen MINT und FIREFOX.
Hier der empfohlene Workaround :
Firefox 149 Speicher-Dialog Focus Workaround
Bei mir funktioniert das auch tadellos bis auf die Tatsache, das der Speicher-Dialog mit meinem Dark-Theme nun links dunkel und die File-Liste in hell dargestellt wird.
23.4.2026
Heute trudelt wieder ein Firefox-Update (150.0) rein…und auch damit verschwindet der Effekt nicht 🙁
Linux Mint viele kleinere Updates gemacht unter anderem war auch ein Firefox Update dabei. Seit Jahren konnte man im Firefox auf ein Bild gehen, Rechte Maustaste, dann ‘u’ getippt, der Speichern unter Speicherdialog ging auf.
Tut er auch noch immer. Leider kann man nun NICHT mehr direkt den Dateinamen Editieren und ENTER drücken weil der Speicherdialog keinen Focus hat, sondern scheinbar immer noch der Firefox im Hintergrund-Fenster. Drückt man nämlich TAB in der Hoffnung man könne im Dialog-Fenster zum Dateinamen gelangen sieht man im Hintergrund zufällig die untere STATUS-Leiste des Firefox. Dort verändert sich jedes mal der Link zu dem man ungewollt mit TAB springt.
Also ich hab ja schon so einiges gesehen, das ein Speicher-Dialog aufgeht der Cursor fröhlich beim Filenamen blinkt man aber nix editieren kann weil der Fokus in Wirklichkeit woanders im Speicher-Dialog hängt. Aber das nun der Fokus in einem aufrufenden Fenster im Hintergrund liegt ist doch mal ‘ne neue Qualität. Einfach nur traurig so etwas.
Wer ist hier der Schuldige, Firefox oder MINT selber ?!
Jetzt muß man jedes mal mit der Maus in den Speicher-Dialog klicken um den zu aktivieren !!
Ich Update den Pi mit sudo apt update und danach sudo apt upgrade. Es werden über 500 MB geladen und installiert, naja nach einem halben Jahr. Der OS Codename ist Bookworm, aktuell wäre Trixie, man kann aber nicht von einer zur anderen Version springen, leider.
Ich riskiere es und mache auch noch ein sudo apt autoremove, das listet nur Linux-Headers also Kernel die weg können, ich sage JA.
Ich starte den Pi neu mit shutdown -r (Neustart)
Ich suche nach einer Möglichkeit die 64GB SD-Partition auf die vollen 128GB der SD-Karte aufzublasen und finde schnell raspi-config das schon installiert ist. Das bietet unter die Funktion Expand Filesystem, die genau dafür gedacht ist.
Ich drücke ENTER : es kommt KEINE textliche oder grafische Vor-Ansicht bei so einer wichtigen Aktion. Nur eine Meldung root Partition wurde auf volle Größe erweitert, Neustart erforderlich, der auch direkt angeboten wird … bibber
raspi-config – Partitions-Erweiterung
Danach teste ich mit lsblk die Partitions-Größen
lsblk – Partitionen
Sieht ja erstmal OK aus, ich gebe noch ein df -h /home/pi
df -h /home/pi
Das mache es dann ganz deutlich, Available 102GByte im Home-Directory, also auf dem gesamten root-Pfad.
Nein ist besser so, sonst werkelt der Pi nur auf der halben SD-Karte rum, was diese schneller altern läßt. Nach der Erweiterung kann der Pi auf der gesamten SD-Karte wirken.
Was für ein Drama mal wieder. Nach Jahren treuer Dienste funktioniert plötzlich mein Raspberry Pi 3 B+ nicht mehr. Ich stele fest das die LAN Verbindung nicht mehr leuchtet. Dann fällt mir auf, das die ACT LED nix mehr macht.
Sofort schreibe ich auf eine andere SD-Karte ein Raspi-OS-Image, nix, die ACT (Drive-Activitäten) LED ist tot. Kurz nehme ich den steinalten Raspberry Pi 2, alles gut mit der ACT-LED.
Nach intensiven Test’s bestelle ich einen Raspberry 4 B mit 1GB.
Lasset die Spiele beginnen
Der Pi 4 ist angekommen und ich stecke Hoffnungsvoll die alte 64GB SD-Karte rein, jau, er bootet in den Desktop. Fröhlich passe ich die IP-Adresse wieder an, teste, alles bestens. Und ab damit ins 19″-Rack … nix geht mehr, wieder alles zum Arbeits-PC um letztlich festzustellen – die 64GB SD-Karte ist TOT/DEFEKT/ENDE. Dabei hatte ich am Pi 4 vorm Umbau sogar einen SHUTDOWN gemacht und gewartet bis die Drive LED aus bleibt !!
TOTAL-KATASTROPHE, denn wie der Mensch so ist länger schon kein BACKUP mehr über’s LAN gesichert. Das letzte BACKUP stammt von 09-2025 :O
So ein MIST jetzt beginnt wieder dieser ganze Dreck mit OS/APACHE/PHP/SSL/HTTPS-ZERTIFIKATE/MYSQL/WORDPRESS. Das ist ein tagelanges Gefrickel, oft ohne Sinn und Verstand.
Was ich versucht habe
Zuerst händisch wieder alles nach irgendwelchen kruden Anleitungen/Video’s zusammen-installiert.
Dann nach Tag 1 finde ich durch Zufall ein IMAGE-File auch von 09-2025. Tja, dann bin ich ja gleich fertig. Da ich Images wenn überhaupt nur mit Clone/Rescue-Zilla erstellt haben kann, Kinderspiel…von wegen.
Ich habe bestimmt EINEN TAG damit verbracht sowohl mit Clonezilla als auch mit Rescuezilla das Image zurück zu spielen, KEINE Chance.
Clonezilla ist da mal die größte Enttäuschung. Das Teil listet das Save/Restore Directory nicht mal ansatzweise komplett, findet das Image gar nicht obwohl es vor der Nase liegt.
Rescuezilla ist da viel schöner, wunderbar kann man mit der Maus navigieren. Es findet das Image ohne Probleme. Leider endet die Freude beim zurückspielen. Erst werden Partitionen generiert, dann kommt die Haupt Partition dran…ERROR. Rescuezilla meckert weil beim Ziel-Datenträger ein paar hundert Bytes zu viel/wenig da sind. Absolut lachhaft, altes Image stammt von besagter 64GB SD-Karte und soll neu auf eine 128GB SD-Karte. Wo kann es hier kapp oder eng werden ?!?!?
Jetzt kommt der größte Witz, die USB-Abbilderstellung von Linux Mint schafft es ganz easy das Image zurückzuspielen. Leider enthält der wp-content-Ordner von WordPress danach aber viel zu wenig Daten.
Jedenfalls läuft der Pi 4 erstmal mit diesem Image. Es beginnt eine Odyssee des Hacken’s per Putty, Rechte neu vergeben, Passworte vergeben, Datenbank manuell erstellen dann Import eines Datenbank-Dump’s. Dann noch WordPress die DB-Zugangsdaten beibringen.
Endlich nach gefühlt 3 Tagen sehe ich Licht am Ende des Tunnels.
Ich sehe meine Webseite, natürlich verstümmelt ohne Grafiken. Durch totalen Zufall ist der letzte erhaltene POST einer über Zertifikat Erstellung, ich folge meinem eigenen Schrieb und siehe da die Seite wieder in voller Pracht.
Dann stelle ich in WordPress unter Einstellungen/Allgemein diese beiden Seiten-Links um lösche /wordpress hinter der URL, bibbernd speichere ich. Erst klappt danach nix mehr, kriege es aber schnell wieder hin.
Dann machen natürlich wieder die Permalinks Probleme, EINFACH funktioniert, BEITRAGSNAME geht schlecht/nicht weil bestimmte Links damit nicht funktionieren. Genau das hatte ich schon mal und zum Glück hatte ich notiert wie die Lösung war.
In der /etc/apache2/apache2.conf muß unter <Directory var/www/> Allow Override auf ALL stehen. Danach mysql (mariaDB) und Apache durchstarten. Leider funktionieren danach die Permalinks mit Beitragsname genau so wenig.
Permalinks und Apache-Rewrite
.htaccess Rewrite manuell hinzugefügt
Weil WordPress normalerweise bei jeder Permalink Änderung + Speichern eine versteckte .htaccess generiert, das aber dieses mal NICHT tut, erstelle ich mühsam Eine per Hand im html-Ordner
Und siehe da, mit der Permalink-Einstellung auf Beitragsname funktioniert es nun wieder.
Und ich wette das hat mit den Schreibrecht-Problem zu tun das ich nun beschreibe.
WordPress kann nicht Uploaden/Plugins Updaten usw.
Was ist das nun wieder, WordPress meckert herum will ich Bilder (Medien) uploaden.
Keine Server Schreibrechte
Auch nach intensiver Recherche finde ich keine Lösung. Und natürlich mache ich ein chown rekursiv für verschiedenste Ordner.
Nächster Morgen
Es kann so einfach sein, chown ist die Lösung. Ich habe (warum auch immer) WordPress 2x, einmal direkt im html-Ordner und einmal in html/wordpress. Welches ist nun das ECHTE ?
Rekursiv, also incl. aller Unterordner, gebe ich folgenden Befehl ein :
ES GEHT WIEDER – WordPress kann Uploaden und es gehen auch Plugin-Updates wie gewohnt.
Nun will ich schauen WO die Bilder-Upload’s nun landen.
Leider kommt durch das chown plötzlich mein pi User nicht mehr in den html-Ordner. Ich füge den pi User der Gruppe www-data hinzu mit :
sudo usermod -a -G www-data <Benutzername> sudo systemctl restart apache2
Nö, geht immer n.n. Da fällt mir ein, das man User Ab/Anmelden muß damit Änderungen wirksam werden. Und es funktioniert, mein Pi-User kommt wieder auf html und alle Unterordner.
Ich schaue nach wo nun der neu kreierte 2026/03-Ordner liegt und es ist /var/www/html/wp-content/uploads/2026/03
Also dürfte das WordPress in html/wordpress irrelevant sein. Bevor ich den Ordner lösche benenne ich Ihn testweise um.
sudo mv wordpress / aaaa/
WordPress läuft weiter, ich lösche den aaaa-Ordner mit sudo rm -R aaaa
Nachtrag
Und sieh mal einer an, nachdem ich eben die Permalink-Einstellungen änderte/speicherte hat WordPress in MEINE hand-getippte .htaccess die gleichen Einträge nochmals eingetragen. Ich lösche dort als mein mühsam hand-getipptes raus weil doppelt.
Seit ich meinen Pi Webserver neu aufsetzen mußte kann ich in den WordPress Einstellungen/Permalinks umstellen was ich will, es funktioniert ohne 404 Error nur “Einfach”.
Jeder, aber auch Jeder im Netz sagt “ist ganz einfach” – “einmal auf irgendwas umstellen, Speichern, wieder umstellen, Speichern – ALLES GUT”.
> FUNKTIONIERT ABER LEIDER NICHT <<<<
Nachdem ich vor Tagen geistig erstmal aufgegeben habe – heute nochmal ein Versuch.
Zuerst finde ich so Hinweise wie “chmod 777 .htaccess”, damit auch alles und Jeder schreiben darf (auch WordPress). Aber WordPress konnte immer in die .htaccess (unsichtbar im WordPress-Ordner) schreiben.
Jedes mal wenn ich von “Einfach” auf irgendwas anderes umstelle kommen 404 Error klicke ich irgendwas auf meiner Page an.
DER TIP
In der /etc/apache2/apache2.conf hiernach suchen :
apache2.conf
Dort das None durch All ersetzen und mit Strg + O speichern und mit Strg + x verlassen.
Was ich jetzt hier schreibe ist nur aus dem Gedächtnis wiedergegeben und das vom Hacking über eine Woche hinweg.
Was war passiert
Wenn ich das so genau wüsste, denn ich bin mir keiner Schuld bewußt. Jedenfalls lief meine Wesbeite (Diese) gar nicht mehr und das obwohl im No-IP Account meine korrekte Dynamische IP hinterlegt war und der Router unberührt blieb (Port Forwarding).
Irgendwie entdeckte ich das im Apache Status diesem scheinbar ein SSL Zertifikat fehlte oder leer sein soll und er deswegen nicht starten wollte.
Über eine Woche absolutes Chaos
Zuerst war es mir tagelang nicht so wichtig, dann plötzlich WordPress Entzugs-Erscheinungen, der Ehrgeiz packte mich. Und ich muß sagen WordPress scheint unzerstörbar, denn seit gefühlt 15 bis 20 Jahren habe ich noch keinen POST verloren.
Klar läuft ein Backup-Plugin das wöchentlich mal ein Backup erstellt. Ab und an lade ich dann mal eines runter zum sichern. Auch mache ich ab und an einen SQL-Dump um die Datenbank zu sichern.
Das Problem dieses mal war das ich weil der Apache nicht lief auch nix in WordPress machen konnte und ich kein sehr aktuelles SQL-Dump hatte aber immerhin ein recht junges WordPress-Backup.
Rettungsversuch Apache SSL Zertifikat
Natürlich versuchte ich zuerst eben ein SSL Zertifikat neu zu generieren, aber finde mal eine funktionierende Anleitung. Das klappte schon mal nicht. Irgendwann gab ich auf und befasste mich mit einer Neu Installation.
Raspberry neustes OS
Wenn schon dann muß ich eine neue SD-Karte (größer) mit dem neusten Raspberry OS bespielen. Das machte ich mit dem Raspberry Pi Imager. Mein OS war wirklich schon alt und ein kompletter Sprung on the Fly ist mit Risiken behaftet.
Ich weiß nicht wie oft (bestimmt 6-10x) ich die SD-Karte neu aufgesetzt habe. Das OS lief erwartungsgemäß sauber, aber es gibt da einige Änderungen seitens Raspberry.
Der Imager bietet sehr unauffällig vor dem Schreiben einige Optionen an, wo man schnell mal einfach weiter klickt. So mußte ich schmerzlich erfahren das es KEINEN User ‘Pi’ mehr gibt überspringt man es. Oder auch diese Sache mit dem SSL Zugriff, kann man abhaken in den Optionen.
Egal, nach mehreren Neu Beschreiben der SD Karte war die Basis gesetzt.
Der Horror beginnt (und nahm kein Ende)
Apache, PHP, mariaDB, phpmyAdmin, WordPress, FTP-Server und was ich noch alles eben mal installieren. Eigentlich geht das gut findet man mal eine halbwegs moderne Anleitung. Dafür brauchte ich bestimmt 1-2 Tage von morgens bis Nachts.
Während all diesem Gefrickel fällt mir absolut unangenehm auf diese chown und chmod Linux Dinger. Das absolute Grauen, jeder sagt was anderes. Jede Software will eigen Rechte. Klar ist das echt sicher, aber das Handling ist würg.
Als dann die Basis Software drauf ist fehlt noch WordPress. Wahrscheinlich hätte ich den alten Inhalt ‘einfach’ (User Lese/Schreibrechte) kopieren können nach /var/www/http aber irgendwas hat mich veranlasst WordPress erstmal neu zu ‘installieren’ und dann über zu Kopieren.
Also WordPress tar.gz in den html Ordner down geloaded/entpackt. Der Apache lief auch (noch ohne SSL https) und WordPress Startseite lief.Per phpmyAdmin hatte ich eine leere Datenbank ‘wordpress’ angelegt.
Und jetzt kommt der Hammer.
Wie doof kann ich (WordPress-Programmierer) sein ?
Wirklich 2 Tage lang die simple Installationsseite wo oben der Datenbankname steht (tut es das wirklich ?) versucht zu absolvieren.
Immer kommt eine Fehlermeldung ‘Datenbank nicht gefunden’ blabla. Irgendwann erkenne ich dann, der vorgefertigte ‘wordpress’ Schriftzug ist gar kein echter Eintrag im Feld Datenbank !!!
Das ist nur ein Schatten-Vordruck was sein könnte !!!!!!!!
Ich habe wegen der kaum erkennbaren Unterschiede (grauer Vordruck vs schwarz echter Eintrag) nicht realisiert das ich dort ‘wordpress’ rein schreiben muß !!!
Jedenfalls lief WordPress dann.
Das DRAMA des Datenbank Import
Oh mann ich finde keinen halbwegs aktuelle SQL-Dump, was nun. Nach vielen Querelen komme ich auf die Idee – starte den Pi mit der alten SD Karte um per Putty direkt in der mariaDB einen Dump des ‘Jetzt’ Zustandes zu erstellen.
Hatte ich noch nie gemacht, wußte auch nicht das es sowas gibt. Klappte jedenfalls.
Ein Drama immer wieder ‘wie bekomme ich Files auf die neue SD Karte ? Klar habe einen Card-Reader aber diese verdammten Schreib/Leserechte. Irgendwann habe ich es dann immer so gemacht, die neue SD Karte in den Reader und was auch immer nach /home/pi kopiert.
Dann den neuen Pi wieder gestartet und per phpmyAdmin die ‘wordpress’ Datenbank importiert.
Das darf man sich wieder nicht so einfach vorstellen, weil in irgendwelchen phpmyadmin config Files steht man dürfe nur satte 2MByte hochladen. Ähm wir haben 2025 !!
Alles auf 50MByte hoch gesetzt. Mein Dump war gerade mal 15MB groß. Danach klappte der Import.
SSL
Da Webseiten heutzutage https:// haben müssen muß ich wieder Zertifikate erstellen usw. Außerdem ist WordPress auch auf https:// geeicht. Will ich im Detail nicht erklären, aber wieder ziemlich viel Gewurschtel.
WordPress Links funktionieren nicht
Irgendwann lief WordPress dann auch im alten Muster, ich war ganz erstaunt das sogar die Plugins da waren. Leider funktionierten keinerlei Links. Die POST’s waren auf der Hauptseite sichtbar. Klicke ich aber auf irgend etwas kommt ‘Not Found’ Apache Meldung. Als URL steht im Browser aber der gewünschte Post-Link.
Immer wieder auf Anraten in WordPress unter Einstellungen – Permalinks die Permalink-Struktur umgestellt und Gespeichert. Danach wieder zurück zur alten Einstellung und Gespeichert.
Keine Besserung und ich finde auch KEINE Lösung.
Dann aus Verzweiflung stelle ich mal auf ‘Einfach‘ um speicher das und ES FUNKTIONIERT !!!!!!!!!!
Alles geht wieder Gallerien, In-POST Foto’s öffnen usw.
Danach probiere ich viele andere Permalink-Strukturen, keine funktioniert außer ‘EINFACH’
Dieses Umstellen der Struktur ändert beim Speichern die unsichtbare .htaccess Datei im WordPress Ordner selber. Der Apache richtet sich nach dieser Datei und schreibt URL’s um damit Sie im Browser lesbarer erscheinen.
Das ist nur ein ganz kurzer Außschnitt meiner Erlebnisse über bestimmt 5 Tage am Stück nur gehackt am Pi
Später
Oh, eben probiere ich mal ob’s am Handy funktioniert, ja, bis ich zufällig auf einen Post treffe, der einen Link zu einem anderen Post hat. Und der, man höre und staune, nicht automatisch beim ändern der Permalink-Struktur mit geändert wird. Da hat mal wieder ein WordPress Programmierer gut aufgepasst.
Homecomputer Elektronik PC Synthesizer Windows Linux
196:56 frei steht oben !!!
