As with Coding standards, naming consistency is very important in PrestaShop, thus there are conventions that every PrestaShop contributor should follow.
PrestaShop controllers follow these naming conventions:
SomethingController).CustomerController, ProductController).Actions follow these conventions:
deleteAction).editAction(), savePrivateNoteAction() are good examples, but formAction() or processAction() are not clear enough.indexAction.indexAction: displays the listing (in Object-type controllers like CustomerController) or a form in configuration controllers.createAction: shows the object’s creation form page and handles the form submiteditAction: shows the object’s edit form page and handles its submitdeleteAction: deletes an itemFor a complete example see code below.
<?php
// CustomerController.php
namespace PrestaShopBundle\Controller\Admin\Sell\Customer;
// Controller name is prefixed with Customer in singular form
class CustomerController
{
// Index page which is opened when
// user clicks "Improve > Sell > Customers" in side menu.
// It shows list of customers and KPIs.
public function indexAction()
{
}
// Customer Edit page which is opened when
// user clicks "Edit" action on selected customer.
// It shows customer form with data that can be edited.
public function editAction($customerId, Request $request)
{
}
// Deletes given customer.
// Does not show page, but returns flash message with redirect instead.
public function deleteAction($customerId, Request $request)
{
}
// Transforms guest customer (customer without password)
// to customer with password.
// Does not show page, but returns flash message with redirect instead.
public function transformGuestToCustomerAction($customerId, Request $request)
{
}
// Saves private note for customer, that can only be seen by admin in Back Office.
// Does not show page, but returns flash message with redirect instead.
public function savePrivateNoteAction($customerId, Request $request)
{
}
// Toggle the status of given customer.
// Does not show page, but returns flash message with redirect instead.
public function toggleStatusAction($customerId)
{
}
}
PrestaShop templates follow these naming conventions:
CustomerController:viewAction() action, then your template name should be view.html.twig.<?php
// CustomerController.php
namespace PrestaShopBundle\Controller\Admin\Sell\Customer;
use PrestaShopBundle\Controller\Admin\FrameworkBundleAdminController as AbstractAdminController;
class CustomerController extends AbstractAdminController
{
// Our action name is "view", thus our
// template name is "view.html.twig".
public function viewAction()
{
$this->render('@PrestaShop/Admin/Sell/Customer/view.html.twig');
}
}
For a typical CRUD page, you should have these template names:
index.html.twigcreate.html.twigedit.html.twigdelete.html.twigPrestaShop routes follow admin_{resource}_{action} naming structure.
{resource} is the object’s name in plural form (e.g. customers, products, orders).{action} name should match the controller’s action name (without the “Action” suffix).GET, POST).{resource} as prefix (root) of the controller’s routes (e.g. /customers/foo, /customers/bar)./{resource}/{resourceId}/{action} naming (e.g. /customers/23/edit)./customers/{customerId}/ instead of /customers/{id}/).If we were to create CRUD routes for Customer, this is how it would look like:
admin_customers_index, with URL /customers and responds to GET method.admin_customers_create, with URL /customers/new and responds to GET and POST methods.admin_customers_edit, with URL /customers/{customerId}/edit and responds to GET and POST methods.admin_customers_delete, with URL /customers/{customerId}/delete and responds to POST method.Example of implementation for Customer routes:
# src/PrestaShopBundle/Resources/config/routing/admin/sell/customer/_customer.yml
_catalog:
resource: "customers.yml"
# route urls defined in "customers.yml" file will be prefixed with "/customers"
prefix: /customers/
# src/PrestaShopBundle/Resources/config/routing/admin/sell/customer/customers.yml
admin_customers_index:
path: /
methods: [GET]
defaults:
_controller: PrestaShopBundle:Admin/Sell/Customer/Customer:index
admin_customers_edit:
path: /{customerId}/edit
methods: [GET, POST]
defaults:
_controller: PrestaShopBundle:Admin/Sell/Customer/Customer:edit
requirements:
customerId: \d+
admin_customers_transform_guest_to_customer:
path: /{customerId}/transform-guest-to-customer
methods: [POST]
defaults:
_controller: PrestaShopBundle:Admin/Sell/Customer/Customer:transformGuestToCustomer
requirements:
customerId: \d+
Service ids should follow the fully-qualified class name of the registered class. See example below.
<?php
// src/Core/Payment/PaymentOptionFormDecorator.php
namespace PrestaShop\PrestaShop\Core\Payment;
class PaymentOptionFormDecorator
{
// ...
}
services:
# service id follows fully-qualified class name
prestashop.core.payment.payment_option_form_decorator:
class: 'PrestaShop\PrestaShop\Core\Payment\PaymentOptionFormDecorator'
Do NOT use “named argument” syntax in your front services declaration:
services:
# Good
foo_bar:
class: 'Foo\Bar'
arguments:
- 'baz'
# Wrong
wrong_foo_bar:
class: 'Foo\Bar'
arguments:
$baz: 'baz'
If you do try to use named arguments in your front services definition you will end up with the following error:
Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\RuntimeException: Invalid service “wrong_foo_bar”: class “Foo\Bar” does not exist.
PrestaShop comes with a lot of Grids (Products, Customers, Orders & etc) and keeping consistency between them is very important, thats why it follows these naming conventions:
snake_caseps_linklist).