WordPress pobiera metadane dla wszystkich niestandardowych typów postów w widoku listy

Mam problem z WordPress, w którym umiera PHP. Zwiększyłem pamięć, ale proces PHP przeskakuje do 100% wykorzystania procesora, a następnie umiera, a Apache generuje błąd 500.

Próbowałem zmusić Apache do zarejestrowania czegoś lub PHP / MySQL do zarejestrowania błędu, ale nic nie jest rejestrowane poza ogólnym błędem 500.

Numer 500 znajduje się na stronie listy, np .:

/wp-admin/edit.php?post_type=artist

Obecnie mamy ponad 1200 wpisów artystów w WordPress, jeśli dołączę sortowanie według dat w ten sposób:

/wp-admin/edit.php?post_type=artist&orderby=date

Potem lista ładuje się dobrze, nawet szybko! Siedziałem i obserwowałem dziennik zapytań MySQL i wydaje się, że WordPress ładuje metadane dla każdego pojedynczego postu (wszystkie 1200), aby utworzyć listę około 10. W przypadku tylko jednego zapytania zwraca 92 000 wierszy. Używam zaawansowanych pól niestandardowych i szablonu z własną strukturą, więc do każdego postu dołączona jest spora część metadanych. Myślę, że jest to zbyt wiele danych, aby PHP mógł je przetworzyć i osiągam tutaj pułap. 1200 stanowisk prawdopodobnie podwoi się w ciągu następnego roku.

Jak zmusić początkowe ładowanie strony do dodania sortowania według daty lub rozwiązać problem z ładowaniem wszystkich tych metadanych?

wp-query post-meta list

— Paul Cullen
źródło

Czy próbowałeś wyłączyć ACF i inne wtyczki? Myślę, że kiedyś miałem podobny problem i myślę, że winowajcą nie jest sama WP, ale ACF. np. ACF dodaje metadane do wersji, a następnie ładuje to wszystko. Upewnij się, jakie jest źródło tego problemu, ponieważ pomoże to innym osobom pomagającym.

— kraftner

Hej @kraftner ive wyłączył ACF i nie zrobiło to żadnej różnicy.

— Paul Cullen

Ile pamięci używasz na wp-config (WP_MAX_MEMORY_LIMIT)? Jaka jest twoja wartość PHP.INI dla memory_limit? Spróbuj podnieść je do maksimum. Chciałbym również rzucić okiem na twój plik konfiguracyjny mysql.

— Emanuel Rocha Costa

Podniosłem tymczasowo PHP i WP_MAX_MEMORY_LIMIT do 512, bez żadnego efektu. Mój plik konfiguracyjny mysql to:

default-storage-engine=MyISAM innodb_file_per_table=1 max_allowed_packet=268435456 open_files_limit=10000 query_cache_size=64M log_slow_queries = 1 log-slow-queries=/var/log/mysql.slow.log log-error=/var/log/mysqld.log general_log_file = /var/log/mysql_general.log

— Paul Cullen

czy niestandardowy typ posta „wykonawca” jest hierarchiczny (jak strony)? .. jeśli tak, to może być to winowajcą, ponieważ wszystkie posty będą wyszukiwane w panelu administracyjnym. Jeśli Twoja aplikacja pozwala, możesz spróbować zmienić hierarchiczną na false dla CPT „artysty” i sprawdzić, czy to

— rozwiąże

Spróbuj zmienić hierarchiczną: fałsz w definicji CPT (jeśli aplikacja na to pozwala).

Gdy CPT są ustawione na hierarchiczne: prawda, wszystkie posty będą sprawdzane w panelu administracyjnym, co może powodować problemy z pamięcią.

— locomo
źródło

Problem polegał na tym, że CPT był ustawiony na hierarchiczny, przełączając go na hierarchiczny: fałsz w functions.php rozwiązał problem.

— Paul Cullen
źródło

Proszę zaakceptować własną odpowiedź, aby to pytanie mogło zostać zamknięte.

— cjbj