Понял. Спасибо.
Ждем релиз.
Всё равно. Годится любой сервер, который умеет переправлять запросы к index.php. Можно даже встроенный php-сервер использовать. Так что проблем не будет.
Добрый день, Максим!
Вы пишите: Единственный нюанс — это файл .htaccess, который может иметь свои особенности на сервере
Я не большой специалист, но как-будто файл .htaccess подразумевает использование сервера apache. Как быть если я использую связку nginx + php-fpm?
А зачем? Есть HTTP_ACCEPT_LANGUAGE, от него и пляшем. Если нужно сменить язык страницы, то нужно сменить предпочитаемый язык браузера. Я пользуюсь Language Switch.
Чи передбачається селектор в шапці (чи деінде) для ручного вибору мови за бажанням? Було б цікаво генерувати селект з вибором, залежно від наявності head-lang[**] в налаштуваннях.
Круто.
Але спіймав себе на думці, що на описи налаштувань сторінки прийдеться виділити окрему главу мануала. Щиро бажаю натхнення автору.
Поправил статью. Добавил описание других возможностей.
Жирнющий лайк! Затрахали эти поиски универсальной версии, как Святого Грааля. Статью нашёл на этом фоне, ввёл в поисковик: "какой пиздец происходит с версиями 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 и нужно в кэш кидать. Но когда читаешь папку на своём сервере, то нет смысла её кэшировать, потому что это очень быстрая и легкая операция для сервера.
Другое дело, если тебе нужно считать данные их файлов. Тогда да, может и кэш поможет ускориться. Но вообще, я бы рекомендовал проверять эффективность кэша хотя бы по общей статистике времени генерации сайта и потребляемой памяти. Статистика в цифрах избавляет от субъективности.