План развития

Итак. Что мы имеем в итоге. Сообщество в целом желает переезда, но из них малая часть готова принять участие в этом. Невозможность данной затеи очевидна, так как сил, денег, времени нет. Я не собираюсь браться за это в одиночку. Сообщество у нас маленькое. Так что давайте держаться вместе и не доводить до оскорблений. Конструктивной критики много. Нужно определиться с тем что делать или не делать дальше. Но даже для этого нужна какая то методология. У большинства высказавшихся безусловно имеется свое соображение на данную тему. И они выстраивают свою цепь задач, которые необходимы для начала работы. Я попытаюсь выстроить свою.
Базовое условие для жизни проекта — это ресурсы позволяющие ему развиваться и поддерживаться. Никто не сможет бесконечно вкладывать свое время и силы, если от этого нет толка. Так и livestreet, продолжал активно развиваться пока создатели видели смысл в этом. Личное развитие, интеллектуальный интерес, азарт, возможность применения наработок в своих проектах. Как только проект дорос до уровня, когда он стал функционально удовлетворять потребности и пропал первоначальный запал, он стал постепенно угасать. В этот момент еще и сыграли внешние факторы — очередной закон о запрете малого бизнеса в России. Тем не менее, благодаря упорству и таланту основателей в проект были заложены, как я считаю, весьма перспективные вещи. Я имею в виду например новую структуру шаблона и применение компонентов.
Но вернемся к основным задачам. Нужен ресурс. Им может быть на данном этапе только каталог и процент с продаж платных плагинов. Чтобы он заработал, нужны установки движка и соответственно заказы на плагины.
Чтобы были установки считаю нужным:
1. Упростить установку для пользователя. Чтобы ставилось в несколько кликов, без дополнительных махинаций с директориями.
2. Доработать стандартный шаблон. Добавить тем. Возможность выбора цветов в темах и прочее
3. Встроить во фреймворк возможность определения мобильного устройства. Это даст почву для доработки структуры шаблонов с включением в него мобильных версий. Не адаптивных, хотя их не кто не запрещает. Но чисто мобильного вида на основе, например framework7.Дело в том, что не всегда удобно использовать адаптивный шаблон, особенно если сайт разрастается функционалом и необходимо адаптировать его с разным отображением на PC и смартфоне. Это в свою очередь поднимет вопрос о мобильном приложении из коробки. Для чего останется лишь обернуть уже готовый шаблон в phonegap. Да, приложение не будет нативным, но это лучше чем ничего. В последствии можно качать эту тему, как преимущество.
4. Добавить вариативности. Определить, что сейчас востребовано на рынке. Ленденги, новостные сайты, блоги, и другое. Выбрать из этого, что нам больше по душе. Сделать несколько дополнительных репозиториев и начать работу над ними параллельно. Благо движок вынесен от фреймворка, на его базе можно сделать все что угодно.

А так же нужно привлечь разработчиков:
1. Взять за основу 2ю версию и сделать обратную совместимость с 1ой. По сути они отличаются только структурой шаблона, миграциями и некоторыми методами в модулях. Считаю это решаемая задача. Пусть даже и придется пожертвовать стройностью.
2. Расширить практику использования компонентов шаблона. Вплоть до вынесения в каталог. Это позволит frontend разработчикам осваиваться заходя с этой стороны. Что нам дают компоненты? Инкапсуляция в шаблонизаторе и javascript, через jquery виджеты. В результате прекрасная переносимость из проекта в проект. Останется только сделать, чтобы css не пересекался и не примешивался, и подгрузку компонентов динамически, чтобы грузились только необходимые в зависимости от запрашиваемой страницы.
3. Документация. Необходимо продумать документацию, и вынести ее на видное место. Добавить видео уроки по ключевым моментам. Примеры кода. Расставить все это в логичном порядке.
4. Условия и рекомендации. Написать для разработчиков рекомендации, по написанию кода с примерами. Выставить необходимые условия по качеству. Например можно ввести практику доработки, когда разработчику рекомендуется писать рабочий заготовок плагина, а в последствии дорабатывать его для конкретного клиента, что обычно и приходится делать. Это позволит экономить время самим разработчикам.
5. Бесплатное демо. Дать возможность показать готовое творение на нашем сервере. Для этого не потребуется большая нагрузка. Особенно если использовать один движок на всех, установленный по жесткой ссылке или монтированный из отдельной директории(для тех кто слышал о linux)
6. Начать пользоваться задачами на github. Там и карточки со списком задач есть. Документация для контрибьютеров должна быть обязательно. И вообще продумать какие нибудь бонусы для принявших участие, например процент от дохода каталога.

Теперь попрошу зарыть тему о переезде. И обсудить ваши предложения о дальнейших действиях.

39 комментариев

avatar
Взять за основу 2ю версию и сделать обратную совместимость с 1ой.
Совместимость с плагинами (с темами, насколько я понимаю, обратная совместимость невозможна)? А это реально?
avatar
Да это возможно. Нужно провести анализ, даст ли это существенный результат.
avatar
Дальнейшие действия — идти в след за ort `ом.
avatar
Поддерживаю. Тема переезда закрыта, обсуждать уже нечего. Лучше new_css сказать что-то сложно.
комментарий был удален
avatar
А какие именно траблы были с каталогом, кстати? Только 54-ФЗ с онлайн-кассой, или что-то ещё?
avatar
Нужно уточнять у Максима
avatar
Я вижу ещё, в качестве юрлица была зачем-то выбрана форма ООО, что увеличивает гемор отчётности. Ну и, получается, для развития лайвстриту требуется найти ИПшника с уже имеющейся онлайн-кассой, облачной или железной. Или просто ИПшника и юзать безкассовые решения типа Робомаркета. Есть среди нас такие?
avatar
А почему нельзя вынести все денежные операции в офшоры, как это сделал Юкоз? На тот же Кипр. Чтобы ничего не связывало с законодательством РФ.
avatar
Подозреваю потому, что стоимость регистрации офшора превышает возможную прибыль от каталога за несколько лет )
avatar
В офшорах ВСЯ экономика, не только Юкоз.
avatar
1. Запустить каталог, чтобы люди имели возможность публиковать свои расширения
2. По возможность делать документацию, мануалы, видео для второй версии
3. Выбрать 5-10 самых популярных плагинов для первой ветки и адаптировать их под двойку

1. Упростить установку для пользователя. Чтобы ставилось в несколько кликов, без дополнительных махинаций с директориями.
2. Доработать стандартный шаблон. Добавить тем. Возможность выбора цветов в темах и прочее
1. Достаточно видеоинструкции по установке, а время потратить на работу с расширениями
2. ИМХО стандартный шаблон сильно на любителя и толку от тем, если нет документации и возможности сделать под себя. Опять же нет адаптивности. Для большинства пользователей мобильные версии это темный лес, очень небольшой процент будет с этим заморачиваться, только если на сайте больше 1000 уников в сутки, для остальных адаптивности хватит с головой.

P.S. При любом раскладе, спасибо если будете развивать лайвстрит, по какому бы пути вы не пошли.
avatar
Я бы принял участие, являюсь так же разработчиком но тут увы, это гиблое дело.
LS хороший двиг под конкретную цель, а это коллективные блоги. Да, можно переделать под портал и под свой блог и под сми сайт и даже под онлайн магазин. Но первоначальный его функционал это что-то типа Хабра. И вот беды этого действия:
1. Обновлять двиг но оставлять его именно под эту цель не разумно. Насколько СНГ рынок нуждается в подобном продукте?
2. СНГ рынок. Хотите развивать движок? Иметь много сторонних разработчиков? Уходите с СНГ рынка и цель ставьте на западный.
3. Изменить цель движка. Сделать его простым для использования во всем не ставя перед ним конкретную цель делать что-то лучше в одном направлении.

Затея мертвая в ее начале, я просто не вижу смысла восстановление движка. Сообщество мертво, потому что двиг мертв. Даже если и будет продолжение движка его ждет такая же участь которая сейчас. Только потом вряд ли кто возьмется его опять воскрешать.
avatar
Добрый день!
Я тут новенький и прошу строго не судить.
Смотря на то что движок погибает и соглашусь с Gameer с тем что надо делать более функциональный движок под разные проекты.
Я предлагаю свое виденье со стороны обновить движок LS и дальше его развивать плюс сделать такой же движок но под разные цели и запускаться на западе. Есть имя LS соответственно людям будет интересно посмотреть что разработчики из LS сделали еще.
Я сам не программист но очень мне эта тема нравится но больше всего я люблю развивать. Если конечно меня подержите готов даже предложить разумное финансирование для разработки нового движка.
avatar
Вот человек sersar с прямыми руками сделал прекрасный сайт для своего проекта на alto. И хотя altocms в такой же Ж… как и LS — это не помешало ему выкинуть все лишнее из движка, обновить bootstrap и много еще что доработать под себя. Может есть смысл его пригласить поучаствовать в реанимации LS? Но люди должны быть мотивированы материально. Просто так никто свое время тратить не будет. Вот его проект о котором я затронул liferp.ru
avatar
Долго думал стоит ли вносить свои 5 копеек, но сколь меня упоминули, выскажусь. Постараюсь не разводить полемику.

Представленный план меня не устраивает. Те же грабли.

Каким я вижу план. Какой должна быть версия 3.0:
— Никакой (!) обратной совместимости с предыдущими версиями. Не надо городить огород и захламлять код лишним хламом.
— Убрать компоненты. Идея хорошая. Подгружать то, что надо. Но на деле возишься с мелкими файлами в которых надо найти связи с другими компонентами, а те в свою очередь с другими. В итоге имеем вермишель.
— Шаблон бутстрап 4 (админка тоже). Написанный блоками (как в альто). Очень быстро правится. Адаптивный.
— Принцип js скриптов как в версии 1.0.3.
— Разделить back-end и front-end по сути. Ядро РНР (framework) с которым можно работать в любом направлении и в будущем навешивать нужный функционал.

Структура примерно такая:
/app/ — в этой папке всё, что обновляется чаще всего в процессе разработки сайта.
/framework/ — “ядро” движка. Обновляется крайне редко.
/frontend/ — раздел в котором три категории: css, js, tpl. То что в движке по-умолчанию.
/vendor/ — Различные библиотеки (jquery, bootstrap и т.д.) которые обновляются не часто

Всё, что тут описал пришло из опыта написания сайта используя альто. Удобно работать. Обновлять библиотеки если требуется. И если построить LiveStreet 3.0 в таком плане, по моему субъективному мнению, то получится возродить движок.
avatar
— Никакой (!) обратной совместимости с предыдущими версиями. Не надо городить огород и захламлять код лишним хламом.

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

Какой должна быть версия 3.0
Весь вопрос в том нужна ли версия 3.0 или стоит довести до ума 2.
avatar
Весь вопрос в том нужна ли версия 3.0 или стоит довести до ума 2.
На мой взгляд стоит. Потому-что задача не только довести до ума движок, но и сайты привести к состоянию удобному к адаптации и развитию.
avatar
Для развития ls2, нужно выбирать — или делать обратную совместимость с плагинами для первой версии или адаптировать плагины под ls2. Потому что сейчас сложилась такая ситуация, что много пользователей хотят остаться на 1.0.3 и подозреваю именно из-за большего количества расширений под эту версию.
Есть авторы плагинов и они несут ответственность перед покупателями за то будут ли они адаптировать или нет. Или скупать все плагины и адаптировать их под 2.0?

Весь вопрос в том нужна ли версия 3.0 или стоит довести до ума 2.
2.0 мертв, после релиза как много контента вышло к нему по сравнению с 1.3? Сообщества нет, не кому что-то делать и адаптировать под то что не используется очень и очень малым кругом людей. Это не принесет прибыли а писать за просто так, увы на дворе не 2010 год.

Моя личная мысль нужно сделать новый двиг полностью не основывая его на какой-то одной цели и использовать в нем только само название Livestreet. Всё.

Но и тут ничего не будет, я больше чем уверен что кроме этих тем дело никуда не пойдет. Автор не будет сам писать весь код, а помогать ему за бесплатно тоже не будут. Никого это не интересует, пустая трата времени. Проще взять заказы на фрилансе, выхлопа и то больше будет. Не в обиду разработчику, но так и есть. Всё это пустая трата времени как своего так и чужого, подумайте над этим.
avatar
Есть авторы плагинов и они несут ответственность перед покупателями за то будут ли они адаптировать или нет. Или скупать все плагины и адаптировать их под 2.0?
Можно начать с бесплатных. И если уж на то пошло, если плагин пользуется спросом можно написать другой аналогичный по функционалу.
Сообщества нет, не кому что-то делать и адаптировать под то что не используется очень и очень малым кругом людей.
На чем основаны ваши суждения? У меня аккаунты на нескольких профильных вебмастерских форумах и несколько заказов в месяц идут именно на livestreet/altocms, в большинстве случаев приходится отказывать, т.к. не хватает готовых решений плагинов и до конца не ясна судьба CMS.

Моя личная мысль нужно сделать новый двиг полностью не основывая его на какой-то одной цели и использовать в нем только само название Livestreet. Всё.

Что же вас останавливает?;)
avatar
Принцип js скриптов как в версии 1.0.3.
Кстати, а как было с js в ls1 и что изменилось во второй версии?
avatar
Что-то меня зацепила судьба LS.
Я уже давно не использую CMS, так как фреймворки сейчас настолько удобны, пакетов сейчас такое количество, что опытным проще взять и написать всё самому, чем влезать в прокрустово ложе CMS и молиться, что функционала хватит. Новичкам тоже выгоднее для собственного развития потратить месяц на самообучение фреймворку, а дальше накопипастить себе требуемый функционал.

Но конкретно LS хочется чтобы жило. В наше время миграции сообществ во вконтакт/телеграм/дискорд/гиттер/слак хочется дать вебу ещё один шанс.

Моё видение.

1. Берем за основу ls2 с его фреймворком — окей. Но я продолжаю настаивать, что надо использовать композер и делать фреймворк в виде его пакета, чтобы лайвстрит можно было использовать программистам, пишущим на симфони, ларавеле, yii2 и других фреймворках. Это позволит резко расширить аудиторию LS. Т.е. /framework переезжает в папку /vendor, которую делает composer, вместе с остальными пакетами. Остальное (аппликейшн, дизайн) находится в папках, пути для которых прописать в index.php в виде констант или конфига, чтобы можно было во фреймворке при подключении LS менять их. Загрузку классов можно оставить имеющуюся, не переводить всё на PSR-4. Я попробую сие сделать для прикидки.

2. Для мотивации разрабам нужен каталог. Нужен чел с ИП, или уговорить Максима всё возродить на базе его бухгалтерии с ООО, разобраться с Робомаркетом, как туда выгружать товары с ценами — и можно жить без онлайн-кассы.

3. По поводу совместимости плагинов ничего пока не скажу, так как слабо владею темой. Мне кажется, это будет сложно, затраты на ограничения в коде будут слишком большими. Ждём анализа от @olezhikz или других разрабов, плотно знакомых с темой.
avatar
4. Добавить вариативности. Определить, что сейчас востребовано на рынке. Ленденги, новостные сайты, блоги, и другое. Выбрать из этого, что нам больше по душе. Сделать несколько дополнительных репозиториев и начать работу над ними параллельно. Благо движок вынесен от фреймворка, на его базе можно сделать все что угодно.

И разрываться среди этих решений? Чем плох предложенный мной вариант по выносу функционала в плагины ядра? Имели бы один продукт с вариативностью использования.

1. Упростить установку для пользователя. Чтобы ставилось в несколько кликов, без дополнительных махинаций с директориями.

Так в двойке и так все максимально просто. О каких махинациях с директориями идет речь?

3. Встроить во фреймворк возможность определения мобильного устройства. Это даст почву для доработки структуры шаблонов с включением в него мобильных версий. Не адаптивных, хотя их не кто не запрещает. Но чисто мобильного вида на основе, например framework7.Дело в том, что не всегда удобно использовать адаптивный шаблон, особенно если сайт разрастается функционалом и необходимо адаптировать его с разным отображением на PC и смартфоне. Это в свою очередь поднимет вопрос о мобильном приложении из коробки. Для чего останется лишь обернуть уже готовый шаблон в phonegap. Да, приложение не будет нативным, но это лучше чем ничего. В последствии можно качать эту тему, как преимущество.

Мобильный шаблон не нужен. Был же уже, особого спроса не было. Достаточно просто адаптивности. Большие проекты, в случае необходимости, смогут самостоятельно решить этот вопрос. А вот мобильное приложение очень даже хорошо бы было.

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

Совместимость не нужна. Перенос и доработка дополнений под текущую версию — да.

5. Бесплатное демо. Дать возможность показать готовое творение на нашем сервере. Для этого не потребуется большая нагрузка. Особенно если использовать один движок на всех, установленный по жесткой ссылке или монтированный из отдельной директории(для тех кто слышал о linux)

Это тоже не сильно-то необходимо, любой разработчик в силах развернуть демки у себя. Единственный плюс в данном случае — независимость каталога от разработчиков.

ИМХО, в первую очередь следует сосредоточится на самом движке и не распыляться на второстепенные задачи. Тот же запуск каталога не сильно важная задача, он может работать и в существующем режиме.
avatar
Сделать несколько дополнительных репозиториев и начать работу над ними параллельно
И разрываться среди этих решений? Чем плох предложенный мной вариант по выносу функционала в плагины ядра? Имели бы один продукт с вариативностью использования.
У разных сайтов разный набор урлов, и разный набор контроллеров, эти урлы обрабатывающих. Контроллеры в LS завязаны с роутингом и находятся в application/classes/action. Делать разные сборки придётся, по-другому никак, мне кажется. Можно переместить все контроллеры во фреймворк, но тогда нужен будет какой-то конфиг, где ненужные контроллеры будут отрубаться, и вообще всё будет менее гибко.

Вот некоторые модули из нынешнего application можно переместить и во framework. Возможно, сделав из них плагины, чтобы сделать actions для HTTP API.

О каких махинациях с директориями идет речь?
Я так понимаю про права на запись в директории. Но без этого никак не обойтись, увы.
За адаптивность +1, @media в css прекрасно разруливают отображение на мелких экранах.
avatar
Хз, с правами на запись с позапрошлой версии не сталкивался. Если только перенос сайта, но там ведь и инсталяху запускать не нужно…

По путям: некоторые ведь вещи их и не касаются (голосование, к примеру), а с остальным же — можно ведь сделать просто отключение части функционала, урлы при этом просто будут убираться.

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

Выносим топики в отдельный плагин и в ядро добавляем плагин для страниц — получаем возможность создавать простые статичные сайты. Вырубаем все, оставляя одну главную страницу и верстаем всевозможные лендинги. Уже доволи гибко и урлы в основном нужно только отключать, а не как-то изменять (тут уж простите, не программист, поэтому могу только предполагать).

Что хорошо в таком плане развития, на мой взгляд: все это можно делать частями, выпуская минорные версии. В таком случае и юзеры видят какое-то движение и функционал движка расширяется, да и трудозатраты на это дело, как мне кажется, не такие большие, как если бы был переезд на фреймворк. Опять же, можно в любое время остановиться, если никакого движения не образуется. Но это все лишь мои размышления, я не навязываю.
avatar
Делаю проект один, и там как раз весь функционал (кроме пользователей) вынесен в разные плагины — страницы, фото, новости, документы и т.п.
avatar
Выносим топики в отдельный плагин и в ядро добавляем плагин для страниц — получаем возможность создавать простые статичные сайты. Вырубаем все, оставляя одну главную страницу и верстаем всевозможные лендинги. Уже доволи гибко и урлы в основном нужно только отключать, а не как-то изменять (тут уж простите, не программист, поэтому могу только предполагать).

Вопрос в том, что для контент сайтов, лендингов, портфолио — уже есть готовые решения, которые (на мой личный взгляд) гораздо лучше для этого подходят.

С другой стороны у ls есть функционал, которого нет в других CMS. А именно пользовательский контент, может эту сторону и стоит развивать? Реализовать функции для легкого взаимодействия пользователя с системой. Если добавить в коробку ваш developer-kit под вторую версию с возможностью различного вывода контента — masonry и т.д., думаю количество новых проектов на ls вырастет в разы.
avatar
У ЛС с нынешним функционалом слишком ограниченная аудитория, чтобы собрать достаточное для развития сообщество, никакие шаблоны здесь не помогут, необходимо расширение возможностей. Приведенный мною вариант развития видится мне самым оптимальным из возможных.
avatar
Собственно адаптивный вывод контента плиткой и расширяет возможности системы. 90% пользователей сразу смотрят на шаблон и его возможности.

Вспомните самые продаваемые в каталоге — synio flow, social, developer-kit, Prestige.
avatar
Вынесение в плагины разобьет и шаблон. Но в целом можно идти по этому пути.
avatar
Увидеть бы пример удобного, адаптивного, шаблона, который мог бы поконкурировать с приложением. Я ведь к чему веду. Мобильный шаблон, который оснащен удобством и фичами приложения: выпадающее меню, слайдеры отзывающиеся на свайп, всплывающие окна, итд.
avatar
А что такое «мобильный шаблон» тогда? Это же в любом случае html+css? А там невозможны ни свайпы, ни родные всплывающие окна, это модули cordova или т.п. инструментов. Или нет?

Адаптивный шаблон не может конкурировать с приложением, конечно (а приложение на cordova и т.п. с WebView не может конкурировать с React Native). Но мобильное приложение — это большой кусок работы с внедрением в фреймворк API, jwt- или oauth-авторизации, плюс приложение надо делать точно под конкретную сборку сайта. До этого очень далеко. Пока для корректного отображения в мобильных браузерах достаточно адаптивности на css media queries.
avatar
Ошибаетесь. Все возможно. Поглядите framework7.io. Нативное приложение это само собой круче. Но это уже пусть решают по конкретному проекту. Для блог платформы это приблизительно одно и тоже.
avatar
А, в браузер отдаётся приложение на js, которое всё рисует? Да, ты прав, можно и так. PS Из новых есть ещё quasar-framework.org/, на vue.js
avatar
Раз уж тут принимаются предложения, оставлю это здесь sciactive.com/pnotify/#demos-simple
avatar
К чему? Это вроде демо нотификатора…
avatar
предложение использовать этот нотификатор.
avatar
Почему именно этот? Чем нынешний из 2.0 не устраивает? Мне кажется не хватает аргументов… И, наверное, с этим лучше сюда
avatar
На нынешний нельзя забиндить, например, обработчик по клику. Или изменить лэйаут.

Но тема почему именно pnotify действительно не раскрыта.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.