Ищу Candidat CMS

Неужели зайти в админку любой CMS и добавить статью через форму сложнее, чем писать что то в файл, потом закидывать его по ФТП? Эти файловые CMS были разработаны в прошлом веке, когда MYSQL был не на всех хостингах. Не перестаю удивляться тупостью людей.

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

2. FTP - только у тех, кто не умеет иначе (или как у меня лично для себя - не умножает сущности сверх необходимого). У сапиенсов (к коим вы, любезный, можете быть причислены с трудом, т.к. вид "cercopithecus lamer ordinarius" отделяется последними исследованиями биологов и этологов от вида homo sapiens sapiens) давно придуманы абстракции и методы, прячущие ненужные технические детали - WebDAV там, с монтированием вебдавов локально, SSHFS, etc. У меня сейчас, к примеру, в неторопливой разработке для Grav - процесс чисто десктопной работы с контентом (да, флатфайлового с Маркдауном) на базе визивигового MD-редактора (пока выбор не окончательный - то ли MarkdownPad, то ли MarkText) и Гита (Гитхаба с его вебхуками), где процесс в оконцовке вообще будет

* Открыть локальный файл

* Отредактировать

* Сохранить

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

Если немного поинтересоваться вопросом, то для тебя, чудо, будет surprise - большинство (если не все из активно живущих сейчас Flatfile CMS) были начаты разработкой в десятые годы, когда хостинги с MYSQL уже давно не экзотика, а фактически "стандарт услуги". И мотивация создателей и ЦА чуть более другая, чем "CMS для нищебродов" (о сугубой ошибочности такого целеполагания я писал в первом своем посте, или втором, в этом топике), то что вы, милсдарь, ее не видите - это исключительно проблемы ваши и вашего кругозора

Аналогично - не перестаю удивляться (кому/чему?) тупости агрессивных ламеров, не выучивших даже родного языка, но "имеющих мнение" и уверенных, что именно их мнение единственно верное. Как правильно отмечал Aisamiery, если не ошибаюсь - эффект Даннинга-Крюгера в полный рост

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

Все может делаться через админ-панель, если быть уж совсем точным: в Grav, скажем, административный интерфейс это такой же плагин, как и остальные, и его даже может не быть. В прочих Markdown-CMS примерно так же: хочешь не разрешать лишнего - научи класть правильные файлы в правильное место, и все

---------- Добавлено 07.01.2020 в 14:23 ----------

Вдогонку - расскажи это суровым математикам/химикам, у которых нет проблем (даже ручками) записать их суровые многоэтажности правильно даже просто руками в Tex|LaTex, а в этих ваших HTML-визифигах их ожидает литовский праздник "обломайтис".

Или автору статьи, у которого микс из нумерованных-ненумерованных списков на несколько параграфов каждый с 4-5 уровнями вложенности (и стиль оформления и непрерывность нумерации он хочет сохранить "как у меня в Word")… ох и намаялся уже я с этим в ВПшном Гутере, а потом и в классике

Мне кажется что редакторы в массовых CMS и не должны это уметь.

Зачастую даже в серьёзных научных онлайн-журналах в этих случаях используют тупо jpeg сканы pdf-ок

Вы ошибаетесь, с появлением ssd на серверах, проблемы работы с диском решились сами собой. Создать подключение к бд это уже тяжелая и для многих сайтов бесполезная операция. Для чего вам бд если вы там просто храните статьи и настройки? А так то бд требует ресурсы, там есть ограничения и ещё это самое первое бутылочное горлышко с которым сталкивается сайт. Например тот же ВП что бы работал быстрее, ставят модули кэширования, которые результаты выборки с бд складывают в файл и далее забирают эти данные с файла.

В основном оперативку. А она сейчас недорогая - то что в тарифах у хостеров это другой вопрос.

Смотрите платформа Супермикро :

1270v6, 64 gb ram, hw raid котроллер MegaRaid, 4 intel 240 gb ssd (ставим в raid 10), 2 10gbase-t - стоит 175.000 руб.

Разумеется думая о надёжности берём две штуки.

Соединяем по 10-гигабитной сети и зеркалируем содержимое. Использовать дублирование будем через dns round-robin.

Прослужат они 5 лет.

Colocation 2-ух 1U с IP и каналом обойдётся если оплатить сразу 5 лет в 180.000 руб.

Итого: (175.000+175.000+180.000)/60 = 8.833 рублей в месяц.

Сколько "обычных" сайтов какого-нибудь WP с базами данных потянет такой конфиг ? И о надёжности мы подумали и о быстродействии (два сервера же).

Так что наличие БД - никому ничем не мешает.

P.S.

А ещё бонус - через 5 лет эти два сервера можно будет поменять на ящик хорошего пива :)

Що занадто - то не здраво... Или "Co za dużo, to nie zdrowo!" от шляхетского паньства

RDMS нужна только тогда, когда нужна

Хорошо, убедили, отличная штука ФФ системы. А что можно реализовать на них еще, кроме новостника? Например магазин со сложным составным товаром? Это будет практичнее чем использовать БД?

---------- Добавлено 07.01.2020 в 13:47 ----------

Странно, где-то я тут читал что гит не торт...

То есть ты изобретаешь CI/CD, Jenkins?

Вы правы - я же просто к тому что мифы о прожорливости БД если переводить в деньги сильно преувеличены.