До корисних плагінів Obsidian я б додав Share Note docs.note.sx, як засіб для того, щоби ділитися примітками, або іншою відкритою інформацією. Потужний засіб його використання - можливість розгортання на своєму приватному сервері.

Існує ще Quartz з quartz.jzhao.хyz для ієрархічної публікації, який загалом наводить на крамолу, що для статичних сайтів html стане не потрібен взагалі. CSS+markdown копають чималу яму, глибину якої поки не знає ніхто. Практично все, що потрібно для організації і ведення документації там є.

Сделаю опрос в канале. Если большинство скажет да, то включу.

Не хочешь включить обсуждения /комментарии в тг?

Wordpress, при всей его тормознутости, сравнительно несложно приготовить в нормальный вид, без сотен запросов к БД. Для это я добавляю дополнительные таблички в БД (как правило, это связывание записи с полями характеристик, картинками и uri), и с помошью хуков вношу/обновляю в них нужные данные. Естественно, никаких WooCommerce, CF7, плагинов галлерей и т.д., и желательно использование форка CMS ClassicPress.

Для сайтов же, не требующих таксономий (например корпоративных сайтов услуг), как правило, использую MODx.

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

Роки три тому експерементував з Альбірео та вкладеними папками, коли створювалася тематична, а в неї закидувалися окремі сторінки у міру їх написання. Таким чином виникала ієрархія, яка відображалася на сторінці розділу з витягнутими slug, title і description для інформативності. Спосіб нехитрий, але легко реалізуємий в рамках цього фреймворку. Більше тоді бентежило відображення дерева в боковому меню.

З перерахованого вище не вистачає (як на мене) перемикання стилю теми типу "світла-темна", але то таке..

Да, вот схема, когда рядом с контекстным файлом расположен meta/info-файл достаточно распространена. У меня в LPF похожая схема использовалась. А вот JSON довольно медленный, хотя и читабельный формат. Если это не критично, то можно спокойно заменить на обычную серилизацию — она быстрее работает.

Теоретичні пошуки можна лише вітати, але з кешами у мене був і свій досвід на інформаційному ресурсі, організованому у вигляді сховища документів різних форматів (zip, jpg, pdf, tiff, mp3). Тобто сторінка являла собою одночасно читалку і генерацію файла кешу у форматі json (в разі його відсутності або зміни).

Сторінка завжди читала інфу з кешу, в якому були записані метатеги документів. Кеш генерувався один раз при додаванні, або видаленні відповідного документа і містився він поряд з php-скриптом самої сторінки. При чому, спочатку кешем був звичайний текстовий файл, потім у форматі rss, а потім - json, по них навіть пошук можна було робить.

Зовнішньо виглядало так, що сторінка була відображенням тематичного розділу з описом кожного документа, архіву, або мініатюри растрового зображення. Такий фрагментований кеш виявився доволі живучим при загальній кількості близько 3 тисяч файлів з їх описами у 25 розділах.

Коли Альбірео був ще молодим, то він сподобався тим, що ідея побудови розподіленого кешу мета-інформації запросто лягла на його структру і лише трохи адаптувалася: до шаблону додався скрипт генерації в upload окремої папки з назвою сторінки, після чого, в папку закидувалися документи, з яких витягувались мета-дані та формувався кеш розділу і мініатюр при потребі. Віддача, само собою, була миттєва. Оновлення кешу при додаванні, або вилученні документа зводилася до простого видалення папки за кешами, після чого вони автоматом генерувалися наново. Підхід дилетантський, але автор не претендує на овації, а лише хотів поділитися розв'язанням локальної задачі на файлах, без БД будь-якого формату.

Змагання між ШІ відбулося, і нам лишається коментувати ці шалені перегони, або Кібернетичний Кошмар.

Зі свого невеликого досвіду додам, що Grok від (xAI) більш практичний і гнучкий. Хочеться написати про своєрідний ЧПУ, або кращий юзер-френдлі при спілкуванні з Grok, але, гадаю, що це не зовсім точні смисли. JS він оптимізує класно, але ви праві - слідкувати треба, бо інколи результати можуть бути не тими, які очікуються.

Зараз пробую Mistral (Mistral AI), так ті взагалі пропонують API для власного використання. І тут лише обмеження фантазії може завадити художникам електронного слова. :)

Бажано б розглянути у майбутньому, або додати сюди структуру .htaccess хоча б в частині встановлення заголовків безпеки (стосовно XSS тощо).

Ну й керування кешем теж не завадило б. Вимкнення ETag для уникнення дублювання кешу, наприклад, або кешування статичних ресурсів. Наскільки це цікаво?

Тогда MaxSite CMS не трогаем, пусть работает как сейчас.

Я б ще додав один показник, який обмежує сайтобудівника.

Це - Inodes в характеристиках сервера або хоста, який вказує на кількість індексних блоків (inodes), що використовуються для зберігання метаданих файлів у файловій системі.

Простіше так: будь-яка папка має свій Inodes, файл скрипта, медіафайл, архів, файл бази, права доступу, час останньої модифікації, вміст корзини тощо. Це не тотожно розміру дискового простору, це ближче до такого поняття, як фрагментованість, але не буквально. Наприклад, умовно, хостер виділяє вам 25 GB, але ви маєте вкластися у 200 000 inodes. Якщо їх буде більше - сервер перестане створювати нові, хоча місця на диску буде достатньо. Інколи, це суттєво і має обговорюватись з адміном окремо (за потреби, звісно).

И что делать этим людям сейчас?

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

Что делать пользователям Maxsite CMS, Albireo Framework, LPF, ведь они фактически убиты. Вы сами их убили на взлёте, я бы сказал.

Вы сами понимаете какую чушь пишите? MaxSite CMS уже 16 лет — сайт работает, обновления идут, делайте сайты, шаблоны, плагины — кто мешает пользоваться?

Albireo Framework и LPF — это одно и тоже. Вы всё проспали. Был LPF, который трансформировался в Albireo. Это как минимум 10 последних лет! Точно также как и другие мои проекты — они доступны и продолжают развитие.

Парадокс в том, что у вас какие-то детские претензии, но при этом вы не являетесь пользователем ни Albireo, ни MaxSite CMS, ни Berry. Вы всё чего-то ждёте. Но так это уже ваши проблемы. Мне совершенно неинтересно общаться с таким людьми. Они просто ноют, но ничего полезного не делают, мне жалко потраченного на них время.

"Albireo Framework получился очень хорош. Кто успел сделал на нем свои сайты и лендинги, тот молодец"

И что делать этим людям сейчас?

Что делать пользователям Maxsite CMS, Albireo Framework, LPF, ведь они фактически убиты. Вы сами их убили на взлёте, я бы сказал.

И да, мне бы хотелось предсказуемости, это плохо?

Вы не поняли о чём я, ну впрочем я не удивлён. Вот так всегда заканчивалась вся коммуникация с вами.

Вам нужна "гарантия" завтрашнего дня? Ну так это вы не по адресу. Обратитесь к высшим силам, может они вам и подскажут, что будет завтра.

От себя я могу только предложить качественный продукт, за который и отвечаю. А всё остальное, включая маркетинг, и прочие дискотеки, извините, но у меня нет ни денег, ни времени. "Корпоративный стандарт" - самому не смешно? За всеми этими стандартами стоят огромные деньги, не нужно идеализировать этот мир.

Легко обвинять других, при этом ничего не предлагая самому. Ваше участие это "следить", но были те, кто заказывал сайты, шаблоны, лендинги. Тот же MF люди заказывали и покупали и среди них нет недовольных. Потом эти все наработки перешли в MaxSite CMS, вот вам и развитие. Если вы просто стояли и "следили", так это ваши проблемы. Albireo Framework получился очень хорош. Кто успел сделал на нем свои сайты и лендинги, тот молодец. Но сейчас я физически больше не могу тянуть множество проектов, поэтому ограничился только развитием Albireo и Berry. Хотите поучаствовать в том же MaxSite CMS -- ок, код открыт, пользуйтесь, участвуйте - всё это бесплатно. Но Albireo CMS - это проект другого уровня, где я сосредоточен на развитии системы и любой, кто купит эту CMS станет непосредственным участником его развития. Если вы всё ждёте "чуда", так можно всю жизнь ждать. Всё опять пройдёт мимо вас. Лично я понимаю, что вы просто хотите бесплатного. Но бесплатные проекты обречены - лично я это уже усвоил. У меня нет возможности создавать команду, студию, фирму или корпоративные стандарты, но я могу сказать сколько будет стоить мой труд. Если вам это дорого, воспользуйтесь альтернативами. Но не нужно не уважать и не ценить то, что я сделал.

Вы про вложить или купить?

Заплатить, как пользователь, и полностью попасть в зависимость от одного человека? Ни комьюнити, ни команды, ни стратегии, ни предсказуемости. И что завтра?

Вкладывать, это уже другое, вкладывают владельцы, совладельцы, инвесторы. Это тем более то, что требует понимания перспектив.

Куда вложить и каковы перспективы?

Где то есть демо Albireo CMS? Може опыт пользователей? Или какая-то команда (кампания, фирма, студия ... ) взяла Maxsite CMS, Albireo Framework(CMS), LPF, UniCSS, Berry CSS за корпоративный стандарт? Шаблоны (темы)?

Может я что пропустил?

В любом случае, желаю вам успехов.

Возможно, если бы в Maxsite CMS, Albireo Framework, LPF, UniCSS, Berry CSS пользователи вкладывали деньги и показывали, что эти проекты им нужны, то они бы и дальше развивались. На текущий момент я просто сосредотачиваюсь только на тех проектах, которые мне позволяют выжить. Если вам система нужна бесплатно, то вы можете использовать ту, за которой стоят крупные компании - они могут себе это позволить. Я же один и хочу получать деньги за свой труд.

А так всё хорошо начиналось...

Следил сначала за смс. Мне кажеться с самого начала (будучи довольным вордпрессом один день, давно это было, начал искать альтернативу, наткнулся на макссайт смс).

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

Потом надеялся на развитие LPF, Аlbireo .... И что?

А ничего. И тут внезапно закрытый код и 100 баксов? Вы серьёзно?

Вы безусловно вправе делать что хотите.

Жаль потраченного времени.

Дякую!

З усього серця вітаю, друже!

Це хороший і вагомий крок у світі фреймворків, бажаю розвитку проєкта, а автору особисто - цікавих партнерів і невпинного розвитку. Щасти!

Из популяных CMS у меня сейчас топ - MODX и форк Вордпресса ClassicPress.

Modx очень хорош для разветвлённых многостраничников, например корпоративных сайтов, особенно когда много переиспользуемых блоков. Однако он не подходит для тех сайтов, где важна развитая система разделов и категорий (каталоги), так как в Modx таксономии отсутствуют, все url там - это аналог водпрессовского post_type = page.

Что касается ClassicPress - это Вордпресс здорового человека. Никаких идиотских конструкторов и Гутенберга, форк регуляно обновляется и надеюсь его не забросят. Универсальное решение для новостников, сайтов услуг, и небольших ИМ.

Для ИМ с большим количеством товаров я бы выбрал OpenCart, этот движок, на мой взгляд, самый быстрый как среди готовых e-commerce решений.

Я как-то пытался изобрести свой велосипед для интернет-магазинов и каталогов. Суть в том, что в качестве админки предполагалось использовать чистый Вордпресс, а для пользовательской части часта - полностью свои скрипты в MVC-формате, не зависимые от ядра WP. Свою админку делать даже в мыслях не было, это реально сложно с нуля написать качественные аплоадеры файлов, редактор страниц, систему аутентификации и т.д. К тому же админка у WP удобная, простая и знакомая многим, это сильная сторона данной CMS. Главной идеей проекта была высокая скорость по TTFB - предполагалось на более 50-60 мс без кэширования.

Короче, затея умерла в самом начале - столкнулся с тем, что система роутинга WP и собственная не совпадают, а следовать громоздкому вариативному роутингу WP смысла нет (тем не менее, алиасы страниц и категорий должны были прописываться а админке). Админ/модер сайта переходил по ссылкам в пользовательскую часть, а тут ему мой роутинг просто выбивал 404. Это оказалось непреодолимым препятствием, и в итоге я это дело забросил.

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

В Albireo CMS если ты загружаешь файл через админку, то можно указать её размер (ширину) и качество. Она автоматом конвертируется в webp, поэтому исходные 3Мб скорее всего превратятся в 30Кб.

Либо можно просто указать исходный файл в функции в теле страницы, он автоматом создаёт миниатюру, или может просто сконвертировать в webp, или указываешь каталог — его можно весь сконвертировать в wepb. Таких возможностей нет в других системах.

Привет! Что думаешь насчёт CMS HTMLy? Она тоже на файлах и заточена под блоги. Немного с ней поработал, в целом положительное впечатление, но напрягает, что вообще нет проработки картинок. Юзер вставляет в админку например картинку на 3 Мб, она так в оригинале и выводится в превьюхах и везде по сайту).

Понял. Спасибо.

Ждем релиз.

Всё равно. Годится любой сервер, который умеет переправлять запросы к index.php. Можно даже встроенный php-сервер использовать. Так что проблем не будет.

Добрый день, Максим!

Вы пишите: Единственный нюанс — это файл .htaccess, который может иметь свои особенности на сервере

Я не большой специалист, но как-будто файл .htaccess подразумевает использование сервера apache. Как быть если я использую связку nginx + php-fpm?

А зачем? Есть HTTP_ACCEPT_LANGUAGE, от него и пляшем. Если нужно сменить язык страницы, то нужно сменить предпочитаемый язык браузера. Я пользуюсь Language Switch.

Чи передбачається селектор в шапці (чи деінде) для ручного вибору мови за бажанням? Було б цікаво генерувати селект з вибором, залежно від наявності head-lang[**] в налаштуваннях.

Круто.

Але спіймав себе на думці, що на описи налаштувань сторінки прийдеться виділити окрему главу мануала. Щиро бажаю натхнення автору.

Поправил статью. Добавил описание других возможностей.