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).
Related
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.
I have installed Spartacus 3.2.2 recently. Can I please know is there documentation available to upgrade 3.2.2 to 3.3 ?
Can I please know if I upgrade to 3.3 will it effect to current development components or pages?
Upgrading to the later minor or patch version of Spartacus should not introduce any breaking changes to your application. It's because Spartacus follows the Semantic Versioning contract.
Sometimes new features introduced in minor versions of Spartacus might require some breaking changes, but in that case such features are not enabled by default. They will appear only when you opt-in to that feature by bumping the feature level in the Spartacus config. You can also opt-in to use the latest SCSS styles, by bumping the styles feature level variable in SCSS.
Significant breaking changes can be introduced only in major version. To smooth the migration process for you, Spartacus team provides the migration docs and automated migration tools (aka. schematics) that will fix some of the the breaking changes in your code and put code comments in your codebase near the usages of the changed Spartacus API.
For example, here are docs for migration from 2.x to the major version 3.0: https://sap.github.io/spartacus-docs/updating-to-version-3/
Can Someone tell me the proper process to upgrade Prestashop 1.7.1.2 to the new version? I have to upgrade my Prestashop version because the PHP version I was using was outdated, so I have upgraded my PHP version. After I upgraded my PHP version, my Prestashop 1.7.1.2 backend didn't open. Because this version of PrestaShop won't support the latest PHP version. I don't want to use outdated PHP version also because my hosting provider charges me a lot.
It would be great, I can upgrade my PrestaShop. So, I need a proper step by step process to upgrade Prestashop.
Also, how do I change my shop into maintenance mode by changing the code? Keep in mind, my backend won't open. I have to change it programmatically.
I already have done a lot of google searches and won't get the proper procedures.
To disable your shop from the database, go to the configuration table and
search where name = PS_SHOP_ENABLE, set this to NULL.
I have a reasonably large WiX installer (250 Mb plus) and I am trying to come up with a suitable upgrade strategy.
Most of the files in the installer will not change and we would prefer not to have to distribute the whole package when only one or two files have changed.
I have looked into major and minor upgrades and my understanding is that a major upgrade will happen if the Product ID changes, so long as the Upgrade ID stays the same and minor upgrade patches can be used if both of these values stay the same.
My feeling is that a minor upgrade using a patch would be the best option to handle the cases where only a few files change and only to rebuild the whole installer when a substantial number of files change.
I have tested this using "torch" to produce a "wixmst" file based on the differences between two "wixpdb" files, then building a patch from that. However, I found that I can only patch from one version to another (e.g. 1.0.0 to 1.0.1, then 1.0.1 to 1.0.2 but not 1.0.0 to 1.0.2). Is it possible to target a minimum version for a patch and support any version above it?
Patching is a pain so get ready for a lot of it as you learn to master it. Here's another strategy that might work for you. Split your MSI out into 2 MSI ( Microsoft calls this Micropackages ). Have a Base MSI that contains the bulk of your content that is expected to not change and a Second MSI that is much smaller that contains your files you expect to be high churn.
Then use Burn is a bootstrapper to handle chaining these together and uninstalling them together. This is similar to what Visual Studio does.
Now you can just ship major upgrades of your second MSI.
I believe that it is possible to patch in the scenario you described above, as long as the patches are uninstallable. An example scenario would be:
Install msi (v1.0)
Install msp (v1.0 - v1.1)
Uninstall msp (back to v1.0) then install msp (v1.0 - v1.2)
For more information on uninstallable patches, see the wix documentation: http://wix.sourceforge.net/manual-wix3/patch_restrictions.htm
and the Windows documentation: http://msdn.microsoft.com/en-us/library/aa372102.aspx.
Note that to create uninstallable patches there are certain restrictions and you must be at WiX 3.0 or greater.
Like Christopher mentioned, patching can be a pain. I have found that in many cases, my managers may ask for the ability to do patch upgrades when all they really mean is for the user to be able to upgrade without manually installing first, which can be accomplished by a major upgrade just fine.
That said, if you have customers that require many small updates that get downloaded frequently, then patching may be worth the extra effort.
While Christophers answer is awesome in that he suggests the wix bootstrapper, I would discourage the route of doing major updates for the "high-churn" package. The problem is that after you have done your bootstrapping patch which internally does a major upgrade of your volatile libs in the HighChurn.msi from version v1.0 to v1.1, the bootstrapper will not, to my knowledge, re-install the previous package of HighChurn.msi in v1.0.
There's another path: you can certainly author patches which target the release of your main package. Given what you wrote I'm not entirely sure, but if your 1.2 patch can only be applied to 1.1, then you probably diffed your 1.2 only against 1.1, and not against 1.0.
Here's a neat guide how to create patches: https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/
Follow that guide, do superseding patches ([PatchFamily/#Supersede], it'll make v1.2 invalidate everything which v1.1 shipped, so you are basically forced to make v1.2 patch v1.0 and not v1.1), and add this flag to the patch element to target the major release, even though higher versions are present: Patch/#MinorUpdateTargetRTM="yes". Always diff your patches against the release installer (HighChurn.msi v1.0), never against the installer you used for a patch (HighChurn.msi v1.1).
There are of course situations where you might want to require a certain upgrade installed for patches: A well planned fixpack/servicepack scheme, for example, where patch 1.1.1 requires service pack 1.1 installed on top of the release 1.0.
A final word on patching your volatile data (I'm presuming versioned libraries here): You might want to have an eye on which libs you could basically replace in the patch. Then you can create patches with very few data, by only giving the changed libraries a higher version. If you increase the version on all of your libraries, all libraries are going to be patched, resulting in larger patches. This might require a slightly more complicated build workflow (God knows it did for us).
I have installed a fresh install of XWiki on a Windows platform.
The XWiki instance was installed using hsql for data storage.
The XWiki instance is hosted on Apache Tomcat.
Some of my users entered an apostrophe into the title of a page as well as the page content.
I received the following error:
http://jira.xwiki.org/jira/browse/XE-767
What is my next step to fix my broken XWiki instance?
Is there a way to upgrade a XWiki instance to a version that works? How do I save my existing content?
From reviewing the developers comments, it appears that issue has been corrected.
I, however, do not have enough background in Java or XWiki to know how I can move forward.
Thank you in advance for your help.
Indeed, the best solution is to upgrade to a newer version. Don't worry, upgrades are not that difficult.
http://platform.xwiki.org/xwiki/bin/AdminGuide/Installation#HUpgradinganXWikiInstallation
There are two parts in an upgrade: the platform, meaning all the files on the filesystem, and the wiki content, since quite often things change in the default wiki documents. Your specific bug can be fixed by upgrading the platform part, so if you're not too confident about upgrading the wiki content, you can just leave the old content in place.
In order not to lose your current database, be sure to leave the old "database" folder in place, and just replace the "webapps\xwiki" part.
From the error report the versions that fix the issue are
2.7 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise27
2.6.1 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise261
You can upgrade to one of them or to any following version, like XE
3.0 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise30
All versions can be downloaded from http://forge.ow2.org/project/showfiles.php?group_id=170
In a project that has such a rapid development cycle is very good to upgrade often in order to benefit from the latest features and bug fixes.