There are critical security issues in Shopware 6 pre 6.4.18.1.
We manage our shops via Composer and due to incompatible 3rd party plugins cannot upgrade to 6.4.18.1 quickly.
Now there is https://store.shopware.com/swag136939272659f/shopware-6-sicherheits-plugin.html?number=Swag136939272659
What is a recommended way to install / upgrade this plugin.
We have the following options:
Activate Shopware store and install the plugin using the store (after login on the Shopware account, which can cause complications with staging URLs)
Download the plugin ZIP manually, for example from a Wildcard account and upload it manually
Install via composer, run through a full deploy process but don't update Shopware just yet but just the Security plugin.
How are others handling the Security plugin upgrades? Is there an officially recommended way?
I prefer handling all Store plugins via composer, so in your case requiring store.shopware.com/swagplatformsecurity and deploying that (along with a plugin:install or plugin:update).
As you mentioned, using the included Store breaks down in deployed/version-controlled environments.
You could also extract the ZIP into custom/plugins and deploy that, but then this would be an exception of your otherwise composer-managed project.
Related
We have a React App which uses some components written by us and published to our internal npm repository. Our code is maintained in Bitbucket Data Center, the build is done with Bamboo and the npm repository is hosted in JFrog Artifactory. We work with feature branches and pull requests for developing new features.
It happens often that a new feature in the app, requires a change in the component. In this case, each repository (the App and the component) will have its own feature branch and pull request. Many times the component interface changes, so that the App needs the pull request version of the component and not the mainline one to build and to be tested.
The build is done exclusively by the build server, so that the bundled javascript files are not committed to git.
Let's say the component has version 1.0.0. A new feature in the App needs a change in the component. In this case, the component version will incremented to 1.0.1. We don't want to publish it to Artifactory, until version 1.0.1 is tested, but at the same time, the build of the new App version needs the changes from version 1.0.1.
Our current solution is to change the package version of the component during the build of feature branches to something like 0.<Ticket #>.<Build #>. This 0.x.x version will be published to Artifactory so that the App feature branch can use it to compile.
We use 0.x.x so that the version is never bigger than the current released version. Once the component is merged to the main branch, it will compile with the right version (1.0.1) and will be published to Artifactory again.
I find this solution cumbersome, it requires some funny build scripts, making sure that the branch name always follows some convention and teaching developers about it.
I wonder if there is a better way for managing pull requests and feature branches using npm, without having to manipulate the package.json during build time, depending if it is a feature branch or the main branch.
Sounds like you are using artifactory like a secondary version / staging for the npm package, just use npm?
I am not in devops, but have worked on a few packages, testing a package that has not been released does not sound like testing the package - what about using a beta tag npm publish --tag beta, pulling that into your app npm i package#beta then testing your application in a staging environment?
As i expect you know if you apply a tag then the tag would need to be specified to be pulled into a repo so you can use it to deter users from using that version of the package - an i believe you can delete versions later if you are dead set on not having it public.
Here is a medium article which may be helpful?
I'm building an Azure Function that depends on another project I'm building that's on Nuget. Everytime I update the nuget project, I publish the updates to https://nuget.org. Then I wait for the validation. Then I update my other project to pull the latest version. It's really annoying waiting for the validation... sometimes a couple times per day.
Is there a way I can use my nuget package without waiting for validation to complete? Keep in mind I'm developing both packages side-by-side on the same laptop.
There are three levels to doing this efficiently:
Whenever possible, do local development within the same solution using project references instead of package references. As zivkan said in the comments, this "inner loop" is fastest. Do this until you need to test the package itself (e.g., making sure it installs correctly).
Use a local NuGet feed if you are able to test the package without hosting it on a cloud repository. (nuget add my-package.1.0.0.nupkg -source C:\somedirectory\localnuget) Visual Studio and the nuget CLI can both be configured to look in a local directory, which makes the testing loop much quicker.
If your Azure functions must get the package from a real hosted repository, use MyGet (or if you want to DIY it, Artifactory) to host your own NuGet feed. Publishing your packages to that feed and consuming them from your function should be faster than waiting for official verification on nuget.org.
I ran the migration utility to upgrade our Nexus 2 (2.14) to Nexus 3.40-02.
The Nexus 3 migration tool brought all the content from our 2.14 instance but subtly changed the URLs to all our Maven Repos.
For instance
https://nexus.foo.net/content/repositories/releases
became
https://nexus.foo.net/repository/releases
If I go in the Nexus 3 UI with the Admin account, browse to repostiories/settings I can see the URL but not change it.
This seems really dangerous since the Nexus URLs are encoded in poms by hundreds or more end-users consuming the jars. Why would the migration tool change the URL like this? Also I can find nothing in the Documentation about why the URL field is visible under "Settings" but cannot be changed to fix it.
Does anyone have any ideas about what went wrong?
Thanks.
The URI pattern will change after the upgrade. However you can activate a switch to enable the old URI pattern.
"By default, Nexus Repository Manager 2 uses a different URL pattern to expose repositories and repository groups than Nexus Repository Manager 3. While automated tools and CI can be reconfigured to utilize the new patterns, it is possible to change a configuration on the Nexus Repository Manager end to allow your upgrade to use the old pattern as well. This can be done in $data-dir/nexus3/etc/nexus.properties by adding:"
org.sonatype.nexus.repository.httpbridge.internal.HttpBridgeModule.legacy=true
https://help.sonatype.com/display/NXRM3/Upgrade+Procedures#UpgradeProcedures-ConfiguringLegacyURLPaths
I'm going to work on a Shopify theme, and I want to figure out how to run/edit it locally. I'd like to be able to the following, if possible:
Pull all the Shopify theme code from the site to my local computer (ideally a single command line tool)
Make edits locally, and run them locally or in a staging environment
Push all the edits to the main Shopify site, again using a command line tool
Is this at all possible?
There are quite a few workflows you can use here.
1. Task runners
If you're using either Gulp or Grunt locally for development, there are libraries out there that will upload your files to the store through API credentials of a Private App that you have to create. Most work by uploading the files you change, using a watcher.
grunt-shopify
grunt-shopify-upload
gulp-shopify-upload (it's my favourite since I use Gulp but has a known issue that sometimes it stops uploading files and you have to restart it).
2. Official Shopify Theme Kit
Theme Kit is a cross-platform CLI tool that was built by Shopify Employees. It can run on windows/linux/OS X. You can read more about it on Shopify Blog or download it directly. The alternative previously mentioned of Desktop Theme Editor is deprecated and has been replaced by Theme Kit.
3. Third-party SaaS Applications
Instead of watching for changes, these will work with a continuos integration workflow, where your latest push on a certain branch gets uploaded to the theme you've selected.
Beanstalk. More specific information can be found on their landing page for Shopify, here.
DeployBot. Their help article on Shopify has some information on how to get started.
Both options are from the same company. Here's a comparison of both they've did on their blog.
4. Third-party libraries
There's also an alternative not officially supported by Shopify which is a TextMate Bundle in case you use that OSX editor.
There's an unofficial extended cli similar to theme kit but with further functionality called Quickshot, which I've just found out based on Matt's response and seems pretty awesome. Some of the features they highlight are:
Supports uploading to multiple Shopify stores and themes
Easy to use configuration wizard
Uploads/downloads in parallel greatly reducing transfer times
Supports autocompiling scss locally before uploading to Shopify
Supports autocompiling Babel/ES6 into modules which are easily used by - Requirejs and others
Can use with .gitignore files or a custom .quickshotignore file.
Can download/upload Shopify Blogs, Pages and Products! Easily transfer them between stores! Even the metafields! And edit them locally in your favorite editor.
Shopify recently released Slate, a new tool for theme development.
https://github.com/Shopify/slate
As of 2020, Shopify has stopped support Slate so you can now use Themekit - https://shopify.github.io/themekit/
2022 update
Currently it is not possible to run Shopify locally. There are only solutions, mentioned in other answers to edit files locally and upload it to Shopify. It makes the development hard.
I am working on a solution to emulate Shopify locally making development similar to WordPress, React or Angular. So you will see changes immediately, even without reloading the page and without the need to upload files to Shopify each time.
You can read more here: https://link.medium.com/6SGd1kcVdnb
Juan's answer is spot on.
There's one more I know of which I believe is a little more advanced than Themekit (which I use) called Quickshot: https://quickshot.readme.io/v2.1/docs
Shopify have built a tool for Mac that allows you to develop your theme locally, and sync with your store https://apps.shopify.com/desktop-theme-editor
I don't know of anything for windows/Linux etc.
If you're looking for completely offline development, it's unfortunately not possible at this time. While the Slate/ThemeKit CLIs lets you code in your favorite text editor, an internet connection is still required because it likes to keep everything in sync at all times.
Install the state package by running the following commands:
npm install -g #shopify/slate
slate theme theme-name
Yes, I'm aware this has been asked before but the questions were asked in a manner that didn't give me the answer to find out the appropriate usage and if each package manager had exclusive packages that couldn't be found on another.
I understand that the ionic framework has these three frameworks/package managers underneath it and I can obtain the same package into my package making any of these same calls.
npm install [mypackage]
bower install [mypackage]
ionic plugin add [mypackage]
cordova plugin add [mypackage]
I also understand that they rely on each other like so.
Parent>Child [The framework above the other you would need to install the other]
npm>bower
npm>ionic
npm>cordova
npm>ionic[contains cordova]
However from what I've seen so far I don't find any packages that are exclusive to one or the other and was wondering
1. Are there some Packages/Plugins that are exclusive to one package manager?
2. Is it better to make a different call depending on workspaces?
npm- It is called as network packet manager it is just like installing a software or package from terminal without using GUI
bower-It will be used to install the required libraries in our project
cordova plugin add/Ionic plugin add these both commands are same there is no difference between them, but we are using ionic plugin add because we are using Ionic framework.
Having any queries, reply back