Rapida Форк на базе simpla 2.3.8

## =================
## v0.0.8.1.9 09.12.2017
## =================
### bugs:
### improvements:
- Добавлена возможность группировки свойств товаров.
 
Rapida v0.0.8.1.10

## ****************
## Changelog
## ****************

## =================
## v0.0.8.1.10 18.12.2017
## =================
### bugs:
- Много мелких ошибок повсюду. И их все еще очень много. Теперь ошибок будет меньше, поскольку новые функции пишу сразу с модульными тестами к ним.

### improvements:
- Сохранялка бекапов теперь не трогает изображения. Т.е. при сохранении изображения не сохраняются в бекап, а при восстановлении не удаляются, если файлы были.
- Переписан класс ControllerResize. Теперь он может выдавать содержимое изображений в режиме докачки (понимает http заголовок range).
- В целях облегчения модульного тестирования дебагер можно вызвать для вывода информации в консоль.
Обычный вызов dtimer::show() выводид информацию в HTML формате, что удобно для отладки из браузера. Для отладки из консоли добавлен метод dtimer::show_console().
- Полностью переписан класс image и products в части изображений. Изображения теперь хранятся в /img
Теперь любая сущность в системе может иметь дополнительные изображения, в том числе бренды, категории, статьи блога. Принцип хранения изображений полностью унифицирован. Теперь в основной таблице какой-то сущности хранится основное изображений, а в таблице изображений этой сущности остальные изображения. Например, Для товара с id 1 в записи в таблице s_products есть поле image, в котором хранится запись об основном изображении. Например, image123.png. В таблице s_img_products для этого товара хранятся следующие записи:
id │item_id │basename │pos
──┼───────┼───────────-─┼─────
1 |1 |image123.pn |0
2 |1 |image124.png |1
3 |1 |image125.png |2

Изображение с pos 0 является основным, запись о нем копируется в основную таблицу.
Аналогичные таблицы создаются и для остальных сущностей. бренды, категории, статьи блога. Работа с изображения осуществляется с помощью следующих методов:
get($type, $filter)
update($type, $item_id, $basename)
delete($type, $id)
add($type, $item_id, $basename)
download($type, $image_id)
download_new($type, $item_id, $url)
upload($type, $basename)

Перечень $type соответствует названию основной таблицы сущности.
'products' для s_products;
'brands' для s_brands;
'blog' для s_blog;
'categories' для s_categories.
 
Здравствуйте, как обстоят дела с производительностью, при ~200к товаров и ~6к категорий?
Сейчас магазин на симпле, заметно притормаживает если в категории много вложенных подкатегорий с товарами.
 
Здравствуйте. Возможно, мой вопрос глупый, но прошу не сильно бросаться помидорами.. При установке почему-то ошибка 500 не проходит. Что я делаю не так?
 
Здравствуйте. Возможно, мой вопрос глупый, но прошу не сильно бросаться помидорами.. При установке почему-то ошибка 500 не проходит. Что я делаю не так?

Сложно сказать - слишком мало информации.

Ошибка 500 вылетает во многих случаях. Напиши как устанавливал. Если установка была из github, то там нет конфига БД (config/db.ini).
Что-то там 5xx вылетает, если клонировать с гита в корень веб сервера и сразу попытаться зайти.

2 варианта установки.
1. Из дистрибутива, ссылки есть в 1 сообщении.
2. Из гита.

При установке из гита необходимо выполнить последнюю стадию "установка и настройка бд". После копирования/клонирования запускаем в браузере site.com/install.php?step=database Настраиваем БД и пользуемся.

Для нормальной работы необходимо иметь следующие расширения php (пишу сразу названия пакетов:
php-mbstring (для разных манипуляций с текстом)
php-curl (для работы с внешними источниками изображений)
php-imagick (опционально - если его нет, будет использоваться gd)
 
Здравствуйте, как обстоят дела с производительностью, при ~200к товаров и ~6к категорий?
Сейчас магазин на симпле, заметно притормаживает если в категории много вложенных подкатегорий с товарами.

6к категорий не тестировал, но товаров заливал 2м - все отлично работает. Дай экспорт своего товара потестируем на твоем кол-ве.
 
6к категорий не тестировал, но товаров заливал 2м - все отлично работает. Дай экспорт своего товара потестируем на твоем кол-ве.
Спасибо, разобрался, по аналогии с вашим кодом настроил memcached и закешировал все тяжелые запросы. Сейчас летает, до этого генерация страниц занимало 3-9 секунды.
 
Новая версия. Все ближе к релизу бета версии.

## ****************
## Changelog
## ****************
## =================
## v0.0.8.1.10 b9 24.12.2017
## =================
### bugs:
- Исправлены скрипты в способах оплаты (/payment) с учетом того, что теперь все структурированные данные хранятся в массивах, а не в объектах.
- Мелкие исправления стандартного шаблона в части уведомлений пользователя о заказе.
- Исправлено баг в стандартном шаблоне с одновременным добавлением сразу 2 единиц товара за за клик. Исправлена ошибка в библиотеке jquery. При тестировании плугина bender, который сжимает и собирает в бандлы css и js к jquery примешались другие js скрипты из-за чего товар добавлялся в корзину дважды.

### improvements:
- В настройки добавлен параметр "телефон". Доступ из шаблона {$settings->phone}
- Для категорий и товаров добавлено 2 поле для адресе - url2. Предназначено для переезда с другой системы для сохранения видимости в ПС. При попадании на товар или категорию по 2 адресу будет производится redirect 301.


## =================
## v0.0.8.1.10 b8 23.12.2017
## =================
### bugs:
- Окончальтельно изменены названия полей в БД, отвечающих за позицию (position), теперь везде pos
- Изменения плугина smarty resize (api/Design.php). Теперь в случае ошибки в параметрах плугина страница все равно загружается полностью, ошибки аргументов выводятся через dtimer::log().
- Ошибки в метода get_prev_product() get_next_product()
- Мелкие ошибки в тех местах, куда еще не добирался, в том числе в метках заказов, шаблонах уведомлений при заказе

### improvements:
- В случае ошибок в запросе теперь в dtimer::log выводится не только сам запрос, но и метод его вызвавший.
- Добавлен новый метод results_array_grouped() в класс db. Теперь можно получить сгруппированные данные не в одномерный массив, который получается методом results_array(), а двумерный массив, где на первом уровне ключи из заданного поля БД, а на втором уровне все строки, у которых данное поле совпадает.
 
Последнее редактирование:
почти все, что заявлено, как преимущества

1. Давайте по существу. Что именно выпилено, что добавлено, почему вы считаете это преимуществами или наоборот. В гит-портянке ни разу не видно.
2. Сразу из коробки ваше детище не работает.
3. Куда слать баг-реквесты когда разберетесь с п.1 и п.2
 
1. Давайте по существу. Что именно выпилено, что добавлено, почему вы считаете это преимуществами или наоборот. В гит-портянке ни разу не видно.
2. Сразу из коробки ваше детище не работает.
3. Куда слать баг-реквесты когда разберетесь с п.1 и п.2

Софтина на ранней стадии разработки, поэтому работает соответствующе. Что выпилено, что добавлено написано в readme.md, если там не видно, то больше нигде нет, сам я подробности помню смутно. Если не вдаваться в детали.
Сделано следующее:
1. Все данные переведены из объектов в массивы, потому что с массивами в php гораздо удобнее работать.
2. Вся маршрутизация переведена из htaccess в отдельный контроллер, за счет чего система легко включается на nginx
3. Структура базы в части хранения свойств изменена для повышения быстродействия. Теперь все свойства хранятся в горизонтальной таблице, а не в вертикальной, как было в симпле.
4. За счет того, что все данные теперь только в ассоц. массивах эти данные легко можно serialize/unserialize любым способом var_export() serialize() JSON_ENCODE() на этом принципе построен кеш. 1 кеш в БД, которых хранит только целые числа. Сделан для сохранения затратных вычислений кол-ва товаров count_products(). 2 кеш для методов, которые выдают массивы get_products() get_options() он хранится на диске.
5. Для работы кеширующего механизма в системе имеется механизм очереди заданий, который служит для отложенного обновления данных кеша. Данные кеша не имеют ttl и обновляются по мере обращения к нему. Обращение к кешу - сохранение кеша, выдача результата. Повторное обращение к кешу - выдача данных из кеша, добавление в очередь заданий задачи на обновление кеша. Такой подход позволяет постоянно обновлять кеш в отдельном потоке, который влючается через cron, при этом пользователю всегда доступные данные из кеша. Данные о цене товара и количестве не кешируются.
6. Переписан механизм работы с изображениями. Подробности есть в README.MD


Из коробки работает прекрасно. Устанавливаю то здесь, то там по несколько раз в день. В чем конкретно проблема?

Баг реквесты можно слать в git можно сюда, а можно в телеграм канал t.me/rapidacms
 
Назад
Сверху