I would be interested, a lovely learning curve and a beautiful end product.

I would definitely be interested!

I too would be interested in something like that.

I would like Sylius but a framework agnostic version with Symfony and Laravel drivers.

+1 for this. Been looking for a Laravel 4 solution to E-commerce for a while now.

That would be awesome!

I would be able to participate in making it. I've created multiple tutorials about building a shop, from creating a review system to implementing fancy search-as-you-type to pagination in-place using Backbone.js, maybe some parts could be integrated with this open source solution?

Check the list here: http://maxoffsky.com/code-blog/building-a-shop-with-laravel-tutorial-series-announcement/

Please let me know if this would be helpful.

I think that this is a good starting point. https://github.com/Sylius/SyliusCartBundle

ShawnMcCool said:

I think that this is a good starting point. https://github.com/Sylius/SyliusCartBundle

These were my thoughts exactly Sean. If we started a fork of sylius with intention to make it framework agnostic it would be beneficial to the community as a whole and also garner more interest.

Awesome response people... I will keep you all updated

+1, would be a great project. Sylius is definitely worth looking at.

I guess I am a little curious about the purpose of such a project? By that I mean, is it intended to be a viable and competitive ecommerce application or is it intended to be an "eat your own dog food" proof-point/learning tool for Laravel? Or both?

Don't get me wrong, I think the project sounds interesting and I would probably be interested in participating (I am not a professional programmer, but have been in the software industry for 20 years in other capacities), but I wonder what we might want out of this? What are our motives?

Take Sylius. It seems (to me) to be as much of a proof point for Test Driven Development (Behat and phpspec) as it is a credible ecommerce package. It is highly dependent on Symfony for a reason... to emphasize stability of the platform. But would someone looking for an ecommerce package really care if it was developed using TDD methods? This aspect seems a bit geared for the academics not the actual target market.

I defiantly agree with you on some of the points that you have made m0j0r1s1ng.

Although the advantages of a TDD are massive. Its true that an end user most likely would not care weather its TDD or not. The whole point of TDD is not as a marketing tool but as a development tool to create very stable, bug free software and speed up the testing phase of development. You do not need to be a computer scientist to see the advantages of a fast paced and very stable application.

PHP in my opinion seriously lacks a decent e-commerce offering.

An offering tied into the composer ecosphere has countless advantages.

I also want to contribute?

UPDATE: I posted an issue on the core Sylis repo describing the intentions / need to convert the sylius packages to framework agnostic composer packages.

There was a very posative response, they are already actually undertaking this as a pull request. So i believe we should direct our attention and resources their.

Thus we can create a specific Laravel / Eloquent implementation once that is done. This is very very good news.

view the topic: https://github.com/Sylius/Sylius/issues/969

m0j0r1s1ng said:

Take Sylius. It seems (to me) to be as much of a proof point for Test Driven Development (Behat and phpspec) as it is a credible ecommerce package. It is highly dependent on Symfony for a reason... to emphasize stability of the platform. But would someone looking for an ecommerce package really care if it was developed using TDD methods? This aspect seems a bit geared for the academics not the actual target market.

I really don't agree with the sentiment that TDD is specific to academics.

Hi everybody,

I'm Pawel Jedrzejewski and I started the Sylius project. When I discovered Symfony2 in its early days, I really wanted to create shops for my customers using this new piece of technology, so I created some standalone bundles for e-commerce. I've open sourced them at some point. Last year, we've decided to create a full application using these standalone components.

As you said, Sylius is coupled to Symfony2. And I want Sylius to be Symfony2 based, because I love this framework. That being said, I think there is a great potential in different communities working together. You can read more here - https://github.com/Sylius/Sylius/issues/549, this is an RFC that started our work on extracting standalone PHP components from our bundles. And, as you see, our code is quite decoupled so it wasn't so hard to do. We left our Symfony2 bundles very skinny. :) We stopped for a moment, because of a large Sylius adoption that would get into trouble if we merge such change and just tag the releases. (we're not stable, so I would prefer not to branch off)

I've got in touch with Drupal Commerce guys and I think there is some space for collaboration with them as well. I think it would be just amazing if we can get all together and collaborate on a generic set of PHP e-commerce components.

And Sylius seems like a good starting point... But I'm sure you have some questions or concerns regarding that and I'm here to discuss it with you. :)

One thing to note is that afaik Lavaral now exposes a "clean" HttpKernelInterface. This means that integration of Laravel apps into Symfony2 apps and vice versa is relatively trivial to do. While this would maybe not be exactly what a Laravel would like, it does mean that its possible to use Sylius for ecommerce and Laravel for other aspects of a project.

That being said, as Pawel points out, the Bundles are relatively thin already and pushing this forward even more is of course much easier once there is another community is there to help make it happen and ensure that the boundaries of what should sit in a lib/component and what may live in framework specific layers are chosen properly.

ShawnMcCool said:

m0j0r1s1ng said:

Take Sylius. It seems (to me) to be as much of a proof point for Test Driven Development (Behat and phpspec) as it is a credible ecommerce package. It is highly dependent on Symfony for a reason... to emphasize stability of the platform. But would someone looking for an ecommerce package really care if it was developed using TDD methods? This aspect seems a bit geared for the academics not the actual target market.

I really don't agree with the sentiment that TDD is specific to academics.

Shawn, I should not have used the word academics as this is much too trite and not very accurate. What I was trying to convey is that TDD might not be an end-user feature per se, though I concede the point that @andrewmclagan makes above that use of TDD can contribute to the overall quality and stability of the package... which certainly is something the target user is looking for.

I have actually been building an open source ecommerce engine using parts of sylius for the past several months. It has been somewhat difficult since the components are not currently decoupled. However the end goal is to use a bit of everything similar to how laravel uses symfony and other packages. I have to get a little more fleshed out in order to release some code but it could be a good starting point for something like this?

Would definitely get behind this and contribute

definitely interested in something like this.

since everyone has a different vision of what they would want the final cart to look and feel, perhaps we can look into developing it so it's built around a rich set of apis, (i.e. add to cart, compare products, authorize payment, etc...) making it more friendly in allowing the developer to heavily customize the checkout flow, etc... by piecing together the different api calls, instead of having everything ready out of the box, like the typical php shopping cart.

lemonstand.com actually did it very nicely in making it developer friendly, but they are moving to a saas model. would love something like that in laravel.

https://github.com/drhenner/ror_ecommerce

was looking at that ruby cart and was about to create something similar to that in laravel for the cart portions that i need. they have an interesting way of setting up the cart that is pretty flexible.

http://www.ror-e.com/posts/29-e-commerce-tips-1-2-the-shopping-cart

since everyone has a different vision of what they would want the final cart to look and feel, perhaps we can look into developing it so it's built around a rich set of apis, (i.e. add to cart, compare products, authorize payment, etc...) making it more friendly in allowing the developer to heavily customise the checkout flow, etc... by piecing together the different api calls, instead of having everything ready out of the box, like the typical php shopping cart.

Personally, I don't agree 100% with this. Sure, having the option to pick components from here, there and everywhere would be good, but something that's easy to deploy would be handy too. I work a lot with Magento, and it's absolutely disgusting to work with. But it's so popular because it deploys easily and has a massive feature set built in.

To build an eCommerce platform that takes off the ground, I think it will need to appeal beyond the developer community. Sure, we want the ability to hack about with it as much as needed, but a good, solid platform that a non-hardcore dev can easily deploy (as one would do with Magento) would be advantageous.

that's true, it would probably be nicer to have it ready and start working. but as long as there's before/after events around major functions and the ability to overrride methods, it could achieve developer flexibility. that's what lemonstand does. has a lot of before/after events and api calls you can make as well in your custom pages.

another idea is to see how development of octobercms goes and use that to base the cart on that. but that is a few months away however.

keyurshah said:

another idea is to see how development of octobercms goes and use that to base the cart on that. but that is a few months away however.

I think PyroCMS would be the better match since it's probably closer to launch.

I have been working with lemonstand since beta and plan on bringing over some of the finer features and functionality. Personally I am building this from scratch since I think basing it off a pre-built cms such as octobercms or pyrocms would not be very appealing in the long term. Its great for short term to get something off the ground, however If the visions are not aligned at any point in time then it is going to be difficult to take on the likes of magento and other platforms when you not only depend on laravel and all of its dependencies but also a 3rd party cms. Imagine needing a core change in order to make something critical work only to have them deny the pull request. Its way to risky in my opinion.

shansma said:

keyurshah said:

another idea is to see how development of octobercms goes and use that to base the cart on that. but that is a few months away however.

I think PyroCMS would be the better match since it's probably closer to launch.

isn't PyroCMS CI-based? I think the idea was using a Laravel foundation for the eCommerce app.

m0j0r1s1ng said:

shansma said:

keyurshah said:

another idea is to see how development of octobercms goes and use that to base the cart on that. but that is a few months away however.

I think PyroCMS would be the better match since it's probably closer to launch.

isn't PyroCMS CI-based? I think the idea was using a Laravel foundation for the eCommerce app.

Yes, but they are slowly moving to laravel a little bit at a time. I am not sure how long before the transition is complete or usable for something like this... but probably not something to wait around for. Secondly octobercms was created by the co-founder of lemonstand ecommerce which is now a saas only product. So creating anything ecommerce would be in direct competition with the company he founded. It may not be wise to build on such a platform unless you are guaranteed that the product would be approved and not shut down if it poses a threat to his main company.

+1 would love to help with this.

I feel this post is veering slightly off topic.

Basically i have now been in contact with the developers on the Sylius project, looked over the issue tracker and codebase. Good progress has already been made to decouple the various components of Sylius from Symfony2.

What im interested in is developing a Laravel application from these components and assessing how much support there is in the Laravel community for an e-commerce project with this approach.

Sylius developers are looking for support from the ZF2, Drupal commerce, Laravel and of course Symfony2 communities. If momentum can be generated (and there is a already considerable amount) it would benefit the PHP ecosphere immensely:

• More developers working on the core Sylius components
• Further promote / develop the composer ecosystem

andrewmclagan said:

I feel this post is veering slightly off topic.

Basically i have now been in contact with the developers on the Sylius project, looked over the issue tracker and codebase. Good progress has already been made to decouple the various components of Sylius from Symfony2.

What im interested in is developing a Laravel application from these components and assessing how much support there is in the Laravel community for an e-commerce project with this approach.

Sylius developers are looking for support from the ZF2, Drupal commerce, Laravel and of course Symfony2 communities. If momentum can be generated (and there is a already considerable amount) it would benefit the PHP ecosphere immensely:

• More developers working on the core Sylius components
• Further promote / develop the composer ecosystem

Doesn't Running Symfony2 and Laravel together get slow the script ? And using them might increase file size. How can we prevent that ?

We would not be running Symfony2 and Laravel together. these are the key lines:

• "decouple the various components of Sylius from Symfony2"
• "Framework agnostic composer packages"

Make things work in the composer ecosystem would be great benefit to PHP ecosphere. I'm from Drupal community, I'm a user of ubercart and drupal commerce. It would be great to have all PHP commerce guys work together. I would like contribute.

keyurshah said:

since everyone has a different vision of what they would want the final cart to look and feel, perhaps we can look into developing it so it's built around a rich set of apis, (i.e. add to cart, compare products, authorize payment, etc...) making it more friendly in allowing the developer to heavily customize the checkout flow, etc... by piecing together the different api calls, instead of having everything ready out of the box, like the typical php shopping cart.

We're already working on this right now, it's called Moltin, here are the API docs. You're not locked into any platform or programming language so going forward you can switch out or add additional front ends without having to go through the painful migration process between platforms.

We also have a number of composer packages available on packagist that you can pick up and start using pretty quickly for your own projects.

If anyone has any questions just drop me a message at [email protected]

AJSturrock said:

keyurshah said:

since everyone has a different vision of what they would want the final cart to look and feel, perhaps we can look into developing it so it's built around a rich set of apis, (i.e. add to cart, compare products, authorize payment, etc...) making it more friendly in allowing the developer to heavily customize the checkout flow, etc... by piecing together the different api calls, instead of having everything ready out of the box, like the typical php shopping cart.

We're already working on this right now, it's called Moltin, here are the API docs. You're not locked into any platform or programming language so going forward you can switch out or add additional front ends without having to go through the painful migration process between platforms.

We also have a number of composer packages available on packagist that you can pick up and start using pretty quickly for your own projects.

If anyone has any questions just drop me a message at [email protected]

Moltin seems like a wonderful project and an awesome concept. Although my only issue is in the past i have invested in closed source SaaS models and the company has later gone out of business. This in my opinion is an unacceptable risk as then i would have multiple client sites not just out of action but irrelevant.

As much as i believe Moltin is here to stay there is no way possible that a company can give me that assurance and ownership with a SaaS model. Even large companies disappear over night AKA Kodak?

Therefore i truly believe that a non SaaS, open source offering is the only way forward for development firms.

I agree with a non SaaS, open source offering. I will be releasing concept stage platform early this year. If anyone wishes to collaborate sooner than that feel free to contact me at my GH email. In any case I am excited to see some movement in this area!

patrickheeney said:

I agree with a non SaaS, open source offering. I will be releasing concept stage platform early this year. If anyone wishes to collaborate sooner than that feel free to contact me at my GH email. In any case I am excited to see some movement in this area!

Why not open source what you have now so we can extend it as a community?

andrewmclagan said:

Moltin seems like a wonderful project and an awesome concept. Although my only issue is in the past i have invested in closed source SaaS models and the company has later gone out of business. This in my opinion is an unacceptable risk as then i would have multiple client sites not just out of action but irrelevant.

As much as i believe Moltin is here to stay there is no way possible that a company can give me that assurance and ownership with a SaaS model. Even large companies disappear over night AKA Kodak?

Therefore i truly believe that a non SaaS, open source offering is the only way forward for development firms.

Your concern is completely valid as the team here and I feel the same way about a completely closed source SaaS model (we're developers too!). This is a hurdle that we must overcome for a number of reasons and we have been discussing this since we started development. We're looking into ways to mitigate this risk, such as being able to easily get all of your data from our API (which you always have access to).

We love the open source community and this is why we have some of our core packages available for you to use in your own projects. Open source can have its own drawbacks though over time including redundancy (no long term plan), maintenance and support. The same can be said for a number of the currently available e-commerce solutions and the nightmare it is to upgrade/migrate. A SaaS solution goes a long way to alleviate many of these issues, though ofcourse there are benefits and drawbacks to each approach.

So what will we do ?

@ Motlin Honestly, haven't looked at the site but if I'm hitting an API ... Not interested.

Hmmm, so all your posts are to build brand awareness?

@ topic So, is this going to be a cart or a full aka magneto solution?

@ stylus I was looking at porting it to L4 a few months back and came to the same conclusion of it being coupled with SF2. Also, spent a few hours in MySQL workbench with the DB and realized that my L4 skills would challenged.

@ those offering to help Are you just offering testing or actual coding time?

+1 I would find a way to contribute ^.^

It seems like no one cares this project.

shansma said:

patrickheeney said:

I agree with a non SaaS, open source offering. I will be releasing concept stage platform early this year. If anyone wishes to collaborate sooner than that feel free to contact me at my GH email. In any case I am excited to see some movement in this area!

Why not open source what you have now so we can extend it as a community?

I definitely plan to open source it at the first opportunity. Right now its a bunch of components that are not ecommerce related that will be needed first in order to add the e-commerce layer on top. The ground work needs to be in place before bringing in a community otherwise I will get a flood of messages about the vision, direction, how we can help, bug reports, etc and not have time to actually develop. I'd rather a basic structure be in place at a very early alpha stage, the vision and contribution guidelines written out, and then bring in a community to help build it and talk about the different technological problems and ways to solve them. Releasing too early would not benefit the project in the long run.

At Sylius, we'll extract the standalone php components anyway, because it is the right architecture decision, makes our code cleaner, more decoupled and opens collaboration opportunities like this one. We have a growing community and more contributors every week, you guys can join us for some time and see how things work on our side and see if you want to reuse our components for Laravel based platform. I'm not familiar with Laravel, so I would not be able to participate much in the coding, but definitely ready to help with some discussions.

As I said, Sylius will extract the components anyway, so hopefully you will be able to start Laravel platform on top of our foundation. Obviously, I'd love to see some collaboration, because Laraval community and its expertise can have major impact on Sylius and PHP in general.

To sum things up, obviously I can't see myself in some leading role around this project, as my open source time is completely consumed by Sylius and I don't know Laravel. However, if you would like to organize some working group to actually make Laravel shop happen, I'm here to help and happy to participate in such awesome initiative.

Regarding the Sylius packages: how can I follow the decoupling progress? If there are any already available as independent packages, is there a way to learn how to use these packages?

I've been working on and off making a laravel ecommerce package for a little while now. You can see it here http://github.com/shopavel

I've largely been using it as a way to practice laravel, but it is something I intend to continue with.

lsjroberts said:

I've been working on and off making a laravel ecommerce package for a little while now. You can see it here http://github.com/shopavel

I've largely been using it as a way to practice laravel, but it is something I intend to continue with.

looks great

zenry said:

lsjroberts said:

I've been working on and off making a laravel ecommerce package for a little while now. You can see it here http://github.com/shopavel

I've largely been using it as a way to practice laravel, but it is something I intend to continue with.

looks great

Thanks :) Any suggestions / feedback is always welcome, I'm hoping to get an initial alpha out by end of April or so.

lsjroberts said:

Thanks :) Any suggestions / feedback is always welcome, I'm hoping to get an initial alpha out by end of April or so.

a suggestion would be to drop Cartalyst\NestedSets, while it's really great, you need a subscription to their Arsenal

take a look at https://github.com/etrepat/baum and see if that works for you

zenry said:

lsjroberts said:

Thanks :) Any suggestions / feedback is always welcome, I'm hoping to get an initial alpha out by end of April or so.

a suggestion would be to drop Cartalyst\NestedSets, while it's really great, you need a subscription to their Arsenal

take a look at https://github.com/etrepat/baum and see if that works for you

Huh, I switched to that a while ago and am using that here - https://github.com/shopavel/shopavel/blob/master/src/Shopavel/NestedSets/Node.php

Must be an old bit of code. It does need a bit of cleaning.

@lsjroberts How do install your packages?

I just finished rolling my own ecommerce site with Laravel. Nested categories with baum, full product browsing (filters with sorting, price, sub-cat, brand, rating, etc), search, ratings, reviews, q/a, product tags, order admin, stripe/bitpay/paypal integration through omnipay, integration with easypost api for easy shipment label creation, stock management, product variations, product specifications, user accounts, user address management/saving, product images stored with S3, etc.

It's for a single site --- not developed as a package. I'm honestly not sure how long it would take to generalize everything and open source it, and right now my next planned project is in the CMS world --- but this is something I want to do in the future (unless cartalyst releases their package.....)

That would be great and unique, specially if be organized and complete, not just cover some part, both back-end and front-page. How we can be informed about its news?

I am working on something similar and would love to see your code even if it's only for your site. Just to understand coding concepts.

Sure thing --- you can follow my (rather bare, coming from bitbucket) github profile if you'd like, and that should notify you when I put something up. I can't make any time promises, though.

@ Andrew Any chance of just dumping what you have on github or is this a project you did for a client?

I would certainly be interested in helping with this; its something I have been tinkering with, on and off for the past 9 months or so.

Dear All, We have started with a full blow e-commerce / shopping cart solution on top of Laravel4 we will soon post more updates.

andrewmclagan said:

I feel this post is veering slightly off topic.

Basically i have now been in contact with the developers on the Sylius project, looked over the issue tracker and codebase. Good progress has already been made to decouple the various components of Sylius from Symfony2.

What im interested in is developing a Laravel application from these components and assessing how much support there is in the Laravel community for an e-commerce project with this approach.

Sylius developers are looking for support from the ZF2, Drupal commerce, Laravel and of course Symfony2 communities. If momentum can be generated (and there is a already considerable amount) it would benefit the PHP ecosphere immensely:

• More developers working on the core Sylius components
• Further promote / develop the composer ecosystem

Andrew we would be very interested to contribute, we are starting off and are planning to use Sylius components as well would be happy to contribute we can put in dedicted man hours too if required, Please hook me up with the Sylius project lead.

I have some initial ground work / components in place. I hope to open source the beginning stages of this soon. Contact me at evocore[at]gmail if you are interested in joining the project.

Hey guys!

Just for your information, the components are already available. There are some little compatibility bugs most likely and not much documentation, but we made the first big step. If you are still interested in reusing Sylius within Laravel, let me know, I'll be more than happy to help with bootstrapping such initiative. :)

Cheers, Pawel

I'm rather new to Laravel development, but would be very interested in making whatever contributions I can to this project; it seems very exciting.

pjedrzejewski said:

Hey guys!

Just for your information, the components are already available. There are some little compatibility bugs most likely and not much documentation, but we made the first big step. If you are still interested in reusing Sylius within Laravel, let me know, I'll be more than happy to help with bootstrapping such initiative. :)

Cheers, Pawel

Your best bet would be to do the bootstrap project yourself, providing the minimal amount of code necessary for the laravel community to get started.

I am very interested in possibly using the Sylius components if they can make my life easier.

I'd like to contribute as well =]

I would be interested and willing to be contributor. thank

This is too good to be left alone like this :(

What's the status of this? Any repo up yet?

Is it on allready?

Hi guys, any news on this?

Would be definitely interested to contribute.

Is decoupling completed? Have any one tried creating a wrapper/ServiceProvider?

Very interesting ! i'll follow this project to learn some good stuff and contibute if possible (new to laravel)

seems someone is working on it !
https://github.com/Crinsane/LaravelShoppingcart
https://github.com/liamqma/Laravel-Ecommerce

Has this kicked off yet?

I would be interested in being one of the leaders of this project.

Our company has used various systems over the years and we do work quite extensively with Magento. Magento in certain parts is a great system and has some great features but is a pain in the neck to work with. It's extremely bloated and the learning curve can be quite daunting for a lot of people. Version 2.0 looks promising but again has numerous issues with it (we believe so) and is over 3 years late and who knows if it will ever be released.

I believe Laravel is the framework that can be the catalyst for a friendly and accessible ecommerce system that developers all over the world can use. The syntax in Laravel is the best we have seen and we would be interested in this project but only if the goal is to become the leading ecommerce system in the world.

There's no point in just making another ecommerce system when there are so many others that have such a large head start.

I'm still very interested in pursuing this. Although for the next few months I will be unable to contribute.

Although if someone makes a start now, I'm sure this will be all the encouragement I need.

Laravel already incorporates many symphony components, so that would be a starting ground for anyone interested.

Ok so after further investigation it seems that integrating Sylius components will be out of line with the objectives I think we are looking to fill.

Mainly the tight coupling with Doctrine ORM. One of the main reasons I use Laravel is for the Eloquent ORM personally im not willing to sacrifice this.

Also there are some architectural decisions within Sylius (totally valid) that I would want to change.

Im seriously considering to begin development of a from scratch solution.

Further interest from other developers would be very very appreciated. anyone still putting their hands up?

I would be very interested in working on a project like this!

The fact we would be building from the ground up interests me even more :-)

awesome!

so to flip again... the small problems that I had with Sylius composer modules has been resolved. I brought up an issue on their github tracker: https://github.com/Sylius/Sylius/issues/2232 so now it looks good to integrate and share the sylius components.

So now the question begs...

What do we call the project?... :)

Awesome idea. Give me a call if you need any help!

Great! Im so up for this. Don't have any name suggestions, but will happily put som effort & time when repo is up.

Hello, I work with Impulse Creative (http://www.impulsecreative.com/)

I'm interested in contributing as well.

We are currently developing quite a massive application in Laravel 4.2 for Pharmacy Development Solutions (http://www.pharmacyowners.com/).

At some point there will be a section of the application that will handle e-commerce and it's proving to not be so 'easy'.

So, us developers here are offering our services (in our free time of course) to get this on track.

Im actually struggling with certain decisions regarding the integration of Sylius Components into Laravel. As this would cut our development time massively and leverage a cross community solution.

Issues with this approach:

• Sylius is based off Doctrine ORM that uses the "data mapper" pattern. Unlike Laravel with uses Eloquent and an "active record" pattern

• No matter what is stated, Sylius components are essentially tied to Doctrine because it is the only (real) option for the data mapper pattern in PHP.

• Would we alienate most of the Laravel community by using Doctrine? Thus loosing most of our user base and the project never really taking off?

• If we ditch doctrine, and the data mapper pattern, there is not much use for Sylius components apart from a little bit of a guide designing our own components on the active record pattern.

• maybe there is another way that we could integrate sylius components, with their plain old PHP models that I'm just not seeing???

your thoughts...?

I'm not sure, but something tells me that for instance the Product model would be problematic to implement with Eloquent. The "win" of using Eloquent is mainly retrieval and saving to DB, which probably still would have to be put somewhere else in a project like this. For instance, when saving a product a master variant should be created/assigned, a category might need to recache/reindex or whatever. This could obv be done via the events dispatched by Eloquent, but it would probably be bloated very quickly.

Eloquent also has a 1:1 relationship between db-table and model, which is certainly not true in the Sylius product model. It has lots of fields that are "calculated" of db fields (not necesseraily on the product table, for instance isInStock() that checks inventory tables).

I have made the decision to go with Eloquent and the active record pattern. As a few people have pointed out, it would be counter productive to swap out Eloquent when the whole community is already using it and spent the time learning it.

Moving forward the core principals of the project will be:

• An eco-system of independent, re-usable, framework agnostic packages.
• Ability for developers to integrate elements of the system into their existing applications.
• Product variations, options and attributes system based off the EVA pattern.
• Extensive documentation written in parallel to each package, not as an afterthought.
• Re-usable administration package including auth, data-tables, menu system etc. to integrate into Laravel applications.
• Full test coverage using PHPSpec for unit testing and PHPUnit for integration.
• Focus on enterprise level e-commerce without the complexity, usable by small and medium business.
• Fostering the developer community as this is OUR target audience, whilst developers target the customers.

At present one of the most re-occurrent issue with e-commerce platforms is that they don't integrate well with existing applications and business logic. A system that is focused on discreet packages that integrate into an entire system gives developers the opportunity to pick and choose what they need to integrate.

I'm hoping to make the repo public by the end of January at a basic functional level.

Of course suggestions and disagreements are encouraged, this is open source.

@andrewmclagan: Is there progress been made on this? A github repo or some such? Would be interested in having a look over it and contributing however I can.

I Would also love to contribute ASAP. Not only as a developer, but perhaps mostly as one that has built, been/is CEO of, and tangled a lot with current ecommerce platforms.

Interesting that lots of people are willing to check out/look over or contribute but only Andrew who posts solid and thought provoking comments.

I'd love to see some proposals ;)

@illuminate3: People have different strengths. Certainly writing a spec for an eCommerce platform is not one of mine, but I'm willing to contribute code and testing and docs to up my PHP game.

I've lightly used Magento and redSHOP before and another bespoke system my employer has. I doubt I have any insights above basic specs. If there is something more conducive than a forum thread to add to I am happy to check it out and add my 2 cents.

I'm hoping to make the repo public by the end of January at a basic functional level for people to start pull requests from there.

The reason I have been biding my time setting up a repo is simply because initial architectural decisions are so crucial to the life cycle of the project.

@andrewmclagan: I feel ya. All good. Post a thread when you're ready. I'll follow you on Github too. This project dovetails nicely with an internal project I am doing for my employer - will be nice to take lessons from both projects and apply them to the other.

Maybe a hangout to check all the main specs willl help keep in mind that before start the project

By the way... i would like to help :)

So I'm posting a link to the repository so people can begin pull requests and issues

https://github.com/Jiro-Commerce

It's being posted way too early, therefore some points to note:

• It will be hard to do any pull requests as I have only the product repo up presently.
• No-one will know much of my plans or architecture from this point.

And yes the it is called Jiro
(Jiro-Commerce on github as Jiro is taken)

One of the main problems I have identified with the Sylius project is how fast they move.

They seem to be more concerned with new feature development rather then consolidating the current features and paying attention to the front-end. Don't get me wrong their test coverage is incredible therefore they have rock-solid code.

I would rather have a slower roadmap and a production usable codebase sooner, even if it does have less features.

May i ask how you will chose to handle variants? The "Sylius way" with master variant, or the Magento way where there is no such thing as a variant - all "variants" are products with own attributes and they can be bundled into different types of products?

That is open for debate. I'd actually like some input on this.

I think it would be more logical to work with a "master" product, a variant is still the same product with maybe an other colour or size.

Lets take a T-shirt for the "all variants are products with own attributes" method: You will also make a new product variant for different sizes. This would become very messy and unmanageable.

Those are my 2 cents on that matter xD.

They way I'm currently seeing it is by asking What's different about a product and a varient?

Well any attribute / property that needs to be unique in a product that has differing attributes / properties, such as: SKU and Price

That is the reason I'm leaning towards the "Sylius way". Having a master varient for all products. With some nice fluent api on the product model we can make it less daunting for people learning the platform.

It just seems more normalised to use a master varient then have this on the actual product?

What do you think? What are the advatages / disadvantages for the Magento way?

I would say the Sylius way is superior. Mainly because it's making working with products SO much easier, since you wouldnt have to make a whole product (with categories, descriptions etc) every time you want to add a new variant. It's also techinically easier to work with, since there's a distinct difference between a product and a variant.

There are however two things regarding this that I think should be thought of.

The first one is that attributes/eav should not only be applicated on products. Variants might have attributes that are not "options", but some kind of meta data. For instance, i have a shop that sells bikes. Bikes "options" is frame size, but thats not so intuitive for users - so we have person_height_from and person_height_to as attributes on the variants. This should obv be shown on product detail, but should also be able to be used as a filter/layered navigation. I don't really have good solution for this, but i see atleast two options:

1. Simply let attributes be applicated to variants as well. Perhaps any given attribute can be marked as "product attribute" or "variant attribute" to make handling easier. This would be very flexible, but would be kind of hard to handle (since you would have to access all variants when performing filtering, search etc)
2. Instead make a new concept of "size table"/"size chart", where user/administrators creates table headings and choose which option that should be mapped. If so, for this example we would create the table with two headings "person_height_from and to", map it to the option "frame size" and then be able to fill in each value for each option value that is assigned to a product. This would make it easier, since the size map actually is tied to a product.

The other thing i can think of that is not very well handled in any ecommerce system is the possibility to "soft" link options. Example: you sell a T-shirt in pink and black. Obiovusly, the customer who buys the pink might not be interested in a black and the same could be true the other way around - so both products has to be shown in category pages/search results etc. This will not be good for SEO since we would have two (probably a lot more) almost identical pages, and for UX it's not very good either when coming to product detail and not being able to see all available options. This could be solved with some relationship, but i think the best way would be to have some kind of flag on every option, like "should split in catalog". Another example of this would be a MacBook Pro, where you might want to show both retina and non-retina in the catalog, but give customer the option to choose when on product detail.

I DO realize this won't bring to much up on the table, but it's some thoughts that might or might not help planning the project.

Consider thinking in SKU since they are/should be different even among products that are "essentially" the same besides "color" :-)

@illuminate3 nice way of putting it. SKU to spell it out Single - Stock - Unit

refers to a stock keeping unit, a unique identifier for each distinct product

Thus each variation of a product is really a product in itself. THAT is why I love the way Sylius addresses this issue. Even a Product with no options / variation still has one master variation, purely to make developing more consistent.

• every product has a variation
• every product has options
• every option has values
• every variation represents a combination of options and their values

For Example

Product:

 * T-Shirt

Option:

 * Size
      * * Small
      * * Medium
      * * Large
 * Colour
      * * Red
      * * Green
      * * Blue

Variations:

 * SKU: XXXX    - Size: Small     - Colour: Red
 * SKU: XXXX    - Size: Small     - Colour: Green
 * SKU: XXXX    - Size: Small     - Colour: Blue
 * SKU: XXXX    - Size: Medium - Colour: Red
 * SKU: XXXX    - Size: Medium - Colour: Green
 * SKU: XXXX    - Size: Medium - Colour: Blue
 * SKU: XXXX    - Size: Large     - Colour: Red
 * SKU: XXXX    - Size: Green     - Colour: Red
 * SKU: XXXX    - Size: Blue       - Colour: Red

Therefore the Models, Entities, Repositories or whatever-you-want-to-call-them would be:

• Product
• Option
• OptionValue
• Variation

As a side note development on the repo has stalled until Laravel 5 stabilises. Currently there is to much changing to warrant moving further.

I will also interested on this idea.

This seems like a really promising project and good job @andrewclagan for taking the lead.

From the limited amount of thinking I've done about this the variable product problem is probably the most challenging. I like the suggested way of doing it but it seems the app will generate the variations automatically depending on the options chosen for the master product. This is currently the way WooCommerce does it.

From a UI point of view there might be a few steps when making a variable product:

• Visit the "add product" page
• Select "variable product" as the product type. (Non-variable products would still have 1 variation)
• Select attributes/options (e.g. size, color) that are applicable to the product, and available "optionValues" (e.g. large, red etc).
• Click "generate variations". All possible combinations of options and their values are generated.
• User fills fields such as SKU, price, stock qty, variation image.

For products with even just a couple of options you quickly end up having many variations. This could present tedium when adding products as each variation has to be set up individually (e.g. inventing many unique SKUs etc for each variation). It might be good to have master SKU, price etc fields for the product and each variation inherits these if they're not set on the variation themselves.

I guess one question is do you differentiate between variable and non-variable products? Or do you always have at least one variation? If so how do you handle lack of options on a non-variable product?

About a month a go, the company I work for launched a Laravel based webshop. Although we're not open-sourcing our solution you can see the list of used packages here: https://murze.be/2014/12/a-laravel-webshop/

In the latest weeks, this project has been pretty active developed: https://github.com/lavender/lavender Looks pretty promising!

It looks nice, although the core aim of this project is to have discreet, independent packages that can be used separately or in an integrated system. Most people develop applications and CMS's alongside a e-commerce package.

https://github.com/Jiro-Commerce

https://jiro-commerce.herokuapp.com

Slowly coming along. More repos will go up soon. Followed by a rough time-line.

Think we will be looking at 12months to 1.0 at least... jump on board and lend a hand!

Looking great. When I figure out how to pull in packages for dev purposes I'll see if I can contribute anything.

Just thought I'd ask about the schema decisions as this seems to be the first step in designing such functionality and will determine flexibility further down the line. It's not ideal to have to modify the schema in the future. There's this issue which is asking for clarification.

From my (admittedly limited) knowledge it seems the WordPress schema approach seems pretty flexible as it allows a lot of flexibility with a pretty simple database schema as it makes extensive use of a key-value, kinda NoSQL style design but in a relational database.

I like the way WooCommerce makes the most of this by basically storing all the products and variations on the same table.

How this may apply to Jiro is you'd have a Product table which would include fields like product_type (e.g. product, variation), product_parent or product_id (a self-referencing relationship which indicates which product is the parent of a variation).

So, a product with the id of 123 that has 5 variations will have 5 entries in the products table, each with a product_id of 123 and a product_type of “variation”.

You'd then have another table called product_meta which stores the actual data behind each product (e.g. price, sale_price, stock etc). So this would basically have 4 fields: id (primary), product_id, meta_key, meta_value. This means you can not only have limitless potential fields for your products but you can allow for some sort of fallback from a variation to the parent product for some fields. I.e. if you don't set a price for a variation you can fallback to the parent product's price.

As far as the variation attributes/options are handled, they would be stored as serialized data in the product_meta table. So each variation would have an array of its options stored behind it, e.g. a variation might have a product meta entry with key "product_options" and value ['size': 'S', 'color': 'blue'] and another can have ['size': 'S', 'color': 'red']. Both would have the same parent product.

The schema may already have been decided but I thought it'd be worth putting this out there to see if it helps with design at all.

I would go for Phalcon, sorry, I know it's a Laravel forums, but be objective. Laravel is very slow in comparison to even Symfony, I've tested it myself.

eCommerce platforms like Sylius have their own core base, based on another framework, and any company developing their shop on it will add their own core base adding more overhead.

Don't forget shops suppose to be fast and withstand high loads, not only be scalable and loved by developers.

Obviously compared to Phalcon, which is pre-compiled, Laravel will be slower but it needn't be slow and can be run on scalable, high traffic sites no problem. JustPark is one example that has enormous traffic and was built on Laravel.

Out-of-the-box Laravel may be slow but, as with any web project, you can make it fast by using appropriate caching, especially for DB queries (memcached, redis), choosing the right session drivers, DBs, running it on decent servers with the latest PHP versions. HHVM and PHP7 offer enormous performance improvements and Laravel runs fine on both.

There is absolutely no reason to rule out Laravel due to speed; it's how you make and deploy your app that determines how well it performs. The limit to scalability is not down to framework choice, it's down to network infrastructure.

In addition, many benchmarks you see around the web are now outdated. L5 now includes a route caching feature that greatly improves performance.

ShawnMcCool said:

I would like Sylius but a framework agnostic version with Symfony and Laravel drivers.

Aimeos already offers exactly that: A PHP e-commerce library that can be integrated into any Framework and Aimeos supports Laravel, Symfony2, Zend and Flow up to now and contains all necessary features for a complete shop system.

I am also too curious to launch a ecommerce platform using laravel. However i doesn't want to start the work from the scratch. I read about the clone scripts using which we can easily create ecommerce website by just installing a script. You can also get to know more about this script in this blog https://blogs.agriya.com/2015/09/07/laravel-best-php-framework-creating-ecommerce-website/