[owncloud] Installare ownCloud su Ubuntu Server 20.04.1, configurazione VirtualHost, certificato HTTPS e disco dati con LVM

Vediamo come installare ownCloud su un Ubuntu Server 20.04.1. In aggiunta configureremo anche un VirtualHost con un certificato autofirmato, aggiungendo infine un disco in LVM che ospiti i dati di ownCloud.

1. Configurazione server LAMP

Anzitutto configuriamo il server LAMP installando Apache, MariaDB e il PHP 7.4.

Eseguiamo il seguente comando:

A questo punto configuriamo il database eseguendo:

ATTENZIONE! Se si esegue il commando senza sudo verrà chiesta la password dell’utente root e non ci sarà modo di cambiarla, generando l’errore: ERROR 1698 (28000): Access denied for user 'root'@'localhost'

Digitare in sequenza, per le singole domande:

Change the root password? [Y/n] Y

Remove anonymous users? [Y/n] Y

Disallow root login remotely? [Y/n] Y

Remove test database and access to it? [Y/n] Y

Reload privilege tables now? [Y/n] Y

Una volta completata la configurazione di MariaDB il server LAMP e pronto è possiamo procedere con le specifiche configurazioni.

2. Creiamo il certificato di crittografia

Se non lo abbiamo già fatto installiamo openssl. Questo ci servirà per creare un certificato autofirmato, nel caso in cui si disponga già del certificato si può passare al punto successivo.

Creiamo la chiave privata e il certificato:

Nel caso specifico stiamo dicendo ad openssl:

  • req sottocomando col quale specifichiamo che vogliamo usare l’X.509 CSR (certificate signing request), un’infrastruttura standard per le chiavi pubbliche utilizzata tipicamente con SSL e TSL
  • nodes indica ad OpenSSL di non cifrare il certificato con una password, dal momento che verrà utilizzato su Apache che deve potervi accedere liberamente
  • days specifica la durata di validità del certificato, nel nostro caso 365 giorni
  • newkey specifica il tipo di chiave privata (RSA 2048) che si vuole generare e il fatto che la si voglia generare assieme al certificato
  • keyout indica la posizione dove creare la chiave
  • out indica la posizione dove creare il certificato

Rispondiamo ai quesiti posti da OpenSSL per la configurazione del certificato. Nel mio caso procederò così:

Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Firenze
Locality Name (eg, city) []:Firenze
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Torregatti Spa
Organizational Unit Name (eg, section) []:Servizi Cloud
Common Name (e.g. server FQDN or YOUR name) []:cloud.local
Email Address []:scrivi@petarkaran.it

I valori sono per lo più arbitrari, l’unica cosa importante è il Common Name, che può essere l’indirizzo IP del server, oppure il dominio a cui sarà associato il certificato.

Configuriamo Apache affinché utilizzi correttamente i certificati SSL:

Nel file digitiamo:

Affinché la configurazione funzioni dobbiamo attivare il modulo SSL e il modulo Headers in Apache.

A questo punto attiviamo la configurazione digitando:

Affinché la configurazione sia corretta bisogna riavviare Apache, anche se non è necessario farlo adesso, lo possiamo fare anche dopo.

3. Configuriamo il VirtualHost

A questo punto configuriamo il nostro VirtualHost, immaginiamo che il nostro ownCloud debba trovarsi all’indirizzo cloud.local. (nel caso specifico da http://cloud.local e https://cloud.local)

Creiamo anzitutto due cartelle in /var/www, una per i file, una per i dati ed una per i log, entrambe sottocartelle di cloud.local, nella maniera seguente.

Grazie all’argomento -p creiamo l’intero percorso anche se non esiste.

A questo punto procediamo con la creazione del file del VirtualHost vero e proprio.

Nel file inseriamo le seguenti istruzioni.

In questo modo forziamo il redirect sul HTTPS e abilitiamo il certificato creato in precedenza.

A questo punto riavviamo apache:

4. Creazione partizione per i dati con LVM

Aggiungiamo al nostro server un disco aggiuntivo a creiamo un nuovo disco logico con LVM. Per ulteriori approfondimenti sulla procedura rimando all’articolo LVM, gestore logico dei volumi su Ubuntu [per pinguini alle prime armi]

Anzitutto vediamo i dischi dei quali disponiamo con:

Nel mio caso (sto utilizzando VirtualBox per l’esempio con 2 dischi da 10GB ciascuno):

Il disco che utilizzerò è /dev/sdb. Procediamo quindi a preparare il disco:

Su fdisk digitiamo in ordine:

  1. n per creare una nuova partizione
  2. p per una partizione primaria
  3. 1 numero di partizione
  4. INVIO per confermare il primo settore di default 2048
  5. INVIO per confermare l’ultimo settore
  6. t per modificare la partizione
  7. 8e per impostare Linux LVM
  8. w per scrivere e salvare il tutto

Utilizzando sudo fdisk -l dovremmo vedere qualcosa di simile:

Creiamo un volume fisico digitando:

Creiamo un gruppo di volumi chiamato dati-cloud digitando:

Creiamo sopra il volume logico dati:

Formattiamo il volume in ext4.

A questo punto montiamo il nuovo volume logico sulla cartella /var/www/cloud.local/dati

Siccome vogliamo che il disco sia montato in modo permanente, modifichiamo /etc/fstab.

In fondo al file aggiungiamo la seguente riga:

In questo modo al riavvio del server il volume logico verrà caricato automaticamente.

5. Creiamo un database per ownCloud

ownCloud necessita di un database per funzionare, pertanto creiamone uno nuovo all’interno di MariaDB.

Entriamo in MariaDB/MySQL:

Una volta dentro creiamo un nuovo database chiamato cloud_db:

Creiamo anche un utente per il database appena creato, che potrà accedere esclusivamente da locale (agli scopi dell’esercizio metterò una password banale):

6. Installazione ownCloud

Scarichiamo ownCloud nella cartella httpdocs. Da qui possiamo scegliere da dove scaricarlo.

Se non abbiamo installato unzip facciamolo:

A questo punto estraiamo il file zip.

Spostiamo i file dalla cartella owncloud creata dall’unzip, nella radice del virtualhost.

In questo modo rimuoviamo anche la cartella aggiuntiva ed il file zip.

Assegniamo adesso l’utente apache a tutta la cartella ed i file creati.

Infine abilitiamo la configurazione e riavviamo apache:

Se tutto è andato bene potremo aprire ownCloud all’indirizzo https://cloud.local/

Inseriamo i parametri nella maniera seguente (utilizzando quelli creati):

  1. Scegliamo un utente ed una password
  2. Per la cartella dati impostiamo la cartella creata all’inizio
  3. Inseriamo i dati del database configurati in precedenza:

Una volta fatto tutto possiamo premere su TERMINA CONFIGURAZIONE.

Se tutto è andato bene vedremo una schermata come la seguente:

Fatto tutto questo possiamo accedere al sistema. Spostandoci su Impostazioni > Generali, potremmo notare delle notifiche come le seguenti:

Apportiamo quindi ancora un paio di modifiche per aggiustare il tutto correttamente.

Anzitutto configuriamo correttamente il crontab affinché esegua gli script di ownCloud.

Digitiamo:

Se è la prima volta che lo apriamo ci chiederà quale editor preferiamo utilizzare, io scelgo 1 per nano.

Aggiungiamo la seguente riga:

Salviamo con CTRL+O e usciamo.

Nelle suddette impostazioni di ownCloud selezioniamo come meccanismo di aggiornamento Cron.

Spostiamoci nella nostra cartella di installazione con:

Eseguiamo i seguenti comandi:

L’utilizzo di sudo -u www-data è necessario perché l’esecuzione deve essere effettuata da Apache. Eseguendolo senza sudo lo faremmo usando il nostro utente, con sudo come root. In entrambi i casi non andrebbe bene.

Per risolvere l’avviso di HTTP "Strict-Transport-Security" dobbiamo aggiungere a <VirtualHost *:443> le seguenti tre righe:

Il file definitivo del virtualhost sarà come il seguente:

Riavviamo ancora una volta apache.

A questo punto è tutto pronto e possiamo cominciare ad usare ownCloud.

Vedi articolo

[PHP] Classe in PHP per autenticazione utenti con LDAP

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.

Vedi articolo

[prestashop] Expression #11 of SELECT list is not in GROUP BY clause and contains nonaggregated column

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.

Vedi articolo

[magento2] Script esterno per rimuovere le immagini duplicate su tutti i prodotti

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:

Vedi articolo

[woocommerce] Disabilitare metodi di spedizione in base alla classe di spedizione

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.

Vedi articolo

[wordpress] Escludere pagine dalla sitemap generata da YoastSEO oppure JetPack

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.

Vedi articolo

Errori durante il file upload con PHP, Apache & nginx

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.

Vedi articolo

[php] Configurare php.ini per l’upload dei file

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:

Vedi articolo

[php] Costruire un oggetto iterabile che possa essere percorso con foreach, grazie alle interfacce Iterator, ArrayAccess e Countable

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:

Anche qui usiamo if( $value instanceof Studente ) per verificare che l’oggetto sia di tipo Studente. Nel metodo offsetGet() utilizziamo il null coalescing operator per restituire null nel caso in cui l’oggetto non esista.

A questo punto l’istruzione $scuola[] = new Studente("Edea"); diventa utilizzabile, mentre $scuola[] = "Edea"; produce il solito errore Fatal error: Uncaught InvalidArgumentException: l'oggetto deve essere di tipo Studente in...

Infine vogliamo poter usare il metodo count($scuola) sul nostro oggetto, ottenendo il conteggio di tutti gli studenti inseriti. Se lo usiamo senza ulteriori implementazioni il risultato sarebbe sempre e comunque 1.

L’interfaccia Countable richiede un unico metodo:

Implementiamolo nel modo seguente:

Probabilmente sarebbe stato più carino implementare un metodo interno alla classe, magari un contatore che tenesse conto delle aggiunte, ma ai fini dell’esercizio ci accontentiamo di chiamare count sul vettore interno degli studenti.

Fatto tutto questo vediamo il risultato finale così ottenuto:

Vedi articolo

[wordpress] Got error ‘crayon-syntax-highlighter/crayon_langs.class.php on line 340

Problema: Dopo l’aggiornamento al PHP 7.3 il plugin per WordPress Crayon Syntax Highlighter, utilizzato per evidenziare codici di programmazione, smette di funzionare e blocca la visualizzazione delle pagine nelle quali è utilizzato.

Soluzione: Modificare due file per rendere compatibile il riconoscimento per espressioni regolari con le nuove definizioni di PCRE2

L’errore che si presenta è tipo il seguente: AH01071: Got error 'crayon-syntax-highlighter/crayon_langs.class.php on line 340PHP message: PHP Warning: preg_replace(): Compilation failed: invalid range in character class at offset 4 in

Purtroppo il plugin, per quanto buono, non è aggiornato da 4 anni.

In particolare presenta problemi con l’aggiornamento del PHP alla versione 7.3, per via delle nuove definizioni PCRE2 ed in particolare proprio per la presenza di un segno – (meno), proprio come trattato nel precedente articolo.

Per risolvere il problema facciamo nel modo seguente. Posizioniamoci nella cartella del plugin /wp-content/plugins/crayon-syntax-highlighter/

Modifichiamo il file crayon_langs.class.php alla riga 340

Sostituiamo la riga con:

Modifichiamo il file crayon_formatter.class.php alla riga 118

Sostituiamo le due righe con:

Fatto tutto questo il problema sarà risolto e potremo continuare ad usare il plugin.

Vedi articolo