Categoria: Lo Internet

Alcuni siti bloccano (senza alcuna vera utilità) l’utilizzo del tasto destro, ossia l’apertura del menù contestuale che, tra le altre cose, permetterebbe di copiare il testo o le immagini.

Questo tipo di blocco può essere aggirato tramite Google Chrome, nel modo seguente:

1. Premere il tasto F12 mentre si è sulla pagina, aprendo così la console sviluppatore
2. Aprire la tab della console (qualora non fosse aperta) e digitare document.oncontextmenu=null;
3. Premere invio

Questo dovrebbe disattivare il blocco del tasto destro e dell’apertura del menù contestuale.

Questa guida fa riferimento a Moodle 3.4, ma in linea generale dovrebbe essere valida per tutte le versioni di Moodle 3.x.

Per determinare la versione del proprio Moodle è sufficiente consultare il file version.php nella root del portale.

All’occorenza possiamo impostare Moodle in modalità manutenzione, durante il trasferimento.

1. Backup di tutti i dati

Anzitutto dobbiamo effettuare il backup di tutti i dati.

Moodle si trova tipicamente distribuito in due cartelle, la root del virtualhost e una cartella per i dati.

Per esempio le due cartelle potrebbero trovarsi in:

radice virtual host > /var/www/vhosts/petarkaran.it/htdocs

cartella dei dati > /var/www/vhosts/petarkaran.it/dati_moodle

La cartella dei dati dovrebbe trovarsi sempre in un’ubicazione privata, non accessibile direttamente dal virtualhost. Ovviamente deve essere accessibile ad apache.

Questo vuol dire che dobbiamo ricreare entrambe le posizioni sul nuovo server (con l’eventuale nuovo dominio).

ATTENZIONE! Se il backup dei dati viene fatto tramite FTP bisogna impostare il trasferimento dei dati su binario

A questo punto l’ideale sarebbe fare un file zip per il contenuto di ciascuna delle due cartelle. Per farlo su server Linux è sufficiente digitare:

Il comando va eseguito all’interno di ciascuna cartella. Se volessi farlo in sequenza per le suddette due cartelle, dovrei fare:

Se si dovesse procedere con un client FTP invece, assicuriamoci, come evidenziato prima, di impostare il trasferimento su binario.

Su FileZilla bisogna andare su Modifica > Impostazioni > Trasferimenti > Tipi di file e selezionare Tipo di trasferimento predefinito > Binario, come nell’immagine:

Fatto tutto questo eseguiamo il backup del database.

Se abbiamo fatto tutto correttamente avremo 3 file di backup:

• cartella della radice principale di moodle
• cartella dei dati di moodle
• file SQL del database

2. Importare il database

Adesso predisponiamo il database MySQL/MariaDB.

Anzitutto assicuriamoci che il set di caratteri del nuovo database sia utf8mb4

Per importare il database potrebbe essere necessario modificare alcuni parametri del database stesso.

In particolare potrebbe essere necessario modificare il file /etc/mysql/my.cnf aumentando i parametri innodb_log_file_size e max_allowed_packet

Prima di importare il file dobbiamo sostituire dentro tutti i parametri del vecchio dominio. Se per esempio stessimo migrando la piattaforma da petarkaran.it a petarkaran.org allora dovremmo usare il Trova e Sostituisci di un opportuno editor di testo (per esempio Notepad++).

Una volta sostituiti tutti gli indirizzi possiamo importare il file sql nel nuovo database.

3. Trasferire i dati e modificare il file config.php

A questo punto ricostruiamo la struttura delle cartelle della radice e dei dati sul nuovo server. Immaginiamo di creare:

radice virtual host > /var/www/vhosts/petarkaran.org/htdocs

cartella dei dati > /var/www/vhosts/petarkaran.org/dati_moodle

Scompattiamo dentro i dati (o trasferiamoli tramite FTP) ed assicuriamoci che i permessi siano impostati correttamente sull’utente di apache del nuovo server.

Fatto questo modifichiamo le seguenti voci del file config.php nella radice del virtualhost:

Ovviamente bisogna inserire i dati corretti.

4. Avviare Moodle e pulire la cache

Una volta avviato Moodle possiamo effettuare l’accesso. Prima di rendere tutto operativo dobbiamo solamente svuotare la cache per far ripartire tutto da capo con i nuovi parametri.

Per farlo andiamo su Dashboard > Amministrazione del sito > Sviluppo > Svuota le cache

Premiamo il tasto Svuota Cache

Problema: quando si cerca di caricare su Google Drive un documento di dimensioni consistenti (nel mio caso il problema si presentava con file di appena qualche MB) l’upload non riesce ad andare a buon fine e si blocca su un caricamento simile a quello nell’immagine, dando per tempo stimato “Meno di un minuto rimanente”

Soluzione: il problema può dipendere da Kaspersky Internet Security. Dalle Impostazioni di rete disattivare Scansione delle connessioni crittografate.

Più nel dettaglio ho notato che questo problema affligge tutti gli upload via web. Anche tentando il caricamento altrove, non solo su Google Drive, ed utilizzando qualsiasi browser (ho trovato indistintamente il medesimo problema sia su Chrome, Firefox che Edge).

In generale il problema si presenta come l’impossibilità di stimare il tempo di upload necessario, per cui qualunque barra di upload arriva subito alla fine e si blocca lì fino al completamente del medesimo.

Il problema dipende da Kaspersky Internet Security, nel mio caso ho verificato il problema sulla versione 20.0.14.1085 (j) con Windows 10 x64 Build 18362.

Per risolvere il problema aprire Kaspersky Internet Security > Impostazioni > Avanzate > Rete (Impostazioni di rete) > Scansione delle connessioni crittografate

Selezionare Non esaminare le connessioni crittografate.

In Magento 2 l’errore Exception #0 (LogicException): catalog_product index does not exist yet. Make sure everything is reindexed si riferisce al fatto che il catalogo dei prodotti non è stato indicizzato. Questo problema si presenta frequentemente quando si usano altri motori per la gestione del catalogo, come ad esempio ElasticSearch (specialmente con il plugin di Smile-SA, ma non solo).

Per risolvere il problema lanciamo nuovamente l’indicizzazione del catalogo ed aggiorniamo il tutto, procedendo nel modo seguente da riga di commando.

ATTENZIONE: In teoria l’unico comando utile e necessario è il seguente:

Se dovessero sorgere problemi o non esserci risultati, procedere nella maniera descritta di seguito.

Se non lo abbiamo procuriamoci n98-magerun2.

Scarichiamolo nella cartella di installazione di Magento, poi rendiamolo eseguibile, eseguendo i seguenti comandi:

A questo punto eseguiamo la richiesta di reindicizzazione:

Eseguiamola anche sul fulltext:

Faccio notare che sto concedendo al PHP 5G di memoria per poter portare a termine, senza errori, il processo.

Qualora dovessero sorgere errori nel processo di indicizzazione, come per esempio Catalog Search index is locked by another reindex process. Skipping., procediamo nel modo seguente, altrimenti andiamo alla pulizia della cache.

Individuiamo i processi attivi con:

Reimpostiamo il processo che ci interessa con:

Nel dubbi possiamo reimpostarli tutti eseguendo i seguenti comandi:

A questo punto possiamo rilanciare il processo che ci interessa.

Puliamo tutta la cache:

La cache di Magento è una delle cose più problematiche, per cui conviene eseguire anche comandi superflui per ripetere l’operazione per sicurezza.

Detto questo riavviamo apache e il servizio di elastisearch, se lo abbiamo installato:

A questo punto dovrebbe essere tornato tutto normale.

Trasferire un sito fatto in WordPress da un dominio all’altro è molto semplice. Questo vale anche nel caso in cui si abbia un sito in WordPress su un server locale (per esempio XAMPP) e lo si voglia trasferire su un hosting online.

1. Copiare tutti i file

Anzitutto dobbiamo copiare tutti i file da un dominio all’altro. Se abbiamo il sito su XAMPP, in locale quindi, dobbiamo individuare la cartella di installazione e copiare tutti i file contenuti in essa. La cartella con i file avrà circa questo aspetto:

Trasferiamo tutti quanti i file nella radice del nuovo hosting.

2. Esportare il database

Adesso dobbiamo esportare il database del sito, cosa che possiamo fare tipicamente da PHPMyAdmin. Nel caso di XAMPP l’indirizzo per l’accesso al database sarà probabilmente http://127.0.0.1/phpmyadmin

Dentro PHPMyAdmin selezioniamo il nostro database e poi andiamo alla voce Esporta. In generale da qui è sufficiente cliccare su esegui per scaricare il file *.sql.

3. Cambiare l’indirizzo del sito nel database

A questo punto apriamo il file *.sql che abbiamo appena scaricato con un editor di testo (per esempio Notepad++).

Dentro il file cerchiamo il termine siteurl, dovremmo trovare qualcosa di simile a questo:

Questo è l’indirizzo del nostro sito. Nel caso specifico vuol dire che il vecchio percorso del sito era http://127.0.0.1/wp

Immaginiamo che il nuovo dominio, sul quale vogliamo trasferire il sito, sia https://petarkaran.it

Faccio notare che il nuovo dominio ha la dicitura https anziché http.

A questo punto dobbiamo fare le seguenti sostituzioni usando l’opzione Trova e Sostituisci (disponibile nella maggior parte degli editor come Notepad++). Nel mio caso procederò nel modo seguente:

Attenzione a rispettare la medesima combinazione di slash. Quindi sostituiremo con i seguenti comandi:

http://127.0.0.1/wp ⇒ https://petarkaran.it

http:\/\/127.0.0.1\/wp ⇒ https:\/\/petarkaran.it

127.0.0.1/wp ⇒ petarkaran.it

127.0.0.1\/wp ⇒ petarkaran.it

ATTENZIONE a non fare i seguenti errori dove la struttura del dominio non è la medesima.

http://127.0.0.1/wp ⇒ https://petarkaran.it/

http://127.0.0.1/wp/ ⇒ https://petarkaran.it

In generale se si deve passare da un dominio ad un altro dominio è sufficiente usare:

https://vecchiodominio.ext ⇒ https://nuovodominio.ext

https:\/\/vecchiodominio.ext ⇒ https:\/\/nuovodominio.ext

Una volta fatte le modifiche salvare il file *.sql ed importarlo sul nuovo database.

4. Modificare wp-config.php

Ultima operazione che dobbiamo fare è modificare la configurazione del database dentro al file wp-config.php

Apriamo il file e modifichiamo le seguenti righe di codice:

In ordine mettiamo i dati del nome del database, lo username del database, la password del database e l’indirizzo host del database.

Una volta modificato il file wp-config.php carichiamolo sul nostro nuovo hosting ed abbiamo finito.

Per cambiare le immagini delle bandiere delle lingue del plugin PolyLang è sufficiente procedere nella maniera seguente:

1. Creare dei file PNG (*.png), JPG (*.jpg) o SVG (*.svg) nominandoli secondo il codice della lingua, ad esempio: it_IT per italiano, en_GB o en_US per inglese (dipende quale si è scelto nelle impostazioni di PolyLang), de_DE per il tedesco ecc
2. Creare la cartella /wp-content/polylang (la cartella non esiste di predefinito)
3. Caricare nella cartella i file delle bandiere creati in precedenza
4. Andare su WordPress in Bacheca > Lingue > Impostazioni > Modifiche dell’URL > Impostazioni, senza dover apportare modifiche premere su Salva modifiche

A questo punto le nuove bandiere saranno visibili al posto di quelle predefinite.

Quando si intende fare una campagna pubblicitaria online bisogna tenere conto di diversi fattori, oltre che degli obiettivi per cui la campagna è pensata.

A differenza della pubblicità tradizionale (quella che si potrebbe fare sui giornali, sulla TV oppure sui cartelloni per strada) nelle campagne online è possibile verificare le conversioni prodotte dalla campagna stessa.

Con conversioni si intendono quelle azioni intraprese dagli utenti che hanno visto la pubblicità e per le quali la campagna pubblicitaria era stata pensata. Nel caso di una campagna pubblicitaria finalizzata alla promozione di prodotti, la conversione equivale all’acquisto di un prodotto. La conversione potrebbe essere anche l’iscrizione ad una newsletter, una richiesta di contatto o preventivo ecc.

Il processo di conversione può essere sintetizzato nel seguente schema:

Analizziamo brevemente i singoli passaggi del processo:

1. Impressioni: le volte che la pubblicità viene mostrata, se la pubblicità viene mostrata 30.000 volte allora si avranno 30.000 impressioni. Le impressioni sono sempre maggiori o uguali al pubblico raggiunto. Un pubblico di 20.000 persone potrebbe generare 30.000 impressioni. Questo vorrebbe dire che in media ogni persona raggiunta ha visto la pubblicità 1,5 volte. Questo valore viene chiamato anche frequenza.
2. Visite (o click): il numero di persone che, dopo aver visto la pubblicità, decidono di interagire con essa (o più semplicemente cliccano sull’inserzione). Il rapporto tra quelli che vedono la pubblicità e quelli che decidono di cliccare si chiama CTR (Click-through rate, in italiano “percentuale di click”). In generale come CTR medio si prende, in assenza di ulteriori dati statistici, un valore del 1%. Un CTR del 2% può essere già considerato ottimo. Questo valore dipende ovviamente anche dal messaggio pubblicitario stesso e da altri elementi. Un CTR molto elevato non è garanzia di alcun tipo di successo; significa solamente che le persone cliccano frequentemente sulla pubblicità. Un messaggio pubblicitario fuorviante potrebbe produrre un CTR molto elevato, che non corrisponde poi ad alcuna conversione significativa. Inoltre ad ogni click, in una campagna online, è associato un CPC (costo per click), ovvero quanto spendiamo per ogni click ottenuto. Se il CPC fosse di 0,50€ vorrebbe dire che per ogni click pendiamo 0,50€.
3. Leads: sono semplicemente dei potenziali acquirenti, persone interessate al prodotto, che ancora non hanno deciso di acquistare il prodotto stesso. Un lead potrebbe “condurre” (di qui il nome) anche altri eventuali clienti all’acquisto del prodotto, tramite per esempio il passaparola, sebbene egli stesso poi non effettui alcun acquisto. E’ importante tenere conto dei lead solo dal punto di vista concettuale; significa che dobbiamo pensare la nostra campagna in modo che le pagine ad essa dedicata (le landing page) suggeriscano oppure consentano all’utente di lasciare i propri dati di contatto o memorizzare la pagina, per poter essere contattato successivamente o recuperare facilmente l’accesso al prodotto. Dal punto di vista statistico del processo di conversione i lead possono essere ignorati.
4. Acquisti: sotto il termine acquisto si intende qui la finalizzazione della conversione, cioè quell’azione per cui la campagna è stata pensata. Nella maggior parte dei casi si tratta appunto dell’acquisto di un prodotto, ma potrebbe anche trattarsi di una richiesta di contatto, una donazione, un’iscrizione ad una newsletter o un gruppo, ecc. Il rapporto tra il numero di visitatori e il numero di acquisti, ovvero conversioni, viene chiamato tasso di conversione. Se per esempio ottengo 200 visite dalla campagna (click) e ne conseguono 2 acquisti, il tasso di conversione sarà del 1%. In media il tasso di conversione, in mancanza di ulteriori dati statistici a disposizione, oscilla tra il 1% e il 3%. Il tasso di conversione è anche chiamato CVR o CR (conversion rate)

Appurato tutto questo vediamo come valutare una campagna pubblicitaria su Facebook.

Anzitutto procuriamoci dei dati statistici sull’andamento del mercato, a tale proposito utilizzerò quelli pubblicati da WordStream: Facebook Ad Benchmarks for YOUR Industry [2019]

A titolo di esempio immaginiamo di voler fare una campagna pubblicitaria per vendere dei prodotti casalinghi (vasi, piatti, accessori, complementi d’arredo).

WordStream ci informa che il mercato (Home & Garden) di riferimento ha i seguenti valori:

CTR 0,71%

CPC 2,78$ = 2,50€

CVR 7,02%

Da questi valori possiamo calcolare il costo di una singola conversione (CPA, costo per azione o cost per action) nel modo seguente:

Nel nostro caso specifico avremmo quindi:

Questo significa che per vendere 1 prodotto tramite la pubblicità dobbiamo spendere 35,61€

Questo è il valore più importante da tenere in considerazione. In generale si stima che il budget destinabile ad una campagna pubblicitaria rispetto al valore dell’evento (o dei prodotti che si intendono vendere) si dovrebbe aggirare entro il 12% di quest’ultimo.

Questa proprietà può essere estesa ai singoli prodotti, per cui se un prodotto viene venduto a 100€, il massimo che possiamo spendere in pubblicità per venderlo non dovrebbe superare i 12€. Naturalmente questo valore varia notevolmente da prodotto a prodotto e dai margini che abbiamo sul valore dei prodotti stessi.

Esempio: se intendiamo vendere delle camere di albergo mediante una campagna pubblicitaria, dobbiamo tener conto del fatto che sulle OTA le percentuali che vengono prelevate per la vendita si aggirano dal 15% al 18%. Questo significa che possiamo valutare la nostra campagna prendendo il 15% o il 18% come valore di riferimento. Se quindi una camera costa 80€ a notte possiamo spendere fino a 12€ o 14,40€ per cercare di venderla tramite una campagna pubblicitaria. Se la campagna pubblicitaria richiedesse una cifra superiore per venderla potremmo valutare se fare la campagna per la vendita di pacchetti vacanze (più notti per più persone) oppure rinunciare e affidarci alle OTA. Se per esempio il CPA fosse di 33€, vorrebbe dire che dovremmo vendere servizi (camere) ad almeno 183,33€ (nel nostro caso dovremmo proporre, nella pubblicità, non la singola notte, quanto prenotazioni da almeno 3 notti, dove 3 x 80€ = 240€).

Detto questo abbiamo capito quindi che attraverso una campagna online dobbiamo cercare di vendere prodotti per almeno 296,75€.

Dal momento che vendere casalinghi a questo prezzo non è facile (per proseguire sulla nostra ipotesi), dobbiamo valutare che tipo di offerta promuovere attraverso la campagna. Alcune idee potrebbero essere:

1. Incentivare una spesa di almeno 300€ (spedizioni gratuite, sconti, promozioni future, ecc)
2. Aggregare i prodotti in pacchetti (vendere per esempio set dello stesso prodotto o set preconfezionati di prodotti pronti all’uso)
3. Cambiare pubblico di destinazione (cambiare cioè il target; anziché vendere ai privati, potremmo indirizzare la campagna ad altri rivenditori, oppure ad albergatori che vogliono comprare set del medesimo prodotto per arredare diverse stanze nello stesso modo ecc.)

Attenzione! Resta il fatto che non possiamo sperare di vendere efficacemente prodotti che hanno un valore inferiore, per esempio un vaso da 20€, laddove la spesa per ottenere la vendita è di 35,61€. 

Da questo si deduce un altro fatto importante: le campagne online non sono adatte alla vendita di qualsiasi prodotto.

Per facilitare questo tipo di calcoli ho realizzato un piccolo simulatore in Excel, che ci permette anche di tenere conto di ulteriori dati statistici, quali la dimensione del pubblico, il costo di gestione della campagna, la frequenza di visualizzazione della campagna ecc.

Immettendo i dati di poco prima otterremmo qualcosa di simile a questo:

Nella mia ipotesi ho immaginato una campagna da 5€ al giorno, per una durata totale di 10 giorni ed un pubblico di 10.000 persone. Il valore dei prodotti è di 20€. Il calcolatore mi dirà chiaramente che la campagna non è sostenibile.

Se cambiassi il valore dei prodotti a 300€ otterrei il seguente risultato:

Se adesso provassi ad aumentare il budget giornaliero, portandolo a 60€ al giorno, otterrei di nuovo una campagna fuori dai parametri preimpostati.

Questo perché raggiungendo la saturazione del pubblico (ricordiamoci che sto ipotizzando un pubblico di 10.000 individui) aumenterei la frequenza di visualizzazione che, secondo quanto suggerito da Facebook stesso, non dovrebbe superare i 2 punti. Più è alta la frequenza e più la campagna è onerosa.

E’ altrettanto vero che anche con un budget di 10€ al giorno ed un costo di gestione della campagna (quello che pago a chi la configura e gestisce) di 150€, la campagna resta non fattibile.

Per chiunque volesse cimentarsi in questo genere di simulazioni metto a disposizione il simulatore in Excel utilizzato qui sopra:

Simulatore Facebook Ads

Il simulatore è stato realizzato per il Corso di Social Media Marketing della Mummu Academy di Firenze.

Per chiunque fosse interessato ad installare WordPress in locale, utilizzando XAMPP per creare un server Apache con PHP e MySQL, ho pubblicato una breve guida sul blog di Mummu Academy.

[wordpress] Come installare WordPress in locale

Soluzione1: Questo errore si presenta quando si effettua un ordine su Magento, si viene indirizzati al pagamento, ma il pagamento non va a buon fine e si viene rimandati indietro sul negozio. Per risolvere questo problema è sufficiente modificare il file app/code/core/Mage/Sales/Model/Resource/Quote.php come indicato di seguito

Per risolvere il problema posizioniamoci nella cartella principale del negozio in Magento. Dopodiché andiamo a modificare il file app/code/core/Mage/Sales/Model/Resource/Quote.php

Apriamolo e cerchiamo la seguente parte di codice

Alla linea quattro modifichiamo

In modo che diventi:

Salviamo il tutto.

Soluzione2: Questo errore si presenta quando per qualche ragione sono stati inseriti ordini sopra l’ultimo incrementale registrato in eav_entity_type. Per risolvere il problema è sufficiente incrementare sopra l’ultimo valore registrato il valore dell’incrementale. 

Di seguito discutiamo il problema e la soluzione nel dettaglio.

Anzitutto l’errore che si presenta è simile a questo:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0009032' for key 'UNQ_SALES_FLAT_ORDER_INCREMENT_ID', query was: INSERT INTO sales_flat_order (coupon_code, protect_code, shipping_description, is_virtual, store_id, customer_id, base_discount_amount, base_grand_total, base_shipping_amount, base_shipping_tax_amount, base_subtotal, base_tax_amount, base_to_global_rate, base_to_order_rate, discount_amount, grand_total, shipping_amount, shipping_tax_amount, store_to_base_rate, store_to_order_rate, subtotal, tax_amount, total_qty_ordered, customer_is_guest, customer_note_notify, customer_group_id, quote_id, base_shipping_discount_amount, base_subtotal_incl_tax, shipping_discount_amount, subtotal_incl_tax, weight, customer_dob, increment_id, applied_rule_ids, base_currency_code, customer_email, customer_firstname, customer_lastname, customer_middlename, customer_prefix, customer_suffix, customer_taxvat, discount_description, global_currency_code, order_currency_code, remote_ip, shipping_method, store_currency_code, store_name, x_forwarded_for, customer_note, created_at, updated_at, total_item_count, customer_gender, hidden_tax_amount, base_hidden_tax_amount, shipping_hidden_tax_amount, base_shipping_hidden_tax_amnt, shipping_incl_tax, base_shipping_incl_tax, gift_message_id, payment_fee_amount, base_payment_fee_amount, payment_installment_fee_amount, base_payment_installment_fee_amount, payment_tax_amount, base_payment_tax_amount, referral_code, ebizmarts_abandonedcart_flag, payment_fee_tax, base_payment_fee_tax, payment_percentage_fee, base_payment_percentage_fee) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, '1975-10-01 00:00:00', ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, '2018-11-28 11:14:46', '2018-11-28 11:14:46', ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

Questo errore si presenta perché si sta cercando di inserire una chiave duplicata in sales_flat_order. Prima di tutto verifichiamo la cosa spostandoci in sales_flat_order ed effettuando la seguente query:

Nel mio caso il risultato della query era 10.009. Adesso spostiamoci su eav_entity_store. Qui dovremmo vedere una tabella con tutti gli incrementali. Cerchiamo quello che ci interessa. Per trovarlo guardiamo i campi entity_type_id e store_id. Gli entity_type_id hanno come riferimento la tabella eav_entity_type.

Per esempio il codice 5 corrisponde agli ordini, mentre il codice 6 alle fatture/ordini.

Nel mio caso mi accorgo che increment_last_id è su 9033, mentre il massimo valore inserito in sales_flat_order è di 10.009. Quindi mi è sufficiente portare questo valore al di sopra di quello attuale, per esempio impostandolo su 10.010.

Una volta fatto il problema è risolto.