Думаю вот переделать сайт с wordpress на astro.
Это такой относительно новый static site generator по сути. База мне не нужна.
Интерактивности типа комментариев сейчас легко делаются по-другому.
Вроде выглядит разумно. Для VS Code есть почти что полноценная CMS поверх в виде расширения VS Code.
Страницы можно писать на markdown, typescript, интеграция с любыми компонентами (react/vue/svelte что угодно) из коробки.
Типа next (возможность серверного и клиентского рендеринга), но мне показался гораздо проще, и не привязан к react, чистый markdown.
Тоже устал от Wordpress. Все время надо следить чтобы вовремя обновлялся. И контролировать, чтобы ничего не сломалось после обновления, а это регулярно происходит. И все время риск, что через какую-нибудь уязвимость сломают сайт, у нас ecommerce — взлом означает катастрофу.
Может есть другие решения, типа статическая генерация страниц из Wordpress? Но не вручную, а простое готовое решение.
Здравствуйте, PeterOne, Вы писали:
PO>Тоже устал от Wordpress. Все время надо следить чтобы вовремя обновлялся. И контролировать, чтобы ничего не сломалось после обновления, а это регулярно происходит. И все время риск, что через какую-нибудь уязвимость сломают сайт, у нас ecommerce — взлом означает катастрофу.
PO>Может есть другие решения, типа статическая генерация страниц из Wordpress? Но не вручную, а простое готовое решение.
У меня в ВордПресс внутри маркдаун уже давно, все новые страницы делаю только на нем.
Поэтому и думаю про astro, там вообще один маркдаун, плюс конфиг на json (categories, tags, и т.п.).
Мета-информация в самом же маркдаун (в шапке), типа так
Ну тяжёлые страницы на wp, нет там на сайте ничего зачем эта тяжесть была бы нужна.
Всякие оптимайзеры типа autooptimize или litespeed лечат симптомы а не болезнь, привнося ещё свои проблемы.
Здравствуйте, PeterOne, Вы писали:
PO>Может есть другие решения, типа статическая генерация страниц из Wordpress? Но не вручную, а простое готовое решение.
настроил полностраничное кеширование на уровне nginx, вообще без обращения к php
админку закрыл паролем на уровне nginx
Здравствуйте, bnk, Вы писали:
bnk>Думаю вот переделать сайт с wordpress на astro. bnk>Это такой относительно новый static site generator по сути.
Если смотрите в эту сторону, советую не использовать именно Astro. На сегодняшний день, лучше всего работают решения построенные поверх полноценных Shadow DOM технологий (React, Vue и пр.). Из-за минималистичности Astro сайты построенные на его основе очень часто "фликают" и "мигают", что портит впечатление от использования таких сайтов.
Таким образом, утверждения о минимиалистичности Astro очень сомнительны. С одной стороны, в нём и правда меньше кода, чем в том же React, но с другой стороны, из-за отсутствия этого кода страницам часто приходится перегружаться полностью, что по факту только сильнее нагружает машину пользователя и вызывает нежелательные артифакты перерисовки элементов страницы, которых могло бы и не быть. Это очень заметно при сравнении приведенных выше ссылок.
Здравствуйте, Aquilaware, Вы писали:
bnk>>Думаю вот переделать сайт с wordpress на astro. bnk>>Это такой относительно новый static site generator по сути.
A>Если смотрите в эту сторону, советую не использовать именно Astro. На сегодняшний день, лучше всего работают решения построенные поверх полноценных Shadow DOM технологий (React, Vue и пр.). Из-за минималистичности Astro сайты построенные на его основе очень часто "фликают" и "мигают", что портит впечатление от использования таких сайтов.
Понятно, спасибо за инфу. Не очень понял почему сравнивается react и astro?
Т.е. astro же только обертку генерирует (страницы на сервере), она и не должна клинентский жаваскпит делать, насколько я пониамю?
То есть, клиентские библиотеки или компоненты (тот же react) могут быть вставлены в страницу astro, как "содержимое".
Почему сравнение с реакт? Если уж сравнивать, наверное скорее с next?
Я рассматриваю как замену wordpress (php). Клиентскую часть оставляем за скобками
То есть, это не должен быть конструктор "сделай сам", скорее полноценная CMS.
Я ожидаю что фичи WP (категории, тэги, иерархия и т.п.) будут в какрм-то виде из коробки.
Но без тормозов и монстроузности, и чтобы можно было грабить корованы содержимое писать на markdown
Здравствуйте, bnk, Вы писали:
bnk>Т.е. astro же только обертку генерирует (страницы на сервере), она и не должна клинентский жаваскпит делать, насколько я пониамю?
В этом и есть суть проблемы с отрисовкой страниц в Astro. Поскольку у него нет централизированного управления HTML DOM, получается рак-лебедь-щука. Большинство же прочих подобных систем работают по-другому: в основе центральное управление DOM на основе React/Vue/..., что исключает всякие визуальные побочные эффекты при смене страниц и состояния.
Разницы при использовании практически нет: и там и там будут markdown файлы, но есть разница в качестве сгенерированного сайта. C Astro выше вероятность того, что оно будет низкое из-за слишком децентрализированной архитектуры.
Здравствуйте, Aquilaware, Вы писали:
bnk>>Т.е. astro же только обертку генерирует (страницы на сервере), она и не должна клинентский жаваскпит делать, насколько я пониамю?
A>В этом и есть суть проблемы с отрисовкой страниц в Astro. Поскольку у него нет централизированного управления HTML DOM, получается рак-лебедь-щука. Большинство же прочих подобных систем работают по-другому: в основе центральное управление DOM на основе React/Vue/..., что исключает всякие визуальные побочные эффекты при смене страниц и состояния.
Ну я же говорю, это про сервер. Внутри для интерактивности можно хоть реакт хоть что использовать?
A>Разницы при использовании практически нет: и там и там будут markdown файлы, но есть разница в качестве сгенерированного сайта. C Astro выше вероятность того, что оно будет низкое из-за слишком децентрализированной архитектуры.
А где ещё маркдаун файлы как основа контента?
То что ты перечисляешь это библиотеки клиентские, я скорее про генераторы статики. Типа Hugo, Jekyll?
Здравствуйте, Aquilaware, Вы писали:
A>На сегодняшний день, лучше всего работают решения построенные поверх полноценных Shadow DOM технологий (React, Vue и пр.)
Там с SEO бы не запутаться. Поисковики всё это рендерить или не умеют (Yandex), или умеют плохо (Google).
Server Side Rendering это отдельная проблема, которая может решаться очень непросто. Нужно это учитывать.
Лично я использую React (без SSR) только для админки, а на самом сайте строго генерация на сервере.
Здравствуйте, bnk, Вы писали:
bnk>Ну я же говорю, это про сервер.
HTML DOM — это исключительно про клиент, никак не про сервер. На сервере это начинает фигурировать только в процессе так называемой дегидрации, т.е. когда генератор сайта в процессе построения временно запускает все компоненты на странице и захватывает состояние страницы целиком чтобы записать его в статический .html файл. Но на этом этапе как раз не суть важно как этот HTML формируется: руками, React'ом или еще чем-то.
Значимая важность способа работы с DOM возникает только на клиенте. Это происходит тогда, когда страница регидрируется, т.е. когда статический HTML загружен и запускается скрипт который "оживляет" предварительно "засушенную" страницу. В этот момент появляется дополнительные возможности: интерактивность, продвинутые элементы управления, поиск по сайту, и, например, бесшовное переключение страниц. Вот Astro как раз и не умеет делать это бесшовное переключение страниц — в нем это происходит по старинке с помощью загрузки нового .html файла. Что ведет к потере состояния, повторению процесса регидрации и визуальным вспышкам и фликам. Плюс это тратит время процессора клиента на повторение уже сделанной работы, которое могло бы и не тратиться.
Таким образом, с точки зрения статического контента разницы в подходах особой нет, но есть разница с точки зрения интерактивности и эффективности её работы на клиенте.
bnk>А где ещё маркдаун файлы как основа контента?
Здравствуйте, sharez, Вы писали:
S>Там с SEO бы не запутаться. Поисковики всё это рендерить или не умеют (Yandex), или умеют плохо (Google).
Эта проблема уже несколько лет как решена с помощью пререндеринга HTML с последующей его регидрацией скриптами на клиенте. Такой режим работы называется SSG (Static Site Generation), не путать с SSR (Server-Side Rendering). SSG на выходе делает статические HTML файлы. Для поисковика получается такой же HTML с готовым к употреблению содержимым, как и любой другой статический HTML. Скрипты и прочая продвинутая логика идут бонусом, но они не обязательны для доступа к содержимому страницы. Такие сайты прекрасно смотрятся браузерами с отключенным JavaScript. Что-то интерактивное, естественно, не будет работать, но читаемое содержимое полностью доступно.
Здравствуйте, bnk, Вы писали:
bnk>Думаю вот переделать сайт с wordpress на astro.
Решил попробовать ("потыкать палочкой"), как оно. Первое впечатление — нормально
Круто что поддерживается "бесшовная" интеграция фреймворков, т.е. можно использовать react там или vue или svelte, сделать на нем компонент, и потом использовать его прямо из markdown.
Не надо конфигурировать webpack или еще какую-нибудь хрень, чтобы использовать React или Typescript например, т.е. прямо из MDX файла
Все экспортируется в статику (т.е. никакого сервера), при первой загрузке получаем статический сайт без жаваскрипт, скрипты подгружаются потом.
Вот такое например как ниже пример я не знаю где еще можно сделать? Я отстал от жизни, или это все же новость?
Прямо вау-эффект для меня
page.mdx
import { ExtractImages } from '../components/ExtractImages'; // <--- это вообще-то компонент React, интерактивный!
import Footer from "./footer.md"; // <--- a вот это обычный markdown файл
# Media Extraction Tool
We value your privacy.
Your files are securely processed on our servers and are not stored after processing.
Please report issues to our [GitHub Issue Tracker](https://somewhere.com)
<ExtractImages client:load />
<Footer />
Здравствуйте, bnk, Вы писали:
bnk>Прямо вау-эффект для меня
Когда я начал использовать эту группу технологий (Jamstack) на практике несколько лет назад, у меня тоже был серьезный вау-эффект. Даже не сколько от возможностей .mdx или shadow DOM, сколько от отсутствия состояния на сервере.
В классическом веб-сайте всегда есть мешанина из HTML и кода, который его генерирует, плюс всё это помножено на базу данных. Так вот, эта БД является большой болью, поскольку само её наличие подразумевает наличие изменяемого состояния. В Jamstack же приложениях изменямого состояния нет по определению — весь сайт запечатлён в файлах, которые не могут изменятся на сервере после деполймента. Если нужно изменение — оно вносится в исходный код. Если нужна интерактивность — используются скриптовые веб-компоненты. Если нужна интерактивность с вычиткой\сохранением изменяемого состояния — используются API отдельностоящих веб-сервисов.
Это значительно упрощают архитектуру веб-сайта. Теперь не нужно иметь сумасшедшую связку всего на свете под названием веб-сайт, достаточно только сделать его UI часть по Jamstack технологии. Все остальные плюшки добавляются уже через компоненты и API, нередко готовые. Затем такой сайт деплоится на Netlify вызовом одной команды... сказка. По сравнению со старым подходом когда на текущее состояние сайта страшно было дыхнуть абы чего не сломалось.
Здравствуйте, Aquilaware, Вы писали:
A>Это значительно упрощают архитектуру веб-сайта. Теперь не нужно иметь сумасшедшую связку всего на свете под названием веб-сайт, достаточно только сделать его UI часть по Jamstack технологии. Все остальные плюшки добавляются уже через компоненты и API, нередко готовые. Затем такой сайт деплоится на Netlify вызовом одной команды... сказка. По сравнению со старым подходом когда на текущее состояние сайта страшно было дыхнуть абы чего не сломалось.
Еще оно быстрое. Реально быстрое — 100/100 google pagespeed, LCP 350 мс
Сборка сайта не 15 минут (привет моему прошлому проекту с webpack и иже с ним), а секунды. В общем пока впечатление сугубо положительное
Hugo это вроде как предыдущее "поколение" генераторов?
Нет поддержки компонентов, то есть (есть "шорткоды" по типу WP, но это не то — по сути каждый "блок" будет грузить весь реакт или что там у него внутри)
Там еще какие-то шаблоны странные на GO?
Еще посмотрел на gatsby — минус у него webpack, тормоза. И только реакт для компонентов, без вариантов.
Здравствуйте, bnk, Вы писали:
bnk>Это такой относительно новый static site generator по сути. База мне не нужна.
Это ж весь текущий контент вручную перелопатить придется Или как-то можно автоматизировать?
Я тоже про такие генераторы много думаю в последнее время. Например, я для сайта когда-то купил тему. Еще у меня есть блог на вордпрессе, и у него совсем другая тема (бесплатная), потому что ту покупную тему надо как-то вручную конвертировать для вордпресса (с ходу это у меня не получилось).
Еще вот интересно, если контент сайта остается прежним, а дизайн резко меняется, это не является каким-то плохим сигналом для гугла?
Здравствуйте, Unhandled_Exception, Вы писали:
U_E>Еще вот интересно, если контент сайта остается прежним, а дизайн резко меняется, это не является каким-то плохим сигналом для гугла?
Обычно нет, кроме случаев когда значительно проседает производительность новых страниц. А с покупными темами это, увы, не редкость — большинство из них очень-очень медленные, что может вызвать гарантированную потерю позиций в поисковой выдаче. Это подтверждено практикой, в том числе и личной.
Поэтому страницы должны оставаться быстрыми. Например, если брать инструмент https://pagespeed.web.dev/, то параметр Performance для Desktop должен быть > 90, иначе могут быть применены пенальти.
Здравствуйте, Aquilaware, Вы писали:
A>Обычно нет, кроме случаев когда значительно проседает производительность новых страниц. А с покупными темами это, увы, не редкость — большинство из них очень-очень медленные,
Как тогда быть, если хочется, чтобы сайт выглядел приличным? Когда-то давно я заказывал дизайн, потом перешел на покупные темы.
A>Поэтому страницы должны оставаться быстрыми. Например, если брать инструмент https://pagespeed.web.dev/, то параметр Performance для Desktop должен быть > 90, иначе могут быть применены пенальти.
Попробовал несколько страниц с разных своих сайтов, нигде до 90 не дотянул: 85, 86, 87 Хуже всего у страницы с документацией (генерю с помощью docfx)
Или как-то можно автоматизировать?
