Warning: You are browsing the documentation for PrestaShop 1.7, which is outdated.
You might want to read an updated version of this page for the current version, PrestaShop 8. Read the updated version of this page
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.twig
create.html.twig
edit.html.twig
delete.html.twig
PrestaShop 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 service declaration:
services:
# Good
foo_bar:
class: 'Foo\Bar'
arguments:
- 'baz'
# Wrong
wrong_foo_bar:
class: 'Foo\Bar'
arguments:
- $baz: 'baz'
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_case
ps_linklist
).