shake1
Хранитель порядка
- Регистрация
- 16 Янв 2013
- Сообщения
- 534
- Реакции
- 608
304 не отдает
Для просмотра ссылки Войди
Для просмотра ссылки Войди
Rapida Форк на базе simpla 2.3.8
- Автор темы babahalki
- Дата начала
Для просмотра ссылки Войди
Для просмотра ссылки Войди
babahalki
Постоялец
- Регистрация
- 6 Май 2016
- Сообщения
- 247
- Реакции
- 107
- Автор темы
- #102
Да, надо сделать. Вопрос в том, по какому принципу делать. Честный и обновляемый где-то в БД lastmodified или просто какой-то недельный выводить все время. Насколько я знаю поисковикам плевать на это, они сами решают были ли изменения.
babahalki
Постоялец
- Регистрация
- 6 Май 2016
- Сообщения
- 247
- Реакции
- 107
- Автор темы
- #103
Новая версия Rapida 0.0.8.1.5
Есть в виде дистрибутива:
Для просмотра ссылки Войдиили Зарегистрируйся
# RAPIDA Ecommerce CMS
## SimplaCMS 2.3.8 fork
##IMPORTANT INFO
Для работы системы на сервере Nginx необходимо прописать следующую инструкцию в конфиг.
```
location / {
try_files $uri $uri /index.php$is_args$args;
}
```
## ****************
## Changelog
## ****************
## =================
## v0.0.8.1.5 21.12.2017
## =================
### bugs:
- Исправлен класс api->pages в части возвращаемых значений, теперь тут тоже возвращаются массивы, а не объекты. Теперь исправлено теоретически везде, что заметно упрощает адаптацию шаблонов. Простой шаблон адаптируется за 2 клика. Файлы шаблона обрабатываются 5-6 однострочными perl скриптами, которые делают замену кусков кода по регулярным выражениям.
- Исправлена ошибка для работы аякс поиска по старой симпловской схеме ajax/search_product.php. Удобно для шаблонов от симплы.
- Исправлены ошибки в контроллерах view/*. Изменено $page->var на $page['var'].
- Исправлены настройки полей в БД в связи с ошибками на некоторых версиях mysql.
- Исправления ошибок в стандартном шаблоне.
- Исправлена ошибка в features->get_products_ids() влияла на процесс преобразовании ЧПУ в id свойств и id значений свойств.
- Исправлена ошибка simpla/ajax/import.php, при импорте использовался кеш сразу с самого начала загрузки, что приводило к использованию устаревших данных. Теперь на первом цикле сначала загружаются данные без кеша.
- Устранена проблема загрузки изображений по товарам у которых эти изображения скачивались с удаленного сервера. Была проблема при обновлении страницы в связи с тем, что после загрузки изображения информация в БД изменялась (вместо ссылки записывается имя файла), а в кеше, она еще не обновилась. При попытке открыть изображение по старой ссылке изображение не отображалось. Теперь изображения на удаленном сервере передаются html не в виде ссылок на само изображение, а в виде id товара. Контроллер coResize такие изображения обрабатывает так: По id и pos товара в БД запрашивается изображение, которое и идет дальше по конвееру resize-download-return. Если изображение уже было загружено, то со стадии resize изображение сразу будет передано для отображения в контроллер api->coResize.
- Исправлена проблема значений по умолчанию полей timestamp. Оказывается mysql учитывает time_zone при определении диапазона значения этого поля. Т.е. '1970-01-01 00:00:01' и time_zone = '+01:00' делает дату '1969-31-12 23:00:01'. Проблема решена установкой DEFAULT '1970-01-02 00:00:01'
### improvements:
- Изменения в контроллере view/ProductView.php, для упрощения адаптации шаблонов.
- Добавлен метод product->get_product_image($pid, $pos = 0) для вытаскивания конкретного изображения товара
Есть в виде дистрибутива:
Для просмотра ссылки Войди
# RAPIDA Ecommerce CMS
## SimplaCMS 2.3.8 fork
##IMPORTANT INFO
Для работы системы на сервере Nginx необходимо прописать следующую инструкцию в конфиг.
```
location / {
try_files $uri $uri /index.php$is_args$args;
}
```
## ****************
## Changelog
## ****************
## =================
## v0.0.8.1.5 21.12.2017
## =================
### bugs:
- Исправлен класс api->pages в части возвращаемых значений, теперь тут тоже возвращаются массивы, а не объекты. Теперь исправлено теоретически везде, что заметно упрощает адаптацию шаблонов. Простой шаблон адаптируется за 2 клика. Файлы шаблона обрабатываются 5-6 однострочными perl скриптами, которые делают замену кусков кода по регулярным выражениям.
- Исправлена ошибка для работы аякс поиска по старой симпловской схеме ajax/search_product.php. Удобно для шаблонов от симплы.
- Исправлены ошибки в контроллерах view/*. Изменено $page->var на $page['var'].
- Исправлены настройки полей в БД в связи с ошибками на некоторых версиях mysql.
- Исправления ошибок в стандартном шаблоне.
- Исправлена ошибка в features->get_products_ids() влияла на процесс преобразовании ЧПУ в id свойств и id значений свойств.
- Исправлена ошибка simpla/ajax/import.php, при импорте использовался кеш сразу с самого начала загрузки, что приводило к использованию устаревших данных. Теперь на первом цикле сначала загружаются данные без кеша.
- Устранена проблема загрузки изображений по товарам у которых эти изображения скачивались с удаленного сервера. Была проблема при обновлении страницы в связи с тем, что после загрузки изображения информация в БД изменялась (вместо ссылки записывается имя файла), а в кеше, она еще не обновилась. При попытке открыть изображение по старой ссылке изображение не отображалось. Теперь изображения на удаленном сервере передаются html не в виде ссылок на само изображение, а в виде id товара. Контроллер coResize такие изображения обрабатывает так: По id и pos товара в БД запрашивается изображение, которое и идет дальше по конвееру resize-download-return. Если изображение уже было загружено, то со стадии resize изображение сразу будет передано для отображения в контроллер api->coResize.
- Исправлена проблема значений по умолчанию полей timestamp. Оказывается mysql учитывает time_zone при определении диапазона значения этого поля. Т.е. '1970-01-01 00:00:01' и time_zone = '+01:00' делает дату '1969-31-12 23:00:01'. Проблема решена установкой DEFAULT '1970-01-02 00:00:01'
### improvements:
- Изменения в контроллере view/ProductView.php, для упрощения адаптации шаблонов.
- Добавлен метод product->get_product_image($pid, $pos = 0) для вытаскивания конкретного изображения товара
Последнее редактирование:
Amarous
Постоялец
- Регистрация
- 4 Сен 2011
- Сообщения
- 104
- Реакции
- 15
заменил, не помогло
Установка Rapida
Error performing query '/* Create table s_orders */ CREATE TABLE `s_orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `delivery_id` int(11) DEFAULT '0', `delivery_price` decimal(10,2) NOT NULL DEFAULT '0.00', `payment_method_id` int(11) DEFAULT '0', `paid` int(1) NOT NULL DEFAULT '0', `payment_date` timestamp NOT NULL DEFAULT '1970-01-01 02:01:00', `closed` tinyint(1) DEFAULT '0', `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `user_id` int(11) DEFAULT '0', `name` varchar(255) DEFAULT '', `address` varchar(255) DEFAULT '', `phone` varchar(255) DEFAULT '', `email` varchar(255) DEFAULT '', `comment` varchar(1024) DEFAULT '', `status` int(11) NOT NULL DEFAULT '0', `url` varchar(255) DEFAULT '', `payment_details` text, `ip` varchar(15) DEFAULT '', `total_price` decimal(10,2) NOT NULL DEFAULT '0.00', `note` varchar(1024) DEFAULT '', `discount` decimal(5,2) NOT NULL DEFAULT '0.00', `coupon_discount` decimal(10,2) NOT NULL DEFAULT '0.00', `coupon_code` varchar(255) DEFAULT '', `separate_delivery` int(1) NOT NULL DEFAULT '0', `modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `login` (`user_id`), KEY `written_off` (`closed`), KEY `date` (`date`), KEY `status` (`status`), KEY `code` (`url`), KEY `payment_status` (`paid`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; ': Invalid default value for 'payment_date'
Error performing query '/* Create table s_users */ CREATE TABLE `s_users` ( `id` int(11) NOT NULL AUTO_INCREMENT, `email` varchar(255) NOT NULL, `password` varchar(255) DEFAULT '', `name` varchar(255) DEFAULT '', `group_id` int(11) NOT NULL DEFAULT '0', `enabled` tinyint(1) DEFAULT '0', `admin` tinyint(1) DEFAULT '0', `perm` varchar(200) CHARACTER SET ascii DEFAULT '', `last_ip` varchar(15) DEFAULT '', `last_login` timestamp NOT NULL DEFAULT '1970-01-01 02:01:00', `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `email` (`email`) USING BTREE, KEY `admin` (`perm`), KEY `perm` (`admin`), KEY `created` (`created`), KEY `last_login` (`last_login`) ) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC; ': Invalid default value for 'last_login'
Error performing query '/* Data for table s_users */ INSERT INTO `s_users` (`id`,`email`,`password`,`name`,`group_id`,`enabled`,`admin`,`perm`,`last_ip`,`last_login`,`created`) VALUES (1, 'admin@admin.ad', '5f6b179e0034e203866666666f59cda6', 'admin@admin.ad', 0, 1, 1, '0:1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23', '127.0.0.1', '2017-11-12 03:14:23', '2017-11-12 03:08:40'); ': Table 'vm.s_users' doesn't exist
База данных успешно настроена
Error performing query '/* Create table s_orders */ CREATE TABLE `s_orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `delivery_id` int(11) DEFAULT '0', `delivery_price` decimal(10,2) NOT NULL DEFAULT '0.00', `payment_method_id` int(11) DEFAULT '0', `paid` int(1) NOT NULL DEFAULT '0', `payment_date` timestamp NOT NULL DEFAULT '1970-01-01 02:01:00', `closed` tinyint(1) DEFAULT '0', `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `user_id` int(11) DEFAULT '0', `name` varchar(255) DEFAULT '', `address` varchar(255) DEFAULT '', `phone` varchar(255) DEFAULT '', `email` varchar(255) DEFAULT '', `comment` varchar(1024) DEFAULT '', `status` int(11) NOT NULL DEFAULT '0', `url` varchar(255) DEFAULT '', `payment_details` text, `ip` varchar(15) DEFAULT '', `total_price` decimal(10,2) NOT NULL DEFAULT '0.00', `note` varchar(1024) DEFAULT '', `discount` decimal(5,2) NOT NULL DEFAULT '0.00', `coupon_discount` decimal(10,2) NOT NULL DEFAULT '0.00', `coupon_code` varchar(255) DEFAULT '', `separate_delivery` int(1) NOT NULL DEFAULT '0', `modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `login` (`user_id`), KEY `written_off` (`closed`), KEY `date` (`date`), KEY `status` (`status`), KEY `code` (`url`), KEY `payment_status` (`paid`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; ': Invalid default value for 'payment_date'
Error performing query '/* Create table s_users */ CREATE TABLE `s_users` ( `id` int(11) NOT NULL AUTO_INCREMENT, `email` varchar(255) NOT NULL, `password` varchar(255) DEFAULT '', `name` varchar(255) DEFAULT '', `group_id` int(11) NOT NULL DEFAULT '0', `enabled` tinyint(1) DEFAULT '0', `admin` tinyint(1) DEFAULT '0', `perm` varchar(200) CHARACTER SET ascii DEFAULT '', `last_ip` varchar(15) DEFAULT '', `last_login` timestamp NOT NULL DEFAULT '1970-01-01 02:01:00', `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `email` (`email`) USING BTREE, KEY `admin` (`perm`), KEY `perm` (`admin`), KEY `created` (`created`), KEY `last_login` (`last_login`) ) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC; ': Invalid default value for 'last_login'
Error performing query '/* Data for table s_users */ INSERT INTO `s_users` (`id`,`email`,`password`,`name`,`group_id`,`enabled`,`admin`,`perm`,`last_ip`,`last_login`,`created`) VALUES (1, 'admin@admin.ad', '5f6b179e0034e203866666666f59cda6', 'admin@admin.ad', 0, 1, 1, '0:1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23', '127.0.0.1', '2017-11-12 03:14:23', '2017-11-12 03:08:40'); ': Table 'vm.s_users' doesn't exist
База данных успешно настроена
естессно ПХП 5.6 или ниже, так как симпла не поддерживала более старшие версии
Код:
php -v
PHP 5.6.11-1ubuntu3.4 (cli)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24. com (unconfigured) v10.0.3, Copyright (c) 2002-2017, by ionCube Ltd.
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologiesbabahalki
Постоялец
- Регистрация
- 6 Май 2016
- Сообщения
- 247
- Реакции
- 107
- Автор темы
- #105
Это не симпла, работает на последнем php, на старье даже не проверяю.
Версию мускуля покажи. Очень интересно, что у тебя за зверь, что так строго с полями себя ведет.
Прочитал, что дело может быть в настройках мусуля. Пришли вывод мускуля по
show variables
Очень странно, что застревает именно на этих 2 полях в разных таблицах. Там создается много полей типа timestamp в других местах, создается по такому же принципу
Похоже, я понял в чем проблема. Дело в time_zone
Диапазон допустимых значений устанавливается с 1970-01-01 00:00:01, но с учетом time_zone, получается смещение, которое выводит дату из допустимого диапазона. Поэтому ошибка.
Выбираю самое тупое решение - поставить дату, которая вне зависимости от смещения времени все равно останется в пределах допустимых величин. Если у нас максимальное смещение +13:00, значит суток точно хватит. поставим дату по-умолчанию 1970-01-02 00:00:00
Проблема устранена в версии 0.0.8.1.5. Обновил дистрибутив.
Последнее редактирование:
babahalki
Постоялец
- Регистрация
- 6 Май 2016
- Сообщения
- 247
- Реакции
- 107
- Автор темы
- #107
Самым долгим стал запрос brands->get_brands() ~6сек
А все дело в том, что он не кешируется, а для выполнения прогоняется вся таблица s_products и s_products_categories, чтобы получить только те товары, которые есть в определенной категории, ведь бренды нужно показать не все, а только из этой категории.
Кеширование определенно решит проблему, но 5 сек все равно очень медленно, если учесть, что все эти запросы все равно выполняются в отложенном режиме из очереди заданий.
Есть хорошая идея, но она потребует усложнения БД, чего не хотелось бы делать. Можно бренды для каждой существующей категории просчитывать сразу при создании бренда или категории и записывать в отдельную таблицу. Тогда для получения брендов у категории будет совсем простая выборка из таблицы.
Второй вариант к которому я склоняюсь, просто кешировать этот запрос как и другие.
А все дело в том, что он не кешируется, а для выполнения прогоняется вся таблица s_products и s_products_categories, чтобы получить только те товары, которые есть в определенной категории, ведь бренды нужно показать не все, а только из этой категории.
Кеширование определенно решит проблему, но 5 сек все равно очень медленно, если учесть, что все эти запросы все равно выполняются в отложенном режиме из очереди заданий.
Есть хорошая идея, но она потребует усложнения БД, чего не хотелось бы делать. Можно бренды для каждой существующей категории просчитывать сразу при создании бренда или категории и записывать в отдельную таблицу. Тогда для получения брендов у категории будет совсем простая выборка из таблицы.
Второй вариант к которому я склоняюсь, просто кешировать этот запрос как и другие.
Последнее редактирование:
Amarous
Постоялец
- Регистрация
- 4 Сен 2011
- Сообщения
- 104
- Реакции
- 15
спасибо, помогло.
1. Извините за глупый вопрос, что за пользователь admin@admin.ad?
2. По работе скажу, конечно работает быстрее.
Но, главные категории грузит так же с задержкой, но не с такой большой, как и на симпле, и не такой как на Престашопе и тд.
(скорее всего это из-за такого количестве характеристик в фильтре).
Короче, на данный момент, фильтр бесполезен на главных категориях.
Когда будет онлайн 30-40 человек и юзеры будут тыркать во все щели, нагрузка на 4-х ядерный проц будет 30-50 %.
Возможно надо убрать функцию множественного выбора характеристик в фильтре. В общем надо ускорять главные категории.
А как зайти в админку?
Последнее редактирование:
babahalki
Постоялец
- Регистрация
- 6 Май 2016
- Сообщения
- 247
- Реакции
- 107
- Автор темы
- #110
спасибо, помогло.
1. Извините за глупый вопрос, что за пользователь admin@admin.ad?
2. По работе скажу, конечно работает быстрее.
Но, главные категории грузит так же с задержкой, но не с такой большой, как и на симпле, и не такой как на Престашопе и тд.
(скорее всего это из-за такого количестве характеристик в фильтре).
Короче, на данный момент, фильтр бесполезен на главных категориях.
Когда будет онлайн 30-40 человек и юзеры будут тыркать во все щели, нагрузка на 4-х ядерный проц будет 30-50 %.
Возможно надо убрать функцию множественного выбора характеристик в фильтре. В общем надо ускорять главные категории.
А как зайти в админку?
admin@admin.ad - это запись админа по умолчанию, после создания своей учетки можно удалить.
в админку заход происходит через обычную авторизацию, т.е. надо авторизоваться прямо с основной страницы сайта. Если пользователь с правами админа, то в левом углу появится синий флажок перехода в админку. Но можно и просто руками site.com/simpla/
По поводу скорости, ты все таки учитывай, что на dynamiclight.ru сейчас 1.1млн. товаров, а крутится система на простом виртуальном хостинге fozzy. На таком кол-ве товара вылезли еще узкие места, прикручу туда кеш, посмотрим как будет.
Лично я считаю, что даже без redis система вполне юзабельна будет.