All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
"Stuff like that is truly emergent," PlayerUnknown's Battlegrounds creator Brendan Greene tells Eurogamer. "Something that you can never really plan for." ...
The Drupal 8 module for MailChimp Service.Installation
To install from this repository:
Clone the repository into your Drupal site modules directory:git clone --branch 8.x-1.x https://git.drupal.org/project/mailchimp_service.git cd mailchimp_service
This module require drewm/mailchimp-api": "^2.2
Gone are the days when Steam users would have to venture out into the world to buy and send Steam Gift Cards to friends. ...
The ideas of Atomic Design and component based design allow one to create an established structure within which a large scale front end project can be built. The CMS space hasn’t always been the most friendly toward implementing these types of patterns. Whether it’s difficulty in creating a content architecture that models your front end design system within Drupal or the feeling of lack of control over generated markup, it can feel like an uphill battle.
The Paragraphs module gives us the tools to create much more well defined and structured component based architectures upon which modular front end systems can be built. The Paragraphs module, however, comes with no rules. As a site architect and front end developer, you must decide how to implement Paragraphs. There is definitely a lot of room for flexibility in implementation, but there are many best practices that can be followed to allow for a very clean, scalable, and extendable front end design system to be built within Drupal 8.
The goals of this session will be the following:
- Review the basic concepts and benefits of component based design
- Discuss the paragraphs module and how to create an implementation based on a well defined content architecture
- Explore some Drupal best practices that allow for a successful component based design system implementation
It's here! Lightning 2.2.1 provides a migration to the core media system that was introduced in Drupal 8.4.0.
This is a major milestone for us. One of the big advantages of using Lightning over vanilla Drupal or a roll-your-own solution is that as underlying modules evolve, Lightning maintains an update/migration path. This effectively creates a facade in front of media, workflow, and layout functionality. That functionality remains stable no matter what. Of course, this is in addition to the fact that Lightning provides all of that functionality out of the box. (Even though Media is now a part of core, it still doesn't provide the out of the box configuration, experience, and add-ons that Lightning does.)
Core Media migration was #2 in our list of major migrations. It was preceded by a migration from Layout Plugin to the core Layout Discovery module. Next up is Workflow which will involve migrating from Workbench Moderation to core's Workflows and Content Moderation modules.
Special thanks to phenaproxima who is at the intersection of the core, contrib, and Lightning work. To say the migration wouldn't have been possible without him is an understatement.Want to try it out?
Update your existing codebase:composer update acquia/lightning --with-dependencies composer update drupal/core
Then check out our 2.2.0 -> 2.2.1 update instructions.
Or build a fresh codebase:composer create-project acquia/lightning-project MY_PROJECT
Provides a field with quick links that can be added in the content listing for editors to edit the existing translations or add the missing ones.
Professional design is a half of website successful performance. Every text field, a button, and a picture should be placed purposefully.
We keep exploring Drupal contributions, and here’s the selection of free good-looking Drupal themes available for immediate usage. So download any and start working.
In 2014, I wrote “Three Cues from Your Character Sheet” — which was advice to players on how they could introduce roleplay elements without preparation, simply by identifying three key parts of the character sheet and using them to good effect.
It was advice intended to encourage players to roleplay even in one-shot settings, such as conventions or impromptu gaming opportunities.
To recap, the three things were: 1) You are your weapon; 2) You are your best ability (either your high score or class-granted power); 3) You are what you wear (like an actor “inhabits” a character from their costume or physical description).
I thought I’d return to this subject and guide players who are looking to dive a little deeper into their character, maybe because they ported that one-shot character into a campaign or that pop-up game developed into an ongoing arc.
Here are more things to glean from the character sheet that can guide your roleplaying.1 Raistlin’s Rasping Cough
Raistlin is the sickly ambitious mage of the Dragonlance series, famous for his rasping cough and arrogant demeanor — depictions that made the character memorable in novels by Tracy Hickman and Margaret Weis. But it was Terry Phillips, who portrayed Raistlin in Hickman’s playtest games for the series, that first gave Raistlin his rasping, sickly voice – in part, based on the character’s low constitution score.
In a longer game, consider playing up a PC’s low ability score in some fashion. Introducing a frailty into the character gives you a hook.
Now things don’t have to be roleplayed to such extremes (and it’s probably best if they aren’t). A fighter with a 9 intelligence isn’t stupid, by any means. But he might need time to ponder or figure things out. For example, the thoughtful Onion Knight Davos Seaworth rises to become counselor to Stannis Baratheon in “A Game of Thrones” in spite of being illiterate and cautious.
Low score roleplaying moments help others at the table identify in one another individual weaknesses that the party as a whole might be able to compensate for. A bard adorned in frippery — even at her best — might not sweet-talk her way past a castle guard; but if she’s in the company of the party’s imposing strong-armed swordsmen — who are without a charisma bonus between them — it provides a greater chance of success because they look like they belong.2. Deep pockets
Another defining personality characteristic is their attitude toward wealth and currency. Even though desiring more gold pieces is an almost universal trait among adventurers, a character’s starting gold amount and their subsequent approach to money handling can be telling.
Does the monk from the mountain retreat have need for a personal account, or is she more like Batman – who pours riches into a career of vengeance? Does the cleric seek donations for his church? Is the barbarian carefree with her treasure? Is the bard buying ostentatious clothes with her share, or does she accompany the rogue to the horse race track where they bet it all on a “sure thing”?
Does the character apportion a share of the loot toward a faction or organization to which they belong, to a master they apprenticed under, or to their silver-haired grandmother back in Waterdeep? Is it about sober business commitments in shipping or long-shot investments in odd inventions? Does the character hoard their money like the dragons they stole it from or is it being put to work buying better gear and exotic magics for the next adventure?
Whatever your character’s predilections might be, their attitude toward money, and their attitudes toward others who do other things with it, all reflect the character’s position and outlook. Playing that up can create “moments.” In the marketplace, for example, the sorcerer holds the party treasure and isn’t going to loosen those purse strings just because the barbarian saw something tasty served on a stick. Just like the real world, the fantasy world is made up of people who make impulsive buying decisions, who fall for get-rich-quick schemes and who are misers capable of making Scrooge blush.3. ‘I have many skills’
The familiar catchphrase of Xena: Warrior Princess (well, it’s familiar to me) draws our attention to the skill list on the character sheet. While the skills the character is most proficient at can help frame the player’s personality, it is more often the skills the character does not possess that make things interesting.
Similar to “You are your weapon,” you are your skills can be a handy prompt when roleplaying opportunities surface. Conversely, play up instances when skills outside the PC’s range also instructs.
Roleplay using skills with ranks with confidence in their competence. “I’ve got this” or “This is child’s play” come in handy here. But it’s also important to address skills the character doesn’t posses. These should be tried as shots in the dark or reflected with tentative answers, such as “What’s the worse that can happen?” Again, demonstrating frailty, weakness or lack of skill can be useful, defining the parameters within the party dynamic.
Now you’ve got three more things on the character sheet to guide your interpretation of the character. Have fun bringing them to life.
This module is to import taxonomy terms with hierarchical tree structure via csv file. Taxonomy terms can be imported with custom fields and in hierarchical tree structure.
tl;dr: Review the plan at the end directly.
Software has a changing nature; Drupal and its extensions are not the exception.
To be useful for a most of the users, those need to be on full releases, not only on the version control system; indeed the problem is not new and there is even a well-known phrase for one of its solutions: release early, release often
Therefore it is important to have a release plan.
Following after some context and reasoning, I propose a couple of practical guidelines on release schedule for contributed drupal extensions that I intend to use: release weekly until stable, then once a month following core shedule.
Software inherently tends to change, there are exceptions like embedded systems or really purpose-specific software.
Even really solid software like GNU core utils project, started on 1992, which provides tools that I consider among the most mature in the software space used daily, has 253 commits and three point releases in the last 12 months.
How much a software change depends on many factors.
I would hypothesize that the most relevant factors are the age of the project, the environment around it, and the amount of people behind it.
In this way, new projects change more than well established projects, and projects around dynamic environments which is also influenced by the amount of people around it, will also change more than the ones in environments with less participants or less technology changes.
Drupal contributed extensions are naturally mainly influenced by drupal core, so let us examine a bit how changing is Drupal core.
It is definitely on a dynamic environment, and I will argue that each major release can be considered a new project, making it really changing.
On the dynamic side, even if web standards changes slowly, and for good reasons, technologies around web tools are still constantly changing.
Drupal core project code history is now 17 years old, which seems like enough time to get into a stable state, especially if you are not yet part of the drupal community.
But the drupal project has a history on rewriting the way its internal works, which has been argued as one of the reasons why drupal can keep up with the changing environment around web technologies.
It may be also a consequence of its amazingly collaborative community.
And because of this rewriting between major versions, at least internally, each major release can be considered a new project, especially with 8.x.x.
A hint about it may be reflected in the fact that major contributors across different drupal core versions are mainly different; only a few one are as active across releases.
In consequence, drupal core is still a highly changing project, and in the same way its extensions inherit part of that changing nature; but a contributed drupal extension is not really only influenced by core.
Given the amazingly high number of written extensions, it is only natural to start depending on other software pieces and make its maintenance more effective.
For instance, currently there are 13432 and 4069, D7 and D8 compatible modules respectively.
In this way, one of the factors that will clearly influence a contributed extension is their dependencies, both inside and outside the drupal, and how changing they are.
Another factor is the amount of people behind it, not only developers, but also users reporting bugs.
For drupal contributed extensions this vary a lot, but it is usually not that big.
For all this, contributed drupal extensions are usually in a changing environment.Commits are not releases: release early, release often
As a contributed module developer myself, I will start by mea culpa.
Sometimes I wrongly assume that when a change is inside git the work is done, but that may be only true for people willing to take the extra effort to get the changes from git, or assume the consecuences of using a development release.
Commits are a developer tool inside the used version control system, but not necessarily something that is visible/usable for all.
As in many occasions, the problem is not new, and I find a pretty good answer for it on "The Cathedral and the Bazaar" chapter 2: Release early, release often.
It mainly propose that to be able to tackle enough bugs to make the software usable, the amount of releases needs to be as fast as the pace of the development, even at the cost of some stability.
I definitely recommend reading it fully for more context, and a lot more inspiring insights for any open source developer.
Granted, the answer is not a recipe, and it makes sense it is that way because it really depends on the project.
On the following lines I will propose an specific release strategy for drupal contributed extensions.
Drupal core already has a release plan, it is really detailed, so please review it if you have not done it yet.
Minor releases are approximately available every six months, but security and bugfix releases for a given minor version branch are available monthly, on third and first Wednesday respectively.
Security releases for drupal contributed extensions are published in coordination with the security team, so there is no need to plan them here, they also happen on Wednesdays.
Making it simple to remember can help maintainers stick to it, so I will also be using Wednesdays as well as the weekday for releases.The plan
I propose the following for each supported major branch in contributed extensions:
- release alpha/beta/rc weekly on Wednesdays, until a stable is ready
- release bugfix releases once stable has been reached in the same schedule than core, i.e. the first Wednesday of the month;
Looking back, it seems obvious and really simple, but if it is not documented somewhere, I will probably forget about it.
Hopefully someone else finds this useful, or even better wants to do the same.
Having a more predictable schedule always help to make better planning decisions.
I will start this week using this two guidelines and release a new version in the modules I maintain and there are pending changes to be released.Auto-notify maintainers
Notifications may help us maintainers to stick to this, but I guess the plan itself was relevant enough keep the focus of this post.
I may be exploring some solutions around it in the future.
 To reproduce statistics you can retrieve the main repository from https://git.savannah.gnu.org/cgit/coreutils.git and then run a couple of commands:
git log --oneline --all --since="1 year ago" | wc -l git log --oneline --all --since="1 year ago" --decorate | grep tag
The Calendar Links module provides calendar paths for the following:
- Google Calendar
- Yahoo! Calendar
Once installed you will need to have your module/theme use the paths or the included render element.Add To Calendar Dropdown
It includes an Add To Calendar Dropdown element. You can use the element by having your module/theme create a render element like this example: