Александр Власов: Поиск-замена обычная ломает сериализованные данные. ACF много чего хранит в сериализованном виде - отсюда и проблема. Ранее не использовали ACF и об этом не знали, хотя проблема у вас наверняка тоже случалась, просто вы ее не замечали, ибо мелочи - те же виджеты часто хранят что-то в сериализованном виде, и если там в данных есть урл - привет битые данные. То же касается настроек темы.
Rad Cor: Что-то мне подсказывает, что у вас где-то болтается какая-то мелочь, которая все портит. Потому что должно работать. Мне аж прям интересно. Постучите в скайп (см. профиль), можем созвониться и посмотреть на вашем экране.
AltaiR: Это важные автоматические обновления - ядро и плагины/темы принудительно по инициативе WordPress Security Team. Обычно это фиксы безопасности. Критические апдейты. Отключать данную штуку крайне не рекомендуется.
Что касается обновления плагинов вручную - а зачем это вообще надо? ИМХО, бессмысленная, и даже вредная затея. Но если совсем надо, для плагинов должно быть достаточно:
Rad Cor: Это то же самое, что я вам писал, код аналогичен, только передача параметров идет строкой (что, кстати хуже - строку надо распарсить + неудобно читать, поэтому сразу массивом передавайте). Вы пропустили мое сообщение, одно из последних, где я советовал еще один аргумент добавить: 'meta_compare' => '=',
Это принудительно заставить сравнивать значение.
Алексей: Ну с совсем простыми сайтами это катит, если вы и потеряли где-то мелкие данные (те же postmeta), то и фиг с ним - либо не заметите, либо заметите через неделю, пожмете плечами и руками поправите. Слетит виджет - ну фиг с ним, зашли установили заново. Если же сайт крупный и с кучей кастомного функционала, то такой перенос гарантированно приводит к потере данных. Еще раз - сериализованные массивы вы так не обновите, если попробуете - они перестанут десериализоваться (битые данные), в ваших запросах нет ни слова о других таблицах - options, termmeta, usermeta, postmeta. Я уже не говорю о произвольных таблицах, которых может быть много. Ваш способ ненадежен. Чем крупнее/сложнее сайт, тем менее надежен.
Некоторые разработчики тем вшивают в них лицензию, как и в плагины. Проверка лицензии происходит на сервере разработчика, ессесно. При нарушении лицензирования идет отказ от апдейтов/поддержки и инвалидация лицензии. При попытке установить ту же лицензию на другой сайт выдаст ошибку. Впрочем, при желании это все можно и выпилить. Но согласен, труд надо уважать, тем более деньги небольшие.
Сериализованные данные поломаются, postmeta / termmeta / usermeta вообще не затронутся, а там тоже урлы будут, произвольные опции поломаются. Не делайте так, есть специальные инструменты
Rad Cor: Смотреть в таблице wp_postmeta. Вам нужно знать ID поста из таблицы wp_posts чтобы изолировать только его поля. Но можно и все листать, по последним добавленным постам записи будут в конце таблицы. Ищите там свое поле и смотрите какое у него значение.
Rad Cor: Не сложно. Вопрос упирается в невозможность проверки данных, которые сохранились в БД - у вас нет доступа к базе. Я у себя сделал, не получилось - открыл БД и убедился, что данные не в том формате, который нужен. Изменил тип поля - и все заработало.
Rad Cor: Все, я понял в чем дело. Чекбоксы хранятся в БД в виде сериализованного массива, даже если там всего один чекбокс. Вот такое значение хранится в БД:
go_index_slider
a:1:{i:0;s:1:"1";}
Естественно, оно нам не подходит никак. Измените тип поля с checkbox на toggle и все будет ок. Собственно, в вашем случае toggle как раз более логичен - он true или false (1 или 0 в базе).
Rad Cor: Значит проблема в сохранении данных в это мета-поле. Если пост должен идти в слайдер, значение будет 1? А если снять галочку - какое значение будет? А если галочка ни разу не ставилась - какое?
