This is an interesting topic to get to know more about Drupal core activity. We will be looking into ‘how to use drupal echo on request?’ and ‘how many process it has gone through?’ Basically the process flow of Drupal Pipeline to interpret the steps & finally respond to the end users. Which is called as Bootstrap Process.

Having a little bit of knowledge on bootstrap could help us to develop & customized complicated area of drupal development.

Sample:
When we hit URL in browser: https://domain.com/node/234. which is a standard node page created under any of the Bundle.

…

Creating comments programmatically in Drupal 8 is incredibly easy once you know just which fields are required and why. In Drupal 8, comments are now full-featured, fieldable entities — just like nodes or taxonomy terms. In addition to unifying the way we create content, comments, and other entities, this has made Drupal’s commenting system much more robust and flexible.

Recently, we needed to allow certain users to leave short notes about a node (almost like revision notes without the revisions). Only certain users would be able to leave these notes and the notes are added as part of a custom form. This meant that we needed to handle comment creation ourselves. After much googling, we finally figured out just how to create comments manually.

To create a new comment, you need to create a comment entity in code and then save it. There are a lot of required fields and we'll go over each one below. But first, here’s the code:

// To create a new comment entity, we'll need `use` (import) the Comment class.
use Drupal\comment\Entity\Comment;
 
// The function name doesn't matter. Just put the the function body where you need it.
function my_modules_function_or_method() {
 
  // First, we need to create an array of field values for the comment.
  $values = [
 
    // These values are for the entity that you're creating the comment for, not the comment itself.
    'entity_type' => 'node',            // required.
    'entity_id'   => 42,                // required.
    'field_name'  => 'comment',         // required.
 
    // The user id of the comment's 'author'. Use 0 for the anonymous user.
    'uid' => 0,                         // required.
 
    // These values are for the comment itself.
    'comment_type' => 'comment',        // required.
    'subject' => 'My Awesome Comment',  // required.
    'comment_body' => $body,            // optional.
 
    // Whether the comment is 'approved' or not.
    'status' => 1,                      // optional. Defaults to 0.
  ];
 
  // This will create an actual comment entity out of our field values.
  $comment = Comment::create($values);
 
  // Last, we actually need to save the comment to the database.
  $comment->save();
}

The first three required fields are telling Drupal what entity the comment should be attached to.

• entity_type: This is the entity to which you want to attach the comment. If you're creating a comment on an article or basic page, for example, this would be node.
• entity_id: The id of the entity to which you want to attach the comment. If you're attaching to a node, this would be its nid.
• field_name: The field on the entity to which this comment should be attached. Note: This is something new in Drupal 8. In D8, you can have multiple comment fields on an entity and those comments' fields can use different comment types. The default article content type is the only content type that comes with a comment field. If you want to enable comments on your own content type, you have to add your own comment field which receives a unique machine name. That machine name is the value you would put here.

The uid field tells Drupal which user authored the comment.

The remaining values are all specific to the comment itself.

• comment_type: The type of comment to create. Note: This is new in Drupal 8 too. You can have different types of comments with completely different fields, just like nodes or taxonomy terms. Think of this as the comment "bundle" if you're familiar with that term. The default comment type is just comment.
• subject: Every comment has a subject field, just like the title field on a node.
• comment_body: This field is provided by default just like the body field on nodes. However, it can be removed like any other field.
• status: Set this to 1 if you would like the comment to be automatically approved. Otherwise, an administrator will need to approve it.
• field_foobar: This isn't in the example, but comment types can have custom fields just like any other content entity. If you have custom fields on your comment type, you can just use the field’s machine name and provide a default value here.

In talking to Drupal shops and agency about how they do support, we've sometimes heard something like:

We have junior developers / paid interns handle one-off support and maintenance requests as a way to train them!

We provide white-label fixed-monthly-cost support for agencies, so I am a little biased. :-) But I used to run a small Drupal agency and I truly believe that there are a number of potential issues with this view.

From my perspective, certainly: IT IS NOT OK to leave support and maintenance to junior developers.

I'll try to give some detail to explain my viewpoint on this... Read on to learn more!

Recently I've been writing a number of blogpost tutorials about the Drupal 8 APIs. If you like, you can read all tutorials so far, collected and broken down by topic, roughly following the breakdown in the official documentation.

The tutorials have been written with a focus on achievable results, and with accompanying screenshots explaining what you should see if you work through the examples; like this one:

Read more of "Tutorials on the Drupal 8 APIs, collected"

Come for the code, stay for the community. That’s the mantra of the Drupal community. It’s the reason many of us are here. It’s why we contribute in our spare time, spend our weekends organizing Drupal events, attend week-long DrupalCons. As a community we are continuing to grow and change, just like the project. DrupalCon programming should be changing too.

In particular, we at the Drupal Association want to make sure that the community programming at DrupalCons best serves the community it is made for. And that means that we need fresh voices, more support, and new ideas. We are asking for a new crop of community leaders and leading companies to step in and help us move community programming at DrupalCons forward.

How community programming got here:
Originally, community conversations at DrupalCon took place in sessions for the community track, running alongside all the other content at DrupalCons. The community track allowed for presentations on topics related to our community and although it was valuable to raise the topics, there were concerns that the session format made it difficult to continue the momentum after the Con. Further, the community track was not well attended.

At DrupalCon Prague in 2013, we launched the first Community Summit, a day-long event, on the Monday of DrupalCon week. Morten DK, Addison Berry, and others (thank you all - you have been great collaborators) ran the program and led a number of very useful conversations.

At the past few DrupalCons, Donna Benjamin has stepped up to lead unconference-style Community Summits open to anyone who wants to join, contribute to, or lead a local community. Through the unconference format, the Summit has been able to foster conversations about nonviolent communication, camp budgeting, public speaking, local community activities and more. Unfortunately, unconferences seem to stop once the Summit is over, and continuing conversations and action plans prove difficult with a community spread across the world.

Where is community programming headed?
As we continue to grow as a project and community, we recognize that we need to make sure we have the right format and space for our community to continue to grow and learn from each other.
Community programming needs some new faces to help move us forward into a world of Drupal 8, new camps, project-wide discussions, etc. We are a community full of incredible leaders and we are putting out a call for some of you to stand up and help us design the future for our community.

Community programming also needs a fiscal champion - a sponsor who fully recognizes the importance of investing in our community. Our community leaders are volunteers and e want to minimise barriers for participation. To date, the Community Summit has been free to attend. We’d like to keep it that way. But we’d like to provide attendees with lunch, and workshop tools like post-it notes, markers and flipcharts. Because we offer the Summit at no cost, we have needed to limit the space available which has meant it has booked up early, and many who would have liked to attend, have missed out.

We need you to contribute to community programming
We need you. And we are asking - can you contribute? We would love a team of community organizers to work with the Drupal Association on community programming at DrupalCon Baltimore and beyond. We need a sponsor or two to financially support the Community Summit and allow us to continue to grow it.

We are close to finalizing our space at the Baltimore Convention Center and are also nearing our online registration launch. We need to determine what the Community Summit will be so we can allocate the appropriate space and include tickets on our website. If you can help, take action now by contacting us at the Drupal Association before November 21, 2016. There are a few ways to get involved:

• Can you help coordinate and organize programming (summits, bofs, etc) at DrupalCon? Great! Email amanda@association.drupal.org.
• Can you sponsor the Summit and show how much you value the community? Please reach out to carrie@association.drupal.org to pitch in.

Are we supporting new initiatives like Drupal Diversity in the best way that we can? Are we providing our Camp Organizers with the opportunity to convene and share tips and tricks to running amazing camps around the globe? What other programming can we be providing?  Comment below to let us know what you’d like to see from community programming at DrupalCons.

Thank you for your endless support of this amazing community.

Here goes another Drupal 8 post by one of our Drupal developers!

Read more

When we were considering switching to the Pantheon hosting platform, one of the features that made us confident in our decision is what they call Multidev.

At its core, Multidev is just a method of spinning up complete environments for code that hasn't yet been merged into the main development branch. The main benefit to this is that it makes it incredibly easy to build a complete website environment that parallels your live site where any team member can functionally and visually test changes before they're fully merged.

This blog post covers the Drupalize.Me team's development workflow, and how we're using Pantheon's Multidev to be more efficient.

Today, when you install Drupal 8.2, the out-of-the-box media handling is very basic. For example, you can upload and insert images in posts using a WYSIWYG editor, but there is no way to reuse files across posts, there is no built-in media manager, no support for "remote media" such as YouTube videos or tweets, etc. While all of these media features can be added using contributed modules, it is not ideal.

This was validated by my "State of Drupal 2016 survey" which 2,900 people participated in; the top two requested features for the content creator persona are richer image and media integration and digital asset management (see slide 44 of my DrupalCon New Orleans presentation).

This led me to propose a "media initiative" for Drupal 8 at DrupalCon New Orleans. Since then a dedicated group of people worked on a plan for the Drupal 8 media initiative. I'm happy to share that we now have good alignment for that initiative. We want to provide extensible base functionality for media handling in core that supports the reuse of media assets, media browsing, and remote media, and that can be cleanly extended by contributed modules for various additional functionality and integrations. That is a mouthful so in this blog post, I'll discuss the problem we're trying to solve and how we hope to address that in Drupal 8.

Problem statement

While Drupal core provides basic media capabilities, contributed modules have to be used to meet the media management requirements of most websites. These contributed modules are powerful — look at Drupal's massive adoption in the media and entertainment market — but they are also not without some challenges.

First, it is hard for end-users to figure out what combination of modules to use. Even after the right modules are selected, the installation and configuration of various modules can be daunting. Fortunately, there are a number of Drupal distributions that select and configure various contributed modules to offer better out-of-the-box experience for media handling. Acquia maintains the Lightning distribution as a general purpose set of components including media best practices. Hubert Burda Media built the Thunder distribution and offers publishers strong media management capabilities. MD Systems created the NP8 distribution for news publishers which also bundles strong media features. While I'm a big believer in Drupal distributions, the vast majority of Drupal sites are not built with one of these distributions. Incorporating some of these media best practices in core would make them available to all end-users.

Second, the current situation is not ideal for module developers either. Competing solutions and architectures exist for how to store media data and how to display a library of the available media assets. The lack of standardization means that developers who build and maintain media-related modules must decide which of the competing approaches to integrate with, or spend time and effort integrating with all of them.

The current plan

In a way, Drupal's media management today is comparable to the state of multilingual in Drupal 7; it took 22 or more contributed modules to make Drupal 7 truly multilingual and some of those provided conflicting solutions. Multilingual in Drupal 7 was challenging for both end-users and developers. We fixed that in Drupal 8 by adding a base layer of services in Drupal 8 core, while contributed modules still cover the more complex scenarios. That is exactly what we hope to do with media in a future version of Drupal 8.

The plan for the Drupal 8 media initiative is to provide extensible base functionality for media handling in core that supports the reuse of media assets, media browsing, and remote media, and that can be cleanly extended by contributed modules for various additional functionality and integrations.

In order to do so, we're introducing a media entity type which supports plugins for various media types. We're currently aiming to support images and YouTube videos in core, while contributed modules will continue to provide more, like audio, Facebook, Twitter, etc. To facilitate media reuse, WYSIWYG image embedding will be rebuilt using media entities and a media library will be included to allow selecting from pre-existing media.

We consider this functionality to be the minimum viable product for media in Drupal 8 core. The objective is to provide a simple media solution to make Drupal 8 easy to use out of the box for basic use cases. This would help users of sites large and small.

A work-in-progress prototype of the proposed media library.

Expected timeline and call for help

We believe this could be achieved in a relatively short time — to be included in Drupal 8.3 or Drupal 8.4 as experimental modules. To help make this happen, we are looking for organizations to help fund two dedicated code sprints. The existing contributors are doing an amazing job but dedicated in-person sprints would go a long way to make the plans actually happen. If you are willing to help fund this project, let me know! Looking to help with the implementation itself? The media team meets at 2pm UTC every Wednesday. I also recommend you follow @drupalmedia for updates.

I tried to make a list of all people and organizations to thank for their work on the media initiative but couldn't. The Drupal 8 initiative borrows heavily from years of hard work and learnings on media related modules from many people and organizations. In addition, there are many people actively working on various aspects of the Drupal 8 media initiative. Special thanks to everyone who has contributed now and in the past. Also thank you to Gábor Hojtsy, Alex Bronstein and Janez Urevc for their contributions to this blog post.

In the last two months we released four portals for the Swiss tech publisher Netzmedien. All four websites are driven by the NP8 media distribution and their content is created and curated via Woodwing, a centralized multi-channel publishing platform.

Thanks to all who helped

Many people contribute to our membership campaigns and the recent campaign is no different. Thanks to Andrey, Ricardo, Martha, Ivo, and Tom, for sharing your stories. To everyone who joined or renewed, thank you for your support. And, to our members and supporters who answered the call to share our message, thank you too.

You not only help the community by growing our membership, you give us motivation too.

Focus on grants

Members fund our Community Cultivation Grants program. The grants help grow communities and build local relationships for Drupal. This connection made the grants program an appropriate focus for a membership campaign.

This campaign was based on an idea: you feel more connected within the Drupal community when you receive a grant. Participants told their stories because this idea resonated with them. We shared their stories about feeling connected and how the member-funded grant inspired them to make a local impact for Drupal.

Results

We didn't meet the specific goals of 265 new members and $10,918 in revenue. New member growth did not happen to the degree we wanted for this campaign. We got to 45% of goal for number of new members who joined. Our revenue from the new members made it to 73% of our goal for funds raised. However, this is accounting for all new membership in the time period, and not specifically attribution to the campaign itself.

The breakdown went like this:

• 120 signups by new members (100 Individual Members/ 20 Organization Members)
• $8,050 revenue raised ($3730 Individual Members/ $4330 Organization Members)

For more details, see the data here.

We had three other concurrent places for sign ups. Our main ADO page, DrupalCon Dublin registration, and a page for DrupalCamp Atlanta were available. Thanks Eric, Dave, Shellie, and the whole Atlanta team for the pilot run.

During the 52-day period, 520 members joined or renewed and we raised $35,348 in total revenue. So if the goals I had set were for new, renewing, and reactivated members, we'd have been successful. Call this a good lesson in goal setting!

The first landing page on drupal.org

We had a team effort to create a well-designed landing page for this campaign. We used new design tools to create the first landing page for membership on drupal.org.  We'll use the tools again to add visual interest to our campaigns and we'll continue testing to find what works and what doesn't.

More testing is needed

In our last campaign, the landing page on assoc.drupal.org had 16K pageviews. This campaign had only 25% of that traffic. This disproved the hypothesis that drupal.org would bring more traffic to a membership landing page.

We can see the banner launch and takedown had an impact on page traffic based on the data below. The hill showing on the graph shows the period we ran the banner (September 9-17). However, when we reintroduced the banner on September 28 through October 29, we saw no significant bump in traffic.

Traffic was 25% of the previous campaign landing page.

Social sharing makes a difference

Traffic spikes occurred around days we emailed to ask members to share the campaign. Not only do we see engagement from members, but there were spikes in membership sign-ups too.

We used a story-based approach

I used a storymapping exercise to think through this campaign concept to ensure we were telling a story that left readers satisfied. A story moves along a bell curve from exposition, to problem, to rising action, crisis, resolution, and falling action before the end. I'll try this again for the next campaign. The story-based approach helps to get our narratives into the bigger world and people are left with something they can remember and share.

Coming next

We are taking a deep look at how the drupal.org engineering team has made an impact in the community for our next campaign. We begin with the premise that the work the team does has helped increase the velocity of the innovation of Drupal. The team reduces the friction in the contribution journey and by doing so, we all benefit from their work. More on this to come on drupal.org in a few months.

Personal blog tags: Membership

On October twenty-third I had the pleasure of speaking at BADCamp X, the tenth Bay Area Drupal Camp in Berkeley California. BADCamp is my favorite Drupal event not only because I can drive to it, but also because of the great people and quality of the camp, I never miss it.

In the previous tutorial, you learnt how to customize content pages by using a Display Suite layout. Today, I want to show you how to use Display Suite fields. Display Suite fields shouldn’t be confused with the standard field system. The best way to think of a field in Display Suite is as just a fancy formatter. The field will only render content. You can’t use it to store values or define a widget like you can with the standard field system. You’ve already seen this fields in action. If you select a layout you’ll notice a bunch of new fields appear. These are Display Suite fields which are implemented by the module. A field can be created in two fields: in code or through the Display Suite user interface (UI). Today we’ll look at how to create fields using the Display Suite UI. In a future tutorial, you’ll learn how to implement a field in code.

Migrating my blog from Drupal 6 to 8 Kris Vanderwater 7 November 2016

• Read more about Migrating my blog from Drupal 6 to 8
• Add new comment

Drupal 8 has been out for over a year at this point. I worked extensively on helping to improve portions of core during the Drupal 8 cycle, but maintaining your own site is radically different from trying to develop the platform that site(s) will reside upon. Upgrading my blog is especially exciting for me because I was still on Drupal 6. Getting to jump directly from Drupal 6 to Drupal 8 is a pretty big win and the fact that Drupal 8 supports this out of the box was amazing. Now granted this is just my blog, it's not even 100 nodes, but still...

I sat down with Drupal Social Media Lead, Paul Johnson at Drupal Camp London 2016, a few weeks after DrupalCon Asia in Mumbai. Paul runs the official community social media accounts on Twitter and elsewhere. I feel Paul is a kindred soul, since he and I both love highlighting and celebrating the Drupal community's stories and achievements.

The @drupal Twitter account alone has more than 65 thousand followers and Paul uses his powers for good. "I get so much satisfaction out of it. There's nothing I like more than to hear that it's made a difference to somebody, or I've heard something and made other people aware of it privately and that's maybe solved a problem. Social media is used for quite a lot of things ... It's not just a marketing channel."

Our conversation

Follow Drupal on social media!

Here are the accounts Paul runs:

• Twitter
  • Drupal @drupal
  • DrupalCon @drupalcon
  • DrupalCon Europe @drupalconeur
  • DrupalCon North America @drupalconna
  • DrupalCon Asia @drupalconasia
• Facebook official Drupal group
• LinkedIn Drupal group

Here is the Drupal Association Social Media Request Form that Paul mentions during our conversation.

And here is the full, official Drupal social media directory.

Mentioned in the conversation

• http://celebratedrupal8.com/ and Paul's blog about how the campaign came together: Celebrate Drupal 8 - how it was done
• CTI Digital
• Great Ormond Street Hospital Drupal site
• Drupal 8 release podcasts with Dries Buytaert
  • Part 1 - Drupal 8 Release & Happy Birthday Dries Mega Episode!
  • Part 2 - Drupal 8 Release & Happy Birthday Dries Mega Episode!
  • Part 3 - Drupal 8 Release Mega Episode Bonus Behind the Scenes!

Celebrate D8!

Images used in the podcast video

• https://www.flickr.com/photos/amazeelabs/21513068989/ - https://creativecommons.org/licenses/by-nc-sa/2.0/
• https://www.flickr.com/photos/amazeelabs/21632469131/in/photostream/ - https://creativecommons.org/licenses/by-nc-sa/2.0/
• https://www.flickr.com/photos/peterlozano/21760271581/ - https://creativecommons.org/licenses/by/2.0/
• https://www.flickr.com/photos/68158920@N08/21437374299/ - https://creativecommons.org/licenses/by/2.0/

Podcast series: Drupal 8Skill Level: BeginnerIntermediateAdvanced

Proud to announce that Drupal was officially accepted to participate in Google's Code-In 2016 contest. More info @ https://codein.withgoogle.com/

At this point, Drupal needs mentors. Please contact me directly if interested in mentoring a few tasks or many tasks over next few months. We need all the help we can find. Tasks for GCI are meant to be easier for students ages 13-17. Amount of effort to mentor a few tasks is actually easy and enjoyable.

Not interested in mentoring, but have tasks for students? Do you want someone to write/test patches or create video tutorials for your module? Ping me for access to our task spreadsheet and add as many tasks as you want.

Chat with us in real time on IRC @ Freenode in #drupal-google

Drupal 8 Configuration Managment (CM) is a "killer feature" for a web Content Management System (CMS). When setting up a Drupal site, we spend a lot of time on site configuration: Roles, Permissions, Content Types, Menus, Vocabularies, etc. In most CMS's, all these changes are stored in their databases, making it hard to deploy, track, reuse and rollback important changes.

read more

Recorded October 26th

This episode we are all back in the ‘studio’ to talk about the great time most of us had at BADCamp the weekend prior. Ryan didn’t go so he won’t have much to say, but he will of course have his Final Bell, along with some Blog Mentions, Drupal News and a variety of failed humor.

Habitat for Humanity wanted to explore new ways to further highlight volunteer opportunities, broaden international reach, increase donations, and build an engaging desktop and mobile presence through its website, Habitat.org. Habitat undertook a new digital and content strategy to better help users find the information they are looking for to achieve these goals. The new Habitat.org recently was launched using Drupal 8 as its content management system.

Things I Learned from the DrupalTwig Slack: Volume 2

Welcome to Volume 2 of my adventures in learnings from the DrupalTwig Slack, a resource that continues to be the best source of (frontend) knowledge for Drupal. Again, if you haven't joined, do so. (Volume 1 is here.)

And without further ado, here's some things I've learned (or helped others to learn):