Zend Framework, custom PHP installatie en htaccess

[Daan]

Hallo,

Ben bezig met het opzetten van Zend Framework op een (shared) hosting account bij DreamHost. Heb hiervoor een custom PHP install moeten doen vanwege een custom include_path in de php.ini voor ZF.

Heb hiervoor ook een .htaccess moeten aanmaken in de root folder en die ziet er als volgt uit:

code:

Options +ExecCGI
AddHandler php-cgi .php
Action php-cgi /cgi-bin/php.cgi

<FilesMatch "^php5?\.(ini|cgi)$">
Order Deny,Allow
Deny from All
Allow from env=REDIRECT_STATUS
</FilesMatch>

Dat werkt allemaal prima, PHP files worden gewoon door de nieuwe install geparsed.

Om ZF lekker te laten werken moet ik wat mod_rewrite rules aanmaken zodat het allemaal mooi via een directory structuur werkt (mensen bekend met ZF weten wat ik bedoel). Nu wil het zo zijn dat de rewrite rules hiervoor interfereren met de .htaccess code van hierboven, ik krijg namelijk mooie HTTP 500 errors als ik ook maar iets aanroep. Dit zijn de rewrite rules voor ZF (voor shared hosting, hier vandaan geplukt):

code:

RewriteEngine On

RewriteRule ^\.htaccess$ - [F]
RewriteCond %{REQUEST_URI} =""

RewriteRule ^.*$ /public/index.php [NC,L]
RewriteCond %{REQUEST_URI} !^/public/.*$

RewriteRule ^(.*)$ /public/$1
RewriteCond %{REQUEST_FILENAME} -f

RewriteRule ^.*$ - [NC,L]
RewriteRule ^public/.*$ /public/index.php [NC,L]

Ik heb deze rewrite rules ook al geprobeerd, met hetzelfde resultaat.

Mijn application draait in de root van mijn hosting account en dat ziet er zo uit:

code:

- zend (ZF files)
- php5 (custom PHP install files met custom php.ini)
- <domain_name_hier> (domain root)
  - application
  - cgi-bin (php.cgi)
  - library
  - public
  - tests
  - .htaccess
  - .zfproject.xml

Die .htaccess daar heeft dus de custom PHP install code en de ZF rewrite rules erin.

Hoe kan ik er nou voor zorgen dat dit werkt, dat zowel mijn custom PHP aan wordt geroepen en dat de ZF rewrite rules werken, ook zonder dat die rewrite rules worden toegepast op de /cgi-bin/ folder van mijn custom PHP?

[Voutloos]

Het enige dat je voor het laden van ZF hoeft te doen is een set_include_path(), dus waarom moet je uberhaupt aan de installatie sleutelen?

[Daan]

Ik sleutel verder niet aan ZF, het is alleen dat het htaccess gedeelte voor ZF interfereert met het htaccess gedeelte voor de custom PHP install. Tenminste, dat vermoed ik (ben niet erg bekend met htaccess)..

[Cartman!]

Zoals Voutloos al zegt, je hebt helemaal niks te zoeken bij de install van PHP zelf voor ZF. Include pad kun je gewoon binnen je script aanpassen/uitbreiden. Als .htaccess gebruik ik het volgende, werkt tot nu toe overal:

code:

# Set the default character set to UTF-8
AddDefaultCharset UTF-8

# disable directory listing
Options -Indexes

# etags
FileETag MTime Size

# Redirect all URLs with no corresponding file or directory to the FrontController
<IfModule mod_rewrite.c>
    
    # Enable mod_rewrite
    RewriteEngine On

    # if not a file or dir; rewrite to index
    RewriteCond     %{REQUEST_FILENAME}     !-f             
    RewriteCond     %{REQUEST_FILENAME}     !-d
    RewriteRule     ^(.*)$                  index.php       [L]

</IfModule>

Zoek eens op google naar "mod_rewrite cheat sheet", erg handig

[mithras]

De reden voor een custom install is inderdaad niet nodig, als het je alleen gaat om de include_path. Je kan de include_path plaatsen in de php.ini, de .htaccess of in je index.php.

Met verder de standaard .htaccess zoals in de quickstart is aangegeven moet je er al komen. Die can Cartman! is daarnaast ook mogelijk (hoewel het niet heel veel verschilt).

[Daan]

Hmm, include_path zetten in the index.php van ZF lijkt te werken. Heb de custom PHP htaccess meuk weggehaald en hij draait nu gewoon op de PHP van DreamHost.

Ik denk dat de reden voor de custom install was omdat DH een oudere versie draaide (nu 5.2.6 i.p.v. 5.2.9, maar dat is geen ramp) en dat men daarvoor aanraadde om een custom PHP te installen.

Bedankt voor de hulp iig!

[Cartman!]

5.2.6 is ook goed genoeg voor ZF, custom versie had niet nodig geweest. Neemt niet weg dat t wel lekker is om te beginnen met de meest up2date versie

[Matis]

Daan schreef op vrijdag 12 juni 2009 @ 17:39:
Hmm, include_path zetten in the index.php van ZF lijkt te werken. Heb de custom PHP htaccess meuk weggehaald en hij draait nu gewoon op de PHP van DreamHost.

Als je de documentatie van ZF had gelezen had je zelfs een voorbeeld gekregen hoe het had gemoeten

CONFIGURING THE INCLUDE PATH
----------------------------

Once you have a copy of Zend Framework available, your application will need to
access the framework classes. Though there are several ways to achieve this, your
PHP include_path needs to contain the path to the Zend Framework classes under the
/library directory in this distribution. You can find out more about the PHP
include_path configuration directive here:

http://www.php.net/manual/en/ini.core.php#ini.include-path

Instructions on how to change PHP configuration directives can be found here:

http://www.php.net/manual/en/configuration.changes.php

Dat wordt dus zoiets als voor Windows Servers:

PHP:

ini_set('include_path',ini_get('include_path').';c:\domains\jedomein.nl\wwwroot\...\ZendFramework\library');

[ Voor 7% gewijzigd door Matis op 13-06-2009 09:34 ]

[mithras]

Matis schreef op zaterdag 13 juni 2009 @ 09:31:
[...]

Dat wordt dus zoiets als voor Windows Servers:

PHP:

ini_set('include_path',ini_get('include_path').';c:\domains\jedomein.nl\wwwroot\...\ZendFramework\library');

Als je de performance guide leest zie je dat het handiger is om éérst het Zend Framework in je include path te zetten, omdat dat nogal kan schelen in het aantal iteraties om een bestand te vinden.

Daarnaast zou ik nog twee andere tips geven: de constant PATH_SEPARATOR op paden aan elkaar te zetten; dan ben je platform onafhankelijk
Ten slotte kan je makkelijker een relatief pad gebruiken en dat omzetten naar een absoluut. Als je dan je applicatie ergens op een andere plek neerzet blijft het gewoon werken.

Ergo:

PHP:

//Define path to website
defined('WEBSITE_PATH')
    || define('WEBSITE_PATH', realpath( dirname( __FILE__ ) . '/../' ) );

// Define path to base of project
defined('BASE_PATH')
    || define('BASE_PATH', realpath( WEBSITE_PATH . '/../../' ) );

// Define path to application directory
defined('APPLICATION_PATH')
    || define('APPLICATION_PATH', BASE_PATH . '/application');

set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    get_include_path(),
)));

[Daan]

Matis schreef op zaterdag 13 juni 2009 @ 09:31:
[...]


Als je de documentatie van ZF had gelezen had je zelfs een voorbeeld gekregen hoe het had gemoeten

Ja het punt is dat men aanraadde om een custom PHP install te doen, en dat heb ik toen gewoon gedaan. Achteraf gezien was die informatie waarschijnlijk wat verouderd en de reden dom dat te doen niet meer zo relevant. Ik denk dat destijds DreamHost nog op PHP4 draaide toen PHP5 net uit was, en omdat ZF PHP5 nodig heeft moest je een custom PHP install doen. Nu DreamHost PHP 5.2.6 heeft is dat niet meer boeiend en kan je af met een custom include_path.

Heb dit in mijn public/index.php van mijn ZF app gezet:

PHP:

// Set include_path for ZF
ini_set('include_path',ini_get('include_path').':/home/<username>/zend/library:');

[Cartman!]

Lees de post van mithras nog eens, zitten nog n paar goede tips bij

[drm]

offtopic:
die "statement || anotherstatement" notatie ben ik in de ZF code ook al tegengekomen, en ik moet zeggen dat ik dat stiekem wel bad practice vind. Waarom niet gewoon een if (! ... ) { ... }, dat is toch veel duidelijker?

[Cartman!]

Vind ik ook drm, maar dat is gewoon persoonlijke voorkeur van de developer denk ik.

[Voutloos]

Het valt onder code style, en dus voorkeuren, maar er is wel degelijk een argument dat de intentie veel minder duidelijk is. Imo kan je het ook wel een obfuscation truc willen noemen.

[mithras]

Tja, ik gebruik het eigenlijk ook niet in mijn eigen code

Het stukje komt uit de quickstart en op zich vind ik de defined() || define() wel een stuk opener / leger ogen dan die if(!defined()) {define()}. En ik wil mijn index.php zo leeg mogelijk houden, dus ook als het er leger uitziet is het beter

Maar verder ben ik het met jullie eens. Op zich gebeurt het ook niet in het framework zelf. In de coding standard staat expliciet vermeld hoe je if/else statements moet schrijven