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

Жирнющий лайк! Затрахали эти поиски универсальной версии, как Святого Грааля. Статью нашёл на этом фоне, ввёл в поисковик: "какой пиздец происходит с версиями php".

Скрипт js — там без разницы какие стили.

Метки есть, включая и облако и отдельные страницы и общая страница.

Поиск только внешний. Я прикрутил гугл.

Про пошук на сайті не згадано (або хоча б за хмару тегів?).

Навігатор сторінки - топчик, але скрипт заточений лише на berry.css, як я розумію?

Думаю, что можно сделать. Нужно будет подумать, может просто сделать отдельнй параметр старницы, что-то вроде lang[uk]: адрес а система уже сама раскидывать его на head и sitemap.

Давай спробуймо, може комусь теж цікаво: localized-versions

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

Так, я вже подивився (краще б не питав). Рекомендовано (!) вказувати альтернативи ленгвіджу, на що є кілька варіантів:

html-теги в хедері, або sitemap, вибір залежно від смаків автора CMS :o)

p.s. не знаю, чи коректно додавати в коментар посилання на доки.

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

Можливо, питання було сформульовано некоректно, але мова про інше:

Якщо існують кілька версій сторінки різними мовами, то в результатах пошуку мають бути представлені ті версії сторінок, які краще підходять регіону користувача. Це не обов'язково, звісно, але все ж таки.

Там же только адреса, переводить нечего.

Чи виникає (при мультимовному сайті) необхідність вказувати це у sitemap?

Чи google сам розбереться?

Админку я принципиально не хочу переводить — там по английски и по сути нечего переводить, всё слишком примитивно.

А шаблон нужно переводить через lang(). И опять же, все сам по себе шаблон состоит только из html и css, там нечего переводить. Все служебные сообщение уже переведены. Если нужен перевод, то он указывается на самой странице, либо в конфигурации с помощью lang(). Может будут какие-то доработки, но в целом этого достаточно для 100% мультиязычности.

Лишається проблема, що не була згадана - переклад шаблону.

Як варіант, бачу її рішення через використання lang() для шаблона в комбінації з одним із способів мультипейджу (або я чогось не зрозумів). І чи буде це працювати для панелі адміністратора у варіанті "з коробки"?

Попередні Албірео-версії (до анонсу CMS) прийшлося перекладати адмінку вручну, так би мовити.

Странно, почему-то не приходят уведомления по email на твои комменты. :-)

Хлебные крошки сложно в том плане, что непонятно что в них нужно выводить. Самый простой вариант — это считывать структуру каталогов и по одному их выводить, но не по каждому адресу может быть страница. Поэтому пока ничего разумного не придумал. Но технически подключить любой модуль вообще не проблема.

Так, тут я схибив, бо дійсно, вів мову за прев'ю, зрозумів помилку пізніше, та месага вже була на розгляді.

Мені подобаються в цій статті підходи щодо адмінки, я практично не користувався попереднім варіантом, хоча й зробив окремий розділ користувачам, яким дозволено додавання/зміна файлів у аплоаді. Все інше експериментую напряму.

Хотілося б у layout мати варік з меню типу хлібних крошок, я робив такий, але це викликає необхідність фізичної адресації. Можливо, є й інші способи в рамках роутінга Альбірео, але я про них не знаю.

Да, Obsidian пока рулит, спасибо за наводку. :)

По миниатюрам. У тебя скорее идёт речь о превьюшках, а не о миниатюрах для просмотра в админке. Превьюшка в Альбирео делается автоматом — просто указывается нужный адрес, размеры и файл появится с суффиксом thumb.

Таки Obsidian зачепив? ;о)

Дуже радий, що робота продовжується. Не згоден в тому, що мініатюри це накладні розходи. Я перший скрипт в Альбірео робив без картинки, був перебір .pdf і .jpg з простим виводом списку кожного разу, при звертанні до сторінки. Потім уже варіант зі скануванням і виводом по папках і т.д. Але пізніше, коли кількість документів перетнула відмітку 100шт і тормоза стали помітні, народилася ідея кешування списків для кожної папки. Після кешування мініатюри прописалися на сторінці, слідкувати за ними стало не важко й скорість віддачі не сильно зросла порівняно з "чистим" текстом.

п.с. у Obsidian є крутезний додаток - Share Note, який у поєднанні з Obsidian Dataview дає цікавий інструмент для роботи з примітками.

Конвертация средствами самого PHP. Там вроде бы стандартная GD используется, никаких чудес.

Файлы можно использовать любого формата, никаких ограничений нет. Просто есть удобный механизм получения и работы с WEBP из коробки. Если нужен другой формат, просто указывается в параметрах функции. Это может быть jpg, png, gif и webp.

Для автоконвертації зображення у webp і створення мініатюр використовується Imagick, чи це свійські функції? і чи лишається механізм використання jpg (формат по вибору)?

Питання пов'язане з тим, що є специфічні задачі для збереження тайлів, тобто тисяч фрагментів 256х256px з яких складаються карти, наприклад.

p.s. минулий скрипт мав особливість - редагування ще не модерованого коментаря, чи було це вадою мені невідомо, але кілька раз воно спрацювало.

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

Як на мене, constants.php має стати ключовою ідеєю перебудови вже зробленого, хоча хоронити свої ідеї буде трохи боляче.

Адмінка важлива частина, безперечно, але (на мою думку) лише при необхідності розділення прав доступу. Чи буде вона в нових релізах? (сліди такого намагання були в ранішньому коді).

Возможно. Открытым он точно не будет.

Перетворення Albireo на CMS означатиме, що проєкт стане платним?

Ну смотри. Когда ты получаешь rss, то это обращение к другому серверу, а значит могут быть тормоза. Поэтому итог rss и нужно в кэш кидать. Но когда читаешь папку на своём сервере, то нет смысла её кэшировать, потому что это очень быстрая и легкая операция для сервера.

Другое дело, если тебе нужно считать данные их файлов. Тогда да, может и кэш поможет ускориться. Но вообще, я бы рекомендовал проверять эффективность кэша хотя бы по общей статистике времени генерации сайта и потребляемой памяти. Статистика в цифрах избавляет от субъективности.

Даты пока нет. Сейчас вообще невозможно ничего спланировать.

С гитхаба убрал немого раньше. Распыляться на два проекта не хочу, тем более, что framework плавно перерос в cms.

Так и пусть пишет свою функцию или библиотеку. Всех задач система всё равно решить не может, поэтому пользователи всегда изобретают свой велосипед. Не вижу в этом проблем.

Привет, известна ли уже дата релиза?

З огляду на те, що з GitHub зник проєкт Albireo, після цієї статті виникає стійке відчуття Albireo CMS versus Albireo Framework. Хіба вони не могли існувати паралельно, навіть без супроводу? Чому фреймворком має бути повторена доля LPF?

Цікава стаття з погляду теорії. Я своєю чергою вигадував граблі створюючи локальні текстові кеші. Наприклад, читаємо кілька rss-джерел, генеруємо з них текстовий зведений файл-кеш (тут як фантазія спрацює - хоч одразу в блоки html). Далі віддаємо цей локальний кеш кожного разу при виводі у браузер, оновлюючи його раз на пів години, як заманеться.

Або ще. Обходимо якусь папку, скажімо в Upload, куди юзер (та хоч адмін), періодично додає-видаляє файли pdf, jpg, не суть. Тоді створення локального кешу папки в рази прискорює генерацію виводу сторінки, причому сам кеш може бути json, в якому вже є інфа, автоматом зчитана при формуванні кешу (розмір, мета, дата розміщення тощо). Це працює і для кешу мініатюр. Головне в процесі виводу - кеш читаємо завжди, а при його відсутності - генеруємо хоч обходом, хоч сторонньою бібліотекою, хоч по закінченню строку життя.

Єдиний випадок, коли такий кеш спрацював погано - генерація денної статистики для окремої сторінки, коли неминуче виникла ситуація одночасного доступу до текстовика при додаванні запису. Це добре описано в статті, в частині гарантованих транзакцій. В моєму випадку, краш настав доволі бистро - при навантаженні лише у десяток звернень за пів години, наприклад. Такий собі новачковий експеримент.

Ну, є й такий варіант:

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

Це, як з водіями на дорогах - професіоналів мало, але їхати потрібно всім. Тому, автор CМS або делегує, або обмежує кінцевого користувача у цьому праві, стаючи на шлях волюнтаризму. В будь-якому випадку, обмеження (або користувацькі самообмеження) завжди дратуватимуть перфекціонізм автора.

Схоже, що рішення полягає у площині доступності готових модулів-бібліотек, їх різноманітності, кількості, публічності і якості. А тут уже, без популяризації, не обійтися і маркетинг знову стане основою розвитку продукту. Годувати Уробороса прийдеться.