Come rimuovere le directory svn su ambiente linux

Svn è fantastico, è uno strumento indispensabile per lavorare a più mani sul codice.

Ma bisogna saperlo usare, e usarlo con attenzione.
Questa nota nasce da un errore che non voglio ripetere: volevo portare un intero ramo da un progetto ad un altro, e mi sono limitato a fare una copia (cp -p).

Dopo aver copiato le directory sono entrato dentro una di queste, ho modificato qualche file per adattarlo al nuovo ambiente, e ho committato le modifiche.

Ma, errore degli errori, il commit è avvenuto nel ramo di provenienza, e non sulla destinazione. Avreo dovuto cancellare tutti i riferimento all’svn di origine, e aggiungere i file al nuovo repository.

Questa la premessa per giustificare questa riga di shell. Banale ma utile:

find . -name ".svn" -exec rm -rf {} \;

Come eliminare lo style inline dalla caption wordpress

WordPress inserisce automaticamente uno style sull’html utilizzato per la caption.

Comportamento anomalo, e poco pulito, che può essere rimosso utilizzando il filtro img_caption_shortcode

<?php

// Override img caption shortcode to fix 10px issue.
add_filter(‘img_caption_shortcode’, ‘fix_img_caption_shortcode’, 10, 3);

function fix_img_caption_shortcode($val, $attr, $content = null) {
extract(shortcode_atts(array(
‘id’    => ”,
‘align’ => ”,
‘width’ => ”,
‘caption’ => ”
), $attr));

if ( 1 > (int) $width || empty($caption) ) return $val;

return ‘<div id=”‘ . $id . ‘” class=”wp-caption ‘ . esc_attr($align) . ‘” >’ . do_shortcode( $content ) . ‘<p class=”wp-caption-text”>’ . $caption . ‘</p></div>’;
}
?>

 

Errori da principiante e l’importanza del noindex

Sono diversi anni che lavoro nello sviluppo di siti web, con realtà anche molto importanti della comunicazione, e solitamente sono molto attento a tutte le problematiche legate allo sviluppo, alle performance, alle ottimizzazioni e alla questione sicurezza.
Ma anche chi fa questo lavoro da anni può commettere degli imperdonabili errori, ed è capitato ultimamente anche a me.

Lavorando ad un progetto drupal come committente di secondo livello per una importante realtà tessile, avevo accesso ad un’area di test, nel quale rilasciare le diverse versioni prima del rilascio finale in produzione.
Si tratta di un server non protetto da password, ma il cui indirizzo è raggiungibile da chi lo conosce e lo digita direttamente nel browser.

Bloccato da un problema javascript legato a masonry ho fatto quello che di solito faccio quando un cliente è in difficoltà e non riesco a risolvere un problema: chiedo aiuto professionale assoldando esperti del tema.
E il posto migliore per farlo fino a qualche mese fa era vworker, un posto in cui incontrare sviluppatori di tutto il mondo e in cui è possibile trovare persone competenti e professionali con cui lavorare.

Purtroppo il vecchio vworker è stato recentemente acquisito da freelancer, un suo competitor (più gradevole esteticamente ma meno funzionale, a mio modesto parere), e tra le varie differenze che ci sono ce ne è una che mi è sfuggita: le richieste sono pubbliche, anche per utenti non registrati, e 2000 aggregatori un istante dopo aver inviato la richiesta la propagano sui diversi siti.

Questo comportamento sarebbe anche utile, se non si scrivono nell’articolo indirizzi di test o informazioni seppur temporaneamente riservate.

Ma se, come ho fatto io, inserite una url di test, questa nel giro di pochi giorni verrà propagata a macchia d’olio, generando tra l’altro una serie di link capaci di rafforzare le chiavi di indicizzazione dell’ambiente di test.
E così la società per cui stavo lavorando s’è trovata in seconda posizione della serp il link all’ambiente di test..

Ora, tralasciando il fatto che ha una prima pagina della serp decisamente abbandonata se per raggiungere la seconda posizione basta così poco, indubbiamente ho commesso almeno 2 errori.

Il primo è scrivere pubblicamente un indirizzo di test. il secondo, forse più grave, è nell’averlo fatto senza prima  essermi accertato che l’ambiente di test non fosse indicizzabile dai motori di ricerca.
Sono i ridumenti dello sviluppo, e cadere su una cosa del genere mi mortifica professionalmente.

Per questo faccio altrettanto pubblicamente mea culpa, ricordando a me e a chi legge questo post che per evitare che un ambiente venga indicizzato:

  • Utilizzare il file robots.txt
  • Utilizzare la tag meta “noindex”
  • Non inserire da nessuna parte il link a questo ambiente

devo ripetermelo la notte come un mantra

WordPress tips: come recuperare il file del tema utilizzato in pagina

Per recuperare il file del tema utilizzato da wordpress basta inserire questa funzione nel file functions.php:

<?php
// this can live in /themes/mytheme/functions.php, or maybe as a dev plugin?
function get_template_name () {
	foreach ( debug_backtrace() as $called_file ) {
		foreach ( $called_file as $index ) {
			if ( !is_array($index[0]) AND strstr($index[0],'/themes/') AND !strstr($index[0],'footer.php') ) {
				$template_file = $index[0] ;
			}
		}
	}
	$template_contents = file_get_contents($template_file) ;
	preg_match_all("(Template Name:(.*)n)siU",$template_contents,$template_name);
	$template_name = trim($template_name[1][0]);
	if ( !$template_name ) { $template_name = '(default)' ; }
	$template_file = array_pop(explode('/themes/', basename($template_file)));
	return $template_file . ' > '. $template_name ;
}
?>

e chiamarla in header.php (chiamato da tutti i file) in questo modo:

<? echo get_template_part(); ?>