Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 4 hours 46 min ago

SitePoint PHP Drupal: Using Ajax Forms in Drupal 8

15 May 2015 - 9:00am

In this article, I am going to show you a clean way of using the Drupal 8 Ajax API without writing one line of JavaScript code. To this end, we will go back to the first custom form we built for Drupal 8 in a previous article and Ajaxify some of its behaviour to make it more user friendly.

An updated version of this form can be found in this repository under the name DemoForm (the demo module). The code we write in this article can also be found there but in a separate branch called ajax. I recommend you clone the repo and install the module in your development environment if you want to follow along.

DemoForm

Although poorly named, the DemoForm was very helpful in illustrating the basics of writing a custom form in Drupal 8. It handles validation, configuration and exemplifies the use of the Form API in general. Of course, it focuses on the basics and has nothing spectacular going on.

If you remember, or check the code, you’ll see that the form presents a single textfield responsible for collecting an email address to be saved as configuration. The form validation is in charge of making sure that the submitted email has a .com ending (a poor attempt at that but enough to illustrate the principle of form validation). So when a user submits the form, they are saving a new email address to the configuration and get a confirmation message printed to the screen.

In this article, we will move the email validation logic to an Ajax callback so that after the user has finished typing the email address, the validation gets automagically triggered and a message printed without submitting the form. Again, there is nothing spectacular about this behaviour and you will see it quite often in forms in the wild (typically to validate usernames). But it’s a good exercise for looking at Ajax in Drupal 8.

Continue reading %Using Ajax Forms in Drupal 8%

Categories: Drupal

Another Drop in the Drupal Sea: DrupalCon LA Thursday Recap

15 May 2015 - 8:38am

There was a shortened day of sessions, finishing with the closing ceremony. In the morning I attended a discussion about documentation on D.O. I attended this session because the point of focus the group chose at my BOF was to do something to improve the documentation. The session was quite well attended, which apparently demonstrates that there's a good bit of interest in improving the documentation. So, I guess I'll be putting more of my time, energy and resources to getting involved.

read more

Categories: Drupal

Drupal Easy: DrupalEasy Podcast 154: DrupalCon Los Angeles - Day 3 Recap

15 May 2015 - 6:29am
DrupalEasy Podcast 154

Ryan managed to catch a few final interviews before leaving town on the last day of DrupalCon. He got in a traditional interview with a Blackmesh employee (who isn't Cathy Theyes), namely Jason Ford. Also is an 15 minute interview with Colleen Carrol of Palantir.net who recaps her session about Sustainable Recruiting Practices.

read more

Categories: Drupal

Paul Booker: Collecting total prices on a recipe form using field collections, JQuery / AHAH

15 May 2015 - 6:26am
(function($) { Drupal.behaviors.recipesForm = { attach: function (context, settings) { $(".field-name-field-recipe-quantity input[type=text]").focus(function() { $ingredient = $(this).parent().parent().parent().prev().find("select"); nid = $ingredient.find('option:selected').val(); //console.log(nid); $.get('/ingredient/price/get/' + nid , null, updateCost); }); $(".field-name-field-recipe-quantity input[type=text]").blur(function() { total_cost = 0; $quantity = $(this); quantity_val = $(this).val(); if (quantity_val && cost_per_kg) { var item = $(".field-name-field-recipe-cost"); $cost = $(this).parent().parent().parent().parent().find(item).find("input[type=text]"); cost_val = quantity_val * cost_per_kg; //console.log($quantity_val); //console.log($cost_per_kg); //console.log($cost_val.toFixed(2)); $cost.val(cost_val.toFixed(2)); } $('.field-name-field-recipe-cost').each(function() { //console.log(this); //console.log($(this).find("input[type=text]")); //console.log($(this).find("input[type=text]").val()); cost = $(this).find("input[type=text]").val(); total_cost = total_cost + parseFloat(cost); }); //console.log(total_cost); $total_cost = $('.field-name-field-total-cost').find("input[type=text]"); $total_cost.val(total_cost.toFixed(2)); }); $(".field-name-field-recipe-ingredient select").change(function() { nid = $(this).find('option:selected').val(); $.get('/ingredient/price/get/' + nid , null, updateCost); var item = $(".field-name-field-recipe-quantity"); $quantity = $(this).parent().parent().parent().find(item).find("input[type=text]"); //console.log($quantity); $quantity.val(0); var item = $(".field-name-field-recipe-cost"); $cost = $(this).parent().parent().parent().find(item).find("input[type=text]"); $cost.val(0); }); } }; var updateCost = function(response) { cost_per_kg = response['data']; //console.log(cost_per_kg); } })(jQuery); /** * Implements hook_menu(). */ function mymodule_menu() { $items['ingredient/price/get'] = array( 'page callback' => 'mymodule_get_ingredient_price_ajax', 'type' => MENU_CALLBACK, 'access arguments' => array('access content'), ); return $items; } /** * Callback to return JSON encoded ingredient price for given nid. */ function mymodule_get_ingredient_price_ajax($nid) { $node = node_load($nid); //print_r($node->field_cost_per_kg['und'][0]['value']); $cost_per_kg = $node->field_cost_per_kg['und'][0]['value']; drupal_json_output(array('status' => 0, 'data' => $cost_per_kg)); drupal_exit(); } function mymodule_form_recipe_sheet_node_form_alter(&$form, &$form_state, $form_id) { //dsm($form_id); //dsm($form['field_total_cost']); foreach ($form['field_collection_ingredients']['und'] as $key => &$value) { if (is_numeric($key)) { //dsm($key); //dsm($value); $value['field_recipe_cost']["#disabled"] = TRUE; } } $form['field_total_cost']["#disabled"] = TRUE; drupal_add_js(drupal_get_path('module', 'mymodule') .'/scripts/mymodule.js'); } Tags:
Categories: Drupal

Drupal Easy: DrupalEasy Podcast 153: DrupalCon Los Angeles - Day 2 Recap

15 May 2015 - 5:45am
Download Podcast 153

Ryan Mike and Ted are joined by Dave Hall, Amitai Burstein, Damien McKenna, Tess Flynn, Kelley Curry, Brian Lewis in this musical and magical Day 2 of DrupalCon in Los Angeles.

read more

Categories: Drupal

InternetDevels: Tips for Design when using Drupal

15 May 2015 - 2:33am

Meet the new blog post with tips about Drupal web design from our guest blogger Lalit Sharma, SEO consultant who runs a SEO agency.

Drupal is a popular open-source platform loved by many designers. However, there are a few golden rules to follow when designing anything for Drupal sites in order to ensure developers have an easier time coding, maintain production speeds and the client’s pocket remains relatively bulky. A few are as provided below:

Read more
Categories: Drupal

Metal Toad: Amazon CloudFront with Drupal 8

14 May 2015 - 5:04pm
Amazon CloudFront with Drupal 8 May 14th, 2015 Dylan Tack

Since I wrote my first review of CloudFront in 2012, Amazon has added support for three essential features:

What this means is that CloudFront is no longer just for static content; it's fully capable of delivering content from a dynamic CMS like Drupal. Here are the configs, step-by-step:

Configure your distribution and origin

This is fairly straightforward. I reccomend using a CNAME for your origin (which could be a single instance, or an elastic load balancer). Ideally, your origin URL should not be accessible from the open internet for serveral reasons:

  • Prevent the origin URL from getting crawled by search engines
  • Pevent DDoS attacks from being able to bypass the CDN
  • Prevent spoofing of the X-Forwarded-For header

Configure a default behavior

Noteworthy settings are:

  • "use origin cache headers" - This means CloudFront will honor the page lifetime set on /admin/config/development/performance within Drupal.
  • Whitelist "Host" and "CloudFront-Forwarded-Proto". This allows virtual hosts, and any SSL redirect logic on the origin to function correctly.
  • Whitelist your site's session cookie.

Drupal 8 workarounds

One of the remaining Drupal 8 critical issues interferes with CloudFront:
[meta] External caches mix up response formats on URLs where content negotiation is in use
As a result, some additional behaviors are needed to work around this. These settings instruct CloudFront to forward all client headers for specific paths:

Domain-sharding

If you plan to use a single domain for your entire site, you're done! On this site, we decided to keep the domain-sharding approach described in my previous post, so we need a little D8 code.

mt_custom.info.yml name: Metal Toad Custom description: Stuff that doesn't fit anywhere else. package: Custom type: module core: 8.x dependencies: mt_custom.services.yml services: mt_custom_event_subscriber: class: Drupal\mt_custom\EventSubscriber\MTCustomSubscriber arguments: ['@current_user'] tags: - {name: event_subscriber} mt_custom.module use Drupal\Component\Utility\UrlHelper;   /** * Implements hook_file_url_alter(). */ function mt_custom_file_url_alter(&$uri) {   // Route static files to Amazon CloudFront, for anonymous users only. if (\Drupal::request()->server->get('HTTP_HOST') == 'www.metaltoad.com' && \Drupal::currentUser()->isAnonymous() && !\Drupal::request()->isSecure()) {   // Multiple hostnames to parallelize downloads. $shard = crc32($uri) % 4 + 1; $cdn = "http://static$shard.metaltoad.com";   $scheme = file_uri_scheme($uri); if ($scheme == 'public') { $wrapper = file_stream_wrapper_get_instance_by_scheme('public'); $path = $wrapper->getDirectoryPath() . '/' . file_uri_target($uri); $uri = "$cdn/" . UrlHelper::encodePath($path); } else if (!$scheme && strpos($uri, '//') !== 0) { $uri = "$cdn/" . UrlHelper::encodePath($uri); } } }   /** * Implements hook_css_alter(). */ function mt_custom_css_alter(&$css) { // Mangle the paths slightly so that Drupal\Core\Asset\AssetDumper will generate // different keys on HTTPS. Necessary because CDN URL varies by protocol. if (\Drupal::request()->isSecure()) { foreach ($css as $key => $file) { if ($file['type'] === 'file') { $css[$key]['data'] = './' . $css[$key]['data']; } } } } src/EventSubscriber/MTCustomSubscriber.php namespace Drupal\mt_custom\EventSubscriber;   use Symfony\Component\HttpFoundation\RedirectResponse; use Symfony\Component\HttpKernel\Event\FilterResponseEvent; use Symfony\Component\HttpKernel\KernelEvents; use Symfony\Component\HttpKernel\Event\GetResponseEvent; use Symfony\Component\EventDispatcher\EventSubscriberInterface; use Drupal\Core\Session\AccountInterface;   class MTCustomSubscriber implements EventSubscriberInterface {   protected $account;   public function checkForCloudFront(GetResponseEvent $event) { $req = $event->getRequest();   /* * Make sure Amazon CloudFront doesn't serve dynamic content * from static*.metaltoad.com */ if (strstr($req->server->get('HTTP_HOST'), 'static')) { if (!strstr($req->getPathInfo(), 'files/styles')) { header("HTTP/1.0 404 Not Found"); print '404 Not Found'; exit(); } } }   /** * {@inheritdoc} */ static function getSubscribedEvents() { $events[KernelEvents::REQUEST][] = array('checkForCloudFront'); return $events; }   public function __construct(AccountInterface $account) { $this->account = $account; }   }
Categories: Drupal

Capgemini Engineering: Drupal integration patterns

14 May 2015 - 4:00pm

As Drupal has evolved, it has become more than just a CMS. It is now a fully fledged Web Development Platform, enabling not just sophisticated content management and digital marketing capabilities but also any number of use cases involving data modelling and integration with an endless variety of applications and services. In fact, if you need to build something which responds to an HTTP request, then you can pretty much find a way to do it in Drupal.

“Just because you can, doesn’t mean you should.”

However, the old adage is true. Just because you can use use a sledgehammer to crack a nut, that doesn’t mean you’re going to get the optimal nut-consumption-experience at the end of it.

Drupal’s flexibility can lead to a number of different integration approaches, all of which will “work”, but some will give better experiences than others.

On the well trodden development path of Drupal 8, giant steps have been taken in making the best of what is outside of the Drupal community and “getting off the island”, and exciting things are happening in making Drupal less of a sledgehammer, and more of a finely tuned nutcracker capable of cracking a variety of different nuts with ease.

In this post, I want to explore ways in which Drupal can create complex systems, and some general patterns for doing so. You’ll see a general progression in line with that of the Drupal community in general. We’ll go from doing everything in Drupal, to making the most of external services. No option is more “right” than others, but considering all the options can help make sure you pick the approach that is right for you and your use case.

Build it in Drupal

One option, and probably the first that occurs to many developers, is to implement business logic, data structures and administration of a new applications or services using Drupal and its APIs. After all, Entity API and the schema system give us the ability to model custom objects and store them in the Drupal database; Views gives us the means to retrieve that data and display it in a myriad of ways. Modules like Rules; Features and CTools provide extensive options for implementing specific business rules to model your domain specific data and application needs.

This is all well and good, and uses the strengths of Drupal core and the wide range of community contributed modules to enable the construction of complex sites with limited amounts of coding required, and little need to look outside Drupal. The downside can come when you need to scale the solution. Depending on how the functionality has been implemented you could run into performance problems caused by large numbers of modules, sub-optimal queries, or simply the amount of traffic heading to your database - which despite caching strategies, tuning and clustering is always likely to end up being the performance bottleneck of your Drupal site.

It also means your implementation is tightly coupled to Drupal - and worse, most probably the specific version of Drupal you’ve implemented. With Drupal 8 imminent this means you’re most likely increasing the amount of re-work required when you come to upgrade or migrate between versions.

It’s all PHP

Drupal sites can benefit hugely from being part of the larger PHP ecosystem. With Drush make, the Libraries API, Composer Manager, and others providing the means of pulling external, non-Drupal PHP libraries into a Drupal site, there are huge opportunities for building complexity in your Drupal solution without tying yourself to specific Drupal versions, or even to Drupal at all. This could become particularly valuable as we enter the transition period between Drupal 7 and 8.

In this scenario, custom business logic can be provided in a framework agnostic PHP library and a Naked Module approach can be used to provide the glue between that library and Drupal - utilising Composer to download and install dependencies.

This approach is becoming more and more widespread in the Drupal community with Commerce Guys (among others) taking a libraries first approach to many components of Commerce 2.x which will have generic application outside of Drupal Commerce.

The major advantage of building framework agnostic libraries is that if you ever come to re-implement something in another framework, or a new version of Drupal, the effort of migrating should be much lower.

Integrate

Building on the previous two patterns, one of Drupal’s great strengths is how easy it is to integrate with other platforms and technologies. This gives us great opportunity to implement functionality in the most appropriate technology and then simply connect to it via web services or other means.

This can be particularly useful when integrating with “internal” services - services that you don’t intend to expose to the general public (but may still be external in the sense of being SaaS platforms or other partners in a multi-supplier ecosystem). It is also a useful way to start using Drupal as a new part of your ecosystem, consuming existing services and presenting them through Drupal to minimise the amount of architectural change taking place at one time.

Building a solution in this componentised and integrated manner gives several advantages:

  • Separation of concerns - the development, deployment and management of the service can be run by a completely separate team working in a different bounded context. It also ensures logic is nicely encapsulated and can be changed without requiring multiple front-end changes.
  • Horizontal scalability - implementing services in alternate technologies lets us pick the most appropriate for scalability and resilience.
  • Reduce complex computation taking place in the web tier and let Drupal focus on delivering top quality web experience to users. For example, rather than having Drupal publish and transform data to an external platform, push the raw data into a queue which can be consumed by “non-Drupal” processes to do the transform and send.
  • Enable re-use of business logic outside of the web tier, on other platforms or with alternative front ends.
Nearly-Headless Drupal

Headless Drupal is a phrase that has gained a lot of momentum in the Drupal community - the basic concept being that Drupal purely responds with RESTful endpoints, and completely independant front-end code using frameworks such as Angular.js is used to render the data and completely separate content from presentation.

Personally, I prefer to think of a “nearly headless” approach - where Drupal is still responsible for the initial instantiation of the page, and a framework like Angular is used to control the dynamic portion of the page. This lets Drupal manage the things it’s good at, like menus, page layout and content management, whilst the “app” part is dropped into the page as another re-usable component and only takes over a part of the page.

For an example use case, you may have business requirements to provide data from a service which is also provided as an API for consumption by external parties or mobile apps. Rather than building this service in Drupal, which while possible may not provide optimal performance and management opportunities, this could be implemented as a standalone service which is called by Drupal as just another consumer of the API.

From an Angular.js (or insert frontend framework of choice) app, you would then talk directly to the API, rendering the responses dynamically on the front end, but still use Drupal to build everything and render the remaining elements of the page.

Summing up

As we’ve seen, Drupal is an incredibly powerful solution, providing the capability for highly-consolidated architectures encapsulated in a single tool, a perfect enabler for projects with low resources and rapid development timescales. It’s also able to take its place as a mature part of an enterprise architecture, with integration capabilities and rich programming APIs able to make it the hub of a Microservices or Service Oriented Architecture.

Each pattern has pros and cons, and what is “right” will vary from project to project. What is certain though, is that Drupal’s true strength is in its ability to play well with others and do so to deliver first class digital experiences.

New features in Drupal 8 will only continue to make this the case, with more tools in core to provide the ability to build rich applications, RESTful APIs for entities out of the box allowing consumption of that data on other platforms (or in a headless front-end), improved HTTP request handling with Guzzle improving options for consuming services outside of Drupal, and much more.

Drupal integration patterns was originally published by Capgemini at Capgemini on May 15, 2015.

Categories: Drupal

X-Team: DrupalCon Latin America through the eyes of an X-Teamer (Part 2)

14 May 2015 - 2:25pm

Drupal left the island. Larry Garfield brought us an awesome speech about Drupal 8, which you can see here. Dries explained to us why Drupal 8 had to change. Larry showed us those changes, and everybody loved his demo, but the important thing came after that. The inline editor, content management improvements, rendering HTML5 are...

The post DrupalCon Latin America through the eyes of an X-Teamer (Part 2) appeared first on X-Team.

Categories: Drupal

Acquia: Web Accessibility for Developers -- Part 2

14 May 2015 - 1:15pm

We’re at the halfway point of what hopefully has been a helpful guide for developers to make a website accessible for all visitors. (If you missed the first part of this two-part series, please click here.)

In this blog, we’ll review how instructional text, navigation, and other parts of development can allow those with blindness and low vision, deafness, and other disabilities to make full use of a website.

There’s a Proper Place for Instructional Text

When providing an example that will help the user fill out a field, place it after the label of the field and before the field itself. This will let the screen reader pinpoint the instructional text and leave no doubt to the user that they’re hearing an example of what’s required. For instance, an example of how to enter the country code and remaining digits of a telephone number should come just before the field.

A Search that Searches When Instructed

Many people love filters that are dynamic — offering results after each selection is made — but it’s not the best thing for a text reader. Dynamic searches cause the page to constantly refresh, leaving a visitor who’s using a text reader to wonder what’s going on. A page shouldn’t reload until the user hits a button. That means all filters and search functionality should have “submit,” “go,” and “apply” buttons.

Jump Directly to Main Content

Readers without disabilities probably take it for granted that they can jump directly to the main content on a webpage. But for those using a screen reader, they first have to listen to a long list of navigation links, icons and other elements before reaching the main content. That’s where a “skip to main content” link comes in handy. It allows a user to skip everything at the top of the page.

The good news for developers using Drupal is that the “skip to main content” link is beginning to come right out of the box and is already included in some themes. If it’s not included, don’t worry. The code in your template should look similar to:

<a id="skip-link" href="#main-content" class="element-invisible element-focusable">Skip to main content</a>.

The CSS code should make the link invisible to a sighted user but will allow a screen reader to focus on the link.

An Easier Way to Zoom and Shrink

Visually impaired people who don’t need a screen reader still may need to manipulate the size of text. They don’t always know how to use keyboard shortcuts and need a user-friendly aid. In a matter of minutes, a site administrator can plop a text-resizing module onto a Drupal webpage. Here’s a handy helper on how to do it. Just keep in mind that it doesn’t always work for menu items, but it usually does resize static text.

Know What to Show; What to Hide

CSS allows developers to change the style of a webpage and make content sparkle. But some text-based screen readers or older screen readers need to read the page with all of the styles disabled. It’s important to make sure that if the stylesheets are turned off, the screen reader will still be able to read the order of the content correctly and be able to access all functionality.

Most of the responsive Drupal themes are already providing this functionality out of the box, but this standard is important to think about, and test when choosing how you will lay out your pages.

In order to test, disable your stylesheets — as seen in this screenshot of a White House page, for instance — and scroll down the page to ensure that the content order is the same as you originally intended.

These are only a few steps that can help developers make a website accessible to all visitors. If you’d like to see more ideas — or perhaps even gain a greater understanding of Web accessibility itself — here are two resources worth checking out:

The first is a checklist of standards from Section 508 of the federal Rehabilitation Act that government agencies must follow to provide full and fair Internet access to people with disabilities. Even though only federal agencies are required to follow them, the standards serve as a thorough and detailed source of steps for businesses and organizations to use.

Another useful resource are the Web Content Accessibility Guidelines offered by the World Wide Web Consortium (WC3). The guidelines are comprehensive and should also help you on the way to creating an accessible website.

Thanks for reading. Please leave a comment below if you have other suggestions you’d like to share.

Down the road, we’ll post a companion, two-part series on accessibility for clients – stay tuned.

Tags:  acquia drupal planet
Categories: Drupal

Dave Hall Consulting: Leaking Information in Drupal URLs

14 May 2015 - 12:26pm

When a user doesn't have access to content in Drupal a 403 forbidden response is returned. This is the case out of the box for unpublished content. The problem with this is that sensitive information may be contained in the URL. A great example of this the DrupalCon site.

The way to avoid this is to use the m4032404 module which changes a 403 response to a 404. This simple module prevents your site leaking information via URLs.

AttachmentSize DrupalCon-Philadephia.png139.21 KB
Categories: Drupal

Chapter Three: Drupal 8 Automated Testing with Travis CI

14 May 2015 - 10:05am

Travis CI burst onto the hosted continous integration scene by offering free testing for public projects. If your code is on Github and available to the public then Travis will run your tests for you.



I will show you how to get Drupal 8 running all of it's PHPunit tests in Travis. If you want to use Travis for your own private repo, you will have to pay a little bit. In my opinion that is a small price to pay for never setting up Jenkins again.



First we specify our programming language and the version.




language: php

php:
- 5.4


Next up we specify our database information. Note that we do not have to specify install steps for either PHP or MySQL.

Categories: Drupal

Another Drop in the Drupal Sea: DrupalCon LA Wednesday Recap

14 May 2015 - 9:30am

After the keynote I took advantage of the opportunity to meet face to face with a new contact. Then, after lunch I headed into a couple of BOFs that were way out of my league and made my brain hurt. I finished up the day with a session that was more in my comfort zone.

I think it's good to stretch my mind and get out of my comfort zone even though it, quite honestly, left me feeling really stupid. I also felt really tired by the end of the day. So, I decided to take a pass on any social events for the evening and just relax in my hotel room.

read more

Categories: Drupal

InternetDevels: DrupalTour Zhytomyr

14 May 2015 - 6:52am

Spring time is just perfect for Drupal rides! The weather is great, drupallers are in the good mood and Drupal-van shines in the bright sun… So we decided to make a ride to Zhytomyr. And it turned out to be awesome!

We had to leave Lutsk at 7:30 AM to arrive to Zhytomyr in time. Getting up at 6 on Saturday morning is not so easy, by the way! But we actually had no other options and the trip to Zhytomyr was worth it :)

Read more
Categories: Drupal

Friendly Machine: Notes from DrupalCon Los Angeles

14 May 2015 - 6:41am

On Tuesday, Dries gave the best keynote I’ve heard him deliver. It included some very interesting Drupal history and it brought home to me how extraordinary Drupal really is. There were so many points in the project’s history when things could have happened differently - or not happened at all. To see a photo of the first DrupalCon attendees 10 years ago (27 people) while sitting among ~3000 Drupalists from around the world was pretty amazing.

There are so many people doing big, interesting things with Drupal. Despite concerns about corporate influence within the Drupal community, the project empowers a huge number of non-profits and institutions of higher education and it was great to see them so well represented here. It might be weird to talk about software as a force for good, but that’s really how I see Drupal. It makes a huge difference to a lot of organizations and the valuable work they contribute to society.

As you may have heard, there will be a DrupalCon in India next year. The city hasn’t been announced yet, but my money is on Mumbai. I’ve known two people who have traveled to India. Both said it was amazing and intense. I’m not sure if I’ll go, but I’m very tempted. I love travel, but that is one hell of a long flight (20 hours).

The sessions this year were all recorded and put on YouTube, so if you want to catch up on anything you might have missed, here’s the link. There are a few sessions I recommend you check out:

However, the biggest benefit of DrupalCon for me isn’t the sessions. It’s getting to meet people and talking with them about their projects and how they are solving the problems they encounter. To everyone that came by the Lullabot booth to chat, thank you! It was great to see you in person and I hope to chat again next year - if not sooner!

Drupal
Categories: Drupal

Acquia: Build Your Drupal 8 Team: Technical Roles and Required Skills

14 May 2015 - 6:38am

Last time, we discussed some big themes your Drupal 8 team should be synched up with, like object-oriented programming. Now we're going to drill down into more specifics on the technical side.

Is your tech team full of generalists, or do all your developers have special skill sets and focus on specific kinds of functionality, like databases or communications? Either way, someone on your team will have to fill each of these technical roles for a successful Drupal 8 project.

Drupal 8 Architect

More than anyone else on the project, the Drupal 8 architect needs to understand Drupal 8 in depth. The architect needs to make the decisions about the project's overall architecture, which requires envisioning how the system works as a whole. This is bigger than just the Drupal 8 application, because the project needs to fit into your company's entire software environment. It may need to be integrated with other corporate back-end systems, so this role needs to understand the full technical environment, not just the tech stack that comes with Drupal 8. As much as possible, this individual needs to have a strong understanding of front-end and back-end development tools in addition to a thorough understanding of how Drupal 8 works.

UI Designer

The UI designer needs to understand what the technology is capable of and how to use it to create the best experience for end users. To work with Drupal 8, the UI designer should keep building HTML, CSS and Javascript knowledge, but also develop a Drupal 8-specific understanding of how to create themes and build sites. Learning the capabilities of Twig is needed because Twig replaces PHPTemplate in the new version of Drupal. Instead of .tpl.php files, .html.twig files are needed.

Front-End Developer

All that stuff the UI designer promised the business? It's the front-end developer's job to turn that hypothetical design into a functioning interface. Like the UI designer, front end developers should enhance their knowledge of HTML, CSS and Javascript, and pick up knowledge of Twig. PHP knowledge will help also; so will knowing MySQL. The front-end developer will also want a Drupal 8-specific understanding of how to create themes and build sites, as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Back-End Developer

Clicking on website front-end elements does nothing until you implement the functionality in the back-end. You need to be able to write new functionality from scratch, building on existing components when possible. When the application needs to integrate with other systems, the back-end developer writes the code that hooks it all together into a system that functions seamlessly. This role needs some knowledge of front-end tools like HTML, CSS and JavaScript, but it also requires understanding back-end tools like PHP and MySQL in depth. For Drupal 8 knowledge, the back-end developer should focus on architecture and planning topics as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Marketing Technical Lead

The marketing technical lead owns the content publishing process. She defines the procedure for publishing content and makes sure it adheres to site standards. Because content doesn't accomplish anything unless someone sees it, the marketing technical lead needs to make sure it follows good SEO and SEM practices. It's important that the marketing tech lead keeps current with ever-changing SEO practices, and focuses on learning Drupal 8 as a content management system. Learning about the administration functions, and the kinds of changes you can make that won't require a developer to write code, will be especially useful for this role.

Next time: Non-Technical Team Roles and Required Skills for a Drupal 8 Project.

Tags:  acquia drupal planet
Categories: Drupal

Drupalize.Me: Learning To Debug: Stop Thinking and Look

14 May 2015 - 6:02am

Debugging is a discipline that requires patience, and a fervent attention to detail. In the often times fast paced world of software development, when we're faced with deadlines, and an ever growing list of new features to add, and bugs to resolve, it can be a difficult to slow down and proceed in a meticulous, measured fashion. When it comes to solving difficult problems though, this fastidious approach is exactly what's required to locate, and resolve, a problem's root cause.

Categories: Drupal

Annertech: Thoughts on DrupalCon LA's Front End Forum

14 May 2015 - 4:34am
Thoughts on DrupalCon LA's Front End Forum

At DrupalconLA, I had the opportunity to go to an Open Front End Forum, wherein people chatted about the state of the front end. It was good fun, and the moderator did a good job of keeping the conversation flowing.

First question: "Where is the line that separates front end from back end?"

There was some disagreement on that. There is a line, there is no line, it's a permeable line... Going on to explore what defined front end or backend, people cited tasks and tools like PHP, HTML/CSS/JS, the browser, Photoshop, in favour of one argument or another.

Categories: Drupal


Google+
about seo