With Drupal 8 proliferating out in the wild, now is a perfect time to get caught up on best-practices, trends, and experiments in the vast Front End world.
We've removed the Composer-managed vendor from the git repository.
There will not be any changes for people downloading Drupal 8 from drupal.org. The Drupal.org packager will add dependencies to zip and tar package.
If you're not using zip / tar files, e.g. when using a git clone, run composer install to get dependencies. See https://www.drupal.org/documentation/install/download#git for instructions.
The Louisiana Drupal Community is proud to welcome you to our world class city! Drupal powers some of our finest universities, museums, restaurants, radio stations and some of America’s oldest establishments.
Since 2010 our local and dedicated group of Drupaleanians meet each month for support and to share and socialize.
Our Drupal Camps (http://www.drupalcampnola.com/) have grown in size and popularity over the last two years with attendees traveling from around the country to attend.
Scott has been working with Drupal for nearly 5 years, and has a strong passion around improving the theming experience of Drupal. Scott was a major force in the push for Twig and clean markup in Drupal 8 core, sharing both his technical expertise and his enthusiastic community-building to make Drupal 8's theme layer awesome. He helped lead the "Consensus Banana" initiative that solved a long-standing concern with how core provides classes and markup, and then helped add the Stable base theme so that Drupal core could provide backwards compatibility for themes in minor releases.
Scott has organized sprints and discussions at many DrupalCons, including the groundbreaking templating and performance testing sprint at DrupalCon Portland that allowed Twig to become Drupal's primary theme engine. He and others also organized a Drupal 8 Accelerate sprint on security criticals related to the theme system that were blocking Drupal 8's release, engaging novice contributors to fix the issues. Finally, Scott was previously a lead for the Drupal Core Contribution Mentoring program, mentoring dozens of other contributors on IRC, at sprints, etc. He is skilled at evaluating a problem, framing how it can be solved, and helping people solve it. In short: Scott has not only the strong technical abilities, but also the patient and supportive personality to make him an amazing fit for a core committer.
Scott's appointment as a core committer was enthusiastically endorsed from the rest of the Drupal 8 committers. Please join me in helping him feel welcome! And please also give thanks to his employer, Digital Echidna, who have agreed to partially sponsor his community time!
I selected David Rothstein as my co-maintainer for Drupal 7 back in May of 2012. Since then, David has done a tremendous job shepherding the Drupal 7 release, paying very careful attention to the ramifications of any given patch and allowing ample time for "real world" testing before incorporating changes into the code base, ensuring that the code powering 2% of the Internet stays stable and performant.
However, after nearly 4 years of excellent stewardship on his own, David would like to also focus on other endeavors, including Drupal 8. Now the time has come to select an additional co-maintainer for Drupal 7. While David himself has recommended some excellent candidates, I'd also like to open the call out more broadly, to see if there are others who have an inclination and interest.
https://www.drupal.org/node/721106 contains comprehensive documentation on everything that a release manager does. In particular, the ideal candidate has the following traits:
- Ample experience building "real world" sites/platforms on Drupal 7, particularly high-performant sites, sites with millions of records, or other edge cases.
- Ample experience performing detailed and thorough technical reviews of patches, being particularly mindful of their effects on existing sites.
- Ability to communicate calmly and respectfully when critiquing code.
- Solid knowledge of Git and the Drupal.org release process.
- Ideally, sponsored time to work through your employer to maintain Drupal 7, particularly around the first and third Wednesdays of the month, which are the Drupal core release windows.
Please either respond here or use my contact form if you'd like to be considered as a potential Drupal 7 co-maintainer. Thank you!
- What has been the biggest success of Commerce on D7?
- By starting from scratch on D7 technologies we created a solution that is intuitive to Drupal developers and easier to extend. And with 60k installs, we’ve set a record for ecommerce on Drupal in general.
- And what do you think have been its biggest weaknesses?
- Not prioritizing UX from the start. Took us a year after the 1.0 release to create Inline Entity Form and recreate the admin screens as a part of the Kickstart. At that point many people already had the impression that Commerce was hard to use.
- Not providing enough direction to developers. Flexibility is important, as is having unopinionated code. But developers also need to have a clear and obvious path forward. Having an opinionated layer on top, with sane defaults, can save a lot of development time and prevent frustration.
- Not prioritizing certain features, leaving them to contrib instead. Modules that make up the checkout ux (checkout progress, checkout redirect, addressbook), discounts. Of course, all generals are smart after the battle.
- How has that influenced the development of Commerce 2.x?
- With Commerce 2.x we once again started from scratch, evaluating all feedback received in the 1.x cycle. We decided to address all three of these major points.
- Better UX means paying more attention to the product and order admin experience, as well as providing better checkout out of the box.
- Better APIs means doing more work for the developer, especially around pricing and taxes.
- And finally, we’re growing the core functionality. We’re expecting a dozen contrib modules to be no longer needed, as we address edge cases and add functionality.
- What are some of the biggest new features of Commerce 2.x?
- Multi-store will allow people to bill customers from different branches (US and FR offices, for example), or create marketplaces like Etsy.
- Improved support for international markets means better address forms, better currency management, and significantly better tax support, the kind that will reduce the need for people to use cloud-based tax solutions, at least in Europe.
- Support for multiple order types, each with its own checkout and workflows will allow developers to create tailored experiences for different kinds of products, such as events, ebooks, t-shirts.
- An integrated discounts UI means more power to the store admin.
- And this is just the beginning. Under the hood there are many small features and improvements, over both 1.x and Kickstart.
- What has Commerce done to integrate better with the PHP and Drupal communities?
- We’ve created several independent ecommerce libraries, attacking currency formatting, address management and taxes. These libraries are now being adopted by the wider PHP community, bringing us additional contributors.
- On the Drupal side we’ve joined forces with the Profile2 team, creating the D8 Profile module that we’ll use for customer profiles. We’re also depending on Inline Entity Form, which is now shared with the Media team. We’re also moving some of our generic entity code into a new Entity API module, maintained together with Daniel Wehner and other community members.
- Finally, we have been champions of Composer, the replacement for Drush Make, and required for any module that depends on external libraries.
- Commerce 2.x is now in alpha2. What’s included? What’s next?
- Alpha2 includes stores and products, as well as initial order and cart implementations.
- It also has functional currency management and formatting, address and profile management.
- Alpha3, to be released in the next two weeks, is focusing on completing the order and cart implementations, and adding the initial checkout implementation.
- Post-alpha3 our focus will be on discounts, taxes, and finally, payments.
- The best way to learn more about this is to read the drupalcommerce.org blog, where I post “Commerce 2.x stories” detailing work done so far. We have several new posts planned for february.
- When can we expect Commerce 2.x to be production ready?
- Our current goal is to release a production ready beta by end of march. We should also have Search API and Rules by then. Leading up to DrupalCon New Orleans we’ll be helping the community implement shipping and licensing and port payment modules. At the same time, we’ll be focusing on reaching RC status.
- What’s the status of commerce contrib? Like PayPal, Authorize.net, etc.
- How can the community help?
- Each new alpha welcomes more manual testing and feedback.
- We also have office hours every wednesday at 3PM GMT+1 on #drupal-commerce where people can discuss code and help out on individual issues.
- Do you feel that requiring Commerce to be installed via Composer will impact adoption?
- The average developer is already familiar with Composer and will benefit greatly from it, just like D7 developers benefited from Drush Make. Getting Drupal, Commerce, and all dependencies is a single Composer command, as is keeping it all up to date.
- People unwilling to run Composer on their servers can run it locally and commit the result.
- I’m also hoping we’ll be able to offer distribution-like tarballs on either drupal.org or drupalcommerce.org as we get closer to a release candidate.
- howdytom @howdytom
Commerce Kickstart provides a great toolset with basic configuration. Is there a plan to do a Commerce Kickstart for Drupal 8? If not, will Commerce provide more out of the box solutions for a full featured shop?
- Commerce Kickstart had several parts.
- The first one was about providing better admin and checkout UX, as well as discounts. That’s now handled by Commerce out of the box.
- The second was about providing a demo store with a developed set of frontend pages. That’s going to stay in contrib and will greatly benefit from the flexibility introduced by Drupal 8 and CMI.
- It’s too early to plan a distribution yet. Drupal 8 has almost no contrib, and drupal.org doesn’t support using Composer to build distributions yet.
- However, we are using Composer to provide single-command site templates, the kind that gives you Drupal core, Commerce and other modules. This will allow us to provide good starting points for different use cases, similar in nature to Commerce Kickstart 1.x.
- Once 2017 comes around, we’ll investigate next steps.
- Jimmy Henderickx @StryKaizer
In commerce d8, will it be possible to alter a product name dynamicly (either by hook or other solution)?
- Czövek András @czovekandras
Any plans making iframe payment methods 1st class citizens? Thinking of running checkout form callbacks.
- Marc van Gend @marcvangend
How did D8 architecture change the way you code your modules?
There are two really useful checklist modules in Drupal:
- The SEO Checklist module gives you a rundown of all the search-engine optimization fixes you can make.
- The Security Review module automatically tests for easy-to-make security errors.
In this video, taken from our Drupal 7 Security class, Robert introduces the Security Review module. He shows you how to fix some of the most common errors found by the module, such as "Base URL is not set in settings.php" and "Some files and directories in your install are writable". Even if you think your site is safe, give the Security Review module and you may well find something you missed.
For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.
Yes, Welcome to DrupalCon can now be watched in half the previous time! But if eight minutes is still too daunting, we suggest you absorb it in a series of one-minute bursts, maybe during the rest-intervals in your 30-20-10 training, or on down time while obsessively clicking your pen waiting for the Adderall to kick in.
Enjoy!Tags: DrupalCon Barcelona Drupal Ron Brawer mini-documentary Drupal Association Tag1 Consulting Video:
In November, 2015, the Stanford Web Services team got to dive into Drupal 8 during a weeklong sprint. I was excited to look at the RESTful web services that Drupal 8 gives out-of-the-box; what follows is my documentation of the various types of requests supported, required headers, responses, and response codes.
This is not intended to be an exhaustive documentation of RESTful web services in Drupal 8. However, I have pulled information from various posts around the Web, and my own experimentation, into this post.
Warden is a solution for in-house development teams and agencies who need to keep track of the status of many Drupal websites, hosted on a variety of different platforms.
Warden gives you a central dashboard which lists all your Drupal websites and highlights any which have issues, for example needing secuity updates.
Hosting companies, like Acquia and Pantheon, have their own reporting tools but these only work if you host on their platforms. If you have an estate of websites which run on multiple platforms you need a tool which can report on them all.
The Warden application is composed of two parts, a Warden module which you need to install on each of your websites and the central Warden dashboard you will need to host on a web server. The Warden dashboard is an application written in Symfony and is freely available on github.
At present only a Drupal integration exists but work is underway to produce a pluggable system which will allow new modules to be created for Wordpress and pure Symfony sites. Others may then wish to contribute additions for their own needs, for example by providing different kinds of reports for the sites.Warden Dashboard
After correctly configuring the Warden Symfony application you will be presented with the Warden Dashboard. This lists all the sites in your estate with high level details of each. Sites requiring a security update are highlighted as red, sites with module updates which are not security are yellow and sites with no problems are white.Drupal modules listing screen
The Drupal plugin for the Warden application provides a modules listing screen. This lists all Drupal modules installed across all you estate and allows you to see which Drupal websites have and do not have a particular module installed. This helps when you need to know how many sites need to be updated as a result of a module change or knowing how many of your Drupal sites might be missing a best practice module.Security
The Warden application uses OpenSSL to encyrpt data which is sent between it and the Drupal website. The PHP OpenSSL Cryptography extension is required for both Warden and the Drupal sites it will take data from. You can also IP restrict which servers can request data from your Drupal websites in the module configuration.
In normal operation the Warden dashboard will poll the sites periodically to request the sites data be refreshed. You can alternatively configure it so that the sites push the data to the Warden dashboard. In either configuration, the site will only send data to the configured dashboard and not to the site making the request for data.
It is also recommended that you use a signed SSL certificate on your Drupal websites and your Warden dashboard.Where to get Warden
You can download the Warden central applications from GitHub here: https://github.com/teamdeeson/warden
The Drupal module is available on drupal.org here: https://www.drupal.org/project/wardenWhat next?
We welcome contributions to the Drupal module or the Symfony application codebase, let us know what you think!
If you are intersted in integrating Warden into other web tools then you'll need a copy of the PHP API which is available here: https://github.com/teamdeeson/wardenapi