Support » Allgemeine Fragen » Nach Serverumzug lassen sich Menüs nicht mehr editieren

  • Gelöst shining

    (@mela030)


    Hallo,

    wir sind auf ein Problem gestoßen, für das uns aktuell ein Lösungsansatz fehlt.

    Letzte Woche hat ein Kunde seine bisherigen Domains auf einen neuen (besseren) Server umgezogen.

    Nun ist uns aufgefallen, das es bei allen WordPress-Installationen, die auf diesem neuen Server liegen , nicht mehr möglich ist Menüs zu editieren.

    Was nicht mehr funktioniert:
    – Menüpunkt hinzufügen > er ist im Admin Bereich sichtbar, jedoch nicht im Frontend
    – Menüpunkt löschen > nach dem Klick auf speichern erscheint der/die zuvor gelöschten Menüpunkt wieder

    Was noch funktioniert:
    – Menüs an sich lassen sich löschen
    – Menüs lassen sich neu erstellen
    – bereits vor dem Umzug vorhandene Menüpunkte lassen sich umbenennen oder die Position verändern

    Deaktvieren von Plugins hat nichts gebracht. Es ist auch nicht Browserabhängig. Datei-Berechtigungen wurden auch überprüft und sind korrekt. Die Seiten laufen über PHP Version 7.0.9

    Hat hier jemand eine Idee ob es ein Problem seitens des Servers geben kann und wenn ja welche?

    Sonstige Änderungen an den Seiten wurden bislang problemlos übernommen. Nur die Menü-Bearbeitung funtkioniert (bislang) nicht.

    • Dieses Thema wurde geändert vor 3 Jahre, 6 Monate von shining.
Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 20)
  • Hier fehlen uns Detailinformationen, um den Fehler beurteilen zu können.
    Welche PHP-Version wird verwendet? Wird ein Cache-Plugin genutzt? Können neue Beiträge erstellt und veröffentlicht werden? Kann man sich die Website irgendwo anschauen, bzw. wie lautet die URL? Wurden die Plugins vorübergehend deaktiviert, um Fehlerquellen auszuschließen? Wurde die Konstante WP_DEBUG auf true gesetzt und wenn ja, werden Fehlermeldungen ausgegeben?

    Ich würde als erstes aus fehlende Nutzerrechte (angemeldeter Nutzer hat nicht volle Admin-Rechte) oder Einschränkungen in der Datenbank tippen.

    Hallo, vielen Dank für die Antwort.
    Allerdings hatte ich die fast alle Fragen bereits im Eingangsposting beantwortet:

    Welche PHP-Version wird verwendet?
    7.0.9

    Wird ein Cache-Plugin genutzt?
    Bereits deaktiviert
    Auch Caching via htaccess ist nicht aktiv.

    Können neue Beiträge erstellt und veröffentlicht werden?
    „Sonstige Änderungen an den Seiten wurden bislang problemlos übernommen. Nur die Menü-Bearbeitung funtkioniert (bislang) nicht.“ Also: Ja

    Kann man sich die Website irgendwo anschauen, bzw. wie lautet die URL?
    Geht das via Email? Möchte hier nur ungern URLs posten.

    Wurden die Plugins vorübergehend deaktiviert, um Fehlerquellen auszuschließen?
    Ja: „Deaktvieren von Plugins hat nichts gebracht.“

    Wurde die Konstante WP_DEBUG auf true gesetzt und wenn ja, werden Fehlermeldungen ausgegeben?
    Ist auf true gesetzt, es kommen keine Fehlermeldungen.

    Ich würde als erstes aus fehlende Nutzerrechte (angemeldeter Nutzer hat nicht volle Admin-Rechte)
    „Nein, natürlich Login als Admin“

    oder Einschränkungen in der Datenbank tippen.
    „Jede Domain hat eine eigene Datenbank. Eine der betroffenen Domains nutzt eine Datenbank die extern gehostet ist und auch da funktioniert es nicht (bei anderen Domains dort sehr wohl).

    Im Plesk bei den Einstellungen zu den PHP versionen habe ich eben gerade gesehen:
    opcache.enable on

    Kann es damit was zu tun haben? Die Einstellung war vor Sererumzug nicht zu sehen.

    Scheinbar habe ich ein paar Informationen überlesen – sorry.

    Nutzerrechte können auch eingeschränkt sein, wenn man als Admin angemeldet ist – z.B. wenn die Rollen in einem individuell erstellten Theme oder MU-Plugin geändert wurde.

    Bei der Datenbank geht es mir weniger darum, wo sie liegt, als darum, welche Rechte dem Nutzer gegeben wurden, als der sich WordPress anmeldet.

    Es könnte auch sein, dass im Rahmen des Serverumzugs nicht alle Dateien korrekt übertragen wurden. Ggf. würde ich die übertragenen Dateien auf dem Zielserver nochmal löschen und anschließend erneut vom Quell-Server hochladen.

    Zusätzlich zu Begos Überlegungen:
    Du schreibst nichts über Art und Umfang der Menüs.
    Es könnte unter Umständen auch sein, dass bei dem neuen Webhoster durch andere Voreinstellungen das Menu-Item-Limit früher erreicht wird.
    Du könntest mal testweise in der Datei .htaccess Folgendes eingeben:

    
    php_value max_input_vars 1600
    

    Auch mal mit 2000 oder 3000 testen (je nach Menügröße).
    Die oben genannten Änderungen per .htaccess können allerdings nur dann greifen, falls der Hoster bzw. das Hostingpaket das grundsätzlich erlauben.

    Falls diese Änderungen nichs bringen, liegt es entweder nicht an den max_input_vars oder aber das Hostingpaket lässt diese manuelle Änderung durch den Kunden nicht zu. Dann könntest du mal dem Hoster das Problem kurz schildern und ihn bitten, testweise mal den Wert für max_input_vars zu erhöhen (nach Änderungen in der php.ini muss der Server neu gestartet werden). Falls der Server mit Suhosin läuft, sind noch mal andere Änderungen vorzunehmen, aber der Hoster weiß darüber Bescheid. Vgl. http://sevenspark.com/wordpress/menu-item-limit

    Wie gesagt, das ist nur *eine* mögliche Ursache für diesen Fehler.
    In einem ähnlichen Thread schreibt jemand anderes:

    eventually it was a database table failure, running a repair on the tables fixed that

    Kleines Update:
    Wir haben jetzt „spaßeshalber“ mal eine komplette neue WordPress Installation manuell auf einer Domain gemacht, die auf dem neuen Server liegt.

    Sind dann direkt ohne irgendwelche Änderungen auf der Rohinstallation (Version 4.5.3) zum Menü gegangen.

    Menü angelegt.
    Die von WP aufgespielte Beispiel-Seite hinzugefügt als MenüPunkt.
    dann noch 2 weitere Testlinks einfach mit # und benannt mit test 1 und test 2

    und… das gleiche Problem. Die Menüpunkte lassen sich nicht löschen (also erscheinen nach dem klick auf speichern wieder an der zuvor gelöschten Position) und werden auch nicht in Theme Twenty Sixteen angezeigt.

    wir sind wirklich ratlos 🙁

    @flower33
    Danke.. gebe ich direkt weiter und testen wir.
    Datenbank schließen wir wie gesagt aus, da der Test bei anderen Domains, die nicht auf dem Server liegen, gezeigt hat, das es dann problemlos funktioniert.

    Okay wir haben das Problem scheinbar ein wenig näher lokalisiert:

    In der Datenbank
    post_status wird auf future statt publish gesetzt.

    Jetzt fällt mir auch ein, das Beiträge zwar veröffentlicht werden konnten, aber ich musste die Uhrzeit zurück setzen. Hatte mich gewundert, aber in dem Moment noch gedacht, ich hätte mich vllt verklickt und diese beiden Dinge nicht miteinander in Verbindung gebracht.

    Nun hat mein Bekannter die Zeitzone vom Server korrigiert (Berlin) aber das hat leider noch nicht geholfen 🙁
    Ein Beitrag den ich gerade genau 24 Stunden zurück gesetzt habe, wird mir angezeigt mit „vor 12 Stunden veröffentlicht“.

    Der Server wird jetzt gleich nach dieser Änderung/Zeitumstellung neu gestartet. Dann sind wir mit Glück schlauer.

    Oder kann es doch an der ganz neuen PHP Version 7.0.9 liegen?

    Habe beim googlen gelesen, das es vor Jahren mit einer Worpress Version bereits schon mal so ein Problem gab, was aber durch ein Update gelöst wurde.

    • Diese Antwort wurde geändert vor 3 Jahre, 6 Monate von shining.

    Hmm, ich dachte eigentlich an ein MegaMenu oder UberMenu.
    Bei einer frischen Installation und einen Testmenü mit 2 Unterpunkten dürfte es selbst bei Default-Einstellung der max_input_vars (1000) keinerlei Probleme geben.
    Nachtrag: Hat sich mit deiner neueren Info überschnitten.

    • Diese Antwort wurde geändert vor 3 Jahre, 6 Monate von Flower33.
    • Diese Antwort wurde geändert vor 3 Jahre, 6 Monate von Flower33.

    Ja, auch gerade gesehen 🙂

    Werde weiter berichten. Ist ja vllt doch für den ein oder anderen irgendwann auch mal eine Hilfestellung.

    Drück mal die Daumen.. ansonsten müsssen wir weiter rätseln wie es zu dieser Einstellung kommt.

    Nach Zeitumstellung und Server Neustart ist das Problem nach wie vor da 🙁

    Schade, wäre ja auch zu einfach gewesen. 😉
    Es ist seltsam, dass das auch bei einer jungfräulichen Test-Installation ohne jegliche Plugins und mit WP-Standard-Einstellungen passiert, wenn ich das richtig verstehe:

    Wir haben jetzt „spaßeshalber“ mal eine komplette neue WordPress Installation manuell auf einer Domain gemacht, die auf dem neuen Server liegt.
    Sind dann direkt ohne irgendwelche Änderungen auf der Rohinstallation (Version 4.5.3) zum Menü gegangen.

    Jetzt fällt mir auch ein, das Beiträge zwar veröffentlicht werden konnten, aber ich musste die Uhrzeit zurück setzen.

    Sprichst du dabei vom alten oder vom neuen Server?
    Kannst du vielleicht diesen neuen Aspekt für uns noch etwas genauer aus deiner Admin-Perspektive beschreiben und dabei versuchen, dir die genauen Umstände, Einstellungen, Änderungen etc. ins Gedächtnis zu rufen? Und dabei explizit unterscheiden, ob du von altem oder neuem Server sprichst?
    Ohne möglichst viele solcher Zusatzinfos können wir als Außenstehende ohne Zugang zu den WP-Installationen und deinem Dashboard sonst wenig ausrichten.

    Nun hat mein Bekannter die Zeitzone vom Server korrigiert (Berlin)

    Eventuell hat er eine weitere Stelle übersehen, an der Änderungen vorgenomen werden müssen?

    Keeping track of time in any modern computer system is a complex affair. Not only does one have to consider the timezone of the server, but the timezone of the user, the user’s system, the user’s browser, and systems such as PHP and MySQL, each with their own separate time settings.

    In diese Richtung könntet ihr mal noch recherchieren.
    Im hier beschriebenen Fall, der gewisse Parallelen zu deinem aufweist, waren es letztendlich falsche Server-Einstellungen:

    It is fixed now. After struggling two days with the webhosting company they admit that their timezones were not configured correctly.

    Hallo,

    du schreibst:

    Sprichst du dabei vom alten oder vom neuen Server?
    Kannst du vielleicht diesen neuen Aspekt für uns noch etwas genauer aus deiner Admin-Perspektive beschreiben und dabei versuchen, dir die genauen Umstände, Einstellungen, Änderungen etc. ins Gedächtnis zu rufen? Und dabei explizit unterscheiden, ob du von altem oder neuem Server sprichst?
    Ohne möglichst viele solcher Zusatzinfos können wir als Außenstehende ohne Zugang zu den WP-Installationen und deinem Dashboard sonst wenig ausrichten.

    Ja, ich spreche nur noch vom neuen Server. Der alte ist nicht mehr aktiv seit letzter Woche Mittwoch (bzw nur noch via IP erreichbar) und alle Domains sind auf 2 neue Server verteilt. Auf beiden neuen Servern tritt der Fehler auf.

    Tut mir leid wenn ich etwas wirr schreibe. Ich muss gestehen, zum einen haben die 3 letzten Tage mit der Fehler-Suche ganz schön geschlaucht (anfangs dachte ich noch der Fehler sitzt vor dem PC), zum anderen sind Webhosting/Server/Datenbanken etc sind so gar nicht mein Gebiet. Dafür ist (eigentlich) mein Bekannter/Kunde/Geschäftspartner der Crack. Jedoch hat er sich (bislang erfolgreich) WordPress verweigert und programmiert lieber selbst *gg

    Wenn wir bzw er über Nacht den Fehler nicht finden, versuche ich morgen noch mal eine Art Summary zu schreiben und das ganze etwas mehr aufzudröseln. Glaub heut wird das nichts mehr mit mir.

    Die beiden letzten Links habe ich ihm weitergeleitet. Vielen Dank dafür und deine Hilfe!!!

    Eigentlich sollte der Server-Umzug ja alles besser machen.
    Da hat man jetzt 2 supermoderne Hochleistungs Server und dann sowas.
    Technik die begeistert.

    (Irgendwie graut es mir gerade vor den nächsten WordPress Updates 🙂 )

    • Diese Antwort wurde geändert vor 3 Jahre, 6 Monate von shining.

    Danke für deine Rückmeldung. Keine Sorge, du schreibst nicht wirr, nur diese eine Stelle fand ich etwas uneindeutig. Lass dich nicht zu sehr frustrieren, das liegt letztendlich sicherlich nur an einer Kleinigkeit, die übersehen wurde. Die beiden letzten Links sind keine Lösungsanleitungen, sondern sollten nur kurz andeuten, dass ihr mal weiter in diese Richtung recherchieren und überprüfen könntet, ob in puncto Time-Zone-Einstellungen (der verschiedenen beteiligten Komponenten) nichts übersehen wurde.

    Seid ihr weitergekommen bei eurem Problem?

    Hallo, nein… leider nicht. Es wurde gestern an das Unternehmen weitergegeben, die den Server aufgesetzt haben. Techniker dort hat es geprüft, das mit der falschen Zeit auch bemerkt, aber bislang noch keine Lösung gefunden.. scheinbar. Habe heut auch noch keine positive Meldung bekommen.
    War allerdings auch den ganzen Tag mit Hund in der Tierklinik
    Mein Bekannter hätte mir aber sicher auch direkt Nachricht geschickt, wenn die dort voran gekommen wären.

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 20)
  • Das Thema „Nach Serverumzug lassen sich Menüs nicht mehr editieren“ ist für neue Antworten geschlossen.