Geekly Articles each Day
📜 ⬆️ ⬇️

Bitrix - UrlRewrite (feat. Juggernaut)



Hello!

We continue to peel articles on the topic "Bitrix is ​​not so bad if it is finalized."
This time the conversation will go on the topic “url_rewrite”, because I believe that the current version is not perfect at all.
And I consider ideal the option of routing in microfreemvorki, for example Slim (or the same Lumen), in general, those who are friends with PSR-7.
Who cares, go under the cat.
Who is not interested, well, then decide for yourself ;-)

Intro


Actually, my previous articles were less abstract (well, except for the article about Juggernaut, perhaps), so in this post I will try to write less theory and more code.
')

By the way about Juggernaut


Documentation will be soon, unfortunately there are some obstacles:
  1. time
  2. refactoring
  3. I loved TDD, so refactoring stopped until I write tests
  4. The development direction of the library, as it turned out, I did not quite determine until the end


But this is how to say “a completely different story”, so let's return to what this article is about: routing.

UrlRewrite by Bitrix


I think it is better to portray the routing scheme with a schematic (and clearly, and clearly):



What it all means:

include bitrix / urlRewrite.php
We connect the file that deals with routing (well, I think this, and so everyone understood).
In general, this item (and all that is higher in the block diagram) is the merit of .htaccess :

RewriteCond %{REQUEST_FILENAME} !-f #   RewriteCond %{REQUEST_FILENAME} !-l #    RewriteCond %{REQUEST_FILENAME} !-d #   RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$ #    RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

fix request_uri for IIS
This item, judging by the comments in the code, is responsible for some IIS shoals (poor MS), for which I do not know, but the logic is as follows:
if QUERY_STRING has the form "wtf = 404; http (s): //wtf.ru", then all GET request parameters are cleaned and this construct is removed from the address.
I can't give an answer to the question “what is happening?”, So we are going further.

include dbconn.php
Connect the base.
What for? It is not clear, since there are no further requests to the database and work only with the file system.
Of course, I didn’t fall into the implementation of classes for working with files, but if they need something from the database, then it’s sad :-(

decode request page (for UTF-8)
Everything is clear from the title, REQUEST_URI coding.
What for? Why does Bitrix love Windows-1251? No idea. But it will go on forever (and this is insider information).

include /urlRewrite.php
Actually connect the routing rules themselves.

process url
A bit strange actions, but the following still happens:
If there is a GET parameter SEF_APPLICATION_CUR_PAGE_URL, then we equate REQUEST_URI to its value, and then rewrite all dependent variables and global arrays ($ _GET, $ _SERVER, ...)

process urlRewrite
Oh yeah!
We got to it.
Actually what happens:

I’m confused by the fact that the test is going after we have already thrust all the parameters into global variables?

A lot of ambiguity, why was it done this way and not otherwise?
Well, a lot of ambiguity, why is it done at all?
So now we go to the ideal option Slim'a.

UrlRewrite by Slim


How does this wonderful framework:

 $app = new \Slim\App(); $app->get('catalog/{sectionCode}/{elementCode}/', function(Request $request, Response $response) { // code }); $app->post('catalog/{sectionCode}/{elementCode}/', function(Request $request, Response $response) { // code }); $app->put('catalog/{sectionCode}/{elementCode}/', function(Request $request, Response $response) { // code }); $app->delete('catalog/{sectionCode}/{elementCode}/', function(Request $request, Response $response) { // code }); $app->run();

Easily and naturally we cling to the necessary action, with the necessary route, parameters and implementation.

UrlRewrite by Juhhernaut


Well, now try all this mixanut.
We throw out the method from the Slim and the actual implementation of the action, instead it will be the path to the file.
To begin with, we denote the syntax of binding routes to physically real files (in fact, this is the use manual):

 /* *     */ include_once __DIR__.'/modules/olof.juggernaut/includeRewrite.php'; use Jugger\Context\Router; /** *   *    Slim'a   ,   *      , *      */ $r = new Router(); /* *      * , URL   : "/catalog/section1/section2/element1/", *          'index.php': * - /catalog/section1/section2/element1/index.php * - /catalog/section1/section2/index.php * - /catalog/section1/index.php * - /catalog/index.php * *        *         GET  REQUEST, * ..    *         *       */ $r->runRecursive(); /* *   *  : * {nameParam}, * {nameParam:regExp} *  'regExp' -  . , '\d+'  '[0-9]+' */ $r->run( "/page/", "/page/index1.php" ); $r->run( "/page/{p1:[0-9]+}/{p2}", "/page/index2.php" ); $r->run( "/catalog/", "/catalog/index1.php" ); /* *     */ $r->run( [ "/catalog/{sectionCode}/", "/catalog/{sectionCode}/{elementId:\d+}/", ], "/catalog/index2.php" ); /* *       ?r=path/to/file */ $r->run("{r:.+}", "index.php"); /* *   *      *   /bitrix/urlrewrite.php */ $r->end();

In fact, if the implementation of the routes is left on the conscience of the components, then it will suffice to prescribe the following construction (yes, this is also possible ;-)):

 (new Router()) ->runRecursive() ->end();

This file should (you can) call urlrewrite.php, drop it into the / local / folder and make edits to the .htaccess file, which lies in the root.

Instead:
 RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$ RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

It is necessary to register:
 RewriteCond %{REQUEST_FILENAME} !/local/urlrewrite.php$ RewriteRule ^(.*)$ /local/urlrewrite.php [L]

And actually everything. Easy routing in your pocket.

References:


Juggernaut : github.com/irpsv/juggernaut.bitrix
Implementation of the router : github.com/irpsv/juggernaut.bitrix/blob/master/olof.juggernaut/lib/Context/Router.php

Source: https://habr.com/ru/post/305382/

More articles:


All Articles