Jeff Eaton and Misty Weaver discuss the thrills of content inventories and audits, creative ways to stay on top of a growing web site, and more.
As the first beta of Drupal 8 approaches, we now have the opportunity to reflect and start thinking about the future of Drupal core. If you have contributed to Drupal core and have ideas on what we've done, what we could be doing better, or what we should do in the future, please consider submitting a Core Conversation!
The Core Conversation track team would like to encourage submissions for any topic you are passionate about in Drupal core, but here are some topics that we would be particularly interested in seeing:
In this post, I continue my series on how to override Open Framework's default styles to get a more custom look-and-feel on your site. Last time we looked at how to override the main menu styles. Today, we'll look at how to customize your typography.
As a site building track organizer for DrupalCon Austin this year, Im really excited about the great submissions we’ve received so far. DrupalCon Austin is shaping up to be a fantastic event and the site building track will have some great content and insight for all levels of site builders. While DrupalCon Austin is a few months away, the session submission deadline is the end of this week (March 7th)! But never fear, you still have a week to submit your amazing site building session, so let me give you some hints about what kind of sessions we’re looking for.This year for the site building track, we are looking for creative sessions about how people build sites with Drupal, but even more than that, we are looking for three other related topics that haven’t been covered in the past.Drupal 8
First we want to showcase sessions that discuss how Drupal 8 will effect Drupal site building. Drupal 8 will be a central topic throughout the camp, and I think Drupal 8 discussions surrounding the site building track will be especially engaging and insightful. We want to pick from sessions that dig into the features of Drupal 8 core and how these features might help site builders bring sites to life.Multi-Site Platform Builds
We’re seeing Drupal adopted by larger and larger enterprise organizations. With this adoption, the conversation is shifting from how to build out a Drupal site, to how to build out a multi-site Drupal platform. We are looking for sessions that highlight this new class of site building in Drupal, in which platforms are developed and used by site builders to create multiple sites from 10 to more than 100.Content Strategy And Configuration
Finally, we are looking for sessions about integrating content strategy into Drupal site building. This last topic is really valuable, we want to find sessions that will explore how strategy effects site configuration and how conversions or limits in Drupal effect content strategy.We’re looking for the Glue.
While all Drupal site building topics are welcome, we will be looking for sessions that speak to people that have technical skills but do not spend most of their time in code. We feel these “glue” players are a big part of the Drupal community, and we hope the sessions will not only showcase what can be done with Drupal, but how site builders are developing strategies to get it done.
We have already received tons of great sessions, but we would love to see more! You have a week so come on down and submit a session!
On 24-30 March, Drupal Developer Days Szeged 2014 will have a strategic role in Drupal 8 development. At DrupalCamp London Gábor Hojtsy explained to me that the event would benefit from a little more sponsorship to guarantee providing the best and most reliable wifi and internet infrastructure.
There are few more practical ways to help drive development of the next version of Drupal. Individual sponsorship packages start from just €100! Click here to find out more.
With just weeks until Drupal Dev Days, there is little time to lose.Further information: Drupal Dev Days Sponsorship details
We’ve been talking a lot about Drupal partnerships lately here at the Drupal Association, because we know that it’s a great way to help the Drupal community come together— and it’s also a great way to get noticed.
There are several options for supporting the Drupal Association and one of them is designed specifically for Drupal businesses: Supporting Partner.
When you become a supporting partner, your contribution goes straight to Drupal.org.
In previous articles in this series, we’ve covered the areas of architecture, security and performance. All of these aspects are affected by your infrastructure from the time of development to deployment.
We hosted Drupal websites at Hetzner for a few years. While it's unbeatable on price, it requires a skilled Linux sysadmin, which weights on personnel costs. Our guesstimate was that we'll pay a third more for a Drupal hosting, but our sysadmin costs would go down by ⅔. Add in non-material considerations, such as lower personnel turnover risks and better DDoS protection, and alternatives to Hetzner start to look almost attractive.
So, we decided to check Drupal cloud hosting solutions and asked for quotes from Pantheon and Acquia. Pantheon was less expensive and had more features. It also edged out Acquia on technology by using Linux containers instead of Amazon Web Services as underlying infrastructure. Unfortunately, Pantheon servers were located near Chicago, while most of our readers are from Europe, so we had no choice but to go for Acquia.Tags: drupalsysadmindrupalplanet
Several months ago, I ran a session on the subject at DrupalCamp Montreal. I educated attendees on how Git submodules can be used with Drupal to take advantage of some Git features that wouldn't otherwise be realized.
Here are the benefits of the approach (as discussed on Drupal Answers):
- You can git fetch/merge/pull updates for your contributed modules directly from Drupal.org. There is no need to manually download a new version of each, unpack and then commit (or do this with Drush).
- You can see upstream version history in your own Git log. This makes it easy to see where you're at; you can check if you've got specific upstream commits. Otherwise, all you can see are local changes and "Upgraded Blah from 2.3 to 2.4." log messages.
- You don't need to reapply (cherry-pick) custom changes to your contributed modules after upgrading them. If you use the one-Git-repository method, each contributed-module upgrade will overwrite anything you're previously patched and committed. This is a huge problem because developers often forget to do the reapplying, and then you're left with resolved issues that have been reverted. If you're using submodules, you simply maintain a custom branch, and merge upstream tags (or commit IDs) into it.
Randy Fay essentially wrote the bible on the practice in 2011, and there was even a Drupal on Git initiative with the community to standardize it. But although there are clear benefits, Git submodules within the Drupal space aren't overly popular. I do have a client who's using them, but generally, developers often work with a single repository. (Drush makefiles are still being used, but less so.)
While great in theory, the problem is that it adds more moving parts to existing development processes. I find that if can be difficult enough getting developers to follow all prescribed devops directives. Adding to the mix increases the risk of breakage and further problems. So keeping things simple, with only one (1) repository, isn't a bad plan.
I'll admit that I generally stick with the single-repository approach myself, mostly because I work with developers I'd rather not confuse, and most (if not all) of the Drupal-specific hosting providers are only set up to support projects set up that way.
It's worth noting that there is now an alternative, Git Subtree. For a general overview, take a look at Alternatives To Git Submodule: Git Subtree, or Smarter Drupal projects in projects management with git-subtree for information on how it works with Drupal specifically. I haven't tried this (yet) for any projects, but if I hear enough good things about it, I'll take it for a spin.
See the attached file for my slides, and the YouTube video for the presentation itself. I apologize for the less-than-stellar audio quality. I wasn't given a microphone; we only had access to the one on the camera.File(s): Maximizing version control: Manage your Drupal project with Git submodules.pdf
WebRTC is one of the highlights of HTML5. The latest stable releases of Google Chrome (including the free Chromium browser) and Firefox include support for this technology and although the specifications are still being finalized, this is the time when developers can start preparing the first generation of web-apps that will define the future of this technology.
The JSCommunicator project aims to make it easy to integrate WebRTC into existing web applications.
The student selected for this GSoC project will focus on two practical, real-world deployments of JSCommunicator:
- The popular new Debian Developer WebRTC portal at https://rtc.debian.org
- The FreePhoneBox.net
It is particularly important to think about ways to make this technology useful for the Debian Developer community in the pursuit of Debian's work.Not just for Debian
A communication product is not much use if there is nobody to talk to.
The optimal outcome of this project may involve helping two or three additional free software communities to build portals similar to https://rtc.debian.org so that they can interact with Debian and each other using Federated SIP. As Metcalfe's Law explains, this outcome would be a win-win situation for everybody.
The more diverse the mentoring community, the more positive outcomes we can achieve with this project.
If you would like to be part of a mentoring team for this project, please email me and subscribe to the Debian SOC co-ordination email list. There is no strict requirement for all mentors in the team to be full Debian Developers and emerging technology like this clearly needs people with strengths in a range of different areas.Get started now
For general ideas about getting selected for Google Summer of Code, please see the comments at the bottom of my earlier blog post about Ganglia projects
For this project in WebRTC in particular, please:
- Review the project brief on the Debian wiki
- Discuss your ideas on the JsSIP Google group
- Send an email to introduce yourself on the Debian SOC co-ordination email list and give a link to your post on the JsSIP list
- You must complete a coding test. Please see the open bug list for JSCommunicator, complete one of these tasks and submit a pull request on Github. Please send an email to the JsSIP Google group to discuss your pull request.
- Explain what features you would create during the summer
- Explain which other tools or libraries you would like to use
- Explain how your participation will benefit Debian, free software and the wider world. Give some practical examples.
Migrate in Drupal 7 didn't explicitly have the concept of a process plugin but under the hood you were using the "Get" process plugin when you wrote code like $this->addFieldMapping('source', 'destination');
The Drupal 8 Migrate API has taken advantage of the new plugin system to provide a flexible way to process fields. In core, we already have a handful of process plugin examples including the Get plugin. I wouldn't look at the Get plugin for a simple example however.Why Process Plugins?
The purpose of a process plugin is simply to take a value in and spit a new value out. The plugin can transform the data in anyway it sees fit but if you are following best practices you should ensure that a plugin does only one thing, definitely lean towards multiple process plugins as needed. From our experience so far, process plugins are usually quite simple and often less than 10 lines of code.
Anyone interested in the forthcoming Panelizer v7.x-3.2 release might like to checkout the Trello board I've set up to help coordinate the effort.
FYI I've restructured the various lists around specific topics, which greatly helps get an understanding for the work to be done. Any and all help is appreciated :-)
Reading about development being code-driven on a software developer's blog is a bit surprising, isn't it? As if development was not all about writing code in this industry. Yet some developers use the term to distinguish their method of building web sites with Drupal.
Judging by the top 20 Google search results at the time of writing, the term code-driven development seems to be used exclusively by some in the Drupal community. The only matches not related to Drupal are about test-driven development, demonstrating a lack of other references. Like any community people working with Drupal come up with their own terms for idiosyncratic concepts. However the term code-driven development is misleading and the problem it wants to solve is certainly not unique to Drupal.
Drupal is a breed of content management system for the web that does not require coding skills to customise. Almost every aspect of a Drupal website can be configured through a web UI. An ecosystem of extensions called modules is available and can be added easily to an existing site following the same philosophy. One such extension, the views module, even provides a UI for creating database queries and displaying their results in a highly customisable fashion. All that power is based on storing the configuration that defines the behaviour of a site inside its database along with the content.
Essentially a web content management system like Drupal enables a person, called a site-builder, to define the behaviour of a website entirely through configuration. The way this is achieved has some serious drawbacks though: If development of new features is supported by a team of engineers, distributing configuration changes poses serious challenges. It is not impossible to manage, but it can become a tedious work quickly, which might outweigh the advantages of using Drupal over a framework.
A solution to the challenges posed by Drupal's architecture has been pioneered by making use of the notorious Features module. The idea is to export configuration data from the database and put it into a version control system alongside with the source code. Some people in the community call this approach code-driven development. Obviously, putting configuration files into a version control system does not make their content source code.
Eventually the Drupal community came up with the right name for the solution. One of the key new features of Drupal 8 is called Configuration Management.
There is a module for that!: Features and i18n configuration management, part 3: Optimizing translation sets in Features Translations
In part 1 of this series, I introduced the workflow we use for managing i18n-friendly configuration using Features.
Clarence House is the official London residence of The Prince of Wales, The Duchess of Cornwall, and until recently The Duke and Duchess of Cambridge and Prince Harry. They launched their previous website in 2006 and have made great headway in creating an online presence for these members of the Royal Family. Together with Reading Room they've reassessed the design and structure of the family of websites (www.princeofwales.gov.uk; www.dukeandduchessofcambridge.org and www.princehenryofwales.org), achieving a result that both immerses and informs an increasingly varied demographic.Key modules/theme/distribution used: Ctools EntityDateEntity APIEntity referenceField collectionGoogle AnalyticsMediaRevisioningSchedulerSecure PagesTinyMCETokenViewsWebformWysiwygTeam members: AdamBJimbwlahlinuxydave
In this week's episode Addison Berry is joined by Drupal 8 developers Klaus Purer (klausi) and Lin Clark (linclark), along with our own Joe Fender. In Drupal 8 we've added the new REST module to core. This makes it easy to output your content in multiple formats, including HTML, JSON and XML.
Drupal installation profiles are usually just starting points for a new site, but sometimes you want to leave an installation profile untouched, adding your own additions in a separate space and leaving a "clean" upgrade path for future versions of the profile. Here's a handy script I use for such situations.
Let's say you're building a site on top of an installation profile such as Drupal Commons, and you want to treat Commons like you treat Drupal Core (that is, leaving it untouched). What I did was create a module which gets enabled after Commons is installed, at which point all of the customizations unique to this site are made.
Anyone who works with installation profiles recognizes the need to quickly wipe your database and start the installation process over again, to make sure that everything installs cleanly. However, in this scenario, there's no need to keep re-installing the profile, since it's not changing.
The following script will check for a database snapshot of the installed profile (in this case, "commons"), and if it's absent, it will use drush to install the site and save a backup of the database. Then it will enable my custom module. On subsequent runs, since it will find the database snapshot, it won't re-install the profile, but instead it will just dump the database and import the snapshot, and then enable the custom module.#!/bin/bash
if [[ ! -f ../snapshot.sql ]]; then
echo "Installing profile."
drush site-install -y -v 'commons' \
--site-name='My Drupal Site' \
echo "Saving database snapshot."
drush sql-dump -v --result-file=../snapshot.sql
echo "Dropping database."
drush sql-drop -y -v
echo "Importing database snapshot."
drush sql-cli < ../snapshot.sql
echo "Enabling custom module."
drush en -y -v custom_module
An idea to further refine this: after the entire process is finished, import the database snapshot into a temporary database. Then, the next time the script is run, drop the old tables and rename the temp tables so they get placed in the actual database. Might make it a little faster.Submitted by Joel Stein on February 27, 2014.Tags: Drupal, Drupal Planet, PHP, drush
This blog post is a textual representation of the video shared yesterday. If you are visual learner, watch it. If you are in a hurry, read this blog :). Peter's video also shows how configuration_log module can be used to materialize all config changes in Prod so they may be easily integrated back into the codebase. That is not covered here.
"My budget is really tight, can you get the project started and show me what to do to finish it?" -- Yet another request from several different prospective customers.
This sounds appealing, right? Drupal does put a huge amount of power and control in the hands of users. Aside from custom theming, many of our projects don't involve writing any code -- it's more a matter of mapping out the user stories, putting an appropriate set of modules together, and configuring them to deliver the desired result.DrupalDrupal PlanetMistakesProject Management