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

Насчет комментариев
У телеграма есть отличное решение для встраивания https://comments.app/
Если я не ошибаюсь, то это официальный способ от команды добавить их на сайт
Также быстрый и достаточно удобный: вставить один script тег и все работает
Единственное, поддерживаемая тема пока только белого цвета

Спасибо за ссылку, не знал об этом :/ Покопался в настройках и стало интересно — а можно вставлять комментарии в кастомный div? Или их расположение фиксировано — в самом низу страницы.

Можно, нужно вставить script туда где хотите увидеть подключаемый iframe.

Есть минус — по умолчанию нельзя подписаться на все комменты в своем боге.

Недавно появился, так что этого минуса больше нет

Многие с Jekyll переехали на Gohugo и у последнего уже сообщество с различными плагинами выглядит пободрее. Да и создавать новые посты там попроще. Вместо же disqus можно еще попробовать Commento. Это opensource альтернатива.

+1 за Hugo.
но все же это не совсем то, что ищет автор поста — это именно static generator.

Я сам могу сделать там все, что угодно — и тему сверстать, и перепилить что угодно, но, если честно, заниматься этим надоело. Есть в хозяйстве несколько блогов Hugo, корпоративных, хорошо, что копирайтеры пишут — сам бы давно забил.
Отличный пацанский движок например вот: git.stargrave.org/cgit.cgi/sgblog.git/tree/README (например используется для blog.stargrave.org/russian).

* Представляет ровно один бинарник (после компиляции) на Go + Git для хранения самих данных блога. Хостить можно где угодно, требуя минимум телодвижений. Конфиг ровно один Hjson файл. Для комментариев ещё один бинарник
* SGBlog даёт возможность отдельно дать ссылку на визитку
* «Минимум телодвижений и интерфейса — в идеале интерфейса CMS вообще не должно быть видно, админская панель не нужна, посты должны редактироваться, создаваться и просматриваться в одном месте»: SGBlog идеально этому удовлетворяет, так как CMS интерфейса нет вообще, никакой панели, только ваш же удобный shell+git+редактор (Vim, Emacs, whatever)
* «Полноценный WYSIWYG редактор» — это зависит от вашего редактора
* «Нормальные комментарии — возможность оставлять анонимные комментарии и авторизовываться через максимум соц. сетей для персонифицированных комментариев»: SGBlog принимает комментарии в виде email сообщений, где сам автор (сам email адрес) будет скрыт. Соцсети, правда, не поддерживает
* «Минималистичный внешний вид — я не хочу заниматься версткой и темами, подходящее оформление должно быть из коробки» — соблюдено

Плюс он может быть также одновременно и Gopher сервером для создания, в том числе, phlog-а!
git.stargrave.org/cgit.cgi/sgblog.git/tree/README
Браузеры ругаются — SEC_ERROR_UNKNOWN_ISSUER.
Иногда мне кажется, что от этой долбанной криптографии пользователям больше проблем, чем пользы, а на внедрение и обновление сертификатов потрачено на два порядка больше, чем могли бы нанести ущерба потенциальные злоумышленники…
бесплатный CloudFlare настраивается за 3 минуты. Готовые docker-контейнеры с letsencrypt тоже. Просто кто-то не озадачился.

Есть похожий на Jekyll движок для стат. сайтов — Hugo.
Для него есть фронтенды, которые позволяют постить https://gohugo.io/tools/frontends/
Мы используем netlify cms — это выглядит как кусок js в браузере, который ходит в наш гитлаб (приложение через OAuth) и позволяет контент-менеджеру редактировать статьи сайта. Мы его деплоим на тестовый и доступный только изнутри сайт, там контент-менеджер всё делает и потом это выкатывается на основную версию.

Выглядит интересно, но редактор не умеет markdown и вставлять картинки из буфера обмена.

Сорян, но вы не шарите. WordPress на минималках, на стоковой теме даст вам те возможности, которые еда ли вообще хоть одна CMS может предоставить. Редактор блоков Gutenberg с версии 5.0 является стандартным решением, переосмыслением WYSIWYG-редакторов, и написан на React, если интересно понимать вектор развития. WordPress — это как раз тот случай, когда можно поставить CMS и сразу что-то делать. Не осилили админку? Вы поди и роутер настраивать специалистов зовете.

Плюс можно поставить клиент на декстоп/телефон и вообще не заходить в админку.

Ухты, этого не застал https://wordpress.org/gutenberg/ Действительно очень хорошо, признаю. Пару лет назад, когда я пользовался вордпрессом, он был совсем плох.


UPD: Добавил примечание в статье про Wordpress.

Gutenberg по сей день весьма сырой, хотя, конечно, уже получше, чем 2-3 года назад.
Вставка картинок через буфер — на мой взгляд очень плохая идея.
Сделал я скрин страницы в PNG в 2 метра, лежит в буфере — переложить на уровень сервера обработку и ужатие? И в результате получим пнг в полметра размеров 300*300 пкс?
Нет спасибо, чем проще редакторы — тем больше говнокода они генерят и страницы весят как исходник винды.
переложить на уровень сервера обработку и ужатие?

Почему это проблема? Notion и Telegram как-то справляется.

Попробуйте как нибудь сравнит оригинальную картинку, туже картинку пропущенную через телеграмм и туже картинку пропущенную через любой оптимизатор картинок.
Могу определённо сказать, что у телеграм всегда получается вот такое, если обрабатывать, как картинку, а не как файл: JPEG, quality: 75, subsampling ON (2x2). Т.е. достаточно жёсткое сжатие (лично я ниже 92 не жму и сабсемплинг отключаю).

Ну дык надо же чтобы инструменты работали хорошо, и не работали плохо. Если я вставил картинку размером 3000х3000 в свой пост, она должна, например:


  • Залиться на сервер в этом разрешении без потерь
  • Пережаться в шесть более маленьких разрешений
  • Превратиться в тег srcset и стать responsive image
  • сделать все это быстро и с помощью самой лучшей сжималки, какая только существует на свете
  • может быть, обмазаться каким-нибудь правильным джаваскриптом, который показывает уместные для данного контекста кнопочки или галереи
wp это делает, но из-за технических ограничений (PHP) он не может пожать самой лучшей на свете сжималкой, поскольку там привязка к imageMagick.
А из-за каких таких ограничений? Для обработки изображений в PHP доступно множество альтернатив imagemagick, например libvips (php-vips).
Для интеграции таковой в wordpress, конечно, придётся написать некоторый дополнительный код, хукнувшись в генерацию превью — совсем готовых решений я не знаю.
Это очень хорошо, но libvips он же вроде как про скорость, не про сжималку. Пресс к сожалению не позволяет хуками переопределить класс ядра, отвечающий за обработку графики, если только скопипастить код из ядра и воспроизвести его поведение со своим классом.
libvips, конечно, не ориентирован именно на сжатие, но мне казалось, что он не только работает заметно эффективнее im, но и выдаёт несколько меньшие изображения при аналогичных настройках.
Я сейчас попыталась в этом убедиться, уменьшив до ряда размеров различные пёстрые (такие как фото) и относительно монотонные (скриншоты) изображения, и результаты получились не вполне однозначные:
— разница в размере пёстрых изображений, сохраняемых в JPG составила менее 1% в пользу vips;
— при сохранении монотонных изображений в JPG im выдал файл где-то на 10% меньше;
— для пёстрых PNG, напротив, результат vips меньше по размеру на 10%;
— но для монотонных PNG результат im оказался меньше на 10 и более процентов.
Вполне вероятно, что я просто не знаю каких-то тонкостей или настроек, которые позволили бы im и vips выдать другие результаты при том же качестве. Я использовала следующий код для PNG:
$img = Jcupitt\Vips\Image::thumbnail($file, $size, ['height' => $size]);
$img->writeToFile("$file-vips.png", ['strip' => true, 'compression' => 9]);

$img = new imagick($file);
$img->thumbnailImage($size, $size, true);
$img->setImageFormat('png');
$img->setOption('png:compression-level', '9');
$img->stripImage();
$img->writeImage("$file-im.png");
$img->clear();
$img->destroy();

И для JPG;
$img = Jcupitt\Vips\Image::thumbnail($file, $size, ['height' => $size]);
$img->writeToFile("$file-vips.jpg", ['strip' => true, 'Q' => 75, 'optimize-coding' => true]);

$img = new imagick($file);
$img->thumbnailImage($size, $size, true);
$img->setImageFormat('jpg');
$img->setImageCompression(imagick::COMPRESSION_JPEG);
$img->setImageCompressionQuality(75);
$img->stripImage();
$img->writeImage("$file-im.jpg");
$img->clear();
$img->destroy();


Именно для сжатия можно также попробовать использовать что-то типа pngcrush или pngoptimizercl. Для них вряд ли есть готовые расширения PHP, но, в крайнем случае, можно использовать exec для их вызова.

Касательно интеграции в wp, на сколько я знаю, можно ведь унаследоваться от WP_Image_Editor также, как это делают стандартные классы WP_Image_Editor_GD и WP_Image_Editor_Imagick, и заставить wp использовать эту реализацию через фильтр wp_image_editors.

Унаследоваться можете, а вот подсунуть ядру свою реализацию как делают хуки — нет. Можно дублировать код wp и через хуки его воспроизводить своим классом. Но это выглядит не очень красиво и требует перед обновлением wp проверять не менял ли пресс этот функционал в ядре.
Что касается теста — делаете вы его не очень корректно. Нужно сравнивать качество при одинаковом размере файла, а не настройках. Эта шкала от 0 до 100 у каждого кодировщика может быть своя, а единственная константа для сравнения — вес.

И не забудьте, что в разные форматы, типа webp, ещё нужно. Сам бы таким пользовался, но пока не нашёл
Зачем в разные? JPG у всех открывается. А сжатие webp — такое же на любителя, как и видео webm (фактически — обмен размера файла на качество).
Ну если разработчики заморачиваются с разными размерами, включая 2х, а не просто ставят одно средне-мелкое на все, но стилями его уменьшают до нужного, то и webp точно пригодится, тем более, для крупных нагруженных проектов или дорогого CDN. Ну и кроме того, из-за рекомендаций гугла (многие хотят зелёные пузомерки)).

Я хочу редактировать страницу там же где я ее читаю без настройки особого окружения и пачки плагинов для IDE.

Typora топ!
И картинки умеет вставлять и код подсвечивает и вообще всё красиво, очень похоже на Notion.
Сохраняет в md формат, который потом рендерится через Jekyll.
А какие редакторы есть для markdown? Когда искал WYSIWYG(и вставкой картинок из буфера), их ровно ноль из бесплатных. Остановился на Typora(которая не выйдет никак из beta), но там тоже подглючивает часто.

Я редактирую в vscode по нажатию ctrl + shift + v он из коробки открывает вкладку с визуальным отображением

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

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

Мои потребности не уникальны, это так или иначе нужно любому автору ведущему стэндалон блог, просто они не знают что так можно. До появления notion никто не знал что оказывается именно так должен выглядеть редактор. Пока еще все думают что им нужна CMS с админкой.

Поддерживаю! Сделать надо так, чтобы было хорошо и не было плохо. Чтобы подавляющее большинство юзеров вообще не задавалось вопросом «а где тут админка». Сложная ли это задача? Да, сложная, нужно включать голову, читать книжки по ux, общаться с юзерами, выделять целевую группу, рисовать персоны, наблюдать за юзерами аналитикой и собирать тонны статистики. Работать надо, а не только коды кодить! Ну примерно так и появляются хорошие продукты.

есть еще Blocs
все упирается в то, насколько у вас простые или сложные страницы, точнее ее разметка

Это больше как тильда и webflow. Мне нужно чтобы от момента когда я решил создать, до момента публикации проходило пару секунд. Мне даже кнопки сохранить/опубликовать не нужны, как это сделано в notion.

А есть ли редакторы с поддержкой формул? Markdown-подобного WYSIWYG много (лучше, хуже — отдельный разговор), даже у телеграма есть свой (telegra.ph). Но обычно они такие примитивные. Таблицы, формулы?


Я сейчас нахожусь в процессе раздумывания над способом хранения заметок, записей, базы знаний итп. Пришел к выводу, что LaTeX + Markdown и какой-нибудь pandoc — наше все. А без WYSIWYG проживу.

Советую очень крутой редактор Typora, меня он ещё подкупил тем, что там можно рисовать диаграммы из текста!
Notion вполне себе поддерживает формулы. И в смысле «как в гугл-таблицах» и в смысле человеческого отображения формул

Спасибо за эту историю. Уже несколько месяцев слежу, кто именно из движков победит в гонке.

У меня было еще более специфическое требование — поддержка мультиязычности. Не гугл транслейт, а именно возможность написать один и тот же пост на разных языках.
В итоге остановился на Wordpress. Бонусом прикрутил Google analytics и Statcounter.
Для плагина авторизации через сети пришлось вручную повключать api в социалках, но это ерунда, много не заняло времени.
Именно у многоязычного плагина есть косяки, а вот остальное без сучка без задоринки работает. WYSIWYG редактор там отличный, много стандартных блоков. Плагинов для любой задачи тьма, устанавливаются через магазин в два клика.

Вот что и правда прошлый век (хотя, скорее позапрошлый) — это blogger.com. По сравнению с ним livejournal — это просто мощнейшая и продвинутейшая платформа.

P.S. Ах, да, есть еще плагины для поисковой оптимизации, которые позволяют настроить превьюшки постов в поиске и соцсетях.
Оно еще существует? Здорово. Сколько лет прошло с создания, интересно.

Ещё хочется нового поколения вик, я когда-то ими на профессиональной основе занимался, но давно за отраслью не слежу. Вышло что-нибудь бодрое за последние 5-7 лет?

Есть ли что-то типа Ghost, но с поддержкой локализации из коробки? Нужно:


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

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

Поддерживаю автора, буду очень рад если такое уже есть. Сам пользуюсь Ghost, в целом все устраивает, но для локализации надо танцевать с бубном и лучший способ смапить два поста на разных языках — поместить в тело статьи прямую ссылку :(
Минус за заголовок. Что значит «пацанский»? Ассоциации с 90-х довольно таки противоречивые.

Я для себя открыл Ghost несколько лет назад. Это идеальный движок как с точки зрения заполнения контента, так и с точки зрения создания шаблона — можно реально за день, при готовом HTML запилить себе персональный сайт с портфолио и блогом. С появлением API он еще стал полноценной Headless cms. Для написания я использую Quiver, так как статьи редко пишу в один присест, поэтому все снипиты, хаки и статьи в Quiver, потом оттуда копирую в Ghost. Единственный минус — картинки должны быть на хостинге, так как при копировании прописываются локальные пути.

Поясните, пожалуйста, а то я никак не врублюсь. У меня есть Github-репозиторий, где лежит полностью статический веб-сайт, скомпилированный через Hugo. Я правлю Markdown-файлы, запускаю exe-шник или просто бинарник Hugo, он собирает сайт, я делаю коммит, Github Pages обновляет отображение "сайта".


Можно ли то же самое сделать с Ghost CMS или Netlify? Т.е. без необходимости тащить какой-либо бэкэнд вообще. Помимо Github Pages есть ещё хостинг (не VDS), куда я тоже заливаю всякую статику. Доступа к бэкенду нет, только «фронт». Что, на Ваш взгляд, подойдёт в качестве Headless CMS в таких условиях?

Через Netlify вы можете подключить github репозиторий, с ghost нет.

Спасибо за ответ!
Мне не нравится сама идея, что Netlify на себя берёт роль механизма авторизации для своей «админки». С одной стороны, self-hosted, а с другой – уже не очень. Если бы не этот момент, то с виду всё идеально.

Есть интересное двигло GRAV. Как отдельно движок, так и готовые сборки + множество дополнений. Неперегруженный актуальный валидный код. Обновления постоянные.
Чтобы черкануть пару строк в каком-нибудь Wordpress, нужно слишком много телодвижений.

Я попробовал очень много движков и большинство из них выглядят устаревшими на несколько десятков лет. Главная проблема — переусложненный админский интерфейс и отсутствие WYSIWYG-редактора.

Не могли бы вы пояснить, что имеете ввиду под «телодвижениями» и «переусложненностью админского интерфейса»?
Сдается мне, автор несколько предвзят по отношению к WordPress и сильно его недооценивает. И даже возникло ощущение, что автор хочет «найти то, незнамо что».
Я ни в коем случае не утверждаю, что автору нужно выбрать WP и что это лучшее решение (тем более что Ghost выглядит как действительно достойная альтернатива, очень хочу «потыкать» на досуге). Просто хотелось бы заметить, что WP очень многое «магёт», не гутенбергом единым — можно найти плагин практически на любой случай жизни. Хотя это опять же добавляет упомянутых автором лишних «телодвижений», но я настоятельно рекомендую обратить внимание на эту особенность CMS, порой можно найти просто невероятное решение для своих задач. Сила WP — в огромном комьюнити. У меня большие надежды на будущее развитие продукта, я верю, что он будет перерождаться, избавляться от существующих недостатков и предстанет в совершенно ином обличии.

И да, идеальных CMS не существует:
Я уже было решил, что нашел свой идеальный движок, пока не стал разбираться с оформлением внешнего вида сайта. Оказалось, что дефолтная тема не предполагает никаких настроек, как мы все привыкли видеть в том же Wordpress.

Вопрос со стороны вообще: несколько лет назад на слуху были новости вида «в Wordpress найдена очередная критическая уязвимость, под угрозой 100500 сайтов».
Как сейчас обстоят дела у WP с безопасностью?

На моём скромном опыте не приходилось сталкиваться с уязвимостями собственно движка WP. А вот уязвимости популярных плагинов время от времени всплывают, к сожалению. Одно из последних запомнившихся — была найдена уязвимость в плагине импорта демо-контента одной популярной темы (писали, что на этой теме работают более 200 тыс сайтов), благодаря чему были массово взломаны сайты. Особенно много проблем возникло с этим у веб-студий, которые штампуют конвеерные «какашечные» сайтики на одной теме — множество сайтов висят на так называемом обслуживании, в связи с тем этим студиям пришлось в срочном порядке восстанавливать из бэкапов все сайты и удалять плагин.

Обратная сторона любой популярной CMS — большое комьюнити дает как множество плюшек, так и множество проблем.
У самого движка неплохо, критические баги/дыры случаются довольно редко. Слабое место WordPress — это темы и плагины, особенно премиум (коммерческие). В общих чертах с картиной можно ознакомиться тут. В итоге сайты под управлением WordPress ломаются пачками и на регулярной основе.
О чём идёт речь? Как человеку, не крутившему в руках этот движок, мне было бы интересно это узнать. Полагаю, что не мне одному :)
Я особо тоже его не крутил, но… В конфигурационном файле есть строчка
$_config['broadcast_url'] = 'httр://blogengine.ru/blogs/@notify';

которая при публикации новых записей в пользовательских блогах принимает вид httр://blogenginе.ru/blogs/@notify?src=https://blog_domain.tld/all/post_name/json/ (User-Agent: E2 (vXXXX; Aegea), где XXXX — версия движка).
Иначе говоря, пингует blogengine.ru о новых записях во всех блогах под управлением «Эгеи», которые, как я понимаю, Илья Б. может выборочно добавлять в фид на сайте.

Со слов автора:
Когда вы публикуете что-то новое, она стучит на мой сервер и говорит: «смотри, у меня кое-что новое». В этот момент она сообщает только урл заметки. После этого «Блоги» сами идут по этому урлу и забирают оттуда текст и всё остальное. Если этот урл не откроется снаружи, записи никуда и не попадут.

Из других нюансов: права 0777 на новые/создаваемые файлы, чувствительность к конфигурации веб-сервера (от раскрытия информации до полного управления блогом и загрузки файлов *.php), XSS, доступ к бэкапам БД (хотя эти бэкапы не содержат каких-то логинов/паролей), лог-файлу.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

27 июля 2015 г.

Местоположение

Россия

Сайт

ruvds.com

Численность

11–30 человек

Дата регистрации

18 марта 2016