уменьши тестируемое изображение в 2,3,4,.. раз и поочередно сравнивай с оригиналом
не уверен что это сработает от sharpness фильтров но попробовать можно
это мой вопрос
пока образ собирается совет, создать минимальный образ в котором ошибка воспроизводится, (ну маловероятно что там нужно nginx) и запости баг .. только хз куда, в докер?
решение не учитывает веса а еще из-за дыр в списке значений id это не будет работать как ожидается, но если завести специальное поле - счетчик и обновлять его у всех записей при удалении добавлении записей, то будет работать, только вот обновлять эффективно такой список не получится
у контроллера домена есть специальная роль - backup domain controller, если вы готовы для резервирования данных домена покупать соответствующую лицензию, почему нет.
восстаналивать бакап контроллера через файловую систему а не инструменты резервного копирования самого сервера, после того как вы к примеру там что то поменяли, - мягко говоря опасно и в теории даст сложнодиагностируемые проблемы
Ярослав Иванов, у него там 'толщина ширина и высота'
нет, конечно если там будут еще и другие атрибуты типа массы, формы, цвета и прочего то да, я про это и написал дальше
в подавляюще большом количестве случаев, если работаем с локальным временем а не античной историей к примеру или абстрактным будущим жизни звезд, то более чем достаточно, удобно и максимально быстро работать с unix timestamp, уходя в DateTime или иные форматы только по необходимости (которая происходит очень редко), а в 64bit с отрицательными значениями можно и везде (500 миллиард лет в секундах)
забудь про ob_... он тут совсем не причем,вообще пока не используй
еще раз, создавай картинку как ты сейчас создаешь в post скрипте, не важно сколько у тебя источников, хоть 100500, в конце создания изображения ты его сохраняешь одной командой с выводом в качестве ответа сервера imagepng($full, null);
kna999, это так медленно работает плагин WooCommerce Advanced Bulk Edit? как именно обновляешь данные то?
я не работал с конкретно этой задачей но очень часто, если штатный инструмент создает тормоза, я просто лезу в базу напрямую (да это надо делать с осторожностью), ибо mysq это очень быстрая база данных и простым скриптом, даже если он на каждый товар будет делать по 2 запроса (поиск -проверка что результат 1 - обновление), будет достаточно быстрым, если завернуть все в одну большую транзакцию (или несколько, пакетами).
Кстати так делать не надо, даже с миллионом записей можно залить данные о них локально память скриптом и обработать,