Planet Drupal

Subscribe to flux Planet Drupal - aggregated feeds in category Planet Drupal
Mis à jour : il y a 4 min 42 sec

OSTraining: "No front page content has been created yet" in Drupal

lun, 03/08/2015 - 19:44

When you first load up a new Drupal site, you will a screen like the one below.

On the front page of your site will be this message: "No front page content has been created yet".

Catégories: Elsewhere

DrupalCon News: Training Spotlight: Drupal 8 Theming

lun, 03/08/2015 - 19:29

With the Drupal 8 release just around the corner, now is the time to learn about the major changes it will bring for themers. For example, TWIG will be the default theme engine and thus you need to be familiar with its templating syntax. Other new hot features worth exploring are YAML config files, breakpoints, library management etc. Join this class and learn all you need to know to create your own theme in Drupal 8.

Catégories: Elsewhere

Drupal core announcements: No Drupal 6 or Drupal 7 core release on Wednesday, August 5

lun, 03/08/2015 - 16:59

The monthly Drupal core bug fix/feature release window is scheduled for this Wednesday. However, there have not been enough changes to the development version since the last bug fix/feature release to warrant a new release, so there will be no Drupal core release on that date. A Drupal 7 bug fix/feature release during the September window is likely instead.

Upcoming release windows include:

  • Wednesday, August 19 (security release window)
  • Wednesday, September 2 (bug fix/feature release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Catégories: Elsewhere

EchoDitto Tech Blog: Drupal 8? Drupal, Wait

lun, 03/08/2015 - 16:16

If you’ve been following the Drupal community, you’re probably well aware of the impending arrival of Drupal 8. And if you’ve been following the Drupal community closely, you’ve probably been anxiously awaiting D8 since late 2012.

Well, we’re happy to say that the wait is over...sort of. D8 was technically released (in initial beta form) in October 2014. And while a lot of us here at Echo have gotten our hands on it and taken it out for a few spins, don’t expect to see any D8 sites flying out our doors anytime soon.

What’s the Hold Up?

The biggest problem is simply that Drupal 8 isn’t ready. Even Dries Buytaert, the creator of Drupal, said this year at DrupalCon Los Angeles that he doesn’t recommend using Drupal 8 for production websites yet. That’s not to say you couldn’t make a website using D8 if you really wanted to, but it would be a time-consuming and risky proposition: your developers would have to account for the steady stream of changes being made to D8 as the community addresses remaining bugs, and these core updates could trigger nasty bugs that could take down your whole site.

Trying to bring an old site into D8 would be harder still—the upgrade path isn’t fully supported, meaning you wouldn’t be able to move cleanly from a D6 or 7 site straight to D8. In addition, as of July 20, there are still a dozen critical D8 bugs left published on—down from the 28 that remained when Dries gave his keynote speech but still not the zero required for an official release candidate.

So when will it be ready? “The reality is, it’s done when it’s done,” says Dries. He and the other contributors’ stretch goal is to have the first official release available by the time Drupalcon Barcelona rolls around in mid-September, but in all likelihood, it’ll be closer to early 2016.

From what we’ve seen in our testing here at Echo, we have to say: D8 looks pretty sweet. Built-in Views integration, Twig support, and improved admin tools are among the many features we and a lot of Drupal developers have been awaiting for a long time. We’re hoping to start building our first D8 sites between late this year and early next year, but like Dries said—“It’s ready when it’s ready.”

Tags: drupaldrupal 8development
Catégories: Elsewhere

OpenConcept: An overview of software testing

lun, 03/08/2015 - 15:31

"Software testing" is a term used to refer to a variety of methods, tools, and practices for verifying that a software application works, at many different levels.

All of us in the web development industry do some sort of software testing (even if the testing we do is manual and ad hoc, e.g.: refreshing a webpage after making a change to ensure the code you just wrote works). In this blog post, I will attempt to discuss why you might want to move away from ad hoc testing to more-formal testing, try to dispel some myths about formal testing, and give a high-level overview of the different ways that software can be tested, and the different levels of software testing that exist.

First: a disclaimer — I am not a software testing expert, and to a large extent, I wrote this to help wrap my head around software testing. Also, trying to fit complex, multi-faceted things into neat boxes is difficult (and/or controversial), so be aware that others might classify testing differently. If you find out mistakes or agree/disagree with my categorizations, please let me know in the comments below.

This blog post assumes that:

  • you work in the software development industry, and,
  • you've done manual, ad hoc tests at some point (and have an idea of why they are important).
What do you mean by formal tests?

This blog article considers "formal" tests to be tests which are recorded in some way so that other people (i.e.: not the original developer) or software can run them at any time.

Why test formally?

Software testing is an important tool with benefits such as:

  • a "safety net" to ensure each subsequent change to a program doesn't cause a regression or loss-of-functionality,
  • a "sanity check" to ensure that the code written meets the expectations / requirements of the client and your peers,
  • a way to ensure that your code is not too tightly coupled to a particular set of assumptions or use-case (this evolves naturally as you learn to write testable code),
  • a collaboration tool to ensure that someone else's work doesn't inadvertently break your work and vice-versa,
  • a portability check to ensure that code works outside of your specific environment's assumptions, and even,
  • a way to ensure that time is not wasted over-engineering solutions to problems.

Depending on the nature of your work and clients, manual ad hoc testing might be sufficient for a while.

However, as projects, development time, product lifecycles, and/or consequences-of-failure grow in size, complexity, and budget, the benefits listed above become increasingly important to limit the risk of client dissatisfaction, going overbudget, getting stuck in development/bug-fixing hell, and/or the risk of producing software that requires a high level of skilled maintenance to continue functioning.

Formalizing these tests (even manual tests) by recording them in some way allows you to run them the same way every time you run them, ensuring you don't forget something important. It also allows your co-workers to run them if you're busy, or computers to run them if they're automated. And, formal manual test cases can usually be converted to automated tests with little effort.

Myths of formal testing
Myth: Writing formal software tests isn't worth the cost.
While it certainly takes a while for new testers to get used to how testing works, and it is possible to write too many tests, even a little bit of testing can greatly reduce development time later in the development cycle, both before the product is launched, and during maintenance later on. Acceptance and refinement tests specifically (see below) can also help to give all involved parties a sense of what needs to be focused on, reducing project management time, wasted development time, and the risk of producing a product that clients (or in the case of a website, the general public) doesn't want or cannot use.
Myth: Formal software tests must be written only by software developers.
While developers must write certain tests, and are typically capable of writing most (if not all) types of tests, there are certain types of software tests which are better written by product owners, clients, testers, developers, and designers.
Myth: Most tests should be written after the system is (mostly) functionally-complete.
While the Waterfall software development model states this, the reality is that the earlier you start testing, the earlier you find and correct bugs, missing functionality, architecture problems, and usability issues.
A brief note about test-driven development (TDD)

A powerful way to write software is using Test-Driven Development (TDD). Simply put, TDD is the practice of writing tests first (so your intents are clearly stated), then writing the code to meet the requirements of the test. Test-driven development is applicable to all areas of software testing, except, perhaps, certain types of refinement tests.

Test-driven development has two distinct advantages:

  1. it ensures that everything you write from the point when you start using TDD is well-tested ("has good test coverage"), and,
  2. if you follow the TDD principle to stop developing when the tests pass, you can ensure that you don't waste time over-engineering solutions to problems.

I highly recommend reading Test-Driven Development By Example by Kent Beck (Addison-Wesley, 2003).

Classifying tests

All types of software tests can be classified as white-box, black-box, or grey-box:

White-box tests
Clear-box tests
Tests written to test the internal structure of something, as opposed to it's functionality. Named because you typically look at the code you're testing, and write your tests to target it.
Black-box tests
Tests written to test the functionality of something, as opposed to it's internal structure. Named because you typically (pretend that) you know nothing about the implementation of something, and write your tests to do what you'd expect it to do.
Grey-box tests
A combination of white- and black-box testing, used to test for improper structure or usage defects.
Levels of software testing

I group software testing into five main levels,

  1. Unit tests,
  2. Integration tests,
  3. Acceptance tests,
  4. Refinement tests, and,
  5. System tests.

Generally, the number of tests decrease; but the coverage scope, run-time, effort and cost of the tests increase as you go down the list (i.e.: in a well tested system, there are many unit-tests, each covering a small scope (e.g.: a single function), but few system tests, each covering a wide scope (e.g.: many objects, functions, and subsystems working together as-intended)).

To help you keep track of all these things, I've put together a software testing cheat sheet for you to download. The cheatsheet's source code is on Github, so feel free to improve it!

Unit tests

Unit tests are typically white-box tests to cover edge-cases and code branches (code paths) in a limited scope, typically on a per-function level. Each function typically has one or more unit tests that focus on ensuring each code path functions in the expected manner. Small changes to the code under test typically require changes to the unit tests to incorporate the new changes and ensure new code paths are covered.

Unit tests are typically short and quickly-written by the software developer who is writing the code under test, using carefully-chosen test parameters (typically edge-cases); by checking pre- and post-conditions, state-changes, and output; and by mocking dependencies to ensure that the test only covers the function under test.

Ideally, unit tests are written before the function(s) they test (i.e.: following Test Driven Development principles). If writing and performing unit tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for unit testing are:

  • phpUnit, RSpec, Jasmine, QUnit, Unit.js, etc. (sometimes collectively referred to as xUnit because many follow a naming pattern of <language abbreviation>Unit).
    • Note that SimpleTest in Drupal 6 contrib and in Drupal 7 core can be used to do unit tests, but it's not very good at it, so it's been replaced with phpUnit in Drupal 8.
  • Mock objects (e.g.: Hamcrest).

... note that many of the key technologies can also be used for integration and acceptance (behaviour) testing.

Other names for unit tests are:

  • component tests

Some books on unit tests and mock objects that I've read and recommend are:

Integration tests

Integration tests are typically grey-box tests to cover interactions between objects and interfaces, on a limited scope, typically on a per-object or per-subsystem level. Each object and subsystem typically has one or more integration tests that focus on ensuring the object/subsystem interacts with it's dependencies in the expected manner. Small changes to the code under test might require changes to the integration tests, especially when they change the way an object/subsystem interacts with other objects/subsystems.

Integration tests are typically medium-length and quickly-written by the software developer who is writing the object/subsystem code, by checking success and failure states, how they interact with other components (through mock objects), what they accept as input, what they produce as outputs. Mocking dependencies, shared resources and inter-process-communication is common practice at this level.

Ideally, integration tests are written before the object(s) they test (i.e.: following TDD principles). If writing and performing integration tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for integration testing are:

... again, because unit tests and integration tests are so similar, they share a lot of the same technologies.

Other names for integration tests are:

  • integration & testing (I&T)

Some books on unit tests and mock objects that I've read and recommend are:

Acceptance tests

Acceptance tests are typically black-box tests to cover how a user moves through a system on a broader scope, typically at the user-interface level. Each user-interface display typically has a number of acceptance tests that focus on ensuring the user can complete a certain set of tasks using that display, that the display functions correctly, and that it meets the client's requirements. Small changes to the code under test only require changes to the acceptance tests if the changes affect the user interface.

Acceptance tests are typically short and written by the product owner, client, tester, or in some cases, the developer, by looking at the user story / ticket and outlining the steps the user must take to complete the requested functionality.

Ideally, acceptance tests are written by the client, or product owner before the UI is developed and any work is done. If writing and performing acceptance tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Ideally, parameters for accessibility testing (i.e.: level of conformance) and browser testing (i.e.: list of supported browsers) should be defined by the client before any work is done; and the latest these should be defined is before any work is started.

Key technologies for acceptance testing are:

  • Manual tests (using manual test cases).
  • The Gherkin domain-specific language.
    • Tests written in Gherkin are turned into mouse clicks, keystrokes, etc. by interpreters (e.g.: Behat, Cucumber, SpecFlow).
      • These interpreters forward these mouse clicks, keystrokes, etc. through controllers (e.g.: Mink, Webdriver, CasperJS) to browsers.
        • Controllers like Mink or Webdriver then control:
    • Behavioural output from browsers is usually forwarded back to the Gherkin interpreters for analysis.
    • Visual output from browsers can be forwarded to visual regression tools (e.g.: the Galen framework).
  • SimpleTest in Drupal 6 contrib and in Drupal 7 core.
  • Visual difference tools (e.g.: Shoov).
  • Accessibility testing, both automated (e.g.: Quail) and manual (e.g.: VoiceOver, JAWS).
  • Browser testing (i.e.: ensuring it works in each browser), either automatically (typically performed with the Gherkin stack above), or manually (using a manual test case with local browsers, browsers in virtual machines, or browsers in the cloud).

Other names for acceptance tests are:

  • conformance tests
  • behaviour tests
  • functional tests
  • User Acceptance Tests (UAT)
  • validation tests
Refinement tests

Refinement tests are usually black-box tests to determine if a proposed UI is:

  • useful (does the system do what the user wants to do)
  • usable (can the user figure out how to get their tasks done)
  • aesthetically pleasing (does the UI look good)
  • identifiable (is the purpose of the system clear)
  • inspirational (does the system inspire the users to use it), and,
  • valuable (does the user value the system and it's purpose)

... on a broad scope, at the user-interface level. Each design stage / refinement typically undergoes a series of tests to ensure the design provides a good end-user experience. Changes to the code under test don't normally require changes to the refinement tests unless a desired UI element is deemed too costly to complete.

Refinement tests are typically written by a designer or UX expert by presenting a UI design to users and gathering data on how they experience it, and may be repeated as the design progresses. Beginning refinement testing before any real (non-prototype) code is implemented often reduces the number of design / UI changes later on in the development cycle, as the biggest usability problems can be identified as early as possible.

Ideally, refinement tests are written before the UI is developed and any work is done. If writing and performing refinement tests is required for new work, your last chance to do so is before committing or submitting your code for code review.

Key technologies for refinement testing are:

  • Visual difference tools (e.g.: Shoov).
  • A/B testing frameworks (e.g.: Acquia Lift).
  • Accessibility testing, both automated (e.g.: Quail) and manual (e.g.: VoiceOver, JAWS).
  • Talking to actual users.
  • Observing how users use the system.

Other names for refinement tests are:

  • UX tests
  • Usability tests
  • Business-value tests
  • Return On Investment (ROI) tests
  • End-user tests
  • Field tests

Some books on refinement tests that I've read and recommend are:

System testing

System tests are typically black-box tests to cover the system as a whole and catch regressions, on an extremely broad scope, at the user-interface level. The system usually has a number of system tests, each of which may focus on an important aspect of the system. Small changes to the code under test don't normally require changes to the system tests.

System tests are typically written by the tester, developer, and product owner, to by writing regression tests, setting performance acceptability thresholds, stress-testing the system, ensuring the system is compatible with the systems it's designed to work with (e.g.: where it will be deployed), and whether the system can recover from unexpected, serious problems outside of it's control (recovery tests).

Ideally, system tests are written or their parameters are chosen before any development work is done. If writing and performing system tests is required for new work, your last chance to do this is after integrating code together, usually before a demo to the client or a beta test.

One thing to note about system testing is that the results of the tests aren't always a strict pass/fail, and therefore aren't always actionable. In this case, trends are more important: you should expect software that just got a whole bunch of new features to be a bit slower; but if it's a lot slower, then you should probably examine the new code and schedule some time to refactor.

Key technologies for system testing are:

  • Analysis tools (e.g.: New Relic)
  • Load-testing tools (e.g.: Siege)
  • Manual tests

Other names for system tests are:

  • End-user tests
  • Field tests
  • Regression tests
  • Performance tests
  • Failure tests
Bonus: Smoke tests

Smoke tests are extremely-small, preliminary, typically ad-hoc tests to reveal major defects that would typically preclude someone's ability to run other tests. For example:

  • code that does not compile because of a syntax error prevents all tests from being run, therefore, syntax linters could be considered a type of smoke test;
  • if a file added in the latest deployment does not exist after the deployment, or the file is empty (and it isn't supposed to be), that's usually a good indication that a deployment failed.

Rumor has it that the term "smoke tests" is a calque from the discipline of electrical engineering, where, if you plug something in and it starts to smoke, that typically indicates that something is wrong and would prevent further testing.

Other names for smoke tests are:

  • confidence tests
  • sanity tests
  • intake tests
In conclusion

Hopefully, this blog post will help you to understand some of the terminology that surrounds software testing.

Special thanks to my friend Anand Sharma, who is just as passionate about software quality, and has been a big help and influence in helping me learn software testing. He also reviewed the software testing cheat sheet for me. Also, thanks to Patrick Connelly for the great tools he built and conversations we've had about continuous integration and software quality in general.

Some books on this subject that I've read and strongly recommend are:

If you're looking to implement formal software testing at your organization, don't be discouraged by the fact that it takes a while to learn how to write good tests: it's worth the investment.

Next week, I'll write a bit about automated testing, continuous integration, and continuous delivery.

AttachmentSize Software Testing Cheat Sheet (updated 2015-07-31)120.53 KB Topic: 
Catégories: Elsewhere

Web Wash: How to Display Icons in Drupal using Icon API

lun, 03/08/2015 - 13:15

Good use of icons on a website can really lift its overall design. Of course, you can't just slap them on and expect a site to look brilliant. It's all about choosing the right type of icons to match the design.

Once your designer has chosen a font library like Font Awesome, or made their own, what is the best way of displaying them in Drupal? The quick and simple way is to get the designer to style them using CSS but this is not flexible.

What if an editor wants to choose which icon is displayed in a menu? If you've added them to the menu manually via CSS then the editor won't have the ability to change the icon in the future.

The Icon API module integrates common icon bundles like Font Awesome, Bootstrap and more within Drupal. The module offers integration with a suite of sub-modules. For example, if you want to add icons to menus then install the icon_menu module.

In this tutorial, we'll configure Icon API to allow an editor to add icons to menus and directly into content. We'll do this using the Font Awesome icon bundle.

Catégories: Elsewhere

OSTraining: New Video Class: Speeding Up Your Drupal Site

lun, 03/08/2015 - 10:04

Drupal is a fantastic CMS, but it can be slow if the site is complex or on a slow server. With Google's focus on site speed, this is a very important issue.

In this week's new class, "Speeding Up Your Drupal Site", Robert helps us get the most out of Drupal's power without sacrificing performance.

Robert explains the caching power of Drupal, and introduces you to several great modules to help speed up your site.

Catégories: Elsewhere

Web Omelette: Write your own Views Bulk Operations actions in Drupal 7

lun, 03/08/2015 - 09:05

Views Bulk Operations (VBO) is a powerful module that leverages Views to allow site administrators to perform bulk operations on multiple entities at once. It does so efficiently by processing the items in batches over multiple requests to avoid timeouts.

Installing the module will already provide you with a host of various actions you can perform in bulk on various entities. You can publish 1000 nodes at once, delete them or even change their author. And these are just a few examples of what you can do.

In this article we are going to look at programatically creating our own action that we can trigger with VBO to affect multiple node entities. Sometimes you need to write your own because the use case does not quite fit in the extensive list of actions the module provides.

For our example, let's assume we have an entity reference field called field_users on both the article and basic page content types. This field can reference whatever user it wants. And the requirement is to be able to bulk update the value of this field on a bunch of nodes of both these node types at once.

Out of the box, VBO provides us with an action to change the value of a field but this doesn't help us in this case. When adding a value to this field via VBO, we are presented with as many instances of the field as different node types are in the selection. And this is not ideal if we want to scale the functionality to more than one content type. What we want is to select a number of nodes and then only once provide a value to this field. So let's see how we can define a custom VBO action for this use case.

The action

To define a new action we need to implement hook_action_info():

/** * Implements hook_action_info(). */ function my_module_action_info() { return array( 'my_module_my_custom_action' => array( 'type' => 'entity', 'label' => t('Add a user to Users field'), 'behavior' => array('changes_property'), 'configurable' => TRUE, 'vbo_configurable' => FALSE, 'triggers' => array('any'), ), ); }

With this hook implementation we are defining our own action called my_module_my_custom_action which is available to be triggered on all entity types (because we specified entity for the type) and it acts as a property changer. It is configurable using the default Action API but we don't need any kind of VBO specific configuration. For more information on all the values that you can pass here, feel free to consult the documentation page for VBO.

Next, it's time to create the configuration form for this action, namely the form that will be presented to us to select the user we want to add to the field_users reference field:

function my_module_my_custom_action_form() { $form = array(); $form['user'] = array( '#type' => 'textfield', '#title' => t('User'), '#maxlength' => 60, '#autocomplete_path' => 'user/autocomplete', '#weight' => -1, ); return $form; }

The function name takes from the machine name of the action suffixed by _form and is responsible for creating and returning a form array. All we need is one field which uses the core user/autocomplete path to load users via Ajax. Simple enough.

So now after we make a bulk selection and choose our action, we'll be prompted with this form to choose the user we want to add to the reference field. It follows to couple it with a submit handler that will save the value into the context of the operation:

function my_module_my_custom_action_submit($form, &$form_state) { $uid = db_query('SELECT uid from {users} WHERE name = :name', array(':name' => $form_state['values']['user']))->fetchField(); return array( 'uid' => $uid, ); }

The naming of this function is similar to the previous one except for the suffix being _submit this time around. In it, we load from the database the uid of the user that was referenced in the form field by name and return that inside an array. The latter will then be merged into the $context variable available in the next step.

So it's now time to write the final function which represents this step by adding the selected user to the existing ones in that field across all the selected nodes, regardless of their type:

function my_module_my_custom_action(&$entity, $context) { if (!isset($entity->field_users)) { return; } if (!isset($context['uid'])) { return; } if (!empty($entity->field_users)) { foreach ($entity->field_users[LANGUAGE_NONE] as $ref) { if ($ref['target_id'] === $context['uid']) { return; } } } $user = array( 'target_id' => $context['uid'], ); if (!empty($entity->field_users)) { $entity->field_users[LANGUAGE_NONE][] = $user; return; } $entity->field_users[LANGUAGE_NONE] = array($user); }

The name of this function is exactly the same as the machine name of the action, the reason for which we prefixed the latter with the module name. As arguments, this function gets the entity object that is being changed (by reference) and the context of the operation.

We start by returning early if the current entity doesn't have our field_users field or if by any chance the uid key is not available inside $context. Then we loop through all the values of the field and return if the selected uid already exists (we don't want to add it twice). And last, we add the selected uid to the list of existing users in the field by taking into account the possibilities that the field can be empty or it can already contain values. After passing through this action, VBO will automatically save the node with the changes for us.

And that is pretty much it. Clearing the cache will make the new action available in the VBO configuration of your view. Adding it will then allow you to select as many nodes as you want, specify a user via the autocomplete field and have that user be added to the field_users field of all those nodes. And the cool thing is that you can select any node you want: if the field doesn't exist on that content type, it will just be skipped gracefully because we are checking for this inside the action logic.

Hope this helps.

In Drupal var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Catégories: Elsewhere

Damien McKenna: My Drupal contrib plans for August, updated

lun, 03/08/2015 - 03:03

A few weeks ago I posted my plans for my personal Drupal contributions for the next month-or-so. I wanted to give a minor update on what I'd managed to achieve so far.

Catégories: Elsewhere

Lullabot: The New

ven, 31/07/2015 - 21:09
React.js, CouchDB, Node.js, de-coupling Drupal; if any of that sounds cool to you, then this is the podcast for you. Kyle Hofmeyer gathered a several Lullabots together, who helped create the new, to learn what kind of wizardry was used to make this thing purr like a happy kitten. Jared Ponchot talks about the advantages this process provided for him and his design team. Sally Young talks about the guts of the site and the magic that went in to making this de-coupled Drupal site a success. We are also joined by Kris Bulman, Wes Ruvalcaba, and Betty Tran as they share their experience building the site. From front-end advantages to lazyboyDB, this podcast has it all.
Catégories: Elsewhere

Lullabot: Announcing The New

ven, 31/07/2015 - 21:05
Mmmm… love that new website smell! Some history

It's been nearly 10 years since we launched our first company website at During that time, we've done five full redesigns of the site. The company has grown from two people to 62. We've expanded from a small Drupal consulting and education company to a full-service agency with a complete Design team, dedicated front-end developers, and of course, the expert Drupal back-end development which has always been our foundation.

As we've grown, our site design has reflected our focus and skills. The first site that Matt and I put together back in 2005 was intentionally sparse – not exactly beautiful, but functional and simple to maintain for just 2 or 3 people. As we hired talented designers and skilled front-end developers, site redesigns became more complex. In 2010, we split our Drupal education services into Drupalize.Me and the main focus of became our client services work, showcasing our design and development projects and sharing insights from our team.

Revving up the new

The newest iteration of is our most ambitious to date. As with most of our client engagements, the project started with research. Our Design team interviewed existing and potential clients, site visitors, and the Lullabot team to understand how people were using our site – what they wanted to get out of it, and why they visited. Our team distilled all they'd learned into goals and early wireframes for the site. They then worked with our Development staff to try to come up with the most flexible way of achieving these goals so that we could have full control of the site in ways that Drupal often doesn't afford. They wanted full <html> to </html> blue-sky design of any arbitrary page on the site without losing Drupal's amazing content management capabilities.

The technical team settled on a decoupled, isomorphic approach using Facebook's React, Node.js, CouchDB (a noSQL database) and Drupal as the backend CMS.

Content management is what Drupal does best, and this happens through a purpose-built subsite where the Lullabot team can login and post articles, podcasts, and manage their bios. Drupal pushes content into CouchDB, which exposes a REST API for React to consume. React is an isomorphic library (its code can run both in the server and the client), which means that when a visitor first visits the site, they receive the html of the entire page. Then, the rest of the navigation happens client-side, updating just the parts of the page which are different from the current one. Furthermore, React is written to be completely backward compatible with older browsers.

Our clients are often in need of API-driven native mobile apps, television-based apps, and content ingestion on connected devices. We've implemented these things in less holistic ways with our clients in the past. But the new gave us a chance to experiment with some methodologies that weren't quite tried-and-tested enough to recommend to our clients. But now that we've had a chance to see the type of flexibility they give us on, we'll be adding this to the array of architectural strategies that we can consider for our clients in the future.

Look ma, no hands!

The results are amazing; high-speed, high-performance, and superlative flexibility. In layman's terms, this means our Design and Front-end people can go crazy – implementing blue-sky ideas without the usual Drupal markup constraints. The new site is fully responsive. Articles and portfolio work pages can have giant, dazzling, full browser-height background images or videos. Articles have big text that is easy to read on any scale from large desktop monitors to the smallest phone screens. Furthermore, we did everything with an eye toward blazing fast page loads. We omitted jQuery, trading convenience in the development process for speedy page loads. Then we looked at every http request, every image, every library to make sure our website was as snappy on an older smartphone as it was on the desktop. Best of all, we off-loaded much of the heavy lifting to the client-side with React.

Design-wise, the new site is uncluttered, sparse, and relatively simple. But whether you're looking for our vast archive of articles or podcasts, information about what services Lullabot offers, who we've worked with and what we've done, or you're curious to know what it's like to work at Lullabot, it's all there.

Over the coming months, we will be writing a series of articles and doing a few podcasts talking about different aspects of the new site. Please subscribe to the Lullabot email newsletter below and you'll be the first to know when new articles are published.

Catégories: Elsewhere

Midwestern Mac, LLC: Launching my first Drupal 8 website — in my basement!

ven, 31/07/2015 - 19:48

I've been working with Drupal 8 for a long time, keeping Honeypot and some other modules up to date, and doing some dry-runs of migrating a few smaller sites from Drupal 7 to Drupal 8, just to hone my D8 familiarity.

I finally launched a 'for real' Drupal 8 site, which is currently running on Drupal 8 HEAD—on a cluster of Raspberry Pi 2 computers in my basement! You can view the site at, and I've already started posting some articles about running Drupal 8 on the servers, how I built the cluster, some of the limitations of at-home webhosting, etc.

Catégories: Elsewhere

OSTraining: Image Optimization with and

ven, 31/07/2015 - 19:15

One of the biggest factors to a slow page load is unoptimized image sizes. The bigger the image, the more time it takes the browser to load it.

This tutorial will show you the two free tools that I use to optimize images quickly.

These services will be useful whether you use WordPress, Drupal, Joomla or any other platform.

Catégories: Elsewhere

OSTraining: Googlebot Cannot Access CSS and JS Files

ven, 31/07/2015 - 17:57

Many website owners have recently received an email from Google with the title, "Googlebot cannot access CSS and JS files".

It doesn't matter whether you're running WordPress, Drupal, Joomla or another platform entirely. Google has sent these emails to 100,000's of sites.

I'm going explain the issue that Google is complaining and how you can resolve it.

Catégories: Elsewhere

InternetDevels: Lviv Euro DrupalCamp 2015: the best choice for your awesome autumn!

ven, 31/07/2015 - 16:57

Hi, drupalers! Enjoying your summer? Time to make plans for your awesome autumn! We have checked the forecasts, analyzed the position of stars, written php scripts to define the luckiest date and place for you. Here you go, the answer is: October 17-18, Lviv Euro DrupalCamp. The time and place cannot be changed ;)

Read more
Catégories: Elsewhere

Mike Crittenden: Drupal 7 Deconstructed

ven, 31/07/2015 - 15:40
How does Drupal work? Let's find out.

For years now I've wanted to dig through Drupal core, line by line, and understand how the big pieces do what they do. I'm finally doing that, and writing up my notes as I go.

Drupal 7 Deconstructed is the in-progress result of that.

If you've ever wondered what happens in the bootstrap process, or how Drupal's Form API works, or how exactly Drupal figures out which menu callback to run per page request, then this is the place to go.

It's just getting started, and so far I've only gone through the bootstrap process and the menu router, but I'm having a great time and learning a ton, so I expect to fill it up quickly.

Who could benefit from this?

Any developer who has ever wondered how Drupal works could get some value out of reading this. You'll need to know at least a little about Drupal development to understand parts (for example, I don't explain what hook_menu() is when talking about the menu router), but you shouldn't need to be an expert or anything.

If you feel like that describes you, but you don't understand a part, please let me know so that I can make it more approachable.

Want to help?

If you're interested in helping out, the best thing to do would be to keep an eye on the repo and proofread or review things as they're written.

Pull requests are also greatly appreciated, whether you want to fix a typo or submit a whole new chapter.

Or, if nothing else, just let me know if you like this idea! Knowing that this could be helpful to people besides just me is a huge motivational boost to keep things moving.

What's the end game?

I don't know. I could see this staying on GitHub forever, or being published on Leanpub, or ending up as a blog series.

Any suggestions?

Why Drupal 7? What about Drupal 8?

I chose Drupal 7 because it still has a pretty long shelf life left. Drupal 8 Deconstructed definitely needs to be written though, and I'd love to dive into that after 7 is complete.

What about contrib?

I would love to take apart some of the more commonly used contrib modules like Views, CTools, Panels, Webform, Pathauto, etc., as well, but one step at a time!

Please check out Drupal 7 Deconstructed and let me know what you think so far!

Read this next: I wrote a book for O'Reilly: "Responsive Theming for Drupal"
Catégories: Elsewhere

Drupal core announcements: Recording from July 31st 2015 Drupal 8 critical issues discussion

ven, 31/07/2015 - 12:29

We met again today to discuss critical issues blocking Drupal 8's release (candidate). (See all prior recordings). Here is the recording of the meeting video and chat from today in the hope that it helps more than just those who were on the meeting:

If you also have significant time to work on critical issues in Drupal 8 and we did not include you, let me know as soon as possible.

The meeting log is as follows (all times are CEST real time at the meeting):

[11:03am] jibran: I think it is sorted by name
[11:03am] jibran: the order in the hangout
[11:03am] WimLeers: y
[11:07am] jibran: We have to look at google hangout code base for that.
[11:08am] WimLeers:
[11:08am] Druplicon: => [meta] Auto-placeholdering [#2499157] => 5 comments, 4 IRC mentions
[11:11am] WimLeers: amateescu's issue link:
[11:11am] Druplicon: => Deadlock on cache_config (DatabaseBackend::setMultiple()) [#2336627] => 39 comments, 24 IRC mentions
[11:12am] WimLeers: plach: yay for vacation :D
[11:12am] GaborHojtsy: VACATIOOOOOON!
[11:12am] GaborHojtsy: sometime, sometime :)
[11:12am] alexpott: is the nearly ready issue
[11:12am] Druplicon: => hook_entity_type_update doesn't get the entity in the new revision after addTranslation and setNewRevision [#2542762] => 11 comments, 4 IRC mentions
[11:13am] alexpott: is the gnarly update issue
[11:13am] Druplicon: => Automatic entity updates are not safe to run on update.php by default [#2542748] => 21 comments, 7 IRC mentions
[11:15am] plach: WimLeers: :)
[11:15am] WimLeers: alexpott: yay :)
[11:15am] dawehner:
[11:15am] Druplicon: => Decide whether we need hook_upgrade_N()/upgrade.php front controller [#2540416] => 27 comments, 4 IRC mentions
[11:16am] WimLeers: dawehner: cache tables are auto-created
[11:16am] naveenvalecha|af left the chat room. (Read error: Connection reset by peer)
[11:16am] WimLeers: but yeah, router table etc… #sadpanda
[11:19am] WimLeers: The issue that originally turned it from a separate PHP file into a route + controller:
[11:19am] Druplicon: => Run updates in a full environment [#2250119] => 21 comments, 1 IRC mention
[11:34am] WimLeers: plach: ROFL
[11:34am] WimLeers: plach++
[11:43am] WimLeers: "a foam of circles" lol
[11:48am] alexpott:
[11:48am] Druplicon: => Automatic entity updates are not safe to run on update.php by default [#2542748] => 21 comments, 8 IRC mentions
[11:55am] dawehner: WimLeers: well but those tables aren't auto fixed
[11:56am] dawehner: WimLeers: so just imagine what happens if you need to change the cache_ tables
[12:00pm] WimLeers: dawehner: ohhh!
[12:02pm] WimLeers: plach: is that the church bells in Venice that I'm hearing?
[12:03pm] WimLeers: dawehner: lol
[12:03pm] WimLeers: :)
[12:05pm] plach: WimLeers: yeah, sorry :)
[12:05pm] WimLeers: plach: made me feel like I was on vacation, ever so briefly
[12:05pm] WimLeers: :D
[12:05pm] plach: :)
[12:23pm] dawehner: alexpott: are the issues the new thing or the solutions ;)
[12:24pm] alexpott: dawehner: well we have better ideas

Catégories: Elsewhere

OSTraining: Using Theme Developer and Firebug to Debug Drupal Themes

ven, 31/07/2015 - 00:47

There are several tools that that makes designing for Drupal much, much easier.

In particular, we recommend the Theme developer module and also Firebug.

Many of you may know about Firebug already. It's a browser tool that allows you to inspect any CSS, HTML or JavaScript elements.

Think of Theme developer as a Drupal-specific version of Firebug. Using Theme developer you can click on any element of your Drupal site and get a breakdown of how it was built.

Catégories: Elsewhere

Sina Salek Official Site: Drupal Module: CSS JS Total Control is here to rescue the themers

jeu, 30/07/2015 - 21:46

When we create themes in Drupal, there are great number of reoccurring tasks that we have to do like adding IE conditional comments, remove or replace some core or contributed modules CSS/JS files to prevent conflict with the theme, putting some JavaScript at the bottom of the page or even adding inline CSS or JS files. The module which i'm going to introduce, makes it possible to take care of all those tasks and even more with no special knowledge and no programming.

read more

Catégories: Elsewhere