Newsfeeds

Massive games investment, M&A, stock market rebound - by Tim Merel

Gamasutra.com Blogs - 10 October 2016 - 6:36am
Digi-Capital’s new 200+ page Games Report Q3 2016 found that games investments, M&As and stock markets delivered massive turnaround since last year - $1.6B investment and $25.7B M&A in 2016 so far, with the games stock market up 17% in the last 12 months
Categories: Game Theory & Design

How to create your own stuff: villains(PT3) - by Vitor Bulbovas

Gamasutra.com Blogs - 10 October 2016 - 6:36am
The third part of this “series”, and now talking about a subject that, for some reason, a lot of people like “villains”.
Categories: Game Theory & Design

Tako at the Tokyo Game Show: from dream to reality - by Christophe Galati

Gamasutra.com Blogs - 10 October 2016 - 6:33am
An article about my trip to Tokyo, where I introduced Tako-San to various events like Tokyo Game Show, PicoPico Cafe and Indie Stream Festival 2016. I tell how I was able to make it happen.
Categories: Game Theory & Design

Matt Glaman: Managing Your Drupal Project with Composer

Planet Drupal - 10 October 2016 - 6:15am

Drupal Commerce was started without writing any Drupal code. Our libraries set Drupal Commerce off the island before Drupal was able to support using third party library not provided by core.

Drupal now ships without third party libraries committed, fully using Composer for managing outside dependencies. However, that does not mean the community and core developers have everything figured out, quite yet.

YNACP: Yet Another Composer Post. Yes. Because as a co-maintainer of Drupal Commerce we're experiencing quite a lot of issue queue frustration. I also want to make the case of "let's make life eaiser" for working with Drupal. As you read compare the manual sans-Composer process for local development and remote deployment versus the Composer flows.

Before we begin

We're going to be discussing Composer. There's specific terminologies I'll cover first.

  • composer.json: defines metadata about the project and dependencies for the project.
  • composer.lock: metadata file containing computed information about dependencies and expected install state.
  • composer install: downloads and installs dependencies, also builds the class autoloader. If a .lock file is available it will install based off of the metadata. Otherwise it will calculated and resolve the download information for dependencies.
  • composer update: updates defined dependencies and rebuilds the lock file.
  • composer require: adds a new dependency, updates the JSON and .lock file.
  • composer remove: removes a dependency, updates the JSON and .lock file.

All Composer commands need to run in the same directory as your composer.json file.

Installing Drupal

There are multiple ways to install Drupal. This article focuses on working with Composer, for general installation help review the official documentation at https://www.drupal.org/docs/8/install

Install from packaged archive

Drupal.org has a packaging system which provides zip and tar archives. These archives come with all third party dependencies downloaded.

You download the archive, extract the contents and have an installable Drupal instance. The extracted contents will contain the vendor directory and a composer.lock file.

Install via Composer template

A community initiative was started to provide a Composer optimized project installation for Drupal. The  project provided a version of Drupal core which could be installed via Composer and a mirror of Drupal.org projects via a Composer endpoint (This has been deprecated in favor of the Drupal.org endpoint).

To get started you run the create-project command. 

composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction

This will create some-dir folder which holds the vendor directory and a web root directory (Drupal.) This will allow you to install Drupal within a subdirectory of the project, which is a common application structure.

This also keeps your third party libraries out of access from your web server.

Review the repository for documentation on how to use the project, including adding and updating core/projects: https://github.com/drupal-composer/drupal-project.

Adding dependencies to Drupal Without Composer

Modules, themes, and profiles are added to Drupal my placing them in a specific directory. This can be done by visiting Drupal.org, downloading the packaged archive and extracting it to the proper location.

There's a problem with this process: it's manual and does not ensure any of the project's dependencies were downloaded. Luckily Composer is a package and dependency manager!

With Composer

To add a dependency we use the composer require command. This will mark the dependency, download any of its own. 

Note if you did not use project base: Currently there is no out of the box way to add Drupal.org projects to a standard Drupal installation. You will need to run a command to the endpoint.

composer config repositories.drupal composer https://packages.drupal.org/8

Let's use the Panels module as an example. Running the following command would add it to your Drupal project.

composer require drupal/panels

This will install the latest stable version of the Paragraphs version. If you inspect your composer.json file you should see something like the following

"require": { "drupal/panels": "3.0-beta4", }

One of the key components is the version specification. This tells Composer what version it can install, and how it can update.

  • 3.0 will be considered a specific version and never update.
  • ~3.0 will consider any patch version as a possible installation option, such as new betas, RCs.
  • ~3 will allow any minor releases to be considered for install or update.
  • ^3.0 will match anything under the major release — allowing any minor or patch release.

You can specify version constraints when adding a dependency as well. This way you can define of you will allow minor or patch updates when updating.

composer require drupal/panels:~3.0

This will allow versions 3.0-beta5,3.0-rc1, 3.0 to be valid update versions.

Know what! The same versioning patterns exist in NPM and other package managers.

Updating dependencies Without Composer

As stated with installing dependencies, it could be done manually. But this requires knowing if any additional dependencies need to be updated. In fact, this is becoming a common issue in the Drupal.org issue queues.

With Composer

Again, this is where Composer is utilized and simplifies package management.

Going from our previous example, let's say that Paragraphs has a new patch release. We want to update it. We would run

composer update drupal/panels --with-dependencies

This will update our Drupal project and any of its dependencies. Why is this important? What if Paragraphs required the newest version of Entity Reference Revisions for a critical fix? Without a package manager, we would have not known or possibly updated.

Why we need --with-dependencies

When Composer updates a dependency, it does not automatically update its dependencies. Why? No idea, apparently the maintainers do not believe it should.

Updating Drupal core Without the Composer template

If you installed Drupal through the normal process, via an extracted archive, you have to manually update in the same fashion. You will need to remove all files provided by Drupal core — *including your possibly modified composer.json file*.

Rightly so, you can move your modified .htaccess, composer.json, or robots.txt and move them back. However, you’ll need to make sure your composer.json matches the current Drupal core’s requirements and run composer update.

That’s difficult.

The official documentation: https://www.drupal.org/docs/7/updating-your-drupal-site/update-procedure...

Updating Drupal core via the Composer template

If you have setup Drupal with the Composer template or any Composer based workflow, all you need to do is run the following command (assuming you’ve tagged the drupal/core dependency as ^8.x.x or ~8, ~8.1, ~8.2)

composer update drupal/core --with-dependencies

This will update Drupal core and its files alongside the drupal-composer/drupal-scaffold project.

Using patches with Composer

I have been a fan of using build tools with Drupal, specifically  using . However, when I first used Composer I was concerned on how to use patches or pull requests not yet merged with the project — without maintaining some kind of fork.

 create the   project. This will apply patches to your dependencies. The project’s README fully documents its use, so I’ll cover it quickly here.

Patches are stored in a patches portion of the extra schema of the JSON file.

"extra": { "patches": { "drupal/commerce”: { "#2805625: Add a new service to manage the product variation rendering": "https://www.drupal.org/files/issues/add_a_new_service_to-2805625-4.patch" } } }

This patches Drupal Commerce with a specific patch. 
   

Using GitHub PRs as a patch

Patches are great, as they let you use uncommitted functionality immediately. A problem can arise when you need code from a GitHub pull request (or so it seems.) For instance, Drupal Commerce is developed on GitHub since DrupalCI doesn’t support Composer and contributed projects yet.

Luckily we can take the PR for the issue used in the example https://github.com/drupalcommerce/commerce/pull/511 and add .patch to it to retrieve a patch file: https://github.com/drupalcommerce/commerce/pull/511.patch

We could then update our composer.json to use the pull request’s patch URL and always have up to date versions o the patch.

"extra": { "patches": { "drupal/commerce”: { "#2805625: Add a new service to manage the product variation rendering": "https://www.drupal.org/files/issues/add_a_new_service_to-2805625-4.patch" } } }
Categories: Drupal

Cryptozoic Announces Partnership to Release Train Heist

Tabletop Gaming News - 10 October 2016 - 6:00am
There’s little worse than when you find out that those you entrusted to take care of you are secretly looking to do you over. Well, the corrupt Sheriff and the rich people of Notting County are looking to do just that. They want to steal all of the townsfolk’s money. But there’s still some shining […]
Categories: Game Theory & Design

Pantheon Blog: Turn on Twig Debug Mode in Drupal 8 on Pantheon

Planet Drupal - 10 October 2016 - 6:00am
When working on Drupal 8 theming, it is very helpful to have Twig debug mode on. Debug mode will cause twig to emit a lot of interesting information about which template generated each part of the page. The instructions for enabling debug mode can be found within the comments of the default.services.yml file, among other sources. In short, all you need is the following in your services.yml file:  
Categories: Drupal

Commerce Mangopay

New Drupal Modules - 10 October 2016 - 5:20am

Commerce Mangopay integrates Mangopay with Drupal Commerce 2.x payment

Categories: Drupal

Simpleform

New Drupal Modules - 10 October 2016 - 5:02am
Categories: Drupal

PHPVideoToolkit Library

New Drupal Modules - 10 October 2016 - 3:42am

API module to include the phpvideotoolkit library.

Categories: Drupal

Video embed local

New Drupal Modules - 10 October 2016 - 2:19am

An integration for local videos into Video Embed Field.

Install and enable the PHPVideoToolkit Library module for thumbnail support.

Categories: Drupal

Paul Johnson: Help Dries crowdsource Drupal 8 success stories

Planet Drupal - 10 October 2016 - 2:14am

In little over a month Drupal 8 will be one year old. To mark this momentous occasion Dries Buytaert, Drupal’s founder, will champion noteworthy web sites and applications powered by Drupal 8.

Have you launched a Drupal 8 web site or application this year? Dries would like to hear from you. We’ve prepared a short web form so you can tell him your Drupal 8 success story.

Please spread the word

To reach the widest potential audience and capture the very best examples I encourage your to share this blog post with colleagues, peers, clients. Please email, share on social media, speak to your clients.

Beyond the Drupal shops developing applications our objective is to attract submissions from end users using Drupal 8. If you represent an organisation, enterprise, SME, startup, manufacturer, government department (and more) using Drupal 8 we want to hear from you.

So tell the world, complete the short form and help us celebrate Drupal 8.

Deadline for submissions is November 11th.

Categories: Drupal

1982-1987 - The Birth of Japanese RPGs, re-told in 15 Games - by Felipe Pepe

Gamasutra.com Blogs - 10 October 2016 - 12:44am
A look at the roots of Japanese RPGs – from the hardware to the early proto-RPGs, the Ultima-clones, the first Action-RPGs and genre landmarks like Dragon Quest, Final Fantasy and Ys.
Categories: Game Theory & Design

Troy’s Crock Pot: Tinkering With the D&D Ranger

Gnome Stew - 10 October 2016 - 12:01am

Regardless of the edition of Dungeons and Dragons, it seems that no class invites revision faster than the ranger. It’s seen variously as under-powered or overpowered; too much of this, too little of that; or in flavor and concept, failing to match up with someone’s idea of what the prototypical ranger is.

Should the ranger be more like Aragorn, Calamity Jane, Drizzt, Sheena, William Tell, Van Helsing, Robin Hood or Atalanta?

While we’re discussing literary and folklore archetypes, where did all those spells come from? Robin Goodfellow or Puck, I suppose.

And speaking plainly, many GMs know from experience that any version that includes an animal companion class feature is one that potentially disrupts party balance; essentially a player starts running two characters — the ranger and the companion — shifting the focus of play,  especially combat, entirely on them. To address that, many GMs create homebrew alternatives to the ranger.

So, it comes with little surprise that in its Unearthed Arcana series at the D&D website, the Fifth Edition ranger has received its second suggested revision (with at least one more guaranteed).

It reminds me of the Third Edition days, when Monte Cook released his version of the ranger online, then the Scout class came out in Complete Adventurer, the ranger as prestige class was presented in the 3.0 Unearthed Arcana and then Pathfinder tackled the ranger, which added abilities to all those “dead” levels.

And that’s really just the tip of the iceberg of tinkering with the ranger.

In this current iteration, the designers say that player feedback from playtesting and conversations on social media is driving the revision process. It will be interesting to watch as it develops.

I think no class illustrates the tension that exists between the sorts of players that desire a character that can act independently of the group — handling a combat entirely on its own — and those that want to work within the group dynamic as a supporting character with the ability to navigate a wilderness setting as the ranger.

I’m not sure there is a class that can be designed that meets the expectations of both ends of the spectrum.

Troy’s quick fix

To be honest, I thought I’d long ago given up creating new classes in the d20 sphere. There’s plenty already out there. And frankly, my goal in designing classes has never been to present a baseline version of a class. Rather, I’ve built classes that I think fit the theme of a particular type of game.

I’ve always believed a ranger should be martial in character, but grouped thematically with its Celtic cousins, the bard and the druid (and, occasionally, the barbarian).

With that in mind, here’s my ranger under the Fifth Edition rules, a martial wilderness champion. It’s hardly definitive, but I think it’s playable.

  1. Use the class features, hit points, proficiencies and equipment lists of a ranger.
  2. Build using the level progression table of a fighter, with these exceptions:

1st, player has choice of Favored Enemy ability of a ranger or Second Wind ability of a fighter.

2nd, Natural Explorer ability of the ranger replaces Action Surge of a fighter.

3rd, 7th, 15th and 18th levels, instead of a martial archetype feature, that player selects either the Hunter or Beast Master ranger archetype.

9th, substitute Indomitable with Land’s Stride.

11th, select Extra Attack (2) or Hide In Plain Sight.

13th, in addition to Indomitable, gain Vanish

17th, substitute Action Surge with Feral Sense, gain Indomitable (2)

20th, select Extra Attack (3) or Foe Slayer (if it has Favored Enemy)

Let me know what you think of this straight-forward revision, which ditches spells in favor of a martial build. Or chime in with your experiences of player characters who bring the ranger to the table. I’d especially like to hear stories of players who maximize the ranger abilities while still working in concert with the other players at the table. But if you have a cautionary tale to share, too, feel free to add that.

 

Categories: Game Theory & Design

Fuzzy Thinking: Role Collecting Games

RPGNet - 10 October 2016 - 12:00am
Fuzzy shelves.
Categories: Game Theory & Design

Enzolutions: A week in Paris

Planet Drupal - 9 October 2016 - 5:00pm

Last week I had the opportunity of visit Paris, France for a week as para of my tour Around the Drupal world in 140+ days.

Sadly for me, I got a #drupalflu in Drupal Con, Dublin; So I wasn't in the best shape to enjoy the city.

I want to say thank you to Sebastien Lissarrague and his family for allowing me to stay with them in their home.

During my visit, I had the opportunity to participate in the local Drupal Meetup of Paris community.

Also, I visited some companies like Koriolis, Sensio Labs and Platform.sh.

At Koriolis I have the opportunity to show the owner and developers the Drupal Console project to accelerate the Drupal 8 adoption in their projects.

During my visit to Sensio Labs I had a session with part the Symfony Core development team, to show them how we have been using the Symfony Console in Drupal Console project.

During my visit at Platform.sh I learn I little bit how they enable to their Drupal 8 user the usage of Drupal Console project. Next week I will write an articule about that.

About the city, I think anything that I could say about Paris will be nothing compare how beautiful it's; I just could recommend you to visit three mandatory places in you visit.

Eiffel Tower

Louvre Museum

/Palace_of_Versailles

Airplane Distance (Kilometers) Dublin , Ireland → Paris, France → San Jose, Costa Rica 9.957 Previously 96,604 Total 106.561 Walking Distance (steps) Dublin 116.133 Previously 1.780.955 Total 1.897.088 Train Distance (Kilometers) Today 0 Previously 528 Total 528 Bus/Car Distance (Kilometers) Today 0 Previously 2.944 Total 2.944
Categories: Drupal

MissPlete

New Drupal Modules - 9 October 2016 - 11:41am

Drupal integration for MissPlete: a misspelling-tolerant autocomplete in less than 220 lines, no-dependencies.

MissPlete is a misspelling-tolerant autocomplete written in ECMAScript 2015, aka ECMAScript 6 (ES6).

It supports synonyms and it can be customized with any algorithm to select and sort the completions. By default it uses a Jaro–Winkler distance algorithm, which allows for better sloppy interaction than the usual completion based on exact substring matches.

Categories: Drupal

Steve Purkiss: Leapfrog the Drupal Learning Curve & Architect the Perfect Solution in 3 Simple Steps

Planet Drupal - 9 October 2016 - 6:06am
Leapfrog the Drupal Learning Curve & Architect the Perfect Solution in 3 Simple Steps Steve Purkiss Sun, 10/09/2016 - 14:06

"Drupal has a steep learning curve" is something I hear time and again, however I feel this is a misguided perception and something we need to work towards changing - especially now focus is on the adoption journey. Learning how to 'Drupal' is actually incredibly easy - the trick is to understand exactly what Drupal is and how to mould it to your needs - this is what I'm going to show you how to do in three simple steps.

Step 1: Discover what Drupal doesn't know

This is by far the most important step of the process, hence why I go into much further detail than the other two - skim if you so wish but I assure you the story is there for a reason!

We've been here before

As of writing, Drupal has been around for 15 years and has solved many problems associated with building a wide range of web sites and applications, embedding this knowledge in either the core Drupal distribution or one of the 35,000+ modules available on the drupal.org site. Drupal's decision to only provide backwards-compatibility for content and not functionality means this functionality has had the ability to improve over time and make the most of innovation in technology, for example the recent big jump from mostly procedural programming to object-oriented.

A note about the jump from procedural to object orientation

This latest jump was a big one - Drupal was developed before object orientation was available in PHP (the language Drupal is written in), and so developed its own system of 'hooks'. You use hooks to interact with Drupal core to override functionality in order to make Drupal do what you want it to do for you. You can think of hooks like the ones on a coat stand - the trouble here was as different modules and themes overrode hooks, like an overloaded coat stand with many different coats on each hook, it became increasingly harder to work out what hook was changing what and when in the process it was changing it.

There are still hooks in Drupal 8, but these may disappear in future versions of Drupal as the migration to object-orientation continues. An added benefit is more backwards compatibility than before for future versions, so the change between versions 8 and 9 shouldn't be as pronounced as the change from 7 to 8 as we don't have to perform again such a big move as changing the fundamental way the entire code works. I believe there's plans to support backwards compatibility over two major versions from now on, so 9 will be backwards compatible with 8, 10 with 9, but not 10 with 8 - YMMV, etc.!

Knowledge carried throughout generations Courtesy @sgrame: https://twitter.com/sgrame/status/774232084231680000

The key point to understand here is what Drupal brings along with it as it progresses from version to version. Whilst the underlying code may change in order to improve and make the most of the latest innovation in programming languages, the knowledge, experience, and best practices gained and shared from its deployment to millions of sites is maintained in the API and module layer. It is unlikely what you are trying to build is unknown to Drupal in some way or another, it has dealt with everything from simple brochureware sites which look the same to everyone to sites such as weather.com where everyone who visits sees a personalised version of the site. As I often like to quip, I've never been asked for Rocket Science and even if I was, NASA uses Drupal ;)

This development process is fundamentally different to how other systems on the market work, with many other popular ones focusing on ease of use at the expense of progressive innovation, and is why you see Drupal have a larger share of the market on sites with complex requirements. The adoption of semantic versioning means there are now minor releases which include bug fixes along with both new and experimental functionality, and a new version of Drupal is released every six months. We are already up to version 8.2, and with current focus on 'outside-in' it is becoming easier for people used to systems other than Drupal - or none at all - to use Drupal, however it is not easy to visualise your end goal and know how to get there, or there is a module or modules already out there which could help you along the way to achieve your desired outcome without having to code anew.

To help overcome this out-of-the-box experience there are many ongoing initiatives to provide default content, make module discovery easier, build focused distributions, etc. but they will all take time. There is a way to approach development which means you don't end up going down the wrong path or developing functionality which already exists, it is to discover what exactly it is you want to build Drupal doesn't already know about and focus only on functionality required which is specific to your situation and no other.

What makes you different?

I recently provided the architecture for a high-profile specialist travel site - a six-figure project which unfortunately as with many projects I'm involved in I'm under non-disclosure agreements, doesn't mean I can't talk about the approach I took though, and this is a particularly good example.

As they were merging a number of existing systems I could've just looked at the existing data, however there is nothing to say those systems were designed well and we don't want to fall into the trap which I see many times where people re-create bad systems. Drupal is a very flexible system, many others require you to fit your data into how they work. So by asking the client to explain how their organisation worked and what was different about themselves as opposed to other similar organisations I discovered there were six distinct areas:

  1. Activity - their offerings were split into distinct activity types
  2. Resorts - they operate their own resorts
  3. Accommodation - each resort contains one or more different types of accommodation
  4. Region - the organisation had their own definition of a region, some spanning more than one country
  5. Departure Gateways - they fly out from a limited number of airports
  6. Arrival Gateways - resorts are serviced by one or more local airports

Everything else on the system was something Drupal would have dealt with before in one way or another - number of rooms, features of accommodation and resorts, and so on. These could easily be achieved using fields, taxonomy terms, and everything else Drupal provides out-of-the-box.

Design with the future in mind

I also took the time to observe the operations of the organisation as I walked around their office. I noticed the majority of people were answering calls, so I asked what exactly they had to deal with on the phone - people wanting more information on particular deals, issues with accommodation crop up from time to time - all the usual a travel company would have to deal with but more so here as they owned and operated the resorts. The point here is there's a whole wealth of user requirements contained here which although weren't in the scope of this current phase of development, by having them in mind when designing a system it should make it easier to extend to accommodate their needs as and when budgets and time allow.

If you only design a system for buying via the web you may find when a member of staff is trying to help a customer on the phone the process is unnecessarily complicated, or extending the system to cope with this new use case is particularly hard if you haven't taken this scenario into consideration to start with. Not to say it can't be done, and is easier to adapt now Drupal 8 is more object-oriented, but it's always good to have the future in mind - some of this you will be able to see, some you'll need to extract from key stakeholders, you'll be surprised sometimes with what you find out which you'll then be glad you asked. Here I knew the latest version of Commerce for Drupal 8 has the ability to set up different buying processes so it would be able to cope easily with phone orders if it were ever a requirement.

Design for different rates of change

It is feasible I could've used Drupal's built-in content types to build the system, but this would've limited the system to this particular use-case, making it harder to cope with different buying processes like the one mentioned above. It also did not sound right - an "airport" isn't a content type, it's an entity. It has content - facilities etc. but the thing itself is an entity. So I created six custom entities, and it sounded much better especially when you went to create a view - "list accommodation in resort". By simply teaching Drupal what was different about this particular organisation, we extended Drupal's "knowledge" and leveraged everything else it had to offer to deal with the functionality it does know about, like date ranges, durations, prices, and so on.

Whilst the front-end of a website may go through many enhancements and refreshes, the core business model of an organisation - especially one such as this which is well-established and operated for many years, does not change as much, if at all. In this example they mentioned they may add new activities, and they offered packages which covered more than one activity but their current system couldn't cope with this, which is why activity was treated as a separate entity.

By encoding the core business model of an organisation as high up the chain as you can with Drupal, you end up with a far more flexible system to cope with the faster-moving changes such as views to list out particular promotions, plus ensure longevity by enabling future development of those core parts of the system. I also wanted to make it a little more difficult for them to change any of this as this is critical to the operation of the organisation, so if changes were needed they would have to go through a harder process than changing a view, but there should be a good reason for any changes needed to the core business model so happy with the custom entity approach taken.

Seeing the wood for the trees

It's not only when architecting systems you need to take this approach to Drupal - another small example is when I helped someone out a couple of weeks back who was having problems getting a product listing displaying exactly how he wanted it to using Drupal 7. He had tried a number of different types of views (Drupal's user interface for manipulating database queries) but none of them would do what he wanted, which was to provide a faceted search facility, listing the results grouped by category. You'll see this functionality on most e-commerce sites these days, for example click on Televisions and it'll provide you a list grouped by manufacturer, or perhaps size - the point is it's not Rocket Science, it's been done before, it shouldn't be hard to do, so something else was causing the issue here. Sometimes it's hard to see the wood for the trees, so you need to take a step back and take a logical think about the situation.

We delved into the problem and through a series of questions worked out the thing he wanted to do which was different was he wanted a number of fields to be displayed at the group level - the name of the group, an image, and a description. None of the various combinations of views he had tried provided the ability to display more than one field, and rewriting the field output in the view did not apply to group by fields. Although there are a number of ways to achieve this from different parts of Drupal, I implemented the simplest way I knew which was to output the taxonomy term ID as the field to group by, and overwrite the template in order to load the details of the taxonomy term so we could easily grab the fields we needed.

I can almost hear others screaming at me to use display modes or some other functionality available as I'm sure there's other ways this can be achieved which are 'better', however as I spend most of my time dealing with back-end issues and not front-end and as we only had limited time and budget to solve the issue, this worked as a solution for the situation at hand so we went with it.

The take-away here is to go with what solves the majority of the problem, the thing you see or can imagine seeing other people using, and focus on what is specific to your needs. Faceted searching, listing products, grouping products by category - all standard functionality and should be simple to achieve in Drupal. Outputting multiple fields for a grouping category title? Not so much.

Step 2: Modularise Your Requirements

Drupal is a modular system, so you need to modularise your requirements by breaking them down as much as you can. Yes, what you're wanting to do has more than likely been done before, but maybe not in your exact combination - if it has then cool, you don't have to do anything as there's already a module/distribution/theme/etc. out there for you! Many times there isn't though, and every organisation has their differences, so you need to break your requirements down in order to deal with them successfully.

In our example above where we have a faceted search listing out products grouped by category, by splitting it up into "faceted search", "list products", and "group a view by category" we are going to get much better results when searching for answers than if we search for "faceted search grouped by taxonomy", which is more specific to our use-case than the majority of uses. You're more likely to end up with someone else's specific situation who also has had issues solving it and may forever skip past the actual solutions you are looking for. Be as generic as you can with generic requirements, then be as specific as you can with the ones you identified as particular to your situation, in this example we could've searched for "override view field output" and it would've brought us results for how to override using views templates, which is how we solved the problem there.

Once you align your vocabulary more closely with Drupal's generic, modular functionality, you'll enjoy much more success with your searches - it takes a little logical thought and remembering it's not Rocket Science! Far too many times I've seen sites where little or no research has been done as to what's already out there and people have essentially forked Drupal, creating their own monster significantly increasing the amount of work it takes to maintain and extend the site when it's not necessary.

Every line of code you produce is technical debt - even if you decide not to use the module you find which does what you need or part of what you need, you can study the tried-and-tested code, copy it into your module and use as a base for your work. A good example is detailed in my previous blog post about creating a Drupal Console command where I found code which did some of what I wanted so I based my work on it because I knew what had already been written worked and there was no point in me writing it again.

Step 3: Only Develop Specifics, Share Where Possible & Grow Drupal!

If you find you have to develop specific functionality for your site, have a think about if it would be of use to anyone else, or whether you're going to be the only person in the world doing this specific thing. As mentioned above, every line of code you write is something you or your client is going to need to support your/themselves. If you publish a module to the drupal.org module repository you not only have the possibility of others sharing the maintenance of the code but they may also provide enhancements, and stable module releases are covered by the security advisory policy which doesn't mean they secure your module, but if an exploit is found and reported the 40+ strong Drupal Security Team are there to help. Even if you just create a sandbox project you may discover others find the code useful and provide feedback.

If you're working for a client and they are worried about sharing code, or you're the end client and worry about losing competitive advantage, remember software is easy to copy and it's the rest of what you do which sets you apart from your competition. In our travel example above, it's the resorts they own which provide the value to the customer, not the software code which enables people to book a stay in them.

Currently there is a lack of sharing code on the implementation side - there's a lot of factors for this including competition between suppliers, infrastructure ease of use or lack thereof, and a general lack of co-operation in some industries. The result is many people end up writing similar code when they could be starting at a higher level, collaborating with industry peers, sharing development and maintenance costs, and going towards pushing the Drupal project forward. The more we can do out-of-the-box, the better it gets for all concerned as projects cost less, launch quicker, and we can focus on code which isn't out there already which is specific to the organisation itself, so spending the development budget on genuinely useful code instead of code which could be freely available to us in the first instance. Remembering how much we started with for free may be of help creating impetus to share any code we develop.

Although my site here doesn't do much functionally I haven't had to write a single line of code to be able to use the web to communicate my message to you, something I believe is amazeballs! Drupal can and does provide code for generic websites, however it's up to industries to collaborate and build their modules and distributions, and/or some enterprising people to build code and distributions for them, as we see in some areas such as e-learning and government.

I'm honestly shocked when I hear projects haven't contributed any code back, especially larger projects lasting longer than a year - I worry about how much technical debt they've incurred and feel sorry they haven't helped Drupal to grow, it's only by contributing code the Drupal product itself has reached this amazing level of innovation. I understand there are reasons, however I never see it as "contribution", more akin to riding a bicycle - I can stare at it as long as I like but until I push my feet down on the pedal it's not going to take me anywhere, I don't call it "contribution", just how the bike works!

I hope this post has been of help, do feel free to comment below, or get in touch with me if I can be of help with anything specific.

Happy Drupaling!

Main Drupal 8 Learning Curve image courtesy @sgrame. Other images attributed inline, the rest are public domain, found on pixabay.

Category Tutorials Tags Add new comment
Categories: Drupal

Video Game Deep Cuts: Super Potato Esther Manhole - by Simon Carless

Gamasutra.com Blogs - 9 October 2016 - 4:58am
The latest Video Game Deep Cuts selection, picking some of the smartest longform video game articles and videos of the week, looks at the Japanese game stores gone wrong, Dear Esther & game design, a retrospective of The Manhole, & more.
Categories: Game Theory & Design

Rob Bayliss: A Scalable Pattern for Displaying Simple Remote Data in Drupal 8

Planet Drupal - 8 October 2016 - 1:19pm

Let's imagine a scenario where you need to display some data from a remote service to the user. Instagram, for example. You want to grab the 6 most recent posts, pass them through some theming, then output them into a block. How would you go about doing that? In Drupal 7, one possible approach might look like this.

Categories: Drupal

Review Roundup

Tabletop Gaming News - 8 October 2016 - 11:00am
Weeeeeeeekeeeeeeeend! Wooooooooo! Always a fan of the weekend, as you all know. Today I’m just kind of hanging out before going to a friend’s birthday party later. Should be a good time had by all. But at the moment, I’m bringing you those review articles that I know you so desperately desire. Today we have: […]
Categories: Game Theory & Design

Pages

Subscribe to As If Productions aggregator