Beiträge von paradonym

Danke sehr. Genau das war das Problem (ich hätte nie gedacht, dass die Warnmeldung in der Zuständigkeit meines eigenen Uberspaces liegt - zumal nach einem Umzug, nicht nach einer kompletten Neuerstellung eines shared hosting spaces).

Uberspace war das Problem bekannt und hat dies, weil es mehrfach für Verwirrung sorgte gelöst:
https://github.com/Uberspace/lab/pull/746

Nach einem Serverumzug bei meinem Hoster Uberspace ist die Homepage meines Blogs nicht mehr erreichbar, allerdings sind die einzelnen Posts und Permalinks ohne Probleme aufrufbar und auch das Backend funktioniert ohne Probleme.

Serverumzug-HowTo: https://wiki.uberspace.de/uberspace2uberspace
Nach anpassung des DNS
- läuft https://schnell.news/ ins leere,
- Auch der aufruf von https://schnell.news/index.php läuft ins Leere
- https://schnell.news/wp-admin/ läuft aber weiterhin ins Backend bzw. ins Logininterface.
- https://schnell.news/surface-basics…ogramme-nutzen/ und andere Permalinks (das soll hier keine Werbung sein) - funktionieren tadellos.
- Auch andere WP-Unabhängige Pfade funktionieren tadellos.

Bereits probiert:
- deaktivierung aller Plugins
- zurücksetzen der .htaccess auf den Standardwert nach Wordpress-HowTo
- ändern der Permalinkstruktur und zurücksetzen auf den alten Permalink
- Schalte ich WP_DEBUG in der Config ein geht das Backend mit Fehler 500 offline, die besagte debug.log wird auch nicht geschrieben

Ich kann natürlich via SSH die WordPress-Daten löschen und überschreiben und dann jeweils aus einem Export mit gesichertem wp-content Ordner WordPress komplett neu aufsetzen - das möchte ich aber gerne vermeiden.

Woran kann das liegen? Das Script von Uberspace zum Serverumzug besteht soweit ich das verstehe aus einer Kopie der Daten auf einen neuen Shared hosting space und der Kopie von cronjobs etc.

Kurz nach einem Update auf 4.9.1 erscheint bei jedem Aufruf einer php seite ein Fehler 500... Einige Stunden nach dem Update hat das Backend noch funktioniert.
Die Website selbst läuft ohne Probleme, ausschließlich php-seiten und damit auch die Loginseite und das komplette backend laufen in den Fehler.

.htaccess macht nur noch SSL-Redirect bei http-Anfragen und die Auslieferung von Brotli bzw. webm Grafiken.
Bis auf das Update wurde nichts am Backend hinzugefügt oder geändert.

Gibt es noch etwas was ich testen sollte bevor ich die "radikal-Methode" http://wiki.mediaagentur-in.berlin/wiki/wordpress…-error-beheben/ (reinstall + recovery aus Backup) angehen sollte?

Komisch. wp-cli installiert, einmal über die Kommandozeile ein Plugin aktualisiert und nun geht das gleiche auch wieder direkt aus dem Backend heraus.

Das Thema kann also als Gelöst markiert werden.

per wp-cli ist ein Update nun problemlos durchgelaufen, ohne aktiv bleibenden 5-Minuten-Wartungsmodus... zumindest laut CLI alles erfolgreich. - Wobei der Output und damit die Prozeduren dahinter doch eigentlich die gleichen sind die auch Wordpress aus dem Backend heraus anschmeißen würde...

Zitat von FloRet

Hallo,

Das Standard-Theme von 4.6.1 ist twentysixteen!

Ja kannst du - über FTP oder direkt via Backend hochladen / aktivieren.

Die Schritte sollten bereits des öfteren im Forum beantwortet worden sein: Beispiel

LG

Wie man löscht / installiert weiß ich bereits. Aber ist das reine "deaktivieren" auch per SSH ohne Backend möglich? Also nicht das ganze rauslöschen des Plugins, sondern das reine deaktivieren...

Könnten die reinen Wordpress-Dateien in einer bestehenden Installation eigentlich "überschrieben" werden? Also einfach ein Wordpress-Archiv herunterladen und dann die Dateien aus dem Archiv mit denen auf dem Server ersetzen?
Alle reinen Daten sind soweit ich gesehen habe ja in der SQL-Tabelle und sofern sich die wp-config.php nicht ändert müsste das doch klappen...

Zitat von SirEctor

Deaktiviere mal alle Plugins außer Yoast und wechsel auf ein Standard-Theme und teste es dann. Ich vermute das Theme ist zu alt, oder ein Plugin stört.

Welches wäre das Standardtheme von 4.6.1? Zwecks Fehlerbehebung für das letzte mal flog dies raus.
Und - Können Themes/Plugins per SSH-Zugriff ohne Admin-Backend gewechselt/deaktiviert werden, wenn ja - wie?

Ich habe eine Wordpress-Installation die für ~1 Monat bis auf Auto-Update nicht sonderlich gepflegt wurde.

Seit heute resultiert jeder Versuch ein Plugin zu aktualisieren (getestet an Yoast SEO und einem Wordpress Theme) in einem Maintenance Mode der sich nach ca. 5 Minuten selbstständig wieder beendet.

Momentan aktive Plugins: Screenshot -> https://db.tt/IBUQ6HS3 ("Get Current Mail" ist ein nach Anleitung selbst erstelltes Plugin, welches per PHP eine einzelne Datei aus dem Server ausliest und daraus einen Wordpress Shortcode macht ohne gleich PHP-Vollzugriff geben zu müssen)
Deaktiviert sind nur drei Importer-Plugins - diejenigen die auch unter Werkzeuge verlinkt sind...

Weiß jemand woran das liegen könnte? Ich könnte natürlich wieder Backup&Restore auf eine frische Version machen, aber vielleicht ist das einfacher zu lösen als gleich alles einmal neu zu machen.

Im Apatche-Log steht nichts...
Die Seite ist auch keine Standard-Fehlermeldung, sondern ein einfacher Text, der genau das besagt.

Fehler: Meldung "An internal Server occurred..." bei Plugin-Installationen
Behebungsversuch: Wordpress Dateien auf dem Server gelöscht und nächste Wordpress-Installation mit anderem $table_prefix = ''; in der wp_config.php installiert (damit die alten SQL-Daten erhalten bleiben).
Nach Import der Alten Beiträge über Werkzeuge -> Daten importieren in der neuen Wordpress-Installation, gleicher Fehler "An internal Server occurred..." beim Versuch Plugins zu aktualisieren oder zu installieren.

macht das einiges klarer?

Ich habe Vollzugriff auf den Server per SSH - wo liegt die passende error.log Datei die erwähnt wurde?

Werkzeuge -> Daten exportieren, danach Import über https://wordpress.org/plugins/wordpress-importer/ (vor dem Import funktionieren Plugin-Installationen ja noch). Über phpmyadmin kann ich das ja nicht machen, und habe ich auch nicht, weil es bisher immer mit den Wordpress-Tools funktionierte

Sobald ich die vorher exportierte Backup-XML importiere, gehen Plugin-Installationen nicht mehr und laufen auf das beschriebene Problem hin, das heißt irgendwas an dem Export muss den Fehler mitnehmen, und wird dann vermutlich auch so sein, wenn ich das Recovery per phpMyAdmin mache...

Ich würde jetzt ungerne über 400 Beiträge manuell als Quelltext wegsichern und neu anlegen müssen...

Das hilft leider nicht viel. Auch da ist das gleiche Problem...

Vermutlich nach einem automatischen Update von Wordpress funktionieren Plugin-Installationen nicht mehr.
Der Prozess dauert knapp zwei Minuten, bevor eine Meldung erscheint "[COLOR=#000000][FONT=&amp]An internal server error occurred. Please try again later.[/FONT][/COLOR]".Allerdings als Wordpress-Meldung und nicht als genormte HTTP-Fehlermeldung.
Das eigenartige dabei ist, zum Zeitpunkt der Fehlermeldung ist der Wartungsmodus den Wordpress normalerweise setzt schon wieder beendet - dies ist laut WP immer der letzte Schritt...
Lade ich Plugin-Daten per SSH in \wp-content\plugins, kommen diese im Backend nicht an, versuche ich auf diese weise Plugins zu aktualisieren verschwinden diese aus der Backend-Liste.

Im Zuge dessen habe ich mir die Beiträge mit dem Export-Tool gesichert und \wp-content\uploads gesichert.
Setze ich Wordpress unter anderem Datenbankpräfix auf und importiere die Beiträge inkl. re-upload des uploads Ordners ist der Fehler allerdings wieder da.

Im uploads-Ordner befinden sich nur die Bilddateien die Wordpress verwendet hat, weiter nichts, daher stehe ich ein wenig vor dem Schlauch wie ich das Problem lösen kann ohne jedes Bild wieder manuell aus dem Backup in eine nächste Wordpress-Installation zu packen.

Problem gelöst:

extras.php vom Radium Theme.
Folgender Inhalt (inkl. Kommentar und Problemlösung durch Einkommentierung):
http://pastebin.com/aNLjNM9r

Dieser Absatz hat das ganze gelöst. Keine Ahnung ob es eine elegantere Lösung gibt, aber dort wurde ich fündig...

Hi,

ich habe das Problem, dass der Seitentitel für den Browser doppelt ausgegeben wird. Nicht innerhalb der Website, nur der Name für den Browsertab ist doppelt.

Laut Google ist das Problem irgendwo ein doppelter title-Code im Design oder in SEO-Plugins.
Als Theme verwende ich Radium:
dort lautet der Standard-Titel-Code in der header.php

<title><?php wp_title( '|', true, 'right' ); ?></title>

Das umsetzen auf den Standardcode für Seitentitel -

<title><?php wp_title(''); ?></title>

brachte nur die Entfernung des Strichs zwischen Name und Titel.

Auszug aus Radium -> custom_header.php:

Das einzige Plugin welches ich in irgendeiner Hinsicht auf SEO verwende ist Add Meta Tags. Dort gibt es eine Einstellung Namens "[COLOR=#444444][FONT=Open Sans]Custom content of the [/FONT][/COLOR]title[COLOR=#444444][FONT=Open Sans] HTML element.[/FONT][/COLOR]" für "Metabox features", welches eigentlich nur das Eingabefeld zum Ändern des Seitentitels pro Beitrag im "Beitrag erstellen" Fenster deaktiviert...

Im Code der Startseite befindet sich aber unter dem Code, welcher von Add Meta Tags eingefügt wurde eben jener doppelte Titel:
Blog-URL: https://schnell.news (Zeile 31)
Das kann ich aber so nicht im Design-Editor oder im Plugin-Editor für Add Meta Tags finden...
Kann mir jemand weiterhelfen, wie ich zu dem entsprechenden Code im WP-Editor komme?

Das einzige Plugin von YOAST (welches bei Google-Suchtreffern öfters für doppelte Titel angemeckert wird) ist Google Analytics by YOAST - in welchem ich aber auch nicht viel bezogen auf "wp_title" finden kann...

Auszug aus Radium -> custom_header.php:

<?php        // If the user has set a custom color for the text use that
        else :
    ?>
        h1.site-title a,
        .site-description {
            color: #<?php echo esc_attr( $header_text_color ); ?>;
        }
        .site-title a {
            border-color: #<?php echo esc_attr( $header_text_color ); ?>;
        }
    <?php endif; ?>
    </style>
    <?php

könnte das meine Probleme verursachen?

und mehrere Rewriterules für verschiedene Permalinkstrukturen sind kein Problem?
Wenn ich jetzt z.B. alle 3 RewriteRules aus https://wp-mix.com/remove-date-from-wordpress-permalinks/ unter den RedirectMatch schreibe

ich nehme dann mal an, um z.B. die Struktur [COLOR=#333333]/%year%/%monthnum%/%day/%id%/ auf /%postname%/ zu bekommen
braucht es ebenfalls wie im verlinkten Beispiel mit der Standard-Permalinkstruktur den htaccess-Code:

Zitat

[/COLOR][COLOR=#343434][FONT=Monaco]RewriteRule ^([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ /$4 [R=301,NC,L][/FONT][/COLOR][COLOR=#333333]

So wie ich den verstehe, nimmt sich mod_rewrite dann den Text, der hinter dem Datum steht (Vermutung: (.*)$ tut dies) und hängt ihn direkt an die TLD...
Was bei /%id% quasi das gleiche sein müsste... wie passe ich den jetzt so an, dass der Code auf /?p=%id% weiterleitet?[/COLOR]

Folgendes Problem:
Beim Wechsel der Permalinks, sind alte Links, die bereits in Sozialen Medien und co gepostet sind sofort ungültig.

Eine Problemlösung wäre es, einfach jede erdenkliche Permalinkstruktur auf die aktuell genutzte weiterzuleiten.
Mit den Standard-Permalinks /%year%/%monthnum%/%day%/%postname%/ wäre es ja recht einfach per htaccess mod_rewrite das Datum aus der URL zu entfernen und somit auf den inzw. meistgenutzten Permalink /%postname%/ umzuleiten wie hier beschrieben.

Ist es aber auch möglich z.B. /%year%/%monthnum%/%day/%id%/ auf /%postname%/ umzuleiten? In der ursprünglichen URL wird %postname% ja nicht genannt, was mod_rewrite irgendwie aufnehmen und abändern lassen kann.
Auch wäre es dann ja nett, wenn jede andere logische Konstellation an Permalink umgeleitet wird.

Gibt es dazu eine Möglichkeit oder ein Plugin welches die Aufgabe übernimmt?

Gelöst:
Es waren Erweiterungen aktiv, die die wp-login.php nicht öffentlich verfügbar machten und den Login so abschotteten, dass tatsächlich nur Webbrowser reinkamen. Zusätzlich hatte ich auch noch ein Google Authenticator-Programm drin.
Also war faktisch überhaupt gar kein durchkommen, wegen den Login-Mechanismen.