Tag: php

Immaginiamo di avere un server Windows con dominio chiamato torregatti.local. Possiamo effettuare l’autenticazione tramite PHP utilizzando il metodo LDAP (Lightweight Directory Access Protocol).

Anzitutto assicuriamoci di avere attiva la libreria LDAP all’interno del PHP.

Su Linux possiamo installare la libreria, per esempio con Ubuntu digitiamo:

Mentre su Windows, per esempio usando XAMPP, sarà sufficiente attivare l’estensione nel file php.ini, rimuovendo il commento alla seguente riga:

Che diventerà quindi:

Fatto questo possiamo creare una classe che si occupi del processo di login.

Prima di procedere vediamo il minimo indispensabile per effettuare il processo:

In questo caso stiamo entrando con l’utente amministratore TORREGATTI\ADMINISTRATOR che ha per password Password123

Ricordiamoci che nel nostro esempio il dominio è torregatti.local e il server si trova sull’indirizzo 192.168.56.1. Ci stiamo collegando con una connessione non sicura, usando il protocollo ldap anziché ldaps (richiederebbe la porta 636).

Possiamo creare una classe che effettui tutto il processo di login e ci permetta di verificare l’autenticazione mediante i cookie, nella maniera seguente:

Per effettuare il login sarà sufficiente configurare la classe nella maniera seguente:

Abbiamo aggiunto una nostra chiave casuale e segreta che verrà utilizzata per la costruzione del hash nei cookie.

Per verificare che l’utente sia autenticato, una volta terminato il processo di login, sarà sufficiente richiamare:

Per effettuare il logout sarà sufficiente richiamare:

E’ molto probabile che l’inserimento di username e password lo si voglia fare dopo aver costruito l’oggetto per l’autenticazione LDAP, in tal caso si potrebbe procedere nella maniera seguente:

Con il metodo getError() è possibile verificare gli altri eventuali errori durante il processo di autenticazione, sfruttando le costanti della classe.

Problema: dopo un cambio di database (senza alcuna modifica al dominio) in Prestashop non vengono più visualizzati i prodotti nelle singole categorie e accedendo al pannello di controllo si presenta un errore del tipo Expression #11 of SELECT list is not in GROUP BY clause and contains nonaggregated column [...] which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

Soluzione: Modificare l’opzione sql_mode in sql_mode='STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION'

Nel caso specifico sarebbe sufficiente modificare la variabile globale sql_mode eseguendo la query:

Purtroppo questa modifica, che sarebbe quella ottimale e definitiva, non è sempre possibile da attuare a causa dei permessi sul database. Nel caso in cui non la si possa mettere in pratica sarà sufficiente modificare il file classes/db/DbPDO.php nella maniera seguente.

Aprendo il file alla riga 63 si troverà la seguente funzione:

Modificare la funzione nella maniera seguente, aggiungendo prima di return il pezzo di codice evidenziato:

Questa soluzione è stata presa da questo commento nel forum ufficiale.

Obiettivo: leggere tutti i prodotti del negozio su Magento 2 e eliminare tutte le immagini duplicate per ciascun prodotto.

In Magento 2 può capitare di ritrovarsi prodotti con immagini duplicate, specialmente a seguito di una importazione di dati. Inoltre sembra che ci siano anche dei bug, o almeno ci sono stati nelle diverse versioni, che producevano questo fastidioso problema.

Quello che vogliamo fare è creare una pagina correggi_immagini.php, nella root del sito, richiamando la quale percorreremo tutti i prodotti in cerca di immagini duplicate e le elimineremo.

Come piccolo accorgimento voglio che lo script sia eseguito solo a seguito di una specifica chiamata GET sulla pagina, per esempio /correggi_immagini.php?auth=1234567890abcdefghilmnopqrstuv

Al posto di 1234567890abcdefghilmnopqrstuv raccomando di sostituire un codice sufficientemente complesso.

Nei commenti ho inserito i dettagli sullo sviluppo dello script:

Aggiungendo un filtro a functions.php del tema attivo o in qualunque plugin attivo, possiamo escludere alcuni metodi di spedizione in base alla class di spedizione del prodotto.

Immaginiamo di aver aggiunto, tra i metodi di spedizione, qualcosa di simile (nel mio caso Corriere BRT):

E contestualmente abbiamo creato una classe di spedizione chiamata sempre Corriere BRT nel modo seguente:

A questo punto vogliamo che solo i prodotti con la suddetta classe abbiano a disposizione il suddetto metodo di spedizione, che venga invece escluso per quelli senza una classe.

Procuriamoci anzitutto l’ID della classe e quello della spedizione. Utilizzando Chrome, nel mio esempio, clicchiamo col destro sulla classe di spedizione e scegliamo Ispeziona.

Nella finestra di ispezione individuiamo il codice della classe nel modo seguente:

Nel mio caso il valore da salvare è 17834.

Adesso individuiamo l’ID del metodo di spedizione. Lo possiamo recuperare dal carrello sempre utilizzando Ispeziona su Chrome. Andiamo nel carrello dove abbiamo un prodotto con il metodo di spedizione desiderato:

Clicchiamo su Ispeziona ed individuiamo il seguente pezzo di codice:

Nel mio caso il codice è flat_rate:7

Raccolte tutte queste informazioni andiamo a modificare il file functions.php aggiungendo il filtro.

Modifichiamo opportunamente i due codici che ci interessano.

Fatto questo ci accorgeremo come il hook woocommerce_package_rates non viene chiamato sempre, ma solamente al momento in cui si aggiorna la quantità di prodotti nel carrello. Affinché la cosa funzioni correttamente dobbiamo chiamarlo sempre.

Per farlo andiamo su WooCommerce > Impostazioni > Spedizione > Opzioni di spedizione e qui spuntiamo la voce Abilita la modalità di debug

Se abbiamo fatto tutto correttamente adesso il metodo di spedizione è disponibile solo per la classe scelta.

Sia YoastSEO che JetPack permettono di generare automaticamente delle sitemap per i contenuti del sito.

Potrebbe essere però necessario escludere alcune pagine dalla sitemap. Per esempio le pagine del carrello, del checkout e dell’account, generate da WooCommerce, comprendono il tag noindex, che le esclude dall’indicizzazione di Google per ovvie ragioni (principalmente pratiche, inutile indicizzare contenuti accessibili solo per motivi funzionali o per alcuni utenti).

In entrambi i casi, la presenza di tali pagine nella sitemap, provoca degli errori sulla Google Search Console (vengono proposti link per l’indicizzazione, che poi non possono essere indicizzati per via del tag noindex). Per risolvere simili problemi è sufficiente rimuovere le pagine coinvolte dalla sitemap.

In entrambi i casi è possibile farlo programmaticamente (per YoastSEO anche intervenendo nelle opzioni di ciascuna pagina) aggiungendo un’opportuno filtro nel file functions.php del tema (o dove si preferisce).

Per JetPack sarà sufficiente aggiungere il seguente codice:

In questo caso verranno escluse le pagine con ID 102, 103 e 104. Per trovare l’ID di un contenuto, in generale, è sufficiente controllare l’indirizzo al momento della modifica. Modificando un articolo si avrà un indirizzo del tipo post.php?post=102&action=edit

Il 102 è l’ID del contenuto.

In maniera analoga per YoastSEO è sufficiente aggiungere il seguente codice:

In entrambi i casi i contenuti con l’ID coinvolto non verranno più inseriti nella sitemap.

Riallacciandomi al precedente articolo ([php] Configurare php.ini per l’upload dei file) voglio approfondire il problema del caricamento di file di grosse dimensioni su server che utilizzano PHP, Apache e nginx (nel mio caso specifico anche Plesk).

Gli errori che possono sorgere sono difatti innumerevoli e spesso apparentemente senza senso.

Cominciamo riepilogando il necessario per quello che riguarda il PHP. Come spiegato nel precedente articolo, assicuriamoci di avere una configurazione simile alla seguente nel file php.ini

In questo caso sto supponendo che caricheremo file fino a 512MB.

Per quanto riguarda il PHP ci dobbiamo assicurare che la quantità di memorie allocabile sia compatibile con la dimensione dei file da caricare e che lo sia anche il tempo di esecuzione.

Con un tempo di 1200 secondi si suppone che l’upload avverrà ad un minimo di 0,43MB/s. Questo significa che parte del caricamento dipende anche dalla velocità di upload del client, che potrebbe non essere sufficientemente alta da permettere al server di terminare l’operazione nei tempi consentiti.

Per inciso ricordiamoci che le classiche connessioni ADSL 20 Mega hanno upload che si aggirano attorno a 1 Mbit, ovvero 0,12 MB/s. Questo significa che il tempo di esecuzione dovrebbe essere per lo meno di 4.300 secondi (approssimando per eccesso).

Detto tutto questo si potrebbe incorrere in altri problemi, come ad esempio, lato client: Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR

Se si sta tentando di gestire l’upload tramite javascript e si incorre in questo errore, esso nulla ha a che fare con il protocollo HTTP/2 (e tanto meno è utile tornare al HTTP/1.1 o simili), ma è legato al fatto che la pagina non invia una risposta corretta. La risposta non viene inviata correttamente perché ad interrompere l’upload possono essere Apache oppure nginx.

Controllando il log del server si potrebbe trovare infatti un errore simile al seguente: 19855#0: *532 client intended to send too large body: 180584796 bytes

In questo caso sto cercando di caricare circa 172MB di file ed nginix blocca l’operazione.

Nel mio caso specifico posso verificare la cosa, confrontando su Windows la dimensione dei file che sto tentando di inviare al server con un unico upload.

Si può notare come la dimensione bloccata sia leggermente più grande dei file in upload, perché, come già discusso nel precedente articolo, il corpo che viene inviato al server contiene anche informazioni aggiuntive che vanno al di là dei singoli file che si stanno caricando.

A questo punto dobbiamo intervenire su nginx aggiungendo l’istruzione:

La configurazione predefinite di nginx sarebbe di 1m, mentre sotto Plesk è di 128m.

Questo parametro può essere modificato all’interno del file /etc/nginx/nginx.conf

Per farlo su Plesk procediamo nel modo seguente (è anche spiegato nella vademecum ufficiale, anche se ci sono delle piccole incongruenze):

1. Colleghiamoci via SSH al Server con Plesk
2. Creiamo un file di configurazione aggiuntivo a cui aggiungeremo l’istruzione precedente: echo 'client_max_body_size 128m;' > /etc/nginx/conf.d/aa_client_max_body.conf
3. Verifichiamo se esiste il file /usr/local/psa/admin/conf/panel.ini
4. Se non dovesse esistere creiamolo copiandolo dal file predefinito: cp /usr/local/psa/admin/conf/panel.ini.sample /usr/local/psa/admin/conf/panel.ini
5. Aggiungiamo l’impostazione per la massima dimensione del corpo: echo -e "[webserver]\n nginxClientMaxBodySize = 512m\n" >> /usr/local/psa/admin/conf/panel.ini
6. Modifichiamo i permessi: chmod 644 /usr/local/psa/admin/conf/panel.ini
7. Riconfiguriamo il tutto: plesk sbin httpdmng --reconfigure-all
8. Riavviamo nginx: service nginx restart
9. Assicuriamoci che su tutti i webserver sia configurato il parametro giusto: nginx -T | grep client_max_body_size
10. Nel caso non lo fosse possiamo usare l’istruzione, per riconfigurare il tutto: plesk repair web -y -v

In generale dovremmo assicurarci che, rispetto ai parametri suddetti, nelle configurazioni di nginx, sotto la voce server, compaiano i seguenti due valori:

Questi valori dovrebbero essere in linea (o superiori) con quelli scelti per il PHP.

Infine dobbiamo verificare che anche Apache consenta l’esecuzione dell’upload. Nel caso specifico potrebbero esserci due parametri ad influenzarlo: FcgidMaxRequestLen  e LimitRequestBody

Impostiamoli nel modo seguente:

Se abbiamo configurato tutto correttamente dovremmo essere in grado di caricare i file come definito all’inizio.

L’upload dei file, nel PHP, dipende da diverse parametri, alcuni diretti ed altri indiretti, configurabili nel php.ini.

Anzitutto individuiamo il file di configurazione in uso. Per farlo è sufficiente utilizzare, in una pagina php, l’istruzione phpinfo();

Otterremo un output simile a questo:

Nel mio caso specifico, sotto Plesk, il file si trova in /opt/plesk/php/7.3/etc/php.ini

In una configurazione predefinita di Ubuntu Server 19.10 avremmo qualcosa di simile invece:

Il percorso del file php.ini in questo caso è /etc/php/7.3/apache2/php.ini

Detto questo modifichiamo il suddetto file individuando le seguenti istruzioni:

upload_max_filesize

Questo è il parametro principale, quello che riguarda la massima dimensione di un file in upload. Di solito si trova impostato a 2M oppure 8M. Se volessimo consentire un upload di 20MB dovremmo metterlo a: upload_max_filesize = 20M

post_max_size

Questo parametro indica la massima dimensione dell’intestazione di POST, nel caso specifico se volessimo aumentare il valore a 20MB dovremmo digitare: post_max_size = 20M

Attenzione, perché il POST contiene non solo il file in upload, ma anche altre istruzioni. Con una dimensione di 20MB significa che il massimo file caricabile sarà probabilmente attorno ai 19MB, perché una parte del post è utilizzata per inviare anche altre istruzioni, per quanto in genere ridotte e piccole. Un’istruzione più corretta potrebbe essere: post_max_size = 21M

max_file_uploads

Questo parametro definisce invece il numero massimo di file caricabili. Di predefinito è impostato su 20, quindi si potranno caricare al massimo 20 file in una volta. Se volessimo consentire il caricamento simultaneo di 50 file, potremmo impostarlo come: max_file_uploads = 50

A queste, che sono le istruzioni specificatamente dedicate al caricamento dei file, se ne aggiungono altre che sono strettamente connesse.

memory_limit

Il limite di memoria allocabile dal processo di PHP per l’esecuzione delle operazioni. Nel caso di grossi caricamenti questo limite potrebbe dover essere aumentato. Di solito il valore è 128M, ovvero 128MB, se volessimo aumentare il valore a 256MB dovremmo scrivere: memory_limit = 256MB

max_execution_time

Il massimo tempo di esecuzione del processo PHP. Di predefinito è impostato su 30 secondi, il che vuol dire che se l’upload impiega più tempo il PHP chiuderà l’operazione allo scadere del limite del tempo. Possiamo aumentare questo valore, per esempio su 10 minuti (60 secondi x 10), digitando: max_execution_time = 600

max_input_time

Come prima, anche questo parametro concorre col precedente. Se il tempo massimo di esecuzione è inferiore a questo parametro il processo di input verrà comunque interrotto; viceversa se questo valore è basso l’input verrà interrotto secondo quest’ultimo parametro. Se vogliamo dare anche qui 10 minuti per il massimo tempo di input digitiamo: max_input_time = 600

Riassumiamo infine tutte quante le variabili assieme:

Oggi propongo un semplice esercizio in PHP dove vogliamo costruire un oggetto iterabile che sia accessibile come un vettore e percorribile da foreach.

Immaginiamo di avere due classi Studente e Scuola, quello che vogliamo ottenere è il qualcosa di analogo a questo:

L’output sarà così:

in tutto ci sono 4 studenti
0 -> Squall
1 -> Zell
2 -> Rinoa
3 -> Edea

Anzitutto cominciamo costruendo la classe Studente. Questa è molto semplice e non ha nulla di particolare, la possiamo costruire come vogliamo ed in particolare, ai fini dell’esercizio, la farò con una sola proprietà e due metodi (set e get).

Adesso costruiamo Scuola implementando i metodi Iterator, ArrayAccess, Countable.

Le tre interfacce permettono di implementare diverse proprietà. Affinché l’oggetto costruito con Scuola sia percorribile dal foreach usiamo l’interfaccia Iterator.

L’interfaccia implementa i seguenti metodi astratti:

Si suppone che la nostra classe abbia una proprietà “posizione“, per cui si possa ricavare un valore da questa posizione corrente con current(). Il metodo key() dovrà restituire tale posizione corrente, next() permetterà di andare alla posizione successiva, mentre rewind() consentirà di ripartire dalla posizione iniziale. Infine il metodo valid() verificherà se nella posizione attuale esiste o meno un oggetto.

Cominciamo allora costruendo la classe nel modo seguente:

Per rendere la classe operativa aggiungiamo anche un altro paio di metodi. In particolare:

Con il controllo if( $studente instanceof Studente ) vogliamo assicurarci che l’oggetto aggiunto tramite il metodo add() sia del tipo Studente. Se il tipo non è quello giusto solleviamo un errore del tipo InvalidArgumentException dove avvisiamo l’utente.

Significa che la forma:

Produrrà un errore del tipo Fatal error: Uncaught InvalidArgumentException: l'oggetto deve essere di tipo Studente in iterator.php:92 Stack trace: #0 iterator.php(87): Scuola->erroreOggettoNonValido() #1 iterator.php(98): Scuola->add('Squall') #2 {main} thrown in iterator.php on line 92

L’operazione valida sarà invece:

A questo punto l’oggetto è già iterabile mediante foreach, che può essere chiamato nel modo seguente:

Vogliamo dare la possibilità di aggiungere gli oggetti anche alla maniera di $scuola[] = new Studente("Edea");

Per farlo implementiamo la nostra classe Scuola anche su ArrayAccess. L’interfaccia ArrayAccess richiede i seguenti metodi:

Quindi implementiamoli nella nostra classe Scuola alla maniera seguente: