Skip to main content

The PrestaShop 1.7 file structure


The PrestaShop developers have done their best for clearly and Inference separate the various parts of the software.

Here is how the files are organized:
·      /admin: Contains all the PrestaShop files pertaining to the back office. When you accessing this folder with any browser, you will be asked to provide proper identification, for security reasons. you should make sure to protect that folder with a .htaccess or .htpasswd file  (You can customized  the name on installation)
·      /app: NEW IN 1.7.
·      /cache:  There are temporary and generating folders used to reduce the load of the server.
·      /classes: The Prestashop object contains all the files related to the model (some are used for the front office, for other back offices). Each file represents the PHP class and its contains methods / properties
·      /config: All of the PrestaShop configuration files are included in this folder until you are asked, you should never change them, as they are directly controlled by the installer and back office of PrestaShop.
·      /controllers: All files in Prestashop controllers - such as the Model-View-Controller (MVC), software architecture used by PrestaShop Each file controls the specific part of PrestaShop.
·      /docs: Some documents, licenses, and sample import files are included. Note: It must be deleted in the production environment.
·      /download: Includes your virtual products, which can be downloaded by the payer for it. Files are stored with the MD5 filename.
·      /img: Includes PrestaShop's default images, icons and picture files - that is, it is not related to the theme. This is where you can find pictures for products categories (/ c sub-folders), those products (/p sub-folders), and back office itself (/ admin subfolders)
·      /install: All files related to the installer of PrestaShop are required to be deployed after you install it to increase security.
·      /js: Most javascript files that are not connected to themes include most of the back office. This is also what you will get jQuery framework.
·      /localization: All Localization Files of PrestaShop - that is, information such as currency, language, tax rules and tax rules groups, states and various units used in the selected country (i.e. volume in liter, weight in kilograms, etc.)
·      /mails: All HTML and text files related to e-mails sent by PrestaShop are included. Each language has its own special folder, where you can edit your content manually if you want it. PrestaShop is a tool for editing your e-mails, which are located in the back office, in Localization> Translation Page
·      /modules:  All contains PrestaShop modules; each has its own folder. If you want to remove a module definitely, uninstall it from the back office, then you should delete its folder.
·      /override: This is a special folder that appeared in PrestaShop 1.4. Using PrestaShop's regular folder / filename convention, files that override default classes or controllers of PrestaShop can be created. This allows you to change PrestaShop core behaviour, without touching the original files, which keeps them safe for the next update. Note: Recommendations are not recommended for auditors modules that you want to distribute / sell, and are strictly prohibited in partner modules. Keep them for your own shop.
·      /pdf: The PDF file contains all the template files (.tpl) related to the firm (invoice, delivery slip, etc.). Replace these files to replace the PDF files created by PrestaShop.
·      /src: NEW IN 1.7. It includes architecture files that include Symphony Framework, Legacy Framework and Adapter Classes.
·      /tests: NEW IN 1.7. has automated tests This folder is not part of the public archive.
·      /themes: It has all the themes currently installed; each has its own folder.
·      /tools: External resources that were compiled in PrestaShop. For instance, this will get you a Smarty (template engine), TCPDF (PDF file generator), swift (mail sender), peer XML parser (PHP Tool), etc.
·      /translations: There is a sub-folder for each available language. However, if you want to change the translation, you must use PrestaShop internal equipment, and do not edit it directly in this folder.
·      /travis-scripts: NEW IN 1.7. Includes Travis-Spasic Scripts. This folder is not part of the public archive.
·      /upload: There are files that will be uploaded by clients for custom products (for example, a picture that a client wants to print on a mug).
·      /vendor: NEW IN 1.7. Contains various 3rd-party tools and frameworks that are used by PrestaShop, such as Composer, cURL, Doctrine, etc.
·      /web: NEW IN 1.7. There are various web-server-specific files, such as favicon.com or robots.txt. This folder is not part of the public archive.
·      /webservice: There are files that enable third-party applications to access PrestaShop via its API.
·      /route: folders that were removed between 1.6 and 1.7:
·      /css: All CSS files that are not attached to themes are included - therefore, this is mostly used by Prestesh Back Office, and has now been moved to the theme.css file in / admin / themes / new-theme / public. Folder
·      /log: The log files generated by PrestaShop in different stages, for example, during the installation process

Comments

Post a Comment

Popular posts from this blog

As a symfony developer what you should take care when symfony standard edition is legacy:

Now  symfony standard edition is legacy . So no need to worry much just go threw article and understand whats new in symfony 4 if standard edition is legacy now. This is the main difference in Symfony 4 from symfony 2 and symfony 3 . Older symfony versions provide by default doctrine, twig, form, validation, profiler, annotations and many other components. But some time user do not want to use it. Suppose what if user do not want to doctrine or twig? Still he has doctrine and twig in his dependency. That makes symfony heavy framework. When starting a new project developers do not like to assemble things manually. So symfony 2 and 3 provides standard edition for developers to start a big project. But was hard to scale down project and decrease dependency if user do not require some packages. Symfony 2 and 3  are big success and in years developers are now aware with composer and dependency injection. So adding/removing a new package is not a big deal. So symfony chose...
Post a Comment
Read more

3 Node.js Alternatives To WordPress

3 Node.js Alternatives To WordPress As compare to WordPress there is alternative option like Node.js. There are many various latest challengers that have large communities, support themes, plugins and are easy to install on your own server. Here are 3 you might want to checkout. KeystoneJS KeystoneJS is a content management system and framework to build server applications that interact with a database. It is based on the Express framework for Node.js and uses MongoDB for data storage. It represents a CMS alternative for web developers who want to build a data-driven website but don’t want to get into the PHP platform or large systems like WordPress. EnduroJS Enduro.js offers a fast and easy way to build your project, beautiful and simple admin UI and integrated tools to build everything on the server. It works without a database, instead relying on a system of flat files that can be opened directly in a text editor. It is easy to install and can be deployed via Git. ...
Post a Comment
Read more

Laravel: How to protect .env files?

.env files: If you develop your applications using Laravel, you probably use .env files every day in your development life. We use these files to store the most secret information of our application. Be it database credentials, the application key or any third-party service credentials. So simply put: We do not want anyone to get access to these files! But the truth is: quite a few .env files are accessible. And I don’t mean that they are accessible by some hackers, but by Google. To search for public .env files, all you need to do is google for one of these terms: DB_USERNAME filetype:env DB_PASSWORD filetype:env APP_DEBUG filetype:env Secure your .env files The reason that these .env files are accessible and also get scraped is because of two things: Misconfigured shared hosting The .env file has the wrong access rights Shared hosting If you use shared hosting, please make sure that the root folder of your Laravel application is not accessib...
Post a Comment
Read more