DevMan

А причем тут боязнь ООП?
В документации описаны, как прикрепить параметры к запросу как в объектно-ориентированном стиле, так и в процедурном. Реализовать общение с СУБД можно и в том, и в другом стиле, если речь идет про 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 видео менять при всплытии

самопис.
внешнее сходство ещё не означает один и тот же движок.

Бывают сертификаты, выданные на несколько доменных имён (тот же LE так умеет).

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

То, что у вас что-то генерируется динамически не меняет сути дела - доменное имя в сертификате должно совпадать с открываемым в браузере, иначе получите ошибку.

Использовать подготовленные выражения с плейсхолдерами.