I've enabled multistore mode and created a new shop on the basis of old one (agreed to copy all files, options, products, etc.) and set a theme which was basically also a copy of other one.
I've lost some modules and elements in new shop, but I've managed to revive them by updating modules or changing their settings. However, I am unable to restore blocklayered module. I have tried so far:
in module's config: rebuilding indexes, prices, etc.
reinstalling module
rehooking to position, displayLeftColumn in my case
enabling columns in theme's config
Try to create a new filter template in module settings.
Related
I have a Git repo with two directories:
backend (PHP/Laravel code)
frontend (TypeScript/Vue code)
I would like that backend is marked as excluded when the project is opened in WebStorm and frontend to be excluded when it is opened in PhpStorm.
This is to ensure that searches/indexing only happen for the files that I would actually edit in that specific IDE.
When I change the excluded directory it seems to automatically apply this to the other IDE as well. Is there some way to keep this setting separate?
Comments:
I intentionally have both frontend and backend in one repository.
Opening the subdirectories in their own IDEA projects does not seem
to be an option because the Git integration only works when the
project is in the root folder of the repository.
When I change the excluded directory it seems to automatically apply this to the other IDE as well.
It is expected. That's because the project settings are stored in the .idea subfolder. All IDEA-based IDEs use the same .idea settings format. So opening the same folder/project in different IDEs simply makes them use that already-made config (shared between IDEs).
Plus, both PhpStorm and WebStorm use the same module type ID (WEB_MODULE) and can have only 1 module in total in a project. IntelliJ IDEA and some other IDEs (like PyCharm for example) can work with projects that can have more than one module and of different types.
Is there some way to keep this setting separate?
Yes, with the help of a small workaround: you need to store .idea used by another IDE in another place. As simple as that.
The setup and steps:
Lets assume that you have your project in C:\Projects\MyProject.
Make a brand new empty project in another place, e.g. C:\Projects\IDEProjectsStore\MyProject-frontend. It will be used for a frontend.
Go to Settings/Preferences | Directories and remove an existing Content Root (which will be C:\Projects\IDEProjectsStore\MyProject-frontend from the previous step).
Add new Content Root instead -- point to the actual project (C:\Projects\MyProject from step #1)
Save and configure as needed.
What you will have now:
This frontend project will now have its settings stored in C:\Projects\IDEProjectsStore\MyProject-frontend\.idea while another (original project with backend) will have them in C:\Projects\MyProject\.idea.
Projects (project-specific IDE settings) are stored in 2 separate places while they both use the same folder with the code.
Basically: a project in the IDE's eyes is an .idea folder with a parent folder added as a Content Root by default. Our workaround keeps the second project in a different folder while sharing the same Content Root between them.
https://youtrack.jetbrains.com/issue/IDEA-170102/ -- that's a ticket that asks for a straightforward way of doing this.
I would like that backend is marked as excluded when the project is opened in WebStorm and frontend to be excluded when it is opened in PhpStorm.
Why do you need two IDEs for this?
In case if you do not know: PhpStorm = WebStorm + PHP + Database. You do not really need WebStorm here. Just install any missing plugins that come bundled with WebStorm.
Some modules can be auto-updated in backoffice by clicking the update button. However if the module is from an other source than prestashop itself (e.g. github) the module needs - afaik - to be updated manually.
So how should one handle updates?
Download ZIP and
unzip it over the corresponding modules folder (/modules/acme/)
unzip and rsync it to /modules/acme (rsync -trv /tmp/acme /modules)
Same as 2 but with --delete
Delete the folder completely and unzip the new one in place like rm -rf /modules/acme and cp -a /tmp/acme /modules/acme
Others ...
Side note: what about the config.xml and possibly other generated files?
Same applies for theme updates, how to handle these?
Concerning current version Prestashop 1.7+.
If the module upgrade is made correctly (you can check if module version is updated in main module class constructor and uses upgrade scripts in upgrades folder and files inside the module) you can unzip over it. Then visit the modules list page in backend and module upgrade will run. config.xml is auto (re)generated and used only for optimizing module list loading in the same backend page - it has no effect on module behaviour itself.
For themes you can also just unzip over the last one.
When I am in doubt with any upgrades I make a development copy of the store and do upgrades there first and see if everything is ok then do upgrades on live instance.
You can perform the upgrade automatically with this free module
https://www.prestashop.com/forums/topic/820013-migrate-or-upgrade-prestashop-16-or-other-versions-to-17-%E2%80%93-free-module/
Hope it helps
The modules a Webmin user can see in the menu can be configured via the GUI under Webmin/Webmin Users/Available Webmin modules. Where are these settings stored? I need to restore them programmatically on a fresh Webmin installation - without accessing the GUI.
The Available Webmin Modules that are displayed in the menu are reflected in file /etc/webmin.acl. It contains a space seperated list where modules are added when changing the settings via GUI.
In this case the configuration was made for the root user. The list therefore has the format
root: moduleX, moduleY.
It is likely that configurations for other users would be added in the same format, e.g.:
userXYZ: moduleX, moduleY
Restoring webmin.acl did the trick.
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.
Let's say I have a mediawiki installation. I mess about with it, add little hacks to make the wikipedia logo change into tigger, and bounce up and down.
Now it's time to update to the newest version, so I download it and run the update script. Let say it changed several variables, like $wglogo, the image path to the logo. How does the update script ensure that the logo image path changes (according to the specs of the new version, in this figurative example), while keeping tigger bouncing on the main page?
That is: How do new versions integrate changes to the configuration file without overwriting the user-defined changes in the config file-to-be-overwrit?
Typically we try not to change config files on update. Almost all new configuration settings are optional and thus are not added to the config files upon upgrade. In the rare case where we have to change an existing setting, make the smallest change required to the config file so as not to affect any other things.
Testing is very important. Gather as many real client configurations as possible and create unit tests for the auto-updater to validate that the configs don't gets screwed upon upgrade.