Игорь Воротнёв

location /images/ - маппит УРЛ site.com/images/ в папку, которую вы укажете в директиве root. Соответственно, должно быть:

location /images/ {
      root /var/www/stuff/images;
}

Это называется FOUC – Flash Of Unstyled Content. Происходит он потому что у вас невалидный и кривой HTML, менюшка ваша выводится в HEAD (где ее быть не может по определению, только в BODY), и до CSS. Отсюда и проблема – сначала браузер выплевывает HTML-разметку, а потом спохватывается, что вот еще стили есть, берет их и перерисовывает страницу.

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

Привязка через is_page работает, но на крупных сайтах жизнь сильно усложнится, когда появится много custom post types, архивных страниц и тд, когда кроме подключения файлов js/css еще надо localize_script делать... В общем, таком код быстро превратится в макароны, которые сложно поддерживать.

Я бы делал другим путем. Что мешает добавить на редактирование страниц metabox, в котором можно дополнительно указать путь к произвольным assets, которые уникальны для этой страницы? Хранить их, соответственно, в meta или в options. Ну и дописать функцию которая будет проверять это значение и если оно не пустое - подгружать нужные файлы.

Профит:

- код пишется один раз и он универсален для данной задачи
- код совершенно не зависит от ID или слагов страниц
- при добавлении/удалении assets поддерживать/обновлять код не нужно, достаточно в админке изменить привязку

из обсуждения:

var slides = document.querySelectorAll('.slider-item');
var sliderToggles = document.querySelectorAll('.slider-toggle');
var currentSlide = 0;

if ( slides.length > 0 ) {
    var slideInterval = setInterval(nextSlide, 2500);
}

function nextSlide() {
    sliderToggles[currentSlide].classList.remove('slider-toggle--active');
    slides[currentSlide].classList.remove('active');
    currentSlide = (currentSlide+1)%slides.length;
    sliderToggles[currentSlide].classList.add('slider-toggle--active');
    slides[currentSlide].classList.add('active');
}

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

например ......./glavnaya(это главная моя созданная страница)

Это у вас неправильно. Назначьте этк страницу как "главную" в насройках Чтение.

У вас изначально код торчит в functions.php, не определен в коллбек-функцию, которая вешается на какой-то хук? Тогда вы все делаете неправильно. Ваш код выполняется каждый раз при загрузке любой страницы, как на фронте, так и в админке. И выполняется он когда происходит загрузка файлов темы. Повесьте код на template_redirect. Вместо get_permaink используйте $_SERVER['HTTP_REFERER'].

Ну, реализацию вам тут вряд ли кто-то будет делать - задача более-менее объемная и скорее для фриланса, нежели Тостера. Логика в целом проста:

- Делаете селект с городами
- Выбор сохраняете в куку на клиенте
- При заходе получаете куку
- Исходя из значения в куке подгружаете нужные данные
- Сами данные храните как удобно, скорее всего это будет Options API. Для этого создаете свою страницу настроек, в ней поля для каждого города. Значения сораняете с идектификатором города, который и будет храниться в куке (или лучше вообще сериализованным массивом в одном поле).

Недостатки подхода без геолокации:

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

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

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

1. Регистрируете custom taxonomy 'letter'.
2. Заводите в ней термины для букв.
3. Назначаете статьям соответствующие термины. Можно автоматизировать - на хук save_post повесить автоназначение нужной буквы. Также можно пройтись по всем статьям автоматом и назначить.
4. Все остальное идет из коробки - на фронте буквы выводите как термины, с их ссылками. Страница архива термина и будет словарем со статьями на эту букву. Плюс сразу красивые ЧПУ.
5. Дополнительный (важный) бонус использования таксономии - быстрые запросы. Вместо того чтобы перебирать текстовые поля и проверять первую букву.

Очевидно, что Database() можно вынести в отдельную модель, типа ActiveRecord,

Она у вас и так вынесена, в класс Database.

и просто наследовать её

А вот этого делать не стоит. От слова совсем.

Есть такая штука, Dependency Injection (DI). Почитайте. Возможно, не сразу вкурите. Но это необходимо понять и научиться с этим работать.

Должно быть как - у вас есть контейнер, который знает все ваши классы / сервисы (они регистрируются в него или с помощью Service Locator подтягиваются). Он же (контейнер) держит в себе инстансы этих классов - при первом вызове класса он инициализируется 1 раз и сохраняется в контейнере. При последующих обращениях контейнер возвращает уже существующий инстанс. Инициализацию сервисов в конструкторах делать не надо, это жестко связывает ваш код и ведет в никуда. Зависимости надо подкидывать через конструктор, параметрами.

zorca в комментах написал уже, public_html из путей уберите

Да напишите один раз свой Bem_Nav_Menu_Walker и используйте его повторно в других проектах. Про Walker почитайте тут.

хорошо знает wordpress и woocommerce (опыт 3 года)

Опыт за 3 года можно получить разный, но я как человек который действительно хорошо знает WP (12 лет) и достаточно неплохо WC рискну поставить данное заявление под сомнение. Там такой вагон нюансов и тонкостей, что мало не покажется. И чем крупнее / сложнее проект, тем больше их вылазит.

имеет ли смысл тратиться на рекламу и предлагать только разработку на wordpress и woocommerce

Лично я себе плохо представляю поиск заказов через рекламу. Если же имеется в виду можно ли с помощью WP/WC делать проекты с хорошими бюджетами и, как следствие, прилично зарабатывать - да, можно. В мире WP есть почасовые ставки и по $120/час, и по $200/час. Так что все возможно. Чем больше опыта и знаний, больше успешно сделанных показательных проектов - тем выше заработок. Работы в данной нише на любой вкус и кошелек, от говносайтиков на "премиум"-темах за гроши, до крупных платформ с бюджетами не ниже чем в мире Laravel / Yii / Symfony / Whatever.