Si vous recherchez comment créer une API pour Prestashop, vous allez rencontrer pas mal de résultats qui vous montreront comment activer l’accès aux APIs déjà définies par Prestashop.
La document de Prestashop est exclusif sur la manière d’utiliser les APIs mais pas sur la création d’un webservice non lié à une entité.
Nous allons donc nous concentrer sur la création d’une nouvelle API.
Nous sommes une société de développement spécialiste de projets complexes ou des projets de vente spécifique (Même si chaque vendeur a une méthode de vente spécifique 🙂 )
Pour certains projets informatiques nécessitants une composante de vente en ligne, nous utilisons, grâce à ces modules, Prestashop comme socle de vente et d’encaissement. Cela permet de ne pas ré-inventer la roue et de nous appuyer sur un outil stable, performant, en perpétuelle amélioration comme tout site Internet qui souhaite vendre. Nous l’utilisons comme Framework spécialisé dans la vente en ligne.
Pliciweb Solutions, étant une société spécialisée dans le développement informatique, il n’y a rien de plus frustrant pour ces développeurs en Php que de passer un temps non négligeable sur un petit bout de code, une petite fonctionnalité qui nous bloque la validation d’une fonctionnalité.
Tout développeur informatique pourra vous citer un exemple ou il a réussi à coder une portion complexe de programme informatique en 2 fois de temps qu’initialement prévu mais il a reperdu toute cette avance sur un petit détail qui empêchait le bon fonctionnement du programme informatique. En informatique, tout est question de détail et chaque caractère à son importance. Notre catégorie Prestashop en regorge plein.
Telle est la mésaventure rencontrée par un de nos salarié travaillant sur un site Internet de vente en ligne propulsé par Prestashop.
En effet, après avoir codé un module, plutôt rapidement, et il se mit à vouloir le traduire. Malheureusement tous les champs des templates du modules ne ressortaient pas lors de l’utilisation de l’outil de traduction de Prestashop.
Dans le cadre de notre contrat avec la société La Poste, nous avons été mandatés afin d’effectuer la Tierce maintenance applicative (TMA) pour une filiale spécialisée dans l’envoi des objets perdus et dans la récupération des objets interdits en cabine.
Nous avons donc pris en charge une application basée sur le Framework Php CakePhp dans ce cadre là.
Or notre client nous contacte pour nous informer que certaines étiquettes Colissimo, générée par l’API Colissimo, sont erronées et ce de manière aléatoire. Les étiquettes présentes des données relatives à des colis qui datent de 2 ans.
Nous sommes bien une agence de développement.
Récemment, nous avons été contactés pour une demande…., comment dire, singulière.
Une personne souhaitait transférer sa voiture de Dubaï vers la France et nous a contacté tout naturellement pour savoir comment faire.
Quelle ne fut pas notre surprise, nous qui sommes habitués à travailler sur des développements informatiques. Je sais que notre palette de prestations est plutôt large (Modification de comportements de Prestashop, Création de modules pour Prestashop, Correction de site Internet sous Prestashop, Applications mobiles, Formations, Optimisation de performances, …) . Mais toutes ces prestations sont centrées sur des sites de vente en ligne utilisant le CMS de vente en ligne Prestashop, ou des applications mobiles. L’import / export étant un domaine vraiment spécifique.
Au delà, de nos compétences sur le développement autour de la vente en ligne et notamment le CMS Prestashop, nous développons des applications mobiles multi-plateformes.
Pour certains projets, nous utilisons donc IONIC couplé à AngularJS comme plateforme de développement d’application mobile. Cela permet de créer un seul code tout en générant des applications sur plusieurs plateforme (Android, IOS, …) qui peuvent être distribuées sur le Play Store, ou l’AppStore.
Cela permet de maintenir un seul code, de diminuer sa maintenance et donc le coût global d’une application mobile.
Pour notre client spécialiste de la réparation de chaussures par Internet, nous avons du modifier le comportement de Prestashop afin de lui permettre de payer par carte bleue une commande qui n’a pas pu être finalisée/payée.
Pour cela nous avons donc créé le fichier /override/classes/controller/FrontController.php qui permet de charger un panier et de le transformer en commande. Théoriquement impossible dans un Prestashop qui interdit de charger un panier qui a déjà une commande associée. Et cela quelque que soit le statut de la commande.
Malgré notre petit troll sur l’article d’une mise à jour de Prestashop 1.6 vers Prestashop 1.7, nous avons quand même tenté d’utiliser cette méthode pour une mise à jour.
Comme nous l’indiquions dans notre article, une mise à jour majeure de Prestashop ne peut pas être aussi simple que celle décrite par Prestashop. Pour s’en rendre compte, vous pouvez consulter notre procédure pour une mise à jour d’un Prestashop 1.6 vers 1.7.
Par contre, l’idée de base qui est de déposer les nouveaux fichiers, les fichiers de mise à jour et lancer la mise à jour nous semblait intéressant pour une automatisation.
Si vous êtes un utilisateur des services de la société OVH pour les serveurs, vous n’avez jamais eu trop de soucis pour envoyer des emails en ligne de commande. En effet, Ovh pré-configure son réseau pour autoriser l’envoi des emails depuis votre serveur nouvellement acquis.
Mais qu’en est il pour configurer un serveur local ? La les choses commencent à devenir un peu compliquées …..
« Pourquoi Prestashop n’utilise pas la bonne grille de frais de port ? » voici la question ou la réponse n’a pas été aussi évidente.
Pour les plus impatient(e)s, voici le lien pour la solution. Pour les autres, voici le contexte qui a tout son importance.