как в opencart 2 и 3 из любого места кода получить route?

[sazonoff]

как в opencart 2 и 3 из любого места кода получить route?

имеется ввиду во это: 

 

$this->request->get['route'];

 

Как, например, из своей библиотеки, т.е. там, где $this не работает получить значение route?

В opencart 2 есть глобальная переменная (объект), которая видна везде - это $registry, можно через нее.

В opencart 3 глобальная $registry уже недоступна.

 

Так как правильно вытащить route?

 

Как получить первичный route - это понятно, он легко берется из запроса сервера, но если работает ЧПУ, то route в итоге будет другой. Вот нужен этот конечный route, который и есть:

 

$this->request->get['route'];

 

[thentru]

своя библиотека, которая лежит в system/library?
тогда смотрите system\engine\loader.php

Спойлер

public function library($route) {
        // Sanitize the call
        $route = preg_replace('/[^a-zA-Z0-9_\/]/', '', (string)$route);
            
        $file = DIR_SYSTEM . 'library/' . $route . '.php';
        $class = str_replace('/', '\\', $route);

        if (is_file($file)) {
            include_once($file);

            $this->registry->set(basename($route), new $class($this->registry));
        } else {
            throw new \Exception('Error: Could not load library ' . $route . '!');
        }
    }

 

Змінено 25 листопада 2019 користувачем thentru

[i3bepb]

В 25.11.2019 в 09:03, sazonoff сказал:

В opencart 3 глобальная $registry уже недоступна.

 

В версии 3.0.3.2 и там тоже есть глобальная переменная $registry. В версии 2.3.0.2 тоже есть. И в версии 1.5.4, тоже есть. Это конкретные версии, что были под рукой посмотреть.

Т.е. везде есть такая запись

$registry->set('request', new Request());

И Вы можете всегда получить 

$registry->request->get['route']

 

[i3bepb]

В 25.11.2019 в 09:03, sazonoff сказал:

Как получить первичный route - это понятно, он легко берется из запроса сервера, но если работает ЧПУ, то route в итоге будет другой. Вот нужен этот конечный route, который и есть

 

А в случае если включен ЧПУ, то после обработки rewrite веб-сервером, получается

$registry->request->get['_route_']

Т.е. первоначально нет route вообще затем до того как движок решает какой контроллер запустить он обрабатывает его в catalog/controller/startup/seo_url.php это в чистом без seo_pro или других модулей. Смотри метод index() в class ControllerStartupSeoUrl. Когда, что-то наворочено с seo, тогда просто либо этот класс заменятся другим, либо они последовательно обрабатывают друг за другом.

После сео манипуляции мы получаем:

$this->request->get['route']

Т.е. в $registry, который придет в контроллер будет route.

 

Ну а если рассматривать свою библиотеку, то если ее подключать в контроллере, то в ней должен быть route, но если например ее цеплять заранее то надо посмотреть файл system/framework.php. Это на примере версии 2.3.0.2

 

На скриншоте под номерами

1) Загружаются библиотеки

2) Обработка seo, т.е. из запроса получают route

3) Вызов конкретного контроллера и его метод

Дак вот может проблема в том, что к моменту когда загружается библиотека еще нет route. Вообще советую поразбираться в процессе загрузки движка, т.е. что происходит от момента вызова index.php до вызова нужного метода контроллера.

 

[sazonoff]

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

И Вы можете всегда получить 

$registry->request->get['route']

 

нет.

получите в 3-ке из библиотеки, например, response.php.

В 2-ке и в 1.5 - без проблем.

 

в 3-ке не получается.

 

            echo "==registry==";
			global $registry;
			var_dump($registry);
			echo $output;

 

так тоже самое

 

var_dump($GLOBALS['registry']);

 

Заметьте, что это происходит уже перед самым последним шагом, который делается, т.е. перед финальным echo $output;

 

Куда исчез $registry?

[sazonoff]

2 часа назад, i3bepb сказал:

Вообще советую поразбираться в процессе загрузки движка, т.е. что происходит от момента вызова index.php до вызова нужного метода контроллера.

 

я знаю как это происходит в 1.5 и в 2-ке.

Надеялся, что подскажут, что же изменилось в 3-ке.

на каком этапе и зачем удаляется $registry?

 

Где-то в середине скрипта $registry доступен, а потом исчезает. Так только в 3-ке.

Я вообще не понимаю для чего нужно было делать такую несовместимость с 2-кой?

Уже привык к $registry, а тут сюрприз.

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

вот зачем переименовал token в user_token?  Ничего кроме несвоместимости не получили.

[i3bepb]

50 минут назад, sazonoff сказал:

Надеялся, что подскажут, что же изменилось в 3-ке.

на каком этапе и зачем удаляется $registry?

 

Глянул код 3 версии еще. В итоге следую цепочке index.php -> system/startup.php -> system/framework.php становится понятным, что в отличие от 2-ой версии файл system/framework.php это не кусок кода в глобальном пространстве, а грубо говоря тело функции start. Это видно в файле system/startup.php

function start($application_config) {
	require_once(DIR_SYSTEM . 'framework.php');	
}

Из этого получается, что все переменные определенные в файле system/framework.php находятся не в глобальном пространстве, а в пространстве функции start, а именно там определяется $registry. Чтобы получить доступ к $registry в response.php можно про кинуть $registry в глобальное пространство, в начале файла system/framework.php написать

global $registry;

И по старой схеме, файл response.php

	public function output() {
        global $registry;
	    exit($registry->request->get['route']);

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

[sazonoff]

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

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

 

и тем самым поломали совместимость модулей, которые делались для 2.3. Теперь они не подходят под 3.0.

Стоило ли такое хотение или нехотение разработчиков поломки совместимости?

 

Я не могу понять, что же такого интересного появилось в 3-ке, что из-за этого можно было похерить совместимость с модулями от 2.3?

На одной стороне куча наработанных модулей для 2.*, а на другой - что?

 

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

это не кусок кода в глобальном пространстве

 

я это и предполагал. непонятно только чего этим добиться хотели то?

Повысить безопасность?  Это сомнительно, т.к. все данные из config.php остаются доступными в глобальной области видимости, и этих данных достаточно чтобы получить доступ к чему угодно. Хотите доступ к БД? Пожалуйста! А в ней все на свете настройки и доступы есть.

Так смысл изолировать $registry?

Ведь в общепринятых практиках программирования он именно глобальный.

 

 

[sazonoff]

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

Чтобы получить доступ к $registry в response.php можно про кинуть $registry в глобальное пространство

 

как вариант.

правда, неэлегантное решение получается.

[sazonoff]

еще как вариант:

 

вместо

// Output
$response->output();

делаем в system/framework.php

// Output
$response->output($registry);

 

соответственно в response.php

 

 

Но лучше сделать через дополнительное свойство $route к классу Response.

Делаем, например

 

class Response {
	private $headers = array();
	private $level = 0;
	private $output;
    public $route;

 

в system/framework.php   добавляем строку:

$response->route = empty($registry->get('request')->get['route']) ? null: $registry->get('request')->get['route'];
$response->output();

 

а в самом классе Response используем:

 

var_dump($this->route);

 

Обошлись без глобальных переменных.

И удобно сделать через ocmod без боязни, что ocmod сторонних авторов что-то испортит или мы испортим им. Т.е. максимальная совместимость будет.

Можно, конечно, и через private переменную с публичным методом, но это уже не суть.

[sazonoff]

В 04.12.2019 в 12:36, i3bepb сказал:

в начале файла system/framework.php написать

 

не так то все просто.

файл framework.php защищен от модификаций.  можно сколько угодно его менять через ocmod, но загружаться всегда будет из папки system, но не из папки модификаций.

 

Как можно в нем что-то прописать тогда?

Грубые правки руками - это все, что возможно?

Но править framework.php  не будем.

Змінено 4 січня 2020 користувачем sazonoff

[sazonoff]

$_REQUEST['route']

можно взять отсюда.

 

или сделать 

$request2 = new Request();

 

[sazonoff]

14 часов назад, sazonoff сказал:

$_REQUEST['route']

 

так тоже не получится, т.к. можно получить только 

['_route_'], т.е. то, что до обработки ЧПУ.

А вот финальный route пока не пойму как вытянуть.

[chukcha]

В 05.12.2019 в 00:01, sazonoff сказал:

которые делались для 2.3.

Не может быть

в 2.3.
 

// Startup
require_once(DIR_SYSTEM . 'startup.php');

start('catalog');

в 3.0
 

// Startup
require_once(DIR_SYSTEM . 'startup.php');

start('catalog');

найдите разницу

Ой?

?php
final class Openbay {
	private $registry;
	private $installed_modules = array();
	public $installed_markets = array();
	private $logging = 1;

	public function __construct($registry) {

А тут есть


 

[sazonoff]

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

Не может быть

в 2.3.

 

придирки.

и вы, и я знаем, что речь о 2.1 идет. с 2.3 registry перестал быть глобальным.

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

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

Это форум программистов? На котором нельзя сделать исправления в опубликованном коде?

 

суть темы вовсе не в этом. а как просто и элегантно получить в 2.3 и 3.0 доступ к register из любого места.

Змінено 4 січня 2020 користувачем sazonoff

[sazonoff]

Как решение задачи можно взять любой контроллер.

например, header и в нем передать куда надо 

$this->request->get['route']

или хоть целиком 

 

$this->registry

[chukcha]

Вам нужно получить, грубо говоря registry или стать потомком от controler или model
Я вам показал как в библиотеку можно предать registry