Не интернет-магазин, а просто любой сайт, отличный от UGC-сайта. Во второй версии для того, чтобы разобраться в шаблонах, приходится параллельно учить второй язык — компонентов, это несколько… обескураживает.
А что такое «мобильный шаблон» тогда? Это же в любом случае html+css? А там невозможны ни свайпы, ни родные всплывающие окна, это модули cordova или т.п. инструментов. Или нет?
Адаптивный шаблон не может конкурировать с приложением, конечно (а приложение на cordova и т.п. с WebView не может конкурировать с React Native). Но мобильное приложение — это большой кусок работы с внедрением в фреймворк API, jwt- или oauth-авторизации, плюс приложение надо делать точно под конкретную сборку сайта. До этого очень далеко. Пока для корректного отображения в мобильных браузерах достаточно адаптивности на css media queries.
Сделать несколько дополнительных репозиториев и начать работу над ними параллельно
И разрываться среди этих решений? Чем плох предложенный мной вариант по выносу функционала в плагины ядра? Имели бы один продукт с вариативностью использования.
У разных сайтов разный набор урлов, и разный набор контроллеров, эти урлы обрабатывающих. Контроллеры в LS завязаны с роутингом и находятся в application/classes/action. Делать разные сборки придётся, по-другому никак, мне кажется. Можно переместить все контроллеры во фреймворк, но тогда нужен будет какой-то конфиг, где ненужные контроллеры будут отрубаться, и вообще всё будет менее гибко.
Вот некоторые модули из нынешнего application можно переместить и во framework. Возможно, сделав из них плагины, чтобы сделать actions для HTTP API.
О каких махинациях с директориями идет речь?
Я так понимаю про права на запись в директории. Но без этого никак не обойтись, увы.
За адаптивность +1, @media в css прекрасно разруливают отображение на мелких экранах.
Что-то меня зацепила судьба LS.
Я уже давно не использую CMS, так как фреймворки сейчас настолько удобны, пакетов сейчас такое количество, что опытным проще взять и написать всё самому, чем влезать в прокрустово ложе CMS и молиться, что функционала хватит. Новичкам тоже выгоднее для собственного развития потратить месяц на самообучение фреймворку, а дальше накопипастить себе требуемый функционал.
Но конкретно LS хочется чтобы жило. В наше время миграции сообществ во вконтакт/телеграм/дискорд/гиттер/слак хочется дать вебу ещё один шанс.
Моё видение.
1. Берем за основу ls2 с его фреймворком — окей. Но я продолжаю настаивать, что надо использовать композер и делать фреймворк в виде его пакета, чтобы лайвстрит можно было использовать программистам, пишущим на симфони, ларавеле, yii2 и других фреймворках. Это позволит резко расширить аудиторию LS. Т.е. /framework переезжает в папку /vendor, которую делает composer, вместе с остальными пакетами. Остальное (аппликейшн, дизайн) находится в папках, пути для которых прописать в index.php в виде констант или конфига, чтобы можно было во фреймворке при подключении LS менять их. Загрузку классов можно оставить имеющуюся, не переводить всё на PSR-4. Я попробую сие сделать для прикидки.
2. Для мотивации разрабам нужен каталог. Нужен чел с ИП, или уговорить Максима всё возродить на базе его бухгалтерии с ООО, разобраться с Робомаркетом, как туда выгружать товары с ценами — и можно жить без онлайн-кассы.
3. По поводу совместимости плагинов ничего пока не скажу, так как слабо владею темой. Мне кажется, это будет сложно, затраты на ограничения в коде будут слишком большими. Ждём анализа от @olezhikz или других разрабов, плотно знакомых с темой.
Ну, сначала надо перевести с английского — «доступ запрещён конфигурацией сервера» и дальше путь до директории показывает, что у веб-сервера попросили доступ к директории посредством урла, но эту директорию показывать нельзя. Затем можно погуглить текст и код ошибки в логах (часто с этого приходится начинать, так как описание ни о чем не говорит) — на stackoverflow или схожих сайтах наверняка уже есть объяснение, что конкретно происходит и как лечить.
Я вижу ещё, в качестве юрлица была зачем-то выбрана форма ООО, что увеличивает гемор отчётности. Ну и, получается, для развития лайвстриту требуется найти ИПшника с уже имеющейся онлайн-кассой, облачной или железной. Или просто ИПшника и юзать безкассовые решения типа Робомаркета. Есть среди нас такие?
Мне кажется, компоненты Симфони, на которых построен Ларавель — это последнее в мире php, как Рельсы стали последним в мире Руби. Вряд ли эти тренды изменятся ) А про сроки — если не строить архитектуру под возможность расширения плагинами, а просто повторять функционал — мне кажется, для фуллтайм разраба тут дел скорее на пару месяцев.
Но в любом случае, что бы ни было со сроками и трендами — у нас не так много вариантов.
1. Отказаться от 2.0 (буквально удалить все упоминания о ней), взять ветку 1.х, имплементировать особо востребованные за эти года фичи, написать подробную документацию, выпускать скринкасты, чаще выпускать релизы и жить, не хватая звёзд с неба, на том, что есть. Плюсы — сообщество в виде пользователей-непрограммистов будет удовлетворено. Минусы — желающих делать это очень немного и будет уменьшаться со временем, чтобы поддерживать какой-то продукт надо быть мотивированным, скорее всего денежно, а эти возможности ограничены.
2. Забыть про всё, что было раньше и сделать новый продукт, возможно, с новым именем, с мультиблоговым функционалом, в виде packagist-пакета, для использования в разнообразных фреймворках, прежде всего Laravel. Плюсы — это интересно, активизируются разрабы, прибавится аудитория фреймворка. Минусы — простые пользователи (умею заливать по ftp, что такое ssh не знаю, хочу ставить модули в пару кликов, хочу перенести одной кнопкой свой проект на новый лайвстрит) не получат свой продукт довольно долгое время. Но проблемы пользователей по установке можно решить, кстати, развёртыванием аналога forge.laravel.com, где за небольшую денежку на выбранном голом vps будет поставлена свежая копия движка, настроен nginx, очереди, реалтайм-сервер и т.п. Его же можно будет совместить со стором, и ставить/обновлять плагины одним кликом мышки.
Мне кажется, вариант «делаем 3ю версию как 2, только на новом фреймворке» менее выгодна, так как мало каком разрабу нужен у себя чистый лайвстрит, потому что весь остальной проект придётся строить вокруг него, а так делать никто не будет и народ просто будет проходить мимо. А вот древовидные комменты к своим статьям, виджет с последним прокомментированным, или например чат — он бы взял.
В сообщество Laravel периодически приходят люди с вопросом про Октобер, но им почти никто не отвечает, потому что у него уже своя обширная кодовая база, а опытный программер скорее возьмёт свои наработки на фреймворке и сделает простенькую CMS для клиента под его запросы, чем возьмёт готовую CMS и будет в ней разбираться. Поэтому в сообществе Октобер как-то не прижился, мало кто с ним работал и знает его.
Сколько нужно человекочасов я примерно представляю, придётся посидеть поработать, конечно, но Октобер сие не облегчит почти никак, там нет каких-то своих инструментов для построения социалки с блогами. Если его брать, кстати, то Livestreet3 (коллективные/персональные блоги, комментарии, рейтинги, вот это всё) логичнее выпустить в виде плагина к этой CMS.
По-моему, форкать Октобер не стоит, мы лишаемся всей гибкости фреймворк-подхода и завязываемся на солид, который несёт нам кучу избыточного функционала, и который невозможно будет встроить в существующие проекты людей. Октобер — вещь в себе, там от фреймворка почти ничего не осталось, допиливать его — проще уж допилить ls1.
После ознакомления с ситуацией (не заходил сюда лет пять) поменял своё мнение. Проект действительно мёртв, кому были нужны доделки для своих проектов — те наняли программеров, остальные свалили на другие CMS.
Так что можно делать всё, что угодно, @olezhikz, жги. ) Можно наконец-то выбросить хабр-стайл («Интересные Новые Обсуждаемые ТОП») или попытки сделать интернет-магазин на базе ls и сосредоточиться на социальной составляющей (блоги персональные и коллективные, страницы, комментарии древовидные и линейные, подписки, ленты, агрегация контента со сторонних ресурсов и API ко всему этому делу).
Я бы предложил в качестве фреймворка Laravel (делать livestreet в виде пакета для этого фреймворка для включения в существующие проекты людей), потому что
1. Он построен на symfony components, а в 2к18 те, кто пишет на php не юзает их — явно делает что-то не так.
2. Помимо компонентов симфони у него есть своя развитая экосистема пакетов, типа laravel echo для реалтаймовых вещей типа чата, laravel passport для собственного oauth-сервера для сторонних приложений или laravel socialite с драйверами авторизаций через практически все соцсети.
3. В отличие от собственно Symfony он очень френдли к разработчикам — о куче типовых вещей не надо думать, так как всё делается парой строчек кода, есть удобные простые средства сборки фронта и тестирования. Это всё увеличивает аудиторию возможных контрибуторов и плагинмейкеров.
4. У него уже устоявшаяся кодовая база, в будущем маловероятно повторение истории с yii1 -> yii2 (тем более что у yii наклёвывается уже новая мажорная версия, 3). Плюс слабосвязанность компонентов, а также существование сервисов типа laravel shift, где за деньги могут апнуть проект до актуальной версии, позволит уменьшить боль с апгрейдами, если таковые всё-таки будут.
Главное в начале каждого проекта — понять, какой у нас рынок.
Реально ли существует такое количество людей, которым нужна хабр-стайл социальная CMS? Или, возможно, лучше сосредоточиться на поддержке тех версий, на которых уже существуют проекты ?
Может, пришла пора взяться за допиливание 1й версии ()?
Адаптивный шаблон не может конкурировать с приложением, конечно (а приложение на cordova и т.п. с WebView не может конкурировать с React Native). Но мобильное приложение — это большой кусок работы с внедрением в фреймворк API, jwt- или oauth-авторизации, плюс приложение надо делать точно под конкретную сборку сайта. До этого очень далеко. Пока для корректного отображения в мобильных браузерах достаточно адаптивности на css media queries.
Вот некоторые модули из нынешнего application можно переместить и во framework. Возможно, сделав из них плагины, чтобы сделать actions для HTTP API.
Я так понимаю про права на запись в директории. Но без этого никак не обойтись, увы.
За адаптивность +1, @media в css прекрасно разруливают отображение на мелких экранах.
Я уже давно не использую CMS, так как фреймворки сейчас настолько удобны, пакетов сейчас такое количество, что опытным проще взять и написать всё самому, чем влезать в прокрустово ложе CMS и молиться, что функционала хватит. Новичкам тоже выгоднее для собственного развития потратить месяц на самообучение фреймворку, а дальше накопипастить себе требуемый функционал.
Но конкретно LS хочется чтобы жило. В наше время миграции сообществ во вконтакт/телеграм/дискорд/гиттер/слак хочется дать вебу ещё один шанс.
Моё видение.
1. Берем за основу ls2 с его фреймворком — окей. Но я продолжаю настаивать, что надо использовать композер и делать фреймворк в виде его пакета, чтобы лайвстрит можно было использовать программистам, пишущим на симфони, ларавеле, yii2 и других фреймворках. Это позволит резко расширить аудиторию LS. Т.е. /framework переезжает в папку /vendor, которую делает composer, вместе с остальными пакетами. Остальное (аппликейшн, дизайн) находится в папках, пути для которых прописать в index.php в виде констант или конфига, чтобы можно было во фреймворке при подключении LS менять их. Загрузку классов можно оставить имеющуюся, не переводить всё на PSR-4. Я попробую сие сделать для прикидки.
2. Для мотивации разрабам нужен каталог. Нужен чел с ИП, или уговорить Максима всё возродить на базе его бухгалтерии с ООО, разобраться с Робомаркетом, как туда выгружать товары с ценами — и можно жить без онлайн-кассы.
3. По поводу совместимости плагинов ничего пока не скажу, так как слабо владею темой. Мне кажется, это будет сложно, затраты на ограничения в коде будут слишком большими. Ждём анализа от @olezhikz или других разрабов, плотно знакомых с темой.
Но в любом случае, что бы ни было со сроками и трендами — у нас не так много вариантов.
1. Отказаться от 2.0 (буквально удалить все упоминания о ней), взять ветку 1.х, имплементировать особо востребованные за эти года фичи, написать подробную документацию, выпускать скринкасты, чаще выпускать релизы и жить, не хватая звёзд с неба, на том, что есть. Плюсы — сообщество в виде пользователей-непрограммистов будет удовлетворено. Минусы — желающих делать это очень немного и будет уменьшаться со временем, чтобы поддерживать какой-то продукт надо быть мотивированным, скорее всего денежно, а эти возможности ограничены.
2. Забыть про всё, что было раньше и сделать новый продукт, возможно, с новым именем, с мультиблоговым функционалом, в виде packagist-пакета, для использования в разнообразных фреймворках, прежде всего Laravel. Плюсы — это интересно, активизируются разрабы, прибавится аудитория фреймворка. Минусы — простые пользователи (умею заливать по ftp, что такое ssh не знаю, хочу ставить модули в пару кликов, хочу перенести одной кнопкой свой проект на новый лайвстрит) не получат свой продукт довольно долгое время. Но проблемы пользователей по установке можно решить, кстати, развёртыванием аналога forge.laravel.com, где за небольшую денежку на выбранном голом vps будет поставлена свежая копия движка, настроен nginx, очереди, реалтайм-сервер и т.п. Его же можно будет совместить со стором, и ставить/обновлять плагины одним кликом мышки.
Мне кажется, вариант «делаем 3ю версию как 2, только на новом фреймворке» менее выгодна, так как мало каком разрабу нужен у себя чистый лайвстрит, потому что весь остальной проект придётся строить вокруг него, а так делать никто не будет и народ просто будет проходить мимо. А вот древовидные комменты к своим статьям, виджет с последним прокомментированным, или например чат — он бы взял.
Сколько нужно человекочасов я примерно представляю, придётся посидеть поработать, конечно, но Октобер сие не облегчит почти никак, там нет каких-то своих инструментов для построения социалки с блогами. Если его брать, кстати, то Livestreet3 (коллективные/персональные блоги, комментарии, рейтинги, вот это всё) логичнее выпустить в виде плагина к этой CMS.
Так что можно делать всё, что угодно, @olezhikz, жги. ) Можно наконец-то выбросить хабр-стайл («Интересные Новые Обсуждаемые ТОП») или попытки сделать интернет-магазин на базе ls и сосредоточиться на социальной составляющей (блоги персональные и коллективные, страницы, комментарии древовидные и линейные, подписки, ленты, агрегация контента со сторонних ресурсов и API ко всему этому делу).
Я бы предложил в качестве фреймворка Laravel (делать livestreet в виде пакета для этого фреймворка для включения в существующие проекты людей), потому что
1. Он построен на symfony components, а в 2к18 те, кто пишет на php не юзает их — явно делает что-то не так.
2. Помимо компонентов симфони у него есть своя развитая экосистема пакетов, типа laravel echo для реалтаймовых вещей типа чата, laravel passport для собственного oauth-сервера для сторонних приложений или laravel socialite с драйверами авторизаций через практически все соцсети.
3. В отличие от собственно Symfony он очень френдли к разработчикам — о куче типовых вещей не надо думать, так как всё делается парой строчек кода, есть удобные простые средства сборки фронта и тестирования. Это всё увеличивает аудиторию возможных контрибуторов и плагинмейкеров.
4. У него уже устоявшаяся кодовая база, в будущем маловероятно повторение истории с yii1 -> yii2 (тем более что у yii наклёвывается уже новая мажорная версия, 3). Плюс слабосвязанность компонентов, а также существование сервисов типа laravel shift, где за деньги могут апнуть проект до актуальной версии, позволит уменьшить боль с апгрейдами, если таковые всё-таки будут.
Реально ли существует такое количество людей, которым нужна хабр-стайл социальная CMS? Или, возможно, лучше сосредоточиться на поддержке тех версий, на которых уже существуют проекты ?
Может, пришла пора взяться за допиливание 1й версии ()?
Прибейте только футер к низу экрана на altocms.ru
Ветка testing у debian — 5.1