It is hard to believe, but we just finished our second-to-last board meeting of the year. The Association has grown and changed so much in 2014 and the November meeting was a great chance to talk about some of those changes and what we are planning for 2015. It was a somewhat short public meeting as we spent the bulk of our time in Executive Session to review the financial statements from the last quarter and the staff's proposed 2015 Leadership Plan and Budget. As always, you can review the minutes, the materials, or the meeting recording to catch up on all the details, and here's a summary for you as well.Staff Update
DrupalCons: DrupalCon Amstedam is over, and we are now focused on evaluation of the event - reviewing all the session and conference evaluations as well as closing up the financials for the event. We will have an in-depth review of the event at the December board meeting. Next up is DrupalCon Latin America, which is progressing nicely now with sessions accepted and registration open. One final DrupalCon note is that DrupalCon Los Angeles session submissions should open in January, so mark your calendars for that.
Community Programs: We just held our final Global Training Days for 2014 with over 80 companies on every continent but Antarctica (c'mon penguins!). This program has continued to evolve with new partnerships and currciulums used this time around, as well as a plethora of great photos and tweets sent our way.
Marketing and Communications: Joe Saylor and our team have been working with the Security team to develop a follow up to the recent security announcement focused on the lessons learned and changes our community has made in response to the situation. It's another great example of an Association and community volunteer partnership.Licensing Working Group
As we discussed in the August board meeting, some community members have expressed concern over the slow and sometimes inconsistent response to licensing issues on Drupal.org. In response, a volunteer group came together to draft a charter which was published for comment just after DrupalCon Amsterdam. Some of the main points from the charter include:
- All members (chair + 4-5) appointed by the Board
- Scope is limited to licensing of code and other assets on D.O only, not other sites, and not determining WHICH license is used
- Group responds to issues, does not police for issues
- Will maintain the whitelist of allowable assets
The Association board voted to adopt the charter, so our next steps are to recruit members, create a queue for licesning issues, and then provide some legal training for our new Working Group members. If you are interested in participating, you can nominate yourself for the Working Group. We are planning to present a slate of candidates to the board for approval in the January 2015 meeting.3rd Quarter Financials
Once per quarter, the board discusses the previous quarter's financial statements and then votes to approve and publish them. In the November meeting the board approved the Q3 financials:
I recently wrote a post highlighting how to read our financial statments, but will summarize here for you as well. Generally speaking, we are performing well ahead of our budgeted deficit spend. Though we had planned for a -$750,000 budget for 2014, a combination of slow tech team hiring, savings on Drupal.org contractor expenses, and some better than budgeted revenue means that we will not operate at nearly that level of loss for 2014. Instead the burden of the staffing investment we've made will really be felt in 2015. We'll see more of this and have a larger discussion when we release our budget and leadership plan next month.
As always, please let me know if you have any questions or share your thoughts in the comments.
Flickr phtoo: steffen.r
The next beta for Drupal 8 will be beta 4! Here is the schedule for the beta release.Tuesday, December 16, 2014 Only critical and major patches committed Wednesday, December 17, 2014 Drupal 8.0.0-beta4 released. Emergency commits only.
The Panels and Panelizer modules have opened up a whole world of options for layouts in Drupal, but too often the usage and features of these powerful tools get confused. My goal with this post is to explore some of the capabilities the Panels module has to offer before ever getting into the realm of using Panelizer.
At a high level, the goals of each of these modules break down into the following:
- Panels: Create custom pages with configurable layouts and components.
- Panelizer: Configure Panels layouts and content on a per instance basis for various entities.
Often, I see both modules added and used when Panelizer isn’t needed at all. What’s the problem with that? Introducing Panelizer when it isn’t needed complicates the final solution and can lead to unnecessary headaches later in configuration management, content maintenance, and system complexity.Panels and Panel Variants
Before the introduction of Panelizer, site-builders got by just fine with Panels alone. This original solution is still valid and just as flexible as it ever was. The secret in doing this lies in understanding how variants work and knowing how to configure them.Default Layout for All Nodes
Once Drupal finds a Panels page in charge of rendering the page request, Panels proceeds through the page’s variants checking the defined selection rules on each. Starting from the first variant, Panels evaluates each set of selection rules until one passes. As soon as a variant’s selection rules pass successfully, that variant is used and the rest below it are ignored. This is why it’s important to pay attention to the order in which you define your variants to ensure you place less strict selection rules later in the sequence.
Using this to your advantage, a good common practice is to define a default variant for your Panels page to ensure there is a baseline that all requests can use. To do this, you’ll need to define a new variant with no selection rules, so the tests always pass, and place it last in the series of variants. Since the selection rules on this variant will always pass, be aware that any variants placed below it will never be evaluated or used.Custom Layouts per Content Type
Once you have a generic default in place to handle the majority of content items for your Panels page, you can start to tackle the pages that might have more specific or unique requirements. You can do this by creating a new variant above your default and define selection rules to limit its use to only the scenarios you’re targeting.
A common use case for this is the changing layout for content based on content types. To build this out, you need to edit the default node_view Panels page and add a new variant. If this page variant is intended to handle all nodes of this type, I’ll typically name it with the name of the content type so it’s clear. The next step is to configure the selection rules by adding the “Node: Bundle” rule and select the content type we’re building for. Once you save the new variant, any detail pages for that content type should render using the new configuration.
Building on this, a single page can be expanded to handle any number of variants using any combination of selection rules necessary. It’s common to see a variant added for each content type in this way. Examples of further customizations that are possible include:
• A specific layout for a section of the site matching a specific URL pattern
• Separate layouts based on the value of a field on the entity
• Alternate views of a page if the user doesn’t have access to it
• Separate views of a page based on the user’s role
Thanks to CTools, these selection rules are also pluggable. This means if you can’t find the right combination of selection rules to enforce the limitation you need, it’s easy to write a new plug-in to add your specific rule.Avoiding Too Many Variants
Using the existing selection rules allows for a great deal of flexibility. Adding in custom plugins further improves your options to define any number of increasingly specific variants.
It is possible to take this too far, however. The cost of creating a new variant is that your layouts and content configurations are now forked further. Any common changes across them now have to be maintained in independent variants to maintain continuity.Visibility Rules
It’s important to also remember the other features Panels offers, including visibility rules. Visibility rules are configured on a per-pane basis inside a specific variant’s layouts. These rules offer the same conditions available in variant-level selection rules. Since they’re configured on individual panes, however, you can focus on the component-level differences between pages. A common use case for this is to use the same node variant for multiple content types with similar layouts and configure the unique panes with visibility rules to limit which pages they show on.
To elaborate on this, here’s an example. Assuming a default node variant with a two-column layout, we can define the common elements that all nodes will have, such as the page title, rendered content, and maybe a sidebar menu. If we then add the requirement that all article nodes include a list of similar articles in the sidebar, we can accomodate this by placing the correct pane in the sidebar and adding the visibility rule “Node: Bundle”. We’ll then configure it to use the current node being viewed and limit it to show only when that node is in the “Article” bundle. Now, whenever a node is displayed, it will show the common panes, but the block for similar articles will only show in the sidebar if we’re viewing a article node.Choosing the Right Approach
Once you get to the level of creating panel variants or visibility rules just for single pages, it’s usually time to ask if you’re using the right tool. When you’ve gotten to the point where individual page instances need to be different, you’ve come to the impasse of determining the best approach.
If it’s only a handful of pages that are each unique, then the most straightforward solution may be to create independent Panels pages for each of these.
If instead, individual instances of the same type need different layouts or configurations, then it may be time to install Panelizer to allow instance-specific overrides.
If you're interested in code quality and providing a means by which to bring Drupal beginners up-to-speed on the coding standards, I recommend reviewing code from all developers. I say "all" developers because everyone needs an editor.
The best way to force code reviews is to bake it into your development process. Use a tool like Gitlab (free hosted version) to prevent developers from committing code to authoritative branches. Instead, have them fork the project repository, and submit merge requests. Someone else can then review them. The reviewer can add in-line comments, wait for the developer to make changes, and then accept the request.
Here are some things to look for when reviewing Drupal code submissions. For some of these, we're assuming Git is being used for version control.
- Read, understand and follow the Coding standards.
- Install, enable, and use the Coder module on your development sites.
- For the purists out there, use the Coder Tough Love module as well.
- If you're running a continuous integration (CI) system like Jenkins, check the logs for new errors or warnings on new commits. Either way, make sure your development sandboxes have errors being reported to the screen so that developers can see any new errors that they generate. You'll find a lot of errors in your Drupal log if you're not doing this. (Make them refresh their DBs from your Dev site which already has this enabled.)
- Speaking of CI, add one or more code quality inspection tools to the mix such as SonarQube. There's actually a pre-configured Vagrant profile to build a VM with everything already set up. See CI: Deployments and Static Code Analysis with Drupal/PHP for details.
- Look for unrelated code reversions in merge requests. That is, if you see code changes that aren't related to what the developer is trying to do, there's something wrong. In most cases, this means the developer's branch is out-of-date with the main development branch. He or she should fetch and merge that branch from from the origin repository, fix any conflicts, and then add it to the merge request.
- Look for debugging code that wasn't removed such as dd(), drupal_debug() and other output functions.
- Look for Git conflict symbols such as "<<<", ">>>" and "===". These usually indicate a botched conflict resolution.
- Notice any lack of comments. Stanzas (small blocks of code that do little things) should be separated by blank lines, each with a comment explaining what it does. It may be clear to the original developer, but that doesn't help anybody else.
- Make sure that modules are installed in the right place. This is usually sites/all/modules/contrib (for upstream modules coming from drupal.org) or sites/all/modules/custom (for modules written specifically for the project).
- Ensure consistency in module package names. For custom modules, it's advisable to give the package name the name of the project so that it's clear that these are site-specific. For contributed modules, use what others are using; don't arbitrarily make one up. This helps keep your list of modules organized.
These are the most common issues I've discovered while reviewing code. If you have any others, feel free to add them as comments. I can add them to the list here.
On december 12 the Dutch Drupal Foundation will organise the first edition of the "SplashAwards". This award is to put outstanding projects in the spotlight, the best Drupal projects and community contributions from Belgium and The Netherlands.
Both Drupal agencies and individuals who have achieved extraordinary results get special recognition from inside and outside the Drupal community. The international jury selects winners out of hundreds of contestants in several categories including best government project and best Drupal theme.
The jury includes well known people in the broader PHP and Drupal community from all around the world: Joost de Valk (SEO WP fame) , Moshe Weitzman (contributor since 2001), Jeffrey "jam" McGuire (evangelist with a mo), Holly Ross (Executive Director DA) , Morten Birch Heide-Jorgensen (enfant terrible and good friend :-)), Stefan Koopmanschap (PHP / Symfony guru from the Netherlands) , Guido Jansen (magento fame) and Robert Douglass (SOLR fame and most of all around friendly chap) will select the ten winners who will walk home along the canals with a great award and a smiling face.
There are 10 awards to be given, from architecture and commerce to best governmental site and theme. The award self will be held for some 100 people, in an old cinema in the centre of Amsterdam. We are really looking forward to this event. And in fact, it will be the last event of the year for the Dutch and a great year it has been.
From a record breaking DrupalJam, via the social events around DrupalCon to 100's of students getting a free training on the Drupal Training Day and now the bowtie SplashAwards, showing of the Dutch Drupal community never was better.
If you need to create dynamic output on an entity when it is displayed on your Drupal site you have multiple options. One method that is easy to implement is using hook_entity_view().
You can insert this hook function into your custom module (see creating a custom module for more info).
Recently, I had the need to refer back to a custom module I wrote at a previous job years ago and like it tends to do, the code scared me. As far as I know, this module is still chugging along doing its job to this day, and hasn’t had any issues. But for it to work for us at Mediacurrent, it needed some serious refactoring.
Drupal 8.0.0 beta3 was released since the last core update, with over 200 fixes after the prior release. There are still over 100 known critical issues, which means more beta releases to come.
We take special care to resolve security and performance issues. Both types of issues may require API changes. There is now defined criteria for performance issues as to what kind of improvements qualify as critical issues (and therefore blocking the Drupal 8.0.0 release).
After 2.5 years of work in part sponsored by MongoDB Inc, led by Károly Négyesi (chx), Drupal 8 can now completely install with MongoDB. This is the first time Drupal in its entirety has been successfully installed in a NoSQL database.
Check out the demo video.
In almost three weeks, the Drupal Association and Wunderkraut are sponsoring a focused sprint in Ghent to help move core critical issues forward. However, you can help make things move faster anytime from anywhere, so read on!Where's Drupal 8 at in terms of release?
So how long will it take us to fix those critical issues and get to a Drupal 8 release candidate? The average time it takes to fix a critical issue varies enormously depending on the scope of the problem and the resources our contributors can devote to fixing each. Over the course of the Drupal 8 development cycle:
- 30% of critical issues were fixed within one week of being filed,
- 50% of criticals were fixed within one month of being filed,
- 80% of criticals were fixed within six months,
- and then 20% took more than six months.
This means that one great way to help get Drupal 8 to a release faster is to accelerate some of those long-running issues. Look for the oldest critical issues, or the critical issues that have gone awhile with no updates, and help assess them. Is each still relevant? Is something blocking it? What's the next step that's needed? Is the issue summary up to date? As we both focus on our next milestone and bring these longer-running issues to a successful resolution, we'll be able to narrow our focus to incoming issues and get Drupal 8 done. :)Current focus
The current top priority in Drupal 8 is to resolve issues that block a beta-to-beta upgrade path (critical issues tagged 'D8 upgrade path'). Supporting an upgrade path between betas is an important step for early adopters to begin building with Drupal 8 (and lending their resources to getting other critical issues done).
We also need core contributors to continue evaluating issues for the beta phase based on the beta changes policy. Note that Dreditor now includes a handy button for inserting a beta evaluation template in issue summaries! Thanks Cottser and Mark Carver for adding this feature so quickly.
Finally, keep an eye out for critical issues that are blocking other work. Add the blocker issue tag that other issues are postponed.
(Note that we're changing this section of the Drupal Core Updates to highlight ongoing goals rather than specific issues, because calls to action in these posts haven't resulted in additional momentum in highlighted issues. Instead, we'll be making brief, separate posts every week or two highlighting top-priority issues in critical areas. If you're a core subsystem maintainer or initiative lead and want to highlight a specific issue, we encourage you to submit your own brief announcement to g.d.o/core (requires access). Anyone in MAINTAINERS.txt is authorized to post to this group!)How to get involved
If you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.
If you'd like to contribute to a particular Drupal 8 initiative or working group, see the regularly scheduled meetings on the Drupal 8 core calendar:
Google Calendar ID:
Note that ultimike is now running a virtual Migrate sprint, Wednesdays 19:00-21:00 EST. See the Migrate in core group page for information and updates.
If you are interested in really digging into a tough problem and helping resolve a stagnating release blocker, or if you are stuck on a critical currently, join the #drupal-contribute IRC channel during weekly critical issue office hours on Fridays at 12:00p PST. See chx's office hours reports for an idea of what we've done so far!
You can also help by sponsoring independent Drupal core development.Notable Commits
- Issue 2236855 by rachel_norfolk, stefank, ngocketit, lauriii, LewisNyman, alexpott, yuki77, rteijeiro | mortendk: Use CSS for file icons in file fields.
- Issue 2364647 by chx, alexpott: Fixed [sechole] Remove blacklist mode from Filter:XSS.
- Issue 2322509 by prics, cilefen, gaurav.goyal, harijari, Temoor: Replace all instances of node_load(), node_load_multiple(), entity_load('node') and entity_load_multiple('node') with static method calls.
- Issue 287292 by almaudoh, mr.baileys, drewish, Berdir, znerol, boombatower, dawehner, jpetso, floretan: Add functionality to impersonate a user
- Issue 2267453 by alexpott, dawehner, damiankloip: Views plugins do not store additional dependencies
- Issue 2352155 by Wim Leers: Remove HtmlFragment/HtmlPage
- Issue 2375225 by LewisNyman, davidhernandez: Add emma.maria as Bartik maintainer
- Issue #2362987 by Wim Leers, Codenator, Pinolo: Remove hook_page_build() and hook_page_alter()
- Issue #2339151 by EclipseGc, tim.plunkett, Gábor Hojtsy, effulgentsia: Conditions / context system does not allow for multiple configurable contexts, eg. language types
- Issue #2376791 by dawehner, Wim Leers: Move all _content routing definitions to _controller
- Issue #2378789 by Wim Leers: Views output cache is broken
- Issue #2324055 by dawehner, cilefen, znerol: Split up the module manager into runtime information and extension information
You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.Drupal 8 Around the Interwebs
- YesCT, xjm, KatteKrab, and Schnitzel created a proposal outlining business strategies for contributing to Drupal Core. If you act in a decision-making capacity for your organization, this is an absolute must-read!
- MKorostoff explains how to programatically create a block in Drupal 8.
- Joe Shindelar clarifies some of the differences between templates in D7 and Twig in D8 from a developer perspective. Courtney Koppenhaver also provided some detail on this topic!
- Andrew Cohen details the decisions that need to be made when considering an upgrade to Drupal 8.
- December 10 - 14 - Ghent: The Drupal Association and Wunderkraut are sponsoring a focused sprint in Ghent to help move core critical issues forward.
- January 17 and 18: Drupal Global Sprint Weekend returns for the third year to unite small local sprints around the world. Find or add your sprint location or join online.
- February 8 - 13 - Bogotá: DrupalCon Latin America in Bogotá is the next DrupalCon! Join the sprinters and sign up for various sprints.
Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.0.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Read more about how you can volunteer to help with these posts!
Twelve weeks after it began, the first online class of Drupal Career Online (DCO) graduated yesterday, launching six new Drupalists on their way to a new career. With this class, DrupalEasy has now graduated 71 participants from Drupal Career online and in-person programs. Our graduates were taught the fundamentals of Drupal site-building, Git, introductions to module and theme development, site maintenance, distributions, and much more. Along they way, students were required to use the same communication tools as the rest of the community (including IRC), were provided with a community mentor, and were encouraged (pestered?!) to get involved in their local communities.
I wasn't sure whether to publish this review or not.
One of our members wanted a really simple shopping cart for Drupal. They found the Basic Cart module and asked me about it.
So, I set up and tested Basic Cart. Everything worked great, until the end when I realized there was no payment gateway. None. Basic Cart is a great little e-commerce store ... except it has no way to pay.
Load testing is an important aspect of any project: it provides insight into how your site and infrastructure will react under load. While critical to the launch process of any project, load testing is also useful to integrate into your standard testing procedure. It can help you locate bottlenecks and generic performance regressions introduced in the evolution of a site post launch (due to code and infrastructure changes).
There are many different methodologies and applications for performing load tests, but generally it involves bombarding various pages on the site with enough traffic to start causing degradation. From there, work can be done to isolate bottlenecks in order to improve performance. By performing periodic load tests, you are much more likely to catch something while it’s still a minor performance issue, not after it becomes a major problem.Different Types of Load Tests
There are a number of different load testing configurations (sometimes referred to as test plans) which can be used individually or in conjunction to provide insight into site performance. Generally, we end up running three different types of tests:
DrupalCon is an important community event that brings a diverse group of Drupalers together under one roof to share knowledge, grow skills, and strengthen community bonds. As an organization, it is very rewarding to facilitate these experiences around the world.
In the past, our attendance data has shown that DrupalCon is primarily a regional event, attracting attendees from nearby countries and drawing in some great international speakers, trainers, and community leaders. Knowing this, the Drupal Association is committed to hosting DrupalCon in regions other than just North America and Europe.
In 2015, this third DrupalCon is in Bogota, Colombia. In 2016, we want to host DrupalCon in India and this blog explains why. Can you tell us your thoughts on this host country and which city you think should be the next DrupalCon location?How do you pick locations?
The Drupal Association Board sets the staff’s direction with vision and strategy and they asked staff to come up with a list of possible countries in regions outside of North America and Europe that are viable DrupalCon Locations. They provided us with selection criteria that supported their strategy, which included in no particular order:
- Popularity - People want to visit the host location to site see.
- Strong local community: Size of the camp in the proposed city / # of camps in a country
- Size of Drupal business community - # of Drupal businesses within that country and region
- Ease of doing business with a country: Easy to set up a financial entity so we can collect ticket sales revenue and pay vendors in local currency.
- Local Support: The community reached out to the Association, requesting a DrupalCon and offering to help produce it.
- Inexpensive travel - This gives insight into the average cost of lodging in the city
- Visa: Easy to get a visa or one is not required to enter a country.
- Strong business environment - The number of Fortune 500 companies in that region
- Community survey: Where does the community want to go?
After researching locations and ranking countries and cities based on the above criteria, several places bubbled to the top. Latin America and specifically Bogota, Colombia was a clear leader, which is why we are hosting DrupalCon 2015 there. India was ranked second over other possible locations.What makes India a good host country?
India has an impressive number of Drupal leaders, contributors, businesses, and end users. This country drives the 2nd highest amount of traffic to Drupal.org (Unites States had 1M sessions last month, while India had 450,000.) DrupalCon in India can highlight this country’s Drupal strength to the global community while conversely showing the local community how they can contribute more back to the Project.
More specifically, India ranked high because it has several mature camps and many local communities throughout the country. Producing DrupalCon outside of North America and Europe requires a strong partnership with community leaders who can help us with logistics. Plus, a DrupalCon needs power in numbers to make it financially worthwhile and effective, so a large community base is key.
In India, technology conference tickets are usually very inexpensive, so a DrupalCon in India ticket price will need to cost much less than the standard DrupalCon ticket price. Because of the cost of putting on conferences, having low ticket prices means the event will be funded through sponsorships. India has a strong Drupal business community and many are already pledging sponsorship to make the event financially viable.Which host city is best for you?
We would like to thank Rahul Dewan, Jacob Singh, Mayank Chadha, Rachit Gupta, Ani Gupta, Hussain Abbas, Chakrapani R, Sunit Gala, Venky Goteti, and Shyamala Ramajan and other community leaders for determining the financial feasibility for hosting a 1,000 person DrupalCon in their city. After several discussions, we decided Bangalore, Mumbai, and Delhi are our three most viable host cities. Now we need your input in picking the city where we will host our first DrupalCon in India. Below is a chart summarizing their key findings.
Which city should host DrupalCon and why did you chose that city? (e.g. travel distance, travel cost, ideal hotel cost, preferred venue(s), community size). Please use comments to tell us.Bangalore Mumbai Delhi
(based on 1,000 attendees, 1 keynote room, 6 session rooms, 4 BOF rooms)
- Manpho Convention centre
- The Lalit Bangalore
NIMHANS Convention centre
(OSI days happens here)
- The Ashok, New Delhi (more info)
- Jaypee Greens Golf & Spa Resort, Greater Noida
- Hyatt Regency, Gurgaon
(lunch and coffee/tea break per day)Rs.500 per person per day
($8) Rs 2,460 - 3,075 per person per day
($40 - $50)
- Rs 2,460 per person per day (tax inclusive) ($40)
- Rs 2,100 per person per day (tax inclusive) ($35)
- Rs 1,400 per person per day (tax inclusive) ($25)
Rs. 3,500 per night ($57)
There are 50+ options around Grand Hyatt for all price points, between Rs 1,545 - 7,420 per night ($25-$120)Renaissance Powai Rs 11,130 per night ($180)
Rs 8,000 per night ($120) - 2 seater room
Rs 11,000 per night ($180) - 3 seater room
- Rs 9,000 per night ($140) - 2 seater
Rs 8,000 per night ($120) - 2 seater
Other 3* hotel option (~5km) from the venue - Rs 2,500-4,000 ($40-$80)
By plane - Rs 9,275 RT ($150)
Plane Rs 7,420 ($120)
Bus: (20hr) Rs 3,090 ($50)
Train (20 hr): Rs 3,710 ($60)
Mostly Bus and train(overnight journey - 8hrs).
Plane: Rs 7,730 ($125)
Bus: Rs 3,710 ($60)
Train: Rs 3,710 ($60)
Plane (2 hrs) Rs 8,040 ($130)
Train (16 hrs) Rs 4,950 ($80)
Plane (1hr40) Rs 7,420 ($120)
Train (24 hrs) Rs 3,710 ($60)
Plane (1hr10) Rs 5,570 ($90)
Train (10 hrs) Rs 4,330 ($70)
Plane (2hr00): Rs 7,730 ($125)
Train Rs 2,475 ($40)
Plane (2hr30): Rs 9,275 ($150)
Plane (2hr00): Rs 10,820 ($175)
Indian flag image credit to Sanyam Bagha on Flickr.
DrupalCamp India image credit to Dries' blog.
Everyone is happy to get a sign of appreciation, right? So were we having received a message from the American ranking service Clutch.co, which is regularly analyzing the market worldwide to make up lists of the best companies in certain spheres. Not so long ago they published a new list, based on fresh-conducted research. And know what? InternetDevels company was included in those new list!Read more
The concept of official initiatives came out of lessons learned from the Drupal 7 development. We learned a lot from that and in a recent blog post about Drupal initiative leads, I recognized that we need to evolve our tools, our processes, and our organizational design. Others like Nathaniel Catchpole, Larry Garfield and Gábor Hojtsy have shared some of their thoughts already. One of the things I'm most proud of is that the Drupal community is always looking to improve and reinvent itself. Evolving is an important part of our culture. Each time it will get better, but still won't be perfect.
For me, one of the biggest take-aways (but not the only one) is that for an initiative to succeed, it needs to be supported by a team. An initiative needs to carry out a technical vision, plan the work, communicate with all stakeholders, mobilize volunteers, raise funding, organize sprints, and more. It can easily be more than one person can handle -- especially if it isn't your full-time job or if your initiative is complex.
More specifically, we have learned that the most successful initiatives appear to be run by teams that are self-managed; the team members collaborate in the development of the initiative, but also share both managerial and operational responsibilities like planning, coordinating, communicating, sprint organizing and more.
Because self-managed teams are both responsible for their outcomes and in control of their decision-making process, members of a self-managing team are usually more motivated than traditional hierarchical teams. This independence and greater responsibility are important in volunteer communities. Self-managed teams also build and maintain institutional knowledge. The outcome of their work is also more easily accepted by other stakeholders (like core committers) because they have already built a lot of consensus.
If I were to be an initiative lead, I'd feel strongly about building my own team rather than being handed a team. My initial assumption was that each initiative lead would build his/her own team. In hindsight, that was a mistake. Team building is not easy. It requires a time investment that can seem to compete with technical priorities. This is an important lesson and something we can do better going forward. Before making an initiative official, we have to make sure that each initiative has a good team and the support to be successful -- either we can help create a team, provide more coaching or formal training around team building, or we shouldn't designate the initiative official until such a team has coalesced.
It's all about perspective when it comes to launching. We always think we need something more, that missing set of instructions or special ingredient that will propel us to finish. That special person, few moments of sanity, or foolproof plan.
But at the end of the day, while those things may encourage us to make the choice to take action or bring balance and clarity, they never change the fact that we won't make it anywhere until we start the journey. We could be waiting at the bus stop thinking it's the only way we'll get there, when the whole time we could have been on the train.Read more
Today I got my feed wet with Drupal 8 Configuration Management. For those who are new to this excellent feature in Drupal 8, you should read the documentation at drupal.org (Managing configuration in Drupal 8) or watch this DrupalCon Amsterdam video. This article assumes you are familiar with Drush and Drush aliases.
I worked with a very basic workflow using a development site and an acceptance site. Both sites are under revision control, where the complete webroot (core + modules, but not settings.php) is placed in git. For gitignore I used a copy of the example.gitignore which you'll find in Drupal's root directory.
I used Drush 7 to import and export the configuration. 'Export' is to transfer a site's configuration from Drupal to file and 'Import' is to transfer in reversed direction. Using drush @dev config-export you export the configuration from the development site to the sites/default/config_*/staging directory. The staging directory now holds many *.yml files that each contain the configuration of an individual section. I've chosen to use git to transfer these files to the acceptance site. At the acceptance site drush @acc config-import is used to transfer the configuration from the file system to the acceptance site.
Make sure that the acceptance site is a copy of the development site. For example using drush @dev archive-dump you can make a copy of both the files and database. With this you can create a copy of the site using drush archive-restore.
I made these changes to the .gitignore file to allow the staging directory to be added to git:Tags: drupal 8drushdeploymentconfiguration management
Several weeks ago, we issued an RFP for Drupal.org Content Strategy project. We got a number of great submissions, and the next couple of weeks the Drupal Association staff and the Drupal.org Content Working Group members spent reviewing proposals and interviewing potential vendors.
Today we are happy to announce that we’ve selected a vendor for the content strategy project: Forum One, an open-source digital agency.
Their proposal met all our project requirements and outlined a solid plan for how we can make this project happen. During the interviews Forum One impressed us with their professionalism, passion for content strategy, their extensive experience working on large content strategy projects, and their deep knowledge of the Drupal community and Drupal.org, the website.
We believe that together our staff and Forum One team will make this project a success. Can’t wait to start working and improve Drupal.org content for all our varied audiences.