archelon

1. В оглавлении резюме пишешь DevOps

2. Перечисляешь навыки (включая DevOps стек)

3. Перечисляешь компании где занимался frontend-разработкой.

На первичном собесе с эйчаром, говоришь занимался фронтом, но в какой то момент в компании переключился на DevOps, затем проходишь/не проходишь технический собес.

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


Рекомендую использовать другой плагин или сделать/ заказать свое решение под задачу, посмотрел интереса ради код этого плагина, это творение Аi - весьма кривое

Получаете данные о языках и из них собираете тот переключатель который у вас в верстке. Типа такого:

$translations = pll_the_languages(array(
        "raw" => 1,
));

<div class="dropdown">
    <button class="header-lang__btn"
            type="button" id="dropdownLangButton"
            data-toggle="dropdown" aria-haspopup="true"  aria-expanded="false">
        <span class="header-lang__text"><?= $translations[pll_current_language()]['name'] ?></span>
    </button>
    <div class="dropdown-menu dropdown-menu-right" aria-labelledby="dropdownLangButton">
        <?php foreach ($translations as $item) : ?>
        <a class="dropdown-item <?= ($item['current_lang']) ? 'disabled' : '' ?>" href="<?= $item['url'] ?>">
            <?= $item['name'] ?>
        </a>
        <?php endforeach; ?>
    </div>
</div>

Тут все ответы одновременно верные, не верные и противоречащие самой задаче.

1. "Ничего не изменилось" противоречит концепции самой задачи: по условиям задачи уже что-то изменилось. Ничего не изменилось в дизайне странице. Изменился объём страницы и увеличилось потребление трафика, а так же объём вычислительных ресурсов необходимых для обработки данной страницы.
   
2. Расходы снизились, т.к. после пересборки и деплоя проекта запустился механизм очистки кэша предыдущей версии проекта и которая занимала больший объём, чем текущая. Расходы увеличились, потому что объём проекта увеличился.
   
3. Скорость - аналогично: проект пересобрался чуток по-другому из-за других хэшей в названиях файлов, которые архиватор пережал чуть более эффективно. Или сжатие страниц не использовалась и скорость отображения страниц замедлилась.
   
4. Износ НЖМД относится к пункту 2, т.к. это часть расходов на обслуживание сервера.
   
5. Электропитание - то же самое: больше байт для обработки - больше затраты на электричество, архиватор сжал эффективнее - меньше байт, меньше затраты.
   
6. Так же и с уязвимостью: дополнительные 43 байта привели к возможности использовать атаку при переполнении буфера в такой странице памяти (ну, условно, конечно). Или наоборот избавили.
   
7. По любому пункту выше (и даже ниже) можно получить как взыскание, так и премию.
   
8. То же самое с выбросами: пользователи получили замедление страницы и со злости очень активно и экспрессивно высказались в адрес владельцев и разработчиков сайта, что привело к более активному дыханию и дополнительным выбросам. Ну или наоборот - пользователи уснули в ожидании загрузки страницы и меньше надышали.
   

Даже формулировка вопроса включает в себя вообще все ответы: к чему могло привести? Это событие могло привести вообще абсолютно к чему угодно - хоть к коллапсу и взрыву сверхновой звезды на другом конце вселенной через миллиард или триллион лет. Так что если отвечать именно на этот вопрос, то да, все ответы верные.

Такие вещи лучше делать не ковырянием в стилях, а переключением класса.
И jQuery не нужен.

А иногда можно и вообще без JS обойтись, но не всегда структура документа такое позволяет.

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

1) Лучше искать по словам "IP-камера" (по "веб-камере" будут попадаться всяике изделия с USB портом; а надо - с Ethernet)
2) Убедиться, что поддерживает протокол ONVIF.
3) Убедиться. что в описании нет слов "работа только с облаком ННН"
4) Подумать - надо ли именно поворотную. Ибо парочка не-поворотных камер запросто может стоить дешевле.
5) Подумать - нужны ли детекторы движения и т.п. (дабы начинать запись только по обнаружению движения; или - отправлять алярм)
6) Нужна ли запись (если нет - только текущую ситуацию можно посмотреть; а начинает хотеться глянуть, что собакен делал пол-часа назад и где он взял то, что сейчас жуёт :)))
7) Убедиться, что веб-морда камеры работает в современных веб-браузерах и не требует какого-то
экзотического плагина для просмотра видео.

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

Выбирайте, где будет храниться индекс искомой информации а точнее проводиться сам поиск. Популярно - это делают на веб сервере, но если у вас полностью статический веб сайт (состояит из html файлов и все) то можно сделать и на клиенте в браузере, для этого нужно будет знать javascript (альтернативно vbscript и если совсем необычно - то xml+xslt, но это совсем все переделывать, потому что выворачивает на изнанку подход к разработке).

Если информации мало, т.е. поиск по ней без создания индекса будет быстрым (десятки страниц) то код для реализации этого будет считанные несколько строк на php.

Если делать поиск на клиенте, то необходимо будет собрать в каком либо виде (пусть и в виде константы на javascript, т.е. json) индекс - содержащий искомую информацию и ссылки на страницы, где она размещена, в том виде, в котором его удобно будет искать.

Я очень очень давно видел очень странную реализацию поиска на стороне клиента, каждая страница содержала javascript метод, прописанный на onload, который проверял, что страница загружена во frame, и если да то проводил поиск и вызывал у потомка метод - Результат поиска, с указанием true/false есть ли искомая информация тут (там скорее всего простой поиск по подстроке тупо по содержимому документа document.InnerHTML). На странице поиска был список всех страниц сайта (несколько десятков), они по очереди подключались во frame, делая следующий на получение ответа от предыдущего... т.е. при поиске по очереди загружались страницы, проверялись, нужная ли она или нет, и поиск продолжался, по окончанию оставался список нужных, можно было ткнуть на нужную... естественно страницы всего сайта попадали в кеш браузера после первого же поиска, все работало очень неплохо (я не помню что там было сделано на случай ошибок, сейчас такое бы на чистом javascript реализовали бы),.. делать так не рекомендую но как пример что способов реализовать поиск очень много.

взять тег <blockquote> и стилизовать.