Der Versuch, eine Datei oder einen Ordner zu löschen, umzubenennen oder zu verschieben, scheitert oftmals, weil Windows noch einen Zugriff auf eine enthaltene Datei feststellt.
Bis zur aktuellen Version von WordPress (5.4) gibt es beim mitgelieferten Widget „Schlagwörter-Wolke“ (Tag Cloud) keine Möglichkeit, nur die Schlagwörter einer bestimmten Kategorie anzeigen zu lassen (Tag cloud by category).
Auch die Suche nach einem einfachen – und vor allem aktuellen – PlugIn führte nicht zum gewünschten Ergebnis.
Die aktuellen Zeiten sorgen dafür, dass jeder – der kann – von zu Hause aus arbeitet.
Zusätzlich müssen unsere Kinder, groß und klein, irgendwie vernünftig beschäftigt werden und dabei bestenfalls auch noch Lerneinheiten bekommen, damit die Wochen ohne Schule nicht einfach so vorbeirauschen.
Das alles ist nicht nur eine große Aufgabe und auch eine Belastung, oft fehlt es an Möglicheiten und Hilfsmitteln, das umzusetzen.
Eine Java-Webstartanwendung wird unter Windows auf hochauflösenden Displays sehr klein angezeigt.
Die Skalierung in den Displayeinstellungen helfen hier nicht wirklich weiter, weil sie zum Einen nicht ausreichen und zum Anderen eben alle anderen Anwendungen usw. auch extrem vergrößern und somit das Arbeiten letztlich unmöglich machen.
Die Umstellung von HTTP auf HTTPS sollte inzwischen jeder vollzogen haben.
Doch der ganze ‚alte‘ Content müsste dazu geprüft werden, auch gibt es zahlreiche andere Stellen in einer gewachsenen Seite, die angefasst werden müssten.
PlugIns wie z.B. Really Simple SSL und andere helfen hier, indem die entsprechenden Links und Einstellungen on-the-fly durch das PlugIn umgesetzt werden… Links usw. werden also nicht im Original sondern zum Zeitpunkt der Auslieferung entsprechend geändert.
Nach einem Update auf die aktuelle WP-Version v5.3 war es aber genau solch ein PlugIn, dass mir den oben genannten Fehler erzeugte.
Jedes Mal, wenn ich einen Blogbeitrag speichern oder veröffentlichen, oder z.B. ein Beitragsbild zuordnen wollte usw., kam die Meldung „The response is not a valid JSON response.“.
Um es kurz zu machen… das schlichte Deaktivieren des PlugIns war dann schon die Lösung. Der Hoster und die aktuelle WP-Version tun hier soweit schon ihren Job.
Aber letztlich werde ich dann wohl doch in nächster Zeit mal meinen alten Content prüfen und an entsprechender Stelle anpassen.
Quelle: [1]
Update:
Das Problem trat dann doch nochmals auf und lag letztlich an Seitenelementen, die weiterhin via HTTP statt HTTPS eingebunden wurden. Diese zu identifizieren ist letztlich recht einfach:
Im Firefox unter ‚Extras‘ -> ‚Web Entwickler‘ die ‚Web-Konsole‘ (oder via STRG+UMSCHALT+K) öffenen.
Dort werden direkt die unsicheren Elemente gelistet und können einzeln bzgl. der Anbindung angegangen werden.
Bei mir waren es dann noch einige Grafiken in der Mediathek, die noch HTTP als URL hinterlegt hatten. Die Korrektur habe ich dann mit dem PlugIn Suchen & Ersetzen Von Inpsyde GmbH erledigt.
Alternativen gibt es dazu natürlich auch, z.B. hier…