DevMan

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

Неправильно.
Лучше не играйтесь с безопасностью, если не понимаете как это работает. Используйте стандартный sessionid, и ничего больше в куки не нужно писать.

php.net/manual/ru/session.examples.basic.php

Есть ли смысл брать node.js?

Если фронт не нравится, то смысл залезать в тот же "фронт" только на сервере?

Что можно учить дополнительно к PHP из бека?

Лучше выучить один нормально, а не скакать туда сюда и в среднем не знать ни один язык хотя бы средненько.

Когда будет нормальная база программерская(что как работает, как сделать любые типичные(или не очень) задачи, понимание что выучить список функций языка и синтаксис != быть хорошим разработчиком), тогда можно брать любой язык и пробовать. Синтаксис быстро понимается особенно если в английский смочь. Всё остальное с гуглом узнаётся в пару кликов.
Потому что от языка в основном не зависит что вы на нем сделаете, на всех можно делать одно и тоже, только синтаксис разный и целесообразность действий разная(писать CMS на Си никто не будет в здравом уме).

А причем тут боязнь ООП?
В документации описаны, как прикрепить параметры к запросу как в объектно-ориентированном стиле, так и в процедурном. Реализовать общение с СУБД можно и в том, и в другом стиле, если речь идет про MySQl.
php.net/manual/ru/mysqli-stmt.bind-param.php

PS: Вы просто боитесь усваивать документацию, пробовать различные примеры реализации. Вот и все.

Возможно.
Наберись терпения и подбирай.

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

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

после такого челенджа вопросов где и что искать у тебя просто не возникнут :) удачи.

Вам нужна помощь того, кто работает в компании, в которой все процессы выстроены грамотно и не просто работает, но и участвует в выстраивании этих самых процессов.

Из быстрых советов.

1. Завести систему управления проектами, лучше Jira пока ничего не придумали. Для разработчиков не самая удобная система, но с точки зрения бизнес процессов лучше ничего нет.

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

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

4. Если еть инициативные разработчики, можно сформировать команду которая будет выстраивать эти процессы. Например встречаться раз в пару недель и обсуждать, чтобы хотелось изменить/ улучшить. К таким решениям будет больше доверия.

Работа по выстраиванию процессов медленная и тяжелая, нужно определить приоритеты и составить план действий.

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

По каждому направлению в котором Вам предстоить работать есть множество хороших книг, составляйте для себя список и начинайте изучать.

PDO не пишет за тебя SQL. Он может выполнить только тот запрос, который ты сам смог написать. Поэтому фраза "PDO умеет как-то работать без LIMITа" не имеет смысла.

Так что сами запросы оставляй как есть.
Переделывать под ПДО имеет смысл всегда, если у тебя сейчас стандартный говнокод вида "у пети 2 яблока, а у васи 5": while mysql_fetch_array и вот это вот все.

Если тебе будут впаривать SQL_CALC_FOUND_ROWS - не ведись, это заведомо медленнее, чем count(*) и все равно 2 запроса.

Обеспечивается тем, что умные люди не хранят в коде пароли.

php.net/manual/ru/function.header.php

$path = parse_url($url, PHP_URL_PATH);
if (empty( $path ))
    header('Location: http://www.example.com/news');

Это просто кровавый энтерпрайз. У нас тоже так. У нас разрабы сразу говорят: "Не пытайся понять все это сразу, тебе понадобится минимум полгода чтобы понять и освоить устройство приложения и его частей [на таком уровне, чтобы работать автономно]."
Вам нужно больше задавать вопосов коллегам. Вы не успеете умереть от стыда - вопросы кончатся быстрее:)
Как молвит японская поговорка: "Спросить - позор на один раз. Не знать - позор на всю жизнь".
У нас например один из архитекторов добровольно сделал курс обзорных презентаций (3 раза по часу) по архитектуре приложения и это здорово помогло. Спросите тимлида, может он подговорит какого-нибудь опытного программиста или архитектора на такое доброе дело. Все понимают что новичкам надо помогать. Но сами по себе они не бросят все, чтобы заполнять ваши пробелы. Но все без проблем поделятся опытом. Это же для любого человека приятно - показать свои знания. Так что вы не бойтесь, они только на вид такие неприступные. Сядьте рядом с каким нибудь особенно разговорчивым и веселым коллегой. Он вам будет потихоньку все обьяснять. Посмотрите как он анализирует баги, и задавайте вопросы, это много дает. Никто не ожидает что от вас на первых порах будет много пользы. Так что не переживайте. Но все оценят если вы будете быстро впитывать полученные знания. У нас некоторые новички за 3 месяца освоились а некоторые и за год не в зуб коленом.

Тебе нужно в модалке лишь id видео менять при всплытии