План развития
Итак. Что мы имеем в итоге. Сообщество в целом желает переезда, но из них малая часть готова принять участие в этом. Невозможность данной затеи очевидна, так как сил, денег, времени нет. Я не собираюсь браться за это в одиночку. Сообщество у нас маленькое. Так что давайте держаться вместе и не доводить до оскорблений. Конструктивной критики много. Нужно определиться с тем что делать или не делать дальше. Но даже для этого нужна какая то методология. У большинства высказавшихся безусловно имеется свое соображение на данную тему. И они выстраивают свою цепь задач, которые необходимы для начала работы. Я попытаюсь выстроить свою.
Базовое условие для жизни проекта — это ресурсы позволяющие ему развиваться и поддерживаться. Никто не сможет бесконечно вкладывать свое время и силы, если от этого нет толка. Так и livestreet, продолжал активно развиваться пока создатели видели смысл в этом. Личное развитие, интеллектуальный интерес, азарт, возможность применения наработок в своих проектах. Как только проект дорос до уровня, когда он стал функционально удовлетворять потребности и пропал первоначальный запал, он стал постепенно угасать. В этот момент еще и сыграли внешние факторы — очередной закон о запрете малого бизнеса в России. Тем не менее, благодаря упорству и таланту основателей в проект были заложены, как я считаю, весьма перспективные вещи. Я имею в виду например новую структуру шаблона и применение компонентов.
Но вернемся к основным задачам. Нужен ресурс. Им может быть на данном этапе только каталог и процент с продаж платных плагинов. Чтобы он заработал, нужны установки движка и соответственно заказы на плагины.
Чтобы были установки считаю нужным:
1. Упростить установку для пользователя. Чтобы ставилось в несколько кликов, без дополнительных махинаций с директориями.
2. Доработать стандартный шаблон. Добавить тем. Возможность выбора цветов в темах и прочее
3. Встроить во фреймворк возможность определения мобильного устройства. Это даст почву для доработки структуры шаблонов с включением в него мобильных версий. Не адаптивных, хотя их не кто не запрещает. Но чисто мобильного вида на основе, например framework7.Дело в том, что не всегда удобно использовать адаптивный шаблон, особенно если сайт разрастается функционалом и необходимо адаптировать его с разным отображением на PC и смартфоне. Это в свою очередь поднимет вопрос о мобильном приложении из коробки. Для чего останется лишь обернуть уже готовый шаблон в phonegap. Да, приложение не будет нативным, но это лучше чем ничего. В последствии можно качать эту тему, как преимущество.
4. Добавить вариативности. Определить, что сейчас востребовано на рынке. Ленденги, новостные сайты, блоги, и другое. Выбрать из этого, что нам больше по душе. Сделать несколько дополнительных репозиториев и начать работу над ними параллельно. Благо движок вынесен от фреймворка, на его базе можно сделать все что угодно.
А так же нужно привлечь разработчиков:
1. Взять за основу 2ю версию и сделать обратную совместимость с 1ой. По сути они отличаются только структурой шаблона, миграциями и некоторыми методами в модулях. Считаю это решаемая задача. Пусть даже и придется пожертвовать стройностью.
2. Расширить практику использования компонентов шаблона. Вплоть до вынесения в каталог. Это позволит frontend разработчикам осваиваться заходя с этой стороны. Что нам дают компоненты? Инкапсуляция в шаблонизаторе и javascript, через jquery виджеты. В результате прекрасная переносимость из проекта в проект. Останется только сделать, чтобы css не пересекался и не примешивался, и подгрузку компонентов динамически, чтобы грузились только необходимые в зависимости от запрашиваемой страницы.
3. Документация. Необходимо продумать документацию, и вынести ее на видное место. Добавить видео уроки по ключевым моментам. Примеры кода. Расставить все это в логичном порядке.
4. Условия и рекомендации. Написать для разработчиков рекомендации, по написанию кода с примерами. Выставить необходимые условия по качеству. Например можно ввести практику доработки, когда разработчику рекомендуется писать рабочий заготовок плагина, а в последствии дорабатывать его для конкретного клиента, что обычно и приходится делать. Это позволит экономить время самим разработчикам.
5. Бесплатное демо. Дать возможность показать готовое творение на нашем сервере. Для этого не потребуется большая нагрузка. Особенно если использовать один движок на всех, установленный по жесткой ссылке или монтированный из отдельной директории(для тех кто слышал о linux)
6. Начать пользоваться задачами на github. Там и карточки со списком задач есть. Документация для контрибьютеров должна быть обязательно. И вообще продумать какие нибудь бонусы для принявших участие, например процент от дохода каталога.
Теперь попрошу зарыть тему о переезде. И обсудить ваши предложения о дальнейших действиях.
Базовое условие для жизни проекта — это ресурсы позволяющие ему развиваться и поддерживаться. Никто не сможет бесконечно вкладывать свое время и силы, если от этого нет толка. Так и livestreet, продолжал активно развиваться пока создатели видели смысл в этом. Личное развитие, интеллектуальный интерес, азарт, возможность применения наработок в своих проектах. Как только проект дорос до уровня, когда он стал функционально удовлетворять потребности и пропал первоначальный запал, он стал постепенно угасать. В этот момент еще и сыграли внешние факторы — очередной закон о запрете малого бизнеса в России. Тем не менее, благодаря упорству и таланту основателей в проект были заложены, как я считаю, весьма перспективные вещи. Я имею в виду например новую структуру шаблона и применение компонентов.
Но вернемся к основным задачам. Нужен ресурс. Им может быть на данном этапе только каталог и процент с продаж платных плагинов. Чтобы он заработал, нужны установки движка и соответственно заказы на плагины.
Чтобы были установки считаю нужным:
1. Упростить установку для пользователя. Чтобы ставилось в несколько кликов, без дополнительных махинаций с директориями.
2. Доработать стандартный шаблон. Добавить тем. Возможность выбора цветов в темах и прочее
3. Встроить во фреймворк возможность определения мобильного устройства. Это даст почву для доработки структуры шаблонов с включением в него мобильных версий. Не адаптивных, хотя их не кто не запрещает. Но чисто мобильного вида на основе, например framework7.Дело в том, что не всегда удобно использовать адаптивный шаблон, особенно если сайт разрастается функционалом и необходимо адаптировать его с разным отображением на PC и смартфоне. Это в свою очередь поднимет вопрос о мобильном приложении из коробки. Для чего останется лишь обернуть уже готовый шаблон в phonegap. Да, приложение не будет нативным, но это лучше чем ничего. В последствии можно качать эту тему, как преимущество.
4. Добавить вариативности. Определить, что сейчас востребовано на рынке. Ленденги, новостные сайты, блоги, и другое. Выбрать из этого, что нам больше по душе. Сделать несколько дополнительных репозиториев и начать работу над ними параллельно. Благо движок вынесен от фреймворка, на его базе можно сделать все что угодно.
А так же нужно привлечь разработчиков:
1. Взять за основу 2ю версию и сделать обратную совместимость с 1ой. По сути они отличаются только структурой шаблона, миграциями и некоторыми методами в модулях. Считаю это решаемая задача. Пусть даже и придется пожертвовать стройностью.
2. Расширить практику использования компонентов шаблона. Вплоть до вынесения в каталог. Это позволит frontend разработчикам осваиваться заходя с этой стороны. Что нам дают компоненты? Инкапсуляция в шаблонизаторе и javascript, через jquery виджеты. В результате прекрасная переносимость из проекта в проект. Останется только сделать, чтобы css не пересекался и не примешивался, и подгрузку компонентов динамически, чтобы грузились только необходимые в зависимости от запрашиваемой страницы.
3. Документация. Необходимо продумать документацию, и вынести ее на видное место. Добавить видео уроки по ключевым моментам. Примеры кода. Расставить все это в логичном порядке.
4. Условия и рекомендации. Написать для разработчиков рекомендации, по написанию кода с примерами. Выставить необходимые условия по качеству. Например можно ввести практику доработки, когда разработчику рекомендуется писать рабочий заготовок плагина, а в последствии дорабатывать его для конкретного клиента, что обычно и приходится делать. Это позволит экономить время самим разработчикам.
5. Бесплатное демо. Дать возможность показать готовое творение на нашем сервере. Для этого не потребуется большая нагрузка. Особенно если использовать один движок на всех, установленный по жесткой ссылке или монтированный из отдельной директории(для тех кто слышал о linux)
6. Начать пользоваться задачами на github. Там и карточки со списком задач есть. Документация для контрибьютеров должна быть обязательно. И вообще продумать какие нибудь бонусы для принявших участие, например процент от дохода каталога.
Теперь попрошу зарыть тему о переезде. И обсудить ваши предложения о дальнейших действиях.
51 комментарий
2. По возможность делать документацию, мануалы, видео для второй версии
3. Выбрать 5-10 самых популярных плагинов для первой ветки и адаптировать их под двойку
1. Достаточно видеоинструкции по установке, а время потратить на работу с расширениями
2. ИМХО стандартный шаблон сильно на любителя и толку от тем, если нет документации и возможности сделать под себя. Опять же нет адаптивности. Для большинства пользователей мобильные версии это темный лес, очень небольшой процент будет с этим заморачиваться, только если на сайте больше 1000 уников в сутки, для остальных адаптивности хватит с головой.
P.S. При любом раскладе, спасибо если будете развивать лайвстрит, по какому бы пути вы не пошли.
LS хороший двиг под конкретную цель, а это коллективные блоги. Да, можно переделать под портал и под свой блог и под сми сайт и даже под онлайн магазин. Но первоначальный его функционал это что-то типа Хабра. И вот беды этого действия:
1. Обновлять двиг но оставлять его именно под эту цель не разумно. Насколько СНГ рынок нуждается в подобном продукте?
2. СНГ рынок. Хотите развивать движок? Иметь много сторонних разработчиков? Уходите с СНГ рынка и цель ставьте на западный.
3. Изменить цель движка. Сделать его простым для использования во всем не ставя перед ним конкретную цель делать что-то лучше в одном направлении.
Затея мертвая в ее начале, я просто не вижу смысла восстановление движка. Сообщество мертво, потому что двиг мертв. Даже если и будет продолжение движка его ждет такая же участь которая сейчас. Только потом вряд ли кто возьмется его опять воскрешать.
Я тут новенький и прошу строго не судить.
Смотря на то что движок погибает и соглашусь с Gameer с тем что надо делать более функциональный движок под разные проекты.
Я предлагаю свое виденье со стороны обновить движок LS и дальше его развивать плюс сделать такой же движок но под разные цели и запускаться на западе. Есть имя LS соответственно людям будет интересно посмотреть что разработчики из LS сделали еще.
Я сам не программист но очень мне эта тема нравится но больше всего я люблю развивать. Если конечно меня подержите готов даже предложить разумное финансирование для разработки нового движка.
Представленный план меня не устраивает. Те же грабли.
Каким я вижу план. Какой должна быть версия 3.0:
— Никакой (!) обратной совместимости с предыдущими версиями. Не надо городить огород и захламлять код лишним хламом.
— Убрать компоненты. Идея хорошая. Подгружать то, что надо. Но на деле возишься с мелкими файлами в которых надо найти связи с другими компонентами, а те в свою очередь с другими. В итоге имеем вермишель.
— Шаблон бутстрап 4 (админка тоже). Написанный блоками (как в альто). Очень быстро правится. Адаптивный.
— Принцип js скриптов как в версии 1.0.3.
— Разделить back-end и front-end по сути. Ядро РНР (framework) с которым можно работать в любом направлении и в будущем навешивать нужный функционал.
Структура примерно такая:
/app/ — в этой папке всё, что обновляется чаще всего в процессе разработки сайта.
/framework/ — “ядро” движка. Обновляется крайне редко.
/frontend/ — раздел в котором три категории: css, js, tpl. То что в движке по-умолчанию.
/vendor/ — Различные библиотеки (jquery, bootstrap и т.д.) которые обновляются не часто
Всё, что тут описал пришло из опыта написания сайта используя альто. Удобно работать. Обновлять библиотеки если требуется. И если построить LiveStreet 3.0 в таком плане, по моему субъективному мнению, то получится возродить движок.
Для развития ls2, нужно выбирать — или делать обратную совместимость с плагинами для первой версии или адаптировать плагины под ls2. Потому что сейчас сложилась такая ситуация, что много пользователей хотят остаться на 1.0.3 и подозреваю именно из-за большего количества расширений под эту версию.
Весь вопрос в том нужна ли версия 3.0 или стоит довести до ума 2.
2.0 мертв, после релиза как много контента вышло к нему по сравнению с 1.3? Сообщества нет, не кому что-то делать и адаптировать под то что не используется очень и очень малым кругом людей. Это не принесет прибыли а писать за просто так, увы на дворе не 2010 год.
Моя личная мысль нужно сделать новый двиг полностью не основывая его на какой-то одной цели и использовать в нем только само название Livestreet. Всё.
Но и тут ничего не будет, я больше чем уверен что кроме этих тем дело никуда не пойдет. Автор не будет сам писать весь код, а помогать ему за бесплатно тоже не будут. Никого это не интересует, пустая трата времени. Проще взять заказы на фрилансе, выхлопа и то больше будет. Не в обиду разработчику, но так и есть. Всё это пустая трата времени как своего так и чужого, подумайте над этим.
На чем основаны ваши суждения? У меня аккаунты на нескольких профильных вебмастерских форумах и несколько заказов в месяц идут именно на livestreet/altocms, в большинстве случаев приходится отказывать, т.к. не хватает готовых решений плагинов и до конца не ясна судьба CMS.
Что же вас останавливает?;)
Я уже давно не использую CMS, так как фреймворки сейчас настолько удобны, пакетов сейчас такое количество, что опытным проще взять и написать всё самому, чем влезать в прокрустово ложе CMS и молиться, что функционала хватит. Новичкам тоже выгоднее для собственного развития потратить месяц на самообучение фреймворку, а дальше накопипастить себе требуемый функционал.
Но конкретно LS хочется чтобы жило. В наше время миграции сообществ во вконтакт/телеграм/дискорд/гиттер/слак хочется дать вебу ещё один шанс.
Моё видение.
1. Берем за основу ls2 с его фреймворком — окей. Но я продолжаю настаивать, что надо использовать композер и делать фреймворк в виде его пакета, чтобы лайвстрит можно было использовать программистам, пишущим на симфони, ларавеле, yii2 и других фреймворках. Это позволит резко расширить аудиторию LS. Т.е. /framework переезжает в папку /vendor, которую делает composer, вместе с остальными пакетами. Остальное (аппликейшн, дизайн) находится в папках, пути для которых прописать в index.php в виде констант или конфига, чтобы можно было во фреймворке при подключении LS менять их. Загрузку классов можно оставить имеющуюся, не переводить всё на PSR-4. Я попробую сие сделать для прикидки.
2. Для мотивации разрабам нужен каталог. Нужен чел с ИП, или уговорить Максима всё возродить на базе его бухгалтерии с ООО, разобраться с Робомаркетом, как туда выгружать товары с ценами — и можно жить без онлайн-кассы.
3. По поводу совместимости плагинов ничего пока не скажу, так как слабо владею темой. Мне кажется, это будет сложно, затраты на ограничения в коде будут слишком большими. Ждём анализа от @olezhikz или других разрабов, плотно знакомых с темой.
И разрываться среди этих решений? Чем плох предложенный мной вариант по выносу функционала в плагины ядра? Имели бы один продукт с вариативностью использования.
Так в двойке и так все максимально просто. О каких махинациях с директориями идет речь?
Мобильный шаблон не нужен. Был же уже, особого спроса не было. Достаточно просто адаптивности. Большие проекты, в случае необходимости, смогут самостоятельно решить этот вопрос. А вот мобильное приложение очень даже хорошо бы было.
Совместимость не нужна. Перенос и доработка дополнений под текущую версию — да.
Это тоже не сильно-то необходимо, любой разработчик в силах развернуть демки у себя. Единственный плюс в данном случае — независимость каталога от разработчиков.
ИМХО, в первую очередь следует сосредоточится на самом движке и не распыляться на второстепенные задачи. Тот же запуск каталога не сильно важная задача, он может работать и в существующем режиме.
Вот некоторые модули из нынешнего application можно переместить и во framework. Возможно, сделав из них плагины, чтобы сделать actions для HTTP API.
Я так понимаю про права на запись в директории. Но без этого никак не обойтись, увы.
За адаптивность +1, @media в css прекрасно разруливают отображение на мелких экранах.
По путям: некоторые ведь вещи их и не касаются (голосование, к примеру), а с остальным же — можно ведь сделать просто отключение части функционала, урлы при этом просто будут убираться.
Смотрите: переделываем коллективные блоги в некоторый расширенный вид категорий (по сути они ведь и есть — категории), выносим в плагин и в их админке задаем настройки для урезания их полного функционала до функционала обычных категорий — название, описание (в данном случае, да, операции с урлами нужны). Далее, делаем отдельные плагины голосования, лички, активности и профилей. До кучи выносим отдельно комменты и делаем им надстройку для анонимных комментов. В итоге простыми манипуляциями юзер может получить кроме коллективного еще и обычный блог. Уже плюс.
Выносим топики в отдельный плагин и в ядро добавляем плагин для страниц — получаем возможность создавать простые статичные сайты. Вырубаем все, оставляя одну главную страницу и верстаем всевозможные лендинги. Уже доволи гибко и урлы в основном нужно только отключать, а не как-то изменять (тут уж простите, не программист, поэтому могу только предполагать).
Что хорошо в таком плане развития, на мой взгляд: все это можно делать частями, выпуская минорные версии. В таком случае и юзеры видят какое-то движение и функционал движка расширяется, да и трудозатраты на это дело, как мне кажется, не такие большие, как если бы был переезд на фреймворк. Опять же, можно в любое время остановиться, если никакого движения не образуется. Но это все лишь мои размышления, я не навязываю.
Вопрос в том, что для контент сайтов, лендингов, портфолио — уже есть готовые решения, которые (на мой личный взгляд) гораздо лучше для этого подходят.
С другой стороны у ls есть функционал, которого нет в других CMS. А именно пользовательский контент, может эту сторону и стоит развивать? Реализовать функции для легкого взаимодействия пользователя с системой. Если добавить в коробку ваш developer-kit под вторую версию с возможностью различного вывода контента — masonry и т.д., думаю количество новых проектов на ls вырастет в разы.
Вспомните самые продаваемые в каталоге — synio flow, social, developer-kit, Prestige.
Адаптивный шаблон не может конкурировать с приложением, конечно (а приложение на cordova и т.п. с WebView не может конкурировать с React Native). Но мобильное приложение — это большой кусок работы с внедрением в фреймворк API, jwt- или oauth-авторизации, плюс приложение надо делать точно под конкретную сборку сайта. До этого очень далеко. Пока для корректного отображения в мобильных браузерах достаточно адаптивности на css media queries.
Но тема почему именно pnotify действительно не раскрыта.
Вместо того что бы пилить функционал движка.
К чему я это? Ах, да. К тому, что проект «Livestreet» стал «дедушкой». Устаревшим и от того почти никому не нужным, кроме «родных» людей из редеющего с каждым месяцем сообщества. А все потому, что «Папашка» его разлюбил.
Мне действительно жаль наблюдать предсмертные судороги умирающего проекта, порядком затянувшиеся надо сказать.
:-) Будем оптимистами. Только это и остаётся. С уважением ко всем, Дмитрий.
Вы предлагаете сделать рЭбрЭндинг? DeadStreet?
Без комментариев…
Кому это надо? Сообществу, админу, что бы донатили.
Сделать широкие возможности, хорошую поддержку и как пирожки пойдут.
Да хоть на симфони, главное результат и время.