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

Здравствуйте. Вы бы не могли оживить старую функцию авто подбора изображения товара от его названия и характеристик ?. API Google обновили давным давно. Или можно использовать Яндекс картинки.

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

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

Это реалии жизни что гугл что яндекс уменьшают количество халявы.
Можно это наверное и без API сделать, просто парсить выдачу и тырить картинки оттуда.
<-------------- добавлено через 1834 сек. -------------->
RAPIDA Ecommerce CMS
SimplaCMS 2.3.8 fork

****************
Changelog
****************

=================
v0.0.7 22.10.2017
=================
- В раздел "Автоматизация" добавлен новый подраздел "Обслуживание системы". В нем собраны собраны операции с системой. Например: Очистка от лишних записей таблицы уникальных значений свойств товаров, во время работы системы эта таблица только пополняется новыми записями, какие-то из этих записей перестанут относится хотя бы к одному товару и их можно будет удалить из таблицы. При импорте товаров с изображениями с внешних источников в базу данных записывается ссылки этих изображений, но загрузка и сохранение происходят только при обращении к соответствующей картинке. Если товаров и картинок много, удобно загрузить сразу все изображения с внешних источников.
- Создал новый класс System sys, в нем будут методы, которые используются редко и не предназначены для повседневной работы. В перспективе в этот класс переедут все такие методы, так мы разгрузим память от лишнего.
- Перенес метод sync_options() из features->sync_options() в features->sys->sync_options()

=================
v0.0.6.2 22.10.2017
=================
- Исправлен мелкий баг в файле simpla/OrdersAdmin.php от страницы со списком заказов.
- Исправлен аналогичный баг в файле simpla/OrderAdmin.php от страницы выбранного заказа.

=================1
v0.0.6.1 22.10.2017
=================
- Исправлен баг с загрузкой изображений с внешнего источника https://
- Исправлен баг при создании товара через админку simpla/ProductAdmin.php
- Теперь система не только php7, но и MySql 5.7 совместимая.

=================
v0.0.6 19.10.2017
=================
- Очень значительное с технической точки зрения изменение. Изменена структура хранения свойств товаров. Теперь таблица s_options горизонтальная, а не вертикальная. В ней хранятся id товара, id свойств по столбцам, и значения id самих значений свойств. Значения свойств хранятся в отдельной таблице s_options_uniq. Тут записаны id, уникальные значения свойств товаров и md4 хеши значений в шестнадцатеричном формате bin(16). В классе db небольшие доработки внесены в методы results_array results_object, в классе features почти все методы переделаны под новую систему хранения свойств, добавлены новые методы для работы с более сложной структурой хранения. Переделаны также методы get_products и count_products из класса products, которые в основном используются для отображения товара и подстчета количества страниц в витрине товаров.
- В связи с вышеназванными изменениями ссылки с выбранными фильтрами теперь выглядят не так: site.com/catalog/phones?1=gsm, а вот так: site.com/catalog/phones?1=123. Т.е. теперь вместо значений id.
- При тестировании на Mysql 5.7 x64 обнаружилось, что теперь СУБД более строго подходит к значениям полей "по умолчанию", если поле demo записано без значения по умолчанию, то запрос вида INSERT table SET some = 23 не пройдет так как не указано значение для поля demo. Если поле some стоит как integer, то запрос UPDATE table SET some = 'text' не пройдет. В этой связи в огромном количестве мест пришлось вносить правки.
- Немного улучшил работу модуля backup, раньше он создавал пустой каталог files/products (в нем система пишет миниатюры изображений), т.е. если у вас там .htaccess, то он в архив не попадал. Сейчас все файлы, которые начинаются с точки в архив попадают.
- Во всех таблицах БД поставил DEFAULT NULL всем полям, которые могут быть пустыми.
- Переделал simpla/ajax/export.php. Для нормальной работы в кодировке cp1251, раньше использовалась глючная схема изменением кодировки на соединении с БД через set names, а также с установкой set_locale. Все это убрал, и вставил iconv непосредственно перед записью в csv. Т.е. БД и PHP работают в UTF-8 и только запись на диск идет в cp1251.
- Изменил метод db->dump_table(), теперь создаются не только данные, но и сама таблица.

=================
v0.0.5.3 15.10.2017
=================
- Отключил type hinting в тех функциях, где я уже успел его использовать. Теперь система работает не только на php7, но и на php5.

=================
v0.0.5.2 15.10.2017
=================
- После включения кеша, возник баг с открытием страниц товара в админке. Устранен.

=================
v0.0.5.1 15.10.2017
=================
- В демонстрационную инсталяционную базу, которая создается на этапе установке системы, добавлены недостающие таблицы s_queue рабочая очередь задач. s_queue_full очередь задач для сохранения всех задач (не очищается автоматически) s_cache_integer для записи кеша цифровых значений.
- Расположение файлового кеша по умолчанию изменено на cache в корневой директории системы
- Раньше к имени директории, которая создается для кеша в конце дописывался дефис. securityKey = mysite становилось mysite- Теперь так больше не делает.

Для просмотра ссылки Войди или Зарегистрируйся
<-------------- добавлено через 208 сек. -------------->
Здравствуйте. Вы бы не могли оживить старую функцию авто подбора изображения товара от его названия и характеристик ?. API Google обновили давным давно. Или можно использовать Яндекс картинки.

Функция неплохая, но сделать быстро не выйдет, а делать долго можно будет только после того, как все основное будет налажено.
 
Все больше склоняюсь к тому, что надо изменить/обновить весь api, прямо по порядку, каждый файл. Выражаясь в терминах MVC, сделать так, чтобы модели выдавали данные в одном формате, чтобы все функции возвращали данные по общей логике - данные есть - выдаем эти данные - данных нет или ошибка - выдаем false. Уже на уровне View делать так, чтобы шаблон получал в этом экзотическом виде array[object,object].
 
В итоге останется только внешний вид админки и название некоторых таблиц)
 
В итоге останется только внешний вид админки и название некоторых таблиц)
Самое ценное как раз и останется. :)

Люди, кто по mysql шарит, подскажите. Сейчас перебираю запросы по основновным методам get_products() и count_products(), часто автор использует такую хитрую конструкцию.

Вот, например, запрос метода get_products со включенным фильтром "нет на складе"
Код:
SELECT SQL_NO_CACHE p.id, p.url, p.brand_id, p.name, p.annotation, p.body, p.position, p.created as created, p.visible, p.featured, p.meta_title, p.meta_keywords, p.meta_description, b.name as brand, b.url as brand_url FROM s_products p    LEFT JOIN s_brands b ON p.brand_id = b.id WHERE 1 AND (SELECT count(*)>0 FROM s_variants pv WHERE pv.product_id=p.id AND pv.price>0 AND (pv.stock IS NULL OR pv.stock>0) LIMIT 1) = 0 ORDER BY p.position DESC LIMIT 0, 24

Вот это место вообще не понимаю, как тут что получается?
Такая инструкция получается для каждой строки из выборки делает вот этот вложенный запрос?
Код:
(SELECT count(*)>0 FROM s_variants pv WHERE pv.product_id=p.id AND pv.price>0 AND (pv.stock IS NULL OR pv.stock>0) LIMIT 1) = 0

Я сравнил по скорости выполнения "родную" хитросделанную конструкцию со своей простой и понятной реализацией.


ТЕСТ
Мой простой запрос
Код:
SELECT SQL_NO_CACHE p.id, p.url, p.brand_id, p.name, p.annotation, p.body, p.position, p.created as created, p.visible, p.featured, p.meta_title, p.meta_keywords, p.meta_description, b.name as brand, b.url as brand_url FROM s_products p LEFT JOIN s_brands b ON p.brand_id = b.id WHERE 1 AND p.id in (SELECT product_id FROM s_variants WHERE 1 AND price>0 AND stock = 0) ORDER BY p.position DESC LIMIT 0, 24

Родной запрос
Код:
SELECT SQL_NO_CACHE p.id, p.url, p.brand_id, p.name, p.annotation, p.body, p.position, p.created as created, p.visible, p.featured, p.meta_title, p.meta_keywords, p.meta_description, b.name as brand, b.url as brand_url FROM s_products p    LEFT JOIN s_brands b ON p.brand_id = b.id WHERE 1 AND (SELECT count(*)>0 FROM s_variants pv WHERE pv.product_id=p.id AND pv.price>0 AND (pv.stock IS NULL OR pv.stock>0) LIMIT 1) = 0 ORDER BY p.position DESC LIMIT 0, 24

Вот результат:

100 rounds. average time query1 in ms: 1.5600895881653
100 rounds. average time query2 in ms: 201.30150794983


Т.е. простая конструкция выигрывает у родной 129 раз, или 12800%
 
Последнее редактирование:
Все больше склоняюсь к тому, что надо изменить/обновить весь api, прямо по порядку, каждый файл. Выражаясь в терминах MVC, сделать так, чтобы модели выдавали данные в одном формате, чтобы все функции возвращали данные по общей логике - данные есть - выдаем эти данные - данных нет или ошибка - выдаем false. Уже на уровне View делать так, чтобы шаблон получал в этом экзотическом виде array[object,object].
Это основной бич форков - совместимость. Сначала витает идея что что-то улучшим оставив совместимость с шаблонами/модулями и т.д., но проходит время и встает вопрос или прогресс и оптимизация или совместимость. Есть третий способ - брать старые вещи и адаптировать их под форк.
 
Последнее редактирование:
Мое мнение... Новичок все равно не будет ставить форк и загонятся оптимизацией производительности. А опытный юзверь переделает шаблон под форк.

Я за развитие и оптимизацию в ущерб совместимости.
 
импорт характеристик лучше оптимизируйте, они загружаются годами
 
stock IS NULL и stock = 0 - вроде как не одно и тоже

IS NULL - это бесконечный остаток у товара

0 - это 0 остаток, т.е. нет на складе

я тоже сразу на это обратил внимание, но не внимательно посмотрел, в исходном запросе условие "не (is null и >0)" а у автора "=0" - это по сути 2 одинаковых условия
 
Назад
Сверху