solidusio / solidus-demo Goto Github PK

Right now the backend fails on database adjustments in a variety of ways. Sometimes it returns an error message that looks nice, sometimes it sends you to a 500 page.

Figure out what the best way to fail on these requests is, and standardize it!

Because of the way that we're foiling Devise to allow backend usage, every use is associated with one nonexistant user, and this user has a cart. As a result, everyone shares that cart. This is not ideal, especially for when multiple people are trying to preview the checkout process.

There are two fixes for this as far as I can tell:

• Figure out another way to foil Devise
• Separate Frontend into it's own app

Personally, I favor separating frontend into it's own app, for two reasons:

• Admin side currently is able to see any carts (including addresses entered) and that's not ideal
• We may want to use the frontend as an actual Solidus merch store in addition to being a preview store, and that will require a separate backend.

Two people accessing the app at the same time could cause issues with using global variables.

Most "new" pages don't trigger the activerecord bomb I've set up, but for some reason the "New Order" button does. It would be cool to see this page, as it details how to create a new order.

Editing a taxon seems to break anything related to the taxon - something to do with acts_as_list, it seems like? Edits also don't seem to take effect.

Also, creating a taxon with the API button that creates a "New Node" taxon, displays for all users. I'm guessing something to do with the API creating this taxon.

I think it would be very cool to turn the info panel into an extension, so that it can be added to real stores in order to train store admins after the launch and new store admins when they're onboarded.

We could probably do the same thing with the guided tour and just put them all under the same extension (solidus_backend_help/solidus_backend_guides?).

I noticed we're using Ruby 2.4 which is a bit old and not officially supported by Solidus anymore. We should be using Ruby 2.6 instead. I'd avoid 2.7 because of the ton of deprecation warnings it prints because of the changes to keyword arguments.

I noticed this repository is using Rails 5, however we should probably be using Rails 6 instead to get advantage of all the latest features and performance improvements as well as to future-proof the demo.

On the two existing orders, looks like anyone can see the payments created by other users.

http://demo.solidus.io/admin/orders/R987654321/payments

I think this issue is related to #98.
Clicking on the color variants on the PDP doesn't change the product image.

See the short video:
https://www.loom.com/share/10b745c8c18047be9258e541800aa1e5

If you check out twice on the same session with the same variant, you get an error:

This appears to be from Spree::StockItem#adjust_count_on_hand - looks like it has unsaved changes?

Since it only ever happens on the second checkout, I'm guessing these changes are persisted from the previous order.

https://github.com/nebulab/solidus_starter_frontend

The default frontend looks nice, but presentation is key here. The Starter frontend is supposed to look & perform better, so let's give it a try!

Once we release the first section of the admin, we should update the demo, too.
It should reflect both the progress with the software and the rebranding.

Let's also explore if we can leverage Platform.sh for running the demo.

Images right now are stored in application memory, which is not ideal and could cause problems going forward.

The info panel is where the user can see more information about the page they are currently on. Right now the info is... nonexistant. We should add info for every page.

Important things would be:

What buttons do what
Features that need explaining
Process flows (order management, shipment shipping, how to process returns)

Whenever I've seen a public product demo, it was full of spam. I think we should create some recurring cronjob to reset the data periodically (e.g. every night). This should be easily doable with Heroku's API, or we may even just truncate all tables via Rails.

To reproduce:
Change a product title on admin
Go to home page
😱 The changes aren't there!

The changes are there on the product show and other index pages (taxon, search) - I'm not sure why the home page specifically doesn't show changes.

The new Solidus frontend messes with the bootstrap elements a bit, making the panel look difference between frontend and backend.

It's extremely important for this demo to be working properly, since people could be using it to show prospects what Solidus looks like. In order to make it more stable, we should probably expand the test suite to cover the basic checkout flow and other critical user journeys, and integrate a CI pipeline such as CircleCI.

The guided tour transitions are a bit abrupt, would love to smooth them out, maybe slide out the old messages and in the new, or have the un-whiteboxed-area move from place to place somehow.

When the tour progresses, your place should be saved with a cookie or something. That way, if you leave the tour for some reason, you can hit a button and go back to where you were.

Demo system seems to be down.

The Cart link should be like this:

Instead we're loading the previous cart-link component, so the UI is broken:

It works fine in the local environment.

To prevent DB bloat, we should run a task on a regular basis that looks for user-generated data that has not been created or updated in over a month, and destroy that data.

We could create a rake task that does this, then use heroku scheduler to run it on a regular basis.

Now that we merged solidusio/solidus#3851 (in v2.11) we should regenerate images to remove the gray border.

These have been left out for now since there's no promotion or refund data on the website yet

Production payment methods are visible by all - I'm not entirely sure why, and it doesn't happen on development.

Users should be able to leave the guided tour by hitting the escape key or clicking directly on the lightbox.

Something in the base decorator is causing the sample data load to fail on a new DB

The idea behind the user guide is to provide training on how to use Solidus for Solidus admin - I imagine the primary use case would be to train new employees on things like returns or inventory management. Most people would use it as a quick reference. That said, I think it only makes sense in the context of the admin side of Solidus. You wouldn't want to, and hopefully don't need to, train customers how to use the frontend.

Our engagement on the demo is pretty low - I think a lot of people just hit the front page without realizing it's more than just a "look how pretty our site is" and that they can actually go to admin and do things. Maybe we can increase the visibility of admin access by adding it to the top demo bar?

Create a guided tour for interested users.

This should be a page-by-page guided tour of Solidus. For example:

• Start on admin orders page, have text at the top of the screen that says "This is the orders page, where all of your orders are." and a next button"
• When "next" is clicked, the order filter section is whiteboxed and the text changes to "This is where you can find specific orders"
• When "next" is clicked again, the page changes to the order show page, something else is whiteboxed & explained, and so on.

An example mockup of that this might look like this (but like, better designed and with cool transitions 😄)

As you can see in this screenshot, I added to the cart the blue variant of this product, but the color in the cart's image matches the white variant.

This doesn't happen for other products, like Monogram Hoodie, where the color in the cart matches the variant added.

Frontend users have the "login" button, they should be marked as logged in though. I'd like to see the "My Account" button and allow users to see their account. Potential users are going to want to see what control their customers have over their account.

I'm not sure how difficult this will be to implement, because I think the frontend relies on a user_id which I don't have. Maybe I can just use the default users id?

Steps:

1. Create a payment method
2. Check if the payment method is listed on an incognito window

Desired Behavior
Add a fixed header banner to inform users about an upcoming design overhaul.

Users visiting our existing Solidus demo may not be aware that a new and improved version is in development. To manage expectations and build anticipation, a clear, engaging banner will be beneficial.

The current solidus is 2.11 but 3.2 is already out and 3.3 is around the corner.

This should be upgraded in one of two ways:

1. We consider this an existing app and we upgrade it as usual
2. We try to rebuild the app from scratch and reapply the changes that were required for the demo behavior, this has the advantage that it would also use the latest version of the starter frontend

The second approach seems more complex, but maybe we can do the first and still move a little in the direction of the second, so that next time we can do the jump.

The Solidus demo is not up-to-date, while it should reflect the latest version of Solidus, possibly with the Starter Storefront.

The Docker image should be updated, too, as a result, possibly via automation.

Moreover, we should add some more information on the Docker page.

This line calls exists? on the paperclip object. Most of the time this works fine.

On vanilla paperclip(like an S3 integration), the exists? call will check to see if the original_filename exists, then use that filename to check if the file path exists. Perfect.

On paperclip-cloudinary, which is what we're using, the exists? call does not check if the original_filename exists before attempting to use it - resulting in an error when it tries to convert the nil filename to a string.

Quick and dirty fix would be to toss a !f.object.send(attachment).original_filename.nil? in the if statement before it checks the exists? function result here. Feels a bit hacky... but on the other hand, do we really want to fork paperclip-cloudinary to fix this? 😛

In the context of using the demo store to debug issues or provide instructions to replicate issues like I've done here, it would be useful for users to be able to reset their demo data somehow.

I think the easiest way to do this would be to just change their sample_indicator_id, which would disassociate them from any changes they've made.

Here's what I can see: http://demo.solidus.io/admin/taxonomies/1/edit

And this is creating issues in the frontend as well:

@seand7565 can you please take a look or give me some guidance?

Some pages just aren't interesting enough to be on the tour. On these pages, we should probably just not display the tour code, or have a link to "start tour" or "continue tour"

Order shipments page API pull failed on my latest session, check to see if that's working

Maybe just use the default backend favicon?

https://devcenter.heroku.com/articles/release-phase

To avoid issues where PRs with migrations get auto-deployed without migrating

If you try to check out from the product page, your guest token will be set to something different, causing the payment method to no longer exist, and removing access from anything you've done up till that point.

We should not do that.