fidzu : Drupal

NYC Camp ("nice camp") is an annual conference featuring talks, industry summits and code sprinting all aimed at accelerated learning and contributing to Drupal and related open source projects."

This year NYC Camp 2014 is being held The United Nations April 10th-13th.

16 Apr 2014 3:27am GMT

Did you know NYC Camp has a massive list of completely free Drupal trainings scheduled for Thursday April 10th??? Check out the line-up and sign up!

• Drupal Decision Makers
• Beginning Drupal
• Twig Training
• Open Atrium Training
• Install Clinic
• Get Started With Drupal Training
• Intermediate Drupal
• GIT Training
• Site Building +
• Openshift Training, Deploying Drupal In The Cloud
• Advanced RWD
• Thinking In Drupal
• Drupal For Content Creators
• Intro To Module Development

Don't Forget To Register!

Make sure you create an account and register for NYC Camp 2014, Registration is completely free but the UN security is fairly strict so please register for the camp and then you can go ahead and sign up for a free training on any of the training description pages!

16 Apr 2014 3:27am GMT

NYC Camp (aka 'nice camp') is an annual 4 day mini Drupal conference held in NYC dedicated to Drupal learning and contribution. Best of all it's completely free and volunteer powered! This past year we had a spectacular event packed with trainings, sessions, summits and sprints. We've got a great event in the works and expect NYC Camp 2014 to rock even harder than last year!

Interested in volunteering? Yes You! Sign up to participate and contribute to your NYC Drupal community here

Stay up to date on all upcoming NYCCamp News by following us on twitter @NYCCampDrupal

16 Apr 2014 3:27am GMT

15 Apr 2014 10:50pm GMT

New York city Drupal camp happened last weekend in United Nations HQ and there was, among numerous other things, Media sprint going on. Organizers did their best to bring some of the most active Drupal Media contributors on-site. We are very happy and thankful that they made this possible, as we managed to achieve some very important steps forward.

Plans for Drupal 8

Main part of our efforts at the camp was roadmap for Media in Drupal 8 as part of which we achieved few very important conclusions:

• Storage components: there are still different opinions about the storage part (AKA "File entity" approach vs. "Media entity" approach - for more info check https://groups.drupal.org/node/384813). We decided that this is fine. We will continue to work on both solutions, while trying to find as many sticking points as possible and share as much code as possible. Entire ecosystem will be split into several sub-components in order for this to be possible.
• Decoupled components architecture: as already mentioned we're dividing Media ecosystem into smaller pieces, which will be easier to develop and maintain. We will make sure to make every component as generally usable as possible. This will allow us to use them with both storage solutions and also, when applicable, in more general contexts (not necessary related to media itself). "Full featured" media solutions will still exist, but will mostly provide glue that will make individual components able to work together.
• Media browser/selector/creator: this part of the system will be responsible for browsing media collections, picking and/or creating individual or multiple media items. It will be used in different contexts as fields (entity reference, file, image, ...), WYSIWYG, global, etc. This component will not be related to media by it's nature. It should be possible to use it also in other similar use-cases (browsing and picking nodes for an entity reference field for example). Existing tools/systems should be used where possible (Views for entity browsing, existing field widgets for entity creation, ...).
• WYSIWYG integration: core now supports image embeds by default, but we still want to be able to embed other types of media. WYSIWYG entity embed framework will be responsible for that. It will be able to embed any entity using techniques that were already tested in D7. Entity-specific solutions that we know from D7 world (node_embed, ...) will become obsolete as a result of that.
• Display configuration: we will create two levels of display configuration. Field formatter level will provide more basic functionality, while ensuring simpler interface for site builders and administrators. This approach is expected to be used on simpler sites. Media/File entity render will, on the other hand, provide more powerful display configuration system with more complexity. Both storage solutions will share some parts of display configuration components, but it will not be possible to re-use everything.
• 3Rd party providers: both storage solutions will need own 3Rd party integrations due to fundamental differences in storage implementation.

Next events/sprints

• Sprint at DrupalCamp Alpe-Adria (May 17th - 20th)
• Week-long sprint at DrupalCon Austin (June 1st - 7th)
• Week-long sprint at DrupalCOn Amsterdam (September 28th - October 4th)
• Week-long sprint at BADCamp (approx. October 21st - 26th)

Getting involved

In order for Media to really rock in D8 we need a lot of help (by this I mean A LOT!). Are you personally interested in media on Drupal or you run a Drupal company/shop and have to deal with funky media problems and desperately need a powerful and extensible solution for that? Are you able to dedicate some of your (or one or your employees) time to achieve that goal?

We need you! No matter which skills you have! We need help with back-end and front-end development. We also need design/UX skills to create good editorial experience. Are you not a coder, but have good ideas? We need those!

You can reach us on #drupal-media or on groups.drupal.org/media. There will be weekly "scrums" held in Google Hangout onAir every Tuesday at 3:30PM GMT (follow groups.drupal.org/media for announcements).

We need your user stories

There are as many possible media use-cases as there are Drupal websites. In order to be able to design the system in a way that will work for most possible situations we need your feedback - your user stories. Please take few minutes to think about your past project that dealt with Media and try to remember interesting problems that you'be been facing. Then use our form and send them our way in a form of a user story.

Google Summer of Code 2014

We have two quite strong media related project proposals for this year's Summer of code. We are hoping for both of them to be accepted. We will be able to publish more informations about that in the second part of April.

Please help Aaron Winborn

Aaron is a long time Drupal contributor, author of many media-related modules and a great and inspiring person. He is fighting ALS and he needs our help. Please consider contributing to his fund to help them make his and his families life just a little bit easier. Thank you!

We would like to thank camp organizers one more time. They prepared an unforgettable event for us. We would definitely not be able to achieve this progress without their support!

15 Apr 2014 9:09pm GMT

15 Apr 2014 5:21pm GMT

Sometimes you need to prevent a site, page or everything at a particular path from showing up in Google search. I've heard people say to just disallow the page in robots.txt file. This is actually incorrect.

read more

15 Apr 2014 2:55pm GMT

Some organizations are very serious about their logos. They produce exhaustive guidelines on how their logo should and should not be used.

The Drupal community takes the opposite approach. The Drupal logo is called "Druplicon" and is released under the GPL license. That licensing allows designers to do whatever they want with the logo.

That design freedom has led to some funny, imaginative and downright strange variations on the Drupal logo.

Here are 27 of our favorites from events around the world.

15 Apr 2014 2:28pm GMT

15 Apr 2014 1:36pm GMT

15 Apr 2014 12:20pm GMT

In this screencast, I explain how we can link (register) one or multiple OSF Web Services networks to a single OSF for Drupal instance. I discuss how this OSF Web Services mechanism can be used to bring datasets from multiple different OSF instances into the same Drupal portal. I also cover how we can use the same OSF Web Services network as the backend for multiple Drupal portals (which uses OSF for Drupal).

We briefly discuss the distributed aspect of the Open Semantic Framework (OSF), but this topic will be discussed more in deep in a subsequent screencast.

15 Apr 2014 12:05pm GMT

Files:

PANO_20140322_120703.jpg

IMG_2591.JPG

IMG_2624.JPG

IMG_2575.JPG

IMG_2592.JPG

15 Apr 2014 10:37am GMT

15 Apr 2014 8:52am GMT

  <?php
    $start_date = strtotime($data->field_field_duration[0]['raw']['value']);
    $end_date   = strtotime($data->field_field_duration[0]['raw']['value2']);
    echo time() < $start_date ? 'not started' : (time() < $end_date ? 'underway' : 'closed');
  ?>

15 Apr 2014 8:17am GMT

Last month, we wrapped up a project for nonprofit-oriented payment processor, iATS Payments. iATS Payments wanted to invest in gaining wider adoption of their services and enlisted ThinkShout's help in building a PHP wrapper for their existing SOAP API.

Being a bunch of software engineers who have implemented our fair share of APIs (both good and bad), we knew we had to achieve certain goals if we were going to ease the adoption of iATS Payments within PHP applications:

• Comprehensive: The wrapper handles all communication with the iATS Payments SOAP API, validation of API calls, and error handling.
• Well documented: We made use of phpDocumentor to generate easily browsable documentation from our code comments.
• Reliable: Via a comprehensive test suite covering every API call written in PHPUnit.

With the new PHP wrapper finished and unit tests passing, our attention shifted to the project we felt would most benefit from the work we'd done: the Commerce iATS Drupal module. This module leverages Drupal Commerce to facilitate payment processing via iATS Payments on any Drupal website.

We had already integrated Commerce iATS into some of our clients' websites, so we knew it was a great module, but it was written before there was a standard iATS Payments PHP wrapper and contained some unwieldy code that could be eliminated by using the new PHP wrapper. With support from the community and sponsorship from iATS, we rewrote the module, drastically reducing complexity, which any engineer can appreciate, and improved stability, which site owners love even more. We're excited to replicate the success of our partnership with MailChimp, which created a win for the community, the vendor, and, yes, ThinkShout.

Refactoring Commerce iATS

In refactoring Commerce iATS, we didn't just plug in the PHP wrapper and call it a day. While Commerce iATS was originally written with support for only credit card payments, our PHP wrapper supports all payment methods provided by iATS Payments and we wanted to make sure Commerce iATS had room to grow and take advantage of those payment methods.

Some of the problems

Looking through the code of the existing Commerce iATS module, we realized the current design would not scale well as we added additional payment methods.

As an example, take a look at the 2.x-dev release of Commerce iATS.

Here the function commerce_iats_soap_process_submit_form_submit() is being used to handle a lot more logic than a form submit handler ideally would. Breaking it down:

• There's some tight integration with the Commerce Card on File module. This could be broken out into a different payment method type, avoiding the call to module_exists().
• A lot of conditions are used to build the API request, depending on which payment method triggered the form submit handler. This won't scale well when more payment methods are added.
• A new transaction is created based on the response from the iATS Payments API.
• More tight integration with Commerce Card on File.

A lot of code in commerce_iats_soap_process_submit_form_submit() is later duplicated when commerce_iats_customer_code_charge_submit_form_submit() is called.

The refactor

We set out to redesign the module's architecture and rebuild it with modularity and expansion in mind. Here's what we did.

Created a new standard payment processing function

• This function handles the API call, response handling, transaction creation and logging.
• To handle multiple payment methods, the function accepts a callback function as a parameter. This callback function is the function that makes the API call via the PHP Wrapper and returns the response.

The first lines of commerce_iats_process_payment() demonstrate how the callback function is used:

<?php
function commerce_iats_process_payment($payment_method, $payment_data, $order, $charge, $payment_callback) {
  // Process the payment using the defined callback method.
  $response = $payment_callback($payment_method, $payment_data, $order, $charge);

Broke payment methods out into their own include files

As an example, here's the credit card payment method. Each payment method file contains these standard Commerce functions (where credit_card is the payment method:)

• commerce_iats_credit_card_settings_form()
• commerce_iats_credit_card_submit_form()
• commerce_iats_credit_card_submit_form_validate()
• commerce_iats_credit_card_submit_form_submit()

Then we added our own callback function, commerce_iats_process_credit_card_payment().

The callback function handles building the API request and getting a response from the API. To show how this works, here's a line from commerce_iats_credit_card_submit_form_submit():

<?php
return commerce_iats_process_payment($payment_method, $payment_data, $order, $charge, 'commerce_iats_process_credit_card_payment');

As you can see, all the payment information from the form submit handler is being passed into commerce_iats_process_payment(). That function then calls the callback function commerce_iats_process_credit_card_payment() to make the API call and get the response.

This design is very easy to extend and allows us to add as many additional payment methods as we need in a very clean way. We were able to use this design to implement Commerce Card on File as a submodule of Commerce iATS, eliminating that dependency from the base module.

Roadmap and next steps

All our work on Commerce iATS is currently available in the 2.0-beta1 release. Please take a look and let us know if you have any feedback.

We're already hard at work along with our partners at iATS Payments to integrate more of their payment processing facilities into the Commerce iATS module. While the module currently only supports credit card payments, ACH/EFT and Direct Debit payments will arive before DrupalCon Austin. Speaking of, both ThinkShout and iATS Payments will be attending and spending some time at the iATS booth, number 508. Come find us to say hello and talk some e-commerce.

Keep an eye on the Commerce iATS project page and this blog for more updates.

15 Apr 2014 7:00am GMT

We're back from another successful Drupal NYC Camp!

A great event as always (thanks to Forest Mars and all the other volunteers and organizers that made the event possible), this year the event attracted more than 800 attendees and was held at a truly awesome venue: the United Nations.

Forum One's presence this year was bigger than ever! Five of us attended, four of whom spoke at five different sessions covering a variety of topics:
• Keenan Holloway talked to a packed room with his tongue-twisting, alliteratively-titled session: Paraphrasing Panels, Panelizer and Panopoly;
• Chaz Chumley showed his extensive knowledge of the upcoming Drupal 8 Theming system - look for his book on the same topic later this year;
• Michaela Hackner joined forces with Chaz Chumley to highlight some of our recent work with the American Red Cross on the Global Disaster Preparedness Center in a session called Designing for Disasters: An Iterative Progression Towards a More Prepared World;
• and William Hurley (that's me!) was honored to have the opportunity to talk about Building Interactive Web Applications with Drupal, as well as Developing Locally with Virtual Machines at the DevOps summit (this latter one, sadly, wasn't recorded due to some technical difficulties). I was blown away by the attendance at both of my sessions and was honored to be able to share some of our challenges and solutions at each.

These camps aren't solely about sessions, of course. While not all of us were able to stay the whole weekend, Kalpana Goel stayed through Monday to work on some of the Drupal 8 sprints that were going on.

We love the opportunity to give back to the community in as many ways as possible, in code contributions to Drupal 8, contributed modules and also attending and speaking whenever possible. If you appreciate our expertise and would like us to speak at an event, drop us a line at marketing (at) forumone (dot) com and we'll be happy to participate!

14 Apr 2014 8:27pm GMT