Come utilizzare punti nelle URL

Quando in un progetto si utilizzano url contenenti punti, in una installazione standard di symfony, si otterrà dal server web un errore 404: questo perché verrà cercato dal server stesso un file piuttosto che ridirigere la richiesta al motore di routing di symfony.
Facciamo un esempio pratico:
routing.yml:
test:
url: /test/:title
param: { module: test, action: index }

/modules/test/templates/indexSuccess.php:
<?php echo $sf_params->get('title'); ?>

Ora se visitiamo la seguente url http://localhost/test/abc apparirà a video la scritta abc.
Se invece utilizziamo quest’altra url http://localhost/test/a.b.c il risultato sarà un errore 4040 “The requested URL /test/a.bc was not found on this server.”.

Per evitare questo comportamento si deve mettere mano al file .htaccess presente nella directory web del nostro progetto per un veloce hack, commentando la prima regola di rewriting in questo modo:

# we skip all files with .something
#RewriteCond %{REQUEST_URI} \..+$
#RewriteCond %{REQUEST_URI} !\.html$
#RewriteRule .* - [L]

In questa maniera ricaricando l’url http://localhost/test/a.b.c si otterrà nel browser il risultato voluto, cioè la stringa “a.b.c”

Symfony e YUI

Durante l’ultimo Symfony Camp (che ahimè mi son perso) l’ottimo Dustin Whittle (responsabile di progetti symfony-based in Yahoo!) ha presentato alcune slide che spiegano l’integrazione delle Yahoo! User Interface Library (YUI) nel framework.
Se anche tu come me sei dispiaciuto di aver perso il Camp, ma vuoi comunque vedere le slide di Dustin, allora clikka qui.
Per il post di Fabien (e slide relative) puoi invece clikkare qui.

Symfony arriva a 1.0.7

Oggi è stata rilasciata la nuova versione 1.0.7 del ramo stabile di symfony, versione, come le precedenti del branch 1.0.x, dedicata al bug fixing: in particolare questa versione risolve numerosi problemi riscontrati con il dump e il load dei dati del database (propel-dump-data e propel-load-data).
Questa è la prima versione rilasciata dal duo Noël e Grégoire che gestiranno d’ora in poi il ramo stabile, visto che adesso Fabien si dedicherà alla futura versione 1.1

eAccelerator e routing dei metodi

Se utilizzate eAccelerator sul vostro server di produzione e con le ultime due versioni di symfony ottenete strani messaggi di errore relativi al routing dei metodi simili a

Fatal error: 
Uncaught exception 'sfStopException' in /usr/share/pear/symfony/action/sfAction.class.php:136 Stack trace: 
#0 /var/www/html/progetto/apps/applicazione/modules/modulo/actions\actions.class.php(19): sfAction->forward('default', 'module') 
#1 /usr/share/pear/symfony/action/sfActions.class.php(53): connectActions->executeIndex() 
#2 /usr/share/pear/symfony/filter/sfExecutionFilter.class.php(115): sfActions->execute() 
#3 /usr/share/pear/symfony/filter/sfFilterChain.class.php(43): sfExecutionFilter->execute(Object(sfFilterChain)) 
#4 /usr/share/pear/symfony/filter/sfFlashFilter.class.php(50): sfFilterChain->execute() 
#5 /usr/share/pear/symfony/filter/sfFilterChain.class.php(43): sfFlashFilter->execute(Object(sfFilterChain)) 
#6 /usr/share/pear/symfony/filter/sfCommonFilter.class.php(29): sfFilterChain->execute() 
#7 /usr/share/pear/symfony/filter/sfFilterChain.class.php(43): sfCommonFilter->execute(Object(sfFilterChain)) 
#8 /usr/share/pear/symfony/filter/sfWebDeb in  /usr/share/pear/symfony/action/sfAction.class.php on line 136

significa che siete incappati in questo scomodo bug.

La soluzione è molto semplice, basta infatti disabilitare il modulo eAccellerator per php o alternativamente limitarsi a bloccarne l’ottimizzazione modificando nel php.ini la direttiva eaccelerator.optimizer = "0" finchè non sarà rilasciata la nuova versione dell’optimizer.

via sfForum