Jump to content

Search the Community

Showing results for tags 'dateformat'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Richiesta informazioni e consigli hosting
    • Domini e Registrazioni
    • Shared e Managed Webhosting
    • WebHosting - Primi passi
    • Server dedicati, colocation, connettività e scelta data center
    • VPS - Virtual Private Server
    • Cloud Computing e Cloud Hosting
    • Gestione Server Windows e Server Linux
    • E-mail e Managed Services
    • Pannelli di controllo e Hosting software
    • Professione Hosting Provider
  • Sviluppo Web e Tempo Libero
    • Io Programmo
    • Promozione, advertising e SEO
    • Off-Topic
    • Il tuo sito
  • Guide su hosting, domini, server, CMS e Cloud Computing
    • Articoli e Guide su hosting, domini e cloud computing
    • Annunci e News
    • Offerte Hosting - Provider HostingTalk.it

Calendars

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Biografia


Località


Interessi


Cosa fai nella vita?


Il tuo Hosting Provider?

Found 1 result

  1. Questo tutorial pubblicato anche sul mio blog è frutto di un pomeriggio di bestemmie e tentativi vari di installare Drupal 6.0 su Centos 5.* : Oggi mi sono trovato a risolvere un problema piuttosto fastidioso riguardo il sito di un mio cliente basato su Drupal 6. Detto in parole povere questo sito era hostato su una Linux Centos 5.4 con la versione ufficiale di PHP ovvero la 5.1.6 e si piantava in maniera poco ortodossa restituendo nall’error_log la seguente dicitura : Call to undefined function: date_format() Facendo una breve ricerca ho letto che questa funzione è presente sin dalla versione 5.1 del PHP e dunque non avrebbe dovuto esserci alcun problema anche se nella pratica il problema c’era eccome. Leggendo su vari forum ho notato che tutti consigliavano il passaggio alla versione 5.2.6 di PHP tramite l’utilizzo di repository non ufficiali come quello di REMI ad esempio rischiando comunque di “rompere” le dipendenze tra i vari pacchetti e sopratutto di destabilizzare un server in produzione. La realtà invece era ben diversa e non immaginabile a priori (purtroppo). Le funzioni PHP in questione sono incluse infatti di default dalla versione 5.2 del PHP, MA … (MA) sono incluse come funzioni SPERIMENTALI nella versione 5.1.6 e disabilitate di default. Onde evitare di passare molto pericolosamente alla versione 5.2 ho scelto dunque di abilitare queste funzioni “sperimentali” ricompilando il pacchetto RPM di PHP 5.1.6 Ecco una breve guida per i sistemisti che vogliano ovviare in un modo molto elegante (e anche macchinoso) a questo fastidiosissimo problema. Prerequisiti : Accesso Root tramite SSH al sistema. 1) Scarica il pacchetto SRPMS della versione PHP corrente (rpm -qa | grep php) da rpm.pbone.net o da un relativo mirror : wget ftp://mirror.switch.ch/pool/3/mirror/centos/5.3/updates/SRPMS/php-5.1.6-23.2.el5_3.src.rpm 2) Crea la tua area per ricompilare il pacchetto RPM (da un utente NON root): echo "%_topdir /home/nomeutentecorrente/src/rpm" >> ~/.rpmmacros mkdir -p ~/src/rpm/ cd ~/src/rpm mkdir BUILD RPMS RPMS/i386 SOURCES SPECS SRPMS 3) Installa il pacchetto SRPM (sempre da utente non root) rpm -ivh php-5.1.6-23.2.el5_3.src.rpm Questo comando metterà il tarball sorgente e le patch nella dir SOURCES e lo specfile (istruzioni per la compilazione) in SPECS 4) Editare lo SPEC chiamato php.spec Trovare una linea in cui c’è scritto : CFLAGS=”RPM_OPT_FLAGS -fno-strict-aliasing -Wno-pointer-sign” ed aggiungere -DEXPERIMENTAL_DATE_SUPPORT=1 deve essere modificata esattamente in : CFLAGS="RPM_OPT_FLAGS -fno-strict-aliasing -Wno-pointer-sign -DEXPERIMENTAL_DATE_SUPPORT=1" In questo modo si passano i flag al compilatore GCC abilitando le feature sperimentali sulle date. 5) Ricompilare il PHP ricreando il file .rpm (da utente non root): rpmbuild -ba SPECS/php.spec E’ possibile che sia necessario installare alcuni pacchetti addizionali (solitamente quelli di sviluppo almeno) per soddisfare tutte le dipendenze. Il sistema compilerà PHP e potrà richiedere anche una 20ina di minuti su sistemi non troppo performanti, motivo per cui si consiglia di effettuare l’operazione di notte o in regimi di non produttività. Una volta finito il pacchetto corretto sarà creato dentro a RPMS/i386 6) Estratte i binari dai pacchetti RPM generati. Troverete diversi file .rpm all’interno di questa cartella ma a noi interessa solo quello chiamato php-5.1.6-23.2.i386.rpm Prendiamo il file e scompattiamolo in una cartella ad esempio chiamata pippo sotto /tmp mkdir /tmp/pippo mv php-5.1.6-23.2.i386.rpm /tmp/pippo rpm2cpio php-5.1.6-23.2.i386.rpm | cpio -idmv 7) Sostituzione File. (da root) Troveremo essenzialmente un albero di directory all’interno di questa cartella che rispecchia a grosso modo l’albero del sistema corrente : /usr/bin /usr/lib Sostituiamo i seguenti file del sistema correnti con questi appena scompatatti : /usr/lib/httpd/modules/libphp5.so /usr/bin/php /usr/bin/php-cgi Ripristiniamo i permessi e i proprietari corretti per i seguenti file cambiati e riavviamo Apache. Voilà … problema risolto. PICCOLA NOTA : Ma non è ora che Redhat (da cui deriva CentOS) non dedichi un po’ più di tempo agli aggiornamenti del suo software e agli upgrade delle versioni ? Mi sembra assurdo che una distribuzione che si vanta di avere un lifecycle di ben 7 anni abbia la faccia tosta di lasciare i propri clienti con versioni a mio avviso obsolete di PHP e MySQL, sopratutto in ambiente di virtualhosting dove le abitudini dei programmatori e le applicazioni php installate dai clienti sono piuttosto eterogene. Un modo nativo e ufficiale per poter supportare i continui aggiornamenti e il progredire di PHP 5 senza rompere la retrocompatibilità no eh ?
×