Archives du mot-clé codage Web

Frameworks de thèmes pour WordPress

Bon, on recommence.

À peine ai-je découvert Sandbox et commencé à travailler dessus que je me rends compte que je suis en 2008. Et qu’en 2009, les theme framework ont beaucoup évolué.

J’ai donc beaucoup cherché et hésité. La liste ci-dessous est le résultat de mes recherches.

  1. Première génération : K2. Il introduit l’idée de « super-thème » (advanced template) et de thèmes enfant (styles). Il n’a pas été suivi (il continue à être développé, mais il n’attire pas les foules ou les inspirations).
  2. Deuxième génération : Sandbox. Il devient la base de nombreux développements et, en fait, est le père de (presque  ?) tous les frameworks de thème actuels. Peut-être doit-il son succès à son dépouillement, qui incite justement à regarder le framework comme un framework, et non comme un thème avec des fonctions en plus.
  3. Troisième génération : Carrington (le plus puissant apparemment, il lorgne clairement sur le CMS, Hybrid, Thematic, Vanilla (mon préféré sur le papier), WP Framework, et plein d’autres. Le terme styles de K2 est désormais appelé thèmes enfant (child themes)
  4. Quatrième génération : The Future of WordPress Themes 2009.

J’ai hésité à installer Vanilla, qui me semble le plus intéressant (tout comme le logiciel de forum éponyme), mais il n’est pas finalisé. Je souhaitai aussi utiliser Carrington/JAM (une version dépouillée et améliorée de Carrington/Blog), mais elle était vraiment trop barebones pour moi (même le PHP ne marche pas en l’état).

Donc, je pars de Carrington/Blog et je virerais la CSS.

flattr this!

WordPress, arrête de penser à ma place !

D’après mes essais (texte minimal, fichier CSS vidé), WordPress force l’affichage des liens en tant que tel, même quand on ne veut pas. Exemple pour le prouver, une CSS que je voulais donner « telle qu’elle apparaît dans BBEdit » (mais en conservant un vrai lien) :

/* http://david.latapie.name/blog/765-modifications-esthetiques */

[hreflang]:after	{
    background:transparent;
    color:#666;
    content:"\a0[" attr(hreflang)"]";
    font-size:smaller;
    text-decoration:none
}

Voici le code pertinent : <a href="#" style="color:inherit;text-decoration:none">bla</a>

J’ai même essayé avec du !important (ce qui est généralement une mauvaise pratique), rien n’y fait.

Je vous met au défi d’empêcher WordPress de penser à votre place. Et je suis preneur de tout plugin.

Je suis loin d’être le seul à m’en plaindre (ce lien traite de HTML, pas de CSS, mais j’ai aussi eu ce problème avec du HTML.

flattr this!

Improving Leopress theme for WordPress

I love the Leopress-fr theme (adapted from Leopress 1.0), but it has several issues, some so fundamental I can neither use it nor bugfix it.
  • background is not fixed. It fixed it (pun intented): html {background:attachment:fixed}
  • I favour justify over left when it comes to text-align. I fixed this too: .post .entry {text-align:justify}
  • not widget-ready. Quite important for me and I don’t have the proficiency to fix it.
  • does not display tags in posts. Very important for me and I don’t have the proficiency to fix it.
  • ignore the a element in post! Fundamental and I don’t know how to fix this.
  • no bullet for bulleted lists. Strange, since the code is there. I have the intuition it comes from the same problem with the lack of anchors. Fundamental and I don’t know how to fix this.
The last twos problem may be related to this theme not being WordPress 2.8-ready. If, by any chance, you have some spare time…

flattr this!

Individualiser les formats d’entrée dans Drupal

Dans Drupal, je croyais que le filtrage HTML (format d’entrée ; /admin/settings/filters/ pour reprendre la terminologie Drupal) ne pouvait pas être individualisé, mais juste personnalisé. Ainsi, si on active Filtre HTML, seul un ensemble limité de HTML est autorisé. Là où était mon erreur, c’était de croire que cet ensemble limité était défini pour l’ensemble du site. Que nenni ! Uniquement pour le format d’entrée courant. Joie ! Un exemple pour mieux comprendre :
  1. Texte brut — à la commentaires en mode texte de Dotclear
  2. XHTML filtré — un poil de HTML est autorisé — à la commentaires wiki de Dotclear, mais sans wikibarre :(
  3. XHTML assisté — pour les utilisateurs authentifés ; ils peuvent utiliser tout le XHTML qu’ils veulent (il faudrait que je vérifie ce que ça donne par rapport à l’insertion de styles CSS)
  4. XHTML libre— pareil mais sans les outils plus intelligents que l’utilisateur (ainsi, un retour à la ligne après 72 caractères, typique des geeks, ne sera pas interprété comme un retour chariot). Les gardes-fou (balise non fermée) sont cependant toujours présents.
Dans cet exemple, je ne savais pas que l’on pouvait avoir à la fois 1 (HTML filter/rien) et 2 (HTML filter/<a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>). Source : Raw text filter.

flattr this!

Le blog parfait

Ceci est la traduction d’un billet d’Anne van Kesteren (développeur Opera et gourou HTML/CSS), The perfect weblog system (dernière modification : 18 août 2004) — j’ai d’ailleurs contacté l’auteur avec un résumé en anglais de comment DotClear se positionne sur tout ça, sans réponse de sa part pour le moment. Au niveau du fond, j’ai mis les balises et attributs en minuscules, compacté le bla-bla (si vous pensez que j’ai trahi la pensée, suivez le lien d’origine), ajouté une table des matières et changé le premier niveau de puces par un titre de section (en XHTML 2, la sémantique ne serait pas perdue dans l’opération, mais bon…). J’ai aussi ajouté quelques notes au fil du texte et, en seconde partie, une comparaison avec l’état de ce que fait DotClear2 β3.

Lire la suite

flattr this!

Les chiffres romains Unicode

Plusieurs billets de ce blogue utilisent des chiffres romains.

ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩⅪⅫ ⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹⅺⅻ ⅬⅭⅮⅮⅯⅼⅽⅾⅿↀↁↂↃ

À partir d’aujourd’hui[1], ce ne sera plus le cas (et, quand j’aurais le temps, je modifierais rétroactivement les billets incriminés. Pourquoi ?

Parce que les chiffres romains ne sont pas des caractères, mais des glyphes.

Pour rappel, un glyphe est une forme graphique (voire sonore, tactile…), alors qu’un caractère est l’unité de sens qu’il y a derrière. Pour reprendre la terminologie de Saussure, un glyphe est un signifiant, un caractère est un signifié.

Jusqu’à aujourd’hui, je croyais que, pour les chiffres romains, ce n’était pas le cas. Que même si, sur le papier (ou la pierre), un chiffre romain est identique à la lettre latine dont il s’inspire, il s’agissait fondamentalement de deux caractères différents (le XXe siècle n’est pas le « ixixième » siècle, mais le vingtième siècle). Ceci était d’autant plus justifiable qu’un tel cas de confusion entre glyphe et caractère a des antécédents : l’alpha majuscule (Α) a généralement le même glyphe que le A majuscule (A). Lire à ce sujet B, В, β, ß.

Voici pourquoi j’ai changé d’avis :

Lire la suite

flattr this!

Differences between Redirect and Rewrite

  • Because I am craving for this for months;
  • Because I only found kilometres-long texts about use, performance, advanced manipulation… but no simple thing at all;
  • Because I like (useful) lists.
Here is a short summary of various redirect rules and their uses.

Redirect

(1) Redirect, RedirectTemp, Redirect temporary or Redirect 302
URL 1 is redirected to URL 2; it is visible in the address bar[1].
(2) RedirectPermanent or RedirectPermanent or Redirect 301
Same as (1), but permanent[2].
(3) Redirect Seeother or Redirect 303
Temporary change, do not change the index. Seldom used.
(4) Redirect Gone or Redirect 410
The page has disappeared and nothing will replace it. Think of it as a "voluntary 404".
(5) Redirect xxx
Redirect with the corresponding code.
(6) RedirectMatch
Same as (1), but with regular expressions[3].
(7) RedirectMatch Permanent
Same as both (2) and (6)[4].
Notice how (6) and (7) differ from the other: they do not just send a code, they change the behaviour of the syntax. Consequenty, it is not possible (AFAIK) to use regexps with other than 301.

Rewrite

Rewrite is different and not necessarily better. But in any case, it is more complex (and I won’t delve into it for now). The main differences between Redirect and Rewrite are:
  • Redirect uses mod_alias; Rewrite uses mod_rewrite — except for old Apache version, where both rules use mod_rewrite. Big deal.
  • Rewrite hides the redirection to the user - this means the address stays the same in the address bar. That is the main difference between Redirect and Rewrite.
  • Rewrite is the only one able to cope with dynamic URL (you know, those damn question marks in QUERY STRING). Not even RedirectMatch can do it (AFAIK).
Redirect is appropriate when you want people to remember the new address; You may be sure they will copy the good address and that will save you some CPU cycles in non redirecting anymore. On the contrary, Rewrite is appropriate when you want the address to stay the same/not to be visible; A good example is hiding the architecture (/wordpress/, /wiki/…). Ultimately, using one or the other is not a technical consideration but more of a human and strategic one.

Examples

Below are examples I use to change domain.tld/images/foo to domain.tld/dotclear/public/images/foo (I actually only use the fourth one). The leading circumflex (^) is for forcing the matching string to be at the begining of the address.
  • Redirect ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
  • RedirectPermanent ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
  • RedirectMatch ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
  • RedirectMatch Permanent ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
To be completely accurate, I must say that Rewrite is able to do most, if not all, of what Redirect may do, thank to the flags. But that would be another topic I prefer not to speak of here.
  1. Which is a good idea in some contexts; Error code 302.
  2. Error code 301; search engine should update their index (but Google does not).
  3. Don’t use it if you don’t need it: regexp parsing requires CPU cycles, even when there is no actual regexp to parse.
  4. That is, the resulting regexp-powered redirections are permanent (error code 301).
Ils en parlent mais ne me le disent pas, les petits cachottiers :

flattr this!