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
Related
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'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
On my system, the module sources are under ~/.perl6/sources/ and there's also some kind of metadata file about the modules in ~/.perl6/dist/.
I can also use zef locate ... to show a module's source path, but making changes directly to the source files doesn't seem to have any effects (i.e., use the module from the REPL doesn't show my changes).
I'm guessing it's because the modules were pre-compiled, and perl6 doesn't pick up my changes and re-precompile the modules when I make changes directly to the module source files that way...
UPDATE: Deleting the corresponding pre-compiled files under ~/.perl6/precomp/... seems to work, but I'm not sure how and if that messes up anything.
I'd like to be able to view and make changes to the source code of installed (via zef) perl6 modules. How can I do that?
Please, don't do it that way. Installed modules are supposed to be immutable and as you've found out: if there is a pre-compiled version of a module available, it will not check if the original source file has been updated. That's because it doesn't have to, because it is considered immutable.
If you want to test changes on an installed module, please download the tar file / git clone the module's distribution, make changes you need in there, and then do:
zef install . --force-install
while in the top directory in the distribution. That will re-install the module and handle pre-compilation for you.
Two computers are working on the SAME repository but first computer detect the library and work well but second computer not detect it and show "Error 'PhpOffice\Phpspreadsheet\Reader\Xlsx' not found".
In vendor, the library also exist.
composer.json and composer.lock also the same on both computer.
One thing is that by git ignore, I use yii's composer mechanism at 1st computer but at sec computer(err computer), I add library manually.
If you want to use a composer package, you absolutely need to install it using composer. This ensures that the autoloader is generated properly and your class can be found through PHP.
Copying library files into vendor directory is not enough to install it. During installation Composer creates autoload script with information how to find all classes installed by Composer. If you just copy library files, Composer will not even know that it exist and will not able load any class from it.
If you cannot use Composer on server/computer A, you should install all dependencies on different computer (B) and copy the entire vendor directory into server/computer A. Autoload definitions are in vendor so it should work if you copy the whole dorectory.
I am trying to get a copy of ps_cleaner to clear the dummy data from my 1.7 version of Prestashop and I can't download straight to my prestashop version so I have gone to the Git location to take a copy and upload it but that doesn't work. Is there something I have to do to take it from Git to install on Prestashop 1.7
You should better download the zip and install directly via the system, git are not always perfectly fitting last refactoring.
Download module as zip file then unpack first then rename the folder name with the module name "ps_cleaner".
I mean just remove the branch Name (_master) from your module folder (such as ps_cleaner_master), Then again create a zip and install this.
How to save/restore Sublime Text 2 configs/plugins to migrate to another computer? states that, to backup a Sublime Text 2 installation, a user should preserve the ~/Packages/User directory (from the user's local data folder on whatever OS they're using).
However, http://andrew.hedges.name/blog/2012/01/19/sublime-text-2-more-sublime-with-a-drop-of-dropbox and most other walkthroughs for using Dropbox to sync Sublime's settings specify three directories: ~/Packages, ~/Installed Packages and ~/Pristine Packages.
What is the functional difference between backing up just ~/Packages/User, and the other 3 directories?
I think that Packages/User is the one in which you are supposed to put settings (according to Sublime's official and unofficial documentation). However, some people put them in the other folders from time to time.
The Dropbox advice may be a hedge against poor practice.
From here:
Installed Packages is:
You will find this directory in the data directory. It contains a copy
of every sublime-package installed. Used to restore Packages.
These are the packages installed as sublime-packages. I don't think package control uses this, but if you install something as a sublime-package maybe you want to keep it?
Pristine Packages is:
You will find this directoy in the data directory. It contains a copy
of every shipped and core package. Used to restore Packages.
So essentially a list of .sublime-package files used to restore if you break something.
Packages is:
The packages used by Sublime Text, either installed as part of sublime, or the plugins.
User is:
The user directory is your personal directory, containing configurations, additional snippets, etc.
Below are my personal views on what to save, so feel free to ignore it if you would like.
I would have to agree with the post saying just save the User directory, as Package Control will grab all of the plugins in the list if they aren't already installed. I didn't see this mentioned in that post, but you can also add repositories (by specifying a URL) to Package Control, which allows you to install Packages outside of those submitted to Package Control, but still hosted somewhere. One of the arguments I can see to saving the Packages directory completely is if you are using plugins that aren't hosted anywhere (though these could probably be moved to the Packages directory without any problems).
The Installed Packages and Pristine Packages are used to restore packages, so I wouldn't think these would be needed, but I'm sure there is some use case where it is.
Anyways, realize I got off topic a bit at the end there, but hope everything before that helps clarify.