Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 39 min 59 sec

Acquia Developer Center Blog: Announcing the Acquia Cloud Log Streaming Chrome Extension

lun, 11/01/2016 - 19:52
Isaac Sukin

Today we’re releasing a new Log Streaming Chrome extension that allows developers to see the logs they are generating in real time as they click around their websites.

Imagine you run a large e-commerce website powered by dozens of servers, and your customers are reporting problems checking out. You’re losing money by the minute. What do you do?

Tags: acquia drupal planetAcquia Cloud Log Streaming Chrome Extension
Catégories: Elsewhere

Mediacurrent: Drupalcamp Atlanta 2015: Drupal 8 and Symfony2 - Not so Scary!

lun, 11/01/2016 - 17:19

My presentation from Drupalcamp Atlanta 2015 takes you on a magical journey through the mystical lands of Drupal 8 + Symfony. And trust me, you want to take this journey. Why? Because no matter your development background or experience, making the switch to Drupal 8 is going to hurt. Consider this time a dose of preventative medicine :D

Catégories: Elsewhere

Drupal.org Featured Case Studies: Georgetown University in Qatar (GU-Q)

lun, 11/01/2016 - 16:30
Completed Drupal site or project URL: http://qatar.sfs.georgetown.edu/

Georgetown University School of Foreign Service in Qatar (GU-Q) hosts a dual language, Arabic and English website with 1800+ indexed pages and 800+ publications on the website. Their previous Keybridge Systems Cold Fusion based website suffered from declining performance, lagging speed and an obsolete architecture, on an outdated back-end that was difficult to manage and update. This provided for an ineffective and poor quality user experience and it created difficulties for site editors and administrators.

After a full website audit, it was determined that a complete redevelopment and restructuring of the website was appropriate for the future needs of the campus. GU-Q partnered with Vardot for the complete rebuild of their website from scratch, starting with a remodel of the front-end design in accordance with Georgetown University brand guidelines, a restructuring of the information architecture and a complete back-end rebuild on Drupal CMS.

Key modules/theme/distribution used: Varbase: Drupal Bundled with Necessities | by VardotVarbase EditorPanelizerFeedssimpleSAMLphp AuthenticationApache Solr SearchDomain AccessDisplay SuiteWorkbenchInternationalizationEntity TranslationMenu blockFieldable Panels Panes (FPP)Bibliography ModuleOrganizations involved: VardotTeam members: Mohammed J. RazemIsraaalaa abbadmqannehjosebcRajabNatshahm.abdulqader
Catégories: Elsewhere

Matt Glaman: Drupal 8 Development Cookbook

lun, 11/01/2016 - 14:07

I've been keeping myself busy with a few things over the past few months. One of them is the Drupal 8 Development Cookbook to be published by around May 2016! The book will feature over 60 recipes that will help beginners and seasoned Drupalistas get a handle on Drupal 8. I have been helping on developing Drupal Commerce 2.x and given a hand with the Panels in Drupal 8 initiative. Taking from these experiences I have been working hard to create a great resource for all Drupal 8 hopefuls!

In this book, you will learn

  • Extend Drupal through contributed or custom modules and themes
  • Develop an internationalized website with Drupal's multilingual tools
  • Integrate third-party front-end and back-end libraries with Drupal
  • Turn Drupal into a web services provider using REST
  • Create a mobile-first responsive Drupal application
  • Run SimpleTest and PHPUnit to test Drupal
  • Understand the plugin system that powers many of Drupal 8's new APIs to extend its functionality
  • Get to grips with the mechanics of the configuration management system and the ability to import and export site configuration

Link to book on PacktPub.com: https://www.packtpub.com/web-development/drupal-8-development-cookbook

Catégories: Elsewhere

Annertech: Tutorial: Create a Weather and News Reader App with Ionic and Drupal

lun, 11/01/2016 - 12:55
Tutorial: Create a Weather and News Reader App with Ionic and Drupal

During the Christmas break, I decided to give myself a challenge: increase my knowledge of app building, AngularJS, and Ionic Framework. Since I didn't know very much about any of them, that was the easy part. I then gave myself a second task - build a hybrid app for my local town that would give us home, current weather, and news tabs, with all content being derived from online data sources.

Catégories: Elsewhere

Deeson: Rainmaker: Local Linux Development Containers for the Discerning Drupal Developer

lun, 11/01/2016 - 12:11

Rainmaker is a local development environment for developers. It makes use of Linux Containers to rapidly allow you to clone your whole development environment - including the codebase, files and database.

In simple terms, this lets you have one local development environment which can be branched to create other containers for development of specific features. A bit like Gitflow - but for everything, not just the codebase.

If this sparks your interest then please bear with me whilst I take you on a journey on how we got here.

The Problem

As a Drupal developer building and maintaining Drupal sites my time is broken up between:

  • Investigating and resolving bugs/defects with the current live/production version of a site
  • Applying security fixes and recommended module updates
  • Building new features

At Deeson we use Gitflow and utilise:

  • “hotfix” branches for fixing bugs, applying security updates and recommended modules updates
  • “feature” branches for site additions and new site features

We do all of our development locally creating Git tags and releasing the tagged Git revision to the production site.

Drupal 7 is notorious for putting configuration into the database that backs the site so we utilise the Drupal Features contrib module to get configuration of content types, fields, display modes, etc out of the database and into code where it can be version controlled.

In spite all of the above it is still not completely possible to prevent the Drupal database containing artefacts from other iterations of the Drupal site as you switched between your branches in Git.

This is not ideal as those artefacts can prevent the site from working correctly with the current branch that you are working with.

Real example

Consider this scenario. We are working on a new feature in a Gitflow feature branch. We have a content type named “news” with an existing field of “title” and we are adding a field named “byline”.

We used Drupal Features to get the configuration for “byline” into our “news” feature module. During the course of our development we have to make a change to the field settings for “title” in the production site.

We create a new Gitflow “hotfix” branch and check it out. If we were to list the state of our Drupal Features we would find that the “news” feature is showing as overridden. Why? Because the site database contains configuration for the “byline” field which is attached to the “news” content type and those settings are not in the “news” feature in our hotfix branch.

So, what can we do to avoid those artefacts from getting in the way of our site development?

We could dump the state of the database to disk before switching to another branch and after switching branch restore that branch’s database. Drupal databases can grow large and this can be a slow process and not very efficient for small changes we might need to make. It is also prone to human error.

OK, so why not create a database for each branch of our site?

Whilst there is an initial setup cost per branch, this is more efficient than the previous approach.

However, we would need to keep changing the database name in the Drupal settings or come up with some clever logic allowing Drupal to select the correct database based on branch. Once again this is still prone to human error.

The above approach does not solve the problem of preventing artefacts in our Solr indices. So, maybe we create separate Solr cores per site branch to avoid this? While that could work we are now growing the initial branch setup and maintenance costs.

Instead, I will simply create a new installation of the Drupal site, with its own database, Solr core. I will get a copy of the production database, maybe even the sites files, and reindex the site content into Solr.

Now we are on the right track. But the setup cost of each new branch is now massive to the point we would have to ask ourselves whether what we are going to work on warrants the setup costs or could we just live with the risk of artefacts and avoid all of this?

The Nirvana of Containerised Development

At Deeson we have been trying to solve the challenges above now for a few months and we believe we have found a strategy that is free from the kinds of human error that has been discussed above.

Imagine the scenario where we have a sort of Virtual Machine for each of the branches of a Drupal site we are working on.

Each VM runs its own database, Solr core, has its own public/private filesystem. If we had a copy of the production version of a site running in a VM, we could simply clone that VM, but the cloning would need to be quick and efficient.

Enter Linux Containers (or LXC). Linux Containers are like lightweight Virtual Machines running inside of Linux. If you place the filesystem of each container on a filesystem like BTRFS then it is possible for a Linux Container to be cloned in seconds. If we could network those containers so that our host machine could reach them and if we could introduce some DNS resolution so each container could have a unique name, then we could potentially have found our optimal solution.

Well, we have been working really hard at Deeson to make this happen and we are pleased to introduce to you the development environment we are using - Rainmaker.

This is being used in anger now but still in development. If you want to try out the latest Alpha then follow the links below - otherwise stay tuned for more updates!

Catégories: Elsewhere

ThinkShout: Five Years

lun, 11/01/2016 - 10:30

Five years ago today, Sean and I met on the rainy steps of our attorney’s office in downtown Portland. We walked inside and proceeded to sign a small mountain of paperwork to form ThinkShout, Incorporated. Then, the two of us biked back to the 100 square foot office we’d been sharing for the previous year to figure out what the heck it meant to start a company together.

Apart from our name and commitment to helping organizations that are making a positive impact in the world, it’s safe to say that pretty much everything else at ThinkShout has changed since that first day, including the grey in our beards! Personally, the challenges we face with constant change are among the things I like most about my job. As I often say, running ThinkShout has been a new job every 6 months or so, and I’m more excited than ever to see what the future will hold.

In thinking about all that the team has accomplished and everything we’ve experienced these last five years, I spent some time looking at my first annual wrap-up post. What immediately stands out to me is that when we first started the company, most of our focus and pride came from talking about our technology contributions. We dreamt of being the “smartest geeks in the room” and bragged about how everyone at ThinkShout wrote code. Wow, was that ever naive and foolish. Just one of the many, MANY, lessons that Sean I learned as we stumbled down this path. We now understand that it takes so much more than solid technology to help an organization accomplish its goals. You need strategists to define solutions, designers to create delightful user experiences, and project managers to guide projects to success.

Of course, we are still inspired by open source innovations. In fact, this year the aggregate install base of our Drupal contributions peaked at 60,000 websites and we released perhaps our most innovative solution yet, RedHen Raiser, a viral fundraising platform based on RedHen CRM.

At the same time, our understanding of what it means to build a sustainable, values-driven business has matured. We have grown our team to 21 full-time staff, adding service offerings such as user experience design and digital fundraising strategy. We have also grown our leadership team, creating a “small council” of directors who’ve been tasked with making sure that we are responsive to the needs of both our staff and our customers.

It’s because of the strength of this team that we’ve also been able to work with some amazing clients this last year, including the relaunch of the Southern Poverty Law Center’s website, and the kickoff of a new website for The Humane Society of America. We launched 11 client websites and helped 43 organizations craft compelling digital experiences for their constituents.

This last year saw us focus on more than just our client engagements, as we increased our investment into community engagement by almost 50%. We hosted and sponsored over a dozen local events, many focused on fostering diversity in the tech industry. Similarly, we sponsored six regional and five national conferences, with our team leading over 30 hours of community trainings at these events.

We also undertook a major initiative to redefine our mission, vision, and values. Having these guideposts are critical so we don’t “lose our way” as we continue to grow. And one of my proudest experiences of being part of this team, we achieved our long time goal of becoming B Corp certified. B Corp certification provides us with guidelines, metrics, and a community of practice for all of the business decisions that we make in support of our team, our clients, our local community, and the environment. B Corp certification is our a roadmap for continuing to make intentional choices that put people and the planet above profit as we grow and continue to change over the next five, ten, fifteen years and beyond.

Catégories: Elsewhere

OSTraining: Drupal 8 Themes for Beginners

lun, 11/01/2016 - 01:21

A couple of years ago, we realized that a lot of Drupal beginners were asking us for simple, good-looking Drupal themes.

These beginners didn't want sub-themes, base themes, frameworks or complicated installs. So that meant no Omega, Zen, Fusion or Bootstrap. These beginners just wanted a theme could be installed easily and didn't look embarrassing. That lead to "Recommended Themes for Drupal Beginners", one of the most popular posts on this blog.

Now that Drupal 8 is here, we've started to hear the same question: "What theme should beginners use to create their first site?"

Unfortunately, the news is not good at the moment. Only 86 themes are ready for Drupal 8, and I could only find 3 that are suitable for beginners.

Catégories: Elsewhere

Attiks: Dream permissions

dim, 10/01/2016 - 20:57

The Drupal 7 admin/people/permissions is always been troublesome for big Drupal sites, there are some flaws, we hope we have solved.

By Peter Droogmans

Catégories: Elsewhere

Phponwebsites: Drupal 7 – Hide Promoted to front page & Sticky at top of lists options

dim, 10/01/2016 - 16:54
    This blog describes how to hide "Promoted to front page" and "Sticky at top of lists" options from node form in drupal 7. When adding or editing a node, you can see "Publishing options" at bottom of the page which contains 'Published', 'Promoted to front page' and 'Sticky at top of lists' checkbox options. It should look like below image:


       The "Published" option is used to publish the content. The "Promoted to front page" option is used to display content in the front page. The 'Sticky at top of lists' option is used to keep the content sticked to the top of front page. If you don't want to show "Promoted to front page" and "Sticky at top of lists" options, then you can hide those options using hook_form_alter(), hook_form_FORM_ID_alter() and hook_form_BASE_FORM_ID_alter().

Hide Promoted to front page & Sticky at top of lists options in single node form:
       If you want to hide "Promoted to front page" and "Sticky at top of lists" options only in single node form, then you can remove those options from node form using either hook_form_alter() or hook_form_FORM_ID_alter() in drupal 7.  For example, we go to hide those options from article node form.
/**
 * Implement hook_form_alter().
 */
function phponwebsites_form_alter(&$form, &$form_state, $form_id) {
  // to hide promoted to front page option
  if (isset($form['options']['promote'])) {
    $form['options']['promote']['#access'] = FALSE;
  }

  // to hide sticky at top of lists option
  if (isset($form['options']['sticky'])) {
    $form['options']['sticky']['#access'] = FALSE;
  }
}
     Now you go to article node form and check whether "Promoted to front page" and "Sticky at top of lists" options are hidden or not. You couldn’t see those options in article node form. It should look like below image:

Hide Promoted to front page & Sticky at top of lists options in multiple node forms:
     If you want to hide "Promoted to front page" and "Sticky at top of lists" options in all node forms, then you can remove those options using  hook_form_BASE_FORM_ID_alter() in drupal 7.
/**
 * Implement hook_form_BASE_FORM_ID_alter().
 */
function phponwebsites_form_node_form_alter(&$form, &$form_state, $form_id) {
  // to hide promoted to front page option
  if (isset($form['options']['promote'])) {
    $form['options']['promote']['#access'] = FALSE;
  }

  // to hide sticky at top of lists option
  if (isset($form['options']['sticky'])) {
    $form['options']['sticky']['#access'] = FALSE;
  }
}
     Now you could not see those options in all node forms. Now you know how to hide "Promoted to front page" and "Sticky at top of lists" options from node form in drupal 7.Related articles:
Add new menu item into already created menu in Drupal 7
Add class into menu item in Drupal 7
Create menu tab programmatically in Drupal 7
Add custom fields to search api index in Drupal 7
Catégories: Elsewhere

Théodore 'nod_' Biadala: Drupal gets a feature request out of the blue

dim, 10/01/2016 - 10:42

Word is that Drupal is getting a frontend framework. From the multiple options it seems EmberJS is currently a little ahead of Angular and React. As said in Dries original post as well as in the drupal core issue created, nothing is final and everyone interested is asked to check that the set of library in the comparison is sufficient and more importantly that the criteria used for evaluation are relevant.

Discussing those details is not what this post is about, like others I've been questioning the move from Dries. Since many of us are professionals, let's put this in a professional setting and pretend that Dries is just another client making a feature request seemingly out of the blue. To him the problem and solution is clear — obvious even — and it is the only way to achieve his vision. Let's check.

Client side (pun intended)

Drupal's user interfaces for content modeling (Field UI), layout management (Panels), and block management would benefit from no page refreshes, instant previews, and interface previews. These traits could also enrich the experience of site visitors; Drupal's commenting functionality could similarly gain from these characteristics and resemble an experience more like the commenting experience found in Facebook.

Should we decouple Drupal with a client-side framework?.

Pretty weak set of reasons. What is described later in the post can be achieved though regular Ajax and some resonable amount of javascript. Hardly a need for a frontend framework… until you remember what else Dries has been writing about.

As the Drupal community, we need to stop thinking of Drupal as a "content management platform" and start looking at it as a "digital experience platform" used to create ideal visitor experiences.

From content management to digital experience management.

Ideal as in enriched as in, for example, Acquia Lift. Don't get your pitchforks just now, there is no hidden agenda, just finish reading.

How serious is the client

Sometimes features can be swept under the rug and everyone will feel better in the long term. Sometimes the client does not let it go. So how serious is Dries about this? The two posts directly related to frameworks contain 3 387 words and if you include the related posts you can add 10 394 more words. A busy person doesn't write a short story just for fun. So I'd say he is pretty serious about this, and if you read the trail of posts this is not going away.

Client needs

We know a few things about what the client is trying to address:

  1. He expects the web to be completely different in 10 years.
  2. Most sites will need personalization.
  3. Better UX is crucial.
  4. One solution fitting core and contrib.

Since there needs to be one solution, it has to be in core from the start because contrib is not disciplined enough (by design) to come up with one homogeneous solution in less than 10 years.

A little extrapolation

If you have in mind all the posts Dries has been writting on the topic for the past two years it makes sense that web components or websockets do not address the issue of rich interfaces the way a frontend framework would, also in this discussion any PHP-based solution is off-topic. It looks to me that Dries is trying to get the community as well as Drupal ready for what he believes is coming. I deeply disagree on what the future holds for the web but it doesn't mean nothing should be done, just in case. At worst we'll burn the new people who came to help us switch to the new framework.

Solution

All in all, I would agree that under those assumptions, a framework is a valid tool to be using. Putting my JS maintainer hat on I would suggest to jQueryUI-it. Put it in core and use it anecdotally, and hope contrib will pick it up. Also we should chose the framework with the strongest opinion on how to do things. Because Drupal back-end is rather strongly opinionated about what the PHP should look like. It makes sense the JS should be the same.

On Acquia bashing

I've spent more than 2 years as an Acquia consultant, working closely with the Office of the CTO on several big D8 improvements so I've seen how the community is treated from the inside and I've only seen good will towards it. Sometimes things are downplayed, not out of malice, but out of concern for the issue at hand. Which is why I think Dries didn't explicitly mentioned Acquia Lift — but still hinted to it — to not get dragged in an argument about Acquia's influence. There is nothing wrong with that since compared to the fears expressed during D8 cycle, we're far from the worst scenario possible.

On that topic, when people say that Acquia, big companies or startups are influencing Drupal I think they're taking a shortcut. It's more like Acquia clients are influencing Dries, and in turn he steers Drupal to what he thinks is right. But don't forget that between clients and Drupal there is a filter, it's Dries. So far I think we can agree he's been pretty great at Dictatoring Drupal. So let's at least give him the benefit of the doubt.

Put your pitchforks back and grab some paint, there is a bikeshed to paint.

Catégories: Elsewhere

ARREA-Systems: Build a custom calendar module in Drupal 8

dim, 10/01/2016 - 01:15
Build a custom calendar module in Drupal 8 Submitted by JK on Sun, 01/10/2016 - 08:15

 

In this article we will describe how we created the calendar in our back-office management application EK (see demo).

 

 

For this function, we used the FullCalendar plugin and its dependencies.

1) Create the Drupal 8 library

In a file called MyModule.libraries.yml, insert the following css and js configurations:

Catégories: Elsewhere

Akshay Kalose: Drupal 8: Create a Simple Module

sam, 09/01/2016 - 23:05

Drupal 8 came out with many new features and updates at the end of 2015. As Drupal 8 is object oriented and enforces PSR-4 standards, the way you make modules has significantly changed. However, this change makes modules much more organized to fit today’s coding practices. I will be demonstrating how to create a simple … Continue reading "Drupal 8: Create a Simple Module"

The post Drupal 8: Create a Simple Module appeared first on Akshay Kalose.

Catégories: Elsewhere

tanay.co.in: Drupal 7 to Drupal 8 Migration - 101 and Observations

sam, 09/01/2016 - 18:42

So, Drupal 8 has been out. And Migrate framework is now part of core! I haven’t had a chance to try out a D7->D8 migration so far. Knowing that this would be something I might do probably a hundred times in the coming couple of years, I thought of giving it a try.

I will now attempt to migrate this current Drupal 7 website (www.tanay.co.in) to Drupal 8. I shall be taking the MigrateUpgrade-UI path (than the drush path) as described on https://www.drupal.org/node/2257723 . I don’t expect a full-replica of my current site on D8 at the end of this attempt, but we shall take a look at what worked, what didn’t work.

I used 8.0.2 version of Drupal core, and 8.x-1.x-dev release of Migrate Upgrade module.

These observations might probably NOT reflect the current state of the Migrate Upgrade module. It is highly likely that the module performs better than what is observed below - ie, Some issues noticed in this attempt might have already been fixed in the Migrate Upgrade Module.  Chances are also high that I missed some steps or screwed up something.

  1. Download and enable the migrate_upgrade module

  2. Navigate to the /upgrade path on your website

  3. Populate the Source SQL details and the site url to fetch files from

  4. This will show you a list of available and missing upgrade paths.

  5. Hit the “Perform Upgrade” button. Fingers Crossed!

  6. Still running after 5 mins.. Drupal seems to be doing some serious loads of stuff here..

  7. While I was waiting, I thought of checking out the sites/default/files folder on my Drupal 8 site. As I assumed nodes are now being migrated, probably the assets are being fetched. In which case, the sites/default/files should be filling up. Yep, it indeed is being populated..

  8. Let’s check out what is up with the Drupal 8 Database. Yay! It is being populated as well!

    Well, interesting to see that the node table on D8 doesn’t have the title column. I wonder where the titles sit now in D8. There doesn’t seem to be any node_title, node_field_title tables.. Well there seems to be a new table here though. It is node_field_data which seems to hold the titles of the nodes!

    Hello there node_field_data table! Good to see you. I am sure we are going to bump into each other many times in the coming days!

  9. Cool. Let’s switch back to the browser tab where the upgrade was running and see how things are going.

    Wow,. here we go! The upgrade is now complete.

First Look at the website:

The migration has definitely surprised me. I was expecting a lot of broken stuff. But it already looks good. The site seems to have all the content that I care about. I was surprises to see that some of the blocks of static markup, disqus comments that I had at various positions on the D7 site were migrated as-is into almost similar positions on the D8 site. I never expected that to be the case! I was expecting just the nodes and terms being moved around. THIS IS AMAZING so far...

 

Blocks were auto-migrated!

URL Aliases also seem to have come through fine!

Let’s edit a node and see how it looks…

Term References look good!

Although I am not sure if this was the case with only the default “tags” vocabulary. Probably even custom term reference fields added to custom types also get migrated just fine. Unfortunately, I don’t have such custom term reference field on my site to verify this.

All the content types look good!

This is amazing that all the content  types were just re-created by D8 using their structures from D7, at the click of a button!

Let’s open a content type, both in D7 and D8 and see how they compare. I am taking the most used content type on my site - The Article content type that I have got, which I use to post blog posts like this one.

D7:

D8:

Discounting Meta Tags field (that came from a contrib module), all fields look good.

 

The Image Field Attachments are broken :-(

The content type “article” had an image field and a file field. The file field rarely had any files attached but the image field had an image for every blog post. So, what happened to these image attachments:

The Image field was created on the D8 content type automatically by Drupal

The files were fetched and copied from the source site into the D8 sites/default/files folder

An entry was created for each file in the D8 site files table and these files can be managed from “admin/content/files” on the D8 site.

But the images were NOT attached by the migration to the relevant nodes


Let’s see how good things are. Before we check out how things are on the new D8 site with the old content from D7, here are a few things I am interested in:

  1. The content (nodes) obviously

  2. The term references (I don’t have any node references. So I am not bothered about it right now)

  3. Meta Tags (from the D7 Metatags module). This has 2 items of importance

    1. Checking if these tags themselves are migrated. AFAIR, I haven’t used the metatags module to store any per-node keywords on the module’s storage but the meta-tags are made to appear on the node pages using terms from a term reference field attached. So, irrespective of the migration path of metatags module the terms themselves would probably have been migrated into the D8 site if term reference migration worked on #b above

    2. The display of the metatags in the markup - I am not much bothered about them at this point of time. I don’t expect the upgrade to have ported the contrib metatag module configuration as well. Should be good as long as I have the tags available somewhere on the D8 site. I will probably configure the module afresh on the D8 site using tokens similar to those used on the D7 site

      Considering the use of taxonomy for metatags, I could probably discount metatags in defining if the migration was any useful.

       

  4. Images (Each blog post has an image attached to it on an image field). Also, each blog post has a large number of images embedded in the markup (Usually pasted into the WYSIWIG and retrieved automatically by Drupal 7 using https://www.drupal.org/project/get_image module)

  5. URL Aliases / Clean Urls

As such these would be the items I would care about in the migration and see how Drupal 8 at its current state, using the migrate_upgrade path of migration has fared on these items - Content, Term References, Images, Url Aliases

Content

Was well-migrated. Content types were auto-created on D8 by migration. All nodes were migrated without skipping any. Most of the field and content type display configuration was replicated on the D8 site.

References

Looks good. There was only one vocabulary. It was replicated on D8 and all terms were auto-migrated.

Images

The Image field was created on the D8 content type automatically by Drupal

The files were fetched and copied from the source site into the D8 sites/default/files folder

An entry was created for each file in the D8 site files table and these files can be managed from “admin/content/files” on the D8 site.

But the images were NOT attached by the migration to the relevant nodes

Clean Urls / Aliases

Migrated

NOTE: I am not referring to the pathauto settings. But the existing (generated) aliases for existing nodes were migrated.

Site Configuration

This was the item where I was surprised the most. Blocks, Block Configuration, Content type Configuration (Comments etc), Site-wide configuration (Image Styles) were migrated from the source D7 site to D8 without any effect.

Overall, the migration has surprised me. The only significant issue that stood out for me was that the images were not attached to the nodes. There were a couple of smaller issues that I could stumble upon - Like, some of the migrated image styles had the labels missing. I am pretty sure the issue with the image field attachments is logged somewhere on the Issue queue of core or migrate_upgrade module, wherever it fits best. I haven’t verified that. I will probably check that out later.

Thumbnail Image used on Listing - D7 to D8 - is courtesy of Drupalize.me

 
Catégories: Elsewhere

Drupal core announcements: New Coding Standards Update Process

sam, 09/01/2016 - 18:07

The Technical Working Group was rebooted about a year ago and has been working to clarify and close issues related to the technical aspect and ramping up to take on our biggest assignment: vetting, clarifying, accepting, and announcing all coding standards changes.

Historically there has been no official process for coding standards changes and these issues and the nature of them are notoriously difficult to get developers to agree on leading to endless bike-shedding and difficulty in finding complete consensus. To this end we have worked with interested community members to draft and approve a new policy for reviewing, deciding, and announcing new coding standards changes. To that end we have created a new Drupal TWG twitter account to announce the list of issues for consideration, this list will be posted on the Core groups.drupal.org group and linked from the twitter account.

All coding standards issues have been moved from the Technical Working Group issue queue to the new Coding Standards project, the maintainers of which will be the Coding Standards Committee. The Committee will be composed of members appointed by the Technical Working Group and any documentation maintainers (listed in Drupal Core’s maintainers.txt) will be automatically invited to join.

Meetings are held every two weeks where new issues can be identified for inclusion. The first meeting to review and include issues for the first round of updates to coding standards has been scheduled for January 22nd, at which time the committee will review coding standards issues tagged “Needs announcement for final discussion". Issues that are deemed ready by the committee will be included in the announcement following that meeting, at which time a final round of community feedback on the proposed changes will be appreciated. At a subsequent meeting the final discussion will be evaluated and issues may be ratified as official changes.

Catégories: Elsewhere

David Lohmeyer's Blog: Improving Drupal 8 core search when using multiple content entity searches

ven, 08/01/2016 - 18:58

Drupal 8 allows you to create multiple search pages which show up as primary tabs on the search page after performing a search. This is cool, but has the limitation of making the user input a search term a second time when they navigate to the other tab.

Catégories: Elsewhere

Chromatic: The Anatomy of a Good Ticket

ven, 08/01/2016 - 18:08
The Anatomy of a Good Ticket

We previously wrote about how to write a great commit message, but before that commit message is ever written, there was (hopefully) a great ticket that was the impetus for the change. Whether or not a ticket is great is subjective, and it is often how well thought out the details are that makes the difference. The ticket might have everything a developer needs to complete the task, but not provide any insight into how to test the final product. Conversely, it might provide all the details the QA team needs to verify, but not provide any insight into the technical requirements for implementation.

Before we examine the specific things that make up a great ticket let’s first examine some of the best practices that further enhance communication and efficiency:

  • Having all stakeholders using the ticket management system and not allowing any communication of requirements via email or other communication tools that silo information.

  • Ensuring that requirements which are discussed one-on-one or during a meeting are added back into the ticket so nothing is lost or forgotten.

  • Having any message conversations in open channels that allow visibility into the decisions for others working on related issues.

  • Continuously keeping tickets updated with the current status so the whole team is aware of where everyone else is with their tasks.

  • Ensure everyone is familiar with the internal jargon and acronyms used, or ensure they are provided with the tools to decipher the terms.

With some ground rules established, let’s investigate the factors that make for a great ticket.

A User Story

A user story provides a high-level description of functionality from a user’s perspective, such as, "when a user logs in they should be able to see a list of past purchases." Great tickets often start with a user story that answers what is needed and why at a high level.

Clearly Defined Goals & Scope

Clearly stated goals from the business allows the ticket to be resourced correctly. Also, a full understanding of the requested change’s scope will inform what brands, sites, regions, pages, etc. a new feature or change will affect, and is crucial to planning a proper implementation.

Accurate Estimates

A well thought through estimation of the level of effort from developers and other stakeholders will make sprint planning/resourcing much more accurate and sprint reviews/evaluations more insightful.

Understanding of Priority

A clear understanding of the business priorities will ensure timely completion and allow the team to plan ahead, avoiding late nights and weekends.

Knowledge of Blockers

Exposing any potential barriers or blockers during the estimating of the ticket will allow them to be accounted for and even potentially solved before development starts.

Screenshots

Providing screenshots and adding arrows and text for clear communication that makes it very apparent what "this" and “that” are, thus avoiding pronoun trouble.

Documented Designs

Providing detailed requirements with exact values, sizes, states, etc. with considerations for edge cases will make any developer forever grateful. Style guides with documented font names, sizes, weights, etc. are another tool that will improve design workflow efficiency. Additionally, designs can provide:

  • Where every piece of information comes from.

  • How items should appear if a given field or other information source is empty.

  • How long or short variants of a given data point are handled and what logic controls programmatic truncation if applicable.

Contact Information

Providing the names and contact information for other team members who may hold key pieces of information that didn’t make it onto the ticket will prevent blockers and help new developers learn which team members have expertise in other areas. Additionally, providing contact information for external parties when working on third-party integrations will prevent communication gaps and middlemen. Sending a quick introduction when rolling a new person into the mix will get you bonus points.

Code Context

Taking the first step is the hardest part, but often a lead developer will know right where and how to proceed. Providing other developers with the names of functions or files to look for from someone with deeper knowledge of the codebase can save an immense amount of time up front and avoids potential refactoring down the road. It also reduces guesswork and more importantly, might reinforce a best practice when there are multiple approaches that would technically work. Examples of previous implementations or before-and-after code samples are also great things to consider providing.

Reliable Information

Up-to-date acceptance criteria that is verified as accurate and updated if/when requirements changed, and the ability for a developer to have 100% confidence in this information makes everyone’s life better.

Complete Logical Requirements

Thinking through default values or fallback values/logic if a given piece of data is empty by default, instead of treating it as an edge case, allows for cleaner code and reduces emergencies and "bugs" down the road.

Component Driven Separation

Giving everyone on the team discrete chunks of work that can be documented, developed, tested, and completed will allow everyone to feel much better about the progress of the project. Providing clearly defined subtasks that allow chunks of the work to be checked off and delineated clearly when working on larger tickets will help with this. Another key to success is having properly managed dependencies for blocking work so effort is not wasted until all blockers are resolved.

This can be accomplished by separating tickets by components, not pages. For example, "social share bar" and "comment widget" tickets that probably appear on every content type rather than a "article page" ticket that includes building and styling all of those components before it can be considered complete.

Exact URLs

When possible, always provide the exact URLs of pages where the offending bug can be found or the new functionality should be placed. This keeps anyone from making assumptions and when properly paired with a nice screenshot, it really takes the guesswork out of recreating bugs or finding where new features should live.

Reproducible Steps

In addition to exact URLs, a thorough lists of steps to reproduce the bug, the expected result, and the actual result will all help a developer quickly pinpoint and understand a problem. It is just as important for developers to provide QA and business stakeholders with steps to test functionality that is not intuitive or simple to test.

Assumptions & Changes

Finally, not all developers are the same. If you ask two developers to solve the same problem, you might get very different solutions, but the more details you provide them, the better the chance of a successful outcome. Additionally, a developer with a wealth of institutional knowledge might need significantly less information to have a clear picture of what needs to be done, while a new hire, internal transfer or external contractor will likely need more information.

However, I would argue that regardless of the expected assignee’s knowledge, the extra time spent to write a good ticket is rarely wasted. Tickets often get passed around as people take vacations, flat tires happen, and children get sick. When these things inevitably occur, we don’t want to rely upon assumptions, which, no matter how good, only need to be wrong once to cause potentially large amounts of wasted time, embarrassment, liability, etc.

Ways to Work This Into Your Project
  • Create a blocked status for your Agile or Kanban boards and utilize it liberally to ensure high visibility into the unknowns and show others how much time is lost due to blockers.

  • Loop project managers into conversations with the person who filed the initial ticket so they see first hand the level of effort required to track down answers.

  • Talk through the issues during sprint review and review what did and did not go well.

  • Allow developers to review and estimate issues before they are included in a sprint and require clear requirements before accepting a ticket.

  • Don’t just complain; be a part of the solution. Educate stakeholders on the structure you want to see for requirements and provide them with tools to help communicate more clearly such as logic maps, data flow diagramming tools, etc.

What Now?

I encourage you to think of a good ticket not just as a means to an end; be that a fixed bug, a new feature, or new design. Instead, treat it as an opportunity to show respect to each of the many professionals that will touch the ticket through its lifecycle by providing them the information and tools they need to perform their job to the best of their abilities. This respect goes in all directions, from ensuring good requirements for developers, to writing good testing instructions for QA, writing quality code for a great product and providing stable hosting infrastructure. This all culminates in a well-built project that shows respect to what this is ultimately all about: the user.

adam Fri, 01/08/2016 - 17:08
Catégories: Elsewhere

Mediacurrent: One Word to Save your Project

ven, 08/01/2016 - 14:57

When faced with requirements that threaten to break the budget, blow the scope, derail the schedule and generally destroy a project, there is one magic word that can come to the rescue.

Why.

Asking “Why?” can help clarify, or neutralize, potentially destructive requirements and ultimately save the day.

Catégories: Elsewhere

Deeson: The Curious Incident of the Wrong Theme being used after a Cache Clear in Drupal 7

ven, 08/01/2016 - 12:30

If you are using Drupal 7, have multiple themes enabled, are using hook_custom_theme() to choose the right one and find that after a cache clear the first page load chooses the wrong theme, then this blog post is for you.

On a couple of recent projects we have been using hook_custom_theme() to set one of several active themes for a given page request. This is a really useful hook allowing us to change the look and feel for different parts of the site. For example, we might use a different theme if a page is part of a Drupal Group which makes it look like a sub-site.

We were seeing an odd behaviour where the site default theme would load on the first page request after a cache clear, rather than the one we were returning from our hook_custom_theme implementation. Debugging showed that hook_custom_theme() was being fired and our implementation was returning the right option during the first page load.

Subsequent page requests following the first after a cache clear would result in the correct theme being used. The problem was that if that first page was opened by an anonymous user it would get varnish cached and all users would see the page in the wrong theme for a few hours.

The reason

The problem is the functions we were putting into hook_custom_theme().

hook_custom_theme() along with hoot_url_inbound_alter() and hook_boot() all get called very early in the drupal boot cycle and not everything has been properly initialised at this point, including the correct theme. If you call code that assumes this has happened then odd things can happen.

Following a cache clear the menu needs to be rebuilt - and this is a complex operation which calls a lot of code and prematurely sets the site to use the default theme.

If you access the menu, for example by using ​menu_get_item, ​menu_get_object or even node_load​ in these functions you will trigger a menu build too early and initialise the default theme. 

Solutions

The solutions are to keep the code in the hooks which run before the theme is initialised as simple as possible.

For example, do you need to load the menu to decide the theme or can it be infered from the current path? Rather than load the whole node, can you do a simple db_select on the node table to get the information you need?

Catégories: Elsewhere

OSTraining: Add a Floating Feedback Button in Drupal 7

ven, 08/01/2016 - 02:13

One of our users wanted to know how to add a floating button to his Drupal site. Luckily, this task is easy to accomplish thanks to the Feedback Simple module.

In this short tutorial, I'll share with you how to add a floating feedback button linked to a contact page in Drupal 7.

Catégories: Elsewhere

Pages