I don't like being sandy but I love building sand castles. The potential is high but the stakes are low. You have unlimited raw material to build whatever you can imagine, and if you screw up you can just knock it over (to the delight of your children) and start again.
When your constant is impermanence, you adjust your expectations accordingly. If the sands shift or the tide rises, you shrug it off and start again or go back to bocce. However, if you were somehow bound by the fruit of your labor, you'd think twice about the when, where, and how of your building.
Lyle and I started developing Ubercart when Drupal 5 was still in beta, and we put up with the impermanence because we were just two dudes learning a lot and working from a clean slate.
Moving that forward to Drupal 6 took even longer because our codebase grew unwieldy, so I decided at Commerce Guys to trim the fat and start over. We didn't learn every lesson moving to Drupal 7, though, as it was still unstable when we began developing Drupal Commerce. With an unstable Views module. And an unstable Rules module. And an incomplete Entity API.
I don't think we would've done any differently, as the flip side of the instability is the opportunity to positively impact the development of the projects you depend on. For Drupal 8 we ended up contributing to core in other ways while tackling a full Drupal Commerce rewrite more slowly than we hoped. Even the code that we did develop against Drupal 8 is now outdated, as we had to juggle managing our existing ecosystem, writing new code, and rewriting that code to track changes in Drupal 8 itself.
However, we've recently been given the opportunity to host a variety of developers / documenters in Paris from June 30 - July 4 to re-evaluate ourCommerce 2.x roadmap with the direct help and guidance of key members of the Symfony project. Specifically, we'll be looking to both move our code "upstream" from our Drupal modules into generalized libraries and take advantage of existing Symfony projects where possible.
Our target is an even leaner codebase with connections to the broader world of PHP based eCommerce. If you have any insights in this direction, please comment or contact me directly and consider joining us in Paris to learn and contribute.
Development of Drupal Commerce 2.x began in Drupal core through contributions to core initiatives and new core modules. As a result, the next version of Drupal Commerce will feature a shrunken codebase thanks to updates to Drupal's core Entity API and the Entity Reference module, which alone deprecates a significant portion of the Product Reference, Line Item, and Customer modules.
The roadmap lists out the changes we'll be making to the architecture of the core Commerce modules in response to the changes already present in Drupal 8. It also features a variety of topically organized tasks we've lined up to mitigate the configuration and development challenges our users have faced using Drupal Commerce 1.x.
Our original goal was to have a beta release by the time Drupal 8 hit a full release. However, in an attempt to avoid repeating the turbulent experience of developing Drupal Commerce 1.x on an unstable Drupal 7 / Entity API / Views, we postponed active development of Commerce 2.x until Drupal core settled down.
Development of Commerce 2.x will truly begin in earnest once Drupal 8 has an alpha or beta release. In the meantime, our focus is on ensuring Drupal 8 itself is a success and on testing implementations of proposed features on the new Drupal 8 APIs as they develop.
If Drupal 8 truly has a full release around DrupalCon Prague, there's little chance Drupal Commerce 2.x will be beta ready. We'll be sure to update the forecast as the date draws nearer.
While many of the items in the roadmap task list are grouped according to the subsystem affected, others are more abstract in scope and represent an attempt to apply a general principle or development emphasis more broadly to the codebase. The emphases listed here are described below, providing you with the context necessary to understand the reasoning behind these broader changes:
Our task list certainly does not catch every area in Commerce where a principle should be applied. Contributors should feel free to propose changes not on the list that reflect one or more of these emphases, and we will discuss as a community which of these changes should become a part of the roadmap. All such discussion should take place in the issue queue as tasks or feature requests.
To move Drupal Commerce forward on Drupal 8, we need to look backward and recover one of our core founding principles: an eCommerce site is a data conduit, not a container. It should be easy to move data between a Drupal Commerce site and the various web services the site uses to power eCommerce at a much broader scale than is possible through the website alone.
This effort revolves around a refactoring on Drupal 8 that takes advantage of core REST functionality along with the hypermedia principles being pursued in Commerce Services on behalf of Commerce Guys' mobile app and client requirements.
There are a few clear instances where we added premature "power features" or pursued a local solution to a task better managed by a third party service. This should be addressed in Drupal Commerce 2.0 to better serve the majority use case:
Note that this emphasis does not mean we'll remove any feature that is inconvenient to the average user. For example, many people are surprised by customer profile duplication, but this is an essential feature of Commerce for preserving the integrity of historical order data.
We did a fair job of stamping out "magic" configurations in Commerce 1.x - cases where a setting or combination of settings results in a secondary feature that isn't explicitly mentioned. For example, Commerce 1.x originally depended on a combination of settings for fields to be considered product attribute fields, but we eventually removed this implicit behavior with an explicit settings form built into the field edit form.
Commerce 1.x served as proof of concept for many of the Drupal 7 core and contributed APIs, most notably the Entity / Fields APIs. However, we did not do a great job developing and using APIs within our own modules to facilitate development tasks like creating orders, manipulating prices, and processing payments. This emphasis ties back into the first, as we should develop our systems with REST application in mind.
In Commerce 2.x, we should ensure that our modules define robust internal APIs that are then used by forms, Rules actions, etc. as opposed to embedding functionality into these systems' related callbacks. Most notably, we should seek to make price manipulation and price component management much easier as we open up the sell price calculation process to direct manipulation in module code (as opposed to strictly using Rules) when sell price pre-calculation is disabled.
Each of these tasks will ultimately link to an issue on drupal.org where the change will be discussed and patched. Stricken tasks indicate completion of the core task, though there may be related issues still present in the issue queue.
Drupal Developer having 9+ year experience, implementation and having strong knowledge of technical specifications, workflow development. Ability to perform effectively and efficiently in team and individually. Always enthusiastic and interseted to study new technologies
Giải nén → đổi tên thư mục Symfony thành sfdemo, sao chép vào thư mục “/var/www”
Vừa thoát khỏi SOPA, cộng đồng mạng phải đối mặt với “cơn ác mộng” còn đáng sợ hơn thế.
There are advanced ways to do this, such as using the Workbench module, but in this tutorial we'll show you an easy way to provide a list of each user's content.
