Все не так)
1. WordPress не видит переменные $_GET, кроме тех, которые ему известны (механизм пермалинков использует парсинг $_GET, неизвестные ему переменные вырезаются). Надо либо регистрировать переменную, либо парсить $_SERVER['REQUEST_URI']
2. Внутри функции yo_pre_get_posts не нужно писать никаких SELECT и уж тем более выполнять запрос - странно что при этом вам вообще WP сам не объяснил куда сходить с таким кодом))
3. В этой функции нужно всего лишь задать ПАРАМЕТРЫ запроса (новые либо изменить стандартные), когда вы подключаете функцию в 'pre_get_posts' он отправит измененный запрос через стандартный механизм. То есть, в основном лупе получите не стандартный набор постов, а тот, который вам нужен. И дальше не надо пользоваться new WP_Query, так как на момент вызова этого кастомного лупа у вас уже есть полученные нужные данные в стандартном лупе.
Сейчас вникну в суть задачи, скину параметры для функции
@rOOse ну если б он не сохранял сгенеренную картинку - это же вообще был бы мрак) Сам по себе инсструмент нормальный, тем более что он хукается в родные функции. Просто в данном случае я не вижу вообще никакой необходимости использовать сторонние решения, инклудить и выполнять лишний класс, если поставленная задача решается родными средствами на ура, без дополнительных плясок. По воробьям из пушки)
@georgypoplavsky если обновляете, то могли юзера какого-то брутфорснуть. Пароли принудительно менять на сложные. Или, как вариант - после установки "зануленной" темы или плагина появился бекдорчик - бонус от "нулителей"-робингудов. Лечится просто - покупкой оного у оригинального производителя.
@rOOse ну вот bfi_thumb и есть костыль. Ресайзы на лету - плохая практика, неразумное использование ресурсов. Картинки должен выпллевывать Nginx даже без обращения к PHP, не то что процессить их на лету. Ясно, что на западе тоже своих клоунов хватает) Но процентное соотношение заметно меньше. Генерить допразмеры можно и нужно, если это необходимо. В данном случае я вообще не вижу необходимости, на сайте 3 разных размера картинок. И как раз 3 (не считая оригинала) WP предлагает по умолчанию. Зачем генерить новый размер, если можно изменить стандартный? Если на постоянной основе нужно кропнутый (например, тот же 600х600) - это тоже можно сделать, все настраивается, кроп можно задать и для размера medium, и large, если в этом есть необходимость - не только для thumbnail. Если же нужно временное решение "в нескольких местах", то создавать лишний размер - тем более глупо, ибо он будет создан для ВСЕХ загруженных картинок, из которых большинство не будет использоваться. Вместо этого лучше использовать уже существующий, например, 900х600, и оборачивать его в overflow:hidden.
@rOOse просто я пурист) В основном работаю на запад, там по умолчанию стараются использовать по максимуму богатые возможности ядра, на то они там и есть. Последний год начал осваивать рунет, и начал прозревать от того количества костылей, которые строят над WP там, где это вообще не нужно. Вместо того, чтобы почитать доки и полистать код самого WP, среднестатистический рунетовский разработчик запилит сверху костыль. Как евангелист WP стараюсь препятствовать этому везде, где это возможно. Особенно это касается новичков, которые только осваивают WP. Дай им дурной совет - и вырастет еще один костылестроитель. Направь в правильное русло - вырастет толковый разработчик. Ничего личного :)
Да и вообще, как правило, если портфель в открытом доступе, то вероятнее всего он правдивый. Если публиковать чужие работы - вас достаточно быстро на этом поймают, и потом отмыться будет практически нереально. Так что не стоит даже рисковать. Лучше 3 своих работы поставить, чем чужие. Это правило работает, поэтому к портфолио относятся обычно без каких-либо подозрений.
@zelenin не нужно путать со здравым смыслом. Оптимизация не преждевременная, а как раз на базе накопленного опыта и наступания на грабли. Толковый разработчик изначально систему строит оптимизированной на необходимом уровне. И здесь дело не только в мегабайтах, хотя и они безусловно важны. Чем меньше разных размеров, тем меньше самих файлов грузит пользователь, меньше запросов обслуживает сервер. Те превьюшки, которые он получил на главной, на других страницах уже берутся из кеша. Это тоже большой плюс. Здесь нужно видеть все шире. Ваше утверждение неприменимо. Оптимизированная система тоже работает как часы, ничем не хуже, и даже лучше. Одно другому не мешает. Вы же эти понятия фактически противопоставляете, что в корне неверно. Я занимаюсь разработкой тем для WordPress уже не один год, и с размерами под разные форматы вывода сталкивался уже очень много раз. Паттерн "не плодить ничего лишнего без крайней на то необходимости" всегда был, есть и будет самым разумным подходом. Ваша позиция по "преждевременной оптимизации" - это обычная лень и нежелание разработчика принимать стратегические решения. "Сначала сделаем абы работало, а потом посмотрим, если что - допилим".
@zelenin все относительно. Например, я для оптимизации скорости работы сайтов использую VPS от Digital Ocean, который на SSD. Гигабайты SSD весьма недешевые. Простая математика. Пример: новостной сайт по шоу-бизнесу. Редакторы загружают целые фотоотчеты с каких-то вечеринок. Грузят файлы любых размеров, в том числе оригиналы прямо из камеры. Сверху еще генерится куча превьюшек разных размеров. Каша. Вес папки uploads увеличивается как на дрожжах. Далее ставится плагин Imsanity который ограничивает максимальный размер (грузить можно любой файл, но он потом ресайзится, таким образом оригинальный размер всех файлов никогда не превышает заданные размеры), ставится EWWW Image Optimizer для сжатия без потерь качества, проводится инспекция всех размеров картинок и из 6 разных размеров, созданных ЛЕНИВЫМ девелопером оставляются стандартные 3, которых в реальности более чем достаточно. В итоге, было почти 20Гб мусора, около 50 000 файлов. Становится 6Гб и меньше 20 000 файлов. В деньгах это выражается просто - экономия $20 каждый месяц.
Если картинка не подходит по пропорциям - есть CSS overflow. Это не я узко мыслю, я как раз стараюсь мыслить эффективно. А вот ленивые разработчики, вместо того, чтобы думать стратегически, плодят кучу дополнительных размеров, подключают сторонние библиотеки, и т.д. Владельцу проекта такой необдуманные подход рано или поздно вылазит боком.
@Lici есть плагин ajax thumbnail rebuild, отлично справляется. Но все же это лишний гемор. Мне с первым новостным сайтом пришлось уйти от хостера не потому, что места или трафика больше ел, а inodes не хватало. Файловая система была забита всякими дополнительными размерами и прочей ерундой.
@rOOse и один из 3х существущих вполне должен подходить, их размеры можно изменить в настйроках или через код. Я там на сайте вижу 2 размера - превьюшка поменьше и превьюшка побольше (о которой и идет речь). Первая - thumbnail, вторая - medium, и еще остается large для вставки больших картинок и original для полноразмерного просмотра в лайтбоксе, если нужно (хотя вряд ли). Зачем здесь плодить дополнительные размеры? Чтобы через год-два работы сайта папка uploads весила на 20% больше? Или чтобы при смене темы (дизайна) нужно было опять пересоздавать все превьюшки, менять размеры, создавать новые... Зачем?
@zelenin для начала можно обойтись изменением одного из предустановленных размеров. И только если этих разных размеров заметно больше, нельзя использовать что есть (в том числе уменьшая и подгоняя по размеру в css) - только тогда создавать дополнительные размеры. Ибо каждый дополнительный размер будет создаваться для каждой фотографии. Я, как владелец 2х новостных порталов, знаю чем это выползет через 2 года, когда картинок будет гигов 10. И когда захотите сменить тему, а там другие размеры.
1. WordPress не видит переменные $_GET, кроме тех, которые ему известны (механизм пермалинков использует парсинг $_GET, неизвестные ему переменные вырезаются). Надо либо регистрировать переменную, либо парсить $_SERVER['REQUEST_URI']
2. Внутри функции yo_pre_get_posts не нужно писать никаких SELECT и уж тем более выполнять запрос - странно что при этом вам вообще WP сам не объяснил куда сходить с таким кодом))
3. В этой функции нужно всего лишь задать ПАРАМЕТРЫ запроса (новые либо изменить стандартные), когда вы подключаете функцию в 'pre_get_posts' он отправит измененный запрос через стандартный механизм. То есть, в основном лупе получите не стандартный набор постов, а тот, который вам нужен. И дальше не надо пользоваться new WP_Query, так как на момент вызова этого кастомного лупа у вас уже есть полученные нужные данные в стандартном лупе.
Сейчас вникну в суть задачи, скину параметры для функции