Matt75

Hello I guess you have something not working as expected on your shop cause others payment modules are well available in addition to PrestaShop Checkout at payment step. See screenshots bellow. What is your version of PrestaShop ? What is your theme, name and author ? You can contact customer service at [email protected] This forum is for open source project and modules from open source project. PrestaShop Checkout is a commercial module outside the open source project. So please contact customer service. Only one feature hide others payment methods on payment step, it’s when customer click on an ExpressCheckout button from product page, cart page or first step of checkout page. When customer start an ExpressCheckout session, he pre-approve a PayPal payment then he is redirected to your checkout page to choose a shipping method, once shipping cost are calculated, pre-approved payment is updated and at payment step customer can only see PayPal as payment method to finalize the payment with his pre-approved payment. One feature missing here: to be able to cancel this pre-approved payment to be able to choose another payment method. Once this pre-approved payment is completed, customer can pay with others payment methods for next new cart. ExpressCheckout is an optional feature, disabled by default that’s can be enabled from Customization settings. If you encounter issues with ExpressCheckout you can disable it and use standard payment. So by default, all others payment methods as same behavior of each payment methods. Customer can select a radio button on payment step to choose a payment method: one purposed by PrestaShop Checkout or one from another payment method like Bank Wire, Cash on Delivery, Stripe, Amazon Pay or every others payment options provided by others payment module. PrestaShop Checkout use a hook that’s allow payment modules to override default submit button to replace it from a PayPal SmartButton, this hook should change content of confirm order button by a custom submit button depending on selected radio button of payment options. Some themes are known to have a bad implementation of this hook called "displayPaymentByBinaries", so maybe it’s your issue ? Here some screenshot with default PrestaShop theme: Payment step without ExpressCheckout and no payment option selected ------------------ Payment step without ExpressCheckout and another payment option from another payment selected (Worldline module) ------------------ Payment step without ExpressCheckout and another payment option from another payment selected (ps_bankwire module) ------------------ Payment step without ExpressCheckout and a payment option from PrestaShop Checkout selected (PayPal) ------------------ Payment step without ExpressCheckout and a payment option from PrestaShop Checkout selected (PayPal Pay Later) ------------------ Payment step without ExpressCheckout and a payment option from PrestaShop Checkout selected (PayPal Card) ------------------ PrestaShop Checkout customization settings to enable Express Checkout ------------- ExpressCheckout button on product page - disabled by default, must be enabled from customization settings of PrestaShop Checkout -------------- ExpressCheckout button on cart page - disabled by default, must be enabled from customization settings of PrestaShop Checkout -------------- ExpressCheckout button on first step of checkout page - disabled by default, must be enabled from customization settings of PrestaShop Checkout -------------- ExpressCheckout payment step with only PayPal payment option - disabled by default, must be enabled from customization settings of PrestaShop Checkout At this step, customer has already a pending pre-approved payment with PayPal using ExpressCheckout and he can only finalize this payment. A feature is missing here: customer should be able to cancel this pre-approved payment to choose another payment method. This feature is planed in backlog but not yet available. If this behavior doesn't meet your needs, you can disable ExpressCheckout feature. You can contact customer service at [email protected]

Hello I guess you have something not working as expected on your shop cause others payment modules are well available in addition to PrestaShop Checkout at payment step. See screenshots bellow. What is your version of PrestaShop ? What is your theme, name and author ? You can contact customer service at [email protected] This forum is for open source project and modules from open source project. PrestaShop Checkout is a commercial module outside the open source project. So please contact customer service. Only one feature hide others payment methods on payment step, it’s when customer click on an ExpressCheckout button from product page, cart page or first step of checkout page. When customer start an ExpressCheckout session, he pre-approve a PayPal payment then he is redirected to your checkout page to choose a shipping method, once shipping cost are calculated, pre-approved payment is updated and at payment step customer can only see PayPal as payment method to finalize the payment with his pre-approved payment. One feature missing here: to be able to cancel this pre-approved payment to be able to choose another payment method. Once this pre-approved payment is completed, customer can pay with others payment methods for next new cart. ExpressCheckout is an optional feature, disabled by default that’s can be enabled from Customization settings. If you encounter issues with ExpressCheckout you can disable it and use standard payment. So by default, all others payment methods as same behavior of each payment methods. Customer can select a radio button on payment step to choose a payment method: one purposed by PrestaShop Checkout or one from another payment method like Bank Wire, Cash on Delivery, Stripe, Amazon Pay or every others payment options provided by others payment module. PrestaShop Checkout use a hook that’s allow payment modules to override default submit button to replace it from a PayPal SmartButton, this hook should change content of confirm order button by a custom submit button depending on selected radio button of payment options. Some themes are known to have a bad implementation of this hook called "displayPaymentByBinaries", so maybe it’s your issue ? Here some screenshot with default PrestaShop theme: Payment step without ExpressCheckout and no payment option selected ------------------ Payment step without ExpressCheckout and another payment option from another payment selected (Worldline module) ------------------ Payment step without ExpressCheckout and another payment option from another payment selected (ps_bankwire module) ------------------ Payment step without ExpressCheckout and a payment option from PrestaShop Checkout selected (PayPal) ------------------ Payment step without ExpressCheckout and a payment option from PrestaShop Checkout selected (PayPal Pay Later) ------------------ Payment step without ExpressCheckout and a payment option from PrestaShop Checkout selected (PayPal Card) ------------------ PrestaShop Checkout customization settings to enable Express Checkout ------------- ExpressCheckout button on product page - disabled by default, must be enabled from customization settings of PrestaShop Checkout -------------- ExpressCheckout button on cart page - disabled by default, must be enabled from customization settings of PrestaShop Checkout -------------- ExpressCheckout button on first step of checkout page - disabled by default, must be enabled from customization settings of PrestaShop Checkout -------------- ExpressCheckout payment step with only PayPal payment option - disabled by default, must be enabled from customization settings of PrestaShop Checkout At this step, customer has already a pending pre-approved payment with PayPal using ExpressCheckout and he can only finalize this payment. A feature is missing here: customer should be able to cancel this pre-approved payment to choose another payment method. This feature is planed in backlog but not yet available. If this behavior doesn't meet your needs, you can disable ExpressCheckout feature. You can contact customer service at [email protected]

Join us on Slack - PrestaShop Open Source Project Please note this is not a support channel

To be clear here an example (non exhaustive) of what is allowed. For a module named MyModule, this situation is allowed : mymodule/mymodule.php extends Module class or another class based on Module from PrestaShop Core (PaymentModule, CarrierModule, etc...) mymodule/classes/MyObjectModel.php extends ObjectModel class from PrestaShop Core mymodule/controllers/front/myfrontcontroller.php extends ModuleFrontController class from PrestaShop Core mymodule/controllers/admin/MyModuleAdminController.php extends ModuleAdminController class from PrestaShop Core mymodule/src/Adapters/MyLibAdapter.php implements MyInterface class but use dependancies from PrestaShop Core (Context, Tools, ObjectModel...) => this files must be under a compliant licence with OSL likes AFL, EUPL, BSD, MIT, ISC or Apache V2. mymodule/lib/myinterface.php interface without open source dependencies mymodule/lib/MyClass.php class that use MyInterface without open source dependencies => this files can be under another licence likes a commercial licence but has to be clearly identified and isolated on a specific folder. For all files into "lib" folder ("lib" is only an example, it can be "vendor" for example), it's recommended for each files to have a proper namespace, licence header on each file, LICENSE text file at root of this folder. For all others files, they must be under open source licence AFL, EUPL, BSD, MIT, ISC or Apache V2.

Your module will use some classes (Module, Tools, Context, ObjectModel etc...) from PrestaShop Core that's is under OSL licence so you have to be compliant with OSL. It means you have to use a compliant open source licence with OSL likes AFL, EUPL, BSD, MIT, ISC or Apache V2. Generally modules are under AFL for example. If you have some piece of code using another licence, likes a commercial licence, this code has to be isolated from all pieces of code under an open source licence. Code under commercial licence must be on a separate folder, with a proper namespace, licence header on each file, LICENSE text file at root of this folder. You can use an hexagonal architecture thanks to ports and adapters to isolate this code from others pieces of code under open source licence, it means you cannot have a direct dependancy to a class under open source licence and must pass through a Port or Adapter.

Tu mélanges le logiciel et les extensions. Déjà tu as raison, pendant longtemps la licence des modules était pas forcement correcte, il faut rappeler que la plupart des modules que tu as mentionné sont très vieux et la plupart ont été écrit par des juniors ; de plus à l'époque la licence on s'en préoccupait pas vraiment car on était pas formé. Néanmoins, le coeur du logiciel étant en OSL, les modules doivent obligatoirement utiliser une licence compatible, si d'autres licences étaient utilisées précédemment par erreur, nous avons normalement tout corrigé depuis quelques années maintenant en ce qui concerne les modules du coeur et ceux édité par PrestaShop SA. Tu peux trouver par exemple des modules sur Addons et ailleurs qui utilisent par erreur une autre licence, voir des licences commerciales. En réalité, ce n'est pas possible et tu as forcément le droit de le réécrire et de réutiliser le code grâce à la licence OSL. A partir du moment où tu utilises un élément provenant du core (classe Module, PaymentModule, CarrierModule, Db, Tools, etc...) le code qui les utilisent est nécessairement sous licence compatible OSL. La seule manière d'avoir un code avec une licence commerciale dans un module, c'est d'avoir du code qui n'interagit pas directement avec le coeur du logiciel. Par exemple, si tu utilises une architecture hexagonale et que ton code source commercial utilise des interfaces qui sont implémentées par une couche intermédiaire open source qui fait la passerelle entre le coeur du logiciel et ton code source commercial. Exemple avec un module "mymodule" : mymodule/mymodule.php (Doit utiliser une licence compatible OSL) mymodule/LICENCE.MD (recommandé et doit être une licence compatible OSL) mymodule/controllers/admin/AdminMyModuleConfigureController.php (Doit utiliser une licence compatible OSL) mymodule/controllers/front/ajax.php (Doit utiliser une licence compatible OSL) mymodule/classes/MyModuleObjectModel.php (Doit utiliser une licence compatible OSL) mymodule/src/Adapter/DataProviderAdapter.php (Doit utiliser une licence compatible OSL car je vais utiliser des classes du module ou du coeur) mymodule/vendor/mycompany/myproject/LICENCE.MD (recommandé) mymodule/vendor/mycompany/myproject/DataProviderInterface.php (Peut utiliser une licence commerciale) mymodule/vendor/mycompany/myproject/MyCustomService.php (Peut utiliser une licence commerciale car il va utiliser DataProviderInterface mais qui sera implémenté DataProviderAdapter sans interaction direct avec le code source du coeur) Si par le passé, voir même actuellement, des modules sont distribués avec une licence non compatible avec l'OSL, légalement ça ne vaut rien c'est juste que ce sera à ta charge de le démontrer en justice par exemple en cas de litige. Mais la licence du code source du coeur, te donnes des droits. Très peu de module (j'en ai aucun exemple) n'a l'architecture nécessaire pour utiliser une partie de code source commercial actuellement. Chez PrestaShop SA on fait en sorte d'utiliser uniquement de l'open source et donc des licences compatibles avec l'OSL.

On dirait bien que tu fais tout pour ne pas comprendre oui 🤣 On a déjà répondu, inutile d'aller plus loin : le code source n'est pas protégé en dehors de la licence open source et n'appartient pas à PrestaShop SA Le copyright n'est que la mentions des auteurs et contributeurs, dont la liste exhaustive est disponible ici : https://github.com/PrestaShop/PrestaShop/blob/develop/CONTRIBUTORS.md Les droits sont ensuite définis par la licence https://opensource.org/licenses/OSL-3.0

Absolument, le code n'appartient pas à PrestaShop SA, c'est la marque PrestaShop qui est enregistrée et protégée et non le code source Vous pensez mal Nous avons des sujets bien plus prioritaire, votre besoin concerne seulement une fraction des utilisateurs de PrestaShop. Nul besoin d'être développeur pour contribuer au projet, les spécifications ne sont pas des éléments techniques mais fonctionnels. Les utilisateurs ont tout à gagner à prendre part au projet en partageant leur besoin afin de faciliter la priorisation des tâches. Car le besoin que vous remontez n'est clairement pas prioritaire pour nous, nous avons très peu de demande sur le sujet et sur les canaux officiels du projet, ce besoin ne remonte pas souvent. Vous avez bien fait, nous avons déjà de quoi nous occuper plusieurs années sur d'autres sujets plus prioritaires. Le projet open source est supporté à 80% par PrestaShop SA actuellement, mais les ressources internes dédiées sont limitées, l'équipe qui y travaille comporte une dizaine de personnes, n'escomptez donc pas avoir une solution à court terme. Comme je l'ai déjà dit nous avons déjà d'autres besoins plus critiques qui nécessite notre attention. Sans contribution externe, le projet n'avancera pas sur ce point, cela ne veut pas dire que nous ne pouvons pas accompagner les contributeurs externes pour les assister dans la contribution, cela veut simplement dire que nous n'avons pas la capacité de prendre le sujet rapidement nous même faute de ressources nécessaires. Je vous invite à relire la licence logicielle, les conditions générales de ventes et tous les documents à disposition avant de vous exprimer, car vous êtes dans l'erreur. PrestaShop a vocation a rester un logiciel de vente en ligne basique, il n'a pas vocation a gérer de la comptabilité puisqu'il s'agit d'un métier à part entière. Il a certes quelques fonctionnalités dans ce domaine mais qui sont très limitées. Généralement PrestaShop est couplée à des logiciels métiers spécialisés par exemple pour la comptabilité, la gestion des stocks etc... Certes il faut un certain volume pour que ce genre de solution soit accessible néanmoins le projet lui à simplement vocation a offrir des fonctionnalités basiques. Un logiciel de comptabilité il faut beaucoup de monde derrière, des spécialistes notamment, ce pas avec une poignée de personnes qui doit gérer bien d'autres aspects du logiciel que l'on pourra proposer un outil répond à tous les besoins. Peut être en France ou dans votre région, mais ce n'est pas une tendance que nous observons dans notre écosystème au niveau global. C'est assez spécifique tout de même sinon ce besoin remonterait sur d'autres canaux que le forum. --------------------------------------------------------------- Poursuivre cette conversation ici est totalement stérile aucune équipe ne vient sur ce forum, ce n'est pas un canal que nous utilisons. Ce forum est plus la pour l'entraide communautaire, nous n'y intervenons que très peu. Par ailleurs, personnellement je ne suis pas du tout dans l'équipe qui travaille sur le projet open source, je ne peux que faire remonter l'information et pour plus de traçabilité, le faire via les canaux dédiés au projet : GitHub, Slack Open Source et autres que vous pouvez retrouver sur le site dédié au projet : https://www.prestashop-project.org

Oui ce serait déjà un bon début, car ce n’est pas avec cette attitude que vous aller convaincre qui que ce soit de prendre le temps de se pencher sur votre problème. Puisque vous semblez connaître le sujet et avez à disposition quelqu’un qui maîtrise la problématique, vous pourriez déjà contribuer à l’élaboration des spécifications afin d’entrer dans une démarche constructive pour l’ensemble de l’écosystème. Vous n’êtes pas nos clients, le cœur du logiciel n’appartient pas à PrestaShop. Nos clients sont principalement ceux qui achètent nos services sur Addons, principalement pour des services et des extensions. Ce n’est pas le code source que vous payez dans ce cas mais le support, le service et les mises à jour entre autre). Vous confondez le projet open source et l’entreprise, il est vrai que cela porte à confusion mais les choses vont prochainement changer afin notamment d’éviter les incompréhensions de ce genre. Vous pouvez déjà trouver quelques infos sur le replay de la dernière session de démo consacrée au projet open source. https://build.prestashop.com/news/public-oss-demo-9-2021/ Pour ma part, je ne suis pas de cette génération 😅 Je vous encourage à poursuivre votre démarche en changeant d’attitude et en contribuant notamment sur l’élaboration des spécifications, sans quoi je doute qu’elle aboutisse à quelque chose.

Hi @danielsaar Your cache needs to be cleared, please use your FTP access to rename var/cache/prod to var/cache/prod.old then delete var/cache/prod.old (same for dev folder)

Bonsoir, Ce qu’il faut pas lire des fois 😂 Je dirais plutôt que vous avez un soucis de connectivité à PrestaShop Addons, votre réseau est peut être lent et le timeout est dépassé. Cela arrive généralement sur les serveurs un peu chargé au niveau du réseau ou si l’hébergeur se trouve dans une zone mal interconnectée. Essayez d’augmenter le timeout dans le fichier situé sur votre FTP, dans modules/ps_mbo/src/ExternalContentProvider/ExternalContentProvider.php en modifiant la ligne suivante en augmentant à 15 par exemple : https://github.com/PrestaShopCorp/ps_mbo/blob/master/src/ExternalContentProvider/ExternalContentProvider.php#L33 Pour information, une nouvelle version est actuellement en code review et passera prochainement en test par l’équipe qualité : https://github.com/PrestaShopCorp/ps_mbo/pull/100

Pour info, ce sujet a disparu car c'est l'auteur lui même qui l'a caché et non un modérateur, calmez vous donc sur la théorie du complot 🤣

Ce module est toujours proposé gratuitement par PrestaShop Dans le BO > Modules > Module Catalog, rechercher ps_emailalerts (ne pas confondre le - avec le _) si pas trouvé, essayé dans le Module Manager. Pour rappel, le Module Catalog liste les modules non installés, le Module Manager les modules installés qu'ils soient activés ou désactivés

I cannot help you on this, you should contact your hosting provider to be sure you use a PHP version supported by PrestaShop and retrieve error logs, then contact customer service or developer of your payment module. RazorPay module is not developed by PrestaShop and I never use it unfortunately.

Due to introduction of dependencies like some components of the Symfony framework and because we have more restrictions about breaking change in order to keep modules & themes compliant as much as possible. About support of PHP 7.3, please follow https://github.com/PrestaShop/PrestaShop/issues/12461 About support of PHP 7.4, please follow https://github.com/PrestaShop/PrestaShop/issues/16477