Страница 1 из 3

OkayCMS 3.0 beta описание технического развития системы

Добавлено: 09.08.2019, 09:30
OkayCMS
Уже долгое время мы ведем разработку новой, третьей версии системы.

Цели которые были поставлены, для реализации в новой версии:
1. Избавиться от директории API, которая содержит "кашу" классов.
2. Привести все сущности (товары, бренды) к единому интерфейсу.
3. Избавиться от класса "автозагрузчика" Okay.
4. Избавиться от RewriteRules в .htaccess, это файл настройки сервера, и там не должно быть логики работы приложения.
5. Более четко выделить в системе паттерн Front controller (в частности избавиться от директории ajax).
6. Изменить формат формирования SQL запросов.
7. Спроектировать систему таким образом, чтобы в будущем её можно было покрывать автотестами.

И конечно же постараться сохранить простоту системы.

Более детально по целям.

1.
Папка API содержала классы товаров, брендов... и классы Database, Design, Validate...
И даже здесь "каша" не заканчивалась. Класс Products содержит методы add_image(), update_image(), delete_image(), get_spec_images(), update_spec_images() и т.д.,
я думаю масштаб проблемы виден.
Поэтому мы папку API поделили на Entities и Core.
В папку Entities попали классы сущностей, которые наследуются от абстрактного Entity.
В папку Core попали классы, отвечающие за работу "ядра" системы.
Все классы ядра регистрируются в DI (Dependency Injection) контейнере, с обязательным указанием зависимостей, если таковые имеются.

Чтобы зарегистрировать сервис ядра, его нужно прописать в файле Core/config/services.php.
Прописываются они в виде массива, где ключ массива, это имя сервиса, значение еще массив, с ключами 'class' содержащим название класса сервиса и 'arguments', содержащим массив зависимостей.
Зависимости также должны быть зарегистрированными сервисами. Сервисы не могут содержать циклическую зависимость. В сервисе все зависимости нужно ловить в методе __construct() в таком порядке, как их указали в Core/config/services.php в arguments.

Сущностью считается что либо, что имеет свою таблицу в БД (исключением есть некоторые, хранимые данные в файлах) и имеющая CRUD операции.
Еще мы не выносили в отдельные сущности таблицы связей (ok_products_categories, ok_related_products...).
Чтобы создать сущность, нужно создать её класс в директории Entities и унаследовать его от абстрактного Entity (Okay\Core\Entity\Entity), который имплементирует интерфейс Okay\Core\Entity\EntityInterface.

В абстрактном Entity уже описаны стандартные CRUD методы.
Детальнее об CRUD методах:

get_product($id), get_brand($id) сейчас приведены к методу get($id)
get_products($filter), get_brands($filter) сейчас приведены к методу find($filter)
count_products($filter), count_brands($filter) сейчас приведены к методу count($filter)
delete_product($id), delete_brand($id) сейчас приведены к методу delete($ids) - принимает массив ID сущностей

Класс сущности должен содержать некоторые настройки (статические свойства класса).
protected static $table = '__products'; содержащее название таблицы сущности.
protected static $tableAlias = 'p'; содержащее алиас таблицы.
protected static $fields = ['id','url'...]; содержащее массив колонок сущности.
protected static $defaultOrderFields = ['name DESC','id DESC'...]; содержащее массив колонок с направлением сортировки по умолчанию.
protected static $searchFields = ['id','url'...]; содержащее массив колонок сущности, по которым должен происходить текстовый поиск (поддерживаются только колонки сущности).
Если нужен расширеный поиск (по другим таблицам) нужно переопределить метод filter__keyword($keywords).
protected static $alternativeIdField = 'url'; альтернативное поле, по которому будет происходить выборка в методе get($id) если $id передали как строку, иначе метод get($id) ищет по колонке id.

Если сущность мультиязычна, нужно добавить мультиязычные настройки
protected static $langFields = ['name','meta_title'...]; содержащее массив мультиязычных колонок сущности.
protected static $langObject = 'products'; название языковой таблицы сущности, без "ok_lang_"
protected static $langObject = 'product'; название сущности в языковой таблице без суфикса "_id" (в таблице "ok_lang_products" колонка "product_id")

Также если к сущности нужно добавить в выборке колонки, которых нет у самой сущности (это результаты подзапросов, колонки с других таблиц),
нужно заполнить массив protected static $additionalFields;

На этом конфигурирование сущности закончено.

Фильтрация результатов выборки.
Ранее нужно было в методе get_products($filter) описывать фильтры вида:

Код: Выделить всё

   if (!empty($filter['id'])) {
      $where .= $this->db->placehold(' AND p.id in(?@)', (array)$filter['id']);
   }
   
   if (!empty($filter['brand_id'])) {
      $where .= $this->db->placehold(' AND p.brand_id in(?@)', (array)$filter['brand_id']);
   }
   
   if (isset($filter['featured'])) {
      $where .= $this->db->placehold(' AND p.featured=?', intval($filter['featured']));
   }
   ...


и если присмотреться, все они фильтруют по определенным полям сущности.
Теперь, если нам нужно фильтровать по полю, которое равно полю или входит в массив значений, такой фильтр можно вообще не описывать,
здесь отработает "магический фильтр". Он сам определит тип данных, это строка (или int) или массив, и добавит соответствующее условие в WHERE
Пример.

Код: Выделить всё

$productsEntity->find([
      'brand_id' => [1,2,3],
      'featured' => 1,
   ]);


Построится запрос SELECT ... FROM ok_products WHERE p.brand_id IN (1,2,3) AND p.featured=1

Если же нужно добавить возможность фильтровать по индивидуальным фильтрам, или по полю сущности, с измененным алгоритмом (иначе от магического фильтра)
нужно описать protected метод filter__filter_name($value) {...} в классе сущности (Обратите внимание на два символа подчеркивания).

Пример.

Код: Выделить всё

$productsEntity->find([
      'category_id' => [1,2,3],
   ]);


нужно объявить метод, который на вход примет массив переданных id категорий
protected function filter__category_id($categoriesIds)

Код: Выделить всё

  {
        $this->select->join('INNER', '__products_categories AS pc', 'p.id = pc.product_id AND pc.category_id IN(:category_ids)');
        $this->select->bindValue('category_ids', $categoriesIds);
        $this->select->groupBy(['p.id']);
    }

Точно так же у сущности есть "магические" сортировки. Если передать в сортировку значение name, name_asc или name_desc
и у сущности есть поле name (не важно мультиязычное оно или нет), добавится автоматическая сортировка по этому полю в указанном направлении.

Если же нужно определить какую-то кастомную сортировку, нужно в классе объявить метод customOrder($order = null) {...},
который вернет массив колонок, по которым нужно сортировать

Пример.

Код: Выделить всё

protected function customOrder($order = null)
    {
        $orderFields = [];


// Пример, как реализовать кастомную сортировку.

Код: Выделить всё

 switch ($order) {
            case 'some_custom_order' :
                $orderFields = [
                    'visible',
                    'name'
                ];
                break;
        }

        return $orderFields;
    }


чтобы выбирать сущности в отсортированном виде, нужно перед методом find() вызвать метод order(...) который возвращает $this

Пример.

Код: Выделить всё

$productsEntity->order('name_desc')->find([
      'category_id' => [1,2,3],
   ]);


2. Выше уже описано, что все сущности приведены к единому интерфейсу Okay\Core\Entity\EntityInterface

3. Все классы окая теперь соответствуют стандарту PSR-4 и загружаются через composer autoload.

4. Файл .htaccess теперь используется только для настроек сервера (закрыть доступ, настроить кеширование...) и для реврайта запросов на index.php (Front controller).
Для роутинга теперь используется роутер https://github.com/bramus/router, с указанием роутов в файле Core/config/routes.php.
Роутом считается элемент массива, где ключ, это имя роута, а значение - ассоциативный массив параметров.
Обязательные параметры роута:
"slug" - содержит полное представление структуры урла в данном роуте (вид шаблона).
"params" - содержит массив с ключами "controller" содержащим имя контроллера для данного роута и "method" содержащего имя метода контроллера, который необходимо запустить.

В поле "slug" если какая-то часть роута является переменной (урл товара etc) нужно указывать эту часть как переменную "{$url}".
Имя переменной произвольно, но очень рекомендуется (дабы избежать путаницы) для частей роута, которые отвечают именно за URL сущности, переменной давать название "{$url}"
Впоследствии для slug "/products/{$url}" будет сгенерирован паттерн "/products/([^/]+)", если нужно для переменной {$url} задать другой паттерн, его можно указать в роуте
в параметре patterns, который содержит ассоциативный массив, где ключ это название переменной из поля slug, а значение regexp.
Также для переменных, которым назначена регулярка, как не обязательное (кол-во повторений от 0) можно задать значение по умолчанию, которое будет передано в метод контроллера.
Чтобы задать значение по умолчанию, нужно роуту добавить параметр defaults, который содержит ассоциативный массив, где ключ это название переменной из поля slug, а значение произвольный текст.
Пример:

Код: Выделить всё

   'category' => [
        'slug' => '/catalog/{$url}{$filtersUrl}',
        'patterns' => [
            '{$filtersUrl}' => '/?(.*)',
        ],
        'params' => [
            'controller' => 'CategoryController',
            'method' => 'render',
        ],
      'defaults' => [
            '{$filtersUrl}' => 'some string',
        ],
    ],


Далее, в методе контроллера можно "поймать" все переменные из роута по их названию, порядок значения не имеет.

т.е. в методе render() контроллера CategoryController URL "/catalog/detskie-igrushki" мы можем принимать переменную $url как аргумент
Пример:
public function render($url, $filtersUrl = '') {...}

Также ранее у нас был один класс Okay, который знал все обо всем. Теперь в методе контроллера, получить экземпляр класса сервиса ядра
или экземпляр класса нужного Entity можно через внедрение зависимости DI.
Для этого в методе контроллера, нужно указать дополнительный аргумент с указанием typehint нужного класса и DI контейнер автоматически передаст эти зависимости.
Пример:
В методе render() контроллера CategoryController
нам нужно работать с экземпляром класса Okay\Entities\CategoriesEntity и (реально не нужно, но например) Okay\Core\Comparison, и ловить переменные $url и $filtersUrl.

Код: Выделить всё

   use Okay\Entities\CategoriesEntity;
   use Okay\Core\Comparison;
   
   class CategoryController extends AbstractController
   {
      public function render(CategoriesEntity $categoriesEntity, Comparison $comparison, $url, $filtersUrl = '') {...}
   }


для генерации урлов, на странице, нужно использовать использовать smarty плагин {url_generator},
который принимает один, обязательный параметр route, содержащий имя роута.
Если роут имеет переменные в поле slug, нужно передать значения этих переменных, по их именам.
Например для роута категории, нужно вызывать так: {url_generator route="category" url=$cat->url}.
Еще можно добавлять параметр absolute=1 чтобы URL строился не отнисительный, а абсолютный.

5. Все обработки ajax-а теперь происходят в классах контроллеров. Т.е. создается отдельный роут для ajax-ов, например

Код: Выделить всё

'ajax_search' => [
        'slug' => '/ajax/search_products',
        'params' => [
            'controller' => 'ProductsController',
            'method' => 'ajaxSearch',
        ],
    ],


6. Сущности используют для построения SQL запросов queryBuilder Aura.SqlQuery
ссылка на документацию https://github.com/auraphp/Aura.SqlQuery/blob/3.x/docs/index.md
В каждом экземпляре класса сущности, есть свойство $select содержащее экземпляр класса Aura\SqlQuery\Mysql\Select

Посмотреть то что получилось уже сейчас можно скачав бета версию по ссылке

На данный момент разработка ещё ведется, но мы хотим услышать мнение наших пользователей о промежуточном варианте развития нашей системы и сделать её лучше вместе.

Добавлено: 09.08.2019, 10:33
trainracing
Короче последняя нормальная версия была 2.3.3
На нее хотя бы можно было существующие модули окай и симпла интегрировать. Новая версия - головная боль для разработчиков и темный лес для обычных пользователей, которые покупали модули и ставили их самостоятельно от старый версий окай. Например есть у меня купленные модули от 2.2.2 и на новые проекты в последней версией Уже не смогу поставить, только если разработчик заново перепишет модуль с нуля и заново за него платить

Добавлено: 09.08.2019, 10:45
Redleks
Все очень неплохо.

Вы движетесь в сторону своего фреймворка и это правильно. Я бы вынес его в отдельную папку src например.

Очень не хватает phpdoc.

Немного странный выбор роутера на мой вкус.

В качестве переходного этапа, в принципе, все хорошо и идет в логически правильном направлении. Если предусмотреть модульность и интеграцию с маркетплейсом из админки, как у опен карт, например, то пользовательский опыт будет удовлетворен :)

Добавлено: 09.08.2019, 10:50
le7andr
Интересно, что делать тем, у кого давно и далеко не стандартная CMS, а с установленными модулями по стоимости превышающими лицензию CMS? Снова оплачивать разработчикам за установленные модули?

Добавлено: 09.08.2019, 10:53
Redleks
le7andr писал(а):Интересно, что делать тем, у кого давно и далеко не стандартная CMS, а с установленными модулями по стоимости превышающими лицензию CMS? Снова оплачивать разработчикам за установленные модули?

Жить на старой версии.

Добавлено: 09.08.2019, 11:02
Julius123
Redleks писал(а):
le7andr писал(а):Интересно, что делать тем, у кого давно и далеко не стандартная CMS, а с установленными модулями по стоимости превышающими лицензию CMS? Снова оплачивать разработчикам за установленные модули?

Жить на старой версии.
Я так понимаю что да, большинству магазинов не видать новой версии т.к практически все магазины на Okay CMS с большим кол-вом доработок, обновление на новую версию будет затратнее чем создание нового магазина, на это никто не пойдет. Поэтому думаю должна быть хотя бы поддержка старой ветки CMS с исправлением багов.
И вопрос сможет ли ваша техподдержка обновить CMS на новую версию если магазин с доработками?

Добавлено: 09.08.2019, 11:41
OkayCMS
trainracing писал(а):Короче последняя нормальная версия была 2.3.3
На нее хотя бы можно было существующие модули окай и симпла интегрировать. Новая версия - головная боль для разработчиков и темный лес для обычных пользователей, которые покупали модули и ставили их самостоятельно от старый версий окай. Например есть у меня купленные модули от 2.2.2 и на новые проекты в последней версией Уже не смогу поставить, только если разработчик заново перепишет модуль с нуля и заново за него платить

Большинство претензий к текущему OkayCMS - что это код 2009 года обвешанный плюшками. И отчасти так и есть. Да, он работает и работает неплохо, но развитие системы в эту сторону - это тупиковая ветвь. Поэтому и было принято решение написать большую часть кода с нуля. С разработчиками мы будем договариваться, чтобы клиенты, купившие модули на старую версию получили бесплатно эти модули на новую версию, когда разработчики их напишут.


Redleks писал(а):Все очень неплохо.

Вы движетесь в сторону своего фреймворка и это правильно. Я бы вынес его в отдельную папку src например.

Очень не хватает phpdoc.

Немного странный выбор роутера на мой вкус.

В качестве переходного этапа, в принципе, все хорошо и идет в логически правильном направлении. Если предусмотреть модульность и интеграцию с маркетплейсом из админки, как у опен карт, например, то пользовательский опыт будет удовлетворен :)



le7andr писал(а):Интересно, что делать тем, у кого давно и далеко не стандартная CMS, а с установленными модулями по стоимости превышающими лицензию CMS? Снова оплачивать разработчикам за установленные модули?

Пользоваться уже сделанным, рабочим функционалом. Текущая версия тоже хороша и будет качественно работать еще как минимум несколько лет. Как показывает пример других CMS, даже когда разработчики их полностью забрасывают, они нормально работают ещё минимум лет 5. А в данном случае мы не будем бросать поддержку старой версии даже после выхода новой.

Julius123 писал(а):Я так понимаю что да, большинству магазинов не видать новой версии т.к практически все магазины на Okay CMS с большим кол-вом доработок, обновление на новую версию будет затратнее чем создание нового магазина, на это никто не пойдет. Поэтому думаю должна быть хотя бы поддержка старой ветки CMS с исправлением багов.
И вопрос сможет ли ваша техподдержка обновить CMS на новую версию если магазин с доработками?

Я бы не сказал что большинство магазинов с большим количество доработок. По поводу обновления до новой версии если магазин с доработками - пока ещё у нас есть только бета и однозначно на этот вопрос я вам ответ дать не могу, но скорее всего ТП будет осуществлять перенос данных со старой версии на новую. То есть вам на новую версию перенесут все товары, заказы, покупателей, но ваши индивидуальные доработки переноситься не будут.

Добавлено: 09.08.2019, 12:26
qwen
1. Модули придется покупать заново, потому что покупал давно и мне модули присылали на почту, скачать обновленные модули, возможности не предоставляется... это плохо!

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

3. Считаю статья в вашем блоге по адаптации модулей которые сами разработчики разрабатывали и как самостоятельные модули адаптировать для 3 версии - думаю будет актуально!

4. Разработанные множество своих модулей и работающие на 2.2.2 - 2.3.0 страшно представить как их вообще теперь интегрировать для 3 версии..., но придется адаптироваться... надеюсь вспомогательная статья в блоге появится.

5. Хотя лично мое мнение, лучше бы больше популярного функционала (модулей) напихали прям с коробки, (чтобы при установки на сайт уже были все модули и стабильно все было настроено и работало). Просто администратор в админке мог включать/выключать нужные или не требуемые модули и забыть, а не постоянно при каждом обновлении системы допиливать свои модули либо переносить/дорабатывать те которые ранее купил модули.

6. Также желательно чтобы оптимизировали CMS для работы с огромным количеством товаров (10 - 100 000) и около 1000 категор/подкатегорий.

7. и наконец-то, сделайте с коробки нормальный блог с возможностью разбивать на подкатегории, надоело при каждом обновлении переносить популярные модули с предыдущей версии в последующую.

Добавлено: 09.08.2019, 12:40
OkayCMS
qwen писал(а):5. Хотя лично мое мнение, лучше бы больше популярного функционала (модулей) напихали прям с коробки, (чтобы при установки на сайт уже были все модули и стабильно все было настроено и работало). Просто администратор в админке мог включать/выключать нужные или не требуемые модули и забыть, а не постоянно при каждом обновлении системы допиливать свои модули либо переносить/дорабатывать те которые ранее купил модули.

6. Также желательно чтобы оптимизировали CMS для работы с огромным количеством товаров (10 - 100 000) и около 1000 категор/подкатегорий.

Собственно у нас тоже такое желание, но в текущей реализации чем больше мы напихаем, тем менее стабильно это будет. Поэтому и решили сначала сделать новый, современный фундамент, а затем уже напихивать.

Добавлено: 09.08.2019, 16:22
Shalm
OkayCMS писал(а):Собственно у нас тоже такое желание, но в текущей реализации чем больше мы напихаем, тем менее стабильно это будет. Поэтому и решили сначала сделать новый, современный фундамент, а затем уже напихивать.

Очередное спасибо за нововведения. Очень ждал.
1. Когда ждать выход из beta в официальный релиз?
2. Стоит ли разворачивать новый сайт на beta или она пока предназначена только для ознакомления?
3. Чтобы ознакомиться с системой проще, по примеру старой версии, ознакомиться онлайн. Развернуть у себя демо магазина и админки не желаете? =) Сроки?

Добавлено: 09.08.2019, 16:26
Crypter
80 МБ - в архивном виде ??????

А мне вроде понравилось (фронт энд) вроде немного изменили - молодцы.

Добавлено: 09.08.2019, 17:42
genser
Crypter писал(а):80 МБ - в архивном виде ??????
там дэмо товары, картинки более 60 мб весят

Добавлено: 09.08.2019, 17:52
OkayCMS
Shalm писал(а):
OkayCMS писал(а):Собственно у нас тоже такое желание, но в текущей реализации чем больше мы напихаем, тем менее стабильно это будет. Поэтому и решили сначала сделать новый, современный фундамент, а затем уже напихивать.

Очередное спасибо за нововведения. Очень ждал.
1. Когда ждать выход из beta в официальный релиз?
2. Стоит ли разворачивать новый сайт на beta или она пока предназначена только для ознакомления?
3. Чтобы ознакомиться с системой проще, по примеру старой версии, ознакомиться онлайн. Развернуть у себя демо магазина и админки не желаете? =) Сроки?

1. В планах ещё примерно на 2 недели не очень важных фиксов связанных с мультиязычностью, 1С, различными улучшениями кода и т.д. Такие вещи, которые для беты простительны, а вот для релиза - стыдно.
2. Именно на этой бета полноценный сайт делать - не стоит, но если нужно пораньше, более качественная бета будет к концу следущей недели.
3. С момента сборки беты уже было сделано 26 мелких допилов http://prntscr.com/oqnazi и в рабоче ещё пачка. Демо будут отличаться от того что мы описали.

Добавлено: 09.08.2019, 18:01
Redleks
OkayCMS писал(а):26 мелких допилов http://prntscr.com/oqnazi

Оффтопик, а что за трекер задач используете?

Добавлено: 09.08.2019, 18:29
OkayCMS
Redleks писал(а):
OkayCMS писал(а):26 мелких допилов http://prntscr.com/oqnazi

Оффтопик, а что за трекер задач используете?

https://worksection.com/4455/

Добавлено спустя 3 минуты 57 секунд:
Redleks писал(а):
OkayCMS писал(а):26 мелких допилов http://prntscr.com/oqnazi

Оффтопик, а что за трекер задач используете?
SCRUM реально рулит. http://prntscr.com/oqnsww

P.S. На названия задач не смотрите, аврал всё таки. Обычно они более осмысленные :)

Добавлено: 09.08.2019, 19:37
makki
Очень приятно видеть, система развивается и в нужном направлении. Так держать. С нетерпением ждем релиз.

Добавлено: 09.08.2019, 20:12
OkayCMS
makki писал(а):Очень приятно видеть, система развивается и в нужном направлении. Так держать. С нетерпением ждем релиз.
Спасибо. Ваше мнение, как активного разработчика нам особо ценно.

Ждем ещё отзыв коршунова

Модули доставки

Добавлено: 10.08.2019, 06:00
makki
Пора бы уже сделать возможность подключать модули доставки, наподобие модулей оплаты. Обещали еще в начале 2-й версии. Для нее я уже не дождался, сам сделал, а вот на 3-й хотелось бы иметь такое с коробки.

Добавлено: 12.08.2019, 06:21
Crypter
Чисто теоретически:
1. Почему нельзя оставить 2 версию системы как есть и если есть желание ее развивать дальше то все могут в этом способствовать.
- оставить все дополнения, шаблоны и др разработки.

2. Отдельно развивать новую версию системы 3 - создавать или обновлять старые дополнения, шаблоны и др нововведения уже как новый товар.

При таком подходе пользователь (клиент) сам будет решать оставаться на версии 2 или переходить на 3 + дополнительно тратиться на обновленные под 3 версию.
Под 2 версию сторонние программисты потратили время и сделали дополнения, все есть у Вас в маркете, если хочет клиент что то лучшее то либо платит за обновление по 2 версии если таковы будут или приобретает новые дополнения под 3 версию.

Ну как то так.

Добавлено спустя 30 минут 37 секунд:
Проверьте:
1. Админка - Страницы - Список меню
выбираем любой пункт меню и пытаемся на странице редактирования меню изменить его Активность к примеру с включенного изменить на ВЫКЛЮЧЕННОЕ.
Image 1.png


Добавлено спустя 3 минуты 5 секунд:
2. Нет перевода
Image 2.png


Добавлено спустя 5 минут 55 секунд:
3. Во фронтэнде проверьте стили для отображения капчи при ее вводе.
Image 3.png


Добавлено спустя 1 минуту 50 секунд:
- о отображается ли текст в Админке после отправки сообщения. У меня сообщения небыло :((

Добавлено спустя 4 минуты 12 секунд:
4. В Админке найден новый язык для отправки сообщений админу - Georgian
Image 4.png


Добавлено спустя 5 минут 1 секунду:
5. Можно ли добавить вывод сообщения при очистке всего каталога от товаров?
Image 5.png


Добавлено спустя 5 минут 27 секунд:
6. В инпут поставить ограничение для текста
Image 6.png


Добавлено спустя 7 минут 44 секунды:
7. При заполнении платного способа доставки что то не хватает в инпутах
Image 7.png


Добавлено спустя 5 минут 31 секунду:
8. При добавлении нового менеджера появляется новый язык :((
Image 8.png


Добавлено спустя 5 минут 18 секунд:
9. При добавлении нового языка вылазит странное сообщение
Image 9.png


Добавлено спустя 5 минут 32 секунды:
10. Есть странность при редактировании языка - вылазит форма с кучей языков но ничего понять и сохранять не хочет :((
Image 11.png

Добавлено: 12.08.2019, 08:51
korshunov
Цель 1. "Избавиться от директории" - несерьезная постановка вопроса. Тем более если для этого проводить массу кардинальных изменений. Выглядит так, как будто мастера-программисты повесили заказчику лапшу на уши, что надо непременно разделить категорию на две, для чего им (мастерам) надо оплатить месяцы рабочего времени.
Цель 2. Звучит, конечно, хорошо и красиво.
Цель 3. Тоже цель несерьезная. По крайней мере объявлена несерьезно.
Цель 4. Звучит красиво, но масштаб вопроса мелковат, чтобы затевать такие большие передлки.
Цель 5. Аналогично 4.
Цель 6. Хорошо, конечно, но опять аналогично 4.
Цель 7. Вообще непонятно, что имется в виду. И в дальнейшем, в отличие от других целей, пояснений по этой почему-то не дано совсем.


В целом длинное описание предназначено для программистов. А что даст это простым пользователям CMS - владельцам магазинов, не очень понятно.
Например, в теме
viewtopic.php?f=9&t=177&p=817#p817
поставлен довольно простой, но часто возникающий у владелецев магазинов вопрос о добавлении новых полей.
Уважаемая поддержка много месяцев давала обещания, но толком за несколько лет ничего не сделала.
Можно предположить, что сделано настолько коряко и нерационально, что даже пером не описать.
Интересно, в новой версии можно ли легко и просто добавить поле? Если да, то написали бы парочку примеров, один для простого поля, другой для языкового, от и до, просто и понятно даже для неспециалистов...

Уважаемые разработчики! Спуститесь с небес на грешную землю. Хотелось бы описание не чисто формальное и абстрактное, как сейчас, а простое и понятное именно для пользователей CMS, а не только для программистов. Чтобы в нем фигурировали не абстрактные мутно описанные цели, а НОВЫЕ ВОЗМОЖНОСТИ для пользователей...


Crypter писал(а):Чисто теоретически:
1. Почему нельзя оставить 2 версию системы как есть и если есть желание ее развивать дальше то все могут в этом способствовать.
- оставить все дополнения, шаблоны и др разработки.

2. Отдельно развивать новую версию системы 3 - создавать или обновлять старые дополнения, шаблоны и др нововведения уже как новый товар.

Именно так и надо делать. По-моему, версию 3 надо выпускать как отдельный товар, или даже как отдельную CMS.