Last week Acquia announced a partnership with Magento. I wanted to use this opportunity to explain why I am excited about this. I also want to take a step back and share what I see is a big opportunity for both Drupal, Acquia and commerce platforms.

State of the commerce market

First, it is important to understand what is one of the most important market trends in online commerce: consumers are demanding better experiences when they shop online. In particular, commerce teams are looking to leverage vastly greater levels of content throughout the customer's shopping journey - editorials, lookbooks, tutorials, product demonstration videos, mood videos, testimonials, etc.

Content and commerce

At the same time, commerce platforms have not added many tools for rich content management. Instead they have been investing in capabilities needed to compete in the commerce market; order management systems (OMS), omnichannel shopping (point of sale, mobile, desktop, kiosk, etc), improved product information management (PIM) and other vital commerce capabilities. The limited investment in content management capabilities has left merchants looking for better tools to take control of the customer experience, something that Drupal addresses extremely well.

To overcome the limitations that today's commerce platforms have with building content-rich shopping experiences, organizations want to integrate their commerce platform with a content management system (CMS). Depending on the situation, the combined solution is architected for either system to be "the glass", i.e. the driver of the shopping experience.

Content and commerce is a nice example of a content-rich shopping experience built with Drupal and Drupal Commerce.

Drupal's unique advantage for commerce

Drupal is unique in its ability to easily integrate into ambitious commerce architectures in precisely the manner the brand prefers. We are seeing this first hand at Acquia. We have helped many customers implement a "Content for Commerce" strategy where Acquia products and Drupal were integrated with an existing commerce platform. Those integrations spanned commerce platforms including IBM WebSphere Commerce, Demandware, Oracle/ATG, SAP/hybris, Magento and even custom transaction platforms. Check out Quicken (Magento), Puma (Demandware), Motorola (Broadleaf Commerce), Tesla (custom to order a car, and Shopify to order accessories) as great examples of Drupal working with commerce platforms.

We've seen a variety of approaches to "Content for Commerce" but one thing that is clear is that a best-of-breed approach is preferred. The more complex demands may end up with IBM WebSphere Commerce or SAP/hybris. Less demanding requirements may be solved with Commerce Tools, Elastic Path or Drupal Commerce, while Magento historically has fit in between.

Additionally, having to rip and replace an existing commerce platform is not something most organizations aspire to do. This is true for smaller organizations who can't afford to replace their commerce platform, but also for large organizations who can't afford the business risk to forklift a complex commerce backend. Remember that commerce platforms have complex integrations with ERP systems, point-of-sales systems, CRM systems, warehousing systems, payment systems, marketplaces, product information systems, etc. It's often easier to add a content management system than to replace everything they have in place.

This year's "State of Retailing Online" series asked retailers and brands to prioritize their initiatives for the year. Just 16% of respondents prioritized a commerce re-platform project while 41-59% prioritized investments to evolve the customer experience including content development, responsive design and personalization. In other words, organizations are 3 times more likely to invest in improving the shopping experience than in switching commerce platforms.

The market trends, customer use cases and survey data make me believe that (1) there are hundreds of thousands of existing commerce sites that would prefer to have a better shopping experience and (2) that many of those organizations prefer to keep their commerce backend untouched while swapping out the shopping experience.

Acquia's near-term commerce strategy

There is a really strong case to be made for a best-of-breed approach where you choose and integrate the best software from different vendors. Countless point solutions exist that are optimized for narrow use cases (e.g. mobile commerce, marketplaces and industry specific solutions) as well as solutions optimized for different technology stacks (e.g. Reaction Commerce is JavaScript-based, Magento is PHP-based, Drupal Commerce is Drupal-based).

A big part of Acquia's commerce strategy is to focus on integrating Drupal with multiple commerce platforms, and to offer personalization through Lift. The partnership with Magento is an important part of this strategy, and one that will drive adoption of both Drupal and Magento.

There are over 250,000 commerce sites built with Magento and many of these organizations will want a better shopping experience. Furthermore, given the consolidation seen in the commerce platform space, there are few, proven enterprise solutions left on the market. This has increased the market opportunity for Magento and Drupal. Drupal and Magento are a natural fit; we share the same technology stack (PHP, MySQL) and we are both open source (albeit using different licenses). Last but not least, the market is pushing us to partner; we've seen strong demand for Drupal-Magento integration.

We're keen to partner with other commerce platforms as well. In fact, Acquia has existing partnerships with SAP/hybris, Demandware, Elastic Path and Commerce Tools.


Global brands are seeing increased opportunity to sell direct to consumers and want to build content-rich shopping journeys, and merchants are looking for better tools to take control of the customer experience.

Most organizations prefer best of breed solutions. There are hundreds of thousands of existing commerce sites that would like to have more differentiation enabled by a stronger shopping experience, yet leave their commerce capabilities relatively untouched.

Drupal is a great fit. It's power and flexibility allow it to be molded to virtually any systems architecture, while vastly improving the content experience of both authors and customers along the shopping journey. I believe commerce is evolving to be the next massive use case for Drupal and I'm excited to partner with different commerce platforms.

Special thanks to Tom Erickson and Kelly O'Neill for their contributions to this blog post.


Richard Jones (not verified):

Thanks for taking the time to post this Dries. The Magento announcement last week caused a few waves in the Drupal community and I think it's very important for you to put this into context.

Having been heavily involved in some of the Drupal Commerce examples you mention in this post I have a strong belief that Drupal Commerce with Drupal as a single destination content and commerce platform is a very powerful and widely underrated solution. Since iKOS joined Inviqa I've had the benefit of working with some of the best Magento engineers around and this has allowed me to experience first hand where the short falls in content management are in these mainstream commerce platforms. I have also seen enough to know just how far we can push Drupal Commerce.

I like the phrasing you use - determining which platform is the "glass" when combining two systems. It's an important decision and often not an obvious one. Drupal 8 now being a capable decoupled system makes this a little easier as we can benefit from the full strengths of Drupal whilst maintaining the well respected back office capabilities of Magento.

I have huge respect for what Ryan, Bojan and the team have done with Commerce 2. It's so important for people to realise that the split of Commerceguys from did not and does not mean the death of Drupal Commerce - slow or otherwise. It's understandable that this massive effort in rewriting commerce and addressing many of the thing we learnt from D7 has taken a long time with a small core team. It's now time for those of us maintaining the supporting modules to step up and complete the picture.

As a long term partner of Acquia, Commerceguys and Magento we have interesting times ahead. Our approach is always to look at the business value our clients get from their systems rather that to dictate the solution that meets our interests. As you rightly point out replacing an commerce platform is not always possible so we need to be flexible in how we operate. I expect we will have the opportunity to bring in Drupal Commerce solutions in the future as well as continuing our efforts to bring Drupal and Magento closer together.

More case studies and success stories will benefit all of us against the strong competition in the market.

Ryan Szrama (not verified):

Thanks for sharing, Dries! My perspective on the partnership is colored by my long history of promoting native eCommerce solutions within the Drupal community (and with Commerce 2.x we're pushing hard to be more competitive with dedicated commerce applications out of the box), but I think your strategy w/ respect to winning over existing Magento users is clear / commendable and still points to the opportunity for Drupal Commerce.

I would've shared this assessment even before your partnership was announced for the key reason you mention in the post: re-platforming can be a tough pill to swallow, and even if you are committed to it (that 16% still represents thousands of merchants), the fewer integrations you have to rewrite between your eCommerce application and the various back-end services you depend on for order management, fulfillment, reporting, etc. the better. Every dollar you save on what is purely a cost (i.e. rewriting integrations, absent scalability or other performance issues) you can invest in future revenue by creating a more appealing, engaging experience on the front end.

That said, maintaining separate applications side-by-side will itself increase your technology costs (e.g. hosting, software updates, developer training, etc.), so I believe in a future where Drupal Commerce is sufficient for more use cases and easily scales to meet the demands of the largest merchants. It's great for digital commerce, for event sites, for selling user generated content, etc. (essentially, for verticals where the content *is* the product) - and it's a decent foundation for building robust D2C brand sites (e.g. or the more recent and highly custom business requirements. However, we know that we need to be more competitive both out of the box (esp. with regards to merchandising) and as an ecosystem (esp. with regards to order management / fulfillment), so we've prioritized addressing both of those during Commerce 2.x development.

While making Drupal Commerce an easy replacement for a third party eCommerce application is a long term goal, the short term opportunity is for merchants to use Drupal Commerce as a front-end for third party applications just as you are suggesting. Meaningful integrations will require structured representation of commerce data within Drupal, and there's no reason they shouldn't take advantage of the relevant Commerce modules and libraries, which were designed to be used in part and not just as a whole. For sites requiring currency / address localization, I'd almost say it's a requirement, and the libraries we built to handle this have been humming along in production environments for some time now. : )

Erlend Strømsvik (not verified):

You mention costs and software updates as something which argues against "separate applications side-by-side". I would argue those a absolutely minimal. To host a commerce solution you already need a huge stack of software/applications. One more does not add much to the total cost. That's even more true if one add the costs of development and not only the continued maintenance costs.

The cost of developer training depends solely on the longevity of the skills learned. If skills learned for one set of library/framework is viable for the next 5, 10 or 15 years then that has to factored into the equation. From personal experience I can say that the costs of having to relearn a framework is huge. There is a major undertaking both upfront and for several years when new bugs/problems surface. I've been following UberCart for a long time. We ventured into Drupal Commerce and felt a bit blindsided by that experience. Now Commerce2 is fronted as a "total rewrite" which really makes one wonder what has changed in the real world - tax rules (only tax rates has changed), discount calculations, price handling, currency handling, payment handling, order registrations (backend), order handling (backend), and more has not changed for the last 15-20 years. The presentation of information has changed quite a lot of course, and also so has user interaction, but the backend side of commerce has not changed.

What we experienced from UberCart to Commerce, and our fear is that going from Commerce to Commerce2 the backend again changes (a lot). Those of us who develop and maintain large commerce sites with a myriad of backend integrations (logistics, accounting, third party pricing-systems, giftcards, etc) are faced with a huge undertaking the day we have/want to upgrade a commerce site (UberCart -> Commerce -> Commerce2). The "upgrade" project is so large that we end up facing the same project costs as when we initially set up the commerce site. The result is that the customer might conclude that the best thing is to put out request for proposals on a new site. "A new site" is a pretty accurate description of every major Drupal upgrade and especially if the site is a commerce site with UberCart/Commerce/Commerce2.

We have just begun nibbling at D8. For us the most important thing when considering how to get out of the current Pressflow+UberCart and Drupal+Commerce stack will be how decoupled is the commerce backend from Drupal. If the next iteration of Drupal will again require huge amount of work on the commerce backend then that's not a good option at all. In my opinion an upgrade of the presentation of information (Drupal) should not touch the way prices are calculated or when tax is applied... Neither how orders are stored or handled. Just to give an example. Except for a few, most of our customers never touch an order in Drupal+Commerce. Orders and payments are handled and processed in their own ERP system. Some of those systems are 10+ years old. Some are even nearing 20 years. They still work and there is absolutely no need to upgrade or change system.

Drupal + Magento is something we have looked at earlier. Then we were in them midst of D7 + Commerce development. It will however be quite interesting to compare D8 + Commerce2 and D8 and a Magento stack next year. It will come down to how reusable is current Commerce code/modules with Commerce2 and what the planned life cycle of Commerce2 and (current version) of Magento be.

Ryan Szrama (not verified):

Good to hear from you, Erlend. : )

I think we're aligned in where we understand the true costs of eCommerce updates to be (the integrations), which is why I'm interested in seeing how the Commerce modules can be used to provide a front end to third party eCommerce applications that are already fully integrated but need a modernized shopping experience.

However, and I've seen this question re: the rewrite come up elsewhere, I'd like to point out that the reason Commerce 2.x is a rewrite is because Drupal 8 functionally demands it. We didn't rewrite our modules because "commerce" itself has changed since we wrote Commerce 1.x. We saw it as the only reasonable course of action given the whole host of changes in Drupal core, the PHP ecosystem, and of course our understanding of how to best model commerce data based on our experience over the last 5 years.

(The rewrite of Commerce 1.x was itself precipitated by the advent of the fieldable entity ecosystem, which was an effort we largely championed while paving the way for other modules to do the same. There were also trademark issues at play re: the Ubercart name back in the day.)

I agree that benchmarking for Commerce 2.x needs to include not just features and scalability but also the speed / cost of developing a new site. I don't think it's a wash from a cost perspective (there are still license fees and team make-up things to consider when you stand up two applications side by side - and Magento is widely regarded as very resource hungry and costly to customize - but we do need to make sure the costs to customize Drupal for eCommerce don't exceed the benefits.

Justin (not verified):

Great post Dries.

I'm flattered to see our innovative Drupal + Magento work with Quicken mentioned by you. Quicken is one of the earliest and largest Magento 2 stores launched in the world. We have built headless commerce with Drupal many times now, most recently with (headless Magento 2) and (headless Hybris).

We are also thrilled to be partnering with you and Acquia on building this Drupal Magento integration by porting the work we have already done for many enterprise clients and bringing it into the Acquia stack. Exciting times!

TAG has been integrating best-of-breed commerce solutions with Drupal for many years. We recently shared our analysis of where we think the content and commerce space is going:…

We recently contributed the connectors we developed for Drupal and Hybris back to the community ( These connectors -- like our Quicken work connecting Drupal and Magento -- are used today in production at enterprise-scale to power awesome shopping experiences with Drupal and headless Hybris. As our sponsorship of one of Drupal's six core maintainers (catch) shows, giving back to Drupal is very important to Third & Grove. And it's something we will continue to do as we continue our journey in the content and commerce space.


In my mind, the opportunity for Drupal Commerce is (1) to be an abstraction/integration layer for a variety of different commerce-related services, (2) to provide merchant-optimized tools for creating content-rich shopping experiences and (3) to help deliver those shopping experiences to different channels (i.e. be the "glass").

Organizations uses a variety of different commerce tools and often have different teams. Drupal Commerce could bring much of that together and provide a unified user interface and merchant-optimized workflow to make building content-rich shopping experiences better, faster, cheaper.

So in a way, Drupal Commerce would be a layer that sits above the Hybris-Drupal integration module. The Hybris-Drupal integration module (thanks Third & Grove) allows you to import products from Hybris into Drupal as standard Drupal entities and keep them synced, but the Drupal Commerce modules allow you to use those product entities to build shopping experiences. A Magento-Drupal module could be used to import products from Magento and for the merchants it would be invisible and irrelevant wether these products come from Hybris or Magento. It doesn't have to be limited to product information -- Drupal Commerce could also help unify analytics, promotions, shopping carts, etc.


Justin (not verified):

Thanks! Third & Grove also wrote modules for Drupal-Magento that bring in product information into Drupal, along with a variety of other features (hopefully releasing soon...).

In our recent projects with headless Hybris and headless Magento we haven't found a need for the Drupal Commerce components. We have found that Drupal itself is the most compelling unification layer. Our typical approach has been to keep in the commerce platform all the things commerce engines are good at (pricing, promotions, payments, etc) and to focus Drupal on what it's good at (content and engaging digital experiences). And herein lies the tension (we feel) with trying to use DC as the unification layer - DC is a commerce engine.

1. Abstraction layer - Because of Drupal 7's (and even more Drupal 8's) robust Entity (and other) APIs we have not found a need to leverage what the Drupal Commerce (DC) modules provide. Components like products and promotions become regular Drupal entities, and checkout flows tend to be custom so they are just Drupal page building. It's possible a Drupal Commerce component focused exclusively on checkout might be useful, at least as a starting point that can be customized.

2. Merchant optimized tools - Many of these tools are content driven so they are interacting with the website through the lens of content, not commerce platform components. Because the work of commerce is pushed to the commerce platform Drupal Commerce's components are less focused on the glass, and thus at less at play here. A good example is content personalization, which includes products because once they are in Drupal they are regular Drupal nodes. One potential area where DC may be able to play an important role is in price personalization.

3. Different channels - Say for example you have a headless Magento store that is powering commerce experiences on a website (Drupal) and in a mobile app (iOS). In our typical approach other channels would be going to Magento, not Drupal, in order to calculate discounts, get prices, and process payment. If the app needed some of the marketing content around products (that typically would be stored in Drupal) they would go right to Drupal for that (which has great support for this use case). In my opinion going through Drupal to talk to the commerce engine wouldn't be ideal from a performance, complexity, or level of implementation effort perspective.

Granted most of our clients are enterprise-scale, but in our projects we have had more success with a strict delineation between content information and commerce data. Our clients tend to organize their teams in this way as well - there tends to be a content team and a separate ecommerce/fulfillment team, so each only has to be trained and login into one system.

Anoop John (not verified):

It would be good to see some strong case studies of Drupal + Magento as marketing collaterals for pushing the integration into the market. It would also be good to see a bit of analysis on what would be the best fits for the different scenarios for ecommerce merchants. Maybe a decision tree for different business use cases for business decision makers in ecommerce space.


Robert Douglass from (formerly Commerce Guys) didn't like the integration strategy that I shared in this blog post. He strongly believes Drupal benefits from a native commerce solution like Drupal Commerce. In response, he wrote 8 blog posts to make the case for Drupal Commerce. I read through the blog posts and extracted the 4 main reasons why he believes the world should care more about Drupal Commerce. I'm including them below along with my thoughts.

Reason 1: the world need a true Open Source ecommerce solution. Not a solution that is proprietary (e.g. Hybris or Demandware) or has a dual-licensing model (e.g. Magento).

While Open Source idealism is important to many in the Drupal community, it is not a primary driver to convince customers, digital agencies, system integrators or industry analysts about Drupal Commerce. If we want more organizations to use Drupal Commerce and more organizations to invest in Drupal Commerce, we should focus on how Drupal Commerce is (or can be) a significantly better solution for their needs.

Reason 2: Drupal has already solved user management, authentication, content modeling, creation, editing, and rendering, rules engines, rich asset management, and multichannel publishing are all solved problems. This makes building a Drupal-native commerce solution much easier than building a commerce platform from scratch.

The effort required to build a commerce platform doesn't really concern customers or organizations who are building commerce websites with Drupal. It would have been much more useful to look at this from the customer's point of view; be it their merchants or the IT organization implementing and managing the commerce website.

A more convincing approach could have been to weigh the advantages of a monolithic approach (e.g. a consistent and unified user experience for merchants) against the advantages of a decoupled approach (e.g. the shopping experience and commerce backend usually have different upgrade and innovation cycles, different teams and different hosting requirements).

While a monolithic architecture like Drupal Commerce avoids duplication of functionality and can more easily leverage Drupal's strong content management capabilities, it might not be preferred. Most organizations will favor a decoupled commerce architecture over a unified merchant experience. The often complex demands of a commerce backend favor a decoupled architecture.

Now, one day this might be achieved with two Drupal instances; one Drupal instance using Drupal Commerce that acts as the commerce backend and a second Drupal instance that provides the shopping experience, connected through web services APIs. In such a setup, having two Drupal systems talk to one another might offer real practical advantages (e.g. same technology stack, easier integration, etc). This should be something to strive for.

Reason 3: Drupal will never become the premiere tool for making specialized, vertically targeted distributions without Drupal Commerce.

I don't understand this argument. First, it assumes that a commercial SaaS platform is the only way to make Drupal distributions successful. Second, there exist many solutions that can be used to add billing capabilities to a SaaS platform. The billing system most likely doesn't require deep integration with the Drupal distribution.

Reason 4: Drupal needs to have native commerce solution in other to be a good multi-site platform for organizations like J&J.

I don't understand why a monolithic approach is a requirement for Drupal to be a good multi-site platform. Universal Music, for example, has successfully standardized on a Drupal-Magento stack for hundreds of their artist websites. Almost all of Acquia's customers that manage hundreds of Drupal sites, use Drupal alongside of adjacent technologies, including commerce platforms, marketing automation platforms, enterprise search, customer relationship management software, and more. Why would commerce be different?


If we want more organizations to adopt Drupal Commerce or contribute meaningfully to Drupal Commerce's development, we have to provide them a very compelling reason to -- one that provides them an unfair advantage compared to alternative technologies. I wish Robert helped all of us in the Drupal community understand Drupal Commerce's unique advantage in the market; one that catches the attention of customers, digital agencies, system integrators and industry analysts. I hope we all keep working towards that or that we get better at articulating it.

Django Beatty (not verified):

Not sure I'd agree with the positioning of Drupal Commerce at the low end, particularly given that we used it to re-platform from a huge ATG install across Royal Mail Group (using the separate instances integrated via services approach as you mention in your reply to Robert).

The other key use case for Drupal Commerce was Eurostar, which required deep integration with content along with personalisation and segmentation which we couldn't find in any non-bespoke system. This was similar to an airline booking system (if more complex) and the checkout flow needed to adjust depending on various contexts (eg upsell tickets to a festival in your destination at the time you are traveling, part pay with various types of points, fewer steps when bookings are in high demand, A/B checkout flows).

Both of these examples are going back a very long way and doubtless the product landscape has improved (although I'd imagine finding Hybris devs is still a challenge and ATG still clunky and prohibitively expensive even for enterprise), but I'd hope that Drupal Commerce as a solution hasn't gone backwards with the advent of Drupal 8. I would position Commerce as for where you precisely don't want a separate 'web shop' (for which there are many solutions such as Magento etc.), but instead want a seamless context-driven experience between content and commerce. My expectation has always been that Drupal 8 and Commerce 2 would cement that and allow easier 'omni-channel' use via native services.

Josh Miller (not verified):

There’s a saying that I’ve taken to heart about Drupal projects: “Open source is a do-ocracy.” That means no one truly controls the nature of the beast more than the ones doing the work. Dries and Acquia have roles that sometimes invest, other times lead us as community. But our Commerce project is bigger than Dries, and bigger than Acquia.

The commerce project is bigger, in part, because of the amount and diversity of the “doers” shown here in this graph: which shows, in detail, the 57+ individuals and (by association) the companies that have contributed to the Drupal 8 version of Commerce over the last 2 years. And the quantity and quality of contributors continues to increase. Every day I hear of another company or another freelancer talking about porting a payment gateway or working through a complicated ecommerce problem like recurring payments or event registration.

The real question, though, isn’t “is open source a good idea” or even “is this open source project a powerful contender” it’s the question of “how does an open source box of legos compare to a black box that claims to be a miracle tool of innovation, scale, and integration?” Or perhaps, more acutely, “How does a native Drupal ecommerce tool compare to a non-native, non-GPL licensed counterpart?” I've seen this question at the heart of sales since I started working with Drupal in 2007. It always seems to boil down to two key issues:

1. Complex problems are already solved.

This issue might appear to be in the favor of Magento or SAP Hybris. After all, their stock management, fulfillment, return workflows, and multi-domain multi-currency store solutions are potentially more full featured than whatever one could build with existing Drupal tools. But, in reality, for any black box licensed ecommerce tool out there, there’s a huge deficit in solving flexible content management problems (token-based custom urls for catalogs and products and skus, translation, media, layout, fields, user-generated content, full featured customized catalogs that integrate content and products, etc). That’s why smart clients eventually realize they need Drupal. Everything I mentioned above has a solution in Drupal contrib. There are well over 1,000 different Drupal Commerce specific modules that enhance and create dozens of different ecommerce scenarios that would not be possible without huge efforts to solve some of the most obvious content management problems.

2. One size fits all versus tailored.

"One size fits all" type software is typically opinionated and considered “feature complete” even though they have never even heard of you, your business, or your unique requirements. That means the stock management of Magento is basically set in stone, unaware of the full fulfillment pipeline. Discounts and pricing solutions don't react to translations or might have trouble showing up in point of sale transactions. When you use Drupal-based ecommerce tools, the pricing, the translations, the content, the fulfillment, even the point of sale, all work together, natively. Tailored clothing, much like tailored websites, comes at a higher price initially, but tends to wear better, offer growth opportunities, and gets out of your way when needed.

My employer, Acro Media, has joined the estimated 15 different companies who have all invested huge amounts of time and effort (read: money) in the Drupal Commerce related issue queues and important contributed projects both for Drupal 7 and Drupal 8 not because “it looks good” (try convincing a client that it makes sense to reduce a feature set so that it could be a generic solution all stores could use) but because it makes sense.

Supporting a native Drupal-based ecommerce tool is the best step forward for anyone who wants to benefit from the thousands of stores (and hundreds of thousands of websites) who have shared their useful solutions to obvious challenges. If you insist on fully tailored systems that tie together complex stock management, payment, shipping and fulfilment business logic and seamlessly integrates with their large, online, translated, multi-currency content and catalog, then a Drupal native solution is your best bet.

Sure, some here have praised non-native Drupal ecommerce software. Just remember this: Drupal is big enough to include anyone who wants huge, expensive, fragile, and ultimately tone-deaf integrations with corporate one size fits all bloatware masquerading as something more than a one-trick-pony. For me, I'm going to get back to the issue queue and work on pushing flexible Commerce solutions forward.

Add new comment

The content of this field is kept private and will not be shown publicly.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.