Pixelastic

Nowadays, when I'm developping a new website, I almost always ended using parts and bits of the previous website I've done. All my websites are based on the same framework (cakePHP) that I have itself updated with its own CMS (Caracole, more on that later).

Caracole is made of several little plugins, each one of them focusing on a simple task (like handling 404 errors, adding a recycle bin, draftable elements, SEO-friendly url, and so on).

I've also updated each one of this plugins to BitBucket, allowing me to easily commit changes and clone new version from one project to another.

But very often, when working on a specific project, using a specific plugin I think that I can update the plugin (be it either by adding a new feature or fixing a bug I've discovered). In that case, I want my changes to be added to both the plugin (on BitBucket) and the project I'm working on at the moment.

To do that, I had to struggle my way with Mercurial because nested repositories (called subrepos) is not a trivial setup.

Setting up subrepo with Mercurial :

Let me show you the classical and easy way to achieve that :

First, let's say you have your main repo. You go in the directory where you want to add your subrepo and you either create it using hg init or hg clone.

You then go back to your main repo root and edit the .hgsub file (if you don't have this file yet, just create it). Add the following line to the .hgsub :

path/to/your/subrepo = path/to/your/subrepo

Now, on every subsequent commit Hg will be aware that your repo is holding a new subrepo. If you omit this line, Hg will not allow you to commit complaining about a repo inside an other repo.

You can now safely commit your main repo, or your subrepo independently.

Now, let's see the edge case.

Changing a classical sub directory into a subrepo

The classical example above is what you can find in the Mercurial help pages. It wasn't that helpful for me because my setup was a little different and it was causing Hg a lot of trouble.

I was not creating a new subrepo, nor cloning a new one. I had sub diretcory of my main app, that I wanted to change into a subrepo. My sub directory was named 'myplugin' and I had a repo of that name hosted on BitBucket.

So I tried to delete my existing 'myplugin' directory, and clone the 'myplugin' from BitBucket, edit the .hgsub and commit but Hg aborted the operation, complaining about the repo in repo file structure.

After a lot of testing, and cry for help, I finally managed to get it to work. The workflow is almost the same, with one little new step.

Deleting the 'myplugin' folder wasn't enough. I had to tell Mercurial to completly remove this files from its index. Using TortoiseHg, I was able to do that by right clicking on the folder, and then choosing 'TortoiseHg > Remove Files'. Then I had to commit those changes, officially telling Mercurial to forget this files, and putting it in a state where those files aren't there at all.

Then only was I able to clone my repo from BitBucket, edit the .hgsub file and commit my main repo.

Well, it's been one month and a half now that I've put my freelance activites on hold. I'm in contract with a big company to develop an internal application.

The purpose of the application is really interesting, the guy I'm working with is too, but the language I have to use as well as the all-administrative thing of big companies like that is... well... let's just say I LOVE being a freelancer PHP developper.

One more month and a half and it will be over. I allready have learn a lot about metadatas in general and particularly Exif, Iptc and XMP. I've also learned a little about Coldfusion. Enough to know that I won't work with that language again, unless I'm forced too.

In the remaining week, I'll also learn EXTJs, and this part seems promising. I guess leaving jQuery and its easy syntax will be hard at first, but all the data handling of EXTJs seems really powerful.

Anyway, when that contract will be over, I'll be back to Caracole and I have so many ideas of features and whole websites that I want to create...

I would like to make the admin panel of Caracole the one thing an administrator would have to check to see if everything is going well on its website. I allready have an extended PHPInfo() highlighting possible misconfiguration but I want to push that further by integrating Google Analytics, checking the Gmail inbox associated as well as integrating the PHPSec library.

In the future I also plan on creating a photography website for Street Art and graffitis, with gelocalisation, metadatas saving of the author and place, possibility to upload photo directly from a mobile phone, etc

The old ideas about my own personal website, a quizz website, or one for rating driver's ed are still in my mind. Wait and see.

Cela faisait quelques temps que je souhaitais ajouter une gestion des flux RSS à Caracole. J'ai donc recherché du coté du RssHelper intégré à cakePHP et l'ai quelque peu modifié pour qu'il s'adapte à mes besoins.

En effet, il manquait selon moi quelques fonctions extremement importantes pour la génération d'un flux complet, par exemple la possibilité de spécifier des attributs aux différents noeuds, ou encore de passer le contenu entre balises <![CDATA[]]>.

Mais surtout la possibilité d'ajouter des noeuds de façons récursive, la fonction RssHelper::item() ne permettant d'ajouter des noeuds qu'à un seul niveau.

Bref, j'ai revu tout cela dans ma propre version du Helper, avec une autre fonction pratique pour ajouter un thumbnail à un post. Pour voir ce que cela donne, et il vous suffit de vous abonner aux flus disponibles sur les pages du blog ou sur la page Réalisations

J'ai découvert la syntaxe d'un flux RSS il y a seulement quelques jours, et je n'ai testé le résultat qu'avec Netvibes, je pense donc qu'il me faut me livrer à quelques tests supplémentaires.

En tout cas, il me suffit maintenant d'ajouter une variable $rssFeed à un modèle pour qu'un flux RSS lui soit automatiquement généré (on peut préciser bien sur les informations devant être affichées pour chaque modèle). Voila qui encore un pas de plus pour Caracole :)

Attention : Ce post n'est plus d'actualité. Je n'utilise plus du tout cette technique pour masquer les adresses mails car elle bloquait complétement la lisibilité aux personnes sans Javascript. Je n'ai pas encoe trouvé de meilleure alternative pour le moment, néanmoins.

Pour faire suite au billet précédent, un autre problème que j'ai rencontré dans le développement des sites était un moyen sûr d'empecher qu'une adresse mail exposée sur un site ne soit récupérée par des robots crawlers et ne deviennent la cible de leurs spams.

Je parse donc chaque texte affiché afin de remplacer les adresses mails par une version cryptée, que Javascript décryptera à l'affichage. A chaque affichage la clé de cryptage est différente. Bon, l'algorithme de cryptage est extremement simple, c'est juste une permutation alphabétique, chaque lettre est remplacée par une autre. Et la clée est indiqué dans l'attribut title de mon code généré.

Il suffit d'étudier le Javascript pour réussir à comprendre comment décrypter les mails, mais cela demande que le robot ai intégré mon codage dans ses paramètres, ce qui n'est à priori pas le cas. Et quand bien même se serait le cas, je changerai la façon de crypter la clé.

Jetez un oeil au code source de cette page si vous le souhaitez pour voir comment cette adresse : blabla@somewhere.com est écrite.

Cela devrait être quelque chose de la forme :

<span 
	title="97tasbw84fv6_q3pn5yirchya15nq.p9b_jziggtc40lfolwxxk@meo26m70zj2d-sur@hev8u1-dk.3" 
	class="protectFromSpam">
	
	<span class="noscript">
		<span class="icon icon_notice"></span>
		Cette adresse mail est protégée contre le spam, vous devez activer Javascript pour pouvoir la voir.
	</span>
	
	<span class="cryptedMail">ageh9gxvw1bag4342e</span>
	
</span>

Bon alors bien sur, cela nécessite Javascript activé, c'est un gros défaut, je l'admets. Un message permet de ne pas laisser l'utilisateur sans JS dans l'incompréhension, mais ça reste problématique malgré tout. Je n'ai pas réussi à faire mieux pour le moment.

Les trois derniers sites que j'ai fait avec Caracole avaient tous un formulaire de contact (nom, mail et texte, pour contacter le propriétaire du site).

Et tous les trois se sont fait spammer rapidement une fois que le site est arrivé dans les moteurs de recherche. J'ai donc cherché moyen d'empecher cela, une façon de detecter les spammeurs.

Alors, il existe bien sur Akismet, qui marche du tonnerre, mais qui est payant pour un usage professionnel, j'ai donc d'abord cherché du coté des solutions gratuites.

Il y a le projet reCaptcha, qui en plus d'empecher le spam, permet d'aider la numérisation de vieux livres, donc une assez bonne idée mais qui ne semble pas disponible en français. C'est malheureusement un impératif sur les sites que je développais.

J'ai donc plutot retourné le problème dans ma tête et cherché un moyen facile et ingénieux de faire la différence entre un humain et un bot. J'ai finalement opté pour un champ caché au sein du formulaire qui doit absolument rester vide. Un bot le remplira automatiquement, un humain le laissera vide.

J'avais tout d'abord mis ce champ en type="hidden" et cela semblait fonctionner, mais de plus récents spams me l'ont fait passer en  display:none par CSS et je n'ai pas eu de nouveau spam depuis. Je continuerai de peaufiner le système jusqu'à ce que je trouve un blocage parfait ou que j'en ai marre et que je me tourne vers Akismet :)

Pour le moment, je loggue toutes les demandes de contact avec les informations du Header, afin d'identifier certains patterns qui pourraient me permettre de trouver plus facilement les spammeurs dans le lot.

Je viens de rajouter une petite fonctionnalité sur Caracole qui permet d'exporter une liste d'adresses mails (actuellement les personnes souhaitant s'abonner à une newsletter) dans un format exploitable par les logiciels de messagerie et les webmail.

La liste peut être exportée sous format vCard, ou encore CSV exploitable par Outlook ou GMail.

En plus de son interface d'administration complète, Caracole permet un mode d'édition rapide directement accessible depuis le coté front-end des sites, pour corriger rapidement un titre ou un coquille qui se serait glissée quelque part.

Grâce à jQuery et cakePHP, cette fonctionnalité est très simple à utiliser. Il suffit pour cela d'avoir les droits d'administration sur le site que l'on veut modifier. Il suffit ensuite d'y naviguer avec un navigateur assez récent (cela signifie que IE6 n'y est pas convié) et s'affichera alors automatiquement en haut à gauche de l'écran un petit switch qui permet d'activer ou de désactiver en un clic le mode édition.

Lorsque le mode d'édition est activé, il suffit de cliquer sur une zone que l'on veut modifier pour la transformer automatiquement en champ de formulaire modifiable (avec intégration de tinyMCE pour les grands textes). Il suffit alors de modifier le texte exactement comme on peut le faire dans l'admin et de valider. La modification est prise en compte automatiquement.

Coté développeur, il suffit d'ajouter une class="editable" ainsi qu'un id formé de la forme "controller-champ-id". Ainsi id="posts-text-12" identifiera le champ "text" du 12e post.

C'est extremement pratique pour modifier des fautes de frappe, ou faire des tas de petites modifications, je m'en sers énormément et c'est un pas de plus pour faciliter l'administration à l'utilisateur final.

Le référencement est une des préocupations principales de nos clients, tous veulent savoir si avec le produit qu'on leur propose ils seront en mesure d'être les premiers dans les résultats Google.

Bien qu'il n'existe pas de recette miracle pour parvenir à ce résultat, certaines sociétés sont spécialisés dans ce business et déploient des trésors d'ingéniosité pour réussir à faire grimper les pages de leurs clients dans les index des moteurs.

Mais c'est un boulot à part entière, et ce n'est pas le nôtre. Nous faisons des sites web, à chacun sa spécialité.

Malgré tout, il existe plusieurs bonnes pratiques qui permettent d'obtenir de bons résultats sans trop d'efforts, et Caracole s'en sort pas trop mal de ce coté là.

Tout d'abord il tire parti de la façon dont les urls sont gérées par cakePHP, et donc aucune url ne contient de paramètre de la forme ?foo=bar&action=foobar qui sont très mal indexées. Chaque page possède donc sa propre url unique. Les méthodes d'url rewriting proposées de base par cakePHP sont très puissantes et font déjà une très grosse partie du travail.

Dans la même veine, il est possible de définir des 'slugs' pour chaque élément, un slug permet de donner un identifiant à chacune des pages, ce qui signifie qu'au lieu de retrouver un élément par son id dans l'url (un simple nombre, qui ne donne pas d'indication sur le contenu), on peut à la place le remplacer par un slug (du genre 'services', 'nous-contacter', etc). Cela donne des urls du genre /services.html, /posts/1:mon-premier-post, etc

Cela facilite le référencement des pages car des mots clés se rapportant au contenu de la page peuvent déjà être mis dans l'url, qui est une place privilégiée.

Ici encore, il suffit d'ajouter un champ 'slug' dans la table correspondante au modèle pour que celui-ci soit automatiquement généré à partir du nom (il est bien sur possible de le modifier si besoin).

Caracole est aussi doté d'un système de génération automatique de sitemap (le plan du site). Celui-ci est généré en deux versions, une version html pour vos visiteurs, et une version XML (qui indique les fréquences de réactualisations ainsi que les dates de dernière modification) pour les moteurs.

Et pour finir, je vais passer rapidement sur les essentiels : balise <title> et meta description différents pour chaque page, fichier robots.txt, texte alternatif sur les images et accessibilité du markup HTML mais bien sur, Caracole se charge de tout cela aussi.

Dans la lignée du principe de brouillon j'ai aussi ajouté une fonction de "Corbeille". Ca fonctionne exactement comme celle du bureau de Windows qu'on est bien content d'avoir quand on a eu la main un peu généreuse dans les fichiers à supprimer.

Elle fait office de sécurité et les éléments soit-disant supprimés ne sont pas réellement effacés instantanément, ils passent dans une corbeille intermédiaire. A partir de là, si on se rends compte qu'on a fait une bétise, on peut toujours les restaurer à leur état d'origine. Ou alors vider la corbeille de temps en temps pour faire de la place.

Exactement de la même façon que pour les brouillons, il suffit ici d'ajouter un champ 'is_deleted' à la table du modèle correspondant pour lui ajouter la fonction de corbeille, Caracole se charge du reste.

Les éléments supprimés ne sont plus retournés par les fonctions de recherche habituelle, à moins de préciser l'option 'includeDeleted'.

Une des fonctionnalités les plus pratiques de Wordpress, c'est de pouvoir enregistrer un billet comme brouillon lorsqu'on ne l'a pas terminé. Ca permet d'y revenir plus tard et de le garder dans un coin sans qu'il ne soit perdu.

J'ai ajouté cette fonctionnalité à Caracole hier, et elle peut s'appliquer à n'importe quel modèle (actuellement je l'ai mise sur les pages et les billets de blog uniquement, mais comme vous allez le voir, c'est très facile à ajouter pour n'importe quel modèle).

Une case à cocher "Enregistrer comme brouillon" permet d'enregistrer l'élement comme brouillon, cela signifie qu'il ne sera plus visible sur le site tant qu'il restera à l'état de brouillon.

Pour le développeur, c'est très simple à utiliser, il suffit de rajouter un champ 'is_draft' dans la table correspondante au modèle et Caracole se charge du reste. Les brouillons ne sont plus retournés par les recherches, à moins de préciser 'includeDraft' dans les options de recherche, ce qui permet de garder le code le plus clair possible.

Dans l'admin, les brouillons restent bien sur visibles (bien qu'indiqués de façon légerement différente), et il suffit d'aller décocher la case pour les publier réellement.