НО
Ну это либо запрос в базу либо в options лишний мусор каждый раз. А хук 1 раз вызовет.
Size: a a a
2021 October 18
АП
большинство опцию имеют автозагрузку, тоесть ваша опция из базы подтянется автоматически. не будет лишних запросов
НО
А есть в wp механизм "отложить до след вызова" что то вроде nexttick ?
АП
но это тоже будет мусор в базе
АП
есть ActionSheduler, но вам нужно его вызывать в момент обновления. а хуков нет
НО
Таска удалится, а версия будет каждый раз лежать.
АП
вы удивитесь, но оооочень многие плагины хранят свою версию в базе. и именно так у них устроена миграция
MK
да почти все)
НО
И не только версию... некоторые кеш запросов умудряются там хранить и меня это уже достало)) Потому не хочу эту кучу наваливать дальше. 45мб в какой то момент было в autoload
АП
ну мы же вам не предлагаем кэш хранить в базе. всего лишь версию плагина
НО
Если других вариантов нет то придется но в идеале на хуках как то. Попробую с Sheduler разобраться. По сути на upgrader_process_complete нужно добавить одноразовую таску, а при следующем вызове зарегать хук на эту таску.
АП
если при этом ваш код завязан на изменения в БД, то вы получите ошибку или не предвиденное поведение плагина
АП
при "следующем вызове" как вы говорите
НО
Думаю если поставить наивысший приоритет хуку то обновление бд завершится раньше чем она потребуется менее приоритетным задачам.
АП
В разработке нельзя полагаться на авось.
НО
Без тестов в прод не уйдет)
АП
Тесты - это конь в вакууме. А ситуация может сложиться при определённых обстоятельствах
KD
Все большие плагины так работают
KD
MK
это от того что кто-то доку не читал и не в курсе что для всех новых опций по дефолту включен параметр
autoload