PrestaShop configuration, Smarty compilation
Naturally, PrestaShop is designed to give a protected and stable climate to both the shop chairman and the clients.
As an engineer, there are a few changes that you could and ought to bring to the default establishment to help you code better, spot bugs quicker, and by and large make an extraordinary PrestaShop item.
Disabling the cache and forcing Smarty compilation
At the point when your advancement affects the front office, regardless of whether you are building a subject or essentially a module which shows data to the client, you should compel the format document assemblage and incapacitate the reserve, in order to consistently see the consequence of your progressions straightforwardly.
Go to the “Execution” page under the “Progressed boundaries” menu to change the accompanying Smarty settings:
- Format reserve: change it to “Power aggregation”
- Reserve: cripple it
Compelling the arrangement of Smarty will in every case hinder the stacking season of the page. Ensure that your creation store is set to just recompile formats if there are refreshed records, and that its reserve is empowered.
Showing mistake messages
PrestaShop’s default settings forestall the client to perceive any worker blunder message or any troubleshooting code.
You, then again, need this data to address any expected slip-up in your code. Keeping that in mind, open the /config/defines.inc.php document, and alter it to set _PS_MODE_DEV_ to true:
<?php
/* Debug only */
define('_PS_MODE_DEV_', true);
You can likewise empower designer mode straightforwardly from your back-office, go to the “Execution” page under the “Progressed boundaries” menu and change the accompanying setting: “Troubleshoot mode” to “Yes”. Remember to debilitate designer mode when you’ve done investigating your code.
Utilizing the dump() work
PrestaShop used to have custom investigate capacities accessible for designers: p($variable) and d($variable). They were utilized to show the substance of a variable, and were actually a covering around the notable print_r() strategy. What’s more, PrestaShop had the ppp() and ddd() capacities, which were separately the monikers of p() and d(); and the different fd(), epr() and dieObject() capacities.
The entirety of this has changed with PrestaShop 1.7: we currently depend exclusively on Symfony VarDumper’s dump() work. You would now be able to depend on a solitary capacity as opposed to having various investigate capacities. The landfill() work is amazing, and is consistently accessible on yield (even without die()). Additionally, you can utilize it in your reassure contents since this capacity likewise has a formatter in CLI mode.
The dump() work isn’t enacted as a matter of course. To initiate it, you should empower the Debug mode, by setting _PS_MODE_DEV_ to true (see above).
Empowering the multistore mode
Since variant 1.5, PrestaShop can have more than one store inside a solitary establishment of the product. Many shop heads decide to empower this element, and it can altogether affect the manner in which PrestaShop works. You ought to in this manner ensure that anything you code for PrestaShop works in both single and multistore mode.
Empowering the multistore mode is simple: go to the overall inclinations page, and put the “Empower Multistore” alternative to “Yes”.
You can switch to and fro between single store and multistore mode. In single store mode, just the fundamental store is utilized.
You can peruse more about the multistore mode in PrestaShop 1.7 User Guide.
About the setup documents
There are four principle setup records, three situated in the /config envelope:
- config.inc.php
- defines.inc.php
- smarty.config.inc.php
and one based in the /app/config folder:
- parameters.php
config.inc.php
It is the fundamental arrangement record for PrestaShop. You ought not need to contact anything in there.
defines.inc.php
This record contains PrestaShop consistent qualities.
It likewise contains the area of the relative multitude of records and envelopes. In the event that you need to change their area, remember to keep the first way close by, for example in a PHP remark, on the off chance that you need to return to it later on.
When being developed/test mode, you should ensure that all the blunder messages are shown:
- Set define(‘_PS_MODE_DEV_’, false); to true.
Unexpectedly, when underway mode, you should shroud blunder messages however much as could be expected!
- Ensure that define(‘_PS_MODE_DEV_’, false); is set to false.
You can supersede steady qualities from this record by setting them in /config/defines_custom.inc.php. This is likewise an incredible spot to put your custom constants which should be accessible around the world in the framework.
smarty.config.inc.php
This document contains all the Smarty-related settings.
The Smarty store framework ought to consistently be debilitated, as it isn’t viable with PrestaShop: keep
$smarty->caching = false; all things considered.
$smarty->compile_check ought to be left to false being developed mode.
$smarty->debugging offers admittance to Smarty investigate data while showing a page. That setting is all the more effectively adjusted in the “Execution” page of the high level boundaries menu : the “Troubleshoot comfort” alternative empowers you to pick between never showing Smarty’s investigate data, continually showing it, or possibly showing it when you add ?SMARTY_DEBUG to the URL of the page you need to test, which can be valuable.
When underway mode, $smarty->force_compile should be set to false, as it will give a 30% lift to your page load time.
Then again, when altering a .tpl document, you should erase the /var/cache/(dev|prod)/smarty/compile organizer (with the exception of the index.php record) to see your progressions applied or clear reserve straightforwardly from Back-Office.
Note that this setting can be made straightforwardly from the back office, in the “Execution” page under the “Progressed boundaries” menu.
parameters.php
This record contains some of significant settings, for example, information base association subtleties and storing system. In the event that you change something in this record, make a point to erase store documents physically from/var/reserve/(dev|prod) envelope.
Cripple the Back-Office token security
Back-Office pages require the utilization of a token. If necessary, this assurance can be debilitated utilizing a climate variable:
Apache settings with mod_headers
SetEnv _TOKEN_ disabled
Nginx with ngx_http_headers_module configuration
add_header _TOKEN_ disabled;