Underdoggit

Самые толковые штуки в самых базовых местах. Ссылки отличаются только стилем изложения и подачи.
https://css-tricks.com/snippets/css/complete-guide...
https://www.w3schools.com/css/css_grid.asp
https://gridbyexample.com/examples/

Правильный путь - следовать API wordpress и особенностям CMS.

Выкинуть всё из стандартной темы и забить туда свой код - это значит либо обречь тему на гибель после того, как кто-то нажмёт на кнопочку "обновить", либо сделать тему необновляемой. Ну и, соответственно, это не WP-way.

Прежде чем делать что-то с темой, нужно разобраться, делаете вы тему с нуля, или обновляете существующую.

Существующую тему используют, если
а) требуется лишь несколько фиксов - поправить вёрстку, добавить несколько блоков
б) по какой-то причине даже глубокая кастомизация получается проще (быстрее, легче) чем разработка с нуля. Скажем, диз темы похож на то, что вам нужно, вы чуть меняете подвал-шапку, а остальное закидываете через Visual Composer или похожее решение.

В этом случае создаётся дочерняя тема, в которой происходит основная работа. В результате обновление исходной темы совершается относительно безболезненно для вашего кода, а дочерняя тема поддерживается на уровне совместимости с исходной (требует доработок где-то раз в год при активно обновляемой теме).

Если в планах разработка темы с нуля - то, как уже отметили, оптимальным будет взять готовую стартер-тему вроде underscores. Делать тему с нуля имеет смысл, если вы не хотите тащить кучу мусора из существующей темы, или разрабатываете что-то, что плохо встроится в существующие варианты.

Изменяемые блоки делаются или через визуальный редактор (Visual Composer или другие), или через механизм опций, или через плагины вроде ACF. Причём ACF использовать не обязательно, у WP есть интерфейс для произвольных полей.

В плане того, что использоваться - ACF, фреймворки, или ещё что, логика примерно такая:
1. Общие элементы темы вроде лого, копирайта, контактных данных - это опции (свой код для страницы настроек), фреймворки опций (Redux, ACF-про ) или кастомайзер WP. Последнее кажется наиболее правильным и соответствующим развитию WP - там почти рукой подать до визуального редактирования уже.
2. Контент страниц - стандартный интерфейс для произвольных полей, ACF или другие решения. С ACF причём нужно быть аккуратным, он может упереться в ограничения сервера по количеству полей или давать неверные данные (писал бакенд для мобильного приложения через WP REST API и хлебнул лиха от сохранённых через ACF данных, привязанных к таксономиям)

В плане кода - всё, что должно решаться через API, решается через API. wp_enqueue_script/style для скриптов и стилей, wp_head(), wp_footer() в соответствующих местах. Вариантов превратить разработку темы в извращение тут очень много, доводилось видеть много всякого от неопытных разрабочтиков. И какого-то универсального решения всего этого избежать, возможно, просто нет. Кроме как учиться, смотреть гайды и лучшие практики, следить за обновлениями WP и рекомендациями для разработчиков.

Так, по CMS в целом уже ответили, я лишь пролью свет на сам процесс. По сути термин "натянуть на CMS" не имеет особого смысла. Объясняю:

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

- Чем более кастомный проект, тем больше и больше работы именно на бекенде. Исходя из этого, на практике в крупных проектах фронтенд вообще не прикасается к PHP, "натягиванием" занимаются именно бекендеры. Фронт выдает чистую верстку, а уже задача бекенда - сделать из нее конечный динамичный продукт. Максимум, что светит фронту - уже после натяжки делать какие-то правки, но и тут работа будет сводиться к HTML-CSS-JS. Даже если HTML физически находится внутри файла с расширением .php.

Оторвите голову "дизайнеру"

Любой. У каждого есть своя ниша.
Я занимаюсь WP. Можно и за 2000 рублей шаблон натягивать, а можно за $2000 в месяц разрабатывать плагин с интеграцией в CRM. Можно делать шаблоны с визуальными билдерами, которые будут дико глючить и тормозить. А можно на WP построить магазин с уникальным функционалом, с кастомным импортом/экспортом, с грамотным объектным кеширование и т.п. и этот ваш магазин будет легко держать любой наплыв посетителей.

Перед началом разработки своих тем нужно внимательно ознакомиться с
https://developer.wordpress.org/themes/

Из курсов стоит обратить внимание на:
https://www.udemy.com/wordpress-development-create...
https://www.lynda.com/WordPress-tutorials/WordPres...
Их можно найти на рутрекере, если пока не можете заплатить.

Также стоит обратить внимание на стартовую тему от Automattic:
https://github.com/Automattic/_s

Бойлерплейт - более правильный подход ворпресс-вэй.
Еще лучше - использовать дочерние темы. Тогда многое что нужно уже написано в родительской, и ее за тебя апдейтят, тебе надо только апдейтить в админке наравне с плагинами.
Хотя никто не мешает писать свой велосипед на два с половиной файла и привет.
Это как с плагином - можно одним(!) файлом, а можно целым фреймворком с ООП то же самое(счас как раз сдал такой проект).

1) либо используйте стартовые темы Пример - https://understrap.com/ underscores.me
2) пишите с нуля, не редактируйте стандартные темы ВП и т.д.
3) насчет страницы настроек для темы (Простой вариант - ACF, более грамотный вариант фреймворки). Пример фреймворка - redux framewor
https://reduxframework.com/ https://ru.wordpress.org/plugins/redux-framework/

так как с вп у меня не сложилось, я бы посоветовал начать с modx revo - он несложный, легкий и универсальный. Информации много на ютубе (в том числе в виде пошаговых курсов) + обширная документация. Посадка несложной темы при набитой руке делается за считанные минуты

Для блогов и простеньких сайтов - Wordpress. Лучший урок по созданию шаблона - https://www.youtube.com/watch?v=WFEgmNfvpnw
Интернет магазин - OpenCart. Я выбирал из-за простоты и бесплатности.

На какую CMS вы обычно натягиваете свой макет

На ту которая подходит под проект.

У MODX довольно много гибкости, и на него легко натягивать верстку, плюс он стимулирует к росту в нужном направлении, типо ООП. Вордпресс мне очень не нравится, он тяжел, медлителен, убог и избыточен. Зачем мне эта куча мусора, когда мне нужна CMS, чтобы я мог ее затачивать под конкретные задачи. Вордпресс блог платформа, оставьте ей то для чего она и создавалась - делать репосты из инсты. Дабы не развивать холивар сразу скажу, что это имхо.

Вы выбираете не самый лучший путь. Сверстать макет и натянуть на CMS — это самая низкооплачиваемая работа в вебдеве.

Если отвечать на ваш вопрос — Вордпресс, конечно. Очень популярная система, невероятное количество плагинов, шаблонов и инструментов. Добавьте немного знаний PHP, выучите несколько методов jQuery, разберитесь в устройстве Вордпресса — и вот вы уже готовы работать на фрилансе, делать сайты за 2 тысячи рублей.

Если же вы хотите действительно стать фронтендером, тогда займитесь изучением JS и фреймворков — Реакт, Вью, Ангуляр.

"Громоздкий css фреймворк" === экономия времени.

"Громоздкий css фремворк" хорош когда:
1. Вы являетесь единтсвенным исполнителем, а гонорар за проект фиксированный. Быстрей выполните - больше заработаете.
2. Вы являетесь веб-студией. С фреймворками вы будете клепать типовые сайты со скоростью конвейера. У вас будут конкурентные цены и сроки. Текучка кадров не страшна, так как новые разработчики скорей всего будут знать фреймворк, который вы используете, а если и нет, у фреймворков в большинстве случаев отличная документация и огромное комьюнити.

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

Как путь развития рекоментдую смотреть в сторону Frontend Developer. JavaScript/TypeScript, React/Vue, Babel, Webpack.

любой онлайновый векторный редактор умеет выгружать svg. например figma.com