Bump solidus_core from 2.8.0 to 3.1.4

[dependabot]

Bumps solidus_core from 2.8.0 to 3.1.4.

Release notes

Sourced from solidus_core's releases.

v3.1.1

This patch release only adds a couple of small fixes needed for Solidus 3.1:

• Add deprecation path for arity-zero preference defaults (#4170)
• Fix staled upgrade instructions on the Gemfile's post-install message (#4166)

v3.1.0

Major changes

Spree.load_defaults: preference defaults depending on the Solidus version

Solidus 3.1 brings a new feature where preference defaults can take different values depending on a specified Solidus version. It makes it possible to stop deprecating old defaults every time we introduce a change in the recommended value for a setting. After all, they're just that; recommendations. Instead, now users can explicitly ask for a given Solidus version defaults and, as before, override the preferences they want.

When upgrading to 3.1, you have to take action to adopt the new behavior. You'll need to add Spree.load_defaults('3.1') on the very top of your spree.rb initializer. As we're not changing any preference default on this release, nothing will break. A warning will be emitted on boot-up until you do it!

However, bumping the version given to load_defaults straight away for future upgrades will not be a safe option. Instead, you'll have to go through the new update process detailed below.

• Allow using different preference defaults depending on a Solidus version #4064 (waiting-for-dev)

New update process

As aforementioned, preference defaults can change after a Solidus release. Once you have your defaults locked to the current Solidus version, a new upgrade won't break your application because of them. However, it's a good idea to adapt your application to the updated recommended settings. To help with this process, Solidus comes with a generator that you can execute like this:

bin/rails g solidus:update

That generator will create a new initializer called new_solidus_defaults.rb, which will preview all the defaults that have changed between versions, each on a commented line. From that point, you can activate the new defaults one by one and adapt your application incrementally. Once you're done with all of them, you can bump the version given to Spree.load_defaults in the spree.rb initializer and remove the new_solidus_defaults.rb initializer altogether.

You can read in more detail about [this process on our

... (truncated)

Changelog

Sourced from solidus_core's changelog.

Solidus 3.1.4 (v3.1, 2021-12-07)

• Fix ReDos vulnerability on Spree::EmailValidator::EMAIL_REGEXP GHSA-qxmr-qxh6-2cc9
• Use SSL on fonts.googleapis.com scss import #4210 RyanofWoods

Solidus 3.1.3 (v3.1, 2021-11-17)

• Monkey patch Authentication Bypass by CSRF Weakness vulnerability on solidus_auth_devise for extra security GHSA-5629-8855-gf4g

Solidus 3.1.1 (v3.1, 2021-09-20)

• Add deprecation path for arity-zero preference defaults #4170 (waiting-for-dev)
• Fix staled upgrade instructions on the Gemfile's post-install message #4166 (waiting-for-dev)

Solidus 3.1.0 (v3.1, 2021-09-10)

Major changes

Spree.load_defaults: preference defaults depending on the Solidus version

Solidus 3.1 brings a new feature where preference defaults can take different values depending on a specified Solidus version. It makes it possible to stop deprecating old defaults every time we introduce a change in the recommended value for a setting. After all, they're just that; recommendations. Instead, now users can explicitly ask for a given Solidus version defaults and, as before, override the preferences they want.

When upgrading to 3.1, you have to take action to adopt the new behavior. You'll need to add Spree.load_defaults('3.1') on the very top of your spree.rb initializer. As we're not changing any preference default on this release, nothing will break. A warning will be emitted on boot-up until you do it!

However, bumping the version given to load_defaults straight away for future upgrades will not be a safe option. Instead, you'll have to go through the new update process detailed below.

• Allow using different preference defaults depending on a Solidus version #4064 (waiting-for-dev)

New update process

As aforementioned, preference defaults can change after a Solidus release. Once you have your defaults locked to the current Solidus version, a new upgrade won't break your application because of them. However, it's a good idea to adapt your application to the updated recommended settings. To help with this process, Solidus comes with a generator that you can execute like this:

bin/rails g solidus:update

... (truncated)

Commits

• c8b6357 Bump Solidus to 3.1.4
• 6be174c Merge pull request from GHSA-qxmr-qxh6-2cc9
• d2fc8cf Fix ReDos vulnerability on Spree::EmailValidator::EMAIL_REGEXP
• c3afe4e Merge pull request #4210 from RyanofWoods/v3.1-fix-frontend-scss-font-url-import
• 8394353 Update importing fonts.googleapis.com to use SSL
• 8939d9b Bump Solidus to 3.1.3
• dcace31 Merge pull request from GHSA-5629-8855-gf4g
• bbd3512 Add extra security layer for GHSA-xm34-v85h-9pg2 in solidus_auth_devise
• a5949e2 Bump Solidus to 3.1.2
• 73ae502 Merge pull request #4184 from SuperGoodSoft/backport-paths-fix
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.