Odisseya

https://jsfiddle.net/dcLhk2pn/

Дальше сами.
А так, какая-то дичь. Просто заюзайте фон. Почему многих людей ставит в ступор подобная вещь. Использование фона как картинки не делает вас плохим, это нормальная практика. Либо вы потратите много времени на эту дичь, либо вы просто заюзаете картинку. Ведь их ещё наверняка придётся адаптировать.

Смысл в этом есть лишь 1 на мой взгляд. Когда эти круги нужно анимировать, тогда да. А просто так, пустая трата времени

В header, по стандартам html5. Такая инфа была в ЯндексПрактикуме

ACF Pro помогает создавать блоки для Gutenberg с помощью PHP, это удобно и значительно ускоряет работу. Но если надо полностью отказаться от ACF Pro и использовать только Gutenberg, то придется запилить свои блоки (привет React) или же найти готовые, подходящие под ваши задачи.

Впрочем, по некоторым блокам стоит выдохнуть и немного подумать - возможно стоит изменить свое мышление. К примеру, на ACF мы повторяющийся контент автоматом считаем рипитером и создаем соответствующие поля. А на Gutenberg часто repeater как таковой и не нужен - достаточно самого блока. Ведь создать несколько одинаковых блоков подряд в Gutenberg не составляет труда, это как бы встроено из коробки.

Простой пример - блок testimonials. На ACF мы создаем обычно рипитер, в нем нужные поля которые будут повторяться, скажем - text, name, photo (текст отзыва, имя клиента и его аватар). А на gutenberg достаточно иметь блок testimonial с этими же полями, и просто вставить его X раз подряд - вот вам и повторяющиеся данные.

jQuery "видит" весь DOM целиком. И манипулирует DOM-ом, доступ к которому предоставляет браузер. Но можно и по-другому.

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

Затем отделим состояние от поведения и представления. Состояние можно описать статической структурой данных, JSON-ом, например. А поведение - это чистая функция, из предыдущего состояния и некоего события (действия) делающая следующее состояние. Представление же "знает", как визуализировать состояние. Можно этот принцип воспроизвести от самых мелких компонент (не имеющих потомков) в нашем дереве и до корня. Тогда весь жизненный цикл приложения можно изобразить как цепочку состояний от некоего начального и до текущего, ведомую событиями (действиями).

Для того, чтобы это всё отобразить, не обязательно в ходе вычисления следующего состояния (или представления) сразу манипулировать DOM-ом. Можно построить из состояния и его представления фрагмент DOM-а, каким он должен получиться. А потом вычислить diff между этим построенным фрагментом (виртуальным DOM-ом) и реальным браузерным. И этот diff применить к реальному DOMу. Один раз. Получится быстро.

Насколько мне известно (поправьте, если это не так), Redux заимствован из Elm-а. Elm - это экосистема и функциональный язык, компилируемый в JS, сделанный для того, чтобы фронтэнд можно было разрабатывать удобно, быстро и без runtime-ошибок. По синтаксису - это адаптация Haskell-a. Ключевым элементом Elm-а является как раз вот эта самая архитектура. Советую подробнее почитать в первоисточнике. https://guide.elm-lang.org/architecture/

Кроме упомянутых особенностей эта архитектура также позволяет выполнять так называемую time-travelling отладку. Поскольку каждое состояние и каждое событие по пути от исходного до текущего можно залогировать и воспроизвести (ведь функция, вычисляющая следующее состояние у нас чистая).

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

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

Привет, можешь ознакомится с matthew.wagerfield.com/parallax в своё время очень выручил :) Он не сложен усвоении. Легко настраивается. Частицы делаешь сам и стилизуешь их в css, можешь и дополнительную анимацию для частиц в том же css и написать. А движение когда водишь мышкой - уже поможет плагин.

Правильный путь - следовать API wordpress и особенностям CMS.

Выкинуть всё из стандартной темы и забить туда свой код - это значит либо обречь тему на гибель после того, как кто-то нажмёт на кнопочку "обновить", либо сделать тему необновляемой. Ну и, соответственно, это не WP-way.

Прежде чем делать что-то с темой, нужно разобраться, делаете вы тему с нуля, или обновляете существующую.

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

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

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

Изменяемые блоки делаются или через визуальный редактор (Visual Composer или другие), или через механизм опций, или через плагины вроде ACF. Причём ACF использовать не обязательно, у WP есть интерфейс для произвольных полей.

В плане того, что использоваться - ACF, фреймворки, или ещё что, логика примерно такая:
1. Общие элементы темы вроде лого, копирайта, контактных данных - это опции (свой код для страницы настроек), фреймворки опций (Redux, ACF-про ) или кастомайзер WP. Последнее кажется наиболее правильным и соответствующим развитию WP - там почти рукой подать до визуального редактирования уже.
2. Контент страниц - стандартный интерфейс для произвольных полей, ACF или другие решения. С ACF причём нужно быть аккуратным, он может упереться в ограничения сервера по количеству полей или давать неверные данные (писал бакенд для мобильного приложения через WP REST API и хлебнул лиха от сохранённых через ACF данных, привязанных к таксономиям)

В плане кода - всё, что должно решаться через API, решается через API. wp_enqueue_script/style для скриптов и стилей, wp_head(), wp_footer() в соответствующих местах. Вариантов превратить разработку темы в извращение тут очень много, доводилось видеть много всякого от неопытных разрабочтиков. И какого-то универсального решения всего этого избежать, возможно, просто нет. Кроме как учиться, смотреть гайды и лучшие практики, следить за обновлениями WP и рекомендациями для разработчиков.

Если это окно является dom-элементом (а не открывается через window.open), вы можете посмотреть, куда именно оно вставляется и поставить точку останова на родительском элементе, которая будет срабатывать на изменения его поддерева.
В devtools хрома это делается на закладке Elements -> правый клик по нужному элементу -> Break on -> subtree modifications.

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

Я как -то пытался такое провернуть. Выходит нечитаемая каша. Согласен с Алексеем Николаевым.