parse_url() alternatíva

HTML-ből kiszedett url-eket dolgoztam volna fel, de a PHP beépített parse_url() függvénye egy warning kíséretében elszáll, ha relatív url-eket adunk meg.

Szintén nem tetszenek neki az olyan URI-k, mint pl. a mailto: vagy ftp://

Írtam egy függvényt, ami úgy dolgozza fel az URL-eket és URI-kat, hogy

  • soha nem száll el warning-al
  • jól kezeli a relatív URL-eket
  • teljes értékű helyettesítője a php parse_url()-nek

Itt a kód, illetve a post végén egy linken le is tölthető. Bárki bármilyen hibát talál, jelezze a hozzászólásoknál, hogy javíthassam.

<?php
function parse_url_relative($url, $component = NULL){
 
$full_rx = '!^
    (?P<scheme>[a-z][a-z0-9\+\-\.]*):/*         # scheme
    (?:(?P<user>[^:@]*)(?::(?P<pass>[^@]*))?@)? # user and password
    (?P<host>[^/\?\#:]*)                        # host
    (?::(?P<port>[0-9]+))?                      # port
    (?P<path>[^\?\#]*)                          # path
    (?:\?(?P<query>[^\#]*))?                    # query
    (?:\#(?P<fragment>.*))?                     # fragment
  $!ix'
;

 
$path_rx = '!^
    (?P<path>[^\?\#]*)                          # path
    (?:\?(?P<query>[^\#]*))?                    # query
    (?:\#(?P<fragment>.*))?                     # fragment
  $!ix'
;

  if (!
preg_match($full_rx, $url, $m)) {
   
preg_match($path_rx, $url, $m);
  }

 
$return = array(
   
'scheme'    => isset($m['scheme'])    ? $m['scheme']    : NULL,
   
'user'      => isset($m['user'])      ? $m['user']      : NULL,
   
'pass'      => isset($m['pass'])      ? $m['pass']      : NULL,
   
'host'      => isset($m['host'])      ? $m['host']      : NULL,
   
'port'      => isset($m['port'])      ? $m['port']      : NULL,
   
'path'      => isset($m['path'])      ? $m['path']      : '',
   
'query'     => isset($m['query'])     ? $m['query']     : '',
   
'fragment'  => isset($m['fragment'])  ? $m['fragment']  : '',
  );

  switch (
$component) {
    case
NULL:
      return
$return;
    case
PHP_URL_SCHEME:
      return
$return['scheme'];
    case
PHP_URL_HOST:
      return
$return['host'];
    case
PHP_URL_PORT:
      return
$return['port'];
    case
PHP_URL_USER:
      return
$return['user'];
    case
PHP_URL_PASS:
      return
$return['pass'];
    case
PHP_URL_PATH:
      return
$return['path'];
    case
PHP_URL_QUERY:
      return
$return['query'];
    case
PHP_URL_FRAGMENT:
      return
$return['fragment'];
  }
}
?>

Az Xdebug lassú és nem hagyja békén a var_dump()-ot

Tamás postján fellelkesülve, én is beállítottam itthon a php debug környezetet (PHPEclipse+xdebug). Eddig megvoltam nélküle, de bizony ha egyszer kipróbáljuk, nehéz lesz megválni tőle. Nélkülözhetetlen segítség a mindennapi PHP/Drupal hekkelés közben.

Az Eclipse-et én nem szerettem, és most sem a szívem csücske, de a PHPEclipse-el együtt egy használható eszköznek mondható. A debug melett kifejezetten hasznos funkció a kód kiegészítés és a gépelés közbeni szintaxis elemzés.

Viszont az Xdebug-os környezettel volt két komoly bajom: egyrészt érthetetlenül lassú egy oldal megjelenítése. Érthetetlen, mert sem az sql szerver, sem az apache (+php+xdebug) sem a böngésző kliens nem pörgette a CPU-t, mégis több másodpercig tartott egy oldal megjelenítése. A másik gond, hogy képtelen voltam rávenni az Xdebug-ot, hogy ne definiálja felül a var_dump() függvényt.

A var_dump()-ot sokat használom, főleg a Drupal devel moduljának dvm() függvényén keresztül. De ha belenyúl az Xdebug, a dvm() használhatatlan lesz. A neten (és az xdebug.org/docs-on!) jópár pletyka terjed, hogy miként lehet ezt hatástalanítani. Találtam én mindent, pl ilyeneket:

xdebug.overload_var_display = 0
// vagy
xdebug.overload_var_dump = 0

Érdekes módon nem működnek. Hosszas kutatás után viszont rátaláltam a megoldára: a nevével ellentétben az xdebug.default_enable nem a teljes xdebug-ot kapcsolja ki/be, hanem csak a megjelenítéssel kapcsolatos funkciókat. Tehát ha kikapcsoljuk, attól még a debug működik. Emellett érdemes még kikapcsolni a html_errors standard php.ini kapcsolót is, a teljesen korrekt működéshez.

A másik gond, ami felmerült, a lassú oldal letöltés. Egy E8500-as procin szerintem nem kéne 2-3 másodpercig tartania egyetlen oldal generálásának. Ezt az xdebug.remote_autostart = On beállítás okozta, ami miatt minden egyes oldaletöltés debug session-ként futott le. Ez felesleges, ki kell kapcsolni a fenti funkciót és ha debugolni szeretnénk, elég a GET paraméterek közé felvenni az XDEBUG_SESSION_START=debug_id változót.

Összegezve a fent leírtakat nekem xdebug-ra a következő recept vált be:

; var_dump felülírás hatástalanítása
xdebug.default_enable = Off
html_errors = Off

; debug funkciók bekapcsolása, de
xdebug.remote_enable = On

; debug session automatikusan ne induljon.
xdebug.remote_autostart = Off

A fenti beállításokkal és Tamás leírásával és linkjeivel, teljesen jól használható debug környezetet lehet kialakítani.

Mindenkinek jó rovarírtást.

Tömeges node műveletek

Összegyűlt pár apró ötletem, ami a mindennapi Drupal használat vagy programozás során jól jöhet. Úgy döntöttem indítok egy drupal gyors tippek sorozatot, ahol ezeket leírhatom. Ennek első eleme ez a post.

Véletlenül bukkantam a hook_node_operations hook-ba, amivel kiegészíthetjük az admin/content/node oldalon azt a legördülő listát amivel egyszerre több node-on végre tudunk hajtani egy műveletet.

Hasznos lehet például saját node fejlesztésénél, ha az a node típus igényel ilyen funkciót. De már meglévő node típusokra is implementálhatjuk, ha az adott oldalon egy műveletet gyakran végeznek el a node-okon. El tudok képzelni olyan szituációt, ahol például jól jönne a hozzászólások tiltása tömeges művelet.

A hook_node_operations használata egyszerű, felesleges itt ismételni azt ami egyértelműen le van írva a fenti api.drupal.org-os linken.

Ha van hasonló tippetek várom a hozzászólásokban.

Oldalak

Feliratkozás Prunk-Éger Edgár  RSS csatornájára