WordPress – Das Hinzufügen einer Beitragskategorie erfordert eine Seitenaktualisierung, um angezeigt zu werden

Ich habe ein neues Design auf der neuesten Version von WordPress (Version 3.3.1 ab diesem Beitrag) erstellt.

Beim Hinzufügen einer neuen Kategorie (sowohl in einem normalen Beitrag als auch in einem benutzerdefinierten Beitrag) wird die neue Kategorie nicht angezeigt, ich muss die Seite tatsächlich aktualisieren, damit sie angezeigt wird. Wenn ich einen neuen Beitrag schreibe, muss ich einen Beitrag speichern/veröffentlichen, bevor ich die Seite aktualisieren kann. Das ist etwas ärgerlich, da ich es normalerweise gewohnt bin, dass WordPress die neue Kategorie hinzufügt und die Seite asynchron aktualisiert, sodass ich dann sofort die neue Kategorie auswählen kann.

Ist jemandem das schon mal passiert? Ich habe mein Thema im Moment sehr leicht gehalten, also bin ich mir nicht sicher, was es verursachen könnte. So ziemlich mein gesamter Funktionscode ist für die benutzerdefinierten Beitragstypen, die ich erstellt habe, aber das Problem tritt auch bei Standard-Beiträgen auf.

Hat jemand Ideen?

BEARBEITEN FEST
Ich musste nur meine Funktionsdatei aufräumen, indem ich einige Leerzeichen entfernte

Nur für den Fall, dass jemand anderes auf dieses Problem stößt, einer der Hauptgründe, warum solche Dinge schief gehen können, sind Leerzeichen vor und nach den öffnenden und schließenden PHP-Tags in Ihrer Datei functions.php Ihres Themes.

Weitere Informationen finden Sie in der FAQ- und Fehlerbehebungsabschnitt für WordPress.

Ich habe dieses Problem heute erlebt, und Leerzeichen in PHP-Dateien waren das Problem.

Jedoch, Ich möchte die Schritte teilen, die ich unternommen habe, um das Problem zu lösen:

1. Ich habe versucht, jede PHP-Datei zu öffnen und am Anfang und Ende der Datei nach Leerzeilen zu suchen. Ich habe ein paar Probleme festgestellt, aber das Problem blieb bestehen.
2. Ich konnte auch eine Regex-Suche in meiner IDE nach Problemen durchführen. Ich habe Textmate/Regex: Whitespace vom Anfang/Ende der Datei als Bezugspunkt entfernen und [without quotation marks] die folgende Regex sucht nach „\?>[\r\n\t ]+” um Leerzeichen/Leerzeilen am Ende einer Datei zu finden, und “[\r\n\t ]+<\?" für den Beginn einer Datei.
3. Es gab immer noch Probleme, also habe ich den Umfang eingegrenzt, indem ich Plug-Ins deaktiviert habe (ich wusste auch, dass es eines meiner eigenen Plug-Ins auf der Website war, die ich entwickle, das hat es einfacher gemacht).
4. Beim erneuten Aktivieren eines Plug-ins wird eine Warnung ausgegeben: „Das Plug-in hat während der Aktivierung X Zeichen einer unerwarteten Ausgabe generiert“. Dies half mir bei dem Trial-and-Error-Prozess, die Quelle einzugrenzen.
5. Sobald ich das Plug-in identifiziert hatte, fing ich an, require_once()-Aufrufe in PHP-Dateien zu kommentieren, bis die Warnung „Das Plug-in generiert X Zeichen mit unerwarteter Ausgabe“ verschwand.
6. Irgendwann wurde mir klar, dass ich das Plug-in während des Refactorings beschädigt hatte und ein require_once() auf einer PHP-Datei ausführte, die reines HTML war (um Favicon-Tags in einen Seitenheader einzufügen), anstatt den entsprechenden add_action()-Aufruf für die Datei wie ich es ursprünglich beabsichtigt hatte.

Hoffentlich sind diese Debug-Schritte eine Inspiration für andere Leute, die das gleiche Problem haben. Soweit ich weiß, bietet WordPress keine einfache Möglichkeit, die Ursache dieses Problems zu identifizieren (dh es erkennt nicht, welche Datei fehlerhafte Leerzeichen enthält).