Support » Allgemeine Fragen » wordpress sitzung läuft immer wieder ab

  • Gelöst michaelbrilz89

    (@michaelbrilz89)


    Hallo zusammen, ich soll für unser Unternehmen ein Intranet erstellen und wir haben uns für WordPress entschieden. Jetzt habe ich seit letzter Woche das Problem, dass ich mich nicht sofort im Backend anmelden kann und wenn ich das mal endlich schaffe, werde ich nach paar Sekunden sofort wieder abgemeldet. Folgendes habe ich schon probiert, allerdings ohne Erfolg:
    -Lösche den Cache deines Browsers
    -Lösche die Cookies deines Browsers
    -Überprüfe die Einstellungen deines Browsers
    -Lösche den Cache deiner WordPress-Seite
    -Überprüfe die Adresse deiner WordPress-Seite
    -Deaktivieren und erneutes Aktivieren von WordPress-Plugins

    Außerdem habe ich das function.php file geleert, um zu schauen, ob es am Code liegt. Hat auch nicht geholfen.

    Da ich nicht ins Backend komme, kann ich auch kein Statusbericht erstellen um den hier reinzustellen. Leider habe ich auch kein Link zum Projekt, da die Seite nur aus dem privaten Netzt zu erreichen ist. Ich hoffe ihr könnt mir weiterhelfen.

    Da ich nicht ins Backend komme, kann ich auch kein Statusbericht erstellen, um den hier reinzustellen. Leider habe ich auch kein Link zum Projekt, da die Seite nur aus unserem privaten Netzwerk zu erreichen ist. Ich hoffe, ihr könnt mir weiterhelfen.

    • Dieses Thema wurde geändert vor 1 Jahr, 8 Monaten von michaelbrilz89.
Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 52)
  • Bis auf das LDAP Plugin,

    Woher werden die Anmeldedaten für den Adminnutzer geholt? Lokal aus der WordPress-Installation oder funkt da das Plugin dazwischen und sucht diesen in der LDAP-Datenbank?
    Ich nutze das Plugin nicht, aber ich habe mich schon an anderen (nicht WordPress) Stellen durch solch ein Szenario „gekämpft“.

    Thread-Starter michaelbrilz89

    (@michaelbrilz89)

    Die Zugangsdaten für den Admin werden lokal geholt, der Rest aus dem AD.
    Hättest du den eine Idee, was ich noch versuchen könnte?

    Kann es sein, dass du mit dem User Role Editor Änderungen an den Benutzerrechten des Administrators vorgenommen hast?

    Poste bitte nochmal die jetzt eingetragenen Website- und WordPress-URL.

    Thread-Starter michaelbrilz89

    (@michaelbrilz89)

    Nicht bewusst, laut meinen Kollegen, hat auch keiner was geändert.
    Schade das man keine Bilder Posten kann :/

    WordPress-Adresse(URL) http://intranet3.intern.xxx.de
    Website-Adresse(URL) http://intranet3.intern.xxx.de

    Wie kann man hier Bilder in einen Forenbeitrag einfügen?

    An den URLs wird es dann wohl nicht liegen.

    Thread-Starter michaelbrilz89

    (@michaelbrilz89)

    Folgende Cookies werden bei mir gespeichert (Keine Ahnung ob das für eure Hilfe relevant ist)
    – wordpress_test_cookie
    -wp_lang

    Was ich jetzt probieren würde (nacheinander oder/und einzeln):

    – das LDAP-Plugin deaktivieren.
    – Browser neu starten.
    – anderen Browser verwenden.

    Und immer die Entwicklerkonsole des Browsers im Blick haben.

    • Diese Antwort wurde geändert vor 1 Jahr, 8 Monaten von hupe13.
    Moderator Michi91

    (@michi91)

    Das was @hupe13 sagt. Erstmal minimalsetup testen…

    Thread-Starter michaelbrilz89

    (@michaelbrilz89)

    Guten Morgen zusammen,

    ich habe das von euch Empfohlene getestet, ohne Erfolg.
    Ich habe alle Plugins deaktiviert und den Browser geschlossen. Zudem habe ich
    Firefox, Chrome und Brave benutzt, auch ohne Erfolg.

    Bei Firefox bekomme ich folgende Meldung in der Konsole

    Das Cookie "wordpress_test_cookie" verfügt über keinen gültigen Wert für das "SameSite"-Attribut. Bald werden Cookies ohne das "SameSite"-Attribut oder mit einem ungültigen Wert dafür als "Lax" behandelt. Dadurch wird das Cookie nicht länger an Kontexte gesendet, die zu einem Drittanbieter gehören. Falls Ihre Anwendung das Cookie in diesen Kontexten benötigt, fügen Sie bitte das Attribut "SameSite=None" zu ihm hinzu. Weitere Informationen zum "SameSite"-Attribut finden Sie unter https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite.

    Hat das was mit meinem Problem zu tun? Kenne mich da nicht so aus

    • Diese Antwort wurde geändert vor 1 Jahr, 8 Monaten von michaelbrilz89.

    Nein, das hat damit nichts zu tun.

    Wird eigentlich bei der Anmeldung im Backend ein Cookie wordpress_logged_in_{hashwert} gesetzt?

    Geh bitte auch mal auf Dashboard > Aktualisierungen > WordPress 6.0.2 erneut aktualisieren. Damit soll sichergestellt werden, dass alle Dateien des Core vollständig übertragen wurden.

    Thread-Starter michaelbrilz89

    (@michaelbrilz89)

    Ist das unter wp_options zu finden?

    Wordpress habe ich gerade aktualisiert, allerdings ohne Erfolg. Bei den Erfolglosen Anmeldungen bekomme ich immer noch ein

    WordPress-Datenbank-Fehler: [Table wp_intranet.wp_user_report' doesn't exist]
    SHOW FULL COLUMNS FROM wp_user_report
    Powered by WordPress

    Fehler. Gerade kam auch ein Fehler wo stand, das mein Chrome keine Cookies zulässt und ich das erst aktivieren soll. Aber in den Einstellungen ist das bereits der Fall, dass alle Cookies zugelassen werden sollen.

    Die Tabelle wp_user_report muss von einem Plugin angelegt worden sein. Zum Core oder User Role Editor scheint sie nicht zu gehören.

    Durch die nervigen Cookie-Banner setzen viele User Browser-AddOns ein, die Cookies unterdrücken. Das kannst du aber ausschließen?

    Welche Cookies gesetzt sind, kannst du im Browser nachsehen: Taste F12 öffnet die Entwickler-Tools, im Tab App findest du unter Speicher > Cookies eine Liste aller verwendete Cookies.

    Zum Datenbankfehler:

    Trag bitte mal in der wp-config.php oberhalb von /* That's all, stop editing! Happy publishing. */ folgende Zeile ein:

    define( 'WP_ALLOW_REPAIR', true );

    Danach rufst du http://example.com/wp-admin/maint/repair.php (natürlich mit deiner Domain) im Browser auf und klickst auf den unteren Button zum Reparieren/Optimieren der Datenbank.

    Besteht der Datenbankfehler dann immer noch?

    Thread-Starter michaelbrilz89

    (@michaelbrilz89)

    Ja, das mit den AddOns kann ich ausschließen, da ich keine AddOns verwende.

    Nach dem Reparieren/Optimieren kommt dieser Datenbankfehler immer noch.

    Folgendes wurde nach dem Reparieren angezeigt:

    WordPress
    
    Ergebnisse der Datenbank-Reparatur
    Die Tabelle wp_users ist in Ordnung.
        
        Konnte die Tabelle wp_users nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_usermeta ist in Ordnung.
        
        Konnte die Tabelle wp_usermeta nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_posts ist in Ordnung.
        
        Konnte die Tabelle wp_posts nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_comments ist in Ordnung.
        
        Konnte die Tabelle wp_comments nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_links ist in Ordnung.
        
        Konnte die Tabelle wp_links nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_options ist in Ordnung.
        
        Konnte die Tabelle wp_options nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_postmeta ist in Ordnung.
        
        Konnte die Tabelle wp_postmeta nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_terms ist in Ordnung.
        
        Konnte die Tabelle wp_terms nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_term_taxonomy ist in Ordnung.
        
        Konnte die Tabelle wp_term_taxonomy nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_term_relationships ist in Ordnung.
        
        Konnte die Tabelle wp_term_relationships nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_termmeta ist in Ordnung.
        
        Konnte die Tabelle wp_termmeta nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Die Tabelle wp_commentmeta ist in Ordnung.
        
        Konnte die Tabelle wp_commentmeta nicht optimieren. Fehler: Table does not support optimize, doing recreate + analyze instead
    
    Reparaturen abgeschlossen. Bitte entferne die folgende Zeile aus wp-config.php, um diese Seite vor unauthorisierten Zugang zu schützen.
    
    define('WP_ALLOW_REPAIR', true);

    Das hier ist übrigens meine wp-config.php falls das was hilft.

    <?php
    /**
     * The base configuration for WordPress
     *
     * The wp-config.php creation script uses this file during the installation.
     * You don't have to use the web site, you can copy this file to "wp-config.php"
     * and fill in the values.
     *
     * This file contains the following configurations:
     *
     * * Database settings
     * * Secret keys
     * * Database table prefix
     * * ABSPATH
     *
     * @link https://wordpress.org/support/article/editing-wp-config-php/
     *
     * @package WordPress
     */
    // ** Database settings - You can get this info from your web host ** //
    /** The name of the database for WordPress */
    define( 'DB_NAME', 'wp_intranet' );
    
    /** Database username */
    define( 'DB_USER', 'xxx' );
    
    /** Database password */
    define( 'DB_PASSWORD', 'xxx' );
    
    /** Database hostname */
    define( 'DB_HOST', '127.0.0.1' );
    
    /** Database charset to use in creating database tables. */
    define( 'DB_CHARSET', 'utf8mb4' );
    
    /** The database collate type. Don't change this if in doubt. */
    define( 'DB_COLLATE', '' );
    
    /**#@+
     * Authentication unique keys and salts.
     *
     * Change these to different unique phrases! You can generate these using
     * the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}.
     *
     * You can change these at any point in time to invalidate all existing cookies.
     * This will force all users to have to log in again.
     *
     * @since 2.6.0
     */
    define( 'AUTH_KEY',         'put your unique phrase here' );
    define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
    define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
    define( 'NONCE_KEY',        'put your unique phrase here' );
    define( 'AUTH_SALT',        'put your unique phrase here' );
    define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
    define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
    define( 'NONCE_SALT',       'put your unique phrase here' );
    
    define('ENABLE_CACHE', false);
    
    /**#@-*/
    /**
     * Don't allow any other write method than direct
     */
    define('FS_METHOD', 'direct');
    
    /**
     * WordPress database table prefix.
     *
     * You can have multiple installations in one database if you give each
     * a unique prefix. Only numbers, letters, and underscores please!
     */
    $table_prefix = 'wp_';
    
    /**
     * 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.
     *
     * For information on other constants that can be used for debugging,
     * visit the documentation.
     *
     * @link https://wordpress.org/support/article/debugging-in-wordpress/
     */
    define('WP_DEBUG', true);
    define('WP_DEBUG_DISPLAY', true);
    define('WP_DEBUG_LOG', true);
    define('SCRIPT_DEBUG', true);
    
    /** Absolute path to the WordPress directory. */
    if ( ! defined( 'ABSPATH' ) ) {
    	define( 'ABSPATH', __DIR__ . '/' );
    }
    
    /** Sets up WordPress vars and included files. */
    require_once ABSPATH . 'wp-settings.php';
    
    /**define('WP_PROXY_HOST', 'xxx');
    define('WP_PROXY_PORT', '8080');
    define('WP_PROXY_BYPASS_HOSTS', 'localhost');*/
    
    @ini_set( 'upload_max_filesize' , '128M' );
    @ini_set( 'post_max_size', '128M');
    @ini_set( 'memory_limit', '256M' );
    @ini_set( 'max_execution_time', '300' );
    @ini_set( 'max_input_time', '300' );
    • Diese Antwort wurde geändert vor 1 Jahr, 8 Monaten von michaelbrilz89.
    Thread-Starter michaelbrilz89

    (@michaelbrilz89)

    Würde es war bringen, die Datenbank zurückzusetzen?

    Geht das auch ohne Plugin? Mir werden nämlich keine angezeigt, wenn ich nach was suche.

    • Diese Antwort wurde geändert vor 1 Jahr, 8 Monaten von michaelbrilz89.
Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 52)
  • Das Thema „wordpress sitzung läuft immer wieder ab“ ist für neue Antworten geschlossen.