Uninitialized constant error (Spree::ProductsController)

[Buvanesh-P]

products_controller_decorator searching for Spree::ProductsController which not exist

Steps to reproduce

1. Add the gem gem 'solidus_reviews'
2. rails generate solidus_reviews:install

/var/lib/gems/3.0.0/gems/solidus_reviews-1.7.0/app/decorators/controllers/solidus_reviews/spree/products_controller_decorator.rb:12:in <module:ProductsControllerDecorator>': uninitialized constant Spree::ProductsController (NameError) from /var/lib/gems/3.0.0/gems/solidus_reviews-1.7.0/app/decorators/controllers/solidus_reviews/spree/products_controller_decorator.rb:5:in <module:Spree> from /var/lib/gems/3.0.0/gems/solidus_reviews-1.7.0/app/decorators/controllers/solidus_reviews/spree/products_controller_decorator.rb:4:in <module:SolidusReviews> from /var/lib/gems/3.0.0/gems/solidus_reviews-1.7.0/app/decorators/controllers/solidus_reviews/spree/products_controller_decorator.rb:3:in <main> from /var/lib/gems/3.0.0/g..............................

[jarednorman]

My guess is that you've installed this extension on a store that's using Solidus Starter Frontend, but this extension hasn't been updated to support it.

[fthobe]

@jarednorman what would be the most elegant way to solve this? We could spare some time for that.

[jarednorman]

The project would need to be reviewed (pun intended) to determine which ways it assumes you're using the original solidus_frontend instead of solidus_starter_frontend.

My preference would be that you then update the gem to work with the starter frontend (and possibly the new admin too) and then bump it to a new major version.

It should be possible to craft this extension such that it can be used with either frontend, but it wouldn't be directly compatible with existing installations without some changes.

[fthobe]

We don't want to put hands into the work in progress you are doing with the Admin backend, if we take care of the front-end aspects, could you people handle the backend?

[fthobe]

@Buvanesh-P Did anybody on your side fix this?

products_controller_decorator searching for Spree::ProductsController which not exist

Steps to reproduce

1. Add the gem gem 'solidus_reviews'
2. rails generate solidus_reviews:install

[fthobe]

products_controller_decorator searching for Spree::ProductsController which not exist
Steps to reproduce

1. Add the gem gem 'solidus_reviews'
2. rails generate solidus_reviews:install

@kennyadsl should the old front-end be globally dropped or is it currently something you support?

[jarednorman]

I don't think dropping it is a good idea, given supporting both isn't all that much work.

[fthobe]

@jarednorman @kennyadsl please align on desired level of support.

For how I see it from the readme.md the old frontend is deprecated and all versions are EOL, am I missing something?

https://github.com/solidusio/solidus_frontend

[kennyadsl]

I'm ok with Jared proposed. It's the same thing we did for Subscriptions, which I pointed you to in Slack.

[fthobe]

It should be possible to craft this extension such that it can be used with either frontend, but it wouldn't be directly compatible with existing installations without some changes.

@kennyadsl is the above ok for you? For us a review that works with the old solidus frontend is beyond test scope and I wouldn't like to commit something that we haven't tested (with humans) end to end. I just do not have the same amount of faith in automated testing.

[kennyadsl]

What do you suggest in this case?

[fthobe]

To be fully honest three things:

• old frontend is deprecated by docs, so let's deprecate it, new versions for gems aligned with the solidus numbering scheme so let's bump extensions from whatever version to 4.4. I feel having less stuff reliably running is better than more stuff cramped into not working environments and outdated front ends, as you said regarding solidus 5 the ecosystem needs to work first and right now I have the feeling that instead of keeping a pace that works for the entire ecosystem what should be major releases are made minor releases while abandoning the eco system in non working state
• dropping the old front end allows a reduction of manual test cases to a minimum by having to test only against one front-end, one backend
• add manual testing by spinning up a public staging system for nightly main and beta (I feel that would be a good way to use community funds) and write a manual test protocol, I think there's only so far automated testing can get you as stuff not considered in development will not be considered in circleci and the effort is definitely less stressful than forcing out overnight updates and I wouldn't want to have to mantain them on two frontends concurrently
• pay some dude on upwork 50 bucks a month to test against the protocol on staging a couple of times a month (also community funded)

I know the for example that the new promotion system was a monster task but I have the feeling with a little bit more manual testing a lot of stuff would have been caught earlier and to do manual testing against both frontends seems a nightmare to me, let's not pray to a dead cow. But that's my cup of tea and I wouldn't die on that hill (different than meta data which is something I deem immensely important for the eco system), but I feel that would be a better approach.

[jarednorman]

I don't have time to dive into everything here right now, but I wanted to comment on a couple of things.

old frontend is deprecated by docs, so let's deprecate it

Most existing stores use the legacy frontend and there isn't a practical upgrade path, so we need to maintain support for it.

new versions for gems aligned with the solidus numbering scheme so let's bump extensions from whatever version to 4.4

No. This is a terrible idea for a number of reasons, including that we would have to ship new versions of every supported gem every time we release a new Solidus version.