symfony 1.4 : gérer les profils complets des utilisateurs

Bon, encore un combat de gagné !

On a tous eu le problème (oui, nous, les développeurs d’application web) : gérer les utilisateurs ! Ajout, suppression, modification, inscription, validation, profil, et j’en passe.
Donc je vous livre ici une petite expérience avec sfDoctrineGuardPlugin et sfForkedDoctrineApplyPlugin, deux plugins symfony 1.4 que j’ai utilisé pour me créer mon petit gestionnaire de profil personnalisé.Pour faire simple, voici le scénario à tester :

  •  installer symfony 1.4 : jusque là rien de sorcier
  •  installer sfDoctrineGuardPlugin, qui permet de gérer les utilisateurs à partir de Doctrine
  • installer sfForkedDoctrineApplyPlugin qui permet l’ajout de fonctions du type « register », confirmation d’email, etc., et de gérer un profil utilisateur
  • configurer ce dernier en ajoutant des champs dans votre schema.yml (voir la doc du plugin)
  • générer les modules admin (et l’application backend si ce n’est déjà fait) pour sfGuardUser
  • refaire les build des classes avec symfony doctrine:build –all-classes
  • configurer les routes si besoin est
  • effacer le cache

A la suite de quoi, vous croyez, tout content, pouvoir générer les modules admin generator avec les champs supplémentaires : eh bien non ! Ca serait trop simple !

En gros, et pour faire simple, le forkedPlugin ajoute une table pour gérer les profile : sfGuardUserProfile, et on ne peut pas facilement changer ça. Donc on se retrouve avec deux tables (sfGuardUser et sfGuardUserProfile) séparées (reliée quand même par une relation 1:1, heureusement), pour gérer les utilisateurs ! Seulement votre admin, lui, il aimerait (et on le comprend), éditer les utilisateurs dans son admin generator en un seul formulaire !

La solution (pas belle, mais j’ai pas trouvé mieux…) :

  1. ajouter la relation « Profile » au schéma de sfDoctrineGuardPlugin :
    • <sf_root>/plugins/sfDoctrineGuardPlugin/config/doctrine/schema.yml
    •  Profile: class: sfGuardUserProfile foreign: user_id local: id type: one onDelete: cascade foreignType: one foreignAlias: User
  2. copier le fichier de définition du formulaire admin
    • cp <sf_root>/plugins/sfDoctrineGuardPlugin/lib/form/doctrine/sfGuardUserAdminForm.class.php <sf_root>/lib/form/doctrine/sfDoctrineGuardPlugin 
  3. ouvrir le fichier, dans la fonction configure(), ajouter la commande magique  $this->embedRelation(« Profile »)
  4. créer ou modifier le fichier de config pour l’admin generator pour qu’il prenne en compte le widget ‘Profile’ :
    •  <sf_root>/apps/backend/modules/sfGuardUser/config/generator.yml
    • Voici le mien, mais c’est un exemple :
       generator: class: sfDoctrineGenerator param: model_class: sfGuardUser theme: admin non_verbose_templates: true with_show: false singular: ~ plural: ~ route_prefix: sf_guard_user with_doctrine_route: true config: fields: password_again: { label: "Password (again)" } list: title: User list display: [=username, created_at, updated_at, last_login] form: class: sfGuardUserAdminForm display: "User": [email_address, username, password, password_again] "Profile": [Profile] "Permissions and groups": [is_active, is_super_admin, groups_list, permissions_list] edit: title: Editing User "%%username%%" new: title: New User 

      Remarquez le « Profile » : [Profile] qui insère le sous-formulaire basé sur la relation 1:1 dans le formulaire. Vous pouvez bien-sûr définir des validateurs, et configurer les champs dans le fichier de configuration du formulaire de profil (celui de sfForked) :

      <sf_root>/lib/form/doctrine/sfForkedDoctrineApplyPlugin/sfGuardUserProfileForm.class.php

 

 

ubuntu 12.04 : trucs & tweaks unity

Depuis hier, je teste la dernière version d’ubuntu 12.04 LTS (pour l’instant en béta 2) avec unity. Du coup, forcément, j’ai pleins de trucs qui ne fonctionnent plus comme avant, ou mal.
Et, comme j’en ai résolu certain, je me suis dit autant les mettre quelque part pour la prochaine fois, et les partager tant qu’à faire. Notez que c’est livré sans garantie comme on dit dans le monde de l’open source… A vous de jouer les apprentis sorciers et, comme moi, de passer des heures (quand ce ne sont pas des jours) à réparer vos bétises…

lorsque l'application qui signale le problème plante, on est mal barré...

Je vous laisse donc quelques astuces en vrac (j’éditerai cet article au fur et à mesure), qui feront peut-être gagner du temps à certains :

Les outils utiles (heureusement sinon ça ne serait pas des outils…) pour mettre en vrac le sytème…

Les outils que j’utilise pour modifier les paramètre de gnome permettent, en gros, d’éditer les fichiers de configuration sans savoir exactement lesquels ou leur emplacement : parfait pour un apprenti sorcier ;)

Je me permets de rappeler que ces outils peuvent mettre votre système (en tout cas l’interface graphique) complètement hors d’usage, et sont donc à utiliser avec modération…

  • gconf-editor (disponible par défaut)
  • gnome-tweak-tools (paquet ubuntu), disponible ensuite avec « advanced settings » dans unity
  • ccsm :  CompizConfig Settings Manager, ça parle de soit.

Position des boutons fermer, agrandir et minimiser :

  • alt-f2, puis taper gconf-editor
  • dans la clé /apps/metacity/general/button_layout , changer par ‘:minimize,maximize,close’

Remettre par défaut la configuration :

  • déplacer la config actuelle :
    mv ~/.gconf ~/.gconfd ~/.gnome ~/.gnome2 ~/backupGnomeConfig/
  • Redémarrer la session unity : tout est comme neuf  ! Attention, ça réinitialise toutes les préférences de gnome, je vous aurais prévenu…

Rien n’apparaît dans la recherche unity (les « lenses » comme ils disent)

  • C’est un bug connu, dont voici le fix :
 mv ~/.local/share/zeitgeist ~/.local/share/zeitgeist.bak
kill -s TERM `pidof /usr/lib/unity-lens-applications/unity-applications-daemon` 

Mais où est passé mon indicateur de processeur ?

logrotate, ou comment éviter une catastrophe

Ils sont là. Ils grossissent dans l’ombre… Petit à petit, jour après jour, connexion après connexion, les fichiers de log que vous avez complétement oublié (« je m’en occuperai dès que j’ai fini de développer l’appli »).

Et puis un jour, c’est le drame : vous recevez un coup de fil : « tous les sites sont tombés ! il n’y a plus de mail, rien ne marche ». Alors vous cherchez, cherchez encore : « c’est pas possible, même le ssh a du mal ! Je me suis fais hacker ou quoi ?  » Aucun site ne répond, le ftp rame comme jamais, le serveur de mail est tombé depuis longtemps : vous commencez à sentir une grosse boule dans le ventre…

Enfin, après quelques heures (ou quelques minutes pour les plus doués…) de moite angoisse devant votre terminal, vous avez l’idée -géniale- de regarder l’espace disque disponible : 0 octets ! Vous n’en croyez pas vos yeux… Alors vous cherchez, et soudain la lumière se fait enfin : les logs !!! Bon sang mais c’est bien sûr : les fameux log perso que vous avez fouré dans un coin, tout content d’avoir trouvé (il y a 4 ans) la commande pour faire des logs personnalisés !

Seul problème : si vous ne configurez pas une rotation de log, un jour (lointain certes, mais quand même) la bombe à retardement explose !

Bref, si toi aussi, tu as eu ces malheurs, tu sais quel est ton ami : « logrotate » : une config de 5 minutes chrono, et plus d’ennuis !

Pour rappel (et de ce que j’en ai compris) :  logrotate est installé sur la plupart des distrib linux et est exécuté par le crontab tout les jours par défaut. Un certain nombre de commandes permettent de le personnaliser. En gros et pour faire vite, en admettant que vous ayez un log apache perso (testé sur debian squeeze):

  1. Copier le fichier /etc/logrotate.d/apache2
  2. Changer la première ligne par votre chemin préféré de log, et éventuellement les droits et utilisateur sur les nouveaux fichiers créés (par défaut root:adm, 640)
  3. vérifier avec la commande logrotate -fv /etc/logrotate.conf que vos fichiers de log sont bien créés.

Et hop ! Tous vos log perso apache sont bien proprement compressés une fois par semaine, et votre serveur redémarrera à cette occasion. Franchement ça valait le coup quand même, non ?

Je vous invite à lire les commandes de logrotate : http://www.delafond.org/traducmanfr/man/man8/logrotate.8.html

bonne config :)

 

EDIT : pour ceux qui sont sous symfony, vous avez aussi une commande spécifique :

 php symfony log:rotate frontend prod --period=7 --history=10

A vous de voir :)
 

de git et des branches

Un très bon article sur la subtilité des branches dans le gestionnaire de version git : http://longair.net/blog/2009/04/16/git-fetch-and-merge/

Où l’on explique que faire n’importe quoi avec les pull / push peut se révéler fatal…

symfony : ne pas ecraser le constructeur de doctrine

Il faudra un jour que je comprenne pourquoi on ne peut pas surdefinir le constructeur d’une classe de modèle générée par Doctrine, sans mettre toute l’application symfony en berne…
À chaque fois que j’essaie c’est pareil. Il doit y avoir une solution, mais laquelle ?

EDIT solution ici : http://blog.dsyph3r.com/2011/04/doctrine-1-overriding-constructor.html (utiliser construct() à la place de __construct()… faut le savoir quand même…)

mysql : trier un champ varchar comme un champs numérique

Question : vous avez un champs mysql contenant des valeurs alpha numériques (type varchar par exemple), mais vous voulez les trier par ordre numérique…

Réponse : select champ from table order by abs(champ)

Et hop !
Il se trouve que la fonction abs de mysql renvoie un nombre même si la valeur du champs est alphanumérique, ce qui permet un classement numérique par la suite.
C’est la bonne nouvelle de la journée :-)

hello wordpressed world :)


Et voilà, je me mets à wp !

Un petit test vite fait pour voir si c’est mieux que spip à qui je fais une infidélité en utilisant le fameux moteur de blog…

Ce site est « en construction » comme on  dit, soyez indulgents….