Drupal News

Syndicate content
Drupal related news with the junky stuff filtered out
Updated: 26 sec ago

DrupalCon Amsterdam: Growing the Community & the Project Through Grants, Scholarships, and Mentoring in Amsterdam

July 28, 2014 - 1:00am

Grant and scholarship recipients have been selected for DrupalCon Amsterdam. We had a huge number of wonderful applicants, and selecting our grant and scholarship recipients was a challenge.

For applicants seeking grants, we focused on the importance of each candidate to the Drupal project and code as a whole. Scholarships, meanwhile, were awarded based on the impact or influence on the Drupal community and Drupal adoption that the person would have at their home region— though these were just a few of the many factors taken into account during the selection process.

We’re please to announce the following grant and scholarship recipients below:

Grant Recipients
  • Nathaniel (catch) Catchpole - United Kingdom
  • Larry (Crell) Garfield - United States
  • Dave (Dave Reid) Reid - United States
  • David (David Hernández) Hernández Ruiz - Spain
  • Dan (dcmul) Mulindwa - Uganda
  • J Branson (j.branson) Skinner - United States
  • Joël (joelpittet) Pittet - Canada
  • Jose (Jose Reyero) Reyero - Spain
  • Jeremy (jthorson) Thorson - Canada
  • Kalpana (kgoel) Goel - United States
  • Patrick (patrickd) Drotleff - Germany
  • Brian (realityloop) Gilbert - Australia
  • Ricardo (ricardoamaro) Amaro - Portugal
  • Sébastien (SebCorbin) Corbin - France
  • Shyamala (Shyamala) Rajaram - India
  • Janez (slashrsm) Urevc - Slovenia
  • Evgeniy (Spleshka) Maslovskiy - Belarus
  • Tim (stpaultim) Erickson - United States
  • Kristof (swentel) De Jaeger - Belgium
  • Yves (yched) Chedemois - France
  • Zsófi (zsofi.major) Major - Hungary
Scholarship Recipients
  • Aldibier (aldibier) Morales - Colombia
  • Alvaro (alvar0hurtad0) Hurtado - Spain
  • Andrey (andypost) Postnikov - Russian Federation
  • Carlos (camoa) Ospina - United States
  • Luis Eduardo (edutrul) Yelaya Escobedo - Peru
  • Grzegorz (grzegorz.bartman) Bartman - Poland
  • Konstantin (konstantin.komelin) Komelin - Russian Federation
  • Weber (Mac_Weber) Macedo - Brazil
  • Ivan (rootwork) Boothe - United States
  • Tanay (saitanay) Sai - India
  • Shabana (Shabana Blackborder) Navas - India
  • Tarek (tarekdj) Djebali - Tunisia

Congratulations to all of our grant and scholarship recipients! We'd also like to extend a big thanks to our selection team: Emma Karayiannis (UK) Bart Feenstra (NL) Mike Anello (US).

We’re excited to see all these great people at DrupalCon Amsterdam, and can’t wait to learn from them and make the project even better. When you see our grant and scholarship recipients around volunteering at the event or mentoring new sprinters, give them a high five for being amazing! And regardless of whether you’re receiving financial assistance or not, if you’re coming to DrupalCon, you can share you knowledge and help make Drupal even better too by signing up to become a mentor.

Growing the Drupal project can’t happen if our community doesn’t grow, too— and there’s no better way to help grow the community at DrupalCon Amsterdam than to give back by teaching new skills and ideas to basic, intermediate, and advanced Drupalers.

orkjerns blogg: Now running Drupal 8, in the most hipster way imagined.

July 27, 2014 - 12:48pm
Now running Drupal 8, in the most hipster way imagined.

It has been a weekend in the spirit of headless Drupal, front-end optimizations and server side hacks. The result is I updated my blog to Drupal 8. Since you are reading this, it must mean it is live.

First let's start with the cold facts (almost chronologically ordered by request lifetime):

Other front-end technologies used that does not directly relate to the request itself:

So, HHVM, huh?

Yeah, that's mostly just a novelty act. There is no real gain there. Quite the opposite, I have added some hacks to get around some limitations.

HHVM does not work very well with logged in users right now, but works alright for serving anonymous content.

When I reload and look at the source code, there is no css loading. WAT?

Yeah, I am just assuming you remember the styles from last page load. Also, I have made it an image to have a 1 HTTP request CMS, right?

No, really. How does that work?

The real magic is happening by checking if you as a user already have downloaded my page earlier. If you have, I don't need to serve you css, as far as I am concerned. You should have saved that last time, so I just take care of that.

OK, so you use a cookie and save css in localstorage. Does that not screw with the varnish cache

Good question. I have some logic to internally rewrite the cached pages with a key to the same varnish hash. This way, all users trying to look at a css-less page with the css stored in localstorage will be served the same page, and php will not get touched.

What a great idea!

Really? Are you really sure you have thought of all the limitations? Because they are many. But seeing as this is my personal tech blog, and I like to experiment, it went live anyway.

Give us the code!

Sure. The theme is at github. The stupid cache module is at github. Please be aware that it is a very bad idea to use it if you have not read the code and understand what it does.

And since I am feeling pretty bad ass right now, let's end with Clint Eastwood as an animated gif.

Tags:

Berliners blog: Showcase: Art market

July 26, 2014 - 10:56am

The last months I was busy with a friends art project. Today I'm very happy to announce that it went public on july 15th and is doing good so far.

Jule, the founder of Port of Art, approached me last summer, asking if I could help her building an online market place for artworks. Working primarily as a freelance Drupal developer, knowing that her budget is tight and that she is certainly not the first one with this idea, I hesitated. But I gave it a thought and after several meetings I agreed. I liked the idea and I liked Jules approach, that is very trusting and positive without being naive. I like good people ;) She also gave me the impression of being able to value constructive input, even if it means to change previous ideas. That is a good feature in clients!

Basic ideas with a special flavor

The basic requirements were pretty simple:

  • Content management for static content pages as well as for special content like the artworks that are sold on the site
  • Search artworks by different filters
  • Legal compliant checkout process
  • Integration of external payment providers (limited to paypal for the moment being)
  • Contact forms
  • Multilingual content and communication
  • Integration of social media
  • Some map views for geo visualization
  • SEO, customizability, ...

So far that was relatively straight forward and we all love Drupal for that.
But there were some special requirements too, that had a huge impact on my choice of modules to realize this with.

  • Artworks don't integrate with a basic warehouse approach. Each one should be unique and can be bought only once. Therefor there was no need for a shopping cart either.
  • Artworks can be bought for a fixed price or as an auction.
  • Artworks under a certain price are not sold via the site, but instead the customer and the artist are put in touch directly and have to figure out the details independently of the platform.
  • Artists should be able to upload their artworks, pay a fee to get them published and than manage the selling and delivery on their own.
  • Artworks expire after a certain time that depends on the publishing fee that the artist is willing to pay.
  • Once an artwork has been sold on the site, an additional fee has to be paid.
  • Fully customizable e-mails

The main content is obviously the artwork. This is a node type with additional fields to represent attributes of an artwork. Then there are static pages, artschools, faqs and webforms. On the user side we have two frontend user roles for customers and artists that get enhanced using the Profile 2 module.

Additional considerations

The situation that our development team was faced with: Small budget, tiny team (only 2 people), the project's concept still a little in the flux. The founder had no technical background or previous experience using Drupal but needed a customized shop system that she could actually manage after we finished the project and went on to other things. So one of the goals during development has always been to make things configurable. Special text at a certain page? Build a setting for that. A special criterion that controls logic during checkout? Don't hardcode it somewhere! Build a setting for that as it might change later and you don't want to change code for simple things. I love drupal for it's easy variable management and quick form building capabilities. Building an admin form to control certain behaviors takes rarely more then 10 minutes. Obviously there are things that you can't build that way, but when you can, do it. I feel much butter with it and the client loves it too because it gives him control.

Conception and development process

One of the things I knew before, but that got confirmed again: Communication is the key. The client has never did a web project before. That meant that certain good practices and workflow, concerning the development process as well as the final product, were not clear to her. So we (the designer and me) spend a good amount of time helping her figure out what was realistic and which compromises needed to be done in order to deliver the product without cost explosion or an exagerated time frame. Being honest and communicating potential problems early on, as well as the clients openness towards constructive input, was something that attributed a lot to the perceived quality of the development process. Including the client in the development and design decisions also allowed us to educate her on the technical aspects of the product and raise awarness about technical implications, making her see advantages and restrictions in different areas that she didn't consider in the beginning.
We didn't formalize the process, but we ended up with some kind of agile development with three distinct roles: Conception and design by the client, frontend by the designer and backend logic and architecural design by me. That worked very good for us.

Obvious modules that we still didn't use

First, there is Rules. A crazy wonderland for workflow configuration that amazes me every time I look at it. But I've almost never used it. Call me old fashioned, but when business logic or complex relations must be build, I prefer to build them on my own. I want as much logic as possible in the code, not in the database. So for all the power Rules provide, I still prefer not to use it.

Then there is Commerce. We have never build a real-world website with it, so our experience was very limited. We thought about it. Very seriously. Then we decided against it. From todays perspective that was probably an error. But given the special requirements we were afraid of having to spent too much time customizing and altering the workflow that commerce proposes. This was more of a gut feeling. And at the end I'm not sure it was the right decision. We ended up with conceiving and building a full fledged product management incuding the purchase logic and payment. The obvious advantage when you write something like this on your own, is that you have a lot of fine grained control about flow and design. But the price is pretty high considering the amount of time necessary. At the end we have a considerable code base that needs to be maintained. So next time, I hope I'll remember this an give commerce a more in depth examination regarding the potential for the problem at hand.

Crucial contrib modules / add ons

It's hardly necessary to mention, but we couldn't have build the site so easily without the usual candidates: Views, Webform, Better Exposed Filters, Address Field, CTools, i18n, References, Profile 2, Geofield, Global Redirect, Libraries, ...

The fantastic wookmark jquery plugin is responsible for the display of the central search component of the site. Our designer loves it!

Some modules that got born or advanced

I build MEFIBS for this site. I had a need for that functionality before, but never quite as strong as this time, so I decided to solve it as a self contained module instead of hacking things together. Though there are some problems currently with a few new features that I added recently, it is already in production and doing pretty well. Have a look at the filter and sorting blocks on the artwork search page: . Two independant blocks without duplicating a views display or intensive custom form altering. That's pretty neat.

Hopefully the jQuery Update module will also profit. During development I ran into issues with the admin version feature introduced here: https://www.drupal.org/node/1524944. I wrote about it in jQuery version per theme. This resulted in a feature patch that is currently on a good way to get committed soon.

I also found a bug in the PayPal for Payment module: https://www.drupal.org/node/2052361 that will hopefully get fixed soon.

Another module I find myself using often is my sandbox module Mailer API. It's a bit cumbersome to use as a developer, but for the client it's perfect. She can customize practically every mail that will be send by the system. It's all on a single configuration page and supports multilingual setups. A test mail feature is also included to see what mails will look like. And a batch mailer that the client often uses to address a bunch of people. It's like very easy home made promotional mails in a consistent look and feel. Made the client happy.

For frontend eye candy we have build a jQuery plugin that is responsible for the collapsible checkbox filter elements in the left side bar.

Some module discoveries

During the work on www.port-of-art.com I found some modules that I didn't know before.

The Form API Validation module allows you to simplify validation rules in custom forms, using predefined validation rules. And you can also add your own rules which we used for the price entry validation needed when artists publish their artworks.

The Physical Fields module provides fields for physical dimensions and for weight attributes. That was exactly what we needed for physical goods. It saved us the time to configure fields in field collections.

Conclusion

At the end of the project I can say, that everyone involved has had a good and productive time and enjoyed the process and the result. The client is happy for all the things she can do with the site. Now she can concentrate on managing business and extending marketing. The designer was happy. Even if some of the design decisions might not have been the best ones looking at the requirements profile from today. I feel positive though that the system fully matches the clients expectations and that it'll be a valuable tool for developing her business. If the site manages to establish itself, it's more than probable that we would rebuild the system, at least some substantial pieces like the shop component.

We as the site builders are happy too. We feel that we have done a good job and that we managed to keep resources and expectations in balance. I would do it again, which always feels like a good measure.

Category: Drupal Planet7.x

Code Drop: Drupal 7 WYSIWYG Editors Done Right

July 26, 2014 - 6:36am

It's fair to say, on a fresh install the content authoring experience in Drupal needs improvement. WYSIWYG editors are often criticised for various reason such as the ugly HTML they are known to generate or the power they give users to mess up typography. While these are valid criticisms, there is definitely a right and wrong way configure these editors. Doing things the right way will empower users while keeping them safe from nasty pitfalls. Note: this guide assumes you're already familiar with a typical Drupal WYSIWYG setup.

Provide a true WYSIWYG experience

It's important that a WYSWIYG editor represents exactly what appears on the front-end of your website. While it seems obvious, it's easy to ignore and has a big impact on a user's experience.

Our WYSWIYG stack is:

Drupal.org Featured Case Studies: Concern Worldwide - Mobilisation & Usability

July 25, 2014 - 1:58pm
Completed Drupal site or project URL: https://www.concern.net

Concern Worldwide is a leading international humanitarian organization dedicated to tackling poverty and suffering in the world’s poorest countries. Their main website, www.concern.net, plays an important role in their fundraising process. It enables people from around the world to donate towards specific campaigns and ensure that their money is distributed to where it’s needed most.

SystemSeed has the wonderful opportunity of partnering with Concern in leveraging Drupal to power the Concern Worldwide platform for a number of years spanning all the way back to the days of Drupal 5. This particular site was upgraded to Drupal 7 in 2012 as part of a large platform refactor which aimed to consolidate all of Concern’s Drupal websites under a single common platform. We wrote about the transition from standalone sites in this case study.

Since then, we have been leading a large project to bring full responsiveness and optimisations across a wide spectrum of devices to all sites on that platform. Today (July 3, 2014) sees the completion of this project with the rollout of a fully responsive and adaptive theme layer, catering for its widest audience ever. In this case study, we’ll look at some of the components of this project, the processes, the challenges, the successes, and lessons learned along the way.

Key modules/theme/distribution used: OmegaBreakpointsBreakpoint PanelsPictureInline Form ErrorsOrganizations involved: SystemSeedTeam members: mrfeltonrahulbileroblavfastangeljucallme

Front-end Rapport #5

July 25, 2014 - 1:00pm

Front-end Rapport #5

July 25, 2014 - 1:00pm

LightSky: NavBar - The Next Step in Drupal Navigation

July 25, 2014 - 11:17am

So I am not kidding NavBar is literally the next step in Drupal navigation, it is being used in core for Drupal 8.  This is great news because not only does it mean that the Drupal 8 core will contain some much needed improvements to the administration navigation scheme.  Back end user improvements like this are perhaps the thing that makes me most excited about what Drupal 8 is bringing to the table.  Lets look a little bit at NavBar.

What You Get

Pretty simply put NavBar gets you a responsive administration toolbar for your Drupal users.  It really isn’t going to do anything for what your visitors see, but your content creators, site administrators, and even site builders will see this as a much welcomed change.  NavBar is first and foremost completely responsive, and for those of you who use the traditional Drupal administration toolbar on your mobile phone oh boy are you excited.  The standard Drupal 7 install, not to mention Drupal 6, doesn’t offer the most mobile friendly administrative experience.  NavBar helps resolve this.  NavBar also offers a more flexible navigation option.  You are able to use NavBar at the top of your site above the header, or as a sidebar on the left hand side.  The customization of the tool, really helps set it apart.

Not only is the mobile experience improved, but there is a much cleaner and professional looking image presented than the Drupal 7 administration menu.  Though this might not seem like much, for those of us who build Drupal sites for clients this is a big deal.  Image is everything, and it is tough to sell Drupal’s out of the box usability against WordPresses out of the box usability.  We have a lot of admin usability improvements in our standard Drupal installation to help combat this, but now NavBar is another one.  Users almost expect clean and friendly design, and now they can get it. 

Installation

I am not going to lie, NavBar in its current state is a bit of installation work, but most people should be able to figure it out if they have a little understanding for how Drupal is structured. 

The first step for me is downloading and installing the project.  I think that drush is the best tool for installing and enabling projects like this, but particularly for NavBar I suggest installing the project before moving to some of the other steps.  The reason is that once the project is installed and enabled it will put some indicators on your /admin/reports/status page that can really help you troubleshoot in the next steps.

Once the NavBar module is enabled, you can visit the site’s status report using the path above and notice that there are a three statuses now associated with NavBar, and this is where the fun comes in.  NavBar requires the installation of three libraries (Modernizr, Backbone, and Underscore), and you may have them already installed, or at least some of them.  Using the status page at this point will help you find out if you have them already installed and ready to run, or whether you need to install them.
If you find that you need to install them, the process isn’t all that complicated, there are some helpful guides on the project page that will point you in the right direction.  Or give us a shout we would be happy to help.  Essentially it is a matter of downloading the libraries, or cloning their respective repositories, and moving them to your libraries folder in the Drupal installation.  The Modernizr library requires you to follow a link and download a specific minimized version of the library but there are specific instructions to follow on the project page to help guide you here, so I won’t reinvent the wheel here.  The instructions are pretty thorough, and relatively simple. 

Once you have the libraries installed you can disable your regular administration toolbar and you are off and running.  If you follow those steps and still aren’t having any luck, the site status report is the best place to look.  Most likely it is an error with the libraries that were installed, and that report will point you to which library is causing trouble, and maybe even what the problem is.

We have fallen in love with NavBar, and it has started making a huge impact on our clients and how well they like using Drupal.  We highly suggest you use it.

For more tips like these, follow us on social media or subscribe for free to our RSS feed and newsletter. You can also contact us directly or request a consultation

Clemens Tolboom: It's alive in space

July 25, 2014 - 8:03am
Experimenting with the index file of https://github.com/clemens-tolboom/uml-generator-php lead to a nice animation. Click the image below using Chrome to see Drupal 8 in it's full glory (only if you have the power to consume a hefty animation).

Four Kitchens: Design, Prototype, and Style in Browser

July 25, 2014 - 8:00am

As Brad Frost aptly points out, the core pieces of responsive web design (fluid grid, flexible media, and media queries) are only the tip of the iceberg. In our latest training session at DrupalCon Amsterdam, the Web Chefs will show you how to level up your responsive design skills to create amazing experiences across the web.

Training Drupal

Code Karate: Drupal 7 Fieldable Panels Panes

July 25, 2014 - 4:10am
Episode Number: 159

The Fieldable Panels Panes module allows you to create re-usable and fieldable entities that can easily be dropped into Panels pages. This can be useful if the traditional Add Content panes inside Panels is too limiting for you. This also allows using fields (which are translatable) for your Panels content.

In this episode you will learn:

Tags: DrupalEntitiesPanelsDrupal 7Site BuildingDrupal Planet

Wunderkraut blog: Healthy sprinting

July 25, 2014 - 1:42am

How long can we last on pastry and coffee? It’s time to start taking our sprint nutrition seriously

Of all the activities I take part in the Drupal community, sprinting is my favourite. Coming together with new and old friends to push forwards is a great feeling. Many events around the world are realising the power of sprinting and working hard to accommodate them.

But every sprint I go to I feel completely drained. I feel like I need a holiday after a week long sprint. Part of this is down to diet. Refined sugar, pizza, and caffeine is a short term solution to a long term problem. Quickly absorbed into the bloodstream, they give you a quick high, followed by an unavoidable crash.

In terms of actual nutrients, in refined sugar there is only one: the above mentioned sucrose. It makes up 99.9% of the product. There are no vitamins, minerals, trace elements, fiber, water, protein, fat, or anything else. Nutrients such as chromium, manganese, zinc, magnesium, and copper have been lost in the refining process. For that reason, it has been said that sugar provides “empty calories.”

Annemarie Colbin - SUGAR! Delicious and Deadly

By the second day of a conference, hackathon, or sprint. I need a coffee and pastry before I can start looking and thinking straight. It’s a non-stop cycle, and that’s exactly what most sprint venues provide.

Time to kick the habit

We need to start being more responsible over our bodies and minds and need to ask our kind hosts to be more responsible. It may be a sprint, but life is a marathon. Let’s replace the coffee, pizza, and donuts with healthier options.

Boost your brain powerB1, B2, B3, B5, B12, Folic Acid.

Essential for energy production, brain and nerve function. Find them in:

  • Broccoli
  • Mushrooms
  • Watercress
  • Tomatoes
  • Asparagus
  • Hazelnuts
  • Cashew nuts
  • Walnuts
Fight the Drupal fluVitamin A, Vitamin C.

Strengthens the immune system – fights infection. Needed for healthy skin, bones, and joints. Works with Vitamin B to produce energy. Find them in:

  • Broccoli
  • Cabbage
  • Strawberries
  • Melons
  • Oranges
  • Grapefruit
  • Mangoes
  • Apricots
Up your moodZinc, Vitamin C.

Helps produce the anti-stress hormone. Aids ability to cope with stress effectively. Find them in:

  • Pecan nuts
  • Almonds
  • Brazil nuts
  • Whole wheat bread
  • Whole wheat pasta
  • Shrimps

I really hope we can raise expectations around sprints and the level of food available.

Wunderkraut cares about Healthy Web Projects making healthy decisions with our clients and with our employees. We favour long term benefits over short term. We aim for sustainable projects instead of exhausting projects.

That's why we're sponsoring the sprint buffet at the Drupalaton sprints. As well as the usual snacks, there will also be a range of healthy foods to help your productivity and happiness. "We care about the Drupal community and all the participants that push Drupal 8 forward.

Drupalaton is the perfect event to kickstart this initiative. Four days of blue skies, clear water, and sprinting.

Let's sprint healthy!

DrupalCon Amsterdam: Countdown to Amsterdam - Shaping The Sessions After Selection

July 24, 2014 - 10:30pm

Business track chair Steve Parks writes on the work being done to develop the session content for DrupalCon between session selection and the event itself.

It seemed to happen in the blink of an eye. DrupalCon Austin finished, and within a week the window for submitting sessions for Amsterdam closed. After that, the track chairs had just two weeks to review and assess hundreds of submissions to sift them down to just 13 sessions per track-- and we all had day jobs to do too!.

Although selection is now complete, the work to make DrupalCon great isn’t over. The track chairs (and of course the Drupal Association staff) are still devoting considerable time each week until DrupalCon is actually over.

Feedback

Firstly, we committed to providing detailed feedback to anyone whose proposed session wasn’t selected. In the case of the business track, we went into quite a bit of detail providing tips about what could get each session selected in future. We also encourage new speakers, or those with new talks, to deliver them at DrupalCamps first to get practice.

Presentation Coaching

We offer all selected speakers presentation coaching, and some accept. In these cases Emma-Jane Hogbin works with them to hone their skills and their presentation so that it is ready for the DrupalCon stage. It can be pretty daunting to suddenly have hundreds of smart community members as your audience, especially when many of them will also have expertise in the subject of your talk, so having this coaching can really pay off.

Content Coaching

As track chairs we work with many of the speakers on each track to help them develop the content of their presentation for DrupalCon. This is partly to help ensure the talk is pitched at the right level and contains valuable information, and partly so it can add to previous similar talks rather than repeat them. We also help refine the session titles and descriptions so that delegates will want to choose to go to the session.

Scheduling

There are a range of room sizes available, and 3 days of conference. One of our next jobs is to guesstimate how popular each session will be and put it in an appropriately-sized room-- while also scheduling it at a suitable time. This means considering any requests from the speakers, avoiding clashes between sessions that complement each other, and placing more introductory sessions earlier than similar more advanced sessions, as well as a range of other factors. The aim is also to ensure that, as far as humanly possible, most delegates will have something to see in each time-slot regardless of their area of specialism or their level of experience.

Education, not promotion

One of the clauses in the DrupalCon speaker agreement covers a key part of the longstanding culture of DrupalCon that we’re trying to protect as Drupal grows. DrupalCon is not a typical industry sales conference. Audiences don’t want to sit through a product pitch, or a company’s credentials and ego pitch.

The aim of DrupalCon is for education and sharing by the community, for the community. Yes, companies are a vital part of that community - but they are respected based on what they give rather than what they try to get out of DrupalCon. At previous conferences I’ve heard the backchannel backlash against companies overstepping this line. Sales-y sessions are bad for delegates, bad for DrupalCon’s future, and even bad for the company concerned.

As track chairs, that means that we’re alert to sessions that may risk being a little too promotional, and we’ll chat to the speakers concerned (It was also a factor considered in the session selection, as a first filter). We review the slide decks in advance of the conference.

If you feel that any sessions on the business track this year are too promotional, I’d appreciate you letting me know, and I’ll raise it for discussion with the Drupal Association.

Getting Excited

Finally, there is still time for us as track chairs to get excited about the coming conference. I’ve now booked my ticket and my hotel - and can’t wait to land in Amsterdam at the end of September and see all the work come together.

See you there!

NEWMEDIA: DrupalCamp Colorado 2014: Large Scale Drupal

July 24, 2014 - 7:26pm
DrupalCamp Colorado 2014: Large Scale DrupalWith less than a week until the camp, here is a preview of what to expect from our team!

Everyone here at NEWMEDIA is extremely enthusiastic about this year's DrupalCamp Colorado, which will be held on August 1st-3rd in Denver. This year’s theme for the camp is “Large Scale Drupal” where the focus is on how  larger organizations can become more collaborative with the Drupal community by pooling ideas and resources together to solve common issues they are facing. There will be a wide variety sessions this year, six of which will be presented by members of NEWMEDIA. We are also very excited about being a Platinum sponsor.

Drupal 8 Module Development: Just the Basics

Start off this years DrupalCamp Colorado right and jump into Drupal 8 module development.  Brandon Williams  will cover the basics of Symphony and the Drupal 8 module , including a review of what has replaced some of the most common hooks from D7. Brandon is an advocate for learning and change and in the technological world we experience that invariably. While Drupal 7 will be the best option for the short-term, it is never too early to dive in to D8 as he describes in why I love D8!

Jenkins 101: A Drupal Perspective

Want to know more about Jenkins from a Drupal perspective and have a better understanding on how Jenkins can be applied to multiple processes? Then you should join Brandon in his second session that will introduce Jenkins from a Drupal perspective and how it has been proven to be beneficial within NEWMEDIA. As a community we can take this knowledge and continue the conversation to help emerge the tools to permit everyone to become more effective.

Securing customers credit card data

Security for your clients credit cards is now a necessity in today's growing eCommerce market. Rick Manelius  will review all of the parts of the standard that apply to Drupal along with providing efficient advice on how to best reduce one's risk when processing credit cards. As the amount of eCommerce transactions continues to rise it becomes even more critical to support every part in the system. If you would like more information on PCI compliance for Drupal  visit DrupalPCICompliance.org you can also download the free, community sponsored white paper.

The SCSSy Wild West: Partial Organization for a Complete Site

Take a look at Tim’s blog Partial to Partials: BoF Recap for a recap of last years session about the organization of partials.This year Tim Whitney  will go over a partial layout strategy for all scales of Drupal and non Drupal. Going over common pain points of SCSS partials and how to alleviate them while including approaches to help make life a little easier for everyone.

Integration Testing with KitchenCI & Multiple Provisioners

“Works on my machine” is no longer an acceptable reason for a Drupal site to not perform as expected across multiple environment (i.e. production, staging, development, and local development). This is particularly important as projects become larger, more complex, and have stringent requirements on performance, uptime, and security. Kevin Bridge's presentation will start with the basics of “Infrastructure as Code” and then quickly ramp up to review how to use provisioning tools and integration tests to ensure your infrastructure is achieving the desired state.

Intro to Frontend Ops

Discover the tools that help frontend developers stay consistent as they develop their drupal themes. This discussion from Ryan McVeigh will focus on gruntjs and bower and will also discuss Gulp JS, Phantomjs, PageSpeed, and Slimer JS. You will be able to watch some of his pre-recorded demos of the tools in action. Come and join in on the  discussion and see how the use of these various tools can contribute to your routine work day.

Come Join Us!

There is still time to sign up for this weekend and better yet it is free with the option to donate.  Any registration contributions beyond DrupalCamp Colorado’s  budget target will be donated to 3 charities: The Ada Initiative, Code.org, and Electronic Frontier Foundation.  This weekend has a  great full-day Training Day on August 1st and will be offering three separate classes you can pay and sign up for.

Another Drop in the Drupal Sea: Ways to shoot yourself in the foot: element validation

July 24, 2014 - 7:21pm

I needed to do some custom validation of fields on a form. So, I decided to use #element_validate. One of the fields I was validating appeared a bit strange to me, though. When I displayed its $form_state['values']['field_face_palm'] information I saw that it looked like:

$field_face_palm['und'] = 'you_knucklehead'

instead of like:

$field_face_palm['und'][0]['value'] = 'you_knucklehead'

read more

Drupal.org frontpage posts for the Drupal planet: Drupal 7.30 released

July 24, 2014 - 2:12pm

Drupal 7.30, a maintenance release with several bug fixes (no security fixes), including a fix for regressions introduced in Drupal 7.29, is now available for download. See the Drupal 7.30 release notes for a full listing.

Download Drupal 7.30

Upgrading your existing Drupal 7 sites is recommended. There are no new features in this release. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 includes the built-in Update Manager module, which informs you about important updates to your modules and themes.

There are no security fixes in this release of Drupal core.

Bug reports

Drupal 7.x is being maintained, so given enough bug fixes (not just bug reports), more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.30 is a bug fix only release. The full list of changes between the 7.29 and 7.30 releases can be found by reading the 7.30 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Update notes

See the 7.30 release notes for details on important changes in this release.

Known issues

None.

Front page news: Planet DrupalDrupal version: Drupal 7.x

Mediacurrent: Code Review for Non-Technical Folks

July 24, 2014 - 1:07pm

Andrew Riley leads us through a high level walkthrough of what Code Reviews are and why we need them. In this talk he covers what we check for at Mediacurrent (syntax, security, efficiency etc) and why code reviews are important for our customers and any company that writes their own code.

Additional Resources

Drupal 8 In Pictures (for Users) | Mediacurrent Blog

Forum One: Drupal 8 Code Sprint at the Jersey Shore

July 24, 2014 - 10:52am

On the heels of our own Drupal 8 code sprint in DC, I spent the last weekend with the New Jersey Drupal group who organized a Drupal 8 code sprint in Asbury Park, NJ – and although I was never greeted by The Boss, I was pleased to participate thanks to the generosity of the event organizers.

Issue-Focused

I worked on the MenuLink NG part 1 issue extensively with Peter Wolanin and YesCT. This issue is part of the [Meta] New plan, Phase 2 issue which proposed performance improvement and UI improvement in Drupal 8. This issue originally had a 600KB patch, but to make it more reviewable/committable the issue was split into five child issues.

Three of us spent a solid two days and more than 30 hours addressing every single point that had been raised by reviewers – and which had been holding up the process of adding this to Core.

Image courtesy of Blink Reaction

About this Issue (a high level overview)

A site builder or developer can create menu links in Drupal via configuration by changing the weight, position, creating links in menu, or in code. All these different types of menu links need to be rendered together in menus, so that they present the same in the API to developers. The developer experience on this issue needs to be easy, as almost everything depends on menu items.

While we toiled on this issue, other sprinters worked on DrupalCon Austin’s Consensus Banana, testing the migration path from Drupal 6 to Drupal 7, along with some other issues.

Results and Commits

The sprint was a very productive one, and resulted in Menu part 1 and Menu part 2 being committed to Core, which was a beta-blocker issue. As of this sprint there were seven beta-blocker issues, but solving the Menu issue helps to put us one step closer to the Drupal 8 Beta release!

For those interested, here are the commits for part 1 and part 2. And for those needing a chuckle, Alex “The Situation” Pott – who thankfully preferred DCC (Drupal Core Commits) over GTL (Gym, Tan, Laundry) – drew this goaty looking lama to celebrate his commit

Image courtesy of Blink Reaction

It was very rewarding to work for a weekend with this group of talented developers, and I think we all left the shore content in the knowledge that we’d made strides toward bringing Drupal 8 that much closer to completion.

Check out these other pictures taken by Peter Wolanin and DrupalCamp NJ at the event »

Dries Buytaert: The business behind Open Source

July 24, 2014 - 6:38am
Topic: DrupalAcquiaBusinessThe future

A few days ago, I sat down with Quentin Hardy of The New York Times to talk Open Source. We spoke mostly about the Drupal ecosystem and how Acquia makes money. As someone who spent almost his entire career in Open Source, I'm a firm believer in the fact that you can build a high-growth, high-margin business and help the community flourish. It's not an either-or proposition, and Acquia and Drupal are proof of that.

Rather than an utopian alternate reality as Quentin outlines, I believe Open Source is both a better way to build software, and a good foundation for an ecosystem of for-profit companies. Open Source software itself is very successful, and is capable of running some of the most complex enterprise systems. But failure to commercialize Open Source doesn't necessarily make it bad.

I mentioned to Quentin that I thought Open Source was Darwinian; a proprietary software company can't afford to experiment with creating 10 different implementations of an online photo album, only to pick the best one. In Open Source we can, and do. We often have competing implementations and eventually the best implementation(s) will win. One could say that Open Source is a more "wasteful" way of software development. In a pure capitalist read of On the Origin of Species, there is only one winner, but business and Darwin's theory itself is far more complex. Beyond "only the strongest survive", Darwin tells a story of interconnectedness, or the way an ecosystem can dictate how an entire species chooses to adapt.

While it's true that the Open Source "business model" has produced few large businesses (Red Hat being one notable example), we're also evolving the different Open Source business models. In the case of Acquia, we're selling a number of "as-a-service" products for Drupal, which is vastly different than just selling support like the first generation of Open Source companies did.

As a private company, Acquia doesn't disclose financial information, but I can say that we've been very busy operating a high-growth business. Acquia is North America's fastest growing private company on the Deloitte Fast 500 list. Our Q1 2014 bookings increased 55 percent year-over-year, and the majority of that is recurring subscription revenue. We've experienced 21 consecutive quarters of revenue growth, with no signs of slowing down. Acquia's business model has been both disruptive and transformative in our industry. Other Open Source companies like Hortonworks, Cloudera and MongoDB seem to be building thriving businesses too.

Society is undergoing tremendous change right now -- the sharing and collaboration practices of the internet are extending to transportation (Uber), hotels (Airbnb), financing (Kickstarter, LendingClub) and music services (Spotify). The rise of the collaborative economy, of which the Open Source community is a part of, should be a powerful message for the business community. It are the established, proprietary vendors whose business models are at risk, and not the other way around.

Hundreds of other companies, including several venture backed startups, have been born out of the Drupal community. Like Acquia, they have grown their businesses while supporting the ecosystem from which they came. That is more than a feel-good story, it's just good business.

drunken monkey: Updating the Search API to D8 – Part 3: Creating your own service

July 24, 2014 - 4:28am

Even though there was somewhat of a delay since my last post in this series, it seems no-one else has really covered any of the advanced use cases of Drupal 8 in tutorials yet. So, here is the next installment in my series. I initially wanted to cover creating a new plugin type, but since that already requires creating a new servive, I thought I'd cover that smaller part first and then move on to plugin types in the next post.
I realize that now already a lot more people have started on their Drupal 8 modules, but perhaps this will make this series all the more useful.

Services in Drupal 8

First, a short overview of what a service even is. Basically it is a component (represented as a class) providing a certain, limited range of functionality. The database is a service, the entity manager (which is what you now use for loading entities) is a service, translation, configuration – everything handled by services. Getting the current user – also a service now, ridding us of the highly unclean global variable.
In general, a lot of what was previously a file in includes/ containing some functions with a common prefix is now a service (or split into multiple services).

The upsides of this is that the implementation and logic is cleanly bundled and properly encapsulated, that all these components can easily be switched out by contrib or later core updates, and that these systems can also be very well tested with unit tests. Even more, since services can be used with dependency injection, it also makes it much easier to test all other classes that use any of these services (if they can use dependency injection and do it properly).

(For reference, here is the official documentation on services.)

Dependency injection

This has been covered already in a lot of other blog posts, probably since it is both a rather central concept in Drupal 8, and a bit complicated when you first encounter it. However, before using it, I should still at least skim over the topic. Feel free to skip to the next heading if you feel you already know what dependency injection is and how it roughly works in Drupal 8.

Dependency injection is a programming technique where a class with external dependencies (e.g., a mechanism for translating) explicitly defines these dependencies (in some form) and makes the class which constructs it responsible for supplying those dependencies. That way, the class itself can be self-contained and doesn't need to know about where it can get those dependencies, or use any global functions or anything to achieve that.

Consider for example the following class:

<?php
class ExampleClass {

  public function getDefinition() {
    return array(
      'label' => t('example class'),
      'type' => 'foo',
    );
  }

}
?>

For translating the definition label, this explicitly uses the global t() function. Now, what's bad about this I, hear you ask, it worked well enough in Drupal 7, right?
The problem is that it becomes almost impossible to properly unit-test that method without bootstrapping Drupal to the point where the t() function becomes available and functional. It's also more or less impossible to switch out Drupal's translation mechanism without hacking core, since there is no way to redirect the call to t().

But if translation is done by a class with a defined interface (in other words, a service), it 's possible to do this much cleaner:

<?php
class ExampleClass {

  public function __construct(TranslationServiceInterface $translation) {
    $this->translation = $translation;
  }

  public function getDefinition() {
    return array(
      'label' => $this->translation->translate('example class'),
      'type' => 'foo',
    );
  }

}
?>

Then our example class just has to make it easily possible for code that wants to instantiate it to know how to pass its dependencies to it. In Drupal, there are two ways to do this, depending on what you are creating:

  • Services, which themselves use dependency injection to get their dependencies (as you will see in a minute) have a definition in a YAML file that exactly states which services need to be passed to the service's constructor.
  • Almost anything else (I think) uses a static create() method which just receives a container of all available services and is then responsible for passing the correct ones to the constructor.

In either case, the idea is that subclasses/replacements of ExampleClass can easily use other dependencies without any changes being necessary to code elsewhere instantiating the class.

Creating a custom service

So, when would you want to create your own service in a module? Generally, the .module file should more or less only contain hook implementations now, any general helper functions for the module should live in classes (so they can be easily grouped by functionality, and the code can be lazy-loaded when needed). The decision to make that class into a service then depends on the following questions:

  • Is there any possibility someone would want to swap out the implementation of the class?
  • Do you want to unit-test the class?
  • Relatedly, do you want dependency injection in the class?

I'm not completely sure myself about how to make these decisions, though. We're still thinking about what should and shouldn't be a service in the Search API, currently there is (apart from the ones for plugins) only one service there:

The "Server task manager" service

The "server tasks" system, which already existed in D7, basically just ensures that when any operations on a server (e.g., removing or adding an index, deleting items, …) fails for some reason (e.g., Solr is temporarily unreachable) it is regularly retried to always ensure a consistent server state. While in D7 the system consisted of just a few functions, in D8 it was decided to encapsulate the functionality in a dedicated service, the "Server task manager".

Defining an interface and a class for the service

The first thing you need, so the service can be properly swapped out later, is an interface specifying exactly what the service should be able to do. This completely depends on your use case for the service, nothing to keep in mind here (and also no special namespace or anything). In our case, for server tasks:

<?php
namespace Drupal\search_api\Task;

interface ServerTaskManagerInterface {

  public function execute(ServerInterface $server = NULL);

  public function add(ServerInterface $server, $type, IndexInterface $index = NULL, $data = NULL);

  public function delete(array $ids = NULL, ServerInterface $server = NULL, $index = NULL);

}
?>

(Of course, proper PhpDocs are essential here, I just skipped them for brevity's sake.)

Then, just create a class implementing the interface. Again, namespace and everything else is completely up to you. In the Search API, we opted to put interface and class (they usually should be in the same namespace) into the namespace \Drupal\search_api\Task. See here for their complete code.
For this post, the only relevant part of the class code is the constructor (the rest just implements the interface's methods):

<?php
class ServerTaskManager implements ServerTaskManagerInterface {

  public function __construct(Connection $database, EntityManagerInterface $entity_manager) {
    $this->database = $database;
    $this->entity_manager = $entity_manager;
  }

}
?>

As you can see, we require the database connection and the entity manager as dependencies, and just included them in the constructor. We then save them to properties to be able to use them later in the other methods.

Now we just need to tell Drupal about our service and its dependencies.

The services.yml file

As mentioned earlier, services need a YAML definition to work, where they also specify their dependencies. For this, each module can have a MODULE.services.yml file listing services it wants to publish.

In our case, search_api.services.yml looks like this (with the plugin services removed):

services:
  search_api.server_task_manager:
    class: Drupal\search_api\Task\ServerTaskManager
    arguments: ['@database', '@entity.manager']

As you see, it's pretty simple: we assign some ID for the service (search_api.server_task_manager – properly namespaced by having the module name as the first part), specify which class the service uses by default (which, like the other definition keys, can then be altered by other modules) and specify the arguments for its constructor (i.e., its dependencies). database and entity.manager in this example are just IDs of other services defined elsewhere (in Drupal core's core.services.yml, in this case).

There are more definition keys available here, and also more features that services support, but that's more or less the gist of it. Once you have its definition in the MODULE.services.yml file, you are ready to use your new service.

Using a service

You already know one way of using a service: you can specify it as an argument for another service (or any other dependency injection-enabled component). But what if you want to use it in a hook, or any other place where dependency injection is not available (like entities, annoyingly)?

You simply do this:

<?php
/** @var \Drupal\search_api\Task\ServerTaskManagerInterface $server_task_manager */
$server_task_manager = \Drupal::service('search_api.server_task_manager');
$server_task_manager->execute();
?>

That's it, now all our code needing server tasks functionality benefits from dependency injection and all the other Drupal 8 service goodness.