Предрелиз ocStore 2.3.0.2.4b для тестирования

[RGB]

Вроде да

 

[zhu4koff]

5 часов назад, RGB сказал:

Жму обновить (рубль - валюта по-умолчанию с курсом 1):

это логика расчета api ЦБ РФ, они не все валюты считают по 1, некоторые по 10, 100 и т.д.

https://cbr.ru/currency_base/daily/

http://www.cbr.ru/scripts/XML_daily.asp?date_req=05/03/2021

 

p.s. чуть опоздал с сообщением

Змінено 5 березня 2021 користувачем zhu4koff

[dinox]

4 часа назад, AlexDW сказал:

@dinox

уберите уже художество применением модификаторов по дате

Вернул оригинальную сортировку, отправил в гит

[Prooksius]

Есть такой вопрос. Относительно вот этих простыней языковых переменных в контроллерах

$data['text_empty'] = $this->language->get('text_empty');
$data['text_quantity'] = $this->language->get('text_quantity');
$data['text_manufacturer'] = $this->language->get('text_manufacturer');
$data['text_model'] = $this->language->get('text_model');
$data['text_price'] = $this->language->get('text_price');
$data['text_tax'] = $this->language->get('text_tax');
$data['text_points'] = $this->language->get('text_points');
........

Почему вообще не заменить все их на какой-нибудь

$data['lang_data'] = $this->language->all();

и немного подправить рендерилку tpl, ну чтобы она брала переменные из этого массива..

Ну как предложение, понимаю, что это может сломать многое, не все так заполнится может, но сколько лишнего кода можно будет убрать, а...

Змінено 5 березня 2021 користувачем Prooksius

[Sha]

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

что это может сломать многое

 

кстати, метод all и сейчас есть в /library/language.php

// Please dont use the below function i'm thinking getting rid of it.
	public function all() {
		return $this->data;
	}

 

[Prooksius]

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

кстати, метод all и сейчас есть в /library/language.php

и что интересно, он есть и в трешке, только уже без слов "get rid of it"

[buslikdrev]

34 минуты назад, Prooksius сказал:

Почему вообще не заменить все их на какой-нибудь

$data['lang_data'] = $this->language->all();

и немного подправить рендерилку tpl, ну чтобы она брала переменные из этого массива..

 

		foreach ($this->load->language('extension/module/mymodule') as $key => $lang) {
			$data[$key] = $lang;
		}

 

[Sha]

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

Please dont use the below function i'm thinking getting rid of it.

посмотрел в тройке ещё ни избавился)

[Sha]

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

и что интересно, он есть и в трешке, только уже без слов "get rid of it"

ага) так всё не холиварим)

[Prooksius]

8 минут назад, buslikdrev сказал:

 

		foreach ($this->load->language('extension/module/mymodule') as $key => $lang) {
			$data[$key] = $lang;
		}

 

да, как вариант, классно, но может быть было бы лучше убрать такой код из контроллеров куда-нибудь в core - рутинный же код.
А если нужно какие-то переменные както отформатировать, ну типа sprinf там... так сделать это над конкретными переменными, какие нужны.

загляните в admin\controller\setting\setting.php - это ж пипец, там 35% кода эти простыни.

Змінено 5 березня 2021 користувачем Prooksius

[dinox]

58 минут назад, Prooksius сказал:

Есть такой вопрос. Относительно вот этих простыней языковых переменных в контроллерах

$data['text_empty'] = $this->language->get('text_empty');
$data['text_quantity'] = $this->language->get('text_quantity');
$data['text_manufacturer'] = $this->language->get('text_manufacturer');
$data['text_model'] = $this->language->get('text_model');
$data['text_price'] = $this->language->get('text_price');
$data['text_tax'] = $this->language->get('text_tax');
$data['text_points'] = $this->language->get('text_points');
........

Почему вообще не заменить все их на какой-нибудь

$data['lang_data'] = $this->language->all();

и немного подправить рендерилку tpl, ну чтобы она брала переменные из этого массива..

Ну как предложение, понимаю, что это может сломать многое, не все так заполнится может, но сколько лишнего кода можно будет убрать, а...

Этим действием мы можем уронить не одну сотню модулей  Так что не нужно увлекатся чрезмерным рефакторингом оригинального кода

[Prooksius]

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

Этим действием мы можем уронить не одну сотню модулей  Так что не нужно увлекатся чрезмерным рефакторингом оригинального кода

tpl-ки не изменятся, все то же самое будет.
Только в контроллерах уберется. И если у модификаторов есть привязка к этим простыням - тут, вы правы, фсе))

[mpn2005]

25 минут назад, Prooksius сказал:

tpl-ки не изменятся, все то же самое будет.
Только в контроллерах уберется. И если у модификаторов есть привязка к этим простыням - тут, вы правы, фсе))

Зато модификаторы часто привязываются к таким строчкам.

А если писать свой код, то никто не мешает делать в начале метода:

$data = $this->load->language('product/product');

Будет работать на всех версиях.

Если надо загрузить несколько:

$data = $this->load->language('product/product');
$data = array_merge($data, $this->load->language('checkout/cart'));

Но переписывать именно в сборке нет большого смысла.

[dinox]

Добавлен OCMOD редактор, уже в гите.

Редактор позволяет:

• Скачивать на компютер xml файл модификатора
• Закачивать измененный файл снова в это же дополнение(происходит обновление кода xml)
• Редактировать OCMOD дополнение прямо в админке сайта
• Применить изменения модификтора с  очисткой кеша не выходя с редактирования модификатора. 

Спойлер

 

 

 

[alex1989]

12 часов назад, dinox сказал:

Добавлен OCMOD редактор, уже в гите.

Редактор позволяет:

• Скачивать на компютер xml файл модификатора
• Закачивать измененный файл снова в это же дополнение(происходит обновление кода xml)
• Редактировать OCMOD дополнение прямо в админке сайта
• Применить изменения модификтора с  очисткой кеша не выходя с редактирования модификатора. 

  Показать контент

 

 

 

я скачал с гита и обновил на рабочем магазине с неделю назад

[alex1989]

что делать ?

[dinox]

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

что делать ?

если не делали правок в админке в коде, скачайте с гита снова, и перезалейте с заменой папку admin. Перед этим сделайте бекап всего магазина  Лучше конечно на тестовом это все проверить а потом на продакшн заливать

[alex1989]

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

если не делали правок в админке в коде, скачайте с гита снова, и перезалейте с заменой папку admin. Перед этим сделайте бекап всего магазина  Лучше конечно на тестовом это все проверить а потом на продакшн заливать

пока откатил, поставлю после релиза.

[Prooksius]

Вот еще вспомнил одну сложность.
Часто бывает (вообще - постоянно) при натяжке готовой верстки на опенкарт верстаки делают произвольную разметку пагинации. Ну как вот хотят, так и делают.
А в Опенкарте пагинация и в админке, и на фронте общая. Изменишь ее - и в админке будет абракадабра. Приходится почти всегда переверстывать пагинацию, чтобы была совместима с тем классом pagination в library.
Может быть, как-то разделить пагинации: бутстраповская - в админку, а какая-то другая, пусть даже та же бутстраповская - на фронт. Как говориться, мух от котлет ))
И уже пусть меняют фронтальную, как хотят при натяжке.

В контроллерах, наверное, менять нельзя - можем навредить совместимости. Надо как-то подгружать разные файлы из labrary в зав. от того, админка, или фронт.

[Tom]

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

Может быть, как-то разделить пагинации: бутстраповская - в админку, а какая-то другая, пусть даже та же бутстраповская - на фронт.

Сколько из магазинов используют дефолтный шаблон?

Скольким авторам шаблонов, придётся дорабатывать такой финт ушами , при чём для одних сборок одно, для других другое...

В любом ремонте, самое важное вовремя остановиться.

[Prooksius]

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

Сколько из магазинов используют дефолтный шаблон?

Скольким авторам шаблонов, придётся дорабатывать такой финт ушами , при чём для одних сборок одно, для других другое...

В любом ремонте, самое важное вовремя остановиться.

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

А, или вы хотите сказать, что шаблоны меняют и в админке пагинацию под себя? Блин, как все сложно-то..

Змінено 6 березня 2021 користувачем Prooksius

[Tom]

20 минут назад, Prooksius сказал:

что шаблоны меняют и в админке пагинацию под себя?

Из моей практики минимум пара шаблонов с форума делают это и в админке. Зачем, не понятно и загадочно.

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

Таких метисов и так хватает.

[mpn2005]

Можно организовать аккуратно, при желании.

Проверять наличие шаблона пагинации на фронте, если он есть, то выводить через него.

Если его нет, то всё штатным образом.

Если так сделать, то не будет проблем совместимости, но будет возможность кастомизации данного момента.

Вообще не самое лучшее решение, тянуть вёрстку и в админку и на фронт. 

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

 

[antiuser]

Уважаемая администрация и разработчики!

Добавьте пожалуйста функцию отключения кеширования в SeoPro, если есть такая возможность.

[Sha]

что если выпилить из 3ки/4ки правильный design/seo_url https://github.com/opencart/opencart/tree/master/upload/admin/view/template/design ?
и адаптировать под 2.3, даже таблицу в базе походу не нужно менять.