Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll look at Range, a module which allows you to declare a range of numeric values.
This week's Video Game Deep Cuts longform article/video highlights include the magic of The Void, John Romero on the TEd tool, Hyper Light Drifter's charm, & much more. ...
In January of 2015, Accel-KKR, a private equity firm, combined Ektron and the Swedish company Episerver into a single company and CMS platform. This has caused many organizations to choose to migrate off the Ektron platform and onto a CMS like Drupal. Two factors are driving this trend: the high cost of an Episerver license upgrade, and the fact that the open source landscape has evolved significantly over the prior decade, to the point where many enterprise organizations (from private and public corporations to government entities) have embraced Drupal and the open source community.Tags: acquia drupal planet
Our solution for advanced configuration management workflows has just become more powerful! The core of what makes Configuration Split work so nicely with drush and the Drupal UI has been split off in a new module: Config Filter! Config Filter exposes a ConfigFilter plugin and swaps the sync storage applying all the active ConfigFilters to it. This means it is no longer necessary to manually swap the service as we recommended to do in the past and it works also when installing a site, as the swapping happens only when the module is installed. As of drush 8.1.10 this works with the default config import and export commands.Update Config Split
For current users of the Config Split module it means that they should remove the custom service swapping as part of the update and then apply the database updates which will install Config Filter (you already downloaded it with composer update, right?).New command-line options and new workflows
With the re-factoring we also changed the options of the drush and console commands. We added a new option for specifying a split and then export to and import from only that split directory; this supersedes the previous options to specify separate export destinations and import sources - they are not needed for the simple work flow we advocate for, and the behaviour can easily be achieved by modifying settings.php as needed.
With the addition of the single split export, a new workflow becomes possible: export only the "production" split, before importing the whole configuration which will have it merged back in.Improved Graylists
In addition to the new architecture the graylist feature has been improved so that dependencies can be graylisted as well and optionally only items that differ from the sync storage are split off. More details and more documentation will come in future.Roadmap
The ultimate goal is to improve the export API in Drupal 8 core so that more advanced workflows are possible. Config Filter is our proposal for a solution in contrib, but we feel that this functionality should belong to Core.
On the way to Core, here are some more immediate steps:
- Clean up after the big refactoring, adding automated tests for some special cases.
- Improve the documentation.
- Integrate with Config Readonly to allow locking the site except for the configuration defined in splits.
- For those that want to do configuration management without seatbelts, integrate Config Ignore with Config Filter so that it can work smoothly next to Config Split.
- ...and eventually propose Config Filter for inclusion in Core!
The re-factoring started during the Drupal Mountain Camp in Davos and I would like to thank the organizing committee for the great event. On Friday I gave a presentation about my favorite topic in Drupal: Configuration Management, attached here are the slides based on the Nuvole presentation at DrupalCon Dublin 2016.ConfigurationManagement_no-problems_davos17.pdf
Spacecraft are all very well, but once you reach your destination, how do you get around? Having the appropriate land, sea and air vehicles can go a long way to making other planets feel real, alien, exotic... or whatever impression you are trying to get across. Vehicles can also be a source of adventure: perhaps it is hard to get hold of one when you need it, or maybe offworlders have to use a specific form of transport. Indeed, they can end up being the adventure: many years ago, a spectacular Traveller adventure was spawned at a Games Fair convention in the UK when a bunch of players decided that they weren't staying around for the riot that had broken out and stole a groundcar... unfortunately none of them knew how to drive it, and their exploits on the way back to the starport became the stuff of legend!
The Introduction lays out the purpose of the book clearly. The design system is simple and straightforward, but fits in with everything else so far published. The emphasis is on what the vehicle can do, how fast it goes and what it can carry. That's what you need to know as far as game mechanics are concerned... most of the rest is window-dressing.
Chapter 1: New Rules provides some additional rules that you will need to make it all work. There are notes about resupply and maintenance, sensors, detection of vehicles and even things like can the vehicle tow something else (or indeed, be towed)... and of course the pleasures and perils of the used vehicle market! They also may be specifically designed for a purpose: combat, say, or off-road operation.
We then move on to Chapter 2: Vehicle Design. It's a seven-stage process, very streamlined, and once you are used to it you can crank out new vehicles in a matter of minutes. Actual construction times and costs are likely to be a little more, though there are advantages to mass-production. Most parties will be looking to buy (or rent) rather than make their own vehicles from scratch, however. Starting with chassis type and tech level (stage 1), you then decide the number of 'spaces' the vehicle has (stage 2, which determines the basic parameters for the vehicle), add weapons and armour if required (stage 3), customise it if you want to (stage 4), work out how many crew are needed and passengers can be carried (stage 5), allocate cargo space (stage 6), and finalise your design (stage 7)... and you're done! This is a toolkit rather than hard and fast rules, and the Referee is always at liberty to deviate if desired. An example (a fairly ordinary-looking ground vehicle, a rugged van basically) is worked through in detail to demonstrate the process, and the next four chapters go into more detail about chassis types, armour, weapons, and customisation.
Grouped by basic chassis type - light ground vehicle through gravitics-powered and unpowered ones, then boats, submersible and aircraft - there are loads of options to help you come up with exactly what you need. You can even have ornithopters and walkers if you want. Armour is generally a case of strategically-placed plating, then on to weapons, as many and as varied as you can imagine. Weapons can be mounted in various manners, and a wide range of generic ones are provided... and then comes customisation. Your imagination is pretty much the limit, although there are suggestions galore and an in-character advertisement for a vehicle design consultancy!
Next, things get a bit exotic with Chapter 7: Biotech. This may or may not be commonplace in your universe, or it may be very localised. The chapter assumes that it is rare but possible, and assumes it needs at least a TL10 world to create biotech vehicles, but that the biotech vehicles themselves operate two tech levels lower. If biotech is commonplace, you can ignore these restrictions. Again, maintenance and repair may be problematic if biotech is unusual, but straightforward if such vehicles are readily available. Some exotic versions of chassis types and weapons are provided, but feel free to go wild!
This is followed by Chapter 8: Drones. These can be remotely piloted or autonomous, and there's an interesting sidebar about whether you should use robot rules rather than these drone ones to create them. The conclusion (apart from leaving it open to the Referee to decide) is that a drone is specifically an unmanned vehicle, a robot can do most anything. Perhaps drones are a subset of robots? (Maybe I should ask the computing ethics class I'm teaching after lunch!)
If your head is swimming with all the choices, never fear... the final section is Jayne's Guide to Vehicles of Charted Space, a vast array of pre-generated vehicles of all sorts that you can use straight off... or customise a bit, first. Each one comes with a description, cost, appropriate statistics and an illustration. Conveniently, each occupies a single page so PDF users may print off just the pages they need. There does seem to be rather a lot of military vehicles, fine if you are equipping some mercenaries but of less use if you've just landed and want to go sightseeing!
Overall, a robust system which meshes well with the rest of this ruleset... but in some ways a little uninspired. Consider the science fiction books you've read or films you have seen. Describe the vehicles in them... sometimes troubling to codify everything bogs you down. OK, so you need to know how fast it goes and what it can carry, how much damage its weapon does... as for the rest, let your imagination run riot. This system will let you slot in whatsoever numbers and game mecahnics you need.
Last weekend the Florida Drupal community hosted its ninth annual Florida DrupalCamp (FLDC) at Florida Technical College in Orlando. It was a great success. At this point, we (the organizers) have a pretty good idea how to put on this event. (Since a good number of us have been involved in all nine iterations, (and all still seem to like each other!) some aspects of the camp organizing process are on veritable auto-pilot.
If you're a camp organizer, you know what goes into securing sponsors and a location, spreading the word, finding presenters, arranging for swag and catering, etc… For this year's event, we wanted to step things up a bit by focusing on three things: more learning, more fun, and more networking. Based on feedback and our own experiences, we feel like we achieved all three goals with some changes from previous years' camp recipes.More Learning
In the past, FLDC has been a 2-day event; Saturday has been the main event - a day full of sessions, while Sunday has been a "community day" with sprints, Coding for a Cause, BoFs, and a generally less-defined schedule.
This year we decided we stepped it up to a full-on three-day event; full-day training workshops on Friday, sessions on Saturday and Sunday, as well as a professionally mentored code sprint on Sunday.
With the generosity of five trainers, we were able to provide full-day workshops to almost 80 people on Friday. Many, many, many thanks to our trainers:
- Introduction to Drupal 8 Theme Development - Suzanne Dergacheva, Evolving Web.
- Introduction to Drupal 8 - Michael Anello, DrupalEasy.
- Introduction to DrupalVM - Ben Hosmer.
- Docker for Development with Drupal - Lisa Ridley, Promet Source.
- Beginning ReactJS - John Tucker.
The other change to facilitate more learning is to provide experienced sprint mentors for our Sunday sprint. With a nudge or two (maybe three) from xjm, we decided to have a Major Issue Triage Sprint at this year's camp. We brought in YesCT and nerdstein to mentor the sprinters to great success. During the Sunday sprint, we were able to make progress on well over 20 Drupal core major issues.
Finally, we decided to bring in Kevin Thull (@kevinjthull) to handle all the session recording, processing, and uploading for the event. Kevin's work with recording other Drupal events is top-notch. Having all of our sessions recorded will allow those who weren't able to attend (or those who did attend but couldn't make a particular session) to be able to benefit from our speakers. All of the sessions are currently posted on our website schedule, as well as on our Youtube channel.More Networking
Traditionally, we have always had a full-day beginner track on the main day of the camp. This had the effect of keeping the vast majority of the beginners in the same room all day - limiting their networking opportunities. By having a full-day introductory workshop on Friday, beginners became fully-involved in camp activities the rest of the weekend. The feedback we received from this change is overwhelmingly positive.
The other big-ish change aimed at more networking was to increase the amount of time between each session to a full 30 minutes. This had the side-effect of us having fewer sessions on Saturday, but was mitigated by adding a half-day of sessions on Sunday. Again, the response we received from this change was overwhelmingly positive. It provided a less "rushed" day for all attendees, gave presenters a little more leeway if they went a few minutes over their allotted window, and provided ample time for the hallway track. In addition, our sponsors loved this change, as it gave attendees more time to stop and chat with sponsors in our exhibition area.
During the closing session, we announced that any leftover funds from the event can (and should!) be used by Florida local meetup organizers to promote and grow their local meetups. In the past, we've informally made these funds available, but we're going all-in this year. If you're a Florida Drupal meetup organizer, we have $$$ for you for meetup.com memberships, food for your meetups, or just about anything else that will help you grow your local community. Look for more details on https://groups.drupal.org/florida soon.More Fun
While Drupal events tend to be very positive events for all attendees, we made the conscious decision to ensure that we maximized the enjoyment of our attendees while we kept the Drupal knowledge flowing. It was also very important to us that we make a positive first impression on those new to Drupal and attending one of their first Drupal events. We wanted folks to be able to leave the event with positive feelings for the Florida Drupal community.
To this end, we increased the fun factor in several ways. First off, we further "official-ized" our Friday night dinner gathering. Over the past few years, organizers and a few others have always gathered at Bubbalou's a local BBQ restaurant just down the street from the camp venue after prepping the venue for the event. This year, with the full-day trainings on Friday, we invited everyone to meet up at the restaurant for a pay-on-your-own dinner. This turned into a wonderful, casual evening for well over 75 people. The restaurant has a large indoor/outdoor picnic table eating area, perfect for networking.
On Saturday, we set the tone early and put smiles on people's faces from the very start. We worked with the folks from Gatorland to have a professional animal handler and a friendly alligator named Skywalker on-hand to greet guests when they arrived. Many attendees went for a cuddle with Skywalker even before getting coffee.
Additionally, we wanted to provide unique swag to our attendees. A former attendee of previous Florida DrupalCamps, Kathryn Neel, is now running custom chocolate business, Sappho Chocolates. We worked with her company to create Druplicon chocolates for all attendees. As part of the process, we funded the development of the custom molds for the Druplicon chocolates, so if any other Drupal event organizers want to order chocolates for their event, the molds are there for your use!
Finally, for the last Saturday session, we went with a single session of lightning talks. This ended up being one of the highlights of the weekend, as we had a some amazing 5 minutes talks. With most of the camp attendees in the room, it left everyone with smiles on their faces and provided a great transition to the closing session and after party.Sponsor Happiness
Most camp organizers always have trepidation about camp finances right up to the actual event. Sponsor needs have evolved as the Drupal community has evolved, and camp organizers have to evolve as well. Today's Drupal event sponsors are more focused on getting a return-on-investment from their sponsorship dollars than ever before, so it is up to event organizers to do everything they can to make that happen.
By providing more time for attendees to visit sponsor tables as well as the opportunity for Platinum and Gold sponsors to receive an opt-in version of our attendee list, as well as all of the other "standard" sponsor benefits, the feedback from our sponsors has been very positive. Additionally, we gave Platinum and Gold sponsors the opportunity to place text ads in our emails to attendees leading up to the camp.
Our Platinum sponsor, Achieve Agency is a newly-formed Florida digital agency based in West Palm Beach. John Studdard, their COO (and formerly of Big Couch Media), has been a long-time FLDC supporter and attendee, and wanted to use FLDC as a vehicle to announce Achieve Agency to the community. As event organizers, we couldn't be happier that our top-level sponsor is a Florida-based organization.Featured Speakers
Keeping with our tradition of not having a single keynote speaker (mainly due to the fact that our venue's auditorium can't accommodate all attendees, we invited three featured speakers to this year's event. We were lucky to get our top three choices - check out their (recorded) sessions below:
- Megan Sanicki, Executive Director of the Drupal Association - Keeping the Drupal Community Alive and Thriving.
- Helena McCabe - accessibility expert, Lullabot - In Their Own Words: Accessibility Stories and Accessibility Audit and Case Study.
- Suzanne Dergacheva - co-founder and front-end developer, Evolving Web - Creating Landing Pages and Layouts for Drupal 8.
As always, our post-camp organizer retrospective highlights a few areas we need to address for next year's event.
- Have a printer on-hand for printing emergencies.
- Find a volunteer to arrange for food donations for left-overs.
- Figure out a magical solution for badges that will make everyone happy.
- Find a new official hotel: We had a fair number of complaints.
- Figure out a way to improve the slow service at the after-party.
- Camp attendance was a bit more than last year. Overall, we had 251 registered attendees. A bit more than 100 participated on Friday, almost 200 participated on Saturday, and about 100 participated on Sunday.
- Camp budget was about $18,000, the majority went to catering, but we also had significant costs for featured speakers and sprint leads travel and swag.
- We had a total of 17 fiscal sponsors which provided about two-thirds of our income.
- The registration fee for attendees was $35 ($25 early-bird), with an optional $25 individual sponsorship. We had 41 individual sponsors.
- Our camp organizing volunteers are way better than yours.
- We invested a bit this year in large signage that we can re-use in future years.
- Another change this year - volunteers got in for free (sorry this took so long).
- We had attendees from 9 countries and 19 states.
What more can we say? Florida DrupalCamp 2017 was a huge success. Our volunteers are the best, our sponsors are the best, and the Florida community is the best!
When Hero Forge first came out with their 3D printed miniatures, I did an interview with the creators and backed them on kickstarter. I used my kickstarter codes to order miniatures for review and I did a review of the miniatures from stem to stern, showing what they looked like by getting miniatures made of my gaming group. A few months back, Hero Forge sent me complimentary codes for their new Premium “Grey” plastic option. It took me a while to get them painted and prepped, but here is an update to the previous review.Overall Thoughts
The Premium “Grey” plastic option is right in line with the level of detail, quality, and durability I would expect from any plastic miniature. They paint as easily as Reaper miniatures and have a lot more details than the level of detail I could get from 3D printing them myself or using the Strong plastic. The premium plastic has just a bit more detail than the Ultra Detail options from Hero Forge, but the durability is much higher. I’ve had many of the ultra detail miniatures break at weak points, and even the fiddly bits on the strong plastic pieces have broken on me once or twice, but the Premium “Grey” plastic option holds up far better.Painting Tips
I’ve rarely had to use primer on many of my reaper bones miniatures, but with the Premium “Grey” plastic, I found it very helpful to prime them first. Unlike the strong nylon miniatures, which soak up paint, these almost repel it. The first layer of paint I put on the miniatures was fairly slippery, and the thinner my paints, the less likely they were to stay on. I usually use a flow agent to make my paints a little lighter, but for the Premium “Grey” plastic, I had to have a slightly thicker paint to get it to stick on the plastic easily. It took two coats for the miniatures, and having a primer layer would have made it take only one. The miniatures were easy enough to paint, and I mimed the color schemes and setup of other Hero Forge miniatures I had for comparison. Bear in mind that I am not a master painter by any stretch of the imagination. I can do okay, but I am perpetually jealous of the miniatures I see posted in DM Scotty’s facebook page.Photo Review
Really, the only way to show how well these do is through photos, so check out the picturesbelow to see the comparisons and be sure to check out the other review I did to see the other plastic options from Hero Forge.Unpainted
Compared to other Hero Forge Options
Comparison to Reaper Bones
I’m a big fan of the Premium “Grey” Plastic option for a miniature. The quality, detail, and durability of the Premium “Grey” Plastic far surpass the other options out there for 3D printed miniatures and are on par with Reaper bones miniatures. For a character or the Big Bad for my game, it is well worth the cost, especially if I plan to play the character for a long time. Now let’s talk giveaway. For the miniatures we created, I duplicated one of my primary characters and we did a female gamer gnome.
That unique and original gamer gnome can be yours! How do you get it? Well, there are two ways.
- First, everyone who is a Patreon supporter is already entered into every giveaway contest we do.
- Second, you can leave a comment here.
We’ll compile all of our patreon supporters and the commenters here and roll a die to pick a random winner, then we’ll contact that winner by email to get shipping information. So, if you want to see what the Hero Forge grey plastic is like in person, and have your very own custom painted gamer gnome from Gnome Stew, go back our Patreon (because you love us and want to help us make cool stuff for everyone!) or leave a comment here before 03/06/2017 to be entered into the giveaway!
Dates have always been a tricky thing to manage in Drupal. Even in PHP. PHP 5.2 introduced the DateTimeInterface which makes handling dates, date ranges, intervals, comparisons etc much easier. However, we always still have the complication of data storage, formatting and different timezones management.
In this article we are going to look at how we can run some entity queries in Drupal 8 using the Date field in our conditions. The requirement for returning entities which have a date field with a value between certain hours is definitely not an edge case, and although seems like an easy task, it can be tricky.
Imagine a simple date field on the Node entity which stores date and time. By default in Drupal 8, the storage for this date is in the format Y-m-d\TH:i:s and the timezone is UTC. However, the site timezone is rarely UTC and we very well may have users choosing their own timezones. So we need to construct our node queries carefully if we want reliable results.
Running a db_query() type of query for returning nodes with the date in a certain range would be a pain at best and impossible at worst. Luckily though, we can, and should always in Drupal 8 try to rely on the entity.query service when looking for entities.
So let's see a couple of examples.
First, an easy one: how do we query for all the nodes which have the field_date value in the future.$now = new DrupalDateTime('now'); $query = \Drupal::entityQuery('node'); $query->condition('field_date', $now->format(DATETIME_DATETIME_STORAGE_FORMAT), '>='); $results = $query->execute();
A few things to notice. First, we are using the Drupal wrapper of \DateTime and constructing an object to represent our current time. Then we create our entity query and for the date field condition we pass the storage format so that it can be compared to what is being stored. And the regular operators here allow us to find the right entities.
There is one problem with this though. When creating the DrupalDateTime, the site default timezone is used. So if our timezone is not UTC, the query will suffer because we are essentially comparing apples with oranges. And the further away from UTC we are, the more apples start to become compared to cars and airplanes.
To fix this, we need to set the timezone to UTC before running the query.$now = new DrupalDateTime('now'); $now->setTimezone(new \DateTimeZone(DATETIME_STORAGE_TIMEZONE));
And then use $now in the query. The subtle difference to understand is that we are creating $now totally relative to where we are (the site timezone) because we are interested in finding nodes in the future from us, not from from another timezone. However, we then convert it so that we can have them compared properly in the query.
A more complex example could be a range of times. Let's say we want all the nodes with the time of today between 16:00 and 18:00 (a 2 hour span).
I prefer to work directly with \DateTime and then wrap it into the Drupal wrapper just because i can have all the native methods highlighted by my IDE. So we can do something like this:$timezone = drupal_get_user_timezone(); $start = new \DateTime('now', new \DateTimezone($timezone)); $start->setTime(16,0); $start->setTimezone(new \DateTimeZone(DATETIME_STORAGE_TIMEZONE)); $start = DrupalDateTime::createFromDateTime($start); $end = new \DateTime('now', new \DateTimezone($timezone)); $end->setTime(18, 0); $end->setTimezone(new \DateTimeZone(DATETIME_STORAGE_TIMEZONE)); $end = DrupalDateTime::createFromDateTime($end); $query = \Drupal::entityQuery('node'); $query ->condition('field_date', $start->format(DATETIME_DATETIME_STORAGE_FORMAT), '>=') ->condition('field_date', $end->format(DATETIME_DATETIME_STORAGE_FORMAT), '<='); $results = $query->execute();
So first, we get the user timezone. drupal_get_user_timezone() returns for us the string representation of the timezone the current user has selected, or if they haven't, the site default timezone. Based on that, we create our native date object that represents the current point in time but set the actual time to 16:00. After that we set the storage timezone and create our Drupal wrapper so that we can format it for the query.
For the end date we do the same thing but we set a different time. Then we expectedly write our query conditions and ask for the entities which have a date between those 2 times.
The order of setting the time and timezone on the date object is important. We want to set the time before we set the timezone because the times we are looking for are relative to the current user, not to the storage timezone.
So that is pretty much it. Now you can query for entities and play with date fields without issues (hopefully).