maks843: если вы веб-дизайнер, то должны что-то понимать в CSS. Все формы используют его. Берете их CSS, копируете все стили в свой style.css, их родной файл стилей отключаете через functions.php - и все, модифицируйте стили на здоровье. Даже просто отключив их стили вы уже получите форму дефолтную по оформлению, она должна сразу начать подхватывать ваши стили, если они корректно оформлены.
Максим Олейник: поищите у меня в профиле, я несколько раз подробно отвечал что и как надо делать на VPS, чтобы все работало быстро и качественно. Там для убунты, но на центосе то же самое, только команды адаптировать надо. Свой сервер - всегда быстрее и гибче, но за ним нужно следить. В первую очередь - в плане безопасности, потому что любой выделенный сервер постоянно бомбардируется всевозможными ботами.
Максим Олейник: какая операционная система там? Если убунта/дебиан - почитайте про команды apt-get update, apt-get dist-upgrade. Для CentOS кажется yum update, yum upgrade, или как-то так. А зачем вам тогда VDS, если вы не умеете с ним делать все то, для чего он предназначен? :) Начинайте изучать, там нет ничего суперсложного. Командная строка не так страшна, как кажется
Оксана:
1. Уж больше возможностей, чем у WordPress и его колоссальной экосистемы плагинов, вы больше нигде не найдете. Больше - только самопис под конкретные задачи и пожелания.
2. "Получить больше возможностей" - например, каких?
Если уже используется Owl, то почему его не использовать? Это никакое не забивание, библиотека уже есть, загружена и используется, для этой задачи ее же и юзайте. Owl отлично оптимизирован и прекрасно справляется с множественными каруселями на одной странице.
Иван Украинцев: qTranslate X и Polylang. Работают совершенно по-разному, оба стабильны, оба совместимы с кучей всего остального - от ACF до того же WooCommerce.
Иван Украинцев: разбирайтесь, по ходу еще много интересного узнаете :) Так, чисто для информации - плагины для поддержки многоязычности (например, Polylang) используют для языков именно такой подход - приватная кастомная таксономия. И еще для очень многих решений это можно использовать.
Иван Украинцев: нет, post formats (не types) о которых вы говорите - это от лукавого, и сейчас, кстати, в команде разработчиков ядра платформы поднялся вопрос о том, чтобы выпилить их из ядра в плагин. Я говорю об обычных custom taxonomy. По умолчанию у вас есть стандартные таксономии category и tag, вы используете для своей задачи category, добавляя кучу граблей - nofollow для "служебных" категорий, по-хорошему их еще и из вывода в списке катогорий надо исключать и тд. А можно зарегистрировать дополнительную таксономию через register_taxonomy(), дать ей свойства public=false, rewrite=false (https://codex.wordpress.org/Function_Reference/reg...). Таким образом, она вообще на фронтенде появляться нигде не будет, никакой путаницы, никакой необходимости что-то прятать. Но через код, внутри вашего плагина или темы эта таксономия полностью доступна для работы, ее можно использоваться для Taxonomy_Query в WP_Query, таким образом фильтровать посты по нужному типу. В админке эта таксономия также будет отображаться, рядом с тегами и рубриками, что даст возможность назначать их свободно, и для ACF Pro они также будут доступны, чтобы корректно работали правила отображения метабоксов ACF в зависимости от значения этой таксономии.
Подсказка - можно зарегать кастомную таксономию и сделать ее непубличной. Тогда не нужны будут эти танцы с бубном (nofollow и фильтрация в списках рубрик etc). По +10 в карму за идею и ACF Pro :)
А вот например в том же PHPStorm, тем более в 9, GitHub прекрасно работает, а что делать тем, кто использует BitBucket? Плагин для BB сильно устаревший и нерабочий.
Вот еще информация, на русском. Вызова comments_template я в вашем коде не вижу вообще. Его наличие и корректная работа должна пофиксить и работу have_comments(), и wp_list_comments(), и не надо будет ничего изобретать и строить грабли.
80689248440: Именно поэтому я вам говорил вначале, что для нужно пользоваться хуками. У вас там в wp_list_comments() вместо стандартных аргументов ($args - массив настроек и $comments - массив самих комментов) стоит фильтр WooCommerce. Соответственно, надо читать доку к этому фильтру и хукаться в него, чтобы переназначить $comments, передав в него массив с комментами, так как в этой области видимости он пустой (именно поэтому не отрабатывает have_comments()). Это именно то, что я вам говорил о контексте исполнения кода. Попробуйте там где wp_list_comments() получить комменты вручную с помощью get_comments(), и удалите фильтр из wp_list_comments() заменив его правильными аргументами.
ligisayan: это не бяка, это принцип, по которому сервис работает, и это четко прописано в описании плагина. А в документации всегда описано, как можно сделать все под себя. Читать надо всегда в первую очередь документацию, и только если ее нет или она не полезна - тогда гуглить что-то другое.
