LESS the dynamic stylesheet language

LESS è un semplicissimo linguaggio creato da Alexis Sellier per rendere dinamici i CSS grazie all’implementazione di variabili, funzioni, espressioni e annidamenti. Facilita di molto lo sviluppo e la manutenzione di CSS molto articolati. Per utilizzarlo basta includere nelle pagine web oltre al file style.less(potete chiamarlo come vi pare) che conterrà il sorgente scritto da voi in less anche il file javascript che lo trasformerà in un file CSS e lo integrerà nella pagina.

<link rel="stylesheet/less" type="text/css" href="style.less">
<script src="less.min.js"></script>

Non preoccupatevi di dover imparare molte cose per poterlo utilizzare, un file CSS viene già compilato correttamente da LESS e vi basterà apportargli qualche modifica per sfruttarne le potenzialità.

Ora un esempio molto veloce e non esaustivo di quello che LESS può fare:

@arancio: #ebac20;
@rosso:   #d84227;
@larghezza:  20px;
@url-base:     "http://dominio.it/images/";

.rounded-corners (@radius: 5px) { 
   border-radius: @radius; 
   -webkit-border-radius: @radius; 
   -moz-border-radius: @radius; 
}

.box{
    border: 2px solid @rosso;
    background: url("@{url-base}logo.png") 0 0 no-repeat @arancio;
    .rounded-corners(20px);
    p { width: @larghezza * 2; }
}

Questo codice LESS produrrà il seguente codice CSS:

.box {
    border: 2px solid #d84227;
    background: url("http://dominio.it/images/logo.png") 0 0 no-repeat #ebac20;
    border-radius: 20px;
    -webkit-border-radius: 20px;
    -moz-border-radius: 20px;
}

.box p {
    width: 40px;
} 

Come potete vedere se per esempio utilizzate il colore arancio 50 volte nei vostri CSS ma un giorno vi svegliate e volete cambiare leggermente tonalità vi basterà cambiare il valore alla variabile @arancio senza dover utilizzare find and replace.

.rounded-corners (@radius: 5px) invece è un esempio di funzione che accetta come paramentro un numero di px (di default saranno 5) e semplifica il codice invece di dover ripetere tutte le volte le tre direttive per i bordi arrotondati per ogni browser.

Per evitare di dover scrivere per esteso tutti i percorsi CSS è possibile annidare i vari marcatori e LESS ve li scriverà automaticamente per esteso come nell’esempio p è descritto all’interno di .box.

Queste sono le principali caratteristiche, ma LESS ne mette a disposizione molte altre come gli @import, le operazioni, alcune funzione di javascript, funzioni sui colori, namespace e scope. Per scoprirle vi rimando alla pagina ufficiale da cui potete anche scaricare l’unico file che vi serve per cominciare ovvero less.min.js.

Usi Internet Explorer? Beccati la pubblicità. Usi IE6? pubblicità doppia

ORMAI è da qualche tempo che ho rinunciato completamente alla pubblicità sul mio sito, oltre al fatto che ci guadagnavo poco, l’ho fatto principalmente per questioni di pulizia del layout e per infastidire di meno i visitatori potenziali lettori (la pubblicità infastidisce è ovvio). Ma visto che ogni volta che sviluppo un sito devo passare parte del mio tempo a renderlo, non dico uguale a come viene visualizzato negli altri browser, ma almeno utilizzabile da Internet Explorer, e anche questo mi infastidisce parecchio, mi sembra quasi doveroso e moralmente giusto, per la legge del contrappasso, infastidire chi usa Internet Explorer. Continue reading

Tieni traccia e confronta nel tempo l’Alexa Rank di vari domini

PIU’ che altro per curiosità personale (visto che conta nulla) avevo intenzione di tenere traccia dell’alexa rank del mio sito, poi una cosa tira l’altra e quindi ho creato una mini applicazione per confrontare tramite dei grafici l’andamento dell’alexa rank fra vari domini se vi interessa per curiosità potete provarlo a questa pagina: alexa.gianlucacrema.com

Per ora ci sono circa 300 domini registrati e ogni giorno si aggiornano i dati dell’alexa rank, potete confrontare fino ad n domini contemporaneamente, non ho messo limiti (finche non va in crash la pagina). Potete aggiungere molto facilmente qualunque dominio vi pare e da quel giorno verra registrato l’alexa rank.

Può essere interessante vedere come nel tempo si modifica l’alexa rank. Tempo permettendo faro dei mini tutorial sugli script jQuery che ho usato per creare i grafici, l’autocomplete e sulla parte in php che grazie ai cron jobs ogni giorno alle 05.12 salva nel database i dati sull’alexa rank di tutti i domini registrati. Magari datemi qualche feedback qua nei commenti e se vi interessano i dati chiedetemi pure che ve li mando.

Compressione gzip senza il modulo apache mod_gzip

LA maggior parte dei servizi di shared hosting offrono la compressione gzip di default, come per esempio dreamhost dove al massimo è da disattivare non da attivare. Invece con lunarpages (che per la cronaca anche se non centra nulla ieri un attacco DoS lo ha fatto andare interamente down per un oretta) con il servizio base di shared hosting non consente di attivare il modulo di apache mod_gzip.

C’è un modo forse un po macchinoso ma comunque funzionale per ovviare a questo. Essendo che utilizzano suPHP è possibile tra le altre cose personalizzare il file di configuarazione php.ini per ogni cartella sul server. Ciò consente di abilitare zlib.output_compression ovvero l’estensione di PHP che a runtime “on-th-fly” al volo come recita il manule di php comprime l’html risultante da una pagina php prima di inviarlo ai browser. Per attivarlo quindi basta creare un file php.ini e scriverci:

zlib.output_compression = On
zlib.output_compression_level = 6

Per poter comprimere tutti i documenti, dai fogli di stile ai javascript, e non solo gli script php basta far processare a PHP tutti i file che vogliamo comprimere, pertanto andremo a scrivere nel file .htaccess

AddHandler application/x-httpd-php5 .css .html .js
suPHP_ConfigPath /home/username/public_html/

La direttiva AddHandler serve a far processare a PHP tutti i file con estensione .css, .html e .js potete aggiungere ogni estensione che vi pare, la seconda riga invece serve per specificare il percorso del file di configurazione php.ini, al posto di username va ovviamente il vostro username e dopo public_html potete specificare qualsiasi percorso dove sia presente un file php.ini.

Ora tutti i file prima di essere visualizzati verranno compressi, questo però può comportare dei grossi problemi, l’header di risposta per esempio di un foglio di stile potrebbe non essere più lo stesso, pertanto bisogna ristabilire gli header giusti. Un modo molto semplice è includere prima di ogni file questo script.

<?php
$path = pathinfo($_SERVER['SCRIPT_NAME']);
 if ($path['extension'] == 'css')  {
 header('Content-type: text/css');
}
if ($path['extension'] == 'js')  {
 header('Content-type: application/x-javascript');
}
?>

per farlo bisogna salvare questo script in un file denominato per esempio pre.php e aggiungere al file php.ini questa riga:

auto_prepend_file = "/home/username/public_html/pre.php"

Così ora i file con estensione .js, .css e .html prima verranno processati da php quindi compressi poi gli sarà restituito il giusto header e infine inviati al browser. Attenzione che se avete dell’xml all’interno di questi file tra i tag <?xml ... ?> verrà processato da php, per ovviare a questo basta aggiungere a php.ini il comando:

short_open_tag = 0

questo disabilita gli short tag <? ... ?> per php quindi come è giusto che sia tutto il codice php va messo assolutamente all’interno dei tag <?php ... ?>

Confronto tra Git, Mercurial e Bazaar

PERCHE’ limitare il confronto tra questi tre e non includere, per esempio, subversion (di cui ho scritto nell’Introduzione al controllo di versione)? Oltre che essere rilasciati tutti e tre sotto licenza GNU sono accomunati dall’appartenenza ad una tipologia particolare di software di controllo di versione. Git, Bazaar (bzr) e Mercurial (hg) sono DVCS (distribuited version control system) ovvero sistemi di controllo di versione nei quali ogni working copy locale contiene l’intera storia di tutte le modifiche apportate in tutte le revisioni precedenti. Questo consente di “navigare” tra le varie modifiche e revisioni senza dover interrogare il repository centrale che risiede solitamente su server remoti aumentando notevolmente la flessibilità.

Con DVCS in realtà viene a mancare l’idea stretta di repository centrale, ogni working copy è un repository, ovvio che per collaborazione tra più sviluppatori e per motivi di backup è sempre necessario un server remoto. Per vedere tutti i vantaggi di questa classe di VCS vi consiglio di visitare la relativa pagina di Wikipedia versione inglese.

Ma tra questi tre DVCS quale scegliere? Google nell’estate del 2008 ha già fatto e pubblicato un attenta analisi di confronto tra Mercurial e Git, con annessa discussione, per decidere quale software utilizzare assieme a subversion nel servizio code.google.com. Per la cronaca hanno scelto Mercurial avanzando una maggiore efficienza nell’uso del protocollo HTTP e di una minore difficoltà di approccio. Bazaar nato nel dicembre dell’anno precedente forse era ancora troppo acerbo per essere preso in considerazione ma ora è il terzo più popolare e sicuramente all’altezza degli altri due.

Lo scopo di questo post non è dire, questo è migliore di quell’altro, cosa che ritengo impossibile visto che parliamo di software supportati da grandi progetti e sicuramente equiparabili ma cercare di evidenziarne le differenze per aiutare la scelta a seconda delle diverse necessità.

  • Git è sicuramente più ostico per chi si avvicina per la prima volta a questo tipo di programmi, Mercurial e Bazaar sono sicuramente più semplici ad un primo approccio. Sopratutto per chi già usa svn si troverà sicuramente bene con Mercurial.
  • I benchmarck dicono che Git è più performante rispetto agli altri due nelle operazioni di commit, diff, e iniziallizzazione, Mercurial in adding e status, invece Baazar segue senza medaglie. Questi dati vanno presi con le pinze perchè a forza di rilasci e aggiornamenti tutti e tre tendono sempre ad inseguirsi equipareggiandosi quasi come prestazioni.
  • Anche come dimesione del repository vince Git a parità di operazioni sugli stessi file il repository occupa 92 MB rispetto ai 112 MB di bzr e i 179 MB di hg. Questo è dovuto anche dal prossimo punto:
  • Senza entrare veramente nei dettagli e parlandone molto con superficialità si può dire che Git tra diverse versioni dello stesso file archivia le differenze e non gli interi due file come accade invece con bazaar e mercurial. Questa è dovuto ad un differente progetto del sistema.
  • Git sarà più difficile da usare ma sicuramente offre molto di più e in certe cose è decisamente uno strumento potente. Ma non sempre potenti funzioni di branching, merging e tagging sono indispensabili, la seplicità di bazaar a volte può essere un grosso vantaggio.
  • Forse per lo stesso motivo per cui Google ha scelto Mercurial, ovvero la maggior compatibilità con il protocollo HTTP, in rete sembra più facile trovare servizi che offrono hosting gratuito per progetti open source basandosi su hg.
  • Git da parte sua ha github l’hosting per progetti open source che personalmente preferisco in assoluto, diretto concorrente di Google code.

Infine vi lascio con qualche risorsa per i tre DVCS di cui ho parlato. Se vi interessa avere altre infomazioni su questo confronto vi consiglio di visitare Wikipedia inglese, in particolare: Comparison of revision control software e Comparison of open source software hosting facilities

Voi quale sistema di controllo di versione utilizzate? per quale motivo?

Git

Comando: git
Nota storica: Sviluppato da Linus Torvalds che dice di averlo chiamato così perchè “I’m an egotistical bastard, and I name all my projects after myself. First Linux, now git” in inglese git vuol dire qualcosa tipo stupido. E’ scritto in C e Perl
Progetti che lo utilizzano: Linux kernel, GNOME
Applicazione grafica: Tortoisegit (Windows) gitX (Mac OS X)
Sito ufficiale: git-scm.com
Guida: guida ufficiale , libro “Getting Good With Git” in inglese a 19$
Cheat sheet: GitCheatSheet, gitcheatsheet.pdf
Hosting gratutito per progetti open source: github.com, projectlocker.com, sourceforge.net, freepository.com

Mercurial

Comando: hg
Nota storica
: software creato da Matt Mackall e rilasciato con lincenza GNU nacque inzialmente per essere eseguito su Linux, successivamente furono fatte versioni anche per Windows, 2.0. É quasi completamente scritto in Python
Progetti che lo utilizzano: OpenOffice, Mozilla, Symbian
Applicazione grafica: TortoiseHg (Estensione per Windows Explorer e Nautilius), Murky (Mac OS X)
Sito ufficiale: mercurial.selenic.co
Guida: Bellissima guida a mercurial hginit.com (in inglese) Libro con anche ebook gratuito: hgbook.red-bean.com (in inglese)
Cheat sheet: Mercurial-Cheatsheet-Adrian-v1.0.pdf
Hosting gratutito per progetti open source: code.google.com/hosting, sourceforge.net, BerliOS

Bazaar

Comando: bzr
Nota storica: Sponsorizzato dalla canonical il rilascio della prima versione risale al dicembre del 2007 ma la sua storia è molto più lunga e trae origine dal progetto Baz abbandonato da tempo. Anche questo è scritto in Python e C.
Progetti che lo utilizzano: Ubuntu, MySql, Emacs
Applicazione grafica: Bazaar Explorer (multi piattaforma: GNOME, KDE, Windows, Mac OS X)
Sito ufficiale: bazaar.canonical.com
Guida: Guida ufficiale in inglese
Cheat sheet: quick-start-summary.svg
Hosting gratutito per progetti open source: sourceforge.net, launchpad.net

Introduzione al controllo di versione

QUANTE volte scrivendo il codice di un qualsiasi sorgente vi siete accorti che il lavoro delle ultime due ore era del tutto sbagliato e avreste voluto tornare indietro al codice di due ore prima, oppure non riuscite a capire per quale modifica il codice non funziona più. Bè se vi siete trovati in questa situazione allora avete bisogno del controllo di versione.

Il controllo di versione, o version control (VCS), è un software per la gestione di versioni differenti di un qualsiasi tipo di informazione (disegni, sorgenti, libri). In particolare nel campo della programmazione si occupa di tenere traccia di tutte le modifiche apportate ai file sorgente di un progetto software, questo può benissimo essere un sorgente scritto in C oppure un applicazione web o più semplicemente un plugin di WordPress, ma potrebbe benissimo essere un libro che stiamo scrivendo.

Il controllo di versione tenendo traccia di ogni modifica apportata consente di ritornare facilmente a vecchie versioni, di ricordarci ogni modifica che abbiamo apportato e di lavorare su versioni differenti dello stesso sorgente.

Solitamente il controllo di versione si utilizza su architetture di tipo client server. Ovvero c’è un server che contiene i repository (la raccolta di tutti i dati) e i client da remoto ci accedono per scaricare la copia locale su cui lavorare. Una volta finite le modifiche si “ricarica” la copia locale nel repository in modo da archiviare e volendo anche condividere le modifiche. Il modo più veloce per accedere ai repository è tramite linea di comando ma per chi non ci si trovasse bene esistono anche delle interfacce grafiche.

Un altra importantissima caratteristica è il supporto alla stesura collaborativa tra più persone dello stesso progetto, con il controllo di versione è possibile condividere gli stessi file sorgente sempre aggiornati e visualizzare chi ha modificato cosa. Alcuni software semplicemente impediscono a più persone contemporaneamente di modificare lo stesso file (lock) altri invece offrono strumenti (come il merge) per consentire l’unione di modfiche contemporanee dello stesso file e di risolvere eventuali conflitti che ne scaturiscono.

Dopo quest’introduzione vi presento un non esaustivo decisamente “alla mano” glossario e qualche risorsa per Subversione il software di controllo di versione più diffuso. In realtà questo post mi serviva per introdurre il prossimo che pubblicherò, nel quale confronterò tre VCS ovvero Git, Mercurial e Bazaar.

Glossario

Alcuni termini da conoscere che accomunano più o meno tutti i software di controllo di versione.
Commit: operazione con cui si carica la working copy nel repository
Repository: archivio dove risiede il progetto e tutte le revisioni, attraverso il quale è possibile risalire a revisioni precedenti, solitamente ci si accede da remoto.
Working Copy: è la copia locale del progetto a cui stiamo lavorando
Revision: è un numero che identifica ogni commit
Merge: è l’unione di modifiche concorrenti dello stesso file
Checkout: azione che si compie per scaricare in locale la working copy
Tagging: dare un preciso nome di versione ad una revisione
Branching: duplicare i dati sotto controllo di versione per portare avanti sviluppi paralleli dello stesso progetto
Log: registrazione cronologica di ogni operazione effettuata
Diff: comando per visualizzare le differenze tra due diverse revisioni

Subversion

Comando: svn
Nota storica: Naturale sucessore di CVS è nato nel 2000 ed è rilasciato sotto la stessa licenza di Apache. E’ forse il software per il controllo di versione più diffuso. Dal 2009 è stato incluso nei progetti dell’Apache software foundation.
Progetti che lo utilizzano: KDE, GCC, PHP
Applicazione grafica: TortoiseSVN (Windows) SvnX (MAC) kdesvn (KDE)
Sito ufficiale: subversion.apache.org
Guida: libro “Controllo di versione con Subversion” (quasi interamente tradotto in italiano)
Cheat sheet: Subversion-cheat-sheet.png
Hosting gratutito per progetti open source: code.google.com/hosting, projectlocker.com, freepository.com, sourceforge.net, BerliOS
Altro: molto comodo Subclipse il plugin per integrare SVN in Eclipse.

Brevissimo Subversion tutorial

HO da poco caricato nel repository di wordpress.org la nuova versione aggiornata del mio plugin FlickrRSS RU ed essendo passato un po di tempo dall’ultima volta che l’ho fatto, ci ho impiegato qualche minuto per ricordarmi bene la procedura. Ecco quindi una brevissima guida per ricordami bene come si fa la prossima volta. In realtà questa guida va benissimo per qualsiasi progetto utilizzi subversion come software di controllo di versione.

Per prima cosa se non avete già una copia in locale sincronizzata (o non vi ricordate dove sia) bisogna scaricare il repository, spostatevi nella cartella dove lo volete scaricare e create una cartella in cui metterlo:

$ mkdir flickrrssRU

poi lanciate il comando per copiarlo tutto in locale

$ svn checkout http://svn.wp-plugins.org/flickrrss-ru flickrrssRU 

l’output sarà qualcosa di simile a questo:

A    flickrrssRU/trunk
A    flickrrssRU/trunk/flickrrssRU.php
A    flickrrssRU/trunk/screenshot-2.png
A    flickrrssRU/trunk/flickrrssRU-settingspage.php
A    flickrrssRU/trunk/readme.txt
A    flickrrssRU/trunk/screenshot-1.png
A    flickrrssRU/branches
A    flickrrssRU/tags

spostatevi nella cartella della copia locale, per esempio nel mio caso

$ cd /var/www/flickrrssRU 

e controllate che sia aggiornata all’ultima versione sul repository. Nel caso ci siano più persone che lavorano allo stesso plugin (più in generale allo stesso progetto) potrebbe essere che non lo sia, ovviamente qualcuno potrebbe aver modificato il progetto. Se invece l’avete appena scaricato sarà sicuramente aggiornato.

$ svn update

se state per rilasciare una nuova versione del progetto, e non dovete solo apportare delle modifiche minori, prima di tutto bisogna taggare la versione attuale in modo da renderla fissa nel tempo. Per esempio nel caso la nuova versione aggiunga delle nuove funzioni, a qualcuno potrebbero non interessare, o un altro caso molto più comune è per la compatibilità, se nella versione che state andando a rilasciare sono state fatte delle grosse modifiche potebbe non funzionare più con alcune applicazioni, pertanto qualcuno in questi casi vorrà comunque continuare ad utilizzare le vesioni precedenti.

Per fare questo copiamo il contenuto della cartella trunk (quindi l’attuale versione del progetto da taggare) in una sottocartella di tags nominata con la versione che stiamo andando ad “archiviare”

$ svn copy trunk tags/0.2 

ora possiamo aggiornare e modificare i file che si trovano nella cartella trunk con i file della nuova versione. Ricordatevi se state rilasciando una nuova versione di un plugin per WP di modificare i numeri di versione anche all’interno del file readme. Una volta che avete inserito nella cartella trunk i file aggiornati se avete aggiunto dei nuovi file che prima non c’erano dovete lanciare questo comando:

$ svn add trunk/nome_nuovo_file

oppure se dovete eliminare dei file:

$ svn delete trunk/nome_file_da_rimuovere

Ora per finire bisogna caricare tutte le modifiche effettuate ovvero effettuare il COMMIT. Con esso tutte le modifiche effettuate sui dati vengono memorizzate. Il -m serve per poter personalizzare il messaggio di log ovvero il testo messo tra virgolette, è un aiuto quando si va a vedere il log del repository per ricordarsi le modifiche che sono state effettuate ad ogni commit.

$ svn commit -m "tagging version 0.2"

Comandi Subversion

Vi lascio la lista dei principali comandi di subversion (rigorosamente da lanciare preceduti dal comando svn) con una brevissima descrizione, per vedere bene come funzionano basta lanciare il comando:

$ svn help nome-del-comando

i comandi scritti tra parentesi tonde sono gli equivalenti meno user-friendly ma più veloci

add Aggiunge file e directory al controllo di versione
blame (praise, annotate, ann) Restituisce il contenuto dei file specificato con varie informazioni
cat Restituisce il contenuto dei file specificato
checkout (co) Copia in locale una working copy
commit (ci) Trasmette le modifiche della copia locale al repository
copy (cp) Copia file o cartelle da un sorgente ad una destinazione
delete (del, remove, rm) Rimuove file o cartelle dal controllo di versione
diff (di) Mostra le differenze tra due revisioni
export Crea una copia senza metterla sotto controllo di versione
help (?, h) Descrive l’uso di un comando
import Esegue il commit di un percorso non sotto il controllo di versione
info Mostra varie informazioni
list (ls) Elenca il contenuto della directory nel repository
lock Blocca cartelle e file nel repository dalla modifica da parte di altri utenti
log Mostra i log di un file o dell’intero repository
merge unisce varie modifiche dello stesso file
mergeinfo mostra le info relative al merge
mkdir crea una cartella nel repository
move (mv, rename, ren) sposta o rinomina file e cartelle
status (stat, st) Mostra lo stato attuale tra la copia locale e il repository
unlock Sblocca i percorsi o i file bloccati con lock
update (up) Aggiorna la copia locale con quella del repository

Ed ecco un “cheat sheet” per subversion:

flickrRSS RU – WP Plugin for Unlimited* and Random Images from Flickr to your blog

Integrate Flickr photos into your site. Random option and limit of 500 images. It supports user, set, favorite, group and community photostreams.

Contributors: Gianluca Crema, eightface
Donate link: PayPal
Official Page on wordpress.org: wordpress.org/extend/plugins/flickrrss-ru
Tags: flickr, photos, images, sidebar, widget, rss, random
Requires at least: 2.6
Tested up to: 3.0
Stable tag: 1.0

Description

This plugin allows you to easily display Flickr photos on your site. It supports user, set, favorite, group and community photostreams. The plugin is relatively easy to setup and configure via an options panel.

Avoids the limit of 20 images flickr feed to up to 500 images, implements a random function.

Derived from the flickrRSS plugin created by eightface adding RU functions (Random and Unlimited).

Installation

  1. Put the flickrRSS RU files into your plugins directory
  2. Activate the plugin
  3. Configure your settings via the panel in Options
  4. Add <?php get_flickrRSSRU(); ?> somewhere in your templates or adding the flickrRSSRU widget to your widget area.

Frequently Asked Questions

Can I get random images from my stream?

Yes, Just enable the Random option in the settings panel.

How do a I get borders between photos?

You need to edit your CSS file. There are plenty of tutorials online, you may find some help in the forum.

Why aren’t any photos showing up?

Sometimes it can take a little while to kick in, have patience. Flickr may possibly have been down.

Will it work with video?

Yes, videos will be displayed as a thumbnail image. You’ll need to click through to flickr to play it though.

Screenshots

Changelog

1.0 Modifica della parte più grossa del codice, risolto un bug nei link alle foto dei set

0.2 Initial release

Feedback and Support

For Feedback and Support leave a comment to this post or contact me from contact page. I’ll do my best to respond.

Soon I will create a forum.

Advanced

The plugin also supports a number of parameters, allowing you to have multiple instances across your site.

  1. 'type' => 'user' – The type of Flickr images that you want to show. Possible values: ‘user’, ‘favorite’, ‘set’, ‘group’, ‘public’
  2. 'set' => 'set_id' – Optional: To be used with type = ‘set’
  3. 'id' => 'user_set' – Optional: Your Group or User ID. To be used with type = ‘user’ or ‘group’
  4. 'random' => false – Optional: Enable the random images
  5. 'num_random' => 20 – Optional: Number of images which allows choosing randomly
  6. 'num_items' => 4 – The number of images that you want to display
  7. 'before_list' => ' ' – The HTML to print before the list of images
  8. 'html' => '<a href="%flickr_page%" title="%title%"><img src="%image_square%" alt="%title%"></a>' – the code to print out for each image.
    Meta tags available: %flickr_page%, %title%, %image_small%, %image_square%, %image_thumbnail%, %image_medium%, %image_large%
  9. 'default_title' => "Untitled Flickr photo" – the default title
  10. 'after_list' => ' ' – the HTML to print after the list of images

Example 1

<?php get_flickrRSSRU(array(
'num_items' => 50,
'type' => 'public',
)); ?>

This would show the 50 most recent community photos.

Example 2

<?php get_flickrRSSRU(array(
'set' => '72157620600672300',
'num_items' => 25,
'type' => 'set',
'random' => true,
'num_random' => 150
)); ?>

This would show 25 random picture from the 150 most recent thumbnail sized photos from the specified set.