With each veil pierced, exponentially shrinking numbers of increasingly enlightened people are deemed insane by exponentially increasing masses of decreasingly enlightened people.
This past weekend, our thriving Vancouver community came together and worked on getting a variety of Drupal contrib projects ready for Drupal 8. This weekend allowed us to put on the finishing touches needed to get a stable 8.x-1.0 release out to the community! Let's have a look at what's new about this release of Basic, as well as some upcoming features.
While working on recent Drupal projects, I learned that Internet 10 and 11 (IE10-11) no longer support IE conditional comments. Conditional comments allow us to target specific versions or version ranges of IE to correct bugs or inconsitentices that normally are not present on other browsers. Typically for IE9 and below, we have been able to write conditional css by using something like this:
When we travel, we create memories, and many of us seek to preserve these memories through souvenirs. Soon you will be in Mumbai for DrupalCon and when you are leaving, you should make sure to pick up something you can always cherish. Here are a few things you can take back from India as souvenirs, regardless of how big or little your budget may be.
Two students take a close look at how video game character creators represent race, and speak to players to find out how those representations affect them. ...
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.
Manage external css & jss through Drupal admin UI & Contexts. Files support multiple versions based on prod/stage/dev environments for easier development on production instances.
This module was developed by Interscope Records and designed with Acquia Sitefactory in mind to accommodate building sites in a multisite environment off a shared codebase without the need to push out updates for theme-level updates.
This module extends the Configuration Synchronization user interface with a form to select the source of the configuration to synchronize with.
The core user interface only has the ability to compare with the default sync directory. But it is possible to define any number of other source directories in the settings.php, so this module makes it possible to compare changes between those directories and the active configuration, and to import those changes.
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.
The Drupal core maintainer handbook 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!
Suggests username by defined pattern if filled username exists.Installation
Install as you would normally install a contributed drupal module.Configuration
- Enable module.
- Go to admin/config/people/accounts if you need to configure suggestion pattern.
- Override suggestion message template if needed (username_autosuggestions).
One of the problems in an exploration game is content. We’d all like to put together a campaign world with content jam packed into every nook and cranny, but there are some problems with that. First and foremost is our time constraints. Not only would it take forever to create so much content, but a lot of that effort would be wasted as entire swaths of our setting never got explored closely enough to dig out most of the material. Here is one potential solution to this issue: the mini dungeon as a random encounter.
The concept is simple. You put a dungeon on your random encounter list, when that result is rolled, the players discover a dungeon. From now on, that dungeon is in the world and is a permanent fixture. It’s safe to assume that the players will ransack it once and never come back, but that’s not a big deal because it takes only a few seconds to throw it together, mark it on the map and toss off a few lines in your notes for posterity. In this way you can have a world with dungeons secreted away under ancient trees, in the cellars of fallen houses, and carved out by streams, giving the feel of a deep world with lots of time spent on tiny detail, all with almost no additional prep time.
Here’s why it’s so fast: In an earlier article I noted that the 5 room dungeon has only 9 forms. Several astute readers pointed out that by abstracting away the entrance, there were really only three forms: a straight line, a cross, and a “y”. The article goes on to give ways to differentiate these simple dungeons from one another, but they all boil down to the same few layouts. The same thing can be said of dungeons with other numbers of rooms. There is really only one form each for the one, two, and three room dungeons, and there are only two forms of the four room dungeon, a straight line and a “y”. Just pick (or heck just roll a d8 if you like) one of these, maybe apply a tweak or two from the previous article, and your layout is done quick and easy.
Next you’ll want to apply a little flavor. Since these are all small dungeons, it’s fine for the flavor to be uniform throughout, though if you want to make a ruined cellar that breaks into a natural cave or an old fort with a forested courtyard you’re more than welcome to. Chances are because you know where the players currently are, you know what flavors would be appropriate off the top of your head, though if you don’t want to be put on the spot, you can make up a brief “flavor table” for an area when you put a dungeon on their encounter table. Also give a quick thought to visibility. If the players have been through an area repeatedly and visibility is good, dropping down a highly visible dungeon like an abandoned keep will probably elicit a few questions so you will likely want to stick to a sinkhole or other low profile choice. On the other hand if it’s the player’s first time to an area or it’s hard to see at a distance (heavy forest, hills, etc…) there’s nothing wrong with using a wizard’s tower or other highly visible site. What flavor you choose can also help hammer home the history and particulars of your setting. If dwarves used to live in the hills but were wiped out by orc tribes, you have the perfect opportunity to showpiece that with a dusty dwarven ruin.
Finally, it’s time to stock the dungeon with traps, hazards or monsters. This is super easy. You earlier rolled on a random encounter table. Roll on it again and place that encounter in one of the rooms. Don’t feel like every room has to be filled. This isn’t a large place and it isn’t hotly contested unless you want it to be, so putting encounters in half the rooms is fine. Once you roll, if you need more encounters, either duplicate the same one, tweaking it a bit, or choose a compatible one from your list. Of course a mini dungeon is also a perfect lair for one of the tougher solo encounters from your list as well. Don’t worry too much either about dropping a tough encounter or several encounters where you would have otherwise rolled for one. There is the expectation that the danger is ramping up a little when entering a dungeon and the players can always choose to pass up the danger by walking past.
All of this takes less than a minute and, if you have that “flavor table” can actually be handled with the toss of a set of three dice. These dungeons are simple quick throwaways but they add a little extra adventure to overland travel and exploration and make your campaign world “denser” than it would otherwise be.
- 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.
This module overrides the error level setting with a permission.
So you can
* have a sitebuilder role (or even a special debugger role) see errors and notices
* have others not see errors and notices.
You may also like Role toggle with this.