Alex

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

Возможно зона его ответственности никогда не покроет весь проект, но это и не нужно.

<?php if (get_search_query(false) !== ''): ?>
  <p> Результаты поиска по запросу: " <?php the_search_query() ?> ". </p>
<?php endif; ?>

Нет. Фишка Vue не компоненты, а Реактивность.

При первом посещении сайта, скрипт записывает в localStorage (или куда угодно) время первого посещения. После, запускает таймер, и скажем, каждую секунду проверяет "Прошло ли 60 секунд со времени первого посещения"

При повторном заходе, время первого посещения сохранится, и его не нужно обновлять. Скрипт опять будет проверять "Прошло ли 60 секунд со времени первого посещения" и изменять свойства страницы если "Прошло"

Гуглите, решений полно.
https://uk.wordpress.org/plugins/wp-all-export/
https://uk.wordpress.org/plugins/wp-ultimate-csv-i...

P.S. Уж не знаю зачем вам это. csv абсолютно не подходящий формат для корректного экспорта таких сложных штук как контент сайта.

Можно. Это ж прям в начале документации описано, разве нет?

Вставляете тег <audio> и обычную кнопку. Вечаете обработчик клика на кнопку и программно включаете/выключаете аудио.

Ищите и выбирайте по запросу "wordpress seat booking system"

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

Его можно хранить в cookie. Только обязательно почитайте о том, как сделать это безопасно.

• Не всегда то, что сейчас кажется самодокументированным кодом будет восприниматься так же спустя время.
  
• Каким бы ни был хороший код, простое предложение с описанием для каких целей нужно это свойство, проще для восприятия, чем искать его по всему классу.
  
• Это нужно для генерации документации. В которой будут не только названия свойств и методов, но и их описания. На русском, если нужно.
  
• Если в проект приходит новичок, ему проще вникнуть имея документацию.
  
• Некоторые IDE могут показывать подсказки с комментариями и доп инфой из phpdoc
  

Как ты ни крути, документирование это крайне важно. Возможно, требовать комментировать вообще всё, с точки зрения компании, немного излишне. Но это может помочь в дальнейшем рефакторинге когда код немного выйдет из под контроля. Это такое ограничение, которое доставляет неудобства программисту, но сдерживает его от выстрела в ногу.

Но, это всё справедливо в случаях, когда комментарии представляют собой чуть больше чем

/**
 * @var int
 */
private int $precision;

Wordpress — Это система управления контентом. Его задача — абстрагировать вас от работы с БД. И он требует определённую структуру для себя.
Вы конечно можете сделать то что вам нужно на Wordpress, но это как забивать гвозди дрелью.

Если вам нужен какой-то простой интерфейс для управления — проще сделать что-то своё.
Форма, немного стилей немного JS для запростов на сервер и PHP API для получения команд и работы с БД.

Не совсем понял о каких именно данных речь. Но, могут. В коде расширения должно быть четко прописано:

1. К каким ресурсам у расширения есть доступ. Например для выполнения fetch к какому-то серверу. При установке такого расширения браузер вас проинформирует что такое-то расширение просит доступ к таким то сайтам.
   
2. С каких ресурсов расширение может загружать скрипты или ещё что-то. Например для аналитики. Тут, браузер не будет спрашивать у пользователя разрешение. Во всяком случае ранее не спрашивал.
   

Браузер не даст доступа к какому-то ресурсу, если в манифесте расширения его не указано.
В настройках расширения, браузер показывает к каким ресурсам расширение просит доступ. И в зависимости от браузера вы можете заблокировать его к тому или иному ресурсу. Или ко всем ресурсам сразу.