Keskustelu: Nettisivujen teko: Ongelmia php_intl:n kanssa

Moi yritän tehdä CakePHP:lä projektia, mutta kun yritän surfata esimerkin etu sivulle php valittaa ettei vendor/Autoload.php:tä löydy. Composer valittaa jotain intl:stä, jota ei ilmeiseti lampista löydy, vaikka oli php.inissä kommentoituna.
Joten mistä ton intl:n sais?

Oskuz kirjoitti:

php valittaa ettei vendor/Autoload.php:tä löydy.

Kuulostaa ongelmalta, joka ei liity intl-moduuliin. (En toki tiedä CakePHP:stä tai intl-moduulista paljonkaan.)

Oskuz kirjoitti:

Composer valittaa jotain intl:stä, jota ei ilmeiseti lampista löydy

Miten "ilmeisesti"? Oletko tarkistanut asian esimerkiksi selaamalla PHP:n moduulihakemistoa? Mistä ihmeen "lampista"? Itse en ainakaan tiedä mistään valmiista LAMP-paketista (juuri sillä nimellä).

Oskuz kirjoitti:

Joten mistä ton intl:n sais?

Kun pohjalla on Linux, sekä PHP että sen yleisimmät moduulit löytyvät varmasti paketinhallinnan kautta. Vaikea auttaa sen enempää noin vähäisillä lähtötiedoilla.

Pohjimmiltaan PHP:n intl-moduuli löytyy PHP:n lähdekoodista, josta sen voi itse kääntää. Tämä luultavasti ei ole haluamasi ratkaisu.

Oskuz kirjoitti:

vaikka oli php.inissä kommentoituna

Kai otit sen kommenttimerkin pois ja käynnistit ohjelman uudestaan?

Metabolix kirjoitti:

Kuulostaa ongelmalta, joka ei liity intl-moduuliin. (En toki tiedä CakePHP:stä tai intl-moduulista paljonkaan.)

Composer luo ton autoload-tiedoston, mutta se ei onnistu koska ei ole tota moduulia.

Metabolix kirjoitti:

Kai otit sen kommenttimerkin pois ja käynnistit ohjelman uudestaan?

Otin. Ja selasin php-asennuksen sivussa olevat kansiot ton varalta.

Ja Bitnamin LAMP

Edit: php -m komento ei ainakaan listannut kyseistä moduulia, ja mitä selasi Bitnamin foorumia, niin kyseistä moduulia ei ole ollu joissain varhaisemmissa versioissa, mutta tästä se pitäisi löytyä.

Oskuz kirjoitti:

Bitnamin LAMP

Asensin kokeeksi uusimman Bitnamin LAMP-paketin (5.5.30), ja kyllä minulla intl-moduuli näyttää olevan oletuksena käytössä.

# ./lampstack-5.5.30-0/php/bin/php -m
[PHP Modules]
...
intl
...

Moduuli on paketissa käännetty suoraan PHP:n binääriin, eli erillistä moduulitiedostoa ei kuulu ollakaan eikä moduulia tarvitse erikseen listata php.ini-tiedostoon. Ja kai olet tietoinen, että Linuxissa ei edes käytetä DLL-tiedostoja, eli php.inin extension=php_intl.dll on vain Windowsia koskeva ja Linuxissa täysin tarpeeton ellei jopa virheellinen rivi?

Et kai ole jotenkin sekoillut Bitnamin paketin ja Linux-jakelusi omien pakettien kanssa?

Hieman ihmetyttää, miksi edes käytät tuollaista purkkapakettia etkä asenna ohjelmia normaalisti paketinhallinnan kautta.

Metabolix kirjoitti:

Moduuli on paketissa käännetty suoraan PHP:n binäär
Et kai ole jotenkin sekoillut Bitnamin paketin ja Linux-jakelusi omien pakettien kanssa?

Hieman ihmetyttää, miksi edes käytät tuollaista purkkapakettia etkä asenna ohjelmia normaalisti paketinhallinnan kautta.

Jeps, ratkes. Koska purkkapaketin kanssa ei tarvitse oikeuksia.. Ja koska se oli vähän liian helppo ratkaisu Windowsiin tottuneelle :). Kiitos.

Nykyaikana tuo sovelluskohtainen php alkaa vaikuttaa jopa järkevämmältä ratkaisulta, kun palvelimella ajetaan useampaa järjestelmää rinnakkain. Ei tarvitse joka päivityksen yhteydessä pelätä hajottavansa jotain. Viimeksi törmäsin yhteensopivuusongelmiin versioiden 5.5 ja 5.6 json-toteutuksien välillä, eli kyse ei aina ole siitä että jokin palvelimelle "unohtunut" palvelu vaatii php 5.2:n ja muut tarvitsisivat uudempaa.