Роман Якушев: ну если вы все делаете руками, то и поля делайте руками. Изображения храните в wp_options, загружайте их обычным аплоад-полем, обрабатывайте с помощью wp_handle_upload. Соответственно, либо делаете поле multiple file upload, повторяющееся поле upload. Если не хотите городить вагон кастомного кода вручную - используйте плагин, их для этого и создавали. ACF, Pods, и им подобные.
Что касается "где хранить". Если у вас есть пост - подобные данные хранятся в postmeta. Если поста нет, тогда есть таблица wp_options.
Роман Якушев: Писать кастомный код - это не костыли, а абсолютно нормальный и адекватный способ РАСШИРЯТЬ или МОДИФИЦИРОВАТЬ возможности платформы, если стандартных фич вам не достаточно. Костыли и говнокод - это практика конкретного человека с кривыми руками и недостаточным уровнем знаний. Чтобы не писать костыли, нужно изучать ядро платформы (любой, с которой вы начали работать), понимать как все устроено внутри. А чтобы это осознать и освоить, необходим хотя бы средний уровень знания PHP/MySQL.
По поводу того бага - он долго не фиксился, так как это не баг WordPress, это некорректная настройка БД сервера у некоторых хостеров, как я и написал выше - EDGE CASE (крайний, редкий, нестандартный случай). WP (как и любая другая платформа) не может физически предусмотреть все возможные настройки говнохостеров. По ошибке в логе сразу видно в чем проблема - некорректный Collation. А вот то, что в случае возникновения такой редкой ошибки не срабатывают проверки - это уже по части WP, но багом называть это некорректно. Просто нашелся edge case, для которого пришлось добавить дополнительные checks. Подобные ситуации встречаются везде.
Роман Якушев: Роман, не делайте громких заявлений, не понимая о чем говорите. Любая платформа (и друпал в том числе) имеет свои особенности. Я на WP 10 лет работаю, за это время были сделаны не только "бложики", но и крупные платформы, SaaS-решения и тому подобное. И ни одна из названных вами "проблем" никогда не была проблемой. Ваш баг в мультисайте - edge case, при чем связан с одним и тем же нюансом, про который уже годами твердят - кодировка должна быть UTF-8 и Collate, никаких cp-1251 и прочей средневековой ереси. У меня ни разу с ним не было проблем, даже учитывая то, что есть весьма сложные SaaS-решения на multisite, взглянув на которые вы никогда в жизни не подумаете, что это WordPress. Остальные ваши вопросы - это не "проблемы", и непонимание вами архитектуры или недостаточный уровень владения PHP (вместе с незнанием архитектуры WP) чтобы писать свой кастомный код.
Зачем TimThumb? Так, чисто для информации, его больше разработчики не развивают и не поддерживают. Он уже deprecated. Не говоря уж о том, что это самая дырявая компонента во вселенной.
Хотя {$variable} - вполне нормально для PHP, это не соответствует WordPress Coding Standards. Если пишете код для WordPress - используйте конкатенацию или printf/sprintf, а строки заключайте в одинарные кавычки. HTML-атрибуты должны быть в двойных кавычках.
Tlito: нормально он работает, к тому же там можно выбрать место откуда тестировать - для наших краев лучше всего Амстердам. Не смотрите только на конечную цифру, смотрите ПОЧЕМУ она такая - что сколько времени занимает. И оптимизируйте каждую составляющую, которая в этом нуждается. Pingdom дает кучу подсказок и инструкций по этому поводу.
VladimirZhid:
1. Функция foreach() - это цикл, с помощью которого можно пройтись по каждому элементу массива, пошагово, по одному элементу за шаг. $posts_array as $post означает, что идем мы по массиву $posts_array, и на каждом шаге, его текущий элемент ставим в переменную $post, чтобы иметь возможность работать с ее содержимым (в данном случае это объект WP_Post).
2. WP_Query - это класс WordPress, который используется для получения поста/постов из базы данных и выдачи их в виде объекта/объектов. Это очень мощный инструмент, на котором построена вся работа с постами в WordPress, но в вашем случае проще использовать get_posts, так как вам не нужны и глобальные переменные, ни весь тот вагон дополнительных свойств и методов, которые возвращает WP_Query.
3. По большому счету, вместо get_posts можно было бы использовать кастомный SQL запрос через $wpdb (еще один полезный класс), и получить только ID постов, этого будет достаточно. Но это более продвинутая техника, вам пока лучше не погружаться в этом направлении - мозг взорвется :)
Александр | netpix.pro: можно, только блог - к другой платформе. Ни чего не сказано по поводу блога в блоге, ибо это получается матрешка. Фильм Inception смотрели? У вас примерно так же.
Да вы что! Я вот уже 10 лет никак не разочаруюсь, как и миллионы других пользователей в экосистеме WP :) Забавно, что за эти 10 лет экосистема эта настолько выросла, что занимает почти четверть всего интернета.
