MAMP per costituzione è strumento orientato alla praticità d’uso; con il succedersi delle versioni molte procedure di installazione, di aggiornamento e di ottimizzazione sono state ulteriormente evolute nella direzione della funzionalità: oggi, davvero in «poche mosse», possiamo allestire, e poi mantenere, un ambiente affidabile per testare in locale il nostro lavoro di sviluppo web. Tuttavia, per quanto in MAMP le composizioni d’ambiente siano ponderate, gli aggiornamenti tempestivi e le opzioni di impostazione numerose, non è infrequente il caso di trovarsi a fronteggiare esigenze di ulteriore personalizzazione. Quanto è testato in ambiente di sviluppo, infatti, ha poi in genere necessità di essere trasferito in un server cosiddetto di produzione. Qui i contesti sono variamente condizionati nella configurazione, risultando dunque più praticabile adeguarvisi piuttosto che il contrario.

personalizzazione della versione php
Ogni nuovo rilascio di MAMP aggiorna di norma la versione dell’interprete PHP all’ultima stabile disponibile. Altresì ne integra, quali risorse aggiuntive, un certo numero di precedenti, così come una maggiore varietà è predisposta online, in pacchetti pronti al download, per una veloce implementazione nel proprio sistema. Di contro, l’interfaccia di personalizzazione di MAMP è strutturata per rendere immediatamente accessibili due sole opzioni di versione. Qualora non fosse presente quella di nostra necessità si porrebbe il problema di come poterla impostare.

Detto in pratica, le opzioni di selezione visualizzano le ultime due versioni, ordinate in ordine decrescente, fra quelle che si trovano precaricate nella posizione «/Applicazioni/MAMP/bin/php/...» della nostra installazione. Per determinare la composizione delle opzioni sarà quindi sufficiente operare sull’indicizzazione di queste risorse, anteponendo al nome della cartella delle varie versioni successive a quelle di nostro interesse un suffisso arbitrario, ad es. «toglimi_», così che MAMP non la riconosca come risorsa «valida», dunque non la consideri tra quelle da proporre come scelta di configurazione.

Facciamo un caso concreto: fossero «php7.0.15», «php7.0.1», «php5.4.4» le cartelle delle versioni PHP precaricate nella suddetta posizione, le opzioni immediatamente accessibili dall’interfaccia utente sarebbero le prime due, la 7.0.15 e la 7.0.1. Poniamo servisse poter scegliere la 5.4.4, il precedente elenco di risorse potrebbe essere così riconfigurato nei nomi cartella: «toglimi_php7.0.15», «php7.0.1», «php5.4.45. Naturalmente la cartella relativa alla 7.0.15 potrebbe anche banalmente cancellarsi, ma non costa nulla mantenere la possibilità di riattivarla tra le opzioni in una diversa occasione. Se invece avessimo l’esigenza di usare una versione non già precaricata nell’installazione corrente, ad es. la 5.5.3, si tratterà semplicemente di effettuarne il download e aggiungerla alle suddette risorse, eventualmente operando sui prefissi dei nomi cartella in modo da farla «salire» entro le posizioni «considerabili». Nel caso in esempio, non sarebbe necessario operare modifiche diverse da quelle già specificate, poiché evidentemente la 5.5.3 precederebbe la 5.4.4 rientrando appunto tra le prime due in elenco.

Selezionata la giusta versione dell’interprete PHP, bisognerà assicurarsi che anche la configurazione dello stesso sia congruente con le nostre necessità. Essa infatti è specificabile attraverso un certo numero di direttive, la cui composizione può visualizzarsi processando sul server l’apposita istruzione «echo phpinfo();». MAMP, così come i pannelli di controllo dei server web remoti, reca già predisposta una pagina di visualizzazione rapida. La configurazione è eventualmente operabile nel file «php.ini» della rispettiva versione, ad esempio: «/Applicazioni/MAMP/bin/php/php7.0.1/conf/php.ini».

personalizzazione della gestione errori
Ogni ambiente di sviluppo non può prescindere dalla visualizzazione estesa di eventuali notifiche server, relative ad avvertimenti o errori degli script in elaborazione. Per ovvi motivi di sicurezza, in produzione si impongono opposte necessità, essendo indispensabile al riguardo un’interazione viceversa limitata, filtrata e precostituita. Si dovrà dunque operare con configurazioni distinte. Per impostazione predefinita, in MAMP la visualizzazione degli errori è opportunamente disattivata, lo sviluppatore dovrà pertanto attivarla manualmente predisponendo il proprio ambiente di lavoro.

In PHP anche questa caratteristica è governata dal citato file di configurazione: «/Applicazioni/MAMP/bin/php/php(versione di interesse)/conf/php.ini». Come già descritto, MAMP integra più versioni di PHP alternativamente attivabili: sarà dunque sufficiente personalizzare solo quella/quelle d’utilizzo. In caso di dubbi, basterà consultare, nella Web Start Page di MAMP, la voce di menù phpInfo, e poi cercare attorno alla settima riga l’indicazione Loaded Configuration File, cui corrisponde il percorso del «php.ini» in uso. Individuato/i il file d’interesse (con la buona cura di farne prima una copia di sicurezza,  (es. «php.ini.old»), lo si dovrà aprire e scorrere fino all’intestazione Error handling and logging (230-250 riga circa). A questo punto, chi vorrà avrà materiale per approfondire la conoscenza delle opzioni PHP di gestione errori. Al lato pratico, sarà invece sufficiente attivare/verificare le seguenti configurazioni, le quali per essere attive dovranno altresì presentarsi decommentate, cioè prive del segno « ; » ad apertura riga:

error_reporting = E_ALL

display_errors = On

log_errors = On

log_errors_max_len = 0

ignore_repeated_errors = Off

ignore_repeated_source = Off

report_memleaks = On

track_errors = Off  (deprecato da ver. php 7.2)

error_log = "/Applications/MAMP/logs/php_error.log"

(le prime tre istruzioni sono decisive)

Salvare quindi il file «php.ini», e testare l’attivazione della visualizzazione errori, facendo eseguire al server uno script volontariamente errato (quest’ultima operazione non sarà difficile!).

personalizzazione delle impostazione di mysql
Un’altra potenziale causa di significative difformità di comportamento tra MAMP, utilizzato come ambiente di sviluppo, e il web server di produzione, ad esempio un comune servizio hosting, risiede nella configurazione del database. Classico è il caso di disparità nella visualizzazione dei caratteri accentati o specifici delle diverse lingue; ma problemi non meno spiacevoli possono coinvolgere anche il funzionamento stesso degli script nelle interazioni con la base dati: aggiornamenti, selezioni, cancellazioni. Il meccanismo di interpretazione dei dati, il mantenimento dell’integrità e della congruenza degli stessi, la valutazione dei casi e delle azioni predefinite, ecc. sono infatti governati da una serie di variabili di sistema che possono sensibilmente differire da un’ambiente all’altro.

In genere, per quanto è formulato in PHP, la base dati di predilezione è MySQL, quindi ci riferiremo a questa. Di nuovo, più che fare casi specifici, la cui varietà è davvero innumerevole, ci concentreremo sulla sostanza del problema, in modo che la questione risulti logicamente chiara e, all’occorrenza, si possa avere un riferimento di partenza da sviluppare e far aderire alle proprie puntuali necessità.

Rispetto a queste situazioni, si possono adottare due approcci fondamentali: l’interazione con la base dati attraverso connessioni fortemente parametrizzate, oppure l’equalizzazione delle configurazioni degli ambienti che devono tra loro dialogare. Nel primo caso, gli script imporranno una categorizzazione autonoma di quanto proviene dalle risorse database, quasi si trattasse di dati grezzi, imponendo ad esempio una data codifica della mappa caratteri o una modalità di valutazione della consistenza dei dati; nel secondo caso, viceversa, si porrà minuta attenzione che le risorse della base dati siano trattate per qualità e struttura in modo esattamente univoco nei distinti ambienti, di sviluppo e produzione. Posto che resta sempre opportuno e doveroso che gli script operino autonomamente valutazioni di conformità dei dati che processano, specie in talune localizzazioni critiche, il poter far conto su risorse di cui si possa dare per accertato un certo grado di categorizzazione e integrità costituisce proprio la prerogativa specifica e il vantaggio di una buona base dati. Va da sé che questa seconda opzione sia quella da perseguire in via prioritaria, almeno nel caso generale.

Fortunatamente l’impostazione delle variabili database in MAMP è applicabile con procedura sintetica: si tratta di creare/aggiornare il file di configurazione nel percorso «/Applicazioni/MAMP/conf/my.cnf». Meno immediato è purtroppo operare la scelta dei corretti parametri di configurazione. Trattandosi tuttavia, nel caso comune, di uniformare ad un server di produzione tal quale, un server di sviluppo invece pienamente configurabile, pochi passaggi potranno portarci convenientemente a soluzione.

Attraverso l’applicazione con cui gestiamo il database in ambiente di produzione (tipicamente PhpMyAdmin), sarà semplice estrarre la configurazione MySQL in uso, interrogando il sistema attraverso la console SQL. Ad esempio, l’esecuzione del comando «show variables» ci riporterà l’esteso completo della configurazione. Per facilitarci il confronto, di norma saranno comunque sufficienti delle interrogazioni più mirate: «show variables where variable_name like '%char%' or variable_name like '%colla%'» (o più genericamente «show variables like 'c%'») restituirà l’impostazione delle undici variabili che regolano l’interpretazione della codifica caratteri nei testi.

Altra configurazione di importanza strutturale, e frequente motivo di difformità fra le impostazioni del server di produzione e quello di sviluppo, è la modalità «sql_mode», attraverso la quale si può gestire una strategica selezione di comportamenti e compatibilità di MySQL. L’esecuzione del comando «select @@sql_mode, @@global.sql_mode», ci consentirà di leggere gli attributi assegnati complessivamente a detta modalità. Individuate le componenti cui necessitasse eventuale adeguamento nel nostro MAMP locale, si indicherebbero nel citato file di configurazione «my.cfn», con la valorizzazione corretta e raggruppate sotto opportuno flag. Un esempio basico:

[mysqld]

character-set-server = latin1

collation-server = latin1_general_ci

sql_mode = "no_engine_substitution,strict_trans_tables"

Qualora il file di configurazione «my.cnf» non fosse già impostato (è il caso predefinito) un riferimento può derivare dall’osservazione della struttura d’esempio che si trova precaricata (fino alla versione 4.1.1 ) nella libreria di MAMP, alla posizione «/Applicazioni/MAMP/Library/support-files/my-default.cnf». In assenza è ovviamente possibile generare autonomamente il file con un editor di testo collocandovi le istruzioni di necessità, quindi nominarlo e collocarlo come sopra specificato.