 All right, so we'll go ahead and get started. You have come to the future of commerce on Drupal 8 and Beyond presentation. And I am Ryan Sarama with Commerce Guys. I am a longtime community member starting with UberCart on Drupal 5 and even did some stuff before that. And my first blog was on Drupal 4.7, and I got my first ever freelance contract by putting up a two-page blog post about, you know, QuickBooks integration, so it's always been about e-commerce and it's been fun and I've, you know, grown and learned a lot through being a part of the Drupal community. For commerce, 2.x on Drupal 8, we've actually brought in a co-maintainer, so Boyan Savanovich, who could not be here, so I'm presenting on his behalf, really, is the co-maintainer for Commerce 2 with special focus on the PHP libraries that we are developing outside of our Drupal modules, and then I'm more focused on the actual Drupal side with entity development and all that kind of stuff. But we are both employees at Commerce Guys. Boyan works remotely from Serbia. I work remotely from South Carolina, probably very similar states. And we are the creators of, of course, both Platform.sh and Drupal Commerce, Drupal Commerce itself being born in, you know, 2010, late 2010, early 2011, finally launching at DrupalCon London. So it's, you know, been around for a while, and really our vision since the beginning has been for Drupal Commerce to be like the number one open source e-commerce platform in the world. It's very visionary because it's supposed to be, but we've always said that we power truly flexible e-commerce because, you know, because we're built on Drupal, anything can be altered. Nothing has to be hard-coded. A lot of what we do depends on rules and views and other things that can be overwritten, disabled, changed, et cetera. And I'll just start now by, by providing that sort of an introduction. I'm not sure, you know, by, by show of hands, has anybody here never used Drupal Commerce on a project? That's new to a few people, yeah, okay. So the big idea behind Drupal Commerce is that it was built from scratch on Drupal 7 to take full advantage of Drupal's Entity API. So the fact that in Drupal 7 anything can be fieldable, anything can have multiple types and then you can display them in a variety of different ways, including using views for any type of entity. You know, we built everything around this system, so all of our administrative lists like product lists, orders, line items, all that stuff are built using views so anything can be customized from the user interface and of course exported to code or altered by whatever module you use to maintain your project. But both the front end and the back end and even forms. So in Drupal Commerce on D7, we contributed a patch to views to allow views to render a form so you can actually customize the shopping cart form in the same way you would customize the shopping cart block, among other things that you use views for. We also use rules for all of our business logic. So determining pricing, determining schedules, product availability, and you know, payment method applicability for any different order, you know, maybe based on country, you have different payment options or shipping options. All of that sort of business logic is handled via the rules module, although you can use equivalent Drupal hooks to do the same things. And of course, as I mentioned before, the big idea here is that we wanted to hard code no business logic so that you didn't have to undo something that's in code in order to make Drupal Commerce work for your particular client or use case. If anybody used UberCart before on D6 or 5, you might be familiar with the fact that, you know, everything had to be a product and a node was a product and so you had to have a node, you know, whether there was actually any need to display product data or not. So such as a, like an event ticket, like buying your ticket for DrupalCon. You know, it doesn't necessarily need a standalone product page. It's just a skew that then gets added to the cart via some other form. So we sort of tried to roll back a lot of the hard coded things like that in both the data model and the business logic in Drupal Commerce. And then we also rely on essential contributed modules that really round out the feature set. So we really tried to be minimalistic in what we included in the core feature set of commerce. For example, there is no shipping module in the core of commerce. It's a standalone project. There is no PayPal or authorize.net module or any other payment module. Because the core framework is really just about defining the basic systems and interfaces you need to do business online. And then all of the modules that, you know, that we have for Drupal Commerce, there are several hundred offer payment method integration, shipping integration, different ways to promote and discount your products. Integrate with third party services like MailChimp or other mailing services or marketing services. And some of these, you know, we consider as essential contrives. These are the ones that we maintain. We put them into commerce kickstart, which is a distribution. And so, you know, we're making sure that they're being maintained, kept up to date, certainly addressing any security issues. And, you know, where possible, working with other community members to keep these up to date and keep them all moving forward. And, you know, at the end of the day, we believe we're doing something right, because, you know, we're up to about 55,000 or so sites reporting into Drupal.org as using Drupal Commerce. Of course, not all of those are live sites because Drupal.org statistics include, you know, development sites as well. Or maybe sites that use parts of the module but don't actually represent live stores. But in any event, there's thousands of sites that are using Drupal Commerce to power their online business. And I'm sure that there are many represented in this room here. Including myself, I use it to sell cheese on the internet. So there's, you know, plenty of use cases out there. But as I said, commerce kickstart is actually a distribution of Drupal that was built to round out the user experience for Drupal Commerce. Because out of the box, it's really bare bones. It's just a teaser list and that's it. There's nothing, there's really nothing to look at when you install commerce itself. So we said, first of all, we wanted to optimize the stored administrator user experience. Because again, bare bones commerce out of the box requires you to do things like manage your product skews in one place and then your product displays in another and reference, you know, link them together via a reference field. Within kickstart, you know, we have the inline entity form module that, you know, can actually let you edit both entities on one form. A few other things, like using a new module we wrote called the views mega row module, which lets you look at a view. This one is orders and you can actually expand, you know, any row to include just a summary of the order and update the order status. Things, you know, just things like that that make the admin UX just a little better. In all of these modules that we, you know, we use the inline entity form, entity referencing, of course, views bulk operations for commerce. The views mega row, those are all standalone projects that you can use outside of commerce. And so if you have an existing Drupal commerce site and want to optimize the administrator user experience, you could look at commerce kickstart, find the modules, put them into your project and, you know, not have to worry about using the full distribution. On the front end, we also created a fully responsive theme, including add to cart forms and checkout and everything. And then optimize, you know, product pages with a few best practices, big, pretty images, and a fully functioning faceted product search that was built using the search API, facet API, views. And then, of course, you know, it can connect to solar on the back end if you want to. And for this we did just some neat things like added support for price field facets so you could have like a, you know, a range of prices that you're searching for, that kind of thing. And it also really demonstrates how to create a search index for, you know, using search API that combines both product data and node data. If you're using a node to display product information, that's essential. So you can look into here to see how we constructed that index if you're curious. And then finally we also built into the back end what we called the marketplace, which is just an easy way to find all of those modules that I've mentioned that either integrate with, you know, third party services who have partnered with us to make sure that the integrations are robust and supported. And then we also linked to, you know, a variety of just community contributed modules that would also improve the store UX. So once again, you know, we like to see the graph going up. There are about 13,000 or so sites reporting usage of commerce kickstart. And that's, you know, probably more weighted toward demonstration sites and test sites than commerce itself. But there are, you know, a fair number of examples even in our showcase on DrupalCommerce.org where people successfully took the distribution, put a different theme on it, and then were able to launch a store very quickly. So, you know, we have positive indicators that what we're doing is useful, we're headed in the right direction, and this talk is all about the things that we believe we can do better on Drupal8. Are there any questions? I can pause here just about like DrupalCommerce itself or commerce kickstart the distribution. Or should I just jump right in? Okay, so I'm obviously happy to answer more afterwards. And of course, if you have any other, you know, questions, you can always go to DrupalCommerce.org and read the documentation that Josh has produced, or, you know, find questions and answers there, or even there's a pretty vibrant group of folks in the DrupalStackExchange if you go to Drupal.StackExchange.com that answers a lot of DrupalCommerce related questions, myself included. So, DrupalCommerce 2.x is of course going to be on Drupal8, and one of the first questions that comes up when we start talking about D8 is, well, when will DrupalCommerce be ready? And it's really impossible to say. It's obviously dependent on Drupal8 being ready. The good news is that we'll have fewer dependencies we have to wait for before we can consider DrupalCommerce, you know, ready for use. I'm not sure who was following along progress during the Drupal7 development cycle, but we actually were writing DrupalCommerce at the same time that views was unstable and rules was in alpha and the entity API was changing on a weekly basis, and so we were always having to rush to keep up with the changes. And that's not the case in Drupal8 because, of course, views is in core, and we are not going to have a hard dependency on rules anymore. It will obviously enhance, you know, your ability to customize the store, but we've just decided that we won't hold up the release of DrupalCommerce for a release of rules. And, of course, the entity API is much more robust in Drupal8 than it was in Drupal7. So a lot better tools means we'll have a DrupalCommerce release a lot sooner after the Drupal8 release, but I don't have, like, a date. I just tell that my salespeople not to sale any Drupal8 project until at least, you know, the second half of this year probably wouldn't be able to launch anything until, you know, early next year that depends on a lot of other contributed modules in the Drupal space. But to start, you know, DrupalCommerce 2.x development, we actually gathered a crew in our office in Paris to host a sprint that was really based around validating the architecture of the core commerce framework itself, but also our strategy of using standalone PHP libraries and using Composer to pull those into Drupal as dependencies for the modules themselves. And we actually had a variety of contributors from other e-commerce projects and then a few other Drupal guys and also the creator of Symphony himself, Fabien Potentier came by to give us his input. And the one bit of feedback that I remember of verbatim was that he said, I'm glad I'm not developing an e-commerce solution. This sounds really hard. But he was very helpful in just helping us understand, you know, how to create our libraries in such a way that not only are they useful to us, but they're also useful to Symphony and therefore other Symphony-based e-commerce projects such as Sonata. He's from the Sonata project and we had a few other Symphony-based projects represented as well. And they've even seen since this time uptake in collaboration from other PHP-based e-commerce developers, which has been a huge win for us. So once again, we are starting from scratch with a clean repository, much like we did on Drupal 7. And that's, you know, just because everything is different. The difference between Drupal 7 code and Drupal 8 code is as stark as, you know, as big as the difference between Drupal 7 code and like Drupal 4.6, like it's really, really different. And so we're starting from scratch to take the opportunity to re-architect around the new, you know, concepts and programming models and whatnot that you have in Drupal 8, just simply because we're using object-oriented programming now with namespaces and dependencies and Symphony components and a variety of other things that we wanted to make sure we were making the best use of them instead of just kind of carrying forward our old hooks and our old data structures. So we started by reviewing the entity model. So our entity diagram for commerce1.x looks like this. We have five entity types that we define in commerce. That's the order, the product, the line item, the payment transaction, and the customer profile. We define a few different field types like the product reference field, the customer profile reference field, and the price field. And that's it. That's all the core of commerce1.x defines out of the box. And we actually decided that, you know, one entities are easier and cheaper to define now thanks to the, you know, the patterns we can follow in Drupal 8. And so we decided to add a few more entity types to the mix. This is a little bit out of date, but the gist is, you know, we won't be including variance as a standalone entity type and we'll actually have one or two other payment-related entity types in core. But the big idea is that you'll have a store entity through which everything is, you know, managed. So products belong to a store and this would hold your global configuration for the site and store logos, email addresses, contact information and that sort of stuff. So my products would be related to that. Orders would also be related to stores. So then you can end up with a multi-store scenario where access control is governed by what store a product or an order belong to. We'll be using, you know, payment transactions but then separately payment allocations that sort of divvy up, you know, maybe one large transaction to the invoices that actually covers. We also have an entity type already in commerce2 that we're using to represent your card-on-file data. So the payment tokens that you would use to process recurring transactions or card-on-file payments and a few other things going on. But, you know, the other, you know, basic ones remain, product orders, customer profiles, payment transactions and line items. But we're going to change the way that some of those work together. And also, thanks to the fact that Drupal 8 now has the entity reference field in core which was developed for Drupal commerce on D7, we no longer have our custom reference fields to relate these together, just entity reference fields, no more customer profile reference field or line item reference field or anything like that. So the first big entity change that we brought is to really implement a hierarchical product model that does not depend on nodes for displaying products. So I'm not sure how familiar everyone is with products on Drupal 7 in commerce, but whenever you define a product entity, it doesn't have a front-end URL by default. You have to create that by creating a node and then associating that node to a SKU or a set of SKUs using a product reference or an entity reference field. And then we look at the products that you've referenced and we will sort of create the hierarchy on the fly as part of the add to cart forms logic. So if you have a product with attributes like sizes of a shirt, you would reference the individual SKUs and then the add to cart form knows that you should render this group of products on the add to cart form with a select list for choosing a size. So pretty simple, but what it ends up doing is it makes you have to manage a lot more data at the point of display. So it would be nice, for example, if I could just reference the parent product and have it include every product in the group. So that's one thing that we probably could implement on Commerce One. We just, you know, nobody's done it yet. But it also would be nice if we just didn't need nodes at all. So the idea here is that in Drupal 7 we continued to use nodes as product displays because nodes were still very important. You needed nodes if you wanted to have comments. A lot of other modules were still built around a node-based, you know, node-based content model. We just didn't feel comfortable at the time, and this was 2010, just abandoning nodes entirely. But we knew that products still needed to be a standalone entity type, and we still needed to define individual variations of our product as unique SKUs for accounting and fulfillment purposes. But now we believe that, you know, the entity API has advanced such that we don't need nodes anymore as a sort of intermediate layer. And we will just instead support products having their own, you know, URL in the front and, you know, product slash one, product slash two. That, of course, similar to Path Auto you would be able to create, you know, URL tokens for those. But what we want is to be able to define a hierarchy for my product type and choose at which point in the hierarchy should a unique URL be created. So I might have a URL that lets me choose the colder of my shirt and the size or for the same product, you know, product group I could do, I could support both the combined interface and standalone interfaces if I wanted to. We haven't actually programmed that all yet, but we have designed it to create a new interface mocked up and this is where we're headed. And the big win here is for the bulk creation and management of groups of SKUs because right now you have to manually essentially enter in all of the different variations and then reference them in what we would prefer to do is to define the hierarchy and create a new group and have it automatically create all of the different SKUs beneath it and, you know, manage that. Oh, there goes my... Sorry. And it's probably going to take a second to come back now. Naturally. Are there any questions about products while this is coming back up? Yeah? I'll repeat the questions. Yeah, so the question was how might we make Drupal 8, you know, commerce 2.x on Drupal 8 more friendly out of the box since we aren't dependent on this node-based configuration and, you know, immediately, just by the fact that every product will have a URL by default, you know, as far as a merchant is concerned, they're adding a product page and once they do that, like, it has a URL and they don't have to, you know, they don't have to manage references or any other, you know, content type configuration or anything. I'm not sure that we'll have, like, a catalog out of the box. Although since views is in core, I guess we could have just, like, a disabled view that could be enabled or something like that. But I'm not sure how rich the out of the box experience would be. So, certainly open to feedback on anything that you think might, you know, enrich the product, you know, catalog management experience and be, you know, broadly applicable to a majority of users. But, you know, it's kind of hard to know because, you know, a lot of different vertical markets have very different needs out of their product model. If anything, though, like, it would make the most sense to optimize for, you know, a physical-based product catalog and, you know, I wouldn't have a problem even having multiple different types of catalog views. But maybe that would be best as even a standalone module just because you could, you know, change it faster. That's really it so far. Any other questions that would be related to products or, yeah, coming in? Yeah, so the question is about data mining and business intelligence, you know, plugins. To be honest, I mean, we certainly aren't thinking there yet that we're just building out the core framework. You know, the Drupal commerce on Drupal 7 has the giraffe module now available for it which provides, you know, good intelligence about usage of the website so it has your, you know, conversion funnels, your conversion rate optimization and a nice dashboard. It shows what products convert more and all that kind of stuff. So I would look into that. It's giraffe with a J, so J-I-R-A-F-E. And that might be a good place to start. So another thing that we want to do beyond just making it easier to build out your product catalog and manage your product database is to actually have more opinions about checkout user experience. In commerce 1.x we basically just we didn't do much to support checkout best practices beyond allowing you to basically choose between anonymous versus authenticated only checkouts. So there's no reason for us not to have that. Or at least, you know, yeah, it would be a block so it could be moved around, disabled, whatever. But to bring more, you know, conversion oriented tools like this to the core framework would be useful. But also, we want to be able to actually support multivariate testing or split A, B testing on the checkout form. Or even just multiple checkout paths based on the product that's being purchased. So just to explain a little further in Drupal Commerce right now you have one checkout form configuration and you can alter it using an alter hook but it's really kind of flaky. It's not the best system for creating a different checkout experience whether it, you know, whether because you want to do A, B testing or because you have a different checkout workflow for your B2B customers versus B2C you know, whatever it is we just want to support that and the way that we'll do that is ideally by using Drupal's form modes so I'm not sure how familiar we are with Drupal 8 but in Drupal 7 you have the concept of view modes where any node for example could be displayed as a teaser or as a full page or as a search result or an RSS, you know, entry. Drupal 8 extends this concept of different ways to display the rendered content to supporting different ways to display the edit form and since the checkout form is really just an order edit form that may or may not have multiple steps we believe that we can use form modes to define both the back end order editing interface and the front end checkout workflows and then basically just have the checkout module give you some sort of mechanism to choose or indicate which particular form mode should be used for this current user so I do believe it's going to be possible but again I haven't researched it yet and tried to implement it so once you've worked with form modes I'd love to hear about your experience but the idea would then be to not have to maintain anymore our drag and drop checkout form builder but just build that all into the form modes interface and you know have one less thing that's unique to commerce and just be more natively using Drupal concepts and we're also going to be very more controlled from status to status so right now in commerce and uberkart before it we basically just implemented order status updates as a select list so any administrator can go in and change a value in a select list and basically say this order is now cancelled this order is now complete but there is no check and balance that ensures that this order was paid for or that a refund was issued and so really when we're dealing with an order it has a very complex workflow that's more defined and controlled with state transitions that actually control moving from one status to another and don't support invalid transitions so you wouldn't be able to move from a completed order to a cancelled order without first going through our refund step that sort of thing and the model or the paradigm that I'm following here is the has anybody used JIRA for project management? yeah so in JIRA every project can have a number of types of issues and the issue has an assigned workflow and in this workflow you define the steps you define the state transitions you give them a name so as a developer I come in and I say start progress and it moves it to the in progress status and then I can either stop progress or complete it or mark it as done but these buttons actually give me sort of a user interface text to put on the button to initiate the state transition there might be in this transition some intermediate form we have to put in additional information or explain why you're reopening a closed issue that kind of stuff and so this sort of functionality is what we are now implementing for orders so that no longer can you just randomly move an order from one state to another nor would you be able to sort of daisy chain together via rules a bunch of different order status updates there's a lot of trouble on commerce 1.x just because it's really difficult through rules to manage the dependencies of one state automatically moving to another to another and so this is actually already being worked on in a workflow module I don't think it's on Drupal.org yet I think it might just be in Pedro Canberra's GitHub but we'll be continuing to flesh this out ideally as a standalone entity workflow module one of which does already exist on Drupal 7 so we're pursuing either reusing that or making this part of the roadmap for that project but then we will implement it specifically for orders and I have a hunch that we'll also implement it for line items because oftentimes the order status is derived from the line item statuses so an order is shipped whenever all of the line items have been actually shipped so in the case of like a back ordered product you wouldn't mark the order as complete until all of the products have come into the warehouse and shipped out and so on so I'm really excited about this because there are just a lot of things that aren't easy with the way order statuses work in commerce one and I have a blog post about it that I haven't published for like six months so shame on me I'll make sure I do that after this conference finally we are not finally we do want to support discounting core this is the current commerce discount user interface which I'm not a huge fan of but the concept is good which is that just throwing a merchant at the rules user interface is a losing strategy for happy customers because none of our merchants are equipped to navigate the rules UI and not break something and manage their discounts that way and so the discounts module in commerce 1.x provides a simpler user interface with the ability to still use some conditions and it also integrates with the coupon module and a few other things but we're actually pursuing better opportunities to support discounts in core and finally because of the addition of the store entity to the core of commerce 2.x we will support both multi store and multi vendor scenarios out of the box so right now there's the commerce marketplace module that facilitates some of this but for an example is in commerce 1 you cannot say like easily use different payment credentials if you had a multi vendor website where I was supplying my paypal credentials and wanted customers buying from me to submit payment to my paypal account that's actually a little bit difficult in commerce 1 and does require the commerce marketplace module to provide both a user interface where merchants can enter their credentials but also kind of hack around some limitations in the payment method to make that work. Another big thing though is and we're not sure how far we're going to go down this rabbit hole is that a multi store or a multi seller website needs to decide what it should do when customers try to order products from multiple vendors you know should it be two separate shopping carts should it just all be one who actually gets paid, who's responsible for fulfillment we haven't answered all of those questions to decide just how much will support in core commerce which will depend on contributed modules for but again if that's a discussion that's relevant to you Boyan would be more than happy to discuss that I'm happy to discuss that at the very least we'll have the data types in the core of commerce that we need to support any scenario but when it comes to systems and interfaces we're not quite decided so as far as actual progress goes I'm not sure if I should try this live or not looking at Drupal 8 right now I do have a commerce menu item where I can come and access my store because the resolution soloed season the sidebar so it's not going to look great up here but you know you can create orders you can create products that have no fields and no information on them that's useful but the entities are there the pattern has been set so that we can continue to define all of our entity types and then you can also do some configuration like manage your currencies and import currency settings import you know tax settings number formats and the like and then also set your store information which is where you manage your store entities and their fields so this is the current status of things there's no front end work yet as far as add to cart form or checkout form goes and that's kind of on me so I'll be looking to do that over the next few months and hopefully have a great demo for DrupalCon LA are there any feature related questions as it pertains to the development of commerce on Drupal 8 right now okay let's talk about what may be actually the most exciting part of Drupal commerce on Drupal 8 we are actually whenever we got wind that Drupal 8 was adopting symphony and that there would be composer as a core concept now for managing a Drupal site that got our gears going where we realized well we have the opportunity now to move functionality from our modules out into standalone libraries where we can still depend on them in our modules but we can also invite other projects to collaborate around them and influence the development of other projects and basically collaborate around the essential things for doing business online that aren't specific to Drupal and certainly don't need to be specific to our solution so we started out by researching the deficiencies in our own software we looked into pre-existing price management and currency management libraries pre-existing e-commerce bundles for symphony even some non-symphony and even non-php based applications to see who is solving things like locale specific currency formatting and locale management address formatting and validation price management and currency management all that stuff and Boyan Zavanovich I mentioned previously is our commerce 2.x my co-maintenor in Drupal commerce now in general and he's also an e-commerce machine and he just hammered out this research over the course of a couple of weeks and basically just identified some age old tax management issues as deficiencies that we could address in generic solutions a price management API that doesn't actually really have an API right now if you're manipulating prices in Drupal commerce you have to really interface or interact with the data array of a price field to set your price components and we just never really finished the API around that also every new point release of Drupal commerce brings with it yet another currency that we didn't support previously in terms of formatting it appropriately for that locale but even with every currency covered we still wouldn't accommodate the fact that each country may render the same currency differently so the euro looks differently from country to country around Europe much like the peso is going to be rendered differently from a formatting standpoint from country to country and the dollar between the US and Canada and Australia it's just we don't have support for that right now in our currency API we also have really abused the address field implementation for managing addresses and Boyan has actually improved it based on our library work but it just was difficult again to customize address formats to know in advance which countries require you to select a state which ones depend on a postal code whereas different fields optional all that kind of stuff and also we identified as a weakness not something to do with our code but really just to do with our community which was we had a real inability to collaborate with other PHP app developers that are doing e-commerce because all of our logic and all of our knowledge that we've amassed over the last six or seven years was locked away in our Drupal modules so not useful to any other project and we wanted to fix those things so we proposed standalone solutions for internationalization which is managing locales and then also managing number formatting for each locale and then additionally extending that to currency formatting that's locale specific we also proposed to solve once and for all address form generation validation and locale specific formatting for every country in the world lofty goal we also proposed to support territory grouping for the sake of simplifying taxing shipping payment selection all that stuff and then also as far as we can encapsulate like tax rate management and price calculation and manipulation in standalone libraries I'm not sure how relevant European style VAT management is to Latin American stores but I'm definitely happy to talk about that afterwards so we we knew that we didn't want to just create based on Boyan's research again presenting on behalf of him we did know that we weren't going to just produce a set of interfaces that other applications had to develop and provide all of the logic and data for we also wanted to bundle in unprecedented data like all of the address formatting rules for every country in the world that's unprecedented for any e-commerce library anywhere as far as we know we also decided we wanted minimal dependencies so we weren't going to create these as symphony bundles and make them dependent on other things certainly weren't going to make them dependent on Drupal or its APIs we certainly are striving for simple APIs with clear documentation and examples for everything and full test coverage so that's a very high goal actually this is interesting in doing the address library our test coverage has turned up actual bugs in the data source that we were using and we have been improving our data source that we're now consuming for all of our address rules it's been fun to see how that's worked out finally we wanted these to be reusable by any PHP based e-commerce application so we started with CommerceGuysINTL and this was a PHP 5.4 internationalization library powered by data from CLDR which manages number formatting rules for every country and locale in the world and so we built a library and we set it up to manage countries currencies, languages, etc and then also have number formatting rules and currency formatting rules for everywhere and it was so good that symphony is actually adopting our internationalization library into the core of symphony itself in future versions and even now in the current long term support version they've been accepting patches from boyan which is a huge win so we're not just feeding off of symphony we're also feeding back into symphony so really creating a very healthy partnership so the CLDR project just sort of lets us know exactly how to render the dollar, the euro the peso, any currency that did kind of different formatting for different regions the proper way for every country in the world and that's already done and we've already used it to improve the currency definitions in commerce 1.x then we have the pricing library which provides a price object where we are managing the storage the formatting, display, etc of a price which in commerce is defined as a numeric amount with a currency code and then right now we just support rendering that in one format for each currency here it will be locale specific currency formatting with additional class methods for managing like manipulating the price and tracking changes to a price object over time so exactly what in commerce 1.x we use price components for there's a bit of a holy grail goal here which is to also be able to properly apply discounts relative to taxes and that sort of thing but that may be stretching a bit far for a generic library and then the one that I thought was most exciting was the addressing library we found a data set from the android SDK that Google let us reformat and re-license I can't remember the license, BSD or something they let us reformat it from their giant flat file into JSON files put it out under an MIT license and now use that to do form generation and validation through symphonies form generators and validators and then also do again locale specific ordering of the elements on the address form and then rendering when you actually print it out basically on the screen versus print it out for usage on a label so all of that stuff the data set had that knowledge and we've now converted that into JSON files that we're consuming by this library to build all of our address forms for commerce and now we're getting other e-commerce projects to use the same library and build into it again just the power of the community is going to drive its accuracy and its feature set over time and so this being able to get that knowledge when Burnham's written about it on the Drupal commerce blog and again this solves so many problems for so many people that we really can't wait to start using it now and you've already begun to use this data set to improve all of our address formatting rules for address field on Drupal commerce 1.x and so I'm not sure this is just one example where the address form that's generated one is dependent on the country because you have different fields that are going to be required for each country some countries have provinces and cities you have to select some don't in some cases the postal code might be all that you need to submit an address form that kind of thing but how it's rendered might actually differ based on the language you're using to build the form so in this case this is a Chinese address rendered in English and so they have the address go from followed by my company, my street address district city province and postal code and that's maybe a more traditional like western sort of ordering of the address fields but if you're doing the same form in Chinese it would actually reverse you know the postal code province city and district so that you're selecting them in reverse order for Japanese addresses you also have to select a title so not just my first and last name but am I Mr, Mrs, Doctor, etc so all of these different requirements from each country for each locale are already working in the addressing library and being used by live projects right now so super super exciting and huge kudos to Boyan for driving that forward and also to Damien our CTO for finding the data set and convincing Google to let us re-license that and redistribute it I mentioned we had the zone library and this is just handling grouping territories together so for example you might have one payment method for any country in the EU but a different payment method for all international orders or the same might apply to Latin American countries where you're using the pay you as a payment method for only specific countries in South America but then internationally using some other payment method like PayPal or something but it also lets us do fun things like well shoot like prepare international tax zones so I know I've heard that you know Colombia can be difficult to implement and report on after the fact well it's even worse elsewhere in the US you know we're a total mess but even in the EU where VAT is supposed to be simpler to account for you literally have a German VAT that applies to any German address but also five postal codes in Austria which means you have to know that when you're calculating tax for the order and you have to know the inverse so if you're calculating Austrian VAT it applies to Austria except those five postal codes and the good thing is that all of these types of groupings are pre-defined and they don't change that often so the PHP library you know the zone library can amount to the tax library just sort of codifies this knowledge and then we'll again crowdsource it and get these other people that are developing other solutions that are specific to different markets to contribute to these definitions and help us keep them up to date and help us make better use of them in our own software and you know once again we feel like we're doing something right whenever we put out the addressing library for a bright shining moment we were the top trending developer on github and that is of course because all of these libraries are hosted on github and you can go find them, fork them, contribute to them we'd be more than happy to have you use them whether it's in a Drupal project or not we're already seeing collaboration around the tax library from other systems like Foxycart and shoot there was a new one in Kong recently that started to adopt the library so we're getting good participation and expect to see that continue to grow before I move on are there any questions about the libraries or where they stand or what we're up to with those so the question is how then, since these are all hosted on github is standalone libraries do we get them into Drupal and right now the installation process requires the composer manager module which is a standalone module for Drupal 8 that basically reads all of your contributed modules looking for a composer.json file and then updates the composer.json in your Drupal 8 vendor directory to in your Drupal 8 directory to include all of the necessary dependencies so it does just a bit of dependency negotiation make sure there aren't any duplicates but then ultimately when you run your composer update it's putting all of those dependencies in the one core or the one vendor brand the one vendor directory that Drupal 8 is using to fetch all of the other libraries and components that it's depending on so it's a bit of a manual process right now ideally that will become more automatic because it's a bit of a stretch to require everyone running this to also go and install a composer and do the updates and all that kind of stuff but that's where things stand right now any other questions about libraries before I move on so boyonsavanovich is leading the development on these and giving Drupal a great name to open source communities and also finding good partners to collaborate around them so huge kudos to him finally at commerce guys we're not just concerned about improving the data model behind our modules themselves but also improving the tooling that we have to build and deliver commerce projects and we believe that commerce projects are somewhat unique in the Drupal realm in the sense that they are exposed to more rapid changes they oftentimes have more rigorous and more involved testing testing processes and you also have to very often respond to the midnight whims of your merchants that want to see a new type of discount or promotion or whatever deployed immediately the next day so that they can run a sale or something so we ask ourselves the questions a lot how do we actually manage and scale complex e-commerce applications especially when code bases stretch across Drupal.org, GitHub, public repositories private repositories, site specific code, how do we actually manage that so that we don't take down someone's store when they're ready to take a sale live additionally how can we continue to deliver new features without disrupting existing shopping sessions because the last thing you want is to take the site down for maintenance to roll out a new update when somebody is in the middle of putting in their credit card information additionally merchants are often non-technical or almost always non-technical but they still want to be able to do QA and seal a live preview of the code changes that we're making in an exact replica of their live environment and oftentimes that includes all of the data whether it's products, users, customer profiles, etc that's just kind of what they need and so these sorts of things they're not specific to e-commerce, any Drupal project is going to have similar requirements but we found it to be especially true for our commerce projects so answering those questions drives a lot of our philosophy and approach to platform.sh which is just our Drupal based platform as a service that basically manages your code base via a Drushmake file so you can pull in any project from d.o from GitHub, from private repositories using a project specific SSH key, you can apply patches and basically just manage your code base with a lot more transparency into what is actually compiled into the project so I can just look at my project.make file and see all of the contributed modules that Josh has added since the last time that we rolled out a new version of a customer website then once you do that you commit a change and push it up to platform, it actually rebuilds the entire environment but it doesn't go down it just sort of puts the pending HTTP request in a bit of a loop while it basically rebuilds the environment and then deploys it so your customers might see a bit of a lag but nobody is actually losing a session or the site is not apparently going down even while you are rolling out new features in real time so there are a few other things that platform brings to the table related to QA of course we have just a branching strategy where any branch you create in your repository has a live environment for someone to do QA on and you can branch any number of ways that you want to and we maintain the parent-child relationship between your branches so you can basically create any number of workflows for developing, testing and deploying new changes to the live site we have also optimized it both for Drupal and commerce projects and just for bare bone symphony projects basically deploying a different tool stack depending on what type of project you are identifying your application as so in your Git repository you have these YAML configuration files where you say I am Drupal 8 versus Drupal 7 and then Git Composer and Drush and a few other tools out of the box or say your symphony and then you just get Composer and no Drush, no anything else and the idea is that you are actually managing the services that you are using including PHP, MariaDB, solar, etc from these configuration files so you can actually deploy like a whole new feature set like a whole new service to your live site so from an e-commerce standpoint that might mean turning on a faceted search powered by solar but you would want to test that downstream enable the solar service, configure it, tweak it and then immediately roll out the infrastructure change to the live website at the same time as you roll out the code and configuration change and so that is what Platform.sh enables you to do if anybody is interested in giving it a whirl I am happy to hand out free voucher codes or whatever but that is all that we are up to to support Drupal commerce and e-commerce in general on Drupal 8 it involves both the framework itself and the Drupal modules it involves standalone libraries and it involves improving the tools and processes that we use to actually manage these projects together if there are any questions I am happy to field them now otherwise we can go find more coffee do we have any data about market penetration? No, not particularly I only have a few examples of stores that I know that have launched I know that the LUSH website just launched in Brazil and that was started in London and then rolled out through a local partner in Brazil that is probably the largest one that I know about and then just a handful of other smaller projects that we see come in I am happy to hang around and take questions after the session is over if you are camera shy or whatever but thank you very much for your attention and hope you have a good rest of your day