Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

opencart 2.3.x


markimax

Recommended Posts

Боюсь показаться маразматиком, но мне кажется это перебор. 

Обычно в движках небольшие, минорные изменения версии (с 2.2 на 2.3) это небольшие изменения самого движка, которые практически не сказываются на работе модулей и почти все модули, которые работают на 2.2 должны работать на 2.3, потому что движок кардинально не изменяется, изменяются какие-то мелочи, проблемы безопасности, исправляются баги итд.

А уже изменения мажорной версии (напр. с 2.x на 3.x) несет более глобальные изменения самого движка.  

Что мы видим в опенкарт? В последнее время каждая(!) новая минорная версия практически полностью несовместима с предыдущей. Модули, написаны на 2.1 совсем не будут работать на 2.2, модули написанные на 2.2 также совсем не будут работать на 2.3.. И приходится с каждой новой версией писать новые версии для каждого модуля. А что если у кого-то модулей 2-3 десятка?.. Короче, имхо, идиотизм, о разработчиках никто вообще не думает.

Неужели не было бы проще все новые модные изменения на протяжении нескольких месяцев вести в какой-то дев. ветке, а потом пакетом все обновить и выпустить новую версию движка - 3.0.  А разработчикам пришлось бы делать всего 2 версии модуля - для 2.х и для 3.х, а не для 2.0, 2.1, 2.2, 2.3 итд.. 

 

+ как мне кажется, глупо делать кучу косметических улучшений, когда сам движок написан криво, неужели было бы не лучше сначала сделать нормально события (и отказаться от ocmod из-за которого куча конфликтов), добавить какие-то хелперы, например для форм, улучшить работу с языками (а не добавлять по 100 строк в каждом контроллере), добавить какую-то простую орм для работы с базой (чтобы не писать сотни идентичных запросов), добавить какой-то класс валидации, чтобы он автоматом входящие данные проверял согласно правилам итд. итп. Все это есть практически в любом, даже самом простом фреймворке. А уже потом делать всю косметику.  

 

так, просто мысли вслух. 
  • +1 3
Надіслати
Поділитися на інших сайтах

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

Километровая таблица даже при наличие кеширование вполне может нарваться на проблемы связные с меленой работай (привет * и джоины) и затратой излишних ресурсов 

+ нужно постоянно при редактирование переменных или добавление модуля обновлять эти километры, а если у пользователя 100500 модулей и 2 - 3 языка ? тоже весело будет 

 

Если я ошибаюсь, поправьте буду только благодарен 

Надіслати
Поділитися на інших сайтах

улучшить работу с языками (

 

 

$data = $this->load->language

 

И опа.. уже все на месте..

$this->language->all (а может это с oc_store)

 

 

В том то и дело... Что на данном этапе нужна именно косметика.. Иначе можно будет погрязнуть в объеме изменений и не закончить..

Т.е. выдавать поочередно..

 

Я не знаю, что Вам хочется от событий?

 

добавить какую-то простую орм для работы с базой

 

Вот тут.. я и руками и ногами за...

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

 

Но тогда вся модель превратится в вызов this->db->sql

Надіслати
Поділитися на інших сайтах

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

Километровая таблица даже при наличие кеширование вполне может нарваться на проблемы связные с меленой работай (привет * и джоины) и затратой излишних ресурсов 

+ нужно постоянно при редактирование переменных или добавление модуля обновлять эти километры, а если у пользователя 100500 модулей и 2 - 3 языка ? тоже весело будет 

 

Если я ошибаюсь, поправьте буду только благодарен 

Нет, никаких join

SELECT * FROM oc_traslation WHERE store_id= $this->config->get(srtore_id AND route='extension/module/account' AND language_id = $this->config>get(language_id)

Надіслати
Поділитися на інших сайтах

+ как мне кажется, глупо делать кучу косметических улучшений, когда сам движок написан криво, неужели было бы не лучше сначала сделать нормально события (и отказаться от ocmod из-за которого куча конфликтов), добавить какие-то хелперы, например для форм, улучшить работу с языками (а не добавлять по 100 строк в каждом контроллере), добавить какую-то простую орм для работы с базой (чтобы не писать сотни идентичных запросов), добавить какой-то класс валидации, чтобы он автоматом входящие данные проверял согласно правилам итд. итп. Все это есть практически в любом, даже самом простом фреймворке. А уже потом делать всю косметику.  

 
так, просто мысли вслух. 

 

они к этому стараться двигаться, но для этого нужно время и ресурсы, вот по этому такие скачки в минорных версиях, в 3.0 с такими темпами будет совсем новая архитектура.

Кстати все могут внести свой вклад на гитхабе, и показать им правильны путь развития 

Надіслати
Поділитися на інших сайтах

Кстати все могут внести свой вклад на гитхабе, и показать им правильны путь развития

 

ага и быть не услышанным.

Надіслати
Поділитися на інших сайтах

Нет, никаких join

SELECT * FROM oc_traslation WHERE store_id= $this->config->get(srtore_id AND route='extension/module/account' AND language_id = $this->config>get(language_id)

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

Надіслати
Поділитися на інших сайтах

ага и быть не услышанным.

Ну 50 / 50

Надіслати
Поділитися на інших сайтах

 

В том то и дело... Что на данном этапе нужна именно косметика.. Иначе можно будет погрязнуть в объеме изменений и не закончить..

Т.е. выдавать поочередно..

 

Я не знаю, что Вам хочется от событий?

 

 

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

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

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

Поэтому на событиях должно работать все в движке, чтобы модуль через события мог изменить все что угодно. Так работает например Drupal, так работает Symfony, другие движки и фреймворке, вот только в одном опенкарте решили изобрести свой велосипед - vqmod.

 

Надіслати
Поділитися на інших сайтах

$data = $this->load->language

 

И опа.. уже все на месте..

$this->language->all (а может это с oc_store)

 

 

В том то и дело... Что на данном этапе нужна именно косметика.. Иначе можно будет погрязнуть в объеме изменений и не закончить..

Т.е. выдавать поочередно..

 

Я не знаю, что Вам хочется от событий?

 

Вот тут.. я и руками и ногами за...

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

 

Но тогда вся модель превратится в вызов this->db->sql

 

Я делал чуть по другому (увидел этот подход на simple checkout).

 

В контроллере:

$data['l'] = $this->language;

во вьюхе:

<?php echo $l->get('cart_label'); ?>

Зачем они городят эти языковые переменные..

 

Касательно "Customer Searches Report", это хорошая вещь, но похоже что работает только для залогиненых кастомеров, а жаль.

 

Кстати, касательно "Customer Searches Report" и "Customer Online", тестил на себе на локалке, что-то не работает.

 

Divido как я понял, это для оплаты по факту (до 30 дней спустя доставки).

Надіслати
Поділитися на інших сайтах

только профит какой от этого ?

Гибкость изменений, без доступа к фтп

 

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

типа такого

 

<?php _e($text_information, array($count,$total)) ?> - т.е. убрать из контроллера sprinf, а его функционал отдать в хелпер

 

 

Если нужно внести изменения в код функции, то никакие события не помогут

Ну а существующие события тоже какие-то хитро выкрученные

 

	public function view($route, $data = array()) {
		$output = null;
		
		// Sanitize the call
		$route = preg_replace('/[^a-zA-Z0-9_\/]/', '', (string)$route);
		
		// Trigger the pre events
		$result = $this->registry->get('event')->trigger('view/' . $route . '/before', array(&$route, &$data, &$output));
		
		if ($result) { 
			return $result;
		}
Можно или что-то поменять уже в $output и вернуть false

а можно и в result что-то положить

или даже сменить путь шаблона

		
		if (!$output) {
			$template = new Template($this->registry->get('config')->get('template_type'));
			
			foreach ($data as $key => $value) {
				$template->set($key, $value);
			}
		
			$output = $template->render($route . '.tpl');
		}
		
		// Trigger the post events
		$result = $this->registry->get('event')->trigger('view/' . $route . '/after', array(&$route, &$data, &$output));
		
		if ($result) {
			return $result;
		}
Можно или что-то поменять уже в $output и вернуть false

а можно и в result что-то положить

		
		
		return $output;
	}

Надіслати
Поділитися на інших сайтах

Да..

			if (isset($this->request->get['search']) && $this->config->get('config_customer_search')) {
				$this->load->model('account/search');

				if ($this->customer->isLogged()) {
					$customer_id = $this->customer->getId();
				} else {
					$customer_id = 0;
				}

				if (isset($this->request->server['REMOTE_ADDR'])) {
					$ip = $this->request->server['REMOTE_ADDR'];
				} else {
					$ip = '';
				}

				$search_data = array(
					'keyword'       => $search,
					'category_id'   => $category_id,
					'sub_category'  => $sub_category,
					'description'   => $description,
					'products'      => $product_total,
					'customer_id'   => $customer_id,
					'ip'            => $ip
				);

				$this->model_account_search->addSearch($search_data);
			}

Как видите нет ограничений

Змінено користувачем chukcha
  • +1 1
Надіслати
Поділитися на інших сайтах

Касательно design/translation.

 

У меня получилось кое-как запустить что-то, звучит дико))

через design/translation/install

 

Как я понял это для загрузки языка локализации удаленно через crowdin.com.

 

Но что-то этот раздел еще сыроват и выдает ошибки.

Надіслати
Поділитися на інших сайтах

Ну.. я не смотрел в контроллер, т.е. мне не интересно пока это..

 

Т.к.. 2.2. пролетела мимо, то мне кажется 2.3. будет более менее стаб. веткой, вот потому я ее и верчу

Надіслати
Поділитися на інших сайтах

Т.к.. 2.2. пролетела мимо, то мне кажется 2.3. будет более менее стаб. веткой, вот потому я ее и верчу

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

Поэтому 2.3, мне кажется, ждет точно такая же судьба как и 2.2, где тоже не было совместимости модулей.

Надіслати
Поділитися на інших сайтах

Я представляю объем необходимых модулей, которые, на 50-70% мои

Поэтому меня это мало интересует.

 

И я стараюсь не покупать закодированные.

Надіслати
Поділитися на інших сайтах

В dev'e вчера добавлено. Видать пришло озарение, что изменений больше, чем на минорную версию. Похоже, что можно расслабить булки и ждать релиза тройки.

Надіслати
Поділитися на інших сайтах

Тем более спрашивается - зачем вообще было делать 2.3?!

 

Ведь прямо сейчас на нее никто не перейдет, потому что еще нету всех необходимых модулей совместимых с ней. Какая-то часть модулей будет месяцев через 2-3 минимум. И вот через 2-3 месяца когда разработчики потратят кучу своего времени, чтобы сделать версии модулей для 2.3 и покупатели надумают на нее переходить, что сделает опенкарт? Правильно, исправит все ошибки 2.3, добавит пару косметических мелочей, которые опять нарушат совместимость и выпустит 3.0, после выпуска которой смысла переходить на 2.3 уже не будет никакого. В результате тем разработчикам, кто потратил время на перенос модулей на 2.3 теперь опять придется писать новые версии уже для 3.0, а версии для 2.3 просто останутся невостребованными, так как смысла на нее переходить после выпуска 3.0 уже не будет. 

  • +1 2
Надіслати
Поділитися на інших сайтах

 

Тем более спрашивается - зачем вообще было делать 2.3?!
 
Ведь прямо сейчас на нее никто не перейдет, потому что еще нету всех необходимых модулей совместимых с ней. Какая-то часть модулей будет месяцев через 2-3 минимум. И вот через 2-3 месяца когда разработчики потратят кучу своего времени, чтобы сделать версии модулей для 2.3 и покупатели надумают на нее переходить, что сделает опенкарт? Правильно, исправит все ошибки 2.3, добавит пару косметических мелочей, которые опять нарушат совместимость и выпустит 3.0, после выпуска которой смысла переходить на 2.3 уже не будет никакого. В результате тем разработчикам, кто потратил время на перенос модулей на 2.3 теперь опять придется писать новые версии уже для 3.0, а версии для 2.3 просто останутся невостребованными, так как смысла на нее переходить после выпуска 3.0 уже не будет. 

 

 

У вас такие смешные вопросы...

А зачем что-то в принципе делать ?

 

А ничего что, по идее 2.3 == 3.0, и те кто по быстрому подсуетился, сделали задел на будущее и сэкономили время...

 

Ну и давайте на забывать, что хорошо что после 2.3 дошло что это major release, а не после 2.7

Надіслати
Поділитися на інших сайтах

У вас такие смешные вопросы...

А зачем что-то в принципе делать ?

 

А ничего что, по идее 2.3 == 3.0, и те кто по быстрому подсуетился, сделали задел на будущее и сэкономили время...

 

Ну и давайте на забывать, что хорошо что после 2.3 дошло что это major release, а не после 2.7

ну если 2.3 == 3.0 то тем более зачем было делать 2.3? Правильнее было бы сразу делать 3.0. Но 3.0 не может быть такой же. И в 3.0 по любому сейчас  добавят какие-то косметические изменения и совместимости с модулями опять не будет, потому что если ее нету в минорных версиях, то в мажорной тем более не будет. И разработчикам опять придется делать новые версии но уже под 3.0. 

вопрос не в том чтобы сделать или не сделать, вопрос в том, чтобы сделать с умом, чтобы было удобно и разработчикам и пользователям. А версия 2.3 она никакая. Она неудобна не тем ни другим. Если пользователь на нее перейдет (а многие пользователи берут последнюю версию, потому что считают что чем новее, тем лучше, плюс на оф. сайте всегда предлагают последнюю версию устанавливать) то получат во-первых кучу проблем с совместимостью модулей, во-вторых через 2 месяца выйдет 3.0 и пользователям придется переходить уже на 3.0, как на более новую версию и под которую подозреваю со временем будет модулей больше, чем для проходной 2.3. 

А нужно было бы или делать 2.3 оставляя совместимость модулей (как делают все нормальные движки на минорных версиях) или не выпускать 2.3 вообще, а все изменения уже выпустить в 3.0, тогда и в 3.0 было бы действительно много изменений и она реально тянула бы на мажорную версию (а не была бы почти копией 2.3) и разработчикам было бы проще и пользователям не пришлось бы страдать.  

Надіслати
Поділитися на інших сайтах

А ничего что, по идее 2.3 == 3.0, и те кто по быстрому подсуетился, сделали задел на будущее и сэкономили время...

1.Появился Twig - как пишут, работает быстрее, чем просто пыха(хотя смутно верится, как может прослойка работать быстрее)

2.Есть уже namespace, не может не радовать

3. например, наверное я плохо знаю пыху, но по моему, такая конструкция - "foreach ($this->cart->getProducts() as $product) {"

работает только начиная с 5.5 т.е.результат метода

Надіслати
Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.