Comments 46
хороший кейс, написано интересно.
спасибо!
Это решение не масштабируемое, вы загнали себя в достаточно узкие рамки, выход из которых будет стоить вам полного рефакторинга структуры проекта.
Если хотелось готового из коробки решения — есть wordpress с его историей редактирования. В вашем же случае, как по мне, было проще создать дополнительную таблицу с историей редактирования и кастомизировать WYSIWYG (это обычно не так сложно, BBCode+regex на бекенде), чтобы облегчить жизнь редакторам.
В прочем, решение имеет право на жизнь, если вы, переходя на статику, просчитали вышеописанный момент и однозначно и на века, решили, что бекенд не нужен :)
Если вдруг понадобится какое-нибудь взаимодействие, то есть, например, лямбды. Даже в статический сайт можно добавить динамику, как например staticman умеет добавлять комментарии, не говоря уже о всяких Disqus и Commento.
Но если вдруг понядобится что-то более узкое, то можно взять и сделать виджет на ReactJS, который будет рендерить что-то с маленького и легкого бека.
Зато статический сайт это действительно дешево (платишь только за домен), быстро (время уходит только на передачу контента) и надежно (GitHub с большим успехом переживет хабраэффект, чем любой купленный хостинг).
Эти плюсы чаще всего с лихвой покрывают все неудобства.
А формы можно отправлять через гуглформс
Заплатки безопасности устанавливаются без участия пользователя.
Более того, есть довольно неплохие бесплатные решения по безопасности для wp от сторонних разработчиков, обрабатывающих общие известные стратегии проникновения. Это как бы мастхэв изначально.
Не идеально, но и не сказать что прям ужас ужас решето.
Вы не правы. Почти никто не пользуется вордпрессом из коробки. Практически всегда используются темы, плагины для кеширования и прочие штуки. И в этих самых штуках и скрывается все криминальное.
Со статикой проблемы взлома просто не существует.
Более того, есть довольно неплохие бесплатные решения по безопасности для wp от сторонних разработчиков, обрабатывающих общие известные стратегии проникновения. Это как бы мастхэв изначально.Можете их перечислить?
2. Что делаете с переменными? К примеру у вас есть номер телефона где его нужно отображать в разных местах шаблонов. Есть ли бд с константами?
3. Sitemap чем генерируете? Если вы переименовываете файлы в папки индексхтмл
4. Странные у вас подход к оформлению вакансий. Выходит если надо где то поменять блок местами, зп над инфой надо править все вакансии. То есть у вас каждая вакансия это шаблон. А если нужно выводить вакансии карточками внизу на главной вдобавок? Нужна бд. Пока не нашел удобного визуального редактора к json файлу который кушает pug, правлю так и перегенерирую проект.
Вам следовало ваш sqlite конвертнуть в json и продолжить размечать им вьюхи как будто у вас RoR.
Сколько у вас страниц в итоге что минута на рендер уходит?
- Не, не нужно. :-) Для подобных вещей есть всякие инстаграмы, фейсбуки, фликры и прочие файлопомойки. Но если вдруг очень захотелось, ничто не мешает обрабатывать файлы в момент сборки точно так же, как вы бы их обрабатывали в момент аплоада на бэкенде.
- Есть подключаемые файлы, переменные, миксыны. Кстати, номер телефона вместе с имейлом вынесены в такой файл, это вы верно подметили.
- JavaScript'ом, например. Или ещё чем-нибудь, как удобнее. Из makefile'а можно вызвать любую утилиту.
- Нет, не выходит. Есть шаблон. Есть контентные файлы. Есть наследование шаблонов. Есть переопределяемые блоки. Почитайте документацию pugjs.org. Если нужно на главной — не проблема. На главной уже есть карточки с кейсами портфолио, например. Задача уже решена и не вызвала трудностей.
C pug все хорошо только он требует все равно заглядывания в предыдущий файл, чтобы скопипастить все от туда. Все равно остается осадочек от необходимости минимального копипаста. Вот у вас .container не вынесен в шаблон а остался в контентном файле. У ul есть класс. Я стараюсь свести разметку в контентном файле к минимуму, к обычному html без спец классов, потому что в случае чего нужно бегать по всем файлам и искать не забыл ли где то исправить класс какой. Даже комментарии я бы удалил т.к title,description, vacancy_active понятные по названиям.
я имел ввиду, что есть вам требутся дублировать текст, те же вакансии размещать в двух местах с одним и тем же текстом? вы просто копипастите?
.container умышленно не вынесен, потому что это блок, задающий ширину, а по ходу описания вакансии может потребоваться ширину разорвать полноширинным блоком.
У ul класс тоже умышленно сделан. Никто не мешает повесить стили на .page-content ul, но мы так делать не стали.
Комментарии вам не нужны, а HR-менеджерам могут быть нужны.
Но это всё мелкие детали, которые вы можете сделать по-своему, а мы сделали по нашему, потому что нам так оказалось удобнее. И в случае чего переделать — вообще не проблема. Всё максимально тривиально.
Дублировать текст пока не понадобилось. Если понадобится, то решить тоже можно будет. Копипастить не будем, это чревато так называемыми update-аномалиями.
- Cloudinary вполне справляется с этой задачей. Бесплатного тарифа хватит за глаза и за уши.
- Статический сайт тоже имеет исходники и собирается генераторами, которые вполне поддерживают переменные.
- В популярных генераторах статики такие штуки уже давным давно сделаны другими людьми и обкатаны десятками тысяч проектов.
- Опять же, данные храниться могут в любом формате, например в yaml, а как они будут отображаться — работа шаблонов и шаблонизатора.
Посмотрите в сторону Jekyll. Очень популярное решение для статики с кучей официальных и не очень плагинов вдогонку. И вопросы отпадут сами собой.
Ребята, сорян, но мне кажется тут технологии ради технологий. Все это прекрасно, пока такие in-house решения вы не продаете клиентам.
Из WordPress легко можно генерировать статику, если нужно — есть REST API, так что рендеринг можно делать любым удобным способом (React, Vue, Angular). Ну серьезно, WP используется на миллионах сайтов разного уровня, но нет, для очередного лендинга или визитки — это не серьезно. Вы упоминали про кривой WYSIWYG: все так, в 2019 отдавать клиенту сайт с возможностью редактирования только с помощью визуального редактора и пары чекбоксов — стыдно. Для WP есть по меньшей мере 5 великолепных плагинов, которые позволяют создавать интерфейсы любой сложности. Не любите плагины — используйте родные блоки Gutenberg, введенные в версии 5. Если умеете React, то написать новый блок не проблема, или можно сделать экстенд существующего(кастомные кнопки, листинг других постов, что угодно — клиент будет только мышкой тыкать).
У меня такое ощущение, что на российском рынке разработки все что касается WordPress воспринимается исключительно негативно, даже при том, что инструментов разработки для WP сотни.
Как раз наоборот, господин radist2s говорит, что WP может в пару кликов сгенерировать вам статический контент, который не будет жрать ресурсы бэка. А когда надо, вы снова правите контент силами WP, который также снова нагенерирует кучу статики. Статику отдавать не проблема вообще любому серверу, даже очень слабому. У вас ведь основная мотивация была в том, что Бэк для отрисовки жрёт кучу ресурсов, плюс тяжело оркестрировать контентом. Так вот, WP решает все ваши проблемы.
Мы в курсе, что WP (и ряд других решений) так может. Но для нас это решение более тяжеловесное (WP тоже надо хостить где-то, хоть на локальной виртуалке) и менее поворотливое (кастомизировать WP намного сложнее). У нас уже есть гитлаб, в котором хостятся сотни других проектов и который предоставляет и UI для редактирования, и CI, и CD. И в итоге покрывает не половину нашей мотивации, как вы перечислили, а всю.
Моя защита WP была скорее направлена не как ответ вам, а просто общее замечание. По поводу Gitlab CI у нас как раз так все и работает. Деплоим проект через Trellis, в процессе сборки проекта проходятся всякие тесты и прочее. Но это тоже все не относится к делу, конечно.
Можно использовать любой из плагинов для генерации статичных HTML файлов из WP. Естественно, так работать будет только тогда, если вы пишете тему/сайт c нуля, и можете контролировать вывод и все запросы. Не важно, чем будет рендериться фронт, как я выше упоминал, через Node.js или родными средствами PHP.
Имеет ли смысл через Проксирование сохранять оригинальные файлы?
Плагины дают, зачастую, богатый функционал. Нужно понять, что WP остается на своем месте. Вот только никакие front-end части WP и плагинов рендериться не будут. Получаете json с контентом для конкретной страницы, туда же все пункты меню. Вся страница должна быть в json-представлении. Этот json вы скармливаете тому рендереру, который вам нравится, а там может быть React/Ng/Vue.
И Bootstrap с jQuery есть)
А вам фронты на удалёнку не нужны случайно?)
вторая (иногда третяя) сильнейшая политическая партия чехии свой главный и десятки региональных сайтов давно сделала статическими (jekyll). к чему все эти вордпрессы?
Перенос сайта на статику: мотивация, стоимость, работа