Одновременное обновление администратора приводит к тому, что настраиваемые поля не обновляются

Хорошо, у меня есть еще одна проблема с проблемой, и хотя я все еще пытаюсь выяснить, что происходит, и какую помощь мне может понадобиться, я подумал, что я что-то выброшу и посмотрю, будет ли кто-нибудь еще раньше видел такую ​​проблему.

Мой сайт в настоящее время запускает WordPress 3.6 на сервере Linux и размещается в Rackspace. На самом базовом уровне моя проблема связана с обновлением настраиваемых полей для сообщения, когда сообщение сохраняется или обновляется.

Я настроил несколько настраиваемых мета-полей, которые отображаются для определенного типа сообщения (в этом случае – продукты). Эти настраиваемые мета-поля содержат входы и спецификации для каждого из этих продуктов как на их собственной почтовой странице, так и на других интерфейсных страницах моего сайта. Я добавил функцию сохранения в действие сохранения для сообщения (кнопка обновления), чтобы информация, содержащаяся в этих мета-ящиках, была сохранена в несколько настраиваемых полей. Я выполнил это с помощью следующего метода.

Вставить мета-окно:

function create_custom_products_taxonomies(){ register_post_type( 'products', array( ...other inputs... 'register_meta_box_cb' => 'products_meta_box', ...other inputs... ) ); } add_action('init', 'create_custom_products_taxonomies'); function products_meta_box() { add_meta_box('custom_product_info', __('Top 10 Product Listings'), 'add_custom_page_product_info', 'products', 'normal', 'high'); } 

Определение функции:

 function add_custom_page_product_info() { ...code to populate meta box... } 

Сохранить определение:

 function save_acpi_data() { ...code to save information in meta box... } add_action('save_post', 'save_acpi_data'); 

Я добавляю это в основном просто для того, чтобы показать, как я это делаю.

Способ настройки моего кода заключается в том, что функция сохранения проверяет данные из настраиваемых мета-полей, а затем сохраняет информацию в соответствующие пользовательские поля. У меня также есть функция сохранения, настроенная для очистки после себя и удаления любых настраиваемых полей, которые присутствуют, которые не имеют связанной метаинформации, присутствующей в сообщении сохранения / обновления.

Моя проблема возникает ТОЛЬКО, когда несколько пользователей регистрируются в админке моего сайта и обновляют / сохраняют эти страницы. (У нас на сайте около 700 продуктов, и для обновления сайта требуется несколько человек.) Когда это условие происходит, данные, которые находятся в моих настраиваемых мета-полях (настраиваемые поля?), Каким-то образом удаляются и, таким образом, исчезают из мой сайт.

Сейчас моя рабочая теория заключается в том, что данные, которые проходят через WordPress при загрузке страницы на стороне администратора и / или после публикации, как-то усекаются. Я основываю это на том факте, что, когда у нас около 6-7 человек вошли в админку сайта и работали над ним, что на четырехъядерном сервере у нас есть текущий сайт, размещенный на привязках к ЦП до 100% для короткие, но повторяющиеся периоды времени. Кроме того, я заметил, что в моих журналах ошибок apache и в то время, когда несколько человек обновляют сайт и исчезают данные, появляются ошибки, похожие на следующие:

 Script timed out before returning headers: async-upload.php, referer: wp-admin/post.php?post=75064&action=edit&message=1 Script timed out before returning headers: async-upload.php, referer: wp-admin/post.php?post=75262&action=edit&message=10 Script timed out before returning headers: async-upload.php, referer: wp-admin/post.php?post=75269&action=edit&message=6 

повторяется несколько раз.

Эта проблема с потерей данных не была очевидной до этой недели, но опять же до этой прошлой недели в данный момент на сайте было всего 2-3 человека. Я также не смог дублировать эту проблему даже в малейшей степени на втором сервере разработки (идентичная настройка сервера, версия WordPress и код темы), когда я единственный человек, зарегистрированный в админке. Это последнее нажатие изменений на нашем сайте появилось после обнаружения нескольких постоянных ошибок почти на каждой странице продукта и исправления ошибок в течение разумного промежутка времени.

Я хотел бы просто проигнорировать проблему и сказать, что она будет завершена и убрана, как только эти проблемы будут исправлены, но я знаю, что она снова появится позже, и, кроме того, проблемы, которые она вызывает для текущего сайт сейчас очень впечатляет. У нас есть резервная копия сайта, и команда, ответственная за ее поддержание, просто вынуждена копировать эти потерянные данные из резервной копии на текущий сайт. Снова и снова и … вы получаете картину.

Прямо сейчас я пытаюсь смягчить проблему, проверяя, что количество информации, присутствующей в моих настраиваемых мета-ящиках, соответствует тому, что присутствует, когда моя функция сохранения переходит к сохранению (и очистке) всех соответствующих настраиваемых полей. (Проверьте данные после сохранения сообщения)

Я еще не смог найти способ проверить, урезаны ли данные на загрузке страницы на стороне администратора, а затем удаляется при сохранении сообщения. В этом случае пользовательские поля на странице будут отображаться пустыми после загрузки страницы, даже несмотря на то, что данные все равно будут присутствовать в базе данных и «должны» отображаться. (Проверьте данные о загрузке страницы администратора для публикации)

Я уже вычистил весь сайт для ошибок php, обратившись к информации, представленной параметром WP_DEBUG, к true, пропуская через передний и задний концы сайта с активным плагином панели Debug Bar, а также путем очистки моих журналов ошибок apache (кроме упомянутые выше ошибки).

Я думаю, что это достаточно описывает проблему, которую я вижу. Думаю, мои вопросы для сообщества:

  1. Кто-нибудь еще видел такое поведение? (Не имея части «очистки» моей функции сохранения, эта проблема будет отображаться как информация в мета-ящиках, которые не сохраняются / не обновляются в соответствующие пользовательские поля, когда почта сохраняется.)

  2. Есть ли что-то еще, на что я должен смотреть?

Моя единственная другая опция – отключить «очистить» часть моей функции сохранения и заставить других парней вручную удалить все пользовательские поля, связанные с информацией, которую они хотят удалить, что было бы утомительно для них, но сохранить сайт удаление случайной информации, которую мы не хотим уходить. Если я не смогу найти решение этой проблемы относительно скоро, мне, возможно, придется обратиться к этому нежелательному варианту.

Я бы скорее решил проблему. Думаю, это то, что я получаю за то, что я инженер. 🙂

Solutions Collecting From Web of "Одновременное обновление администратора приводит к тому, что настраиваемые поля не обновляются"

Итак, я думаю, что я уверен, что я сузил эту проблему достаточно, чтобы опубликовать решение.

Эта проблема возникла на другом сайте. Однако этот новый сайт размещен на сервере, на котором размещено большое количество других веб-сайтов (все наши). Важная часть причинно-следственной ситуации выше должна заключаться в том, что серверный процессор закрывается и, таким образом, вызывает проблему где-то в WordPress и, вероятно, не имеет никакого отношения к тому, чтобы быть зарегистрированным на стороне администратора WordPress. Функция сохранения сообщений, которая по-прежнему мне неизвестна, вызывается без какой-либо информации, представленной на домашней странице WordPress.

Кажется, я решил свою проблему, включив в каждый из своих мета-полей скрытый ввод со значением «присутствует», а затем проверяя наличие и значение этого ввода перед выполнением каких-либо пользовательских функций сохранения / очистки связанные с этими обычными мета-ящиками. Поведение этого нового сайта, похоже, подтверждает эту гипотезу, поскольку ранее я применял это «исправление» ко всем настраиваемым мета-полям на этом новом сайте, за исключением одного, и на этот раз этот единый настраиваемый мета-ящик (без «исправления») ) был единственным, кто смог отобразить любую потерю данных.

Я не совсем уверен, как описать эту проблему достаточно, чтобы я мог уверенно представить ее как ошибку для WordPress. Я даже не знаю, можно ли считать это ошибкой. Тем не менее, включая некоторую проверку ошибок в коде WordPress, которая активируется, когда что-то пойдет не так с данным запросом сервера, вероятно, будет хорошей идеей. Эта функция проверки ошибок, похоже, не присутствует в этой версии WordPress (3.6), или, по крайней мере, такая проверка ошибок, похоже, не работает так, как должно быть, в моем случае.

Надеюсь, это поможет кому-то еще в подобной ситуации, даже если из-за этого не произойдет никаких изменений кода ядра WordPress.