Verfasste Forenbeiträge

Ansicht von 15 Antworten – 1 bis 15 (von insgesamt 59)
  • Thread-Starter onlaie

    (@onlaie)

    Super Idee. Danke!
    Das könnte auch mit helfen, diesem ärgerlichen Ausloggen Einhalt zu gebieten.

    Thread-Starter onlaie

    (@onlaie)

    Die Information hätte mir die Rechercher erspart.

    Sorry!!

    Ein IP-Wechsel = User-Logout könnte durch Sicherheitsplugins verursacht werden.

    Nein, auf keiner Site ist sowas aktiv. Ja, auf einer ist Limit Login Attempts Reloaded und Two Factor. Aber keins der großen Dinger wie Wordfence. Daher kann man sagen, dass sich in den wenigen Optionen der beiden erstgenannten Plugins nichts verbirgt, was so ein Verhalten erklärt.
    Und wie gesagt: Das autom. ausloggen passiert seit immer auf allen Sites, egal wie viele und welche Plugins da laufen.

    Cookie-Einstellungen in den Browsern

    Das kann schon sein!
    Denn ich kann nicht bei allen checken, was die so einstellen. Und ausgerechnet die Person, welche fast täglich über einen Rausschmiss jammert, jammert auch bei anderen Internet-Aktivitäten über ähnliche Phänomene.
    Doch da habe ich nachgesehen und bis auf einen komplett überfrachteten Speicher sah ich in deren Firefox keine Option, welche zu so einem Verhalten führt.

    Thread-Starter onlaie

    (@onlaie)

    Das Problem mit dem ausloggen tritt natürlich in allen Webs auf.
    Auch dort, wo keins der genannten Plugins läuft.

    Serverseitiges Caching ist aktiv, ja. Sollte aber lt. den Hostern keinen Einfluss auf die Logins haben.

    Mein Hauptverdächtiger ist eher der jeweilige Zugangsprovider der Autoren. Keiner hat eine fixe IP und deren Wechsel könnte den Status als Benutzer beeinflussen. WP denkt vllt.: „Andere IP = anderer Nutzer“.
    Das könnte erklären, warum ein Script zur künstlichen Lebensverlängerung des „wordpress_logged_in_123abc456def“ Cookies nichts bringt.
    Mir wird zwar eine um 1 Jahr + 14 Tage in der Zukunft liegende Lebensdauer des Cookies angezeigt, doch wenn die IP wechselt, ist das auch egal.

    Thread-Starter onlaie

    (@onlaie)

    Wie sollte den das Cookie heißen, welches dafür zuständig ist? Hier zeigen sich 12 Cookies und ich kann nur einige davon ausschließen.
    Ist es evtl.:
    wordpress_logged_in_a3he521b30ce8567f5157a63e775346a

    Bericht (Obacht, es ist eine Testsite mit vielen Plugin-Experimenten usw.):

    
    ### wp-core ###
    
    version: 7.0
    site_language: de_DE
    user_language: de_DE
    timezone: Europe/Vienna
    permalink: /%postname%/
    https_status: true
    multisite: false
    user_registration: 0
    blog_public: 1
    default_comment_status: undefined
    environment_type: production
    user_count: 7
    dotorg_communication: true
    
    ### wp-paths-sizes ###
    
    wordpress_path: /var/www/clients/client21/web238/web
    wordpress_size: 250,31 MB (262468035 bytes)
    uploads_path: /var/www/clients/client21/web238/web/wp-content/uploads
    uploads_size: 5,98 MB (6274279 bytes)
    themes_path: /var/www/clients/client21/web238/web/wp-content/themes
    themes_size: 11,16 MB (11701895 bytes)
    plugins_path: /var/www/clients/client21/web238/web/wp-content/plugins
    plugins_size: 192,27 MB (201609181 bytes)
    fonts_path: /var/www/clients/client21/web238/web/wp-content/uploads/fonts
    fonts_size: directory not found
    database_size: 100,17 MB (105038976 bytes)
    total_size: 559,89 MB (587092366 bytes)
    
    ### wp-active-theme ###
    
    name: MH Magazine Child Theme (mh-magazine-child)
    version: 1.0.0
    author: MH Themes
    author_website: https://www.mhthemes.com/
    parent_theme: MH Magazine (Premium) (mh-magazine)
    theme_features: core-block-patterns, post-thumbnails, widgets-block-editor, menus, title-tag, automatic-feed-links, html5, post-formats, custom-background, custom-header, custom-logo, customize-selective-refresh-widgets, widgets
    theme_path: /var/www/clients/client21/web238/web/wp-content/themes/mh-magazine-child
    
    ### wp-parent-theme ###
    
    name: MH Magazine (Premium) (mh-magazine)
    version: 5.0.6
    author: MH Themes
    author_website: https://mhthemes.com/
    theme_path: /var/www/clients/client21/web238/web/wp-content/themes/mh-magazine
    
    ### wp-themes-inactive (1) ###
    
    Twenty Twenty-Four: version: 1.5, author: Das WordPress-Team
    
    ### wp-mu-plugins (1) ###
    
    Health Check Troubleshooting Mode: author: (undefined), version: 1.9.2
    
    ### wp-plugins-active (27) ###
    
    Advanced Custom Fields: version: 6.8.1, author: WP Engine
    Advanced Database Cleaner: version: 4.1.1, author: SigmaPlugin
    BackWPup: version: 5.6.9, author: BackWPup – WordPress Backup & Restore Plugin
    CODO's Menü Einträge: version: 1.5, author: Codo der Dritte (ZIB-BAUSTELLE)
    Content Views: version: 4.4, author: Content Views
    Content Views Pro: version: 7.3, author: Content Views
    Disable Emojis (GDPR friendly): version: 1.9.2, author: Ryan Hellyer
    Disable Gutenberg: version: 3.3.1, author: Jeff Starr
    Instant Images: version: 7.1.1, author: Darren Cooney
    Kadence Mail: version: 3.0.0, author: Kadence
    Limit Login Attempts Reloaded: version: 3.2.4, author: Limit Login Attempts Reloaded
    My Sticky Bar: version: 2.9.0, author: Premio
    Paid Memberships Pro: version: 3.7.3, author: Paid Memberships Pro
    Paid Memberships Pro - Anpassungen: version: 1.5, author: Paid Memberships Pro + Codo der Dritte (ZIB-BAU)
    Paid Memberships Pro - PayPal Gateway: version: 1.1.1, author: Paid Memberships Pro
    Paid Memberships Pro - Update Manager: version: 1.0.1, author: Paid Memberships Pro
    Password Protected: version: 2.8.0, author: Password Protected
    Post Snippets (free): version: 4.1.1, author: Postsnippets
    Rank Math SEO: version: 1.0.270, author: Rank Math SEO
    Real Cookie Banner: version: 5.2.23, author: devowl.io
    Regenerate Thumbnails: version: 3.1.6, author: Alex Mills (Viper007Bond)
    Shortcodes Ultimate - Content Elements: version: 7.5.3, author: Vova Anokhin
    Two Factor: version: 0.16.0, author: WordPress.org Contributors
    User Role Editor: version: 4.65, author: Vladimir Garagulya
    Widget Options: version: 4.2.4, author: Widget Options Team
    WP Crontrol: version: 1.21.0, author: John Blackbourn
    WPForms Lite: version: 1.10.0.5, author: WPForms
    
    ### wp-plugins-inactive (21) ###
    
    Better Search Replace: version: 1.4.10, author: WP Engine
    Bulk remove posts from category: version: 3.4, author: MasterNs
    CODO's Bildasuchafinda: version: 1.2, author: Codo der Dritte (ZIB-BAUSTELLE)
    CODO's BST Post Counter: version: 1.1.2, author: Codo der Dritte (ZIB-BAU)
    CODO's Simple Login Limit: version: 1.0, author: Codo der Dritte (ZIB-BAUSTELLE)
    Complianz - Terms and Conditions: version: 1.3.0, author: Complianz
    Disable & Remove Google Fonts: version: 1.8.2, author: Fonts Plugin
    Donations via PayPal: version: 1.9.11, author: Tips and Tricks HQ, Johan Steen
    FooBox Image Lightbox: version: 2.7.43, author: FooPlugins
    FooGallery: version: 3.1.26, author: FooPlugins
    Health Check & Troubleshooting: version: 1.7.1, author: The WordPress.org community
    Iks Menu: version: 1.12.7, author: IksStudio
    Loco Translate: version: 2.8.4, author: Tim Whitlock
    LuckyWP Table of Contents: version: 2.1.14, author: LuckyWP
    PDF & Print by BestWebSoft: version: 2.4.7, author: BestWebSoft
    Pixabay Images: version: 3.4, author: Simon Steinberger
    Show modified Date in admin lists: version: 1.5, author: Apasionados.es
    Statify: version: 1.8.5, author: pluginkollektiv
    Steady for WordPress: version: 1.3.3, author: Steady
    WP Dashboard Messages: version: 1.1.7, author: Jörn Lund
    WP RSS Aggregator: version: 5.0.12, author: RebelCode
    
    ### wp-media ###
    
    image_editor: WP_Image_Editor_GD
    imagick_module_version: Nicht verfügbar
    imagemagick_version: Nicht verfügbar
    imagick_version: Nicht verfügbar
    file_uploads: 1
    post_max_size: 128M
    upload_max_filesize: 128M
    max_effective_size: 128 MB
    max_file_uploads: 20
    image_format_transforms: image/heic → image/jpeg, image/heif → image/jpeg, image/heic-sequence → image/jpeg, image/heif-sequence → image/jpeg
    gd_version: 2.3.3
    gd_formats: GIF, JPEG, PNG, WebP, BMP, XPM
    ghostscript_version: unknown
    
    ### wp-server ###
    
    server_architecture: Linux 5.4.0-216-generic x86_64
    httpd_software: nginx/1.18.0
    php_version: 8.3.19 64bit
    php_sapi: fpm-fcgi
    max_input_variables: 1000
    time_limit: 120
    memory_limit: 256M
    max_input_time: 60
    upload_max_filesize: 128M
    php_post_max_size: 128M
    curl_version: 7.68.0 OpenSSL/1.1.1f
    suhosin: false
    imagick_availability: false
    opcode_cache: true
    opcode_cache_memory_usage: 130491704 of 130491720
    opcode_cache_interned_strings_usage: 100% of 8388608 (8 free)
    opcode_cache_hit_rate: 54.1
    opcode_cache_full: true
    pretty_permalinks: true
    htaccess_extra_rules: false
    static_robotstxt_file: false
    current: 2026-05-26T15:17:20+00:00
    utc-time: Tuesday, 26-May-26 15:17:20 UTC
    server-time: 2026-05-26T17:17:18+02:00
    
    ### wp-database ###
    
    extension: mysqli
    server_version: 10.3.39-MariaDB-0ubuntu0.20.04.2
    client_version: mysqlnd 8.3.19
    max_allowed_packet: 16777216
    max_connections: 151
    
    ### wp-constants ###
    
    WP_HOME: undefined
    WP_SITEURL: undefined
    WP_CONTENT_DIR: /var/www/clients/client21/web238/web/wp-content
    WP_PLUGIN_DIR: /var/www/clients/client21/web238/web/wp-content/plugins
    WP_MEMORY_LIMIT: 256M
    WP_MAX_MEMORY_LIMIT: 256M
    WP_DEBUG: true
    WP_DEBUG_DISPLAY: false
    WP_DEBUG_LOG: true
    SCRIPT_DEBUG: false
    WP_CACHE: false
    CONCATENATE_SCRIPTS: undefined
    COMPRESS_SCRIPTS: undefined
    COMPRESS_CSS: undefined
    WP_ENVIRONMENT_TYPE: undefined
    WP_DEVELOPMENT_MODE: undefined
    DB_CHARSET: utf8
    DB_COLLATE: undefined
    EMPTY_TRASH_DAYS: 30
    
    ### wp-filesystem ###
    
    wordpress: writable
    wp-content: writable
    uploads: writable
    plugins: writable
    themes: writable
    fonts: does not exist
    mu-plugins: writable
    
    ### acf ###
    
    version: 6.8.1
    plugin_type: Free
    update_source: de.wordpress.org
    ui_field_groups: 3
    php_field_groups: 0
    json_field_groups: 0
    rest_field_groups: 0
    post_types_enabled: true
    ui_post_types: 0
    json_post_types: 0
    ui_taxonomies: 0
    json_taxonomies: 0
    rest_api_format: light
    admin_ui_enabled: true
    field_type-modal_enabled: true
    field_settings_tabs_enabled: false
    shortcode_enabled: true
    registered_acf_forms: 0
    json_save_paths: 1
    json_load_paths: 1
    ai_enabled: false
    schema_support: false
    schema_ready_objects: 
    	blocks: 0
    	post_types: 0
    
    ### solid-mail ###
    
    active_connections_number: 1
    active_connections_names: other
    brevo_connections: undefined
    mailgun_connections: undefined
    sendgrid_connections: undefined
    ses_connections: undefined
    smtp_connections: 1
    sent_emails: 45
    
    
    Thread-Starter onlaie

    (@onlaie)

    Danke.
    Also Google KI sagt mir dazu zwei Sachen:

    Standardmäßig speichert WordPress die Sitzung für 14 Tage. Wenn Sie bei der Anmeldung auf dem Login-Bildschirm das Häkchen bei „Angemeldet bleiben“ setzen, wird dieser Zeitraum voll ausgenutzt und die Sitzung bleibt aktiv, selbst wenn Sie den Browser schließen.

    Naja, zum einen schmeißt WP manche Nutzer alle paar Tage (sogar während es Verfassens von Beiträgen!) raus und zum anderen hilft „Angemeldet bleiben“ in dem Bezug nicht immer.

    Dafür zeigt man mir gleich ein Script:

    add_filter( 'auth_cookie_expiration', 'keep_me_logged_in_forever', 20, 3 );
    function keep_me_logged_in_forever( $expirein, $user_id, $remember ) {
        if ( $remember ) {
            $expirein = 31536000; // 1 Jahr in Sekunden
        }
        return $expirein;
    }

    kann das korrekt sein?
    Denn testweise tut sich das nichts …

    Thread-Starter onlaie

    (@onlaie)

    Post Snippets … Bei jedem Code muss man auswählen um was es sich handelt.

    Ja, stimmt. Ich nutze es schon sehr lange, auf mehreren Sites und bisher klappte damit alles. Natürlich musste man schon immer die richtige Option anhaken.
    Doch seit WP 7.0 nutzt das nichts mehr. (außer man hat eben die do_shortcode Filter f. Widgets aktiv)

    da Shortcodes kein echo zurückgeben sollten, sondern ihre Ausgabe per return zurückgeben.

    So verstand ich das auch …

    Bei mir geht aber (ab WP 7.0) gar nichts mehr. Also egal wie ich die Post Snippets Codes ändere – entweder kommt nichts oder wieder nur der [code].
    In Webs mit WP 6.x funzt das einwandfrei. Auch mit return - Wenn das (wie eingangs gezeigt) mit dem Funktionscode umschlossen ist.

    OT: Aber Post Snippets verwaltet hier nur eher untergeordnete Sachen.
    Alles, was wichtig ist, wo sich viele dynamisch generierte Daten zusammenfinden, ausgegeben werden sollen, dort sind es eigene Funktionen in der functions.php.
    (Das kleine Beispiel war stets auch nur in der functions.php. Und lief bisher perfekt.)

    In Post Snippets selbst sind nur wenige echte Shortcodes, PHP Codes.
    Es sind eher Textbausteine, welche die Autoren einfach irgendwo reinklicken können. (Post Snippets stellt ja einen Button im Editor zvg., wo man die Snippets wählen kann.)

    Somit ist es wichtiger, dass die eigenen Shortcodes aus der functions.php auch mit WP 7. tun, was sie sollen.
    Und das scheint nur mehr mittels

    add_filter('widget_text', 'do_shortcode');
    add_filter('widget_custom_html', 'do_shortcode', 10);

    zu klappen ...

    Thread-Starter onlaie

    (@onlaie)

    Ja, innerhalb von Content gehts. Also Shortcodes mitten in Seiten, Beiträgen zeigen sich weiterhin.
    Aber irgendwas ist bei den (HTML)-Widgets passiert. Da tut sich nichts, die gaben nichts mehr aus.

    Daraufhin fand ich den Trick für die functions.php:

    add_filter('widget_text', 'do_shortcode');
    add_filter('widget_custom_html', 'do_shortcode', 10);

    und ja, seitdem gehts wieder.
    Mal sehen, ob auch wirklich alle Shortcodes aus allen Quellen zuverlässig erscheinen. Jedenfalls zeigen sich die selbst gebauten Ausgaben plötzlich wieder!

    Denke und hoffe, das war’s.

    Thread-Starter onlaie

    (@onlaie)

    Alle DEBUG Aktionen, inkl. Plugins, Themes deaktivieren usw. brachten hier keine Änderung oder Erkenntnis.
    Ansonsten ich ja mit einer Fehlermeldung oder einem Bericht angekommen wäre.

    Doch das Problem ist eindeutig eine Veränderung bez. Shortcode Handling im WP ab 7.0.
    Googles KI redet davon, dass man jetzt die eigenen Shortcode-Funktionen registrieren sollte …
    Bevor ich das näher nachfrage, wollte ich halt wissen, was ab WP 7.0 geändert wurde.

    Thread-Starter onlaie

    (@onlaie)

    Ok, dachte es reicht, das in den Plugin/Theme Optionen nicht auf automatisch zu haben und ggf. noch entweder in der config oder in der functions zu hinterlegen. (Dzt. habe ich als Filter)
    Aber ja, dann halt das ganze Programm. Mal sehen, obs reicht.

    Danke, ist vorerst erledigt!

    Forum: Plugins
    Als Antwort auf: Loginversuche begrenzen
    Thread-Starter onlaie

    (@onlaie)

    Stimmt.
    Und egal wie man alles aussperrt, versteckt – die von außen ansprechbaren Dateien sind ja noch da.

    AuthBasic hatte man dort vorher, doch damit war ein reibungsloser Betrieb des Membership-Plugins nicht zu machen. Auch harmlose Abonnenten wurden mit dem serverseitigen Backens-Schutz konfrontiert. Ja, wir habens mit Ausnahmen (für das Plugin) versucht, doch das ging nicht wirklich.
    Also kam AuthBasic weg und die evtl. geringere Sicherheit soll nun zT. ein bisschen mit Login Limit (und 2FA/MFA) ausgeglichen werden.
    Dazu wurden aber eh auch noch die REST Endpunkte mit den Benutzern, XMLRPC, u. weitere Kleinigkeiten wegversteckt …
    Den Rest muss die WAF usw. des Hosters machen …

    Forum: Plugins
    Als Antwort auf: Loginversuche begrenzen
    Thread-Starter onlaie

    (@onlaie)

    Eine Quelle … naja, eigentlich stehts eh auf der Site https://de.wordpress.org/plugins/limit-login-attempts-reloaded/ > Funktionen (kostenlose Version), das es DSGVO-konform wäre.

    Der Betreiber, für den ich so einen Login Limiter suchte, las aber zuerst den Supportbereich, wo man sich auch mal über deren „Mikro-Cloud“ Gedanken machte: https://wordpress.org/support/topic/gdpr-conformity-3/
    Das hat den verunsichert, daher sollte ich ein anderes nehmen. Doch naja, das lief nicht so toll.

    Aber: Mir genügte es dann, als ich unter den Einstellungen des Plugins > „Allgemeine Einstellungen“ die Optionen „DSGVO-Konformität“ und „DSGVO-Nachricht“ fand. Das ist schon mal gut so.

    Und: Man muss als Betreiber ja nicht bei der „Mikro-Cloud“ mitmachen. Solange man das Plugin als freie Version aktiv hat und sich nicht an diese Cloud hängt, solange passiert mal gar nichts. Denke ich.

    Letztlich liegt aber schon ein Interesse vor, dass man die Site vor zu aufdringlichen Leuten/Bots schützt und das man diese Daten (eh ohne Personenbezug) irgendwo speichert. So ähnlich verstehe ich auch die abschließenden Einträge in besagten Kommentar …

    Dzt. lassen wir es ohnehin nur auf einer Testsite laufen, bisschen beobachten, was sich so tut und wie das Plugin mit umgeht.
    Interessant ist dabei: Trotz das diese Staging-Testsite serverseitig im Wartungsmodus ist und trotz das noch „Password Protected“ läuft – dennoch schlagen Loginversuche auf die wp-login.php auf …

    Forum: Plugins
    Als Antwort auf: Loginversuche begrenzen
    Thread-Starter onlaie

    (@onlaie)

    So, „Limit Login Attempts Reloaded“ ist doch DSGVO-konform (evtl. sogar mehr als andere) und wichtiger: Es tut, was es soll!

    Forum: Plugins
    Als Antwort auf: Loginversuche begrenzen
    Thread-Starter onlaie

    (@onlaie)

    Funktionieren beide nicht.
    Ersters tut gar nichts sperren;
    Zweiteres zu viel, sperrt den korrekten Adminzugang!

    Ich werde halt noch einige durchtesten …

    Thread-Starter onlaie

    (@onlaie)

    Da kein Mail kam, wieder übersehen, sorry

    Ja sicher muss man jede Fehlerzeile, zumindest die auslösende ansehen.
    Aber wenn dann eine oder mehrere Dateien aus dem Kern genannt werden, steige ich aus.
    Melden, ja. Nur oft kommt einem da eh jemand zuvor, der sich mit dem Meldesystem auskennt (ich nicht).
    Und manchmal sind daher die Fehler nach dem nächsten WP-Update eh wieder weg …
    Deswegen eben die Frage, ob man das filtern kann.

    WordPress Playground

    Interessantes Projekt. Gibts eine DE Beschreibung, Anleitung zu?

    announcing-my-wordpress/

    Kannte ich auch noch nicht …

    Ich mache es oft so: Am guten alten XAMPP immer eine neue WP-Site komplett neu drauf. Oder beim Hoster eine nagelneue Staging Site einer frisch geladenen WP-Instanz (nicht die aus dem Baukasten des Hosters)
    Auch damit kann man dann experimentieren. Etwa das störende Plugin finden.
    Letzteres geht damit jedenfalls besser, als mit dem (selbst fehlerhaften und nie reparieren) „Health Check“ Plugin.

    debug.log:
    Genauso mache ich es. FTP ist offen, Seiten, Scripts, Plugins testen und sobald die debug.log angelegt wird, nachsehen, was los ist. Dann lösche ich die auch mal, wenn zu unübersichtlich, korrigiere und sofern die nochmal kommt, sofort wieder nachsehen.
    Das ist zwar mühsam, aber so weiß ich genau, welche Aktion was wann auslöste.

    Query Monitor:
    Das Plugin hatte ich früher mal. Danke fürs Erinnern.

    PS: Die zuletzt gemeinten WP Core Fehler hat echt schon jemand gemeldet!

    Forum: Allgemeine Fragen
    Als Antwort auf: Passwort zurücksetzen
    Thread-Starter onlaie

    (@onlaie)

    Danke, das liest sich sehr sicher!

    Danke auch bez. der Hinweise im anderen Thema zu ?author=1 und der REST API (s. Eingangspost „… Ebenso habe ich den REST API Endpunkt users blockiert …“)

    Also wenn man die ID der Benutzer unfallfrei ändern kann, dann würde ich das sogar noch vor dem Einsatz von diesem Script, eigentlich MU Plugin, machen.
    Darf man das echt direkt in der DB machen? Wenn ja, reicht es die users Tabelle, Feld ID zu ändern, oder sollte man das noch wo berücksichtigen?
    Eigenantwort: Leider reicht das nicht, danach ist dem geänderten Benutzer nichts mehr möglich …

    • Diese Antwort wurde vor 3 Monaten, 3 Wochen von onlaie geändert.
Ansicht von 15 Antworten – 1 bis 15 (von insgesamt 59)