Игорь Воротнёв

А откуда взялся шорткод [code]? Что-то я не вижу его в списке стандартных шорткодов. Используйте
<code>...</code>
в режиме Text, естественно (не WYSIWYG). Ну а если нужен полноценный вывод кода, да еще с подсветкой синтаксиса - смотрите плагины. Их много, на все фломастеры.

Вопрос немного расплывчато поставлен.
Дополнительные поля постов вывести в постах на странице архива? get_field(), the_field(), как обычно.
Или - добавить дополнительные поля только для самой страницы архива?

UPDATE (из комментов):

Вам следует понять как вообще работают Custom Fields. Поля и их значения хранятся в базе данных в таблице wp_postmeta. Они привязаны внешним ключом в post_ID, то есть поле / поля привязаны к конкретному посту (любого типа - пост, страница, custom post type). Привязать абстрактно к странице архива не позволяет архитектура, то есть, Custom Fields не подходят для этой задачи.

Зато подходят другие решения. Самое простое и очевидное - таблица wp_options. Туда можно сохранять любые ключи с любыми значениями, которые не имеют явной привязки к какому-либо объекту (посту, странице, etc). Для работы с опциями есть функции add_option(), get_option(), update_option(), delete_option().

Если же речь идет только об архивах таксономий (рубрик, меток, custom taxonomies), то можете посмотреть в сторону termmeta. Это полный аналог wp_postmeta, который позволяет добавлять кастомные поля для терминов таксономий (не всей таксономии, а для конкретных терминов, то есть, конкретных рубрик или меток). В данный момент это не является стандартной таблицей, но в версии 4.4. (декабрь 2015), максимум 4.5 (апрель 2016) этот функционал уже будет добавлен в ядро. А пока можно воспользоваться плагином для этого - https://wordpress.org/plugins/wp-term-meta/

Что касается ACF для этих задач. Если у вас бесплатная версия, то этого функционала нет. Если у вас Pro версия, то в ней есть такая штука как Option pages - возможность создавать свои страницы настроек и наполнять нужными полями. Вот эта фича как раз и позволяет создать страничку настроек, добавть в нее поля с привязкой к архивам и создать нужные настройки и поля, чтобы решить вашу задачу. Но, повторюсь, это только в ACF 5 Pro (в 4й весрии это отдельный модуль для страниц опций, но нет смысла сейчас покупать лицензию на 4ю версию).

Используйте специализированные сервисы - MailChimp (рассылки), Mandrill (транзакционные), Amazon SES тд. Настраивайте их корректно на свой имейл, имейл должен быть доменный. То есть, если у вас сайт mycoolsite.ru, то письма должны быть от newsletter@mycoolsite.ru (часть до @ на ваше усмотрение, но лучше что-то близкое по смыслу, или no-reply@). Для этого нужно корректно настроить DKIM и SPF. Вот так это работает, не попадает в спам, не блокируется почтовыми серверами и клиентами, имеет очень высокий показатель доставки писем etc. А слать пачками рассылки через обычный SMTP - это плохая практика.

Ну у тебя кроп по высоте 300px, если картинка больше 300 - она будет обрезана, если меньше - будет свободное пространство сбоку. Это абсолютно логично поведение. Заливай картинки минимум раза в 2 больше. Для вертикальных картинок лучше всего привязку кропа делать к ширине, тогда все будет нормально ложиться в сетку по колонкам, а уж высота - сколько получится (в настройках - высота = 0).

А версия ACF какая? Какие ошибки появляются?
Я когда-то делал стандартным способом, по документации. Вот тут работает без проблем (зарегайтесь быстро, и увидите форму).

WP REST API

https://wordpress.org/plugins/search.php?q=code+hi...

Установите пакет Find Key Conflicts и проверьте нет ли конфликтов.
Если что, все шорткаты - в файле Key Bindings - Default. Переназначить принудительно можно в файле Key Bindings - User. Оба файла доступны из меню Preferences.

Бесплатные:

Polylang (у него есть WPML Compatibility, работает со всем, что запилили под WPML)
qTranslate X
WPGlobus, www.wpglobus.com
MultilingualPress

У всех разный подход, а именно:

Polylang / WPML - переводы это самостоятельные записи, связаны между собой скрытой таксономией "язык". Неудобство - нельзя использовать один и тот же slug для разных языков.

qTranslate X - переводы хранятся в одной и той же записи с помощью спецразметки. Неудобство - при выключении плагина и/или переходе на другой, придется чистить весь контент от спецразметки. В некоторые плагины сложно добавить поддержку qTranslate X.

MultilingualPress - мультисайты, каждый сайт сети - это языковая версия. Контент перелинкован между собой. Удобно, если сайт большой и над каждой версией работает отдельный человек / команда, если контент не зеркальный.

WPGlobus - относительно новый плагин, но выглядит интересно, отзывы хорошие. Работает по принципу qTranslate X (и поддерживает кажется его синтаксис).

Подобные rewrire rules - штука достаточно непростая, ибо, как вы заметили, документация и уроки по этой теме практически отсутствуют. Я года два назад для одной SaaS-платформы на базе WP делал подобную штуку с городами. В итоге сделал, но убил не одну ночь на это, моск почти сломал. Сейчас со старта не вспомню детали, но логика плюс-минус такова:

1. add_rewrite_tag - создать теги-шаблоны %city% и тд
2. зарегистрировать новые переменные для query через фильтр query_vars
3. создать rewrite_rules

Самое главное - регулярки, которые будут ваши rewrite tags (1) парсить в переменные query (2). То есть, результирующая строка в итоге будет типа index.php?post_type=XXX&taxonomy1=YYY&taxonomy1_term=ZZZ&taxonomy2=WWW&taxonomy2_term=UUU

Да и вообще, для начала сделайте п.2 и добейтесь чтобы у вас все работало с "некрасивыми урл", а уж потом - займитесь ЧПУ. Потому как с rewrite rules чаще всего беда как раз в том, что query vars неправильные.

Ну и потом еще сами урлы ссылок (пермалинки) надо будет в нужном формате строить. Там свои хуки, но это уже не сложно.

В общем, приготовьтесь к большому объему отладки, запаситесь кофе Query Monitor и Rewrite Rules Inspector в помощь.

Если настойчиво исследовать результаты гугла после 3й страницы, пробовать разные ключевые фразы, то должно найтись 2-3 урока, более-менее глубоких. 2 штуки точно было на каком-то сайте кажется со словом Shiba в названии. Я пороюсь на досуге в архивах, может найду.

Простой ответ - да.
Сложный ответ:

Есть имплементаторы, есть разработчики. И те, и другие делают сайты. Первые собирают лего путем утановки и настройки цмс, двух десятков плагинов, максимум - копипаста простого кода из интернетов. Вторые на базе цмс решают любые задачи, ровно так, как надо. Разница огромная - и по деньгам, и по срокам, и по качеству. Но и то, и другое - вариант. По сути, это просто разные лиги. Региональный любительский чемпионат против олимпиады или чемпионата мира. Как-то так. Поэтому, если вам в имплементаторы, то достаточно основ пхп, которых нахватаетесь в процессе. Если в разработчики - ближайший год вам придется плотно учиться.

Когда вам приходит возврат из Робокассы на ваш коллбек-урл, на init или другом подходящем хуке вешайте свою функцию, которая и будет менять роль. Как работать с ролями, кратко:

$user = new WP_User( $id );
$user->add_role( $role_name ); // добавить юзеру роль, текущая роль (роли) не меняется
$user->remove_role( $role_name ); // удалить одну роль
$user->set_role( $role_name ); // заменить все роли на одну новую

Подробнее тут и в документации.

Сначала запилите одну темку (желательно что-то отличное от блога) с кастомными фичами в качестве самообучения. Используйте за основу _s (Underscores.me или на гитхабе ищите), это отличный учебный материал. И уже после этого берите ответственность за коммерческий проект.