Как стать автором
Обновить

Комментарии 46

хороший кейс, написано интересно.


спасибо!

Я тоже думал об этом)
Достаточно появлению одного малейшего требования взаимодействия с бекендом и статика уже не поможет. Банально, говоря, например, только про раздел вакансии, ведь, например, это может захотеться уже завтра: кнопка (форма) отправить резюме, «оставьте емейл и мы перезвоним», лайки, просмотры.
Это решение не масштабируемое, вы загнали себя в достаточно узкие рамки, выход из которых будет стоить вам полного рефакторинга структуры проекта.
Если хотелось готового из коробки решения — есть wordpress с его историей редактирования. В вашем же случае, как по мне, было проще создать дополнительную таблицу с историей редактирования и кастомизировать WYSIWYG (это обычно не так сложно, BBCode+regex на бекенде), чтобы облегчить жизнь редакторам.
В прочем, решение имеет право на жизнь, если вы, переходя на статику, просчитали вышеописанный момент и однозначно и на века, решили, что бекенд не нужен :)

Если вдруг понадобится какое-нибудь взаимодействие, то есть, например, лямбды. Даже в статический сайт можно добавить динамику, как например staticman умеет добавлять комментарии, не говоря уже о всяких Disqus и Commento.
Но если вдруг понядобится что-то более узкое, то можно взять и сделать виджет на ReactJS, который будет рендерить что-то с маленького и легкого бека.
Зато статический сайт это действительно дешево (платишь только за домен), быстро (время уходит только на передачу контента) и надежно (GitHub с большим успехом переживет хабраэффект, чем любой купленный хостинг).
Эти плюсы чаще всего с лихвой покрывают все неудобства.

Несомненно, мы об этом подумали. Помимо того, что ответил вам Виталий vtvz_ru, хочу заметить, что на сайте уже есть формы подписки на уведомления о наших конференциях и школах. Они используют Google Forms на бэкенде, что тоже не добавляет дополнительной стоимости, потому что у нас уже есть корпоративный G Suite.
Вместе в вордпрессом Компания получит пачку уязвимостей, возможно взломов и возможность все это лечить, фиксить и обновлять.

А формы можно отправлять через гуглформс
Можно пачку паследних уязвимостей wp ядра? Плагинов меньше юзать надо. )
Можно пачку паследних уязвимостей wp ядра?

Выбирайте
Последние два года по Code Execution — все связаны с авторизированными пользователями. 17 год уязвимость не ядра, а через сторонние темы или плагины. 16 год пусто. Дальше не проверял. Не плохо для системы, с миллионными копиями.
Заплатки безопасности устанавливаются без участия пользователя.

Более того, есть довольно неплохие бесплатные решения по безопасности для wp от сторонних разработчиков, обрабатывающих общие известные стратегии проникновения. Это как бы мастхэв изначально.

Не идеально, но и не сказать что прям ужас ужас решето.

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


Со статикой проблемы взлома просто не существует.

Этого не лишен ни один программный продукт. Чем популярнее сайт тем больше он уходит с общих решений. Непопулярные сайты рискуют схватить от китайских ботов.Как я писал, общие стратегии проникновения закрывают решения типа wordfence. Никто не говорит, что статика плохо. Взлом сайта компании не самое страшное, что может случиться. Не все компании айтишные и воспринимают это как удар по репутации. Тем более мы говорим о вероятности, а не о том что wordpress ломают налево и направо.
Более того, есть довольно неплохие бесплатные решения по безопасности для wp от сторонних разработчиков, обрабатывающих общие известные стратегии проникновения. Это как бы мастхэв изначально.
Можете их перечислить?
Да каммон, поднимаешь свою динамику где хочешь и взаимодействуешь по rest из статики.
Не очень понимаю по картинке, в чём ошибка. Поясните, пожалуйста.
… подхватываем вашегои приложения
Так и задумано. Тут эмоджи несёт смысловую нагрузку. Модно и молодёжно. :-) Тем не менее, спасибо за бдительность.
отстаю от моды, старею )
1. Что делать с картинками? Нужно выложить корпоратив галлереей. Фотки 4000px по ширине 6мб каждая. Где ресайзите оптимизируете и как делаете превьюшки?
2. Что делаете с переменными? К примеру у вас есть номер телефона где его нужно отображать в разных местах шаблонов. Есть ли бд с константами?
3. Sitemap чем генерируете? Если вы переименовываете файлы в папки индексхтмл
4. Странные у вас подход к оформлению вакансий. Выходит если надо где то поменять блок местами, зп над инфой надо править все вакансии. То есть у вас каждая вакансия это шаблон. А если нужно выводить вакансии карточками внизу на главной вдобавок? Нужна бд. Пока не нашел удобного визуального редактора к json файлу который кушает pug, правлю так и перегенерирую проект.
Вам следовало ваш sqlite конвертнуть в json и продолжить размечать им вьюхи как будто у вас RoR.
Gulp-data, не заметил. Но все равно как то у вас сложнее чем иметь json объект.

Сколько у вас страниц в итоге что минута на рендер уходит?
  1. Не, не нужно. :-) Для подобных вещей есть всякие инстаграмы, фейсбуки, фликры и прочие файлопомойки. Но если вдруг очень захотелось, ничто не мешает обрабатывать файлы в момент сборки точно так же, как вы бы их обрабатывали в момент аплоада на бэкенде.
  2. Есть подключаемые файлы, переменные, миксыны. Кстати, номер телефона вместе с имейлом вынесены в такой файл, это вы верно подметили.
  3. JavaScript'ом, например. Или ещё чем-нибудь, как удобнее. Из makefile'а можно вызвать любую утилиту.
  4. Нет, не выходит. Есть шаблон. Есть контентные файлы. Есть наследование шаблонов. Есть переопределяемые блоки. Почитайте документацию pugjs.org. Если нужно на главной — не проблема. На главной уже есть карточки с кейсами портфолио, например. Задача уже решена и не вызвала трудностей.
4. Ага, открыл полный скриншот. С порядком проблем не будет.
C pug все хорошо только он требует все равно заглядывания в предыдущий файл, чтобы скопипастить все от туда. Все равно остается осадочек от необходимости минимального копипаста. Вот у вас .container не вынесен в шаблон а остался в контентном файле. У ul есть класс. Я стараюсь свести разметку в контентном файле к минимуму, к обычному html без спец классов, потому что в случае чего нужно бегать по всем файлам и искать не забыл ли где то исправить класс какой. Даже комментарии я бы удалил т.к title,description, vacancy_active понятные по названиям.

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

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


У ul класс тоже умышленно сделан. Никто не мешает повесить стили на .page-content ul, но мы так делать не стали.


Комментарии вам не нужны, а HR-менеджерам могут быть нужны.


Но это всё мелкие детали, которые вы можете сделать по-своему, а мы сделали по нашему, потому что нам так оказалось удобнее. И в случае чего переделать — вообще не проблема. Всё максимально тривиально.


Дублировать текст пока не понадобилось. Если понадобится, то решить тоже можно будет. Копипастить не будем, это чревато так называемыми update-аномалиями.

  1. Cloudinary вполне справляется с этой задачей. Бесплатного тарифа хватит за глаза и за уши.
  2. Статический сайт тоже имеет исходники и собирается генераторами, которые вполне поддерживают переменные.
  3. В популярных генераторах статики такие штуки уже давным давно сделаны другими людьми и обкатаны десятками тысяч проектов.
  4. Опять же, данные храниться могут в любом формате, например в yaml, а как они будут отображаться — работа шаблонов и шаблонизатора.

Посмотрите в сторону Jekyll. Очень популярное решение для статики с кучей официальных и не очень плагинов вдогонку. И вопросы отпадут сами собой.

да это ясно, яж интересовался как у них.
а чем JAMStack не подошел?

Тем что он тут не нужен совсем, например.

Ребят, вам что жалко 750р/мес?)
Мы рассматривали несколько движков и отвергли разные по разным причинам: где-то были проблемы с нашей двуязычностью, где-то было не сделать (либо слишком неочевидно, как) то, что нам требовалось. Многие движки заточены исключительно под блоги. В общем, потратив некоторое время на ознакомление с готовыми решениями, пришли к тому, что быстрее сделать своё, благо кода там две сотни строк, из них треть — gulp'овый boilerplate.
НЛО прилетело и опубликовало эту надпись здесь

Ребята, сорян, но мне кажется тут технологии ради технологий. Все это прекрасно, пока такие in-house решения вы не продаете клиентам.
Из WordPress легко можно генерировать статику, если нужно — есть REST API, так что рендеринг можно делать любым удобным способом (React, Vue, Angular). Ну серьезно, WP используется на миллионах сайтов разного уровня, но нет, для очередного лендинга или визитки — это не серьезно. Вы упоминали про кривой WYSIWYG: все так, в 2019 отдавать клиенту сайт с возможностью редактирования только с помощью визуального редактора и пары чекбоксов — стыдно. Для WP есть по меньшей мере 5 великолепных плагинов, которые позволяют создавать интерфейсы любой сложности. Не любите плагины — используйте родные блоки Gutenberg, введенные в версии 5. Если умеете React, то написать новый блок не проблема, или можно сделать экстенд существующего(кастомные кнопки, листинг других постов, что угодно — клиент будет только мышкой тыкать).
У меня такое ощущение, что на российском рынке разработки все что касается WordPress воспринимается исключительно негативно, даже при том, что инструментов разработки для WP сотни.

Всё это прекрасно, только коммент не имеет отношения к посту. В посте нет ни слова про WordPress, так что не понятно, с чего вдруг вы пишете про негатив к нему. Алсо, в посте нет про продажу клиентам. Если бы вы прочитали заключение, то увидели, что речь идёт про сайты-визитки и прочие маркетинговые лендинги внутри IT-компаний.

Как раз наоборот, господин radist2s говорит, что WP может в пару кликов сгенерировать вам статический контент, который не будет жрать ресурсы бэка. А когда надо, вы снова правите контент силами WP, который также снова нагенерирует кучу статики. Статику отдавать не проблема вообще любому серверу, даже очень слабому. У вас ведь основная мотивация была в том, что Бэк для отрисовки жрёт кучу ресурсов, плюс тяжело оркестрировать контентом. Так вот, WP решает все ваши проблемы.

Я не спорю с господином/госпожой radist2s, что 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.

Прикол, чё. Все идут в сторону React, GraphQL, а пацаны взяли и перешли на статику 90-х годов, красавчики)
И Bootstrap с jQuery есть)
А вам фронты на удалёнку не нужны случайно?)
не вижу противоречий. О переходе на статику еще не одна статья будет, поверьте. SSR сам толкает к этому, тут Gatsby.js и другие есть

вторая (иногда третяя) сильнейшая политическая партия чехии свой главный и десятки региональных сайтов давно сделала статическими (jekyll). к чему все эти вордпрессы?


https://www.pirati.cz/

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