Afin de bien pouvoir travailler avec les prix TTC dans votre catalogue dans la nouvelle version de Magento (1.4.0.1), vérifier bien votre configuration dans
Systeme => Configuration => Ventes => Paramètres de livraison=> Origine : mettre France au lieu de Etats Unis

Sinon Magento ne tiendra pas compte de vos réglages de TVA

On ne peut pas faire plus leger: un seul fichier pour effectuer l'administration mysql telle qu'on la connait avec Phpmyadmin : http://bit.ly/5jUvRH

Sur un site multilingue, il peut arriver que nous ayons à générer du contenu dans une langue différente de celle du siteaccess courant. L'affichage dans une iframe d'un autre siteaccess ayant la langue recherchée n'est pas toujours le plus facile, notamment lorsqu'il s'agit de générer un template d'envoi de mail...

Pour nous faciliter la tache, on peut employer une petite astuce :

 //On récupère l'instance par défaut du site.ini, utilisé pour les locales :
 $ini = eZINI::instance();
 //Récupération de la locale courante :
 $originalLanguageCode = $ini->variable( 'RegionalSettings', 'Locale' );
 //On défini la locale souhaitée :
 $ini->setVariable( 'RegionalSettings', 'Locale',  'fre-FR' );
 //On vide le cache de locale pour que notre changement soit bien pris en compte :
 eZLocale::resetGlobals();
 $tpl = templateInit();
 /* Nous placerons nos fetchs d'objets à afficher ici */
 $content = $tpl->fetch( 'design:mon_template_a_traduire.tpl' ) );
 //On redéfini la locale d'origine:
 $ini->setVariable( 'RegionalSettings', 'Locale',  $originalLanguageCode );
 eZLocale::resetGlobals();

Il est a noter que dans le site.ini de votre siteaccess, dans le paragraphe [RegionalSettings], la variable TextTranslation doit bien être a enabled, il n'est pas possible de la redéfinir au niveau d'un module (du fait du mécanisme d'appel des fonction i18n en fonction de cette variable).

Lorsque vous créez vos propres modules, il est parfois intéressant de rediriger le visiteur vers une vue antérieur. Pour récuperer l'URI de la dernière vue utilisée, eZ Publish met à notre disposition une variable de session, "LastAccessesURI", qui peut être appelée dans une des vues de vos modules de cette façon :

$http = eZHTTPTool::instance();
$http->sessionVariable( "LastAccessesURI" );

Vous obtiendrez alors la dernière page visitée par l'utilisateur avant l'appel de votre vue.

Là où il peut y avoir problème, c'est lorsque cette dernière page visitée n'est pas vraiment pertinente. Par exemple lorsqu'il s'agit d'une page d'édition de contenu, ou de l'appel d'une méthode AJAX : il peut être déroutant pour l'utilisateur de se retrouver sur l'édition d'une version d'objet qui n'existe plus ou sur le retour d'une portion d'HTML qui est générée par une de vos vues orientée AJAX...

La solution se trouve dans la déclaration de vos vues au niveau de votre module.php, dont voici un fragment d'exemple :

$ViewList["ajax_action"] = array( 'script' => 'ajax_action.php',
                                  'functions' => 'action',
                                  'ui_context' => 'edit',
                                  'params' => array( 'objectID' ) );

Pour faire en sorte que la vue ne soit pas retenue comme 'dernière URI utilisée', il suffit de mettre dans l'index 'ui_context' une des valeurs suivantes : 'edit', 'administration', 'browse' ou 'authentication'.

Une page chargée après l'appel de la vue "ajax_action" n'aura donc pas cette dernière comme "LastAccessURI", mais bien la dernière page "utile" visitée par l'utilisateur.

Pour en savoir plus, voir dans le code : /index.php aux environs de la ligne 880 (eZ Publish 4.1.3).

Comme disait ma grand-mère ! Et la sagesse ancestrale est archi-validée dans la jungle des nouvelles technologies : Finies les galères d'installation et de paramétrage du dernier package beta de votre application Open Source favorite => Pensez à télécharger un "Stack" chez BitNami, une sorte de package d'installation clé en main : http://bitnami.org/stacks

Je suis tombé la-dessus par hasard en cherchant un package d'installation de RubyOnRails pour Mac OS X. Amateurs de Joomla, Moodle et autres WordPress, faites votre marché.

Sont annoncés des Stacks pour Typo3, eZ Publish et SugarCRM, à suivre !

Pour Mac, on trouve même une alternative intéressante à l'architecture serveur MAMP : Elle s'appelle tout dimplement MAMPStack, et intègre à ce jour Apache 2.2.6, PHP 5.0.45, MySQL 5.2.5 et PHPMyAmin 2.11.2. Autant dire que c'est du lourd, et que c'est plus qu'à jour.

Chers amis webmasters qui avez switché !

Votre bonheur serait total s'il y avait sur Mac un éditeur web digne de ce nom, à la fois pertinent pour le codeur qui someille en vous et ultra-ergonomique pour l'utilisateur exigeant qu'Apple a révélé en vous.

Vous avez naturellement essayé Adobe Dreamweaver ... très très lourd et gourmand.

Vous avez essayé iWeb, Rapid Weaver et autres Sandvox ... trop trop légers.

Vous vous êtes rabattus sur vtre éditeur de texte ultra-léger, type Smultron ou Textmate, sur lequel vous vous consolez en éditant les fichiers CSS de votre CMS favori ...

Mais ne désespérez pas ! La solution est là, et elle s'appelle ... CODA ! Merci à Panic Software pour cette magnifique pépite, que je qualifierais pour résumer de "Dreamweaver Pro porté nativement dans Mac OS X".

Dans CODA 1.1 vous allez trouver :

• Un gestionnaire de sites, avec support SFTP et terminal SSH,
• Un éditeur HTML en mode code source et Wysiwyg,
• Un éditeur CSS très pointu,
• Une sympathique librairie de code : HTML, CSS, PHP, Javascript ...

Le tout dans un fenêtrage Apple Aqua à pleurer de bonheur ! Merci, promis je ferai bruler un cierge à la vierge !

Notre environnement informatique d'entreprise, collaboratif et connecte 24/24h, est plus que jamais vulnerable aux instabilites intrinseques des logiciels et aux attaques de visiteurs mal intentionnes.

L'anticipation des risques est dans ce contexte un facteur cle de survie, et pourquoi pas egalement un avantage competitif dans le domaine de la prestation de service.

Une des regles de base de pour une information fiable est la multiplicite des sources, et dans ce domaine precis de la securite informatique je vous invite a bookmarquer 2 sources diametralement opposees et donc ultra-complementaires :=> l'US-CERT : Le "Computer Emergency Readiness Team" a ete fonde en 2003 pour veiller a la securite informatique des reseaux americains, et coordonner la defense contre le cyber-terrorisme. Le site est une inepuisable mine de renseignements, et de nombreux fils RSS thematiques peuvent etre souscrits. Ils ont un bulletin hebdomadaire des vulnerabilites, qui ne fait pas rire, et ou l'on retrouve tous les grands noms de l'informatique. On peut soi-meme soumettre des failles que l'on a decouvertes : http://www.us-cert.gov/nav/t01/=> Le groupe Milw0rm : Ce groupe d'"hacktivistes" international est apparu en 1998, et il s'est illustre en infiltrant le reseau informatique d'un centre de recherche atomique indien (cf cet article), a l'epoque ou l'Inde affirmait son role de puissance nucleaire regionale. Depuis, certains membres du groupe son sortis de l'anonymat pour creer un portail consacre a la securite. De quoi occuper vos longues soirees d'hiver et hanter vos nuits d'horribles cauchemards ! Le lien : http://www.milw0rm.comA titre d'exemple, un tutorial video de codebreak1984 qui devrait vous faire froid dans le dos, consacre a l'injection de code malicieux PHP dans un bete fichier JPEG.

Un homme averti en vaut deux.

RSS : US-Cert Milw0rm

A l'heure où vous mettez peut-être en oeuvre des applications Flash/Flex connectées à des bases de données en ligne, la sécurisation des flux de données est cruciale !

Le recours aux échanges binaires en AMF, via des services RPC tels que AMFPHP, est certes intéressant mais bien loin d'être satisfaisant : N'importe quel proxy moderne sera en mesure d'examiner dans le détail les paquets de données qui transitent entre l'interface utilisateur et le service web.

Naturellement, vous franchirez un cap significatif en utilisant le protocole HTTPS, sécurisé avec un certificat SSL adéquat. Mais pour les plus paranos ou les moins fortunés, le recours ultime est de procéder vous-même à l'encodage et au décodage de vos données, à chaque bout de la chaîne.

Côté serveur pas de soucis, vous devriez disposer des librairies adéquates dans votre langage de scripting favori. En PHP, on utilise l'excellent librairie de chiffrement mcrypt.

Mais côté actionscript, il n'existe aucune classe ou fonction native dans Flash ou Flex à l'heure actuelle. Que faire ? Je m'étais déjà posé le problème en 2004, alors que je développais un jeu Flash primé pour le compte d'adidas. J'avais alors identifié une librairie publiée par un certain MEYCHI. La librairie s'appelle AScrypt, et j'ai constaté avec plaisir qu'elle est toujours maintenue par ce contributeur finlandais.

=> A découvrir ici, sur le blog de MEYCHI : http://www.meychi.com/archive/000031.phpAu programme, les algorithmes suivants : MD5, SHA-1, Base8, Base64, TEA, AES, RSA, ROT13, RC4 + la compression LZW.=> Pour compléter votre collection avec un bon vieux Blowfish, qui est toujours dissuasif : Actioncrypt ( http://sourceforge.net/projects/actioncrypt/ )

Rappelons les algorithmes les plus performants et donc recommandés : SHA-1 et AES

J'administre un portail qui date de 2002, et qui avait ete developpe exclusivement en scripting PHP pur, en dehors de tout CMS pre-existant.

Il se connecte a des sources de donnees MySQL a travers une simpe classe AdoDB, legerement remaniee, que j'avais a l'epoque piochee dans le package PHPLib 7. Au passage, je constate avec plaisir que cette superbe librairie est toujours referencee sur Sourceforge, et a meme fait l'objet d'une releae 7.4a en fevrier 2006.

Mon portail comporte sa propre gestion de droits, relativement rudimentaire, basee sur une matrice croisant des groupes (ou roles) avec des droits fonctionnels elementaires, une simple fonction du tive "verifieDroit($groupe,$droit)" assure les controles logiques.

La pluparts de mes fonctionnalites sont codees a travers une page dediee, du type adm_func.php ou usr_func.php, suivant que je traite du backoffice ou du frontoffice du portail. Naturellement, chaque fonctinnalite fait appel a un certain nombre d'inclusions locales, ou de fonctions globales.

Voici les problemes que je rencontre :=> Mes utilisateurs souhaitent des interfaces plus ergnomiques,=> Avec le temps, mon code est devenu plethorique, confus, et intrique,=> La fiabilisation des processus et de l'integrite des donnees devient un vrai casse-tete

Fort de ces constats, mon but est de moderniser les fontionnalites offertes a mes utilisateurs, en mettant en oeuvre des interfaces enrichies avec Flash ou Flex. Toutefsoi, j'ai de nouveaux enjeux a prendre en compte :=> Je ne veux pas refondre tout mon portail d'un seul coup : Il y a trop de dependances liees, et ce serait un travail de romain. J'ai besoin d'une methodologie qui me permette de mettre a niveau mes fonctionnalites progressivement.=> Nous sommes plusieurs developpeurs a intervenir sur le site, et j'ai donc besoin d'une organisation collaborative.=> Les mises a niveau doivent etre validees par mon client sans perturber le site en exploitation : J'ai donc besoin d'une gestion des versions.

Le challenge est piquant, n'est-ce pas ?

Je vous livre ici la demarche que j'ai adoptee, en 4 actes, et en demontre les benefices : Avis bienvenus !

=> ACTE 1 : Mise en place d'un processeur PHP global. Cette simple mesure permet de faire d'une pierre 3 coups :- Je peux mettre en oeuvre un environnement multi-developpeurs- Je peux mettre en oeuvre un versionning de fichiers- Je peux mettre a la disposition de mon client des versions beta de fonctionnalites, sans perturber l'environnement de production.Pas mal non ? La technique est d'une simplicite deconcertante. En outre, elle me permet d'economiser un rigoureux et fastidieux service CVS ou SVN.AVANT : J'invoquais ma fonctionnalite directement par "adm_func.php"APRES : J'ai mis en place un processeur PHP global qui suit la syntaxe suivante :processeur.php?f=adm_func[&d=xxx&v=nnn]ou "f" est le nom de mon fichier "d" est le nom du developpeur (optionnel) "v" est la version (optionnel)Le contenu de mon fichier processeur est le suivant :switch ($d) {case "quad": switch ($f) { case "adm_func": // mes regles de redirection ici, en fonction des numeros de version break; default: if ($v) { $le_fichier=$f."_v".$v.".php"; } else { $le_fichier=$f.".php"; } break; default: if ($v) { $le_fichier=$f."_v".$v.".php"; } else { $le_fichier=$f.".php"; } break;}// In fine, je charge le bon fichier s'il existeif file_exists($le_fichier) { require($le_fichier);} else { echo "Ce fichier n'existe pas."}

En production mon URL est "processeur.php?f=adm_func"En test et beta, mon URL :"processeur.php?f=adm_func&d=quad&v=2"renverra naturellement la nouvelle version de la fonctionnalite, telle qu'elle est developpee par le programmeur "quad", ou dans l'environnement de developpement "quad". Pour les plus malins d'entre vous, vous aurez compris qu'on gagnera du temps et du confort d'utilisation en fixant les variables $d et $v en session cote serveur !

=> ACTE 2 : Mise en place d'une nouvelle interface Flash/FlexJe met au feu mes vieilles pages HTML, et je met en oeuvre une nouvelle interface moderne et attractive avec Flash ou Flex. Avec l'un ou l'autre de ces outils, il en resulte un fichier SWF que j'encapsule proprement dans une nouvelle page fonctionnelle a l'aide du cultissime " swfObject". Le contenu type de ma page adm_func_v2.php sera reduit a cela :<code><html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title>Mon BO PORTAIL - Ma fonctionnalite v2</title></head><body><script type="text/javascript" src="js/swfobject.js"></script> <div id="flashcontent">  Mon portail - Pour visualiser ce contenu, vous devez activer Javascript, et disposer du lecteur Flash version 7 ou plus.</div><script type="text/javascript">   var so = new SWFObject("swf/adm_func.swf", "mon_swf", "800", "600", "7", "#FFFFFF");   so.write("flashcontent");</script></body></html></code>

=> ACTE 3 : Securisation des sessionsNous sommes dans une page qui est securisee, avec 2 niveaux d'accreditation :- Un login utilisateur global- Une verification des droits de cet utilisateurCes informations peuvent tres facilement etre stockees en variable de session tres en amont, et il suffit donc de retransmettre au composant SWF ces donnes de session, stockees dans le tableau unique PHP $_SESSION.-Cote client, on amenage notre fichier HTML comme suit :<?// Je recupere mes en tetes PHP indispensables au seul fonctionnement de mon template HTML $SID=session_id(); // Je recupere l'id de session?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title>Mon BO PORTAIL - Ma fonctionnalite v2</title></head><body><script type="text/javascript" src="js/swfobject.js"></script> <div id="flashcontent">  Mon portail - Pour visualiser ce contenu, vous devez activer Javascript, et disposer du lecteur Flash version 7 ou plus.</div><script type="text/javascript">   var so = new SWFObject("swf/adm_func.swf", "mon_swf", "800", "600", "7", "#FFFFFF");      so.addVariable("SID", "<? echo  $SID; // Et je la transmet a Flash ?>");   so.write("flashcontent");</script></body></html>

=> ACTE 4 : Extraction de la couche "business" avec AMFPHPCote serveur, on prepare tout d'abord un service AMFPHP (type svc_verifieSession.php) pour verifier la session : Si le SID renvoye par Flash correspond au session_id courant on renvoie a Flash tout ou partie du tableau $_SESSION. Je suggere pour ma part de renvoyer 2 tableaux filtres, l'un du type userData pour collecter les donnees utiles sur l'utilisateur courant, et un autre du type userDroits pour collecter la matrice de droits. Mais a chacun sa sauce, et tout depend de votre architecture !

Une fois ce cap passe, les grands espaces couverts d'herbe verte et jonches de petales de roses s'ouvrent devant vous : - Preparez un service AMFPHP global intitule svc_adm_func.php,- Remobilisez a ce niveau votre connecteur SQL (dans mon cas, ma connexion MySQL via adoDB ),- Declarez toutes les methodes dont vous aurez besoin pour gerer les transactions entre l'interface utilisateur et la base de donnes.- Codez vos requetes SQL, et verifiez vos echanges de donnees in/out avec votre fidele Charles.

=> CONCLUSION : Les benefices degages- Je n'ai pas perturbe mon environnement existant, et mes nouveaux developpements s'integrent naturellement au fil des jours,- J'ai desormais une architecture multi-utilisateurs avec une gestion de versions de fichiers, certes sommaire mais efficace,- Je mets en oeuvre des interfaces plus riches et conviviales avec Flex et Flash, pour le plus grand bonheur des utilisateurs finaux,- j'ai tres explicitement dissocie ma couche applicative et ma couche data, grace aux services AMFPHP,- J'ai clarifie mon architecture de fichiers et de dependances : Pour une fonctionnalite donnee, j'ai un conteneur HTML ultra leger (adm_func_v2.php), un element SWF qui contient tous les elements d'interface graphique (swf/adm_func.swf), et un service AMFPHP (svc_adm_func.php) qui fournit toutes les methodes necessaires aux transactions de donnees.

Le bonheur c'est simple, non ? Bon courage a tous !

Si comme nous ce sujet vous interesse, voici un site a mettre sur ecoute ...

http://www.brightworks.com/technology/adobe_flex/with_php.html