Archives For PHP

Ti riporto qui di seguito una piccola modifica al codice del functions.php di WordPress che puoi utilizzare per escludere dalla creazione del feed RSS una particolare categoria di articoli che non vuoi compaiano nei lettori feed dei tuoi lettori. Si tratta di una modifica semplice e che non si limita a una sola categoria nel caso tu te lo stessi chiedendo.

WordPress e sicurezza: alcune best practices 2

Forse inutile che te lo dica ma sai bene che in questi casi è meglio prevenire che curare:

ATTENZIONE: Prima di eseguire qualsiasi modifica ai tuoi file e/o dispositivi sei pregato di effettuare un backup di questi (o lavorare in ambiente di test e mai di produzione). Solo così sarai capace di tornare indietro ponendo rimedio a eventuali errori di distrazione.

Ciò detto, apri il file functions.php del tuo tema e copia / incolla il codice PHP qui di seguito, non salvare le modifiche prima che io ti abbia spiegato cosa c’è da ritoccare:

function exclude_category( $query ) {
    if ( $query->is_feed ) {
        $query->set('cat', '-000');
    }
return $query;
}
add_filter('pre_get_posts', 'exclude_category');

Come forse avrai capito quel -000 fa riferimento alla categoria da escludere dal feed RSS del tuo blog. Per individuare il giusto ID da escludere portati nella pagina Categories (Categorie in italiano) del tuo pannello amministrativo (dovresti arrivare all’URL TUOBLOG.COM/wp-admin/edit-tags.php?taxonomy=category per capirci), punta il cursore del mouse sul nome della categoria che intendi escludere (non fare clic) e leggi in basso a sinistra (o destra, dipende dal browser) l’URL al quale quel collegamento punta:

Lo vedi quel tag_ID? È proprio quello l’ID che ti serve. Per capirci, se dovessimo basarci sull’esempio nell’immagine dovresti sostituire il -000 con il -2415. Tutto chiaro? Bene, salva le modifiche al file e sovrascrivilo sul server, l’operazione è così terminata. Se hai bisogno di escludere più categorie contemporaneamente poco male, puoi aggiungerle in coda alla prima dichiarata separandole con la virgola, per capirci $query->set('cat', '-000, -001, -003');.

In caso di problemi utilizza pure l’area commenti qui di seguito.

Buon lavoro!

× Le pillole del Dr.Mario

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

Te la faccio facile: dopo l’upgrade dei dischi del mio Synology sono finalmente riuscito a replicare in maniera completa i dati che tengo sul mio account Dropbox. Ho sostituto più job di replica specifica dal noto servizio di Cloud Storage a Synology con uno solo:

Replica di file sullo stesso NAS (Synology) con rsync

Uno di quei job di replica però svolgeva un diverso lavoro, un ponte tra Synology Drive e Dropbox, utile per tenere allineate due cartelle che nascono da Cloud Storage diversi e che non posso gestire con un collegamento simbolico. Ho risolto il problema con una stringa di rsync e un’operazione programmata da Pannello di Controllo del NAS.

Il comando non fa altro che prendere il contenuto della cartella Drive di CONTOSO e portarlo nel mirror Dropbox che ho creato sul volume1 del NAS, cancellando nella destinazione file eventualmente eliminati dalla sorgente, vince Synology Drive. Quello che vedi sopra è uno script di bash che ho chiamato Drive2Dropbox.sh e che ho messo in una cartelle del NAS. Accedi ora al Pannello di Controllo Synology e avvia l’Utilità di pianificazione. Crea una nuova attività pianificata con script definito dall’utente.

A questo punto ti basterà inserire il comando che richiama lo script (nel mio caso bash /volume1/Script/Drive2Dropbox.sh) e programmare l’attività per ripetersi ogni 30 minuti nell’arco dell’intera giornata, tutti i giorni da ora in poi.

Replica di file sullo stesso NAS (Synology) con rsync 1

Ora puoi metterti comodo e lasciare che il NAS faccia il suo sporco lavoro, non serve fare altro.

Buon lavoro 🙂

Condividi l'articolo con i tuoi contatti:

Ammettilo, ti è capitato almeno una volta nella vita, hai cominciato a preparare un articolo sul tuo blog e lo hai pubblicato per sbaglio prima del dovuto, correndo poi ai ripari e riportandolo tra le bozze o per lo meno tra gli articoli non pubblicamente accessibili, cancellando eventuali rilanci su Social Network e simili. È fastidioso, genera qualche risposta 404 e il feed RSS comunque mostrerà quell’errore a meno di farlo ricostruire (pratica sconsigliata). Io ci ho messo una pezza (dopo aver fatto l’errore, chiaramente) tanto stupida quanto utile passando per il solito functions.php, un alert Javascript che chiede ulteriore conferma prima di procedere con la pubblicazione o l’aggiornamento di un articolo già pubblicato (e vale anche con la programmazione futura).

WordPress e sicurezza: alcune best practices 2

Prima di cominciare è sempre d’obbligo ricordarti che:

ATTENZIONE: Prima di eseguire qualsiasi modifica ai tuoi file e/o dispositivi sei pregato di effettuare un backup di questi (o lavorare in ambiente di test e mai di produzione). Solo così sarai capace di tornare indietro ponendo rimedio a eventuali errori di distrazione.

Ciò detto, cominciamo. Apri il file functions.php contenuto nella cartella del tuo tema e aggiungi questa porzione di codice in coda (o dove più preferisci in base alle tue esigenze):

$c_message = 'Stai pubblicando o aggiornando un articolo, procedo?';
function confirm_publish(){
	global $c_message;
	echo '<script type="text/javascript"><!--
	var publish = document.getElementById("publish");
	if (publish !== null) publish.onclick = function(){
		return confirm("'.$c_message.'");
		};
	// --></script>';
}
add_action('admin_footer', 'confirm_publish');

Salva il file e carica la modifica online nella modalità che più preferisci. Questa sarà immediata, collegata all’utilizzo del pulsante Pubblica / Programma, non appena ci farai clic sopra incontrerai questo popup:

WordPress: un messaggio di conferma prima della pubblicazione

Un clic su Ok permetterà all’operazione di concludersi, diversamente potrai fare clic su Annulla per evitare l’errore non voluto. Non è un trucco che ti cambia la vita ma è certamente un ulteriore strato che ti porta necessariamente a dover dare una conferma in più, se passi anche questa senza accorgertene allora vorrà dire che te la stai davvero cercando! ?

Per dubbi o domande puoi utilizzare l’area commenti a tua disposizione in coda all’articolo.


credits: trickspanda.com/add-confirmation-dialog-wordpress-publish-button
Condividi l'articolo con i tuoi contatti:

Ciao, articolo di servizio per dirti che – se mi stai leggendo per temponon devi aggiornare il plugin BackupWordPress allaneonataversione 3.9 rilasciata una manciata di ore fa (circa 16 a ora che sto scrivendo l’articolo), questa causa un errore fatale che manderà in crash il tuo blog e che ti costringerà a passare dalla porta di servizio per rimediare (la porta di servizio è quella offerta dal nuovo servizio di Recovery integrato in WordPress 5.2).

Non aggiornare BackupWordPress alla versione 3.9 (per il momento)

Il bug viene minuziosamente descritto qui su GitHub, segnalato da un utente che si è ritrovato nella medesima situazione del sottoscritto: github.com/xibodevelopment/backupwordpress/issues/1206. Come già successo in passato (vedi l’articolo Possibile problema in BackupWordPress 2.3) il modo di rimediare c’è e lo si può mettere in atto facilmente connettendoti in FTP al tuo spazio web e rinominando la cartella del plugin (wp-content/plugins/backupwordpress) in backupwordpress_ (per esempio, ma vale qualsiasi altro nome), questo non permetterà al tuo WordPress di trovare i file del plugin e di conseguenza disattiverà quest’ultimo consentendoti di far tornare operativo il sito web.

Rimanere con la vecchia versione fino a nuovo ordine

Se vuoi rimettere in pista la vecchia versione di BackupWordPress in attesa che ne venga rilasciata una nuova che corregge il bug puoi scaricarla direttamente dal repository ufficiale all’indirizzo downloads.wordpress.org/plugin/backupwordpress.3.8.zip. Scompatta il file ZIP, cancella la cartella attuale di BackupWordPress sul tuo spazio web e carica quella che hai appena scompattato, le impostazioni sono salvate nel tuo database e non verranno quindi perse.

Correggere il bug presente e rimanere con la 3.9

Un thread nel forum di supporto del plugin suggerisce una via alternativa per risolvere il problema generato dal nuovo BackupWordPress: wordpress.org/support/topic/how-i-fixed-3-9-crash.

Puoi lanciare l’aggiornamento alla versione 3.9 (quindi il tuo WordPress diventerà momentaneamente non funzionante), nel frattempo scarica e scompatta il contenuto della versione 3.8 (downloads.wordpress.org/plugin/backupwordpress.3.8.zip), quindi carica via FTP le cartelle backdrop e whitelist-html sovrascrivendo quelle presenti. Al contrario delle vecchie, le nuove cartelle sembrano infatti non contenere i file necessari per il funzionamento del plugin. Sovrascrivendole farai nuovamente funzionare BackupWordPress ottenendo un “ibrido” tra le versioni 3.8 e 3.9.

Sembra proprio che qualcuno abbia avuto un pelo troppa fretta nel preparare la nuova versione del plugin, il tutto senza accorgersi di nulla e senza dare il giusto peso alle numerose segnalazioni di malfunzionamento già pervenute tra GitHub e forum di supporto WordPress. A questo punto non resta che attendere il rilascio della nuova versione del plugin che correggerà questa anomalia.

12/6/19

Tutto come previsto: è stata da poco rilasciata la versione 3.10 che corregge il bug letale della sfortunata e ben poco duratura 3.9 ?
Puoi tornare ora ad aggiornare il plugin senza strani (ma perfettamente funzionanti) work-around.

BackUpWordPress
BackUpWordPress
Developer: XIBO Ltd
Price: Free
× Le pillole del Dr.Mario

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

Tutto parte da una segnalazione di bug arrivata tramite il mio bug bounty program (openbugbounty.org/reports/809068) e, seppur protetto da alcuni metodi di cui ti ho già parlato in passato, effettivamente il file XML-RPC di WordPress risultava raggiungibile dall’esterno, mostrando potenzialmente il fianco a un qualche attacco poco gradito. Per questo motivo ho voluto aggiungere un ulteriore strato di sicurezza che gli permette di continuare a rimanere disponibile per Jetpack e nulla più. Per farlo mi è bastato mettere mano al file .htaccess del dominio.

WordPress: 5 step per la sua (e tua) sicurezza

La documentazione a cui fare riferimento è quella ufficiale di Jetpack, disponibile all’indirizzo jetpack.com/support/hosting-faq. Nello specifico ciò che a te interessa è quel paragrafo relativo a “Whitelist all communications between WordPress.com and Jetpack“, utile per permettere al tuo sito e al servizio messo a disposizione da WordPress.com di parlare senza incontrare ostacoli, lasciando fuori tutto il resto.

Al solito, prima di cominciare, il consiglio resta sempre lo stesso:

ATTENZIONE: Prima di eseguire qualsiasi modifica ai tuoi file e/o dispositivi sei pregato/a di effettuare un backup di questi (o lavorare in ambiente di test e mai di produzione). Solo così sarai capace di tornare indietro ponendo rimedio a eventuali errori di distrazione.

Una questione di .htaccess

Pronto? Cominciamo. Il trucco è semplice e sta tutto nel file che può limitare l’accesso alle risorse contenute nel tuo sito web. Apri il file .htaccess con un editor di testo degno (Notepad++ o Atom), non toccare nulla che sia stato messo lì dal tuo WordPress o da qualsiasi altro plugin da te utilizzato (penso a iThemes Security o W3 Total Cache e simili), trova uno spazio nuovo da occupare con una porzione di codice che dovrebbe essere quanto più simile a questa proposta di seguito:

<Files xmlrpc.php>
    Order Allow,deny
    Allow from 122.248.245.244
    Allow from 54.217.201.243
    Allow from 54.232.116.4
    Allow from 192.0.64.1/192.0.127.254
    Allow from 192.0.80.0/20
    Allow from 192.0.96.0/20
    Allow from 192.0.112.0/20
    Allow from 195.234.108.0/22
    Deny from all
    Satisfy All
    ErrorDocument 403 https://gioxx.org/403.shtml
</Files>

Io ho inserito il codice subito prima del termine del “paragrafo” modificato da WordPress (per capirci, prima di “# END WordPress“). Una volta terminato il tuo lavoro, salva la modifica e sovrascrivi il file presente sul tuo spazio FTP. Ciò che hai appena fatto consiste nel bloccare ogni possibile comunicazione con il file xmlrpc.php a esclusione degli IP appartenenti a WordPress.com, come una sorta di Firewall che taglia fuori tutti tranne loro. Chiunque proverà a puntare a quel file php sul tuo spazio hosting, si troverà davanti a una pagina di errore (nel mio caso https://gioxx.org/403.shtml, nel tuo ti consiglio di modificarla con qualsiasi altro tipo di indirizzo).

La modifica è immediata e dovrebbe portare beneficio alla tua installazione WordPress – in termini di sicurezza, nda – che non risentirà così alcun problema nell’utilizzo del sempre troppo mastodontico JetPack, in attesa che quest’ultimo si decida a utilizzare un diverso metodo per comunicare con le installazioni del CMS in giro per il mondo.

Al solito: per qualsiasi ulteriore dubbio o informazione l’area commenti è a tua totale disposizione (anche per suggerire metodi alternativi a quello proposto poco sopra).


fonti:
namehero.com/startup/how-to-safely-disable-xmlrpc-in-wordpress-while-keeping-jetpack
jetpack.com/support/hosting-faq
Condividi l'articolo con i tuoi contatti: