Максим Степанов: ну это уже совершенно другая задача :) одним-двумя плагинами, боюсь, не обойтись - задача специфическая. Но все решаемо, правда придется лезть в код, и неоднократно. Если с кодом проблем нет - подскажу. Если с PHP не дружите - лучше наймите кого-то. Задача не сложная для разработчика, но писать вам кучу кода с инструкциями куда что вставить и помогать вам удаленно дебажить - это ад. Если выберете вариант с разработчиком - можете в контакты стукнуть (в профиле).
В принципе, все не обнаруженные объекты можно форсить на 404, если так уж сильно надо. Во всех шаблонах идет WordPress Loop, в нем есть блок "else". Обычно именно в нем подключается шаблон или текст "ничего не найдено", который и прилетает вместе с 200м кодом. Ничто не мешает еще на уровне получения результатов запроса к БД посмотреть, если ответ не содержит результатов - отправить соответствующий заголовок, прекратить выполнение, или же продолжить выполнение, но вместо стандартного шаблона включить 404й.
Кеширование результатов запроса идет на уровне MySQL, PHP/Nodejs тут при чем? Если кеш настроен у MySQL нормально, то любой клиент от этого бонус получит. Хоть Perl, Python, C# и тд. Сам в себе PHP ничего не кеширует, если дополнительно не подключен APC/APCu, XCache, Memcahced, Redis или другой кеширующий бекенд.
WP Panda: Не совсем так. Loco - это интерфейс для редактирования PO и компиляции в MO. Он абсолютно никак не подымается при заходах юзеров. на фронтенд, грузятся обычным методом MO-файлы. Поставьте Query Monitor и посмотрите запросы. На фронте ни одного обращения связанного с Loco Translate нет и быть не может. И делает он совсем не то, что код выше. Ваш код - подстановка на лету, а это как раз использование лишних ресурсов. Перевод, сделанный вашим методом нигде не хранится. Если делать через Loco Translate - все изменения раз и навсегда вписываются в PO/MO файлы, как и положено. А MO, кстати, можно еще и в кеширующий бекенд сложить, что будет однозначно лучше и быстрее.
Андрей: я уже попытался подсказать выше, вы видимо не заметили :) Пишете пост. Вариант 1 - дату оборачиваете в шорткод, например [humandate date="ваша_дава" time="ваше_время_опционально"]. Шорткоды WP парсит, вам нужно всего лишь написать функцию, которая будет забирать аргументы шорткода и выводить в нужном виде, и этой функции сделать register_shortcode. Второй вариант - весь контент поста пропускать через парсер. WP предоставляет готовый фильтр:
$content = $db_object->post_content;
$content = apply_filters( 'the_content', $content );
В этот фильтр можно захукать свою функцию, которая пробежит по тексту, найдет нужный контент и заменит его. Для этого есть разные методы - регулярные выражения, preg_replace, preg_replace_callback и другие функции. Это уже вопрос на уровне PHP, и в другой раздел. Со стороны WP для этого все готово.
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, гибкость и удобство на порядки выше.
