Савелий Дзвонкевич

Действительно, за время, которое потратили на создание вопроса, Вы могли без проблем найти интересующую Вас информацию в любом поисковике.

Но раз вопрос уже задан, то должен быть и ответ(ы).
Собственно, @OnYourLips дал ссылку на хороший фреймворк, но если нет смысла тащить в проект/скрипт целый фреймворк ради одного запроса, к примеру, то логичнее воспользоваться упомянутым CURL. В Вашем случае сценарий использования CURL будет выглядеть примерно следующим образом:

$myCurl = curl_init();
curl_setopt_array($myCurl, array(
    CURLOPT_URL => 'http://target.site.com/form.php',
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_POST => true,
    CURLOPT_POSTFIELDS => http_build_query(array(/*здесь массив параметров запроса*/))
));
$response = curl_exec($myCurl);
curl_close($myCurl);

echo "Ответ на Ваш запрос: ".$response;

Если надо передать при этом ещё и файлы, или обратиться по https, или ещё чего Вам понадобится - добро пожаловать в документацию:
http://php.net/manual/ru/book.curl.php
Советую обратиться к документации в любом случае, дабы ознакомиться со всеми возможными нюансами, а также понять и выбрать то, что конкретно Вам потребуется для решения Вашей задачи.

1) json_decode
2) манипуляции
3) json_encode
4) профит

Тут будет множество мнений и какое реально правильное не сказать точно.
Я для себя выбрал вариант - грузить себе по двум основным причинам.
Во-первых, я оптимизирую шрифты иначе. Как правило требуется гораздо меньше символов, чем заложенов CDN.
Во-вторых, не зависеть от других сайтов. А вдруг гуглофонт упадет?))) Ну, или плохой коннект до CDN.
Мой вариант более затратный по времени. Скачай, оптимизируй, загрузи, подключи.
Я вообще не использую CDN (сейчас в меня полетят камни), но я считаю это правильным.

Второй вариант правильный.
По БЭМ, в идеале, не должно быть никаких селекторов, только классы и минимум каскадов.

Как работать с CSS-препроцессорами и БЭМ

codepen.io/anon/pen/jrXGRA?editors=1100

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

Стал замечать, что разработчиков сайтов на Wordpress высмеивают и говорят, что это уже прошлый век.

Прошлый век? Не знаю, доля WordPress продолжает расти. Сейчас это почти 27% всего интернета, если мне не изменяет память. Немногим больше четверти всех сайтов в мире. И на пути к одной трети. Вдумайтесь. Осознайте. А еще на WP делают проекты с бюджетами и по 20, и по 50, и 150к условных единиц. И с ежемесячным саппортом в четырех-пятизначных суммах. Все это есть. Рынок огромен.

Смеются над WP-разработчиками? Ну, пусть смеются. А мы тем временем хорошее бабло косим на этом "говнодвижке" (как его называют те, кто высмеивает), работаем в удовольствие, тусим по всяким WP-ивентам, создаем продукты, делаем заказчиков счастливыми, весело тратим заработанное и наслаждаемся жизнью. В общем, все отлично. А смех без причины - признак дурачины (С) детская поговорка.

Да, и обратите внимание на то, кто смеется. Какой-нибудь фрилансер-нищеброд, пытающийся заработать жалкие $400-800 в месяц, сутками колупающий свой кастомный фреймворк и отлавливая в нем стремные баги? Хипстер-рубист? Престарелый ценитель-теоретик C и Java, в 40 лет живущий с матерью? Ну ок. Пусть хохочут. Я не встречал ни одного разработчика высокого класса, независимо от предпочитаемых языков / технологий, который бы смеялся. Потому что опытный человек понимает, что это всего лишь инструмент. Который, к тому же, прекрасно выполняет свои задачи. Так же как Laravel. Как Django. И все остальное.

Есть такие люди, которые Canon vs Nikon, Apple vs Android, Mercedes vs BMW и тд. Holy Warriors они называются, и встречаются в любой жизненной сфере, в любой профессии. Научитесь держать удар и не замечать их существования.

Пришел к выводу, что cms никто не пользуется при создании заказных сайтов, но неужели для каждого сайта пишется свой движок?

Неправильный вывод. Используются, повсеместно. Сплошь и рядом. Вообще, есть 3 подхода:

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

2. Фреймворк. Средне-долго, средне-дорого. Здесь используется готовая основа, необходимые модули, остальное пишется под конкретные задачи. Экономически целесообразно. Это хороший вариант. Но работы бывает много, и велосипеды встречаются, и модули напильником дорабатывать приходится. А если использовать много готовых модулей, то плавно перетекаем в 3й подход.

3. CMS/CMF. Дешевле, быстрее. Тут, если сайт сильно типовой и его можно собрать без особого кодинга - отлично. Но часто и на CMS/CMF бывают весьма объемные и сложные задачи, сильно выходящие за рамки возможностей движка "из коробки" или готовых плагинов. Та же разработка кастомного функционала, доработка напильником сторонних плагинов и тд. В общем, не типовые сайты на базе CMS/CMF делать можно и ничто не мешает это делать. Главное понимать зачем, почему и как правильно. Понимать архитектуру CMS/CMF и как в нее встроиться. Этот вариант сильно выгодный клиенту, особенно если речь о WP, с его огромным рынком специалистов (впрочем, часто сомнительного уровня. Но это везде так, я встречал проекты на Laravel и Yii где от кода тошнило фонтаном).

В конечном итоге, все это PHP (или другой язык - не принципиально). И кастом, и фреймворк, и готовый движок. И все это можно сделать очень хорошо, а можно очень плохо. Вопрос не в инструменте, а в руках, которые его используют. Если вы возьмете кисть и краски Моне, вы не станете выдавать гениальные картины. Потому что не в кисти дело.

В общем, если WordPress нравится - изучайте его ядро, глубоко и качественно, изучайте глубоко и качественно сам PHP. SQL туда же. Те же фреймворки изучайте, там много интересного и полезного, что можно взять на вооружение. Учитесь решать задачи любой сложности элегантно, быстро, качественно. Учитесь документировать и рефакторить код. Оптимизировать. Использовать best practices. Учитесь создавать качественный продукт, решающий задачи клиента. И вот за это к вам будет стоять очередь, и будут хорошо платить. А не за то, что вы пишете на чистом си плюс плюс. Или на чем-то супер-современном. Enterprise-клиенты вообще такие legacy. А у них больше всего денег, кстати.

Это все в пределах конкретной компании ведь. Тимлид в конторке по разработке сайтов != тимлид большой международной компании. В целом примерно так:
Джуниор не может сам полностью выполнять таски, ему нужны советы и контроль.
Мидл может сам выполнять таски без контроля и советов, кроме исключительных случаев.
Сеньор - тот, на ком все держится и к кому все обращаются.
Тимлид может быть мидлом или даже джуном в другой компании.
Что конкретно нужно знать вам никто не скажет, да и всего знать невозможно. Если речь идет именно о каких-то технологиях, то это не важно, важно уметь находить решения, а не знать их наизусть.
И еще, лучше быть крутым джуниором/мидлом, чем хреновым тимлидом. Очень смешно смотреть, как человек с двумя годами опыта гордо рассказывает всем, что он тимлид. Этим любят пользоваться хитрые начальники, типа: "Давай ка мы тебя тимлидом называть будем, а ты поработай сверхурочно и по выходным, ты ведь теперь сеньор-помидор!", а молодежь ведется.