erstet: без доступа к php-файлам на сервере (или хотя бы через админку WP) я вам ничем помочь не могу. Тем более, такая работа уже выходит за рамки бесплатной помощи. Если хотите - стучитесь в гости (контакты в профиле), обсудим, могу сделать за скромное вознаграждение :)
like-a-boss: так вот концепт как раз в том, чтобы один из 3х кастомных постов, который самый главный на этой странице, являлся как раз этим main_query. А остальные - на здоровье, хоть get_posts, хоть кастомный через $wpdb. Если порыться в исходниках, там на самом деле много фильтров для модификации, я выше скидывал ссылки на часть из них. Первый раз - необычно и непривычно, но добиться нужного результата в большинстве случаев можно. Не всегда, но все же. Зато если получится - тут есть и плюшки. Например, при подключении кеширующего бекенда, результаты главного запроса автоматом кешируются, как и postmeta к ним. Что существенно снижает нагрузку. И ничего писать не надо - все работает из коробки, достаточно кинуть object-cache.php в wp-content. А при использовании $wpdb придется это все ручками делать, хоть и через готове Cache API.
like-a-boss: боюсь, что никак) в теории можно, но категорически не рекоммендуется, ибо повылазить может куча бонусов в самых разных местах. Где-то так, почти слово в слово, ответили разрабы ядра на аналогичный вопрос на StackOverflow. Вообще, я тебе как раз на эту тему в каком-то вопросе пару месяцев назад писал, что по возможности надо всегда использовать именно стандартный запрос, то что называется Main Query, модифицируя его на нужных страницах с помощью хуков pre_get_posts и подобных, а также фильтров (см. один из своих старых вопросов). Это существенно упростит работу и снизит вероятность багов - все переменные и объекты будут корректно инициализированы, запросы нормально распарсены и т.д. Если везде тулить свои запросы, а потом еще пытаться создавать свои пермалинки на кастомные урлы, с передачей кастомных параметров - начнется каша и баги. Работа "по стандарту" убережет от многих граблей.
nzra: WP ломают из-за человеческого фактора - слабые пароли, не закрыт вход, нет лока на брутфорс и т.д. А также - тонны говноплагинов с дырявым кодом. Сам WP, WooCommerce и тысячи адекватных плагинов - безопасны и надежны. Та же ситуация наблюдается с абсолютно ЛЮБОЙ платформой. Про WP вы просто чаще слышите, потому как он очень популярен, и на фоне массового использования, в первую очередь простыми непродвинутыми юзерами, случаи взлома бывают относительно часто, хотя на самом деле редко, если считать от общего количества сайтов на WP.
С 1С интегрируется все, конкретно для WooCommerce есть готовый модуль, не помню только он платный или нет.
nzra: скорость работы зависит от датацентра, серверов, настроек, стека на котором это работает и его заточки под конкретный проект, кеширующих бекендов, оптимальной настройки БД, а уже потом - использование всего этого на уровне кода, кеширование данных, нормальные запросы и тд. Сам по себе WooCommerce сделан хорошо, работает быстро, предоставляет очень большую гибкость для разрабов в плане оптимизации и повышения скорости работы. В принципе, как и любая другая адекватная платформа. Все остальное зависит от рук, которыми вы все это будете собирать. Если поставить WooCommerce и налепить сверху 5 десятков говноплагинов, то работать нормально не будет. Но ровно то же самое произойдет, если налепить столько говна сверху на любую платформу - будь-то Битрикс, OSCommerce или что-то еще.
nzra: можно. Я бы вам советовал перед тем, как связаться с Битриксом или Мадженто, погуглить и посчитать-прикинуть, во сколько будет обходиться допиливание, развитие и поддержка на этих платформах. А потом посмотреть на альтернативы - WP+WooCommerce, OSCommerce, Shopify и так далее. Например, тот же Forbes рекоммендует именно WooCommerce. www.forbes.com/sites/allbusiness/2014/09/26/which-...
Максим Гречушников: для вас лично, как пользователя Битрикс, пусть таким и остается - дело ваше, право имеете. Но кричать на каждом углу, что WP это только бложик - не стоит. 1С нормально интегрируется с внешними источниками, и ему уж точно пофиг что это - WordPress, самописный магазин или что-то еще. Все упирается только в руки и головы программистов, которые эту связку создают.
Lenz007: ок, тогда:
1. Версии игры это у вас - post, page, custom post type или что?
2. Где это надо вывести - в сайдбаре, на главной, на странице игры (поста, страницы, cpt - см. п.1)
Исходя из этого можно будет написать нужный код или указать на нужную функцию.
WordPress - это база, блоги - лишь "встроенный пример функционала post type", из которого эта база изначально выросла. WooCommerce - это полноценные мощные магазины на этой базе. Битрикс - такая же база, которая предоставляет несколько готовых решений на этой базе, среди которых - решение для интернет-магазинов. И то, и другое имеет свои плюсы и минусы. Что выбрать - надо смотреть не только и не столько на функционал, сколько на стоимость и сложность дальнейшего допиливания и поддержки, что неизбежно для любого крупного ИМ. Не несите ерунду по поводу "бложиков на WP", если не владеете предметом разговора в достаточном объеме.
Transients складываются в базу (таблица options), если есть кеширующий бекенд (Memcached, Redis) - тогда в него. Но если есть кеширующий бекенд, то лучше сразу работать через wp_cache_set / wp_cache_get, гибкость и удобство на порядки выше.
add_action работает из functions.php потому что functions.php загружается движком и парсится на очень ранней стадии. То же самое делается в кастомных плагинах, которые тоже грузятся рано. А вот кастомные темплейты уже потом загружаются, и в них add_action не отрабатывается. Там можно ставить хук do_action(имя_экшна) для своих кастомных экшнов, а сам add_action надо тулить либо в functions, либо в плагин.
like-a-boss: Post-to-Posts пришлось использовать, это был наиболее гибкий вариант, так как у меня по сути некоторые custom post types выполняли роль таксономий. Например, есть cpt "событие", есть "таксономические" cpt - локация (у него есть место, адрес, фото, описание, карта и тд - таксономией не обойдешься), есть организация которая делает это событие (у нее тоже куча полей - название, описание, связки по географии, иерархические посты филиалов этой организации, контакты и связки с пользователями - руководители, манагеры и спортсмены, которые входят в эту организацию и тд). И таких связок было очень много. То же с cpt "объявления", которые разных типов и с кучей фильтров-таксономий, кроме аналогичных связок с тем же юзером (cpt user_profile, который в свою очередь тоже связан с кучей других объектов). Я рассматривал вариант добавлять эти поля к custom taxonomy именно через ACF Pro, пробовал даже создавать wp_termmeta и писать класс и template functions, аналогичные по работе с wp_postmeta/wp_usermeta, но в итоге вариант с P2P оказался более гибким и быстрым. Сам ACF Pro очень крутая штука, создание красивых и сложных бекендов для custom fields экономит тучу времени, например те же связки, галерея, repeater (повторяющиеся поля или наборы полей), flexible (добавление гибких наборов полей, по сути любых, в том числе repeater внутри flexible), карта, создание страниц опций и GUI для них, импорт-экспорт, синхронизация между multisite (а у нас эта платформа была еще и SaaS на базе WP Multisite), поддержка мультиязычки (там было 3 языка с возможностью расширения) и т.д. Так что использование этого плагина экономило очень много времени. А с недавних пор у ACF даже заработала более-менее функция создания этих форм и на фронтенде, что еще круче. Буквально 2 строчки - и форма готова. Правда, если это не просто создание поста/cpt, а нужно сохранять дополнительные данные - например, создать юзера, к нему cpt "user_profile", связать их, привязать к другим cpt через P2P - тогда понадобится дописывать немного, но ACF дает кучу разных экшнов на всех этапах, так что в паре с родными экшнами WP получается очень гибко, можно сделать практически все, что угодно. При этом девелоперская версия со всеми фичами и анлимом на количество сайтов стоит всего 100$ - это шара если учесть, сколько времени этот плагин экономит.
Да, я в принципе понял суть, у меня подобна кухня в прошлом году была, большой проект с кучей кастомного контента и сложных связей. При чем не только таксономии, но и postmeta через Advanced Custom Fields Pro, связи между custom post types через плагин Post-to-Posts, и это еще и на кастомный фронтенд завязано, куча своих форм с кучей chained селектов на базе Select2, который как раз и тягал все эти списки таксономий и прочих связок. Задачка еще та была) Например, на одной странице строилась таблица графика соревнований по разным видам танцев, в каждом элементе выводилось количество зарегистрированных участников, а также подробная инфа - откуда участники, их профессиональный класс, и так далее. Большая база пользователей с профайлам с кучей полей. Эта страничка к концу регистрации на соревнования генерила до 2-3к запросов в БД и собиралась больше 10 секунд. Пришлось разбить все на кусочки и отдельно их складывать в memcached с временем жизни от 5 до 15 минут, обновлять их тоже порциями, в результате чего страница грузилась как любая другая - не более секунды. В общем, масштаб вашей трагедии я себе представляю более-менее хорошо)
like-a-boss: да, это больное место запросов WP - SQL_CALC_FOUND_ROWS. Тут немного об этом, и погуглить можете - мне когда-то даже попадались решения. Функция get_posts как раз не использует это, из-за этого нет и пагинации. Эта функция для того и делалась - она идеально подходит, когда надо просто получить Х постов по нескольким параметрам. А для основных запросов (основа контента страницы) используется полноценный объект WP_Query, который корректно устанавливает все глобальные переменные, считает количество строк и тд. Пагинация - не единственный нюанс, там еще есть виджеты и прочие плюшки, которые могут быть завязаны на контекст основного запроса и глобальные переменные. Также с UNION / UNION DISTINCT кое-где есть проблемы, когда-то тут обсуждалось. В общем, с большими базами и сложными запросами всегда приходится маяться. Вам еще хорошо, что вы работаете с таблицей wp_posts, если залезете в сложные запросы на wp_postmeta, в которой значения ключей без индексов - вот там полная печаль с перебором всех строк. И там миллионы строк - обычное дело на более-менее большом сайте. Я, кстати, на всех крупных сайтах где нужен нормальный поиск или фильтрация по куче аргументов (в том числе postmeta) решил проблему на корню другим способом - поставил Elastic Search и все делаю через его индекс. Работает мгновенно, ищет очень хорошо - такой себе персональный гугл. Но тут уже без VPS не обойтись, на shared его не поставишь)
like-a-boss: этот плагин - это must-have) По get_posts vs WP_Query - вы имеете в виду все время, включая выполнение всех остальных операций, связанных с этими запросами, или чисто выполнение SQL? Функция get_posts это обертка, она парсит параметры и делает new WP_Query. Возможно, разница по времени как раз из-за количества аргументов, и, соответственно, сложности запроса.
500к - уже не крохотная бд, тут я немного недосмотрел. У вас это один сервер, или БД отдельно? Для таких объемов не мешало бы выделить отдельный БД сервер и оптимайзить его исключительно под базу. Да и смена движка с MySQL на Percona, а еще лучше - MariaDB, вполне может ускорить. Тяжелые запросы будут всегда, смотрите еще какие из них можно кешировать (механизмы transients, wp_cache_set) и выполнять эти сложные выборки только раз в Х минут / часов.
Тимофей Бережнов: "никак не дебажу" - о боги, как?))) Установите Query Monitor пока работаете и научитесь им пользоваться. Jquery, конечно, выход, но я бы делал server-side.
