I want to migrate a shopware with shopware 3.5.4 version to shopware 5 version, but I cannot update it. I'm also trying to transfer its contents and theme to shopware 5, which I just installed. Is there a short way I can do this
There isn't any short way.
You must update to some intermediate version.
If you made it to version 4.2 you can update in these steps:
4.2
5.1.6
5.6.10
5.7.6
See also the shopware 5 changelog
In the shopware github repository, you can find all versions since 4.0.1 as tags.
As most old versions of shopware (at least the ones I got to know) are pretty "tinkered", the easy way moving to recent shopware is:
Copy database and local files to a supporting host (keep in mind that you will need older versions of PHP)
Disable (better uninstall) every plugin and theme, switch to default theme
Upgrade to SW4, then upgrade to recent version of shopware 5 by following this guide strictly https://docs.shopware.com/de/shopware-5-de/update-guides
Use import/export tool to export all product and order data
You might as well succeed by skipping step 3, applying all db-migrations, and using the db with your fresh installation, but I guess you will run into trouble with your media files (images etc. might not be usable anymore).
Another way might be writing a small script to export all data to csv and import it with the native tool.
There is no way (that I know of) to make your old theme working in recent versions of SW5. Before creating a new one, keep in mind SW5 will quite soon be EOL, and SW6 is much faster and way ahead in usability. You could use SW6's import functions to move from SW5 to the recent release.
Related
I have a store running Prestashop 1.7.2.4 (with Symfony 2.8.27) with tons of customized files, theme, modules etc.. I just can't upgrade to newer Prestashop versions otherwise i will loose a lot of work in a blink of an eye.
My question is simple, can I apply prestashop version by version from 1.7.2 up to 1.7.8 security patches on my actual installed PS ? That is including Symfony vulnerable issues.
What is your advice.
Prestashop security patches applied over time are listed here , you should search the pull requests related to those advisiories and apply / cherry pick them manually on your release.
This can be a hard task though, especially from such an old version.
Generally, I suggest to move your core changes to modules / overrides so that you can update safely to latest version, so you can also benefit of PHP 7.4 support (note that themes and third party modules will not be overwritten during upgrade).
I'm currently developing a (Laravel) package on Gitlab, and i want to automate testing using its CI/CD pipeline.
The problem
I already know ho to set up a pipeline in Gitlab, but what i want to achieve is to automate testing against different versions of the same dependancy, in order to keep checking compatibility with old version and add checking with upcoming new ones.
The case
My Laravel package is not so complex right now and don't use some particular nor specific Laravel features, so i would like to keep it compatible with te more versions of laravel possible: i would trigger different testing stages in my pipeline to run my tests against laravel 5.6, 5.7, 5.8, 6, 7, and 8.
The question
How do i trigger different testing stages using different laravel/framework versions?
When downloading dependancies composer will go for the latest version available if i define it with '^', so which files do i have to edit?
Ok, i've analyzed the problem a bit more, and made some considerations about it.
I'm writing not to properly answer my question, since i hope someone will eventually came up with a better solution/idea, but to just share some toughts with everyone is facing the same problem.
First: since i'm developing a package for Laravel i cannot declare laravel as dependancy for it, production nor develop, it is my laravel project that need to declare my package as a dependancy.
Second: to test my package compatibility with laravel i'm using orchestra/testbench as a dev-dependancy, and as for its documentation every release target a single and precise Laravel version, so if i want to test my package against different Laravel version i need to test it with different orchestra/testbench releases.
Third: the only dependancy my package has is just php 7.3, so i can easily test against this and subsequent version using Gitlab pipeline and creating a job for each php version that use a docker image with the correct php version and the last composer one.
Conclusion
It is not trivial nor straight to test a Laravel package against different Laravel version.
The only idea i came up with, but not tried since i gave it up aj just test php versions (for now) is to make a branch for each Laravel version i want to test with and update its composer.json dev-dependancy with the correct orchestra/testbench release.
Than i can execute php tests on my features branch merge request, and in case of success merge the develop branch on each "laravel branch" and execute on those the laravel compatibility test.
At last, if every laravel branch pass its tests, or at least the ones i decide to keep deevelopment/support active for, i can merge the develop branch on the master.
I'm not goig for it
I decided to avoid all of this since i'm not quite sure on how implement all of this on the pipeline, and i strongly think that it just adds mantainence burden to this project.
So i just keep the php jobs to check against different php versions, this way i just need to copy/paste a job definition in my gitlab-cy.yml file and change the docker image version accordingly to the new php version to test against.
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
I got a problem. I want to upgrade my app during installation process, but I run into problem with versioning. I use version number in format e.g. 5.5.789.0, some new version has version number in format 5.5.12.1. I know that installer only works with first three numbers from version so MajorUpgrade is not suitable for me. New version would not be installed in this case. Is there a way in which I can check versions in some custom action and plan upgrade from there? I cannot change the versioning as app building goes through some automatic post-processes that also works only with first three numbers and it is not possible to change that behavior.
Thanks for suggestions.
EDIT:
I am using WiX#.
It's not obvious to me why you can't use the WiX majorupgrade element. The settings would be AllowDowngrades=yes, maybe AllowSameVersionUpgrades=yes.
Using Schedule=afterInstallValidate is (as the docs say) removes the old product entirely before installing the new upgrade.
I'm newbie in OpenErp and i'm just using basic functionnalities of OpenErp6 and i want to upgrade to OpenErp7.
I'm using it under Ubuntu11..Is there a tool to upgrade it to The 7 version ?because i searched in google and i found that i must uninstall it manually and reinstall the latest version .
Thank you
If you want to keep your data, you have two ways of doing this:
get support from the OpenERP editor: they sell a migration solution, for a not very high price.
get in touch with and contribute to the openupgrade project which tries to build an opensource migration solution. The migration to 7.0 is not yet ready as of today, so you'll need either wait or contribute to get it good enough to migrate your instance.
On the other hand, if you have very little data as you mention in your comment, you can probably migrate by hand be creating a fresh OpenERP 7 instance, and manually recreating your entries in that instance. Obviously, this is not scalable.