Дмитрий

Наконец таки я решил все технические вопросы для внедрения Vue.js в WordPress-Workflow. Долго я к этому шёл. Трудно было совместить freelancing на основе WordPress и WooCommerce и одновременно самообучение Symfony и Vue.js и создание первых реальных проектов на их основе. Но создание первого большого проекта на основе headless Symfony 4 (JSON API) и потребителя на основе Vue.js меня хорошо продвинуло вперед в направлении внедрения Vue.js в WordPress. Почему мне так интересен WordPress/WooCommerce умея делать Backend на основе Symfony? Потому что WordPress делает доступным веб технологии и маленьким клиентам по "демократическим" ценам, при этом всё ещё позволяя фрилансеру хорошо заработать (по крайней мере в Берлине, где я проживаю).

Так как путь сюда до сих пор никем в интернете детально не описан и я угрохал недели если не месяцы на решение этой задачи прочитывая все статьи и docs с этой темой связанные (освоил для этого даже наконец таки Docker и Nginx и углубил знания в настройке Webpack) и пройдя многие не верные пути (vue-cli, nuxt.js) - я решил создать в течении следующих недель курс на Udemy.com на английском за 20 баксов. Если будет тут достаточно интереса (хотя бы лайков 10 ), то сделаю туториал и на русском. Курс будет содержать настройки Webpack, Docker (optional), Apache/Nginx. Моё решение сохраняет в отличии от nuxt.js все преимущества как WordPress так и Vue.js при этом соблюдая "законы" SEO и Social Marketing (Twitter Cards, Facebook Open Graph итп) и самое главное Hot Module Replacement с PHP/WordPress Templates!!!!!! .
Я очень разочарован Nuxt.js и расскажу в Tutorial почему он далеко не во всех случаях технически годен и почему с точки зрения open source этот проект не оптимальный исходя из моего личного опыта.

UPDATE 15.05.2019
К сожалению руки до туториала так и не дошли. Но создал Github Repo с простым Starter Theme.
Демо можно тут просмотреть: wue-theme.app
Пока без доскональной документации. Надеюсь к концу месяца создам.
Приколы темы:
-Hot Module Replacement с PHP файлами (если только это интересно можно и тут скачать Webpack config)
-полная поддержка SEO без Server Side Rendering (SSR). Реализуется это за счёт загрузки данных вместе с HTML в глобальном JS объекте "technomad", вместо дополнительного AJAX-запроса, что не поддерживается гуглом и для чего и нужны все прибамбасы типа Nuxt.js и phpv8/v8js.
-элементы меню и новости автоматически добавляются через WordPress-Backend.
-тема устонавливается как и любая другая тема без каких либо дополнительных настроек сервера (нужно скачать всю Repository и скомпремировать "wuetheme" папку в ZIP и тогда можно просто загружать как и обычную тему).
-Github Repo без данных из демонстрации. Может ещё добавлю функцию установки демо данных.
-сервер демо во Франкфурте без CDN. Так что во Владивостоке загрузка наверное немного дольше длится будет)) Из Берлина за 600-700ms загружается с VPS.
-есть ещё много над чем работать (pagination, проверка загруженны ли скрипты и стили плагинов при Ajax route change, пока они загружаются только при инициальной загрузки, но скрипты и стили могут быть на каждой странице иные) , нo даже в данном виде эта тема на сколько я знаю уникальная.
-тут можно проследить прогресс перестройки моего сайта с этой темой: stage.alexfullstack.dev, там больше клёвых анимаций))
Пока всё. Have fun :)

Update 30.05.2019
Много чего обновил на Github.

Update 02.06.2019
Я решил вчерашнюю проблему)))
Нужно было просто выспаться))
Завтра подробно опишу и обновлю Github Repo.

Update 03.06.2019
-загрузил на Github новую "bulletproof SEO" версию с "Dynamic Rendering Implementation"
-подробная статья тут

Update 14.06.2019
Перенёс сайт на wue-theme.app.
Демонстрация Github версии тут: starter.wue-theme.app
Добавил простую Load More Pagination и очистил код.

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

Прикрепляю пример из своей работы, срез этапа работы с типографикой, иерархией отступов.

Почитать:
https://designpub.ru/https-medium-com-simberev-8pt...
https://designpub.ru/отступы-в-дизайне-системный-п...
https://medium.com/@kovchiy/образы-и-модели-9e4297...

Уже отвечал на подобный вопрос, но про Битрикс, а найти не могу. Расскажу как делаем мы.

Вот структура:

Как видите сам wordpress в репозитории не хранится, (как и плагины, которые из списка зависимостей ставятся на новой машине в пару кликов).

Верстка лежит в src (используется scss и jade) и собирается в папку static - из которой вся статика подключается и в вордпрессе. HTML файлы собираются в папку _v.

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

Если нужно добавить новую страницу - верстальщик верстает в jade, потом программист сольёт его изменения, соберет проект, возьмет из папки _v нужный шаблон и натянет его на wp.

Очень сильно стараемся изменения в шаблонах переносить в исходники верстки, т.е. сохранять её актуальное состояние на протяжении всего проекта.

UPD: Про ветки. Всегда есть master и markup (верстка) + могут быть ветки отдельных программистов / фич и т.д. В мастер изменения сливает только тимлид/техлид/самый-главный-программист.

Здравствуйте!
Зачем прописывать уникальный тайтл для пагинации. С точки зрения СЕО будет лучше, если вы просто добавите для пагинации каноникал (кстати, Yoast SEO по умолчанию доабвляет), но вы также можете настроить каноникал по своему усмотрению. А добавлять тайтл не нужно для пагинации

вот тут много примеров freefrontend.com/css-timelines

1. Если у тебя уже установлен Gulp и настроен локально в папке проекта, то в консоли переходишь в папку этого своего проекта и вводишь npm install node-normalize-scss --save-dev

2. Потом в основном sass-файле делаешь импорт @import "normalize";

3. В таске по компиляции sass в css в пайп добавляешь строчку кода

includePaths: require('node-normalize-scss').includePaths

Вот полный код и документация

var gulp = require('gulp');
var sass = require('gulp-sass');
 
gulp.task('sass', function () {
  gulp.src('path/to/input.scss')
    .pipe(sass({
      // includePaths: require('node-normalize-scss').with('other/path', 'another/path') 
      // - or - 
      includePaths: require('node-normalize-scss').includePaths
    }))
    .pipe(gulp.dest('path/to/output.css'));
});

https://www.npmjs.com/package/node-normalize-scss

Так как в пункте ТЗ не оговорены версии браузеров, то вы можете сьехать на то, что ie8 - это уже не подходит под пункт "Кроссбраузер" в классическом понимании этого вопроса. Поддержка ie8 - это можно обозвать "Поддержка устаревших браузеров = +100% стоимости заказа". Или "Пинание говна динозавра" - если так угодно.
Обосновать - чартами использования браузеров и нецелесообразностью траты денег на мёртвый браузер, который используют полтора пенсионера.

& - это элемент родитель к которому применяеться псевдокласс, можно так же писать и полное имя родителя.
Вот пример с хабра.

.parent {
    position: absolute;  
    &:before {
        height: 100%;
        display: inline-block;
        vertical-align: middle;
        content: '';
    }
}

Он же без &, а с полным именем родителя.

.parent {
    position: absolute;  
}
.parent:before {
        height: 100%;
        display: inline-block;
        vertical-align: middle;
        content: '';
}

Я уже давно понял, что лучше сразу делать адаптивно. Иначе потом все равно переделывать придется. Контейнер у меня выглядит так:

.container {
width: 100%;
max-width: 1200px;
min-width: 320px;
margin: 0 auto;
}

Причем стараюсь делать все резиново. Если такой возможности нет - медиазапросы.

На абстрактный ответ мог бы ответить абстрактно, но отвечу с вариантами.
В зависимости от задачи, я опишу не для сервисов или больших сайтов\ресурсов.
Советую так же прочесть вот эту статью: frontender.info/building-a-better-responsive-website

Обычно использую bootstrap, который дополняю своими стилями, к примеру, сразу удаляю\перекрываю .row с его -15px margin'ом по сторонам, добавляю класс padding-0 для убирания в некоторых блоках padding'a у col- (который стандартно по 15px).

Стандартно учитываю разрешения - HD, ноутбучное 1366 и свое чуть меньше 1366 (у меня пуск справа:) ), 1024-960 - старые мониторы и нетбуки, смотрю в диапазоне 768px-960 для некоторых планшетов и телефонов, и меньше 768 для телефонов. Тут дизайн один, через media onlyscreen убираем с загрузки ненужные части.
Если все сверстано правильно и добавлены везде классы, то сайт будет полностью адаптивным.
Для тестов меньше 768px проверяю через iphone 5 и старенький android-телефон. (Через Toggle Device mode в Google Chrome получаешь очень сильно разительные результаты в сравнении с устройством - браузеры то другие, хотя большие косяки всплывают сразу.)
Тут кстати еще (мобильная) кросс-браузерность очень тонкий вопрос. Стиль у каждого браузера свой, особенно у всяких элементов типа input, так что тоже требует проверки и состояний тоже (placeholder, цвет текста в поле).

Нужно ли это? Безусловно - на любом сайте, в любой отрасли половина трафика с мобильных устройств, это уже стандарт качества, на мой взгляд:)

может для табличных данных все таки стоит использовать таблицы ?

Он ведь для этого предназначен , уверен что если в этом случии сделать через таблиц, все встанет на место.

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

import asyncio  # модуль, который позволяет работать в асинхронном режиме
import random

# "сообщаем", что функция получения данных будет исполняться как сопрограмма
@asyncio.coroutine
def fetch_data():
    data = 0
    # Для примера, будем запрашивать данные, пока не выпадет 6-ка.
    # в реале, вместо получения рандома, ты должен делать запрос к БД
    while not data == 6: 
        print(data)
        data = random.randint(0, 10)  # вот тут делай запрос к БД и заполняй твою переменную
        yield from asyncio.sleep(3.0)  # асинхронная задержка, она не будет блокировать приложение
    return data  # когда вышли из цикла, в переменной data будет только нужная инфа

# эта функция тоже будет исполняться как сопрограмма. без этого декоратора невозможно получать асинхронно данные через yield from
@asyncio.coroutine
def test():
    # получаем данные асинхронно
    # переменная data заполнится только тогда, когда в функции fetch_data выпадет 6,
    # она выйдет из цикла и вернёт значение
    data = yield from fetch_data()
    print('Bingo!', data)
    loop.stop()  # когда получили данные, останавливаем асинхронный цикл
    # ты не должен останавливать, чтобы каждый раз не запускать цикл при получении данных
    # ты должен просто вернуть данные клиенту    
    
if __name__ == '__main__':
    loop = asyncio.get_event_loop()  # создаём цикл
    asyncio.async(test())  # асинхронно запускаем функцию
    # тебе это надо делать при каждом запросе на какой-то УРЛ
    # По-сути, в обработчике УРЛ ты должен просто вызывать функцию test, 
    # а она уже отошлёт данные клиенту
    loop.run_forever()  # запускаем бесконечный асинхронный цикл
    loop.close()  
    # если он завершится (у меня он завершается, когда получена 6-ка), надо закрыть цикл

Ну или вариант попроще, на клиенте создай функцию, которая будет отправлять AJAX-запрос к серверу и ставь таймер в 3 секунды. Когда вернётся непустое значение, тормози таймер.