Hi all, thought I’d put something in this category to get a bit of discussion going.
Slowly but surely I’ve been working on updating Community Store for V9 readiness.
That’s going well, with it really just being further styling/class adjustments across dashboard pages to go - functionality wise everything seems to be working as it does in V8.
If anyone has some time to help with this, it’s really just a case of doing pull-requests against this branch. It’s work suitable for someone who is comfortable with front-end work and Bootstrap.
The main consideration is that these updates also need to work with version 8, so it’s a case of leaving in existing bootstrap 3 classes and adding the newer bootstrap ones. There’s no issue if things end up a little different in V8, sometimes structure needs to change a little, it’s really just making sure it doesn’t end up looking broken or weird.
I’ve been doing this work by running both v8 and v9 installs, but linking the community_store folder into the v9 copy - it’s then easy to work in once place but preview it in both versions.
I’ve intentionally stopped thinking about feature additions during this period, so it’s easier to work on. But once this update is complete and version 9 of Concrete CMS comes out, the question I have is: what should the focus be on next for Community Store?
Some questions might be:
What are the sticking points, or even bugs, that should be addressed before moving on to larger new features? Are there actually any new features needed (or new features via complementing add-ons)?
Do parts of the interface (like product variations) need work, and/or should they be re-thought?
Is it missing any common shop functionality that other common systems like Shopify or Prestashop offer?
Do we need to improve default shipping calculator options, or provide some more add-ons for common shipping scenarios?
Are the tax calculations flexible enough? Does it need to work with something like Taxjar? (screams in terror)
Are product and product list blocks flexible enough? Do we need more templates?
We’ve used Community Store ourselves on a number of projects, but those each have their own specific requirements, and there might be use-cases I’m simply not considering - hence me putting this broader question out there.
Hey Ryan. I might have sometime this week to play with the new V9 version of concrete cms and do a pull request for the V9 version of community store since its just front end work it needs.
I have not used Community Store for any of my client project as of yet. So I can’t really comment on what added functionality might be need. But I would like more robust documentation for community store. Maybe even a short youtube video on how it work in a live project.
I reckon that when the V9 version is ready and polished, that it would be good timing to do a demo outlining the major features and flexibility.
In terms of documentation, when you say more robust, is there a particular section of the documentation that you think is lacking? I know the documentation site itself can be missed, I’ve just updated the README for example to point at the doco instead of the wiki. In fact, the wiki really should be cleared out and just the doco pointed at.
Could the concept of product types be added or built out from categories?
What I mean is that currently all products work with the same set of attributes. So any store that sells both cars and animals has a problem with assigning attributes directly to products. Animals and cars would ideally be configured with different attributes.
How many wheels does my Elephant have? What is my elephant’s engine capacity? Does my elephant run on petrol, diesel or batteries?
Even different kinds of vehicle or animal would ideally exist in separate product types. So it could even extend to a taxonomy tree. Perhaps that would be a bit too much.
if there was an intermediate layer of product type (maybe working with categories), the attributes could be either assigned at that product type or filtered to those applicable to that product type. We could similarly have product type display configurations that present information in a way customized to that product type.
I realise all of the above can be worked round with the current store, so isn’t a blocker to using it.
From a logic and data point of view, I can’t think of any reason why this couldn’t be added - it’s really just a mapping of attribute handles to different groups.
I think the question would be whether adding something like this would be a higher priority than other features, such as being able to create re-usable option groups for product.
Hi @mesuva
I use community cart on a handful of personal sites. Thank you!
Documentation: Overall, the documentation is one of the greatest features of Community Store. It’s practical and is up to date, and I remember when I found the go-live checklist, it made my day. Go-live Checklist | Community Store for concrete5 Real use cases similar Andy’s Dreamrs might be a nice to have for different eCommerce setups.
Scheduling/booking that integrates with the built-in calendar (maybe this is already possible) an everyday use case is a beauty salon or anything with appointments: Let clients book meetings, lessons, events, or several other services.
I’ll set aside some time to contribute to Community Store’s V9 user docs updates or any other non developer tasks the CS project needs.
Cheers!
Jess
It’s interesting you mention bookings/appointments, I’ve had a few conversations along those lines just recently…
Whilst there’s a way to sell tickets to events (we have our own events/calendar add-on, but I’m pretty sure it would work with the built in calendar), but we’re yet to build or find a way to book timeslots. It’s not really the Community Store side of things which is a problem, it’s having some sort of booking platform/admin, one where it allows you define the timeslots, block things out, have multiple resources, etc.
There are quite a lot of complexities to handle, especially if you’re trying to make it a re-usable solution.
It’s something to consider though, I’ve had plenty of people asking me for such over the years.
A bit in line with @jessicadunbar I’d say what would be a real life-changer would be the possibility to extend Community Store with custom product types.
A product type would extend the normal product object but could have specific aspects to it (booking date and time, recurring payments…) That could be user-selectable during checkout. It would also have a specific method called during checkout processing. The rest of whatever the product does after being purchased would fall on third-party code outside of Community Store.
That would allow to keep CS focused on what it does without starting to add every possible option and become a huge factory type add-on.
We’ve got six live Community Store sites and another four in production - we love the simplicity for operators and the ease with which we can change the look/feel and product selection elements. I totally agree with @mnakalay, it’s important to maintain the simplicity of Community Store and not to burden it with too many edge case features.
A basic customer account area would be a really useful addition. A previous orders/reorder now type thing would be useful for most people and could be a jumping-off point for track my delivery addons etc. It would be great to have a quicker way of setting up a themed register/login/profile section in Concrete CMS but that’s probably a more general thing.
We would have found the ability to add Attributes to Manufacturers useful recently. Probably not a big change but may be helpful sometimes.
Booking Events/Timeslots would be useful but it certainly feels like a case for an AddOn to me. Similarly something for repeating subscriptions?
Overall a simple base Store that remains easy to extend and has a range of well maintained Add Ons would be the dream I think.
Instant product search
Ab lock or some configuration to add a product search with thumbnail preview (ajax or other frontend technologies)
Order history for customers
I use a package from jero but probably a good addition to the main installation.
Configuration to hide settings in the product editing page. There is lot of stuff to configure and for each project you only need a handfull off festures. Hiding some parts would help our clients to manage the right things.
But generally I simply love the cool store package!
This is some really great feedback, thanks everyone.
There’s quite a few ideas here that I think would be worth directly adding to the core of Community Store, stuff that really has to be there. But things like searching would be fantastic to have as an additional add-on.
I can appreciate that. I’ve been working on a project (non Concrete) recently where due to their location in the world getting a payment gateway happening has been really difficult.
We’ve ended up using Fondy - https://fondy.io/
My question is, is there a big/obvious payment method to support first? Would that be Yookassa, or something else?
I know that PayPal is supported in Russia, but… well… it’s Paypal…
The challenge with building these gateways is that they’re a non-trivial amount of work. Many of the ones that have been built so far have either been because of a client project, or have been paid to be built (and then open sourced).
PayPal is not quite supported in Russia. You can receive payments but all other operations are prohibited because PayPal refused to obey the law. So PayPal is out of the question in Russia.
No one will use international payment platforms because it’s impossible to withdraw funds or to transfer them to a local bank account.
Yookassa is one of the biggest players. It used to be owned by Yandex (Russian Google analog), then they sold it to Sber - Russian biggest bank. So it’s big, popular and easy.
The easiest (I guess) and most secure implementation should be to send data to their site to process and then return on success, not to process the lot on your own website. And that’s what most Russian sites do.
I tend to prefer the offsite processing these days, so Stripe Checkout, etc.
Whilst some people prefer to keep a customer on the site, there are often a large number of advantages of using a gateway provided interface. E.g. being able to turn on Google and Apple pay trivially. It tends to be a little easier too, and there’s less to style on the checkout side of things.
To be honest, because of the above, I’ve never used the CS on any site I’ve created in Russia because everyone wants to process payments…
I’ve just downloaded and installed the master. I’ll check it out and will post comments as I go.
Yookassa payment addon
it would be great if an option of adding a logo image for manufacturers is added and then automatically appear on the product if the image is uploaded.
what about saving a random SKU for a product if it’s left empty?
why is the Products page excluded from navigation after package installation?
why isn’t the Product List block installed on the Products page on installation?
I’ve got a “Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data” after clicking Add to Cart, although the product is added but the spinning wheel is always turning because of that JS error
something’s wrong with JS, clearing cart also results in error, in fact clicking all cart JS buttons result in error
are attributes used only in Dashboard? I can’t see any on the products list. Although I can see options there
What’s the difference between groups and categories? Are categories a subgroup of a group?
Always download a release for usage, not the master. Master is for development.
Cool, will keep Yookassa in mind.
The manufacturers was contributed recently, but I think it’s highlighting that those should be expanded in terms of attributes for better flexibility.
I don’t think it makes sense to enter a random SKU, as that’s a piece of data normally generated in whatever system that is managing stock, rather than the store being the source of that information.
It’s excluded as more of the time (or at least that’s my experience) people are wanting to set up their shops with their own categories, maybe adding products to the home page, etc. The top level Products page is really more of somewhere to group the created product pages - but of course there’s always the option to unhide it and use it as you see fit.
Same sort of reason as number 4, in that out of the box that Product page is more to hold products, rather than list them. But maybe it’s also an oversight, and it would be good to at least add that block. Some of these decisions go way back.
There’s actually some doco written to explain the difference between groups and categories: Product Categorization | Community Store for concrete5
In short, groups are more like sets, whereas Categorisation is like being able to virtually nest product under pages in your sitemap.
Re. 4 and 5, I guess it’s a personal preference. I just like to see stuff after installation, even if it’s a page with a single word from the package. At least I know what’s going on. It took me a few minutes to recall that the page may be hidden and then I saw no product on it although I had added it.
I thought there are products which can be part of categories which are part of groups simply as a matter of a dropdown selection. But there’s something to do with pages… I have to understand that better
