xmoonlight

<img src="clock-demo-thumb-200.png" 
      alt="Clock" 
      srcset="clock-demo-thumb-200.png 200w, clock-demo-thumb-400.png 400w"
      sizes="(min-width: 600px) 200px, 50vw">

CMS - это система управления контентом (простые готовые "рельсы" для блога и подобного).
HTML/CSS/JS - это фронт-енд.
php/mysql - это бэк-енд.

Что общего между ними?!
Для пары/тройки CMS - нужно изучить грамотное создание шаблона, чтобы люди могли его легко инсталлировать и пользоваться.

А PHP и CMS - здесь ничего общего....
Изучите любой PHP фреймворк для начала - я бы посоветовал микро-фреймворк fatfree.

В canvas можно использовать WebGL рендеринг, который сам по себе быстрее работает (GPU) и намного гибче, чем SVG, для оформления и создания интерактивности графика.

Научитесь тестировать производительность схемы базы данных и профилировать производительность запросов к этой базе.
mysql - более, чем достаточно.
Читайте ТОЛЬКО! оф. документацию!

Кратко: тестировщик - это своего рода экзаменатор/фильтр качества выпускаемого продукта, которое прямо влияет на репутацию компании этого продукта на рынке.

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

Тестировщики - тоже бывают разные: реакция приложения на последовательные действия пользователя (обычный тест), удобство использования(UI/UX), тестирование на реакцию приложения при возникновении различных случайных событий и ситуаций (нет интернета, приложение/окно не закрыли как положено и т.д.).

Есть низкоуровневые тестировщики (или элитные тестировщики): они проверяют отсутствие утечек памяти, нагрузку на CPU/GPU, тротлинг, корректность создания потоков, процессов, race-condition и прочее. Как правило - это дебаггер с ассемблером и прочие страшные вещи для отладки при использовании программного продукта.

Всё зависит от Ваших способностей погрузиться в глубины обработки информации: от банальной реакции приложения на экране до регистров процессора/ячеек памяти/отслеживания системных вызовов.

Могу сказать, что это большое отдельное направление, которое набирает обороты, т.к. качественный и стабильный продукт, работающий без ошибок - это репутация компании, которая его произвела, и чем он будет стабильнее и качественнее работать, тем больше людей перейдёт от конкурентов на продукт этой компании.

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

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

Всё не так страшно (MSSQL, mysql,postgres - сгодится):
1. создайте таблицу НАБОРОВ тегов с ID-шниками самих тегов и с ID-самого набора.
2. К каждой записи при добавлении - ставьте нужный ID-шник набора тегов.
3. При выборке по тегам - получаете из таблицы набора нужные ID-шники подходящих наборов.
4. По этим наборам - делаете выборку из основной таблицы с любым нужным фильтром и сортировкой.

Таким образом, Вы ускорите поиск, т.к. не нужно будет проверять уже сами теги и обращаться к другим таблицам для сопоставления (пересечения).

Отмечу, что владею фреймворком Yii2, однако написание сайтов для меня - лично ад, не люблю это занятие.

Значит Вы не владеете им, как и формированием и пониманием архитектуры. (возможно, что это просто не Ваше...)

Посоветую Вам научиться писать хорошие (асинхронные) классы (для парсинга данных и обработки) с использованием новых функций и методов PHP7.

Ваш "конёк": это написание коннекторов к сторонним сервисам.

Т.е. ищите по таким сочетаниям: "сделать коннектор", "сделать интеграцию", "прикрутить к ...", "внедрить на сайт ...", "установить сервис ..."

Не-е.... Вот тут круче и без JS.

Здесь подробно расписано: как посчитать.

Посмотрите здесь

Есть 3 вида API:
1. Публичные - доступные публично с известными параметрами при запросе.
2. Приватные (авторизованное обращение) - доступные публично с известными параметрами при запросе, но с ключом(токеном по паролю) или сертификатом.
3. Закрытые - проприетарные клиенты со своим закрытым протоколом обмена с серверным API.

JS в браузере - это только 1.
Если не 2 и не 3 - значит остаётся 1.

Если МЕГА-тупо (для п.1): можно проверить длительность сессии в момент POST-запроса на сервер и, если длительность меньше времени самого быстрого заполнения формы человеком в ручном режиме, считать данные недостоверными.

Как-то непонятно: обычно методы (аналоги: create, set, get,update, delete и т.д.) выносятся (монтируются) на точки входа клиентских запросов (endpoint).
Все передаваемые методу параметры - это уже POST JSON (в большинстве случаев).
Бывают и исключения, когда методы простые и параметры идут в адресе endpoint, но тогда адрес должен возвращать БЕЗ редиректов и сервер должен корректно "понимать" этот запрос, т.к. фактически это уже поисковый запрос, не имеющий отношения к RESTful.

напр. пользователю понравился музыкальный трек, он переходит по ссылке /media/{track_id}, а его редиректит на /music-groups/{mg_id}/albums/{a_id}/tracks/{track_id}

Адрес не меняем (без редиректа!), но можем вернуть в ответе расширенную информацию о треке, группе, альбоме в виде структуры (массив или дерево).

Вот.

includeHTML

1. Ранжирование по горячести - сортировка отношений общего количества просмотров за прошедший промежуток времени.
2. Выборка для наполнения ленты пользователя - выборка ID-постов по пользовательским предпочтениям вместе с нужным ранжированием.
3. Отображение ленты - это п.2 + таблица прочитанных ID-постов конкретным пользователем (для исключения уже прочитанных).

В порядке приоритета
1. PayPal
2. 2Checkout
3. Payoneer
4. Google Wallet

1. Никогда не пересекайте между собой основную базу объектов с CMS! Должна быть интеграция по ID-шникам.

2. Выбирайте удобную, гибкую и с большим комьюнити CMS. (Я бы выбрал CMS Joomla!)

3.

И вопрос №2 - что посоветуете: заказывать сайт с нуля или подойдёт ориентация на доработку шаблона интернет-магазина - ведь можно найти шаблон с реализацией личных кабинетов пользователей и каталогами объектов, подстроив их под цели задачи?

Вот это то, что бесит больше всего...
Поймите: САЙТ - это НЕ ШАБЛОН!
Каждый проект - УНИКАЛЕН!
ТОЛЬКО с НУЛЯ!

4. Стоимость и сроки - после ТЗ (оплачивается отдельно), ТЗ - после ФТ.
(ТЗ - техническое задание, ФТ - функциональные требования)

этапы создания сайта и прочее