Today I starting design theme for prestashop and i'm Beginner on that.
i have a Question about Theme Module
i have Some module for my new Theme Located here:
prestashop/theme/mytheme/Module
and i want customize that for my new theme.
but the prestashop not using My Module instead using default module Located here:
Prestashop/Module/
What's Wrong and how to Fix this?
From the PrestaShop documentation:
Overriding a module's behavior
The modules are usually in the following format:
/modules/my_module/my_module.tpl
/modules/my_module/my_module.css
/modules/my_module/my_module.js
Since PrestaShop 1.5, they can and should also be in the following format:
/modules/my_module/views/templates/front/my_module.tpl
/modules/my_module/views/templates/front/my_module.css
/modules/my_module/views/templates/front/my_module.js
PrestaShop allows you to override or replace certain front-office module files
with new ones within the same theme. The override is governed by the
theme: once it contains a /modules folder (or more!), PrestaShop will
browse its content for files which have the same name and path as
those of existing modules, and replace these with the new ones.
This means, for PrestaShop 1.4-compatible modules:
/themes/my_theme/modules/my_module/my_module.tpl
/themes/my_theme/css/modules/my_module/my_module.css
/themes/my_theme/js/modules/my_module/my_module.js
Since PrestaShop 1.5, the path is slightly longer
/themes/my_theme/modules/my_module/views/templates/front/my_module.tpl
/themes/my_theme/css/modules/my_module/views/templates/front/my_module.css
/themes/my_theme/js/modules/my_module/views/templates/front/my_module.js
In general, the proper path to override a .tpl, .js or .css file
depends on the module's own path. That is the reason why if PrestaShop
1.5 has to work with a module without a view folder, it will need the same override path.
In short, you can keep overriding code in 1.5 just
as you did in 1.4.
The new files will be used when the customer loads
your shop.
Contrary to the override code that is to be placed manually
in the /override folder, module overrides are enabled as soon as the
module is installed. During installation, overriding code is merge
with those already in place (if any), otherwise they are copied to the
/override folder at the root of the PrestaShop folder.
Related
I'm using a theme with testimonial slider in homepage and I've figured out that there in the module folder a file called all_testimonial.tpl and something about an upload form.
So I guess that there is a way to have a page with all testimonials with the upload form.
But I'm not able to understand how could use that tpl.
Do you have any suggestions?
TPL file is a file extension for a template file format in general.
In Prestashop, Smarty is a template parser written in PHP
Take a have a look at these websites
https://www.smarty.net/
https://www.smarty.net/docsv2/en/smarty.for.designers
It would be difficult to answer which module for testimonial slider you are using in theme and which PrestaShop version website is using.
But I would say to have a look at the Prestashop Hooks
To see List of Hooks -> For a full list of Hooks
To see Module Development Changes -> https://build.prestashop.com/news/module-development-changes-in-17/
In recent days, it has become impossible to update the modules. I receive an error such as "this is not a valid module name".
Is it possible to manually update the modules by retrieving the latest files from Github? I tried to replace the files with those of the latest version but, it doesn't change anything at all.
I precise that I try to update official modules that are pre-installed in Prestashop.
Yes you can do this.
Grab the moduble from GitHub, wrap the whole module (the ps_xxxxxx directory) in a zip file then install the module from the admin interface.
Don't replace the files manually by using the filesystem (or at least try not to).
If you replace the modules in the modules directory you won't trigger the module "install" method, so if the new version needs some initialization it won't work properly.
EDIT:
Some modules have dependencies, for example ps_facetedsearch will require you to install composer and run 'composer install --no-dev' before you can pack it into a zip.
Alternatively you can get a json list of native prestashop modules here (replace [VERSION] with the version of prestashop you want, ex 1.7.6.4) :
https://api-addons.prestashop.com/?format=json&iso_lang=en&iso_code=all&version=[VERSION]&method=listing&action=native
Then you can download the module with its id with this URL (replace [VERSION] and [MODULE_ID] :
https://api-addons.prestashop.com/?format=json&iso_lang=en&iso_code=EN&version=[VERSION]&method=module&id_module=[MODULE_ID]
I created a small vue.js library that is using scss for styling and published that as npm package. It works well with a default theme included into the package. But what if I would like to provide a custom theme from the application that consumes that npm package, how would you do that?
The source for a very basic version of the library is here: https://github.com/gwildu/gwi-vue-components
The idea is, that you would copy paste the styling folder somewhere (e.g., into your application directory or into another npm package) and configure the library package to import from that copyied directory.
I did some investigation myself and found that there is a big discussion about having dynamic imports in sass since years. This issue (open since 2013) claims to add such a feature (they call it load). Not sure, how actively sass is still developed and when this feature will be supported. For now I see 3 possible solutions:
move to LESS as it supports dynamic imports. Semantic UI gives you a hint about how theming could be done in LESS
It is possible to import from relative paths in SASS. That way you are also able to import from a parent directory of your package root directory (your application directory) like, e.g., #import '../../theme/index';. You would support somewhere in your package an example of a theme that the consumer then would have to copy to, e.g., the root directory of his application and adjust it to his needs. In your package you would then import the theme from that directory in the consumers application folder. The downside is, that the package would not work out of the box
You have a default theme in your package and you add some instructions into the readme how the user can override that theme in a build script. The consumer would have to copy the default theme to his application directory, adjust it to his needs and in the build script he would replace the theme in, e.g., node_modules/your-library-package-folder/theme/ by the theme in your application folder.
To be complete here is the approach with a dynamic import (that is not yet supported by SASS):
In your main theme file in the library package (that would be imported by the components) you would do a relative import of kind of a config file from the consumers application folder like in approach 2 (see above) but that config file yould not contain the theme but only the import path of the theme in a variable. that variable then would be used by the package main theme file to import the theme. For making the library work out of the box, I guess there would be a way to have a default theme as backup if the config file in the consumers directory would not exist (not tested)
Update:
I tried approach 3 but failed to get something useful. The issue with that approach is that you would have to somehow sync your custome theme with the default theme when you update the library to a higher version which might get too complex to handle in a reasonable way. Then I tried to use the overwrite feature of SASS as described here: How to overwrite SCSS variables when compiling to CSS which led me to approach
In your library component you first import a file with possible custom variables and you declare your variables in the library as default.
The issue with that approach is that SASS does not support optional imports. The file with the custom variables have to exist somewhere. So if the library updates you again have to sync your custom theme files for each component / file that was changed in the library. Apparently SASS also don't want to support such a feature in the future: https://github.com/sass/sass/issues/779 which is sad, as it seems to me an essential feature for being able to do theming without a highly complex build step.
Overall, it seems SASS itself is making every effort to prevent a simple theming approach which makes me think of moving back to LESS again. Not having a simple way for static theming in SASS in my opinion outweight the cons of not having an easy way to define custom functions in LESS.
I read many similar issues about "reset", or "uninstall" and "install" of a module being in development in Prestashop 1.7 (like here or there).
Basicaly I have overridden files in [prestashop project]/modules/[custom module]/override/classes/ and [prestashop project]/modules/[custom module]/override/controllers/front/. All my files respect convention:
<?php
class [Class to be overridden] extends [Class to be overridden]Core {
....
}
?>
In [prestashop project]/override/classes/ or [prestashop project]/override/controllers/front/ my files are copied from [prestashop project]/modules/[custom module]/override/... often with mistakes: like bracket {} mitakes (not existing in the source file) that are not opened/closed correctly making the class useless.
So, I delete manually the miscopied files in [prestashop project]/override/... and launch some "reset" action.
I'll add, that after manual delete I often see this issue in the Symfony log when trying to "reset" the custom module:
Exception thrown by module [module name] on install. Class [overriden file]OverrideOriginal_remove[some char chain] does not exist.
As explained in [prestashop project]/override/readme_override.txt:
Frequently Asked Questions
Q: I added an override file but it seems to be ignored by PrestaShop
A: You need to trigger the regeneration of the /cache/class_index.php file. This is done simply by deleting the file. It is the same when manually removing an override: in order to reinstate the default behavior, you must delete the /cache/class_index.php file.
But [prestashop project]/cache/class_index.php does not exists in Prestashop 1.7.
In Prestashop 1.7, class_index.php files are located in:
[prestashop project]/app/cache/dev or
[prestashop project]/app/cache/prod according if the project is set either in "dev" or "prod" mode.
For overriding a class in Prestashop 1.7 you have to copy the class file in [module_name]/override/classes directory during the module installation, and remove it on uninstall.
This is explained in further detail here.
I'de like to copy the [prestashop new theme]cart block (cartblock2 in the main module folder) into my theme/modules in order to customize it and keep the core module intact.
How do I do that ? I searched the documentation and it's not very clear...
What I did so far :
Copy cartblock2 from the main module folder into my theme/module folder, empty prestashop cache (it's turned off but just to be sure), I made my changes but nothing change it's only changing when I modify the module in the main module folder.
Thank you for your help
module folder name must same with root modules name
/modules/blockcart2
in themes
/themes/modules/blockcart2
and you can only edit blockcart2.tpl file in themes folder
and make sure blockcart2 installed in bacoffice