par Stéphanie Pinet
Développée par l’Etablissement de Paiement NordPay, la solution de paiement en ligne Paysite-cash est désormais disponible sur Thelia.
Ce nouveau partenariat s’inscrit dans la volonté d’offrir aux e-commerçants un service d’encaissement simple d’utilisation, hautement sécurisé et facilement intégrable.
« Ce partenariat apporte aux utilisateurs de Thelia une solution de paiement par carte bancaire simple, très complète et totalement intégrée à l’offre de services de Thelia. Concrètement, cela leur permet de simplifier leurs encaissements en confiant l’ensemble du processus à un seul et unique établissement financier, tout en bénéficiant de conditions tarifaires attractives. Cette collaboration s’inscrit dans notre stratégie de développement sur le sol Européen et vise à offrir un service clé en main au plus grand nombre de commerçants possible. », indique Frederic NOEL, Directeur associé de NordPay Financial.
Grâce à ce partenariat, les commerçants bénéficient désormais des nombreuses fonctionnalités de Paysite-cash et peuvent développer leur activité rapidement, sans passer par leur banque.
Ils profitent ainsi d’un service intégrant un contrat VAD, l’encaissement sécurisé des cartes bancaires et d’outils d’optimisation des taux de conversion. Paiement par abonnement, page de paiement multilingue et entièrement personnalisable, paramètres de contrôle de la fraude, suivi et statistiques des transactions via une interface de gestion intuitive, sont dès maintenant accessibles.
Le module Paysite-cash pour Thelia est désormais disponible en téléchargement ici. Les utilisateurs de la solution bénéficient également d’un système d’installation simplifié, un point supplémentaire qui contribue à améliorer la qualité de service apportée aux marchands.
Ce partenariat avec Thelia est une étape supplémentaire clé dans la stratégie de Paysite-cash, qui entend poursuivre et intensifier le développement de son réseau de partenaires en France, pour cette année 2013.
Paysite-cash est une solution d’encaissement par carte bancaire développée par NordPay Financial, Etablissement de Paiement Européen agréé par la FSA (n°535688) et autorisé par la Banque de France (n°73784). Avec plus de dix ans d’expérience dans le e-commerce et sa plateforme de paiement française certifiée PCI DSS de niveau 1, NordPay apporte aux e-commerçants une sécurité maximale pour leurs transactions. Une qualité de service permettant de limiter ainsi les risques de fraude et d’optimiser les conversions des marchands dans toute l’Europe.
Pour plus d’informations sur Paysite-Cash, consultez leur page Partenaire.
Site web : http://paysite-cash.com
Contact NordPay : sales@paysite-cash.com
par Manuel Raynaud
La partie fonctionnelle du plugin est terminée. Nous devons à présent le packager et voir comment le publier sur l’espace de contribution
Pour rappel, vous pouvez consulter la partie 1, partie 2, partie 3 et partie 4 du tuto.
Pour diffuser votre plugin et permettre à la communauté de l’utiliser, il vous faut le packager.
Rien de bien compliqué dans cette étape, il s’agit de générer un zip depuis le répertoire de votre plugin. Ce zip doit contenir notre réperoire "commentaire" qui lui même contient notre plugin.
Pour que votre plugin soit complet, il faut bien renseigner le fichier Readme.txt afin qu’il comporte toutes les informations nécessaires au bon fonctionnement du plugin. De cette façon, la personne qui le téléchargera aura tous les éléments pour pouvoir l’utiliser seul.
Dernier point, il faut que le fichier plugin.xml soit valide. Pour vérifier la validité reportez-vous à la partie 1 du tuto ou bien à la documentation Thelia.
Enfin, pour publier le plugin sur l’espace de contribution de thelia.net, il vous faut créer un compte sur cette page http://thelia.net/Plugins.html et proposer un nouveau module en remplissant le formulaire. Une fois soumis, le plugin sera vérifié par un membre de l’équipe de Thelia et validé.
Via ce tuto, nous avons couvert pas mal de points essentiels à la réalisation d’un plugin, tels que :
l’ajout de sa propre boucle,
l’ajout du contenu dans l’admin sur la page client, commande, contenu,... ,
l’interaction du plugin avec les modifications dans l’admin (utilisation des méthodes modprod, modrub,...).
Il reste encore cependant des points à découvrir, comme :
rajouter une action depuis le font-office (par ex commentaire d’un client sur un produit),
créer son propre filtre (assez facile à faire d’ailleurs),
la gestion des langues.
D’autres tutos seront prochainement publiés. En attendant, vous pouvez découvrir ces éléments par vous-même grâce à la documentation. N’hésitez pas non plus à poser des question sur le forum où vous trouverez de l’aide.
par Manuel Raynaud
Dans cette nouvelle partie nous allons apprendre la mécanique des boucles et mettre en place celles de notre plugin.
Pour rappel, vous pouvez consulter la partie 1, partie 2, partie 3 du tuto.
La dernière partie du tuto est disponible : partie 5
Les boucles sont la particularité de Thelia, qui le différencie des autres CMS du marché. Ces boucles facilitent grandement l’intégration.
Thelia est livré avec les boucles nécessaires pour faire fonctionner une boutique en ligne, mais il est bien souvent nécessaire, pour coller aux demandes spécifiques, de créer de nouvelles boucles. Les plugins sont donc là pour ça !
Comment fonctionne une boucle ?
Les boucles Thelia vont tout simplement répéter une portion de code autant de fois que nécessaire. Une boucle est bien sûr paramétrable et retourne différentes informations.
Les paramètres d’entrée sont les variables passées dans la boucle, permettant de construire la requête qui ira chercher les informations demandées.
Les paramètres de sortie sont les substitutions que vous connaissez sous la forme #QUELQUECHOSE.
Si vous faites votre propre boucle, vous pourrez définir vos paramètres d’entrée ainsi que les informations retournées.
Une boucle récupère le texte et toutes les informations de mise en forme contenues entre l’ouverture et la fermeture de la boucle. Si la boucle ressort des résultats, elle effectuera les substitutions présentes, sinon elle retournera une chaîne vide.
Pour créer votre propre boucle il faut d’abord créer la méthode boucle dans la classe de votre plugin. Elle a la signature suivante :
$texte contient la partie du template qui se situe entre l’ouverture de la boucle et sa fermeture
$args contient les paramètres d’entrée de la boucle
Pour lire les paramètres d’entrée, il faut utiliser la méthode lireTag qui prend en paramètre la variable dans laquelle doivent être recherchés les paramètres (donc dans le cas d’une boucle la variable $args), leurs noms et leurs types (int, string, etc).
Avec tous ces éléments, faisons maintenant notre boucle.
Elle aura en paramètre entrant l’id d’un produit et en paramètre de sortie l’id du commentaire, le titre et le message. Le paramètre entrant va nous permettre de construire la requête qui ira interroger la table commentaire du plugin. Si le paramètre id est vide, une chaine vide est retournée :
Comme vous l’avez remarqué, nous passons par une variable temporaire, le temps de faire les substitutions. Cela permet de ne pas perdre le texte original sans substitutions, sinon au deuxième tour de boucle les paramètres #QUELQUECHOSE ne seront plus présents.
La méthode query_liste est une autre méthode permettant de communiquer avec la base de données, elle prend en paramètre la requête et retourne un tableau. Chaque entrée du tableau représente une ligne de la table, sous forme d’objet. Il est possible de spécifier en deuxième paramètre le nom d’une classe à instancier et peupler avec les résultats.
Nous aurions donc pu passer "Commentaire" en second paramètre mais cela s’avère inutile dans notre cas, nous n’avons en effet pas l’utilité d’utiliser cette classe.
Nous pouvons à présent commencer à compléter notre fichier readme du plugin expliquant le fonctionnement de la boucle.
A vous de le faire et d’intégrer la boucle dans votre template !
Dans la prochaine partie, qui sera la dernière, nous verrons comment packager et soumettre un plugin sur l’espace de contribution. Nous verrons aussi quelques fonctions utiles que nous n’avons pas encore utilisées.
N’oubliez pas, vous pouvez vous aider du plugin sur github : https://github.com/thelia/commentaire
_
par Manuel Raynaud
Peu à peu nous allons migrer notre outil de versionning de sourceforge vers github. Sont déjà présents : l’admin en bootstrap, le modèle de Thelia 2 ainsi que le plugin servant de modèle pour le tuto
Le but de cet article n’est pas de vous apprendre à vous servir de git, il existe de très bonnes ressources pour cela comme sur le site du zéro ou bien pro git.
Le dépôt de Thelia sur github est à l’adresse suivante : https://github.com/thelia/
Quelle est la manière la plus efficace pour nous remonter des corrections, modifications, améliorations sur nos dépôts ?
Le plus simple et le plus efficace est de faire un fork du dépôt concerné, vous faites ainsi les modifications sur votre compte et vous nous proposez vos modifications grâce à la fonction Pull Request de github. Pour plus de détails, la documentation de github : https://help.github.com/
Pourquoi utiliser github plutôt que subversion ?
La principale raison est la possibilité de pouvoir contribuer simplement, comme détaillé ci-dessus. De cette manière, chacun peut nous faire remonter librement du code avec une intégration plus facile par rapport à ce qu’il est possible de faire actuellement sur subversion.
Le code actuel de Thelia sera-t-il migré sur github ?
Il n’est pas prévu pour l’instant de mettre le code sur github. En effet, nous avons mis en place un processus interne de développement qui ne nous force pas à migrer sur github.
Un répertoire dédié aux plugins verra-t-il le jour sur github ?
Il est possible que ce répertoire soit créé, en attendant rien ne vous empêche de mettre le code de vos plugins sur votre répertoire plugins.
par Manuel Raynaud
Dans cette partie nous allons travailler sur la validation du formulaire précédemment créé, et voir de manière générale comment interagir avec les actions de l’admin.
Rappel partie 1 partie 2 Parties suivantes : partie 4 et partie 5
Le principal intérêt de développer un plugin est de pouvoir étendre les fonctionnalités du moteur de Thelia et de communiquer avec lui, sans toucher au code même de Thelia. De cette façon, pas de mauvaises surprises lors des mises à jours de Thelia, aucune modification ne risque d’être écrasée.
Une API est donc mise à disposition pour que le module interagisse avec le moteur. Nous allons voir ici quelles sont les interactions concernant le back-office.
Lors de la partie 2 vous avez réalisé un formulaire permettant de rajouter un commentaire à un produit. Dans la classe principale du plugin nous allons implémenter la méthode modprod, appelée à chaque fois qu’un produit est modifié. La méthode modprod reçoit en paramètre l’instance de la classe Produit qui vient d’être modifiée.
Vous pouvez consulter une liste des méthodes appelées lors d’action dans le back-office ici.
Il existe aussi des helpers permettant de récupérer les paramètres de la requête HTTP passés en méthode GET, POST ou les deux. Ils permettent de sécuriser les paramètres rentrants en les filtrant grâce à la librairie HTMLPurifier. Il s’agit de la fonction lireParam et voici sa définition :
$param est le nom de l’input recherché.
$filtre est le type du paramètre attendu (int, float, string, etc). Bien qu’optionnel, il est très fortement recommandé de l’utiliser.
$méthode est la méthode HTTP (GET, POST). Si non précisé la fonction ira chercher dans les deux tableaux GET et POST.
$purifier permet d’activer ou non le filtrage via HTMLPurifier. Par défaut il est activé et je vous déconseille vivement de le désactiver.
Avant de pouvoir enregistrer nos commentaires, il ne nous reste plus qu’à indiquer au moteur de Thelia le nom et les champs de notre table.
Pour cela nous allons nous servir des propriétés :
chaque champs de la table est une propriété de la classe
la propriété bddvars est un tableau contenant tous les champs de la table (ça fait un peu double emploi mais c’est nécessaire au bon fonctionnement du plugin)
la propriété $table qui contient le nom de la table.
Nous voilà prêts pour enregistrer nos commentaires :
Nous vérifions donc qu’un commentaire a été renseigné et si c’est le cas nous l’enregistrons. Si vous souhaitez faire d’autres contrôles je vous invite à le faire.
Il ne vous reste aujourd’hui plus qu’à lister les commentaires existants sur la fiche produit et gérer l’activation et la suppression. A vous de jouer ;-)
La semaine prochaine nous réaliserons la boucle qui affichera en front-office les commentaires validés.
Voici une liste non exhaustive des méthodes qui sont appelés lors d’action dans le back-office :
modprod(Produit $produit) appelé après la modification d’un produit.
modrub(Rubrique $rubrique) appelé après la modification d’une rubrique. Instance de la classe Rubrique modifiée passée en paramètre.
moddos(Dossier $dossier) appelé après la modification d’un dossier. instance de la class Dossier modifiée passée en paramètre.
modcont(Contenu $contenu) appelé après la modification d’un contenu. Instance la class Contenu modifiée passée en paramètre.
ajoutprod(Produit $produit) appelé après l’enregistrement d’un nouveau produit. L’instance de la classe Produit nouvellement créée est passée en paramètre
ajoutrub(Rubrique $rubrique) appelé après l’enregistrement d’une nouvelle rubrique. L’instance de la classe Rubrique nouvellement créée est passée en paramètre.
ajoutcont(Contenu $contenu) appelé après l’enregistrement d’un nouveau contenu. L’instance de la classe Contenu nouvellement créée est passée en paramètre.
ajoutdos(Dossier $dossier) appelé après l’enregistrement d’un nouveau dossier. L’instance de la classe Dossier nouvellement créée est passée en paramètre.
supprod(Produit $produit) appelé après la suppression d’un produit. L’instance de la classe Produit supprimée est passée en paramètre.
suprub(Rubrique $rubrique) appelé après la suppression d’une rubrique. L’instance de la classe Rubrique supprimée est passée en paramètre.
supcont(Contenu $contenu) appelé après la suppression d’un contenu. L’instance de la classe Contenu supprimée est passée en paramètre.
supdos(Dossier $dossier) appelé après la suppression d’un nouveau dossier. L’instance de la classe Dossier supprimée est passée en paramètre.
ajoutpromo(Promo $promo) appelé lors de l’enregistrement d’un code promo. L’instance de la classe Promo nouvellement créée est passée en paramètre.
majpromo(Promo $promo) appelé lors de la modification d’un code promo. L’instance de la classe Promo modifiée est passée en paramètre.
suppromo(Promo $promo) appelé lors de la suppression d’un code promo. L’instance de la classe Promo supprimée est passée en paramètre.
addvariable(Variable $variable) appelée lors de l’enregistrement d’une variable. L’instance de la classe Variable enregistrée est passée en paramètre.
modvariable(Variable $variable) appelée lors de la modification d’une variable. L’instance de la classe Variable modifiée est passée en paramètre.
delvariable(Variable $variable) appelée lors de la suppression d’une variable. L’instance de la classe Variable supprimée est passée en paramètre.
ajcaracteristique(Caracteristique $caracteristique) appelée lors de l’ajout d’une nouvelle caracteristique.
modcaracteristique(Caracteristique $caracteristique) appelée lors de la modification d’une caracteristique.
suppcaracteristique(Caracteristique $caracteristique) appelée lors de la suppression d’une caracteristique.
ajcaracdisp(Caracdisp $caracdisp) appelée lors de l’enregistrement d’une nouvelle caracdisp.
modcaracdisp(Caracdisp $caracdisp) appelée lors de la modification d’une caracdisp.
suppcaracdisp(Caracdisp $caracdisp) appelée lors de la suppression d’une caracdisp.
ajcaracteristique(Declinaison $declinaison) appelée lors de l’ajout d’une nouvelle déclinaison.
modcaracteristique(Declinaison $declinaison) appelée lors de la modification d’une declinaison.
suppcaracteristique(Declinaison $declinaison) appelée lors de la suppression d’une declinaison.
ajcaracdisp(Declidisp $declidisp) appelée lors de l’enregistrement d’une nouvelle declidisp.
modcaracdisp(Declidisp $declidisp) appelée lors de la modification d’une declidisp.
suppcaracdisp(Declidisp $declidisp) appelée lors de la suppression d’une declidisp.
ajoutdevise(Devise $devise) appelée lors de l’enregistrement d’une nouvelle devise.
moddevise(Devise $devise) appelée lors de la modification d’une devise.
suppdevise(Devise $devise) appelée lors de la suppression d’une devise.
ajoutclient(Client $client) appelée lors de la création d’un client.
modcli(Client $client) appelée lors de la modification d’un client.
supcli(Client $client) appelée lors de la suppression d’un client.
aprescommande(Commande $commande) appelée lors de la création d’une commande.
statut(Commande $commande, $ancienStatut) appelée lors du changement de statut d’un commande. Sont passés en paramètre la commande concernée ainsi que le code de l’ancien statut (le nouveau statut est dans l’instance de la classe Commande).
Il n’y a pas de suppression de commande, elles passent simplement au statut annulé.
Vous pouvez retrouver cette liste de points d’entrée sur le wiki
Grâce à tous ces points d’entrées vous allez pouvoir intéragir avec le back-office de Thelia de manière simple.
N’oubliez pas, en cas de soucis vous pouvez toujours vous aidez du plugin sur GitHub, enrichi à chaque partie du tuto : https://github.com/thelia/commentaire
par Manuel Raynaud
Nous n’avons encore jamais pris position publiquement concernant la politique que nous appliquons aux licences des plugins réalisés par la communauté de Thelia.
Cette semaine, certains développeurs nous ont demandé si il était possible de réaliser des plugins pour Thelia mais de ne pas les placer sous licence GPL (ou compatible GPL).
Avant tout, nous souhaitons qu’un maximum de personnes utilise Thelia.
Nous aimerions bien sûr que les modules développés par la communauté respectent la licence initiale de Thelia, c’est à dire la licence GPL ou une licence compatible GPL.
Cependant si une personne ne souhaite pas le faire, il n’a jamais été question, et ce depuis la création de Thelia, d’organiser une chasse aux sorcières pour poursuivre les personnes qui n’utilisent pas la licence GPL.
Quand on nous demande sous quelle licence doit être un plugin fraîchement réalisé, nous répondons naturellement qu’il doit être sous licence GPL. Cependant, comme expliqué au-dessus, nous n’obligeons personne à le faire.
Pour clarifier la situation, nous avons décidé que les plugins proposés sur l’espace de contribution de Thelia devront tous être accompagnés d’une licence GPL. Si le plugin n’est pas sous licence GPL il devra être hébergé par la personne qui l’a développé.
Nous ne faisons que clarifier un point qui existe déjà, car oui il existe des plugins qui ne sont pas diffusés via le site thelia.net, et oui il existe des plugins pour Thelia qui ne sont pas sous licence GPL.
Nous souhaitons à tous un excellent développement, en espérant que vous aurez beaucoup de plaisir à travailler sur Thelia !
par Stéphanie Pinet
Dans le cadre des tutos "Créer un module pour Thelia" voici un mémo sur l’héritage des Classes Thelia.
par Manuel Raynaud
Dans cette partie nous allons automatiser l’installation du plugin et mettre en place les premières interfaces dans l’admin.
Rappel partie 1 Parties suivantes : partie 3 , partie 4 et partie 5
Lors de l’activation d’un plugin, il peut être intéressant d’automatiser certaines actions comme : la création d’une ou plusieurs tables liées au plugin, l’enregistrement de données dans les tables existantes de Thelia ou encore la création de dossiers.
Pour réaliser ces actions, Thelia doit exécuter la méthode init présente dans la classe du plugin.
Dans le cadre du plugin en cours de développement, nous devons créer une table pour enregistrer les commentaires. Cette table aura la structure suivante :
Si vous utilisez des outils comme mysql workbench, vous pouvez directement exporter le SQL permettant la création de la table. Pour cela créez la méthode init et initialisez une variable avec l’instruction SQL :
La classe PluginsClassiques hérite des classes Cnx et Requete, qui permettent de réaliser des opérations sur la base de données.
La méthode query utilisée précédemment fait partie de ces méthodes et permet d’exécuter une instruction SQL. Le second paramètre à true va permettre de soulever une exception si une erreur est rencontrée lors de l’exécution de la requête.
La méthode équivalente existe pour la désactivation d’un plugin. Il s’agit de la méthode destroy qui permet d’automatiser des traitements. Il est donc possible de prévoir la suppression de la table créée lors de la désactivation du plugin.
J’ai pris pour habitude de ne pas le faire, pour plusieurs raisons et la principale est qu’il arrive souvent qu’un commerçant désactive un plugin puis le réactive, les données ayant donc disparues. A vous de voir donc ce que vous souhaitez faire.
Ensuite, activez votre plugin et vérifiez que la table est bien présente dans votre base MySQL.
Nous pouvons à présent créer les écrans dans l’interface d’administration. Le back-office de Thelia n’est pas fait sous forme de templates. Pour rajouter des interfaces dans l’admin, il existe des hooks, points d’entrée permettant d’inclure des fichiers à des endroits précis dans l’admin. Il faut créer un fichier pour chaque hook.
Comment utiliser ces hooks ?
C’est assez facile, il suffit de respecter une règle de nommage pour tous les fichiers de votre plugin :
nomplugin_admin.php sera inclus dans la partie "Modules" de l’admin.
nomplugin_admin_produitmodifier.php sera intégré dans la fiche produit.
nomplugin_admin_rubriquemodifier.php sera inclus sur une fiche rubrique.
Vous trouverez la liste exhaustive des hooks (points d’entrées) sur le wiki
Maintenant que nous savons comment nommer les différents fichiers et quels seront les éléments à intégrer, revenons à la création du plugin et passons à l’ajout du formulaire de commentaire sur la fiche produit. Il nous faut d’abord créer le fichier commentaire_admin_produitmodifier.php.
Ensuite, avant même d’intégrer le formulaire, nous allons régler les autorisations pour chaque administrateur. Ainsi, vous pourrez autoriser tout ou partie des administrateurs à accéder à ce module.
Le premier code à intégrer est donc le suivant :
Notez qu’il n’est pas nécessaire de redéclarer la balise form, le plugin sera inclus dans le form général de la fiche de modification du produit.
Je vous laisse maintenant intégrer le formulaire de commentaire dans votre fichier commentaire_admin_produitmodifier.php, et vous rendre compte par vous-même de l’inclusion sur la fiche produit.
La semaine prochaine, nous verrons comment intégrer la validation du formulaire.
Si vous rencontrez des soucis, aidez-vous du plugin sur GitHub, il est enrichi à chaque partie du tuto : https://github.com/thelia/commentaire
Pour lire la suite, rendez-vous sur la partie 3 du tuto
par Manuel Raynaud
Thelia permet d’étendre ses fonctionnalités grâce à l’ajout de plugins. Nous allons voir ici comment en réaliser un.
Il existe 4 types de plugins permettant d’étendre les fonctionnalités de Thelia :
La liste des plugins téléchargeables est disponible ici : http://thelia.net/Plugins.html Thelia recense à peu près 250 plugins.
Pour illustrer la création d’un module nous allons partir du cahier des charges suivant :
Le besoin énoncé, découvrons maintenant comment sont structurés les plugins.
Les plugins sont enregistrés dans le répertoire client/plugins de votre Thelia :
Comme vous pouvez le voir, nous avons ici le plugin chèque et le plugin colissimo avec tous les fichiers qu’ils contiennent. Un plugin c’est donc un dossier avec au minimum un fichier php ayant le même nom que le dossier, commençant par une majuscule.
Nous allons appeler notre plugin "commentaire". Créez donc un répertoire commentaire dans client/plugins ainsi que le fichier Commentaire.class.php :
La structure de notre plugin est en place. Il ne nous reste plus qu’à déclarer notre plugin, c’est à dire spécifier le type de plugin que nous développons (classiques, transports, paiements ou filtres).
La déclaration d’un plugin est en fait la déclaration d’une classe, qui hérite d’une des classes suivantes :
Notre plugin ne rentre pas dans le cadre des plugins transports, paiements ou filtres, il s’agit d’un plugin classique. Ouvrez donc votre fichier Commentaire.class.php à l’aide de votre éditeur préféré et déclarez la classe :
Pour l’instant nous appelons seulement le constructeur de la classe parente en lui spécifiant le nom du plugin. Ce n’est pas nécessaire de le faire si vous joignez la description de votre plugin au format XML, ce que nous allons voir dès à présent.
Le fichier plugin.xml est obligatoire. Il permet d’avoir des renseignements sur vous, la version du plugin, à partir de quelle version de Thelia votre plugin est compatible, si il est stable ou bien encore en développement, etc. Vous trouverez la documentation sur ce fichier ici : http://thelia.net/wiki/index.php/Structure_du_fichier_plugin.xml Voici un exemple :
Vous disposez maintenant aussi du fichier plugin.xml dans le répertoire de votre plugin.
Il est également préférable de rajouter de la documentation dans votre plugin indiquant ce qu’il fait et comment l’utiliser, en donnant des exemples d’utilisation. Nous allons donc rajouter un readme. Il vous suffit de créer un fichier Readme.txt. Pour l’instant il ne contient rien, nous le complèterons au fur et à mesure de nos développements.
Dans le prochain tutoriel nous verrons comment automatiser l’installation de notre plugin , c’est à dire créer automatiquement une table lors de l’activation du module. Nous développerons aussi les premières interfaces dans l’administration.
N’oubliez pas, vous pouvez consulter la documentation de Thelia à l’adresse suivante : http://thelia.net/wiki
par Stéphanie Pinet
Lundi 26 novembre, 1&1 a effectué un changement sur leurs serveurs MySQL installés sur leurs serveurs mutualisés.
Cette modification impacte la méthode permettant de calculer l’encodage des mots de passe, il devient alors impossible de se connecter à l’administration du site ni aux comptes clients.
La marche à suivre pour résoudre ce soucis est la suivante : Il suffit de modifier l’encodage des mots de passe dans les fichiers Client.class.php et Administrateur.class.php en remplaçant PASSWORD par OLD_PASSWORD.
Nous sommes en contact avec 1&1 afin qu’ils apportent une solution viable sur le long terme. En effet lors de la prochaine mise à jour de Thelia, cette modification sera perdue.