Support » Allgemeine Fragen » Zuweisen einer Startseite im Customizer nicht möglich

  • Gelöst mindkicks

    (@mindkicks)


    Hallo Forum,

    ich hoffe, hier ist jemand, der mir helfen kann…

    Die Seite einer Kundin hat aktuell irgendwie einen Fehler, den ich aber bisher nicht filtern konnte.

    Ich habe eine neue Seite angelegt und möchte diese im Customizer als neue Startseite setzen. Leider aber passiert da nichts. Der Customizer lädt auch die ganze Zeit
    Ich kann gar keine Seite als neue setzen. Auch kann ich die neu erstellte Seite (mit Elementor) nicht mehr bearbeiten.
    Alle anderen Seiten gehen problemlos.

    Es gibt wohl irgendein Problem nur mit der Startseite. Die jetzt angezeigte ist eigentlich noch die alte. Die neu erstellte wird gar nicht angezeigt. Die sieht nämlich anders aus.

    Bisherige Versuche – ohne Erfolge: (nicht in der Reihenfolge)
    – Elementor deaktiviert
    – Plugins nach und nach deaktiviert
    – Seite komplett auf einen anderen (fremden) Server kopiert
    – Datenbanken bereinigt
    – htaccess Datei bereinigt / neu erstellt
    – WordPress aktualisiert

    Um zu verdeutlichen, was ich meine, hier eine kurze Aufzeichnung direkt in der Bearbeitung im Customizer:
    Aufzeichnung ansehen

    Ich bin etwas ratlos und jegliche ergoogleten Ideen etc. haben bisher nicht geholfen. :-/

    Der Provider der Kundin ist ionos, aber die sind in der Hilfe auch eher… naja.
    Die sagen auch, es liegen mehr als 50.000 Dateien auf dem Server und somit wäre der Platz voll, können aber nicht sagen, wo diese Dateien liegen.
    Auch toll…

    Ich bin kein Programmierer oder so, nur Grafikdesigner. Daher habe ich von technischen Codesachen oder so, nicht ganz so viel Ahnung. 😉
    Hoffe hier ist jemand, der sich damit besser auskennt.

    Ich hoffe, wenn Fragen sind, dass ich bestmöglich beantworten kann.

    Besten Dank!

    • Dieses Thema wurde geändert vor 2 Jahren, 10 Monaten von Bego Mario Garde. Grund: Link korrigiert

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

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 41)
  • Die sagen auch, es liegen mehr als 50.000 Dateien auf dem Server und somit wäre der Platz voll, können aber nicht sagen, wo diese Dateien liegen.
    Auch toll…

    Das ist auch nicht deren Aufgabe Dateien zu suchen, das musst du machen. Entweder per FTP oder per Admin-Panel des Webspaces.

    Thread-Starter mindkicks

    (@mindkicks)

    Habe ich ja getan und da liegen auch Dateien, aber bei weitem nicht so viele.
    Die Website ist ja nicht wirklich groß.

    Hallo @mindkicks

    Der Customizer lädt auch die ganze Zeit …

    Funktioniert denn überhaupt irgendwas anderes im Customizer?

    mehr als 50.000 Dateien auf dem Server

    Wenn die Seite „nicht wirklich groß“ ist, dann könnten diese irgendwelche (Log?) Dateien sein, die von einem Plugin angelegt wurden. KA. jetzt welches, glaube, SEO Plugins sind da schon mal aufgefallen.

    Nein, die müssen nicht sagen, wo die sind, es wäre aber nett von einem Hoster. Und ja, wie @bscu meinte, sollte die Speicherbelegung am einfachsten im Admin-Panel zu finden sein. Per FTP gehts auch.
    Jedoch sind auch 50 k Dateien eine Hausnummer, eine Zahl die manchen nicht im geringsten juckt. Finde bitte heraus: Wie viel Platz hat die Kundin und wie viel ist belegt?

    habe ich von technischen Codesachen oder so, nicht ganz so viel Ahnung

    Dafür hast du aber schon einige Dinge gecheckt und Kontakt mit dem Hoster aufgenommen. Gut. Also hast mit „nicht ganz so viel Ahnung“ schon vieles abgehakt, was andere erst nach wochenlangem hin-und her diskutieren machen …

    Wobei:

    Seite komplett auf einen anderen (fremden) Server kopiert

    … da ging der Customizer auch nicht? Oder wie?

    Wenn die Seite „nicht wirklich groß“ ist, dann könnten diese irgendwelche (Log?) Dateien sein, die von einem Plugin angelegt wurden.

    … oder Backups.

    Mit SSH-Zugriff lässt sich die Anzahl der Dateien pro Verzeichnis mit ls | wc -l auslesen. Vom Support des Webhoster hätte ich mir da mehr Unterstützung erhofft.

    Ja genau! Backups, danke, die hatte ich vergessen (weil ich die meist auslagere)

    SSH: Hat halt nicht jeder, daher wäre eben das einfachste die Prüfung der Speicherbelegung per Admin. Was dann eher die (mit dem Gesamtplatz vergleichbare) Größe statt Anzahl ergeben könnte.

    Vom Support des Webhoster hätte ich mir da mehr Unterstützung erhofft

    Aber echt!

    @pixolin

    Mit SSH-Zugriff lässt sich die Anzahl der Dateien pro Verzeichnis mit ls | wc -l auslesen.

    Warum so umständlich? Mit
    find . -type f | wc -l
    geht es auch rekursiv 😉

    Thread-Starter mindkicks

    (@mindkicks)

    Funktioniert denn überhaupt irgendwas anderes im Customizer?

    Nein, er lädt die ganze Zeit nur, aber ändern lässt sich nichts.

    Wenn die Seite „nicht wirklich groß“ ist, dann könnten diese irgendwelche (Log?) Dateien sein, die von einem Plugin angelegt wurden. KA. jetzt welches, glaube, SEO Plugins sind da schon mal aufgefallen.

    Wie gesagt, ich habe schon alle Plugins nach und nach deaktiviert, aber nutzte nichts.

    Nein, die müssen nicht sagen, wo die sind, es wäre aber nett von einem Hoster. Und ja, wie @bscu meinte, sollte die Speicherbelegung am einfachsten im Admin-Panel zu finden sein. Per FTP gehts auch.
    Jedoch sind auch 50 k Dateien eine Hausnummer, eine Zahl die manchen nicht im geringsten juckt. Finde bitte heraus: Wie viel Platz hat die Kundin und wie viel ist belegt?

    Angeblich sind die 50 k Standard und da würde jeder Provider an seine Grenzen kommen. So die Aussage des Mitarbeiters.
    In dem Admin-Panel kann man dahingehend nicht wirklich etwas sehen, oder ich finde es nicht.

    Seite komplett auf einen anderen (fremden) Server kopiert
    … da ging der Customizer auch nicht? Oder wie?

    Nein, auch nicht.

    Ja, ich mache Backups, aber aktuell sind es nur 3 Stück.
    Die Kundin hat auf dem Server selbst 500 GB, davon sind nur knapp 10 GB belegt. Der Porvider meint aber, das hätte damit nichts zu tun. Es gäbe eine Standardanzahl an Dateien und die wäre mit 50.000 voll.

    Mit SSH-Zugriff lässt sich die Anzahl der Dateien pro Verzeichnis mit ls | wc -l auslesen.

    Warum so umständlich? Mit
    find . -type f | wc -l

    geht es auch rekursiv 😉`

    Das sagt mir leider gar nichts. :-/

    Welche Lösung schlagt ihr vor?
    WordPress komplett neu aufsetzen und Website neu nachbauen?

    Ich bin echt etwas ratlos und die Kundin auch.

    • Diese Antwort wurde geändert vor 2 Jahren, 10 Monaten von mindkicks.

    Hallo,
    erstelle eine Sicherung z. B. mit UpdraftPlus. Dann richtest du auf deinem Computer einen lokalen Webserver ein, z.B. mit Laragon, Bitnami oder Local by Flywheel oder (relativ neu): Kinsta WordPress Development Suite. Interessant ist auch https://tastewp.com, Anleitung siehe z. B. hier: https://einstieg-in-wp.de/tastewp/.
    Danach installierst du WordPress und stellst die Sicherung von UpdarftPlus wieder her. Wie das im Beispiel von Laragon funktioniert, habe ich hier beschrieben.
    Grundsätzlich kannst du aber z. B. eine WordPress-Instanz mit dem Plugin Duplicator sichern und dann auf dem lokalen Rechner einrichten. Wie das geht, kannst du dir z. B. in der folgenden sehr guten Anleitung ansehen.
    Dann kannst du in aller Ruhe testen, wo das Problem liegt.
    Viele Grüße
    Hans-Gerd

    50.000 Dateien sind schon eine ganze Menge. Ich vermute, dass die Beschränkung auf 50.000 Dateien damit zu tun hat, dass das Einlesen vieler einzelner Dateien beim Backup ein Performance-Problem verursacht. Interessant wäre, wieso auf dem Webserver soviel Dateien liegen.

    Wenn du dich per SSH (über das Terminal) auf dem Webserver anmelden kannst, lässt sich mit Linux-Befehlen ermitteln, wo die ganzen Dateien liegen. @bscu hat meinen Vorschlag mit find . -type f | wc -l etwas verfeinert, was aber immer noch voraussetzt, dass du mit dem Zugriff über das Terminal zurecht kommst.

    Damit wir zumindest etwas mehr über die Website erfahren, wäre ein Bericht hilfreich: Geh bitte auf Werkzeuge > Website-Zustand > Bericht, klick auf den Button und füge den Bericht mit Strg-V unverändert in deine Antwort ein.
    Vielleicht lässt sich damit noch etwas zur Installation sagen.

    Ich hab schon öfters gesehen, dass Kunden auf ihrem Webserver nicht mehr genutzte Dateien älterer Websites „rumfliegen“ haben. Da liegt dann noch eine alte Typo3- oder Joomla!-Installation mit allen Bilddateien in irgendeinem Unterverzeichnis, die eigentlich längst hätte gelöscht werden können. Schau mal, ob du zumindest per FTP Verzeichnisse findest, die dort nicht hingehören.

    Letztendlich besteht auch die Möglichkeit, dass die Website gehackt wurde und nun eifrig für Dateisharing genutzt wird. Das können wir aber nur mit einer Fehlermeldung „Customizer tut’s nicht“ kaum beurteilen.

    Der Webhoster Kinsta hat einige lesenswerte Beiträge zu WordPress geschrieben und bietet auch zum Thema Festplattennutzung einen ausführlichen Beitrag. Vielleicht kannst du mit dem einen oder anderen Tipp etwas anfangen: 7 einfache Möglichkeiten, die Festplattennutzung in WordPress zu überprüfen (große Dateien und Daten finden)

    WordPress komplett neu aufsetzen und Website neu nachbauen?

    … ist eine Holzhammermethode. Vorher würde ich prüfen, ob ein aktuelles Backup vorhanden ist, dass sich wiederherstellen lässt (z.B. auf einem lokalen Webserver prüfen). Dann (und wirklich erst nach einer Prüfung) alle Dateien im Web-Stammverzeichnis löschen und das Backup wiederherstellen.
    Klar kannst du immer WordPress neu aufsetzen und eine ganz neue, tolle Website machen, aber ob die Kundin dann bereit ist, den Aufwand auch finanziell zu tragen?

    @mindkicks

    ich habe schon alle Plugins nach und nach deaktiviert, aber nutzte nichts

    . Klar, denn das Deaktivieren (manchmal sogar das Deinstallieren, Löschen) eines Plugins entfernt nicht unbedingt dessen Hinterlassenschaften.

    Ich würde echt mal jeden Ordner abklappern (zuerst Plugins, Uploads, … ?) eine solche Menge sollte doch auffallen.
    Evtl. hilft https://www.ionos.de/hilfe/hosting/webspace-mit-dem-webspaceexplorer-verwalten/was-ist-der-webspaceexplorer/ oder https://www.ionos.de/hilfe/hosting/speicherplatz-verwalten/verfuegbarer-genutzter-speicherplatz-in-11-ionos-hosting-linux-vertraegen-anzeigen/

    Das Testen auf einer weiteren Instanz ist natürlich auch eine Idee und weit sicherer. Da kannst gefahrlos etwaige überladene Ordner leeren, schauen, ob es dann funzt.
    Und mit Duplicator gelingt das erstellen einer lauffähigen 1:1 Kopie immer.

    Ob es wohl eine gute Idee ist, beim Überschreiten der erlaubten Dateianzahl Duplicator installieren zu wollen? 😀

    @pixolin das stimmt allerdings auch wieder 😊

    Thread-Starter mindkicks

    (@mindkicks)

    erstelle eine Sicherung z. B. mit UpdraftPlus. Dann richtest du auf deinem Computer einen lokalen Webserver ein, z.B. mit Laragon, Bitnami oder Local by Flywheel oder (relativ neu): Kinsta WordPress Development Suite. Interessant ist auch https://tastewp.com, Anleitung siehe z. B. hier: https://einstieg-in-wp.de/tastewp/.
    Danach installierst du WordPress und stellst die Sicherung von UpdarftPlus wieder her. Wie das im Beispiel von Laragon funktioniert, habe ich hier beschrieben.
    Grundsätzlich kannst du aber z. B. eine WordPress-Instanz mit dem Plugin Duplicator sichern und dann auf dem lokalen Rechner einrichten. Wie das geht, kannst du dir z. B. in der folgenden sehr guten Anleitung ansehen.
    Dann kannst du in aller Ruhe testen, wo das Problem liegt.
    Viele Grüße
    Hans-Gerd

    Vielen Dank für die Tipps!


    was aber immer noch voraussetzt, dass du mit dem Zugriff über das Terminal zurecht kommst.

    So etwas habe ich ehrlich gesagt noch nicht gemacht.
    Alles was nicht genutzt/gebraucht wird, ist bereits vom Server entfernt worden.
    Ich habe bereits mit dem Support vom Provider alle nicht benötigten Daten löschen lassen.

    Hier der Bericht von WordPress:

    
    ### wp-core ###
    
    version: 5.7.2
    site_language: de_DE
    user_language: de_DE
    timezone: Europe/Berlin
    permalink: /%postname%/
    https_status: true
    multisite: false
    user_registration: 0
    blog_public: 1
    default_comment_status: closed
    environment_type: production
    user_count: 4
    dotorg_communication: true
    
    ### wp-paths-sizes ###
    
    wordpress_path: /homepages/20/d796362098/htdocs/clickandbuilds/bewegLICH354676
    wordpress_size: 1,24 GB (1331987742 bytes)
    uploads_path: /homepages/20/d796362098/htdocs/clickandbuilds/bewegLICH354676/wp-content/uploads
    uploads_size: 112,72 MB (118199254 bytes)
    themes_path: /homepages/20/d796362098/htdocs/clickandbuilds/bewegLICH354676/wp-content/themes
    themes_size: 8,57 MB (8987198 bytes)
    plugins_path: /homepages/20/d796362098/htdocs/clickandbuilds/bewegLICH354676/wp-content/plugins
    plugins_size: 136,72 MB (143363028 bytes)
    database_size: 23,03 MB (24150016 bytes)
    total_size: 1,51 GB (1626687238 bytes)
    
    ### wp-active-theme ###
    
    name: Rife Free (rife-free)
    version: 2.4.12
    author: Apollo13Themes
    author_website: https://apollo13themes.com/
    parent_theme: none
    theme_features: core-block-patterns, admin-bar, post-thumbnails, automatic-feed-links, title-tag, post-formats, html5, woocommerce, wc-product-gallery-zoom, wc-product-gallery-lightbox, wc-product-gallery-slider, customize-selective-refresh-widgets, custom-logo, header-footer-elementor, menus, widgets, editor-style
    theme_path: /homepages/20/d796362098/htdocs/clickandbuilds/bewegLICH354676/wp-content/themes/rife-free
    auto_update: Deaktiviert
    
    ### wp-themes-inactive (1) ###
    
    Twenty Twenty-One: version: 1.3, author: WordPress-Team, Automatische Aktualisierungen deaktiviert
    
    ### wp-mu-plugins (1) ###
    
    1&1 Product Subdomain: version: 1.1.0, author: 1&1
    
    ### wp-plugins-active (21) ###
    
    Advanced Database Cleaner: version: 3.0.3, author: Younes JFR., Automatische Aktualisierungen deaktiviert
    Analytify - Google Analytics Dashboard: version: 4.0.3, author: Analytify, Automatische Aktualisierungen deaktiviert
    Apollo13 Framework Extensions: version: 1.8.8, author: Apollo13Themes, Automatische Aktualisierungen deaktiviert
    Borlabs Cookie - Cookie Opt-in: version: 2.2.27, author: Benjamin A. Bornschein, Borlabs, Automatische Aktualisierungen deaktiviert
    Caldera Forms: version: 1.9.4, author: Caldera Forms, Automatische Aktualisierungen deaktiviert
    Credit Tracker: version: 1.1.17, author: Labs64, Automatische Aktualisierungen deaktiviert
    Elementor: version: 3.2.4, author: Elementor.com (latest version: 3.2.5), Automatische Aktualisierungen deaktiviert
    eRecht24 Rechtstexte: version: 1.1.0, author: Weslink, Automatische Aktualisierungen deaktiviert
    Essential Addons for Elementor: version: 4.7.0, author: WPDeveloper (latest version: 4.7.2), Automatische Aktualisierungen deaktiviert
    HT Mega - Absolute Addons for Elementor Page Builder: version: 1.5.9, author: HasThemes, Automatische Aktualisierungen deaktiviert
    MaxButtons: version: 8.6, author: Max Foundry, Automatische Aktualisierungen deaktiviert
    Modula: version: 2.5.1, author: WPChill, Automatische Aktualisierungen deaktiviert
    PhastPress: version: 1.124, author: Albert Peschar, Automatische Aktualisierungen deaktiviert
    Premium Addons for Elementor: version: 4.3.6, author: Leap13 (latest version: 4.3.8), Automatische Aktualisierungen deaktiviert
    Rank Math SEO: version: 1.0.64, author: Rank Math (latest version: 1.0.66.1), Automatische Aktualisierungen deaktiviert
    Rife Elementor Extensions & Templates: version: 1.1.8, author: Apollo13Themes, Automatische Aktualisierungen deaktiviert
    Wordfence Security: version: 7.5.3, author: Wordfence (latest version: 7.5.4), Automatische Aktualisierungen deaktiviert
    WP-Optimize - Clean, Compress, Cache: version: 3.1.11, author: David Anderson, Ruhani Rabin, Team Updraft, Automatische Aktualisierungen deaktiviert
    WP Fastest Cache: version: 0.9.1.9, author: Emre Vona, Automatische Aktualisierungen deaktiviert
    WPForms Lite: version: 1.6.7, author: WPForms (latest version: 1.6.7.1), Automatische Aktualisierungen deaktiviert
    WPvivid Backup Plugin: version: 0.9.53, author: WPvivid Team, Automatische Aktualisierungen deaktiviert
    
    ### wp-plugins-inactive (1) ###
    
    Elementor Pro: version: 3.2.2, author: Elementor.com, Automatische Aktualisierungen deaktiviert
    
    ### wp-media ###
    
    image_editor: A13IR_Image_Editor_GD
    imagick_module_version: Nicht verfügbar
    imagemagick_version: Nicht verfügbar
    file_uploads: File uploads is turned off
    post_max_size: 67108864
    upload_max_filesize: 67108864
    max_effective_size: 64 MB
    max_file_uploads: 20
    gd_version: 2.2.5
    ghostscript_version: 9.27
    
    ### wp-server ###
    
    server_architecture: Linux 4.4.262-icpu-066 x86_64
    httpd_software: Apache
    php_version: 7.4.20 64bit
    php_sapi: cgi-fcgi
    max_input_variables: 1000
    time_limit: 30
    memory_limit: 268435456
    max_input_time: -1
    upload_max_filesize: 67108864
    php_post_max_size: 67108864
    curl_version: 7.64.0 OpenSSL/1.1.1d
    suhosin: false
    imagick_availability: false
    pretty_permalinks: true
    htaccess_extra_rules: true
    
    ### wp-database ###
    
    extension: mysqli
    server_version: 5.7.33-log
    client_version: mysqlnd 7.4.20
    
    ### wp-constants ###
    
    WP_HOME: undefined
    WP_SITEURL: undefined
    WP_CONTENT_DIR: /homepages/20/d796362098/htdocs/clickandbuilds/bewegLICH354676/wp-content
    WP_PLUGIN_DIR: /homepages/20/d796362098/htdocs/clickandbuilds/bewegLICH354676/wp-content/plugins
    WP_MEMORY_LIMIT: 40M
    WP_MAX_MEMORY_LIMIT: 256M
    WP_DEBUG: false
    WP_DEBUG_DISPLAY: true
    WP_DEBUG_LOG: false
    SCRIPT_DEBUG: false
    WP_CACHE: false
    CONCATENATE_SCRIPTS: undefined
    COMPRESS_SCRIPTS: undefined
    COMPRESS_CSS: undefined
    WP_LOCAL_DEV: undefined
    DB_CHARSET: utf8
    DB_COLLATE: undefined
    
    ### wp-filesystem ###
    
    wordpress: writable
    wp-content: writable
    uploads: writable
    plugins: writable
    themes: writable
    mu-plugins: writable
    
    ### wpforms ###
    
    version: 1.6.7
    lite: Apr 2, 2019 @ 8:52pm
    upload_dir: Beschreibbar
    db_tables: WicLYnJIwpforms_tasks_meta
    total_forms: 2
    total_submissions: 209
    
    ### modula ###
    
    core_version: Core version 2.5.1
    requested_php: PHP minimum version met
    requested_wp: WordPress minimum version met. Current version: 5.7.2
    galleries_number: Total number of galleries: 1
    track_data: Track data disabled
    enqueue_files: Enqueue files disabled
    grid_type: No grid type selected
    lightboxes: No lightbox selected
    modula_lazyload: No general lazyload
    modula_edit_gallery_link: Edit gallery link enabled
    
    

    Ich hab gerade mal nachgeschaut: in einer Testinstallation mit 132 Plugins und 61 Themes („Kids, don’t do that at home!“) komme ich auf ein Dateivolumen von 1.1 Gigabyte und rund 35.000 Dateien. Das ist alles fernab der üblichen Praxis, bei der du ein, zwei Themes und vielleicht ein Dutzend Plugins installiert hast. Das hohe Datenvolumen von 1,24 Gigabyte lässt sich dann nur mit einer Masse an Backup- oder Cache-Daten erklären.

    Erster Versuch wäre, den Cache des Plugins komplett zu löschen. Eine Anleitung findest du hier: https://www.ionos.de/digitalguide/hosting/blogs/wordpress-cache-leeren/#c262183

    Schau dann nochmal mit einem FTP-Programm in das Verzeichnis wp-content, welche Unterverzeichnisse es gibt.

    Thread-Starter mindkicks

    (@mindkicks)

    Woher hast du diese Werte?
    Testinstallation?

    Den Cache habe ich schon gewiss 100x gelöscht. 🙁

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 41)
  • Das Thema „Zuweisen einer Startseite im Customizer nicht möglich“ ist für neue Antworten geschlossen.