Чего не хватает EWC

EWC развивается семимильными шагами, Павел очень продуктивен, этого у него не отнять. Тем не менее количество рабочих сайтов на EWC крайне мало. Мне кажется, что причиной тому слишком большая универсальность. С одной стороны продукт обладает очень большим функционалом, огромное количество настроек, новые фичи с календарем, СП и т.д., с другой стороны в каждом конкретном модуле есть свои недостатки. По-моему скромному мнению, необходимо, в первую очередь, допилить функционал интернет-магазина, остро нехватает вложенности каталогов (практически у каждого популярного движка эта вложенность неограничена), также добить до логического конца синхронизацию с МойСклад и 1С, а также может в более простой форме сделать характеристики. Затем решить вопрос с СП или забросить окончательно или внедрить функционал, который позволит запускать на базе EWC полноценный сайт по СП. И затем продолжать развивать портальный функционал (CRM и т.д.). Как-то так...
У кого какие мнения на данный счет? критикуйте, предлагайте свое, приглашаю к дискуссии....Ну и мнение Павла, конечно, очень хотелось узнать на этот счет

Павел, по-моему, это стратегическая задача, как уже писал выше, без parent-child категорий совсем никак, потому что никто не будет урезать свою каталогизацию из-за ограниченных возможностей движка и к тому же, обмен с 1с и МойСклад становится бессмысленным потому как он не будет работать при уровне вложенности более 2х (а это 90% случаев по моему мнению)

Скорее всего да, только вот CRM это достаточно трудоемко в написании, сложно в продвижении и все-таки серьезная CRM это уже отдельный проект, если уж и заниматься, то нужно забросить остальное, иначе получится недопродукт.


Во-первых, нужно задокументировать создание шаблонов, затем снять подробное видео как он делается с объяснением подробностей, тогда количество желающих делать шаблоны самостоятельно сильно увеличиться, тратить время единственного разработчика на создание шаблонов, при том, что есть более важные цели, мне кажется не целесообразным.
Во-вторых, малое количество шаблонов для EWC вполне закономерно ввиду малого количества действующих сайтов на EWC. Нужно доработать интернет-магазин, отполировать его до блеска, и потом уже продвигать, в том числе через дилеров/партнеров. А пока что продукта как такового нет, есть куча функционала, в котором сложно разобраться и есть стратегические недочеты, которые не позволяют создавать на EWC серьезные проекты.

Смотря что имеется ввиду. Разработчиков, которые будут помогать работать над кодом EWC или внедренцев, которые будут его продвигать. Повторюсь, для начала нужно доработать до ума функционал интернет-магазина, затем немного покачать его в плане продвижения для простых юзеров (показать как просто пользоваться EWC, как с нуля запустить и настроить магазин и т.д.), а затем уже можно монетезировать по-маленьку (но только тогда, когда количество реальных сайтов на EWC увеличится на порядок).
В общем и целом нужно с вектором развития определиться. Пока что усилия распыляются на несколько направлений, EWC на данный момент это монстр, а монстров боятся, нужно его причесать, где-то подрезать, где-то умыть, чтобы получилась мощная, но управляемая зверюшка, а не дикий бизон
Я с интересом уже несколько месяцев наблюдаю за проектом, порываясь что-нибудь запустить на нем, но, к сожалению, все мои порывы упираются в функциональные ограничения движка. И похоже придется свою задумку запускать на Диафане, например, хотя почти каждый день захожу на форум в ожидании...а вдруг

Не могу понять, каким образом создавать товары с parent-child

Давайте рассуждать.

Раздел переделать в Parent
Подраздел переделать в Child

Пусть это будут к примеру номера какие нибудь
к примеру раздел=1 подраздел=2
вместо предыдущей записи
?catid=1_2
будет
?parent=1&child=2

теперь создадим подраздел
?parent=2&child=3

что по старому будет ?catid=2_3

Поэтому смысла менять старую запись не надо. все нормально как было ?catid=2_3 это хорошо.

Можно было бы даже оставить по старому ?catid=avto_audi, но без номеров может произойти коллизия:
к примеру такая структура:

Авто
-Ауди
--шины
--запчасти
---рули
---глушители
-БМВ
--шины
--запчасти
---рули

приведет к тому что будет 2 одинаковых раздела Запчасти/Рули

а если уникально нумеровать, то не приведет к такому.
значит решили, что будем нумеровать.
но тогда надо где-то хранить названия этих разделов и сами главные Parent-ы

я смогу это сделать на основе готового модуля public

Или может сразу сделать файловую структуру с папками, в которых будут лежать индексные базы?

корневая папка items
в ней папки с языками rus uam eng (если есть)
в них папки: auto
в ней папки: audi и bmw
в них папки zapchasti и shini
а в них уже сами базы или index.php со всеми настройками, куда смотреть и какую индексную базу брать, где кеш и т.п. и require (path_to_root/index.php);

тогда очень легко будет работать и иметь доступ к нужным товарам через их путь:
http://SITE/items/rus/auto/audi/zapchasti/ruli/index.php
в первых не надо будет указывать язык, и так все понятно.
во вторых там можно хранить кеш и сами индексные базы
в третьих это какой никакой а ЧПУ, причем реальный

В каждой папке будет лежать свой файл .idx с названием на родном языке этой папки и его номеров parent и child id (как в модуле паблика) всегда можно переименовать, не трогая название папки.
т.е. можно обратиться к товарам по прежнему &catid=1_2 ( &catid=zapchasti_ruli вызовут коллизию)

переделывать базу не надо будет.
старые ссылки 2-х уровневые будет работать по старому (они же без коллизии)
db_index.txt останется прежний
у товаров останется прежний unifid и item_id
поиск, аксессуары будут раотать по прежнему, ведь мы не трогали ничего в db_index

просто для многоуровневых баз надо будет создать пабликом все разделы заранее, а потом указать из текущей базы их parentы и childы (или файл индексной базы), иконки разделов, описания разделов, может настройки заодно внешнего вида и варианта выдачи. после чего можно отключить левое меню и перейти на систему паблика. придется только переделать главную витрину и хлебные крошки.
Кстати что показывать при промежуточных путешествиях по хлебным крошкам? к примере в разделе audi?
Самое простое - разделы (папки) с иконками.
Не выводить же весь audi товар?

Как вам?

минусы - это то что разделы могут оказаться пустые, если там нет товара, но это как-то решить можно.

А вот собственно скрин из базы диафана, 2 таблицы в базе: parent и child

Как это где? О_о Верхний скрин, допустим
Категория =>Продукты питания id=3, parent_id=0, т.е. категория высшего уровня, родителей нет
Категория=>Детское питание id=4, parent_id=3, т.е категория имеет родительскую категорию "Продукты питания"
Категория=>Десерты и пудинги id=5, parent_id=4, т.е. категория имеет родительскую категорию "Детское питание", у которой родительская "Продукты питания"..получается Продукты питания=>Детское питание=>Десерты и пудинги

А нижний скрин это таблица со всеми категориями 2го уровня и ниже, т.е. у которых есть parent.

блин вот +1 триллион сексилионов лайков. Разрабов привлеч - да начните хотя бы с меня, только без комментов в коде ноги сломать можно, это я как разраб говорю. Всё упёрлось в файлы, не любовь к базе - это я проходил ещё в 20-ных годах, тогда мне один хороший человек пояснил - "у тебя есть интерфейс, и срать тебе должно на то, файлы, базы, хоть облако" (на тот момент облачных таких вот как сейчас не было и понятие облако было не тем, что имеется ввиду сейчас и является в сущности). Используем процедуры "запроса из базы", и реально нам до балды что за хранилище. И вот когда Павел это поймёт, а точнее осознает необходимость, тогда система зашагает дальше. А пока, к великому моему сожалению, система развивается только в области хранения данных в файлах. Павел, да сами сделайте "прокладку", либо возьмите готовый интерфейс взаимодействия с хранилищами и прикрутите. После этого можно будет версию уже сделать 8.0.1. Шаг будет громадный.
Дам пару размышлений (если будет интерфейс, что позволит просто с файлами, базами работать), для примера возьмём клиента у кого база в MySql(MariaDB)/Postgree:
- он используя любой сторонний продукт (ДАЖЕ MS EXCEL!) сможет сделать нужные изменения
- если у него Postgree, то он может юзать функции, процедуры, с базой творить он сможет что хочет, типа авто обновления количества товаров, отзывов, да что угодно, это уже от самой системы баз зависит, а Postgree охеренная система с странзакциями, MySQL всё обещают, но давно тажа MSSQL вообще в лидерах на уровне обычных домашних юзеров.

УНИВЕРСАЛЬНОСТЬ - это так называется. КАМЕНЬ, я уверен, об этом ведёт речь, я могу ошибаться. Вы сфокусировались на файлах. Это ошибка. Надеюсь ВЫ НАС УСЛЫШИТЕ.

И еще круть, я хочу начать хранить ВЕСЬ ДВИЖОК (или наиболее часто используемые функции) в Рамдиске. Ну возможно даже в самом мемкеше. это должно ускорить немыслимо работу и облегчить доступ к дискам. правда это сожрет немного памяти.