Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20492 > unrolled thread

PHP 7 upgrade

Back to article view | Back to it.comp.www.php

Contents

  PHP 7 upgrade Sandro kensan <kensan@kensan.it> - 2016-03-13 17:30 +0100
    Re: PHP 7 upgrade Alessandro Pellizzari <shuriken@amiran.it> - 2016-03-13 17:07 +0000
      Re: PHP 7 upgrade Sandro kensan <kensan@kensan.it> - 2016-03-13 20:08 +0100
        Re: PHP 7 upgrade Alessandro Pellizzari <shuriken@amiran.it> - 2016-03-13 19:26 +0000
      Re: PHP 7 upgrade Sandro kensan <kensan@kensan.it> - 2016-03-14 15:21 +0100
        Re: PHP 7 upgrade "ciccio" <21669invalid@mynewsgate.net> - 2016-03-15 11:09 +0000
        Re: PHP 7 upgrade fmassei@gmail.com - 2016-03-15 11:28 -0700
    Re: PHP 7 upgrade "ciccio" <21669invalid@mynewsgate.net> - 2016-03-15 11:08 +0000
      Re: PHP 7 upgrade Sandro kensan <kensan@kensan.it> - 2016-03-15 13:57 +0100
        Re: PHP 7 upgrade fmigliori <fmigliori@gmail.com> - 2016-03-15 09:17 -0700
          Re: PHP 7 upgrade "ciccio" <21669invalid@mynewsgate.net> - 2016-03-15 18:09 +0000
            Re: PHP 7 upgrade Sandro kensan <kensan@kensan.it> - 2016-03-16 15:57 +0100
              Re: PHP 7 upgrade "ciccio" <21669invalid@mynewsgate.net> - 2016-03-16 19:22 +0000
        Re: PHP 7 upgrade "ciccio" <21669invalid@mynewsgate.net> - 2016-03-15 18:13 +0000
          Re: PHP 7 upgrade Alessandro Pellizzari <shuriken@amiran.it> - 2016-03-16 10:25 +0000
            Re: PHP 7 upgrade "ciccio" <21669invalid@mynewsgate.net> - 2016-03-16 11:30 +0000
              Re: PHP 7 upgrade Alessandro Pellizzari <shuriken@amiran.it> - 2016-03-16 17:10 +0000
                Re: PHP 7 upgrade "ciccio" <21669invalid@mynewsgate.net> - 2016-03-16 19:32 +0000
                  Re: PHP 7 upgrade Alessandro Pellizzari <shuriken@amiran.it> - 2016-03-17 10:18 +0000

#20492 — PHP 7 upgrade

Ho un hosting condiviso, di quelli da 50 euro all'anno e hanno PHP 5
montato. In questo caso come sarà possibile testare i miei script .php
con la nuova versione PHP 7 mantenendo il sito funzionante sotto PHP 5?

Sarà possibile mettere una direttiva in php.ini per fare lo switch tra i
due PHP e testare i nuovi script?
-- 
Sandro kensan www.kensan.it & www.qiqi.it geek site
Saluto gli agenti della NSA - Hello NSA - www.nsa.gov

[toc] | [next] | [standalone]

#20493

Il Sun, 13 Mar 2016 17:30:51 +0100, Sandro kensan ha scritto:

> Ho un hosting condiviso, di quelli da 50 euro all'anno e hanno PHP 5
> montato. In questo caso come sarà possibile testare i miei script .php
> con la nuova versione PHP 7 mantenendo il sito funzionante sotto PHP 5?
> 
> Sarà possibile mettere una direttiva in php.ini per fare lo switch tra i
> due PHP e testare i nuovi script?

No.

Puoi usare Vagrant o Puphpet per crearti una virtualmachine in cui 
installare esattamente la stessa versione che hai sull'hosting.

Se usi PHPStorm puoi forzarlo a usare una certa versione di PHP, in modo 
che ti segnali come errore se usi caratteristiche introdotte nelle versioni 
successive.

A parte questo, a meno che non usi caratteristiche del 7 apposta, ci sono 
forse meno incompatibilità tra PHP 5.6 e PHP 7 che tra la 5.2 e la 5.4. :)

Bye.

[toc] | [prev] | [next] | [standalone]

#20494

On 13/03/2016 18:07, Alessandro Pellizzari wrote:

> A parte questo, a meno che non usi caratteristiche del 7 apposta, ci sono 
> forse meno incompatibilità tra PHP 5.6 e PHP 7 che tra la 5.2 e la 5.4. :)
> 
> Bye.

Posso approfittarne? Non usando le classi e usando solo il PDO per
accedere al database, c'è dell'altro che potrei fare per avere uno
switch indolore? O comunque con pochi bug?
-- 
Sandro kensan www.kensan.it & www.qiqi.it geek site
Saluto gli agenti della NSA - Hello NSA - www.nsa.gov

[toc] | [prev] | [next] | [standalone]

#20495

Il Sun, 13 Mar 2016 20:08:30 +0100, Sandro kensan ha scritto:

> Posso approfittarne? Non usando le classi e usando solo il PDO per
> accedere al database, c'è dell'altro che potrei fare per avere uno
> switch indolore? O comunque con pochi bug?

Anche usando le classi, la compatibilità è quasi totale.

Qui trovi le incompatibilità tra la 5.6 e la 7:

http://php.net/manual/en/migration70.incompatible.php

Come vedi, a meno di aver usato edge-cases, roba deprecata da parecchio o 
hack, la compatibilità è altissima.

Bye.

[toc] | [prev] | [next] | [standalone]

#20496

On 13/03/2016 18:07, Alessandro Pellizzari wrote:
> Il Sun, 13 Mar 2016 17:30:51 +0100, Sandro kensan ha scritto:
>> sarà possibile mettere una direttiva in php.ini per fare lo switch tra i
>> due PHP e testare i nuovi script?
> 
> No.
> 
> Puoi usare Vagrant o Puphpet per crearti una virtualmachine in cui 
> installare esattamente la stessa versione che hai sull'hosting.
> 
> Se usi PHPStorm puoi forzarlo a usare una certa versione di PHP, in modo 
> che ti segnali come errore se usi caratteristiche introdotte nelle versioni 
> successive.

Questo mi ha detto il servizio tecnico:

> Gentile Cliente,
>
> i server non vengono mai aggiornati per impedire di rompere i siti web
> attuali.
> Verranno creati nuovi server che supporteranno le tecnologie più
> recenti
> (tra cui PHP7).
> Ipotizziamo il lancio di PHP7 verso maggio.
>
> Quando lo vorrà potrà migrare gratuitamente su un server più
> aggiornato.

-- 
Sandro kensan www.kensan.it & www.qiqi.it geek site
Saluto gli agenti della NSA - Hello NSA - www.nsa.gov

[toc] | [prev] | [next] | [standalone]

#20500

Sandro kensan <kensan@kensan.it> ha scritto:

> On 13/03/2016 18:07, Alessandro Pellizzari wrote:
> > Il Sun, 13 Mar 2016 17:30:51 +0100, Sandro kensan ha scritto:
> >> sarà possibile mettere una direttiva in php.ini per fare lo switch tra i
> >> due PHP e testare i nuovi script?
> > 
> > No.
> > 
> > Puoi usare Vagrant o Puphpet per crearti una virtualmachine in cui 
> > installare esattamente la stessa versione che hai sull'hosting.
> > 
> > Se usi PHPStorm puoi forzarlo a usare una certa versione di PHP, in modo 
> > che ti segnali come errore se usi caratteristiche introdotte nelle versioni 
> > successive.
> 
> Questo mi ha detto il servizio tecnico:
> 
> > Gentile Cliente,
> >
> > i server non vengono mai aggiornati per impedire di rompere i siti web
> > attuali.
> > Verranno creati nuovi server che supporteranno le tecnologie più
> > recenti
> > (tra cui PHP7).
> > Ipotizziamo il lancio di PHP7 verso maggio.
> >
> > Quando lo vorrà potrà migrare gratuitamente su un server più
> > aggiornato.
> 

E beh meglio di così che ti possono dare... ;-)

Hai pure il tempo di fare tranquillante quanti test vuoi sui
tuoi script in locale, prima del prossimo upgrade del server ;-)

[toc] | [prev] | [next] | [standalone]

#20512

On Monday, March 14, 2016 at 10:21:19 AM UTC-4, Sandro kensan wrote:
> Questo mi ha detto il servizio tecnico:
> 
> > Gentile Cliente,
> >
> > i server non vengono mai aggiornati per impedire di rompere i siti web
> > attuali.
> > Verranno creati nuovi server che supporteranno le tecnologie più
> > recenti
> > (tra cui PHP7).
> > Ipotizziamo il lancio di PHP7 verso maggio.
> >
> > Quando lo vorrà potrà migrare gratuitamente su un server più
> > aggiornato.
> 

Mi sembra giusto :)

Del resto, così funziona ovunque.. se hai un applicativo PHP5 chiedi una
macchina con PHP5, se ti serve la 7, chiedi una macchina con la 7.
No? :)

Ciao!

[toc] | [prev] | [next] | [standalone]

#20499

Sandro kensan <kensan@kensan.it> ha scritto:

> Ho un hosting condiviso, di quelli da 50 euro all'anno e hanno PHP 5
> montato. In questo caso come sarà possibile testare i miei script .php
> con la nuova versione PHP 7 mantenendo il sito funzionante sotto PHP 5?

Ma perché non testi i tuoi script in locale sulla tua macchina
con PHP 7 installato, prima di un eventuale upload sul server?
E' una pratica fattibile e sempre consigliabile.

[toc] | [prev] | [next] | [standalone]

#20503

On 15/03/2016 12:08, ciccio wrote:

> Ma perché non testi i tuoi script in locale sulla tua macchina
> con PHP 7 installato, prima di un eventuale upload sul server?
> E' una pratica fattibile e sempre consigliabile.

Io sono un neofita della programmazione in php ma ho visto che non è la
stessa cosa eseguire dal server oppure fare un $ php script.php

immagino che io sia un po' troppo inesperto per queste cose.
-- 
Sandro kensan www.kensan.it & www.qiqi.it geek site
Saluto gli agenti della NSA - Hello NSA - www.nsa.gov

[toc] | [prev] | [next] | [standalone]

#20505

> Io sono un neofita della programmazione in php ma ho visto che non è la
> stessa cosa eseguire dal server oppure fare un $ php script.php
> 
> immagino che io sia un po' troppo inesperto per queste cose.


Ti stanno consigliando di creare una macchina virtuale con un server web sul tuo computer in locale in modo da testare il preciso comportamento che avrebbe il sito una volta installato sul nuovo server.

Quindi devi imparare a gestire un virtualizzatore, imparare a installare e configurare Apache2 + PHP7 + MySQL o la tua configurazione specifica, capire come spostare i documenti e il db. A quel punto hai un server web e potrai procedere con il debug del programma in locale.

Secondo me la via migliore e già stata indicata è l'utilizzo di virtualbox(https://www.virtualbox.org) +Vagrant (https://www.vagrantup.com).

Vagrant ha già delle box (macchine virtuali) "prefabbricate", ovvero dei server già installati che vagrant si può scaricare autonomamente e che ti risparmiano una parte di lavoro da sistemista.

Riassumendo: studiati approfonditamente Vagrant e hai risolto la parte sistemistica.

Se poi ti sentissi ispirato potresti imparare Git, non tanto come sistema di workgroup, ma come sistema organizzato di backup, perché durante il debug è facile causare arrosti indicibili e con git tieni traccia delle modifiche e puoi recuperare il singolo o tutti file ad un determinato stato.

[toc] | [prev] | [next] | [standalone]

#20507

fmigliori <fmigliori@gmail.com> ha scritto:

> 
> > Io sono un neofita della programmazione in php ma ho visto che non è la
> > stessa cosa eseguire dal server oppure fare un $ php script.php
> > 
> > immagino che io sia un po' troppo inesperto per queste cose.
> 
> 
> Ti stanno consigliando di creare una macchina virtuale con un server web sul
tuo computer in locale in modo da testare il preciso comportamento che avrebbe
il sito una volta installato sul nuovo server.
> 
> Quindi devi imparare a gestire un virtualizzatore, imparare a installare e
configurare Apache2 + PHP7 + MySQL o la tua configurazione specifica, capire
come spostare i documenti e il db. A quel punto hai un server web e potrai
procedere con il debug del programma in locale.
> 
> Secondo me la via migliore e già stata indicata è l'utilizzo di
virtualbox(https://www.virtualbox.org) +Vagrant (https://www.vagrantup.com).
> 
> Vagrant ha già delle box (macchine virtuali) "prefabbricate", ovvero dei
server già installati che vagrant si può scaricare autonomamente e che ti
risparmiano una parte di lavoro da sistemista.
> 
> Riassumendo: studiati approfonditamente Vagrant e hai risolto la parte
sistemistica.
> 
> Se poi ti sentissi ispirato potresti imparare Git, non tanto come sistema di
workgroup, ma come sistema organizzato di backup, perché durante il debug è
facile causare arrosti indicibili e con git tieni traccia delle modifiche e
puoi recuperare il singolo o tutti file ad un determinato stato.
> 

Beh io senza scomodare l'allestimento di una macchina virtuale,
mi scaricherei la versione di XAMPP con PHP 5.6 e l'ultima versione
con PHP 7 e userei entrambe per fare i test in locale. Penso che per
l'OP sia più semplice ed immediato.

[toc] | [prev] | [next] | [standalone]

#20518

On 15/03/2016 19:09, ciccio wrote:

> Beh io senza scomodare l'allestimento di una macchina virtuale,
> mi scaricherei la versione di XAMPP con PHP 5.6 e l'ultima versione
> con PHP 7 e userei entrambe per fare i test in locale. Penso che per
> l'OP sia più semplice ed immediato.

Grazie per le indicazioni ma io penso di fare la cosa più semplice
ovvero approntare in modo teorico il mio sito in modo che funzioni su
PHP7 e intanto farlo girare su PHP5. Per esempio togliere tutte le
chiamate a mysql fatto non tramite PDO e informarmi se c'è dell'altro
che riguarda i miei script e poi fare lo switch e lavorare un po' di ore
col sito off line fino a quando non riesco a metterlo a posto.

Poi magari cercare qualche programma che mi segnali gli eventuali punti
critici dei miei script con php7, forse ne compariranno.

Grazie a tutti.
-- 
Sandro kensan www.kensan.it & www.qiqi.it geek site
Saluto gli agenti della NSA - Hello NSA - www.nsa.gov

[toc] | [prev] | [next] | [standalone]

#20520

Sandro kensan <kensan@kensan.it> ha scritto:

> On 15/03/2016 19:09, ciccio wrote:
> 
> > Beh io senza scomodare l'allestimento di una macchina virtuale,
> > mi scaricherei la versione di XAMPP con PHP 5.6 e l'ultima versione
> > con PHP 7 e userei entrambe per fare i test in locale. Penso che per
> > l'OP sia più semplice ed immediato.
> 
> Grazie per le indicazioni ma io penso di fare la cosa più semplice
> ovvero approntare in modo teorico il mio sito in modo che funzioni su
> PHP7 e intanto farlo girare su PHP5. Per esempio togliere tutte le
> chiamate a mysql fatto non tramite PDO e informarmi se c'è dell'altro
> che riguarda i miei script e poi fare lo switch e lavorare un po' di ore
> col sito off line fino a quando non riesco a metterlo a posto.

Beh è cmq un modo di procedere che richiede di fare delle prove
in locale (si eviterebbe anche di mettere il sito off line, poi quando
le modifiche sono completate, testate e funzionanti si fa l'upload,
con sito off line o no a seconda dei gusti e della velocità di tutto
il processo ;-) ). Stesso discorso con l'adozione di PDO, sempre e cmq
consigliabile.

> Poi magari cercare qualche programma che mi segnali gli eventuali punti
> critici dei miei script con php7, forse ne compariranno.

Mah, come ti è stato detto è già più che sufficiente guardarsi
il manuale ufficiale con le info di compatibilità dell'upgrade PHP
5.6 > 7

[toc] | [prev] | [next] | [standalone]

#20508

Sandro kensan <kensan@kensan.it> ha scritto:

> On 15/03/2016 12:08, ciccio wrote:
> 
> > Ma perché non testi i tuoi script in locale sulla tua macchina
> > con PHP 7 installato, prima di un eventuale upload sul server?
> > E' una pratica fattibile e sempre consigliabile.
> 
> Io sono un neofita della programmazione in php ma ho visto che non è la
> stessa cosa eseguire dal server oppure fare un $ php script.php

Stai usando sempre istruzioni in PHP sia che lo usi come linguaggio
di scripting lato server, e sia come linguaggio di scripting da terminale.
Differisce solo nella modalità di impiego e di elaborazione, al limite, ma
le istruzioni del linguaggio sempre quelle sono ;-)

> immagino che io sia un po' troppo inesperto per queste cose.

Non è un problema, PHP ha una curva di apprendimento non ripida ma
ben bilanciata.

[toc] | [prev] | [next] | [standalone]

#20516

On 15/03/2016 18:13, ciccio wrote:

> Sandro kensan <kensan@kensan.it> ha scritto:

>> Io sono un neofita della programmazione in php ma ho visto che non è la
>> stessa cosa eseguire dal server oppure fare un $ php script.php
>
> Stai usando sempre istruzioni in PHP sia che lo usi come linguaggio
> di scripting lato server, e sia come linguaggio di scripting da terminale.
> Differisce solo nella modalità di impiego e di elaborazione, al limite, ma
> le istruzioni del linguaggio sempre quelle sono ;-)

Ni.

Le istruzioni sono sempre quelle, ma parti fondamentali sono diverse.

Per esempio $_SERVER contiene valori completamente diversi.

E, in generale, il flusso di esecuzione sarà diversi tra un'applicazione 
CLI e una web, anche se certi framewok cercano di unificare il più 
possibile.

Bye.

[toc] | [prev] | [next] | [standalone]

#20517

Alessandro Pellizzari <shuriken@amiran.it> ha scritto:

> On 15/03/2016 18:13, ciccio wrote:
> 
> > Sandro kensan <kensan@kensan.it> ha scritto:
> 
> >> Io sono un neofita della programmazione in php ma ho visto che non è la
> >> stessa cosa eseguire dal server oppure fare un $ php script.php
> >
> > Stai usando sempre istruzioni in PHP sia che lo usi come linguaggio
> > di scripting lato server, e sia come linguaggio di scripting da terminale.
> > Differisce solo nella modalità di impiego e di elaborazione, al limite, ma
> > le istruzioni del linguaggio sempre quelle sono ;-)
> 
> Ni.
> 
> Le istruzioni sono sempre quelle, ma parti fondamentali sono diverse.
> 
> Per esempio $_SERVER contiene valori completamente diversi.

Ok, ma è anche auspicabile e logico aspettarselo, dato che la
chiamata la si fa da ambienti e situazioni diverse.

> E, in generale, il flusso di esecuzione sarà diversi tra un'applicazione 
> CLI e una web, anche se certi framewok cercano di unificare il più 
> possibile.

Certo ma le tantissimissime funzioni sono sempre lì pronte a fare
il loro dovere! Sia che si lavori sul server che da CLI. Per esempio,
via CLI una chiamata alla funzione "trim" ti restituisce la stessa
cosa che ti restituirebbe se la chiamata avviene sul server.

[toc] | [prev] | [next] | [standalone]

#20519

On 16/03/2016 11:30, ciccio wrote:

> Certo ma le tantissimissime funzioni sono sempre lì pronte a fare
> il loro dovere! Sia che si lavori sul server che da CLI. Per esempio,
> via CLI una chiamata alla funzione "trim" ti restituisce la stessa
> cosa che ti restituirebbe se la chiamata avviene sul server.

Sperabilmente la trim è dentro uno script che fa qualcosa.
Come chiami quello script è totalmente diverso tra CLI e Webserver.
Per esempio, se hai un controller che usa PRS7, la firma sarà

class MioController {
  public function indexAction(Request $req, Response $res) {
   ...
   trim(...);
   ...
  }
}

A quel punto non ti basta fare

php MioController.php

ma devi mockare la Request, creare una Response, istanziare la classe e 
richiamare la funzione.

Tutta roba che fai negli unit test, ma appunto non direttamente da CLI.

Bye.

[toc] | [prev] | [next] | [standalone]

#20521

Alessandro Pellizzari <shuriken@amiran.it> ha scritto:

> On 16/03/2016 11:30, ciccio wrote:
> 
> > Certo ma le tantissimissime funzioni sono sempre lì pronte a fare
> > il loro dovere! Sia che si lavori sul server che da CLI. Per esempio,
> > via CLI una chiamata alla funzione "trim" ti restituisce la stessa
> > cosa che ti restituirebbe se la chiamata avviene sul server.
> 
> Sperabilmente la trim è dentro uno script che fa qualcosa.

Beh, ovvio ;-)

> Come chiami quello script è totalmente diverso tra CLI e Webserver.
> Per esempio, se hai un controller che usa PRS7, la firma sarà
> 
> class MioController {
>   public function indexAction(Request $req, Response $res) {
>    ...
>    trim(...);
>    ...
>   }
> }
> 
> A quel punto non ti basta fare
> 
> php MioController.php
> 
> ma devi mockare la Request, creare una Response, istanziare la classe e 
> richiamare la funzione.
> 
> Tutta roba che fai negli unit test, ma appunto non direttamente da CLI.

Sicuramente, ma io intendevo semplici script batch con istruzioni
di manipolazione di stringhe. Stessi trattamenti che si possono fare
su di una stringa in una pagina web PHP lineare.

[toc] | [prev] | [next] | [standalone]

#20523

On 16/03/2016 19:32, ciccio wrote:

>> Tutta roba che fai negli unit test, ma appunto non direttamente da CLI.

> Sicuramente, ma io intendevo semplici script batch con istruzioni
> di manipolazione di stringhe. Stessi trattamenti che si possono fare
> su di una stringa in una pagina web PHP lineare.

Stavamo parlando di testare script web, non script CLI, con la nuova 
versione di PHP 7.

Bye.

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web