Install pandoc

use this script:

FILES=*.rst
for f in $FILES
do
  filename="${f%.*}"
  echo "Converting $f to $filename.md"
  `pandoc $f -f rst -t markdown -o $filename.md`
done

from this link : https://devdocs.prestashop.com/1.7/themes/reference/hooks/

I followed all the instructions but I can't find my new hook among the positions in the back office, until i entered the Database to manually add an entry in ps_hooks table. is this the right way to do ?

or what happened ?

am surprised we cannot do that from the UI of the back office and had to play with the DB.

As spotted in some contributions already, it could be great for everyone to be able to download some modules linked to the tutorials in the documentation.

Also, I'm thinking about a page where people can contribute to and share good community resources.

So my question is the following: are we able to mention and use community modules and resources in the documentation?

Mickaël

In 1.7 version product info page is updating by Ajax but there is no possibility to send data from custom tabs. I mean we can't save data from modules. Maybe it should be some hook or parameter for one that already exists? Or if this method already exists it should be documented better.

Hi there !

Can you tell me how I can have the "id_product" inside the hook "displayBackOfficeDisplayHeader" when I edit a product on the PrestaShop 1.7 version, maybe ?

I think there is no the "Other Modules" section in prestashop 1.7. After I created the appropriate module in /modules directory, not happened to the modules section in back office, but in the Getting Started tutorial you mentioned it appears in the "Other Modules" section. If it is for the prestashop version 1.6 please change this content.

Updating the design of emails is a pain for developers, most notably because header and footer cannot be included as-is.

We at PrestaShop have built specific modules for that:

• 1.6: https://github.com/PrestaShop/emailgenerator
• 1.7: https://github.com/PrestaShop/ps_emailgenerator

It's high time we document them properly!

New version come with a lot of change; for example, in module ps_featuredproducts, you use
use PrestaShop\PrestaShop\Core\Module\WidgetInterface;
use PrestaShop\PrestaShop\Adapter\Category\CategoryProductSearchProvider;
use PrestaShop\PrestaShop\Adapter\Image\ImageRetriever;
use PrestaShop\PrestaShop\Adapter\Product\PriceFormatter;
use PrestaShop\PrestaShop\Core\Product\ProductListingPresenter;
use PrestaShop\PrestaShop\Adapter\Product\ProductColorsRetriever;
use PrestaShop\PrestaShop\Core\Product\Search\ProductSearchContext;
use PrestaShop\PrestaShop\Core\Product\Search\ProductSearchQuery;
use PrestaShop\PrestaShop\Core\Product\Search\SortOrder;

It s very hard to understand... could you provide an explanation step by step ?

Just as we did for previous version:

• http://doc.prestashop.com/display/PS14/Fundamentals#Fundamentals-Databaseschema
• http://doc.prestashop.com/display/PS15/Fundamentals#Fundamentals-Databaseschema
• http://doc.prestashop.com/display/PS16/Fundamentals+of+PrestaShop+Development#FundamentalsofPrestaShopDevelopment-Databaseschema

Here's a good source of inspiration:

https://www.drupal.org/core/issue-priority

We currently have documentation about payment modules, but not about carriers.

Example of details to give:

In case of several carriers created by the same module, how to differentiate their price during getOrderShippingCost ?

By declaring the property id_carrier in the module, and relying on it in the method.

class MyModule extends CarrierModule
{
   /**
    * @var int Current ID carrier in shipping cost calculation
    */
    public $id_carrier;

    public function getOrderShippingCost(...)
    {
        if ($this->id_carrier === /* ID of one of the module carriers */) {
            // Specific calculation for one carrier
        }
    }
}

I've tried to install couple modules and I got "Upload failed" :-(
"Cannot extract module in D:\Web sites (local)\prestashop-1.7/app/cache/prod\sandbox/5805c95e34c28/ to get its name."

Here's a list of things we need to document (the list will evolve in time)

Related to Grid

• How to use reusable Javascript grid Extensions #240
• How to add bulk actions to a grid #244
• How link actions work (see #244 (comment))

Related to Symfony (focus on controller / app layer of the migration)

• Reusable PrestaShop form types
• PrestaShop console commands
• How to create a new page / controller (step-by-step tutorial), listing and CRUD
• How to use composition and SF services to extend PrestaShop behavior
• Overview of the main services being used in PrestaShop
• Twig folder structure and usage
• Prestashop twigs macros and UI-Kit usage
• Thin controller, fat models
• Internal usage of roles for PrestaShop, linked with security
• About Identifiable Objects forms #184
• Improve "settings form" doc (see #184 (comment))
• Reusable PrestaShop form types #245

Related to CQRS (focus on domain / core layer of the migration)

• What is CQRS #232
• Focus on CQRS being used by PrestaShop: legacy handlers layer
• Use of ValueObjects and DTOs (related to CQRS)
• Using Domain Exceptions and how to handle them #255
• What is the usage of Adapter namespace and its content

Related to new Admin Theme

• A zoom on how we use webpack
• Using scss

Related to testing

• Writing unit tests
• Writing behat tests
• Writing puppeeter tests (soon)

This issue has been migrated from the Forge. Read the original ticket here.

• Reporter: pablo.borowicz
• Created at: Wed, 6 Dec 2017 15:09:03 +0100

Reverse engineer and document the way translation works on PrestaShop

• Language packages
• Old xml system
• New xlf system
• Database tables, etc

Hello, how to load custom css and js only from that hook execute. Like in the past if any one want to load js and css from a dynamic hook they didn't load.

<div id="footer">
  {widget name="ps_contactinfo" hook="displayFooter"}
</div>

The goal of this is load different js and css from different widget area, one from home another for special in footer.

Following PrestaShop/PrestaShop#13472 we need to

• explain how to use the Command to obtain Commands and Queries list
• put the list in the doc to help users read it

According guide:
https://www.prestashop.com/forums/topic/549666-guide-the-new-customization-system-in-prestashop-17/

There is problem in new customization system.
If my module creates a custom customization field for product and there is no any other customizations, product.customizable will set to '0' after product update (save).

Code is here:

PrestaShop/src/Adapter/Product/AdminProductWrapper.php

    function processProductCustomization() {
       ........

And that's why even if I set the value of the input #product_customization_id to include the customization in the cart - It not work, because:

PrestaShop/classes/Cart.php

    public function updateQty()
    ...
        if ($product->customizable) {
            return $this->_updateCustomizationQuantity((int)$quantity, (int)$id_customization, (int)$id_product, (int)$id_product_attribute, (int)$id_address_delivery, $operator);
        } else {
            return true;
        }

    ...

Currently, documentation at http://doc.prestashop.com/display/PS17/PrestaShop+1.7+documentation mentions that tests can be used using selenium. Can there be documentation on how to run a phpunit test just to check if the data in a database is what I would expect it to be at time of running the phpunit test.

It'd be great if there were specifics on where to save our test, how to pull in necessary classes correctly, directory structure, etc.

My final goal is to run a phpunit test that indicates whether or not my module can insert orders into the database correctly.

Document Kpi hooks added in this PR: PrestaShop/PrestaShop#12706

The file catalog.html.twig of your example must be located in

PrestaShop/Admin/Product/CatalogPage

of the module and not in

PrestaShop/Admin/Product
as written.

Regards

Not sure where best to put this, but the features page of prestashop.com states it has features to 'reinsure' users. The actual word should be "reassure"

So, it's easier to review and spot every error for each contribution.

There are many ways to do it, but this is a documented one => https://medium.com/akeneo-labs/how-platform-sh-can-simplify-your-contribution-workflow-on-github-6e2a557a1bcc

The Tab don't manage Symfony routes, so in order to add such tabs you need to hack a little:

• you need to have a _legacy_link on your route and use it as your class_name parameter
• you must add your Tab mannually (using new Tab)

This hack needs to be documented, unless PrestaShop/PrestaShop#12640 has been managed in the 176.

As third party module developers, it is useful to be given context for learning how the inner workings of the core function.

As a developer, I tend to look inside classes for method that I might need. When I can't find how to do something, I look online, but with PrestaShop there just isn't much there.

There are two key examples: as mentioned in #24 there are important things to know about ObjectModel, but without a comprehensive and time consuming learning of the whole system, it's not easy to reason about. A contextual explanation would go a long way to educate developers.

Another one that is very important is PrestaShopCollection, which is practically undocumented. You have to look at the code (core and native modules) to know how to use it. It can solve many issues, for example when I had to develop a module that augments Cart Rules, I found that there is no direct method to get all the Cart Rules, so I had to resort to hand-writing queries, that IMHO is an anti-pattern for such a basic thing like querying Core objects. Also, other classes have "get" methods that return multidimensional arrays straight from database rows, others return objects. From what I could see, it would be PrestaShopCollection that adds the necessary consistency, à la jQuery objects… am I correct?

I think documentation should explain these areas better.

Currently, we only have a webservice documentation and tools in PHP.

Having calls examples using other programming languages seems to be useful.

Describe the bug
The devdocs list of hooks lists the former 1.6+ displayOrderConfirmation params.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://devdocs.prestashop.com/1.7/modules/concepts/hooks/list-of-hooks/'
2. Scroll down to 'displayOrderConfirmation.'
3. See params as:
   array( 'total_to_pay' => (float) Total amount with tax, 'currency' => (string) Currency sign, 'objOrder' => (object) Order, 'currencyObj' => (object) Currency );
4. The actual params are order, cookie and cart objects.

Screenshots
Screenshot: https://i.imgur.com/5uWDNeQ.png
Additionnal information
PrestaShop version: 1.7.5.0
PHP version: 7.1+

from @prestarocket on Gitter:

is there any documentation for the new "logic" ( CategoryProductSearchProvider, ProductSearchQuery, ProductSearchContext etc...) ?

In Prestashop V1.6 we were using $this->pagination() function in module front controller. This function removed in V1.7. How we can implement pagination now in module?

Is your feature request related to a problem? Please describe.
The current documentation isn't clear (https://devdocs.prestashop.com/1.7/development/architecture/migration-guide/forms/)

PrestaShop/PrestaShop#11926 - This isn't the reply i would like either. A) That is for a legacy module B) The Main Forums seem slow/inactive C) Stackoverflow, no one replies as they don't know either.

Describe the solution you'd like
A full "Modern" module that we can download/install and view the source. A module that adds a new field to the product admin page. When the admin product page is loaded, it will load this new fields data, also when the product is saved it will save that field data. Would also be good to render the result to a twig template.

Additional context
The Prestashop documentation isn't the best (It's okay, but seems rushed tbh)

I'm developing/testing out creating new modules for PS. Symfony isn't the problem. Mainly its the best practices we need to learn and how Symfony and PS mix together, ready for current and future versions of PS. Currently from the dev docs it looks like we need to work in "src/PrestaShopBundle..." but how does that relate to a "Module", hows the install handled, or are all files meant to be within the module folder?

Basically, if a PS dev could knock up a quick module for us to download (Described above) it will answer 100's of questions in one go 👍

Does not work - please update for PS v1.7.5:
https://devdocs.prestashop.com/1.7/modules/concepts/controllers/admin-controllers/tabs/

We can alter the behavior of the grid when no data are retrieved from query builders.

Ping @sarjon, you can complete an existing article or create your own: as you like.

Hi,
I need the category name appears in product page. I try to find the variable in the code of ps_categorytree.tpl and I guess that's it: {$node.name}. I paste this variable in product.tpl but it doesn't work. Can you help me? Thanks a lot

Coding standards are the same for modules and core.

Currently, this can only be found in the Core chapter. We should add a link from the modules chapter.

Hi,

I think the name of the option property 'route_param_name' in ToggleComumn Type (https://devdocs.prestashop.com/1.7/development/components/grid/columns-reference/toggle/) is wrong

The good options property is 'route_param_id'

Regards,

PYT

I get more and more questions about how the best way to handle a staging environment and a production environment for a PrestaShop, all of it versioned into git.

Additionnal questions are:

• how to handle upgrades using git*
• how to setup continous integration
• how to setup continuous deployment

*Several developers asked the following:
"I have a staging environment and a production environment.
If I run the auto-upgrade module on staging, this will upgrade both the code and the database of staging. Then I commit the new file structure into git. However if I pull these changes into production, I have in production an environment with up-to-date code but outdated database."

⏩ the real issue is actually "how to handle database upgrade and code upgrade separately"

Another issue which is kinda related: some developers wonder whether they should use the release zip archive of the github release tag:

The release zip archive contains a zipped ready-to-use prestashop application however if the developer wishes to develop on top of it, it lacks some dev features such as the tests, the composer.json file ...

The release tag on github has all of these dev tools but need some processing to be production-ready.

Add new hooks from EmailGenerator
see PrestaShop/PrestaShop#12046

Initially posted to: http://forge.prestashop.com/browse/PSCSX-8318

In Gitter chat it was noted that it is an important feature for multi-store shops (sharing product with different features and price). Since this is the case, I guess it would be important to document for third-party module developers how to behave and how to deal with the tables. Also, the tables are present and written to even if multi-store was never enabled.

We have to override list_content.tpl for now to list and image from module folder. Currently, PrestaShop have defined renderList for its own PS folder.

TLDR;

$ docker run --name travis-debug -dit travisci/ci-garnet:packer-1512502276-986baf0 /sbin/init
$ docker exec -it travis-debug bash -l 
// in docker
$ su - travis
// as travis user
$ git clone --depth=50 https://github.com/PrestaShop/PrestaShop.git PrestaShop/PrestaShop
$ cd PrestaShop/PrestaShop/
// 11321 is PR number
$ git fetch origin +refs/pull/11321/merge
$ git checkout -qf FETCH_HEAD
$ cp travis-scripts/.composer-auth.json ~/.composer/auth.json
$ bash travis-scripts/setup-php-fpm.sh
$ bash travis-scripts/setup-apache.sh
$ cp tests-legacy/parameters.yml.travis app/config/parameters.yml
$ composer install --prefer-dist --no-interaction
$ bash travis-scripts/install-prestashop
$ bash tests-legacy/check_phpunit.sh

Thanks for the tip @matks

I want to write documentation about the lite display mode that will be enabled in SF pages with PR PrestaShop/PrestaShop#12897.

I'm wondering how do I write it 🤔. In some "layout features" part ? In "what you can do with BO pages" part ? Where would it belong ?

I also thought maybe we could write doc about any BO (and soon FO) page that has some trick in it. So if I follow this idea, it would be a "Order page insights" part where we would explain how this page is different from the other, what kind of code is related to it, and the "lite display" mode being used there.

Current menu structure is more or less weird, it seems that topics are randomly put in any location that seems "most appropriate".

Some rules should be defined:

1. What is "Core development"? What can be considered as "Core development"? What should be at the root of this section? Same for "Modules" and "Themes" sections.

My suggestion for menu (it's more like "big picture" without much details):

1. Basics
   • Introduction
   • Installation
2. Core development
   • Standards & conventions
     • Coding standards
     • Naming conventions
   • Architecture
   • Components
     • Grid
   • Testing
     • Unit tests
     • BDD tests
     • E2E tests
   • CLDR
   • Database
   • Webservice
3. Module development
   • Getting started
     • Legacy Admin controllers
     • Symfony admin controllers
     • Front controllers
   • Testing
   • Hooks
   • Payment modules
   • Shipping modules
4. Theme development
   • Getting started
5. Contribute
   • Code
   • Documentation
6. Cookbook (Scale previously)
   • Optimization
     • How to benchmark PrestaShop?
     • How to optimize PrestaShop?

Some things that could be improved:

1. Core changes should not be under "Modules" section. Maybe there should be "Changelog" as separate section to document BC breaks & most notable changes (just an idea).
   https://prnt.sc/n9xd6y

2. I think that "Documentation" section should not be part of Documentation itself. It's mainly about contributing to Docs, so I think it should be moved under "Contribute".
   https://prnt.sc/n9xl50

3. There should not be "How tos" at the root of "Core development". These are very small topics thus should be under some subsection, for example "Cookbook", like:

• Cookbook

  • Email
    • How to send e-mails?

  https://prnt.sc/n9xo72

4. Side menu levels are not easy to follow. Maybe styling should be improved or maybe dropdowns added, not sure. :/
   https://prnt.sc/na0xrm

when Logistician user try to configure module for his own store then this error is generated

SmartyException in smarty_internal_templatebase.php line 129: Unable to load template file =>inside admin folder ==>'/themes/default/template/content-legacy.tpl'

url for the regeneration ==> /index.php?controller=AdminModules&configure=googleshopping&token=

We expect to have new chapters on the documentation about

• Upgrade (to another minor version)
• Migration (to another major version)

A draft is currently in work in progress on Google drive, before being imported on this repository.

Reviews and comments are already welcomed: https://docs.google.com/document/d/10bntisRK5V_v-1nrR5_GY1r6nnz_tPZPC2u5MfjUVIE/edit?usp=sharing

It would be nice to have it documented, which I'll do as a common courtesy :)

The goal:

In my MYMODULE_NAME.php, I'm setting up the public tabs property:

public $tabs = [
        [
            'name'              => 'Referify',
            'class_name'        => 'AdminWithdrawRequests',
            'visible'           => true,
            'parent_class_name' => 'SELL',
        ],
        [
            'name'              => 'Withdraw Requests',
            'class_name'        => 'AdminWithdrawRequests',
            'visible'           => true,
            'parent_class_name' => 'AdminWithdrawRequests',
        ],
    ];

I'll update the documentation to show a better example once I figure this out. I tried omitting "parent_class_name" from the Referify tab's options to see if it would do what I want.

I translate the documentation. What do you need to do to get the documentation to the main site?