Технические требования к публикуемым дополнениям

[dinox]

Так как сейчас идет процесс приведения в порядок всего вокруг. Я планирую составить список требаваний к дополнениям которые публикуются в зависимости от типа дополнений

Вот пункты которые войдут в этот список:

1. В контроллерах не должно присутствовать запросов в базу данных, они должны выполняться только в моделях. Тоесть должно  соответствовать структуре MVC в OpenCart
2. Запросы к базе должны содержать экранирование данных: числовые данные не ограничены по типу (int), другие данные  экранированы через штатный $this->db->escape(), так как это потенциальное место для нарушения безопасности магазинов. 
3. В файле install.xml не должна присутствовать ссылка на сторонние маркетплейсы
4. Должно соответстовать стандартам OpenCart (P.S. потом сделаем перевод) https://github.com/opencart/opencart/wiki/Coding-standards 

Пишите Ваши предложения, я буду забегать сюда и дополнять, надеюсь до лета сформируется более менее список и я его размещу в разделе Разработчикам в меню форума. Это увеличит понимание что нужно для более оперативной модерации, а также был чеклист для подготовки к размещению дополнений

[sv2109]

начать пожалуй стоит с этого
https://github.com/opencart/opencart/wiki/Coding-standards
так как это стандарты кодирования для всего опенкарта. 
 

[OCdevWizard]

Такое заявление будет очень провокационным но как насчет наличия ionCube в файлах модуля. Скажу это только потому что на том же OpenCart.com это строго запрещено и может полгода назад мне пришло от админов уведомление  мол или убирайте зашифрованные файлы с модулей или отключим аккаунт - решил отключить модули которые под кубом. 

Собственно что вы будете делать в этом направлении? 

[dinox]

4 минуты назад, sv2109 сказал:

начать пожалуй стоит с этого
https://github.com/opencart/opencart/wiki/Coding-standards
так как это стандарты кодирования для всего опенкарта. 
 

Это в том числе Можно сделать идеальный стандарт и незаэкранировать данные и получить привет с даркнета )

[OCdevWizard]

6 минут назад, sv2109 сказал:

начать пожалуй стоит с этого
https://github.com/opencart/opencart/wiki/Coding-standards
так как это стандарты кодирования для всего опенкарта. 
 

обязательно!

кстати кто юзает PhpStorm то там раз настроил под себя стили и при рефакторинге все делается по красоте. 

[sv2109]

Только что, OCdevWizard сказал:

Такое заявление будет очень провокационным но как насчет наличия ionCube в файлах модуля. Скажу это только потому что на том же OpenCart.com это строго запрещено и может полгода назад мне пришло от админов извинения мол или убирайте зашифрованные файлы с модулей или отключим аккаунт - решил отключить модули которые под кубом. 

Собственно что вы будете делать в этом направлении? 

У меня на оф. сайте продаются модули под кубом, никто ничего не присылал. Просто те пользователи, которые что-то имеют против куба делают возврат и все. 
Мое мнение:
1. в описании модуля обязательно должна быть информация о кубе, в этом случае у покупателя просто есть выбор - покупать или не покупать понимая что он покупает. Все справедливо. Кто против куба - путь проходит мимо, ищет другие решение, кто не против - тот покупает. 
2. кодируют разработчики модули не от хорошей жизни, я бы сам с удовольствием отказался от куба, так как он создает массу неудобств, но увы пока альтернативы кубу нету и если не кодировать то деньги потеряют не только разработчики но и сам форум. Да и под кубом тут очень много модулей. 

Знаю, многие разработчики на этом форуме против куба, поэтому просьба не превращать тему в очередной холивар, у каждого свое мнение и никто ничего никому уже все равно не докажет. 

[OCdevWizard]

16 минут назад, dinox сказал:

В файле install.xml не должна присутствовать ссылка на сторонние маркетплейсы

это вы имеете ввиду то что в теге <link></link> идет?

[OCdevWizard]

4 минуты назад, sv2109 сказал:

У меня на оф. сайте продаются модули под кубом, никто ничего не присылал. Просто те пользователи, которые что-то имеют против куба делают возврат и все. 

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

 

4 минуты назад, sv2109 сказал:

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

 

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

[OtezVikentiy]

1 час назад, dinox сказал:

Так как сейчас идет процесс приведения в порядок всего вокруг. Я планирую составить список требаваний к дополнениям которые публикуются в зависимости от типа дополнений

Вот пункты которые войдут в этот список:

1. В контроллерах не должно присутствовать запросов в базу данных, они должны выполняться только в моделях. Тоесть должно  соответствовать структуре MVC в OpenCart
2. Запросы к базе должны содержать экранирование данных: числовые данные не ограничены по типу (int), другие данные  экранированы через штатный $this->db->escape(), так как это потенциальное место для нарушения безопасности магазинов. 
3. В файле install.xml не должна присутствовать ссылка на сторонние маркетплейсы
4. Должно соответстовать стандартам OpenCart (P.S. потом сделаем перевод) https://github.com/opencart/opencart/wiki/Coding-standards 

Пишите Ваши предложения, я буду забегать сюда и дополнять, надеюсь до лета сформируется более менее список и я его размещу в разделе Разработчикам в меню форума. Это увеличит понимание что нужно для более оперативной модерации, а также был чеклист для подготовки к размещению дополнений

по стандартам кодирования это конечно лихо... то есть если где-то использовать не camelCase - то это повод отказать в размещении приложения? Seriously?
Как-то жестковато. Или это такое будет типа, что там где совсем мясо - тех не пропускают, где более менее приемлемо - то типа ок?

[SergeTkach]

1 час назад, dinox сказал:

Так как сейчас идет процесс приведения в порядок всего вокруг.

О!

Прикольно!

[SergeTkach]

Предлагаю правило, чтобы в модулях с кубом должен устанавливаться набор файлов, который покрывает все поддерживаемые версии PHP.

То есть, клиент установил модуль, и позже переключил версию PHP - и в этот момент он не должен ощутить никаких проблем из-за того, что модуль Х, оказывается, был установлен под PHP 7.0, а теперь-то надо устанавливать под PHP 7.4

[SergeTkach]

1 час назад, dinox сказал:

В контроллерах не должно присутствовать запросов в базу данных, они должны выполняться только в моделях. Тоесть должно  соответствовать структуре MVC в OpenCart

Запросы в методе install() считаются?

[spectre]

12 минут назад, SergeTkach сказал:

Запросы в методе install() считаются?

 

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

 

как по мне бывают ситуации когда нужен один запрос и нет смысла делать отдельный файл модели для этого, тогда можно и прямо в том же контроллере создать функцию для получения данных из бд

[buslikdrev]

Все гет, пост, файл и т.д. запросы из вне, нужно делать так, чтобы не могли запустить вредоносный код через: https://habr.com/ru/company/modesco/blog/472092/

[esculapra]

54 минуты назад, spectre сказал:

 

как по мне бывают ситуации когда нужен один запрос и нет смысла делать отдельный файл модели

Точно. Значить в контоллере ControllerExtensionPaymentKlarnaAccount

$product_query = $this->db->query("SELECT `name`, `model`, `price`, `quantity`, `tax` / `price` * 100 AS 'tax_rate' FROM `" . DB_PREFIX . "order_product` WHERE `order_id` = " . (int)$order_info['order_id'] . " UNION ALL SELECT '', `code`, `amount`, '1', 0.00 FROM `" . DB_PREFIX . "order_voucher` WHERE `order_id` = " . (int)$order_info['order_id']);

 

- это нормально,  а нам нельзя! - геноцид какой-то.

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

[matroskin92]

2 минуты назад, esculapra сказал:

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

Есть статистика, когда подключение модели "дороже" для сервера, чем делать запрос напрямую из контроллера?

[esculapra]

3 минуты назад, matroskin92 сказал:

Есть статистика, когда подключение модели "дороже" для сервера, чем делать запрос напрямую из контроллера?

Проверить профайлером (использование памяти, вемя выолнения)...

[OCdevWizard]

5 минут назад, esculapra сказал:

Например, мне нужен 1 запрос для получения параметов.

Скорей всего это лень.

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

[esculapra]

3 минуты назад, OCdevWizard сказал:

Это так проще или правильнее по вашему?

Я просто констатировал, что во многих официальных модулях это имеет место. Хватит спорить попусту.

[chukcha]

3 часа назад, dinox сказал:

В контроллерах не должно присутствовать запросов в базу данных, они должны выполняться только в моделях. Тоесть должно  соответствовать структуре MVC в OpenCart

очень спорное требование

смотрим startup|seourl

Иногда проще и быстрее без подключения модели  получит данные..
 

[chukcha]

10 минут назад, OCdevWizard сказал:

можно же сразу костылем это прописать прямым запросом.

 

в чем костыль?
тем более, что контроллер и модель в ОС братья, или сестры (как вам удобнее)

[spectre]

35 минут назад, esculapra сказал:

По вашей логике

 

по моей логике можно сделать в том же контроллере private функцию getЧтоТоТам с запросом к бд и вызвать ее как $this->getЧтоТоТам

[chukcha]

33 минуты назад, matroskin92 сказал:

Есть статистика,

лень - согласен.

Но для тройки есть еще накладные расходы на события

[OCdevWizard]

15 минут назад, esculapra сказал:

Я просто констатировал, что во многих официальных модулях это имеет место. Хватит спорить попусту.

в моем понимании в сахарнице должен быть сахар, в перечнице - перец, а в солонке - соль. Если мы говорим о том что можно так делать вставляя напрямую запрос к БД мимо модели исходя из того что это работает или так удобнее, ну ок - можно и так. Но если говорить с точки зрения стандарта, перфекционизма то это такое себе решение. Ну каждому свое получается. 

Я за то что бы разработчики старались придерживаться общепринятых стандартов и стилистики написания кода, по аналогии с тем же PEP8.

[sazonoff]

3 часа назад, dinox сказал:

В контроллерах не должно присутствовать запросов в базу данных, они должны выполняться только в моделях. Тоесть должно  соответствовать структуре MVC в OpenCart

 

в самом опенкарт много чего не соответствует стандартам MVC.

Скорее полезно руководствоваться здравым смыслом, а не чисто формальными стандартами.

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