Display Suite is one of the essential modules which I use on every project. It allows you to change the look and feel of entity bundles, i.e., content types, vocabularies, users and much more. Building custom layouts and adding fields is a breeze, but there's another feature you may not be aware of and that's custom field templates. Display Suite allows you to change the markup which is used to render individual fields. The functionality to change field templates is off by default. To turn it on, you'll need to enable the "Display Suite Extras" sub-module and check the "Field Templates" on the Extras page.
The constant struggle between content editors and web developers: Content editors want to embed rich media, callouts, and references to related content anywhere within their WYSIWYG. They love the Body field and want more buttons added to the WYSIWYG. Web developers want to add additional fields for media, attachments, related content to support rich content relationships and access control. Web developers hate the Body field and wish they didn’t need a WYSIWYG. In the latest 2.30 version of Open Atrium, we attempt to help both content editors and web developers with a new approach to building rich story content using the Paragraphs module. Rather than having a single WYSIWYG body, content editors can build their story using multiple paragraphs of different types and layouts. The order of these paragraphs can be rearranged via drag and drop to create long-form content.
As a front-end developer working with Drupal, I often need to create custom Ctools layout plugins. Ctools is an essential suite of tools for Drupal developers and the basis of many popular modules, including Views, Panels, Context and Display Suite. Its layout plugins provide a flexible alternative to Drupal’s core page region system.
A few months ago I was asked to help manage our company blog. As a busy drupal developer, I had little time to post all of our new blog content on every social media site. So I decided to automate this so I could spend more time on client projects. My first step was to look around and see what was currently available. Although there was some options, I found them to be a bit heavy for my application. One of the things I was looking for was to be able to choose what social networks our content would be posted to. For example, I wanted to be able to choose to post this page to facebook, but not twitter, or post this to all social networks.
When building a Drupal 7 site, one oft-used technique is to keep the entire Drupal root under git (for Drupal 8 sites, I favor having the Drupal root one level up). Starting a new project can be done by downloading an unversioned copy of D7, and initializing a git repo
The Drupal Features module covers a lot of our needs with automating the deployment of database settings for Drupal 7. It allows you to export configuration to code and nicely wrap it up as a module. This means you easily deploy your changes to the live site (or a staging site) without having to repeat the configuration changes. It also means you can apply the changes to a different site. But using Features is not always the best approach. Even if you can export something using Features, it doesn't mean you should.