In the last Paragraphs tutorial, you were introduced to the module and we created a basic paragraph type called Content. We only skimmed the surface of what the module can really do. To utilize Paragraphs to its full potential you need to learn how to create a container paragraph type and nest paragraph items.
The concept of a container is fairly simple. It's a paragraph type that has its own paragraph field on it and allows a user to nest paragraph items.
In this tutorial, we'll create a container paragraph called Banner, it'll have two fields: image and paragraphs.
When a banner paragraph is created and an image is uploaded, the image will be displayed as a background style. Now, I do understand there're multiple ways of doing this, but for simplicity we'll set it using a background style on the paragraph element.
All nested paragraphs will be rendered inside the container and displayed with the background. If you want to add any other settings, i.e., parallax configuration, you would place it on the container paragraph.
Drupal Console is software which allows you to alter your Drupal installation through the command line. According to the official website, “The Drupal Console is a CLI tool to generate boilerplate code, interact and debug Drupal 8.” Unlike Drush, Drupal Console is specifically for Drupal 8, the latest major release. Although Drupal Console and Drush … Continue reading "Drupal Console: Generate Module & Theme Code"
Modules Unraveled: Install Drush 7 and 8 Side-by-Side and Automatically Switch Versions Based on Each Project
Have you started working with Drupal 8 yet? If so, you might have noticed that Drush 7 doesn't play nice with Drupal 8. And if you install Drush 8, that won't work with your Drupal 7 sites. Yikes!
Have no fear!
Here's how to install BOTH Drush 7 and Drush 8 AND have each project automatically use the version that corresponds to that install. It's stinkin' awesome!Uninstall existing Drush instances
Okay, the first thing you'll want to do is uninstall every version of Drush that you already have installed. This process varies depending on how you installed it, but for example, if you installed with homebrew, the command would be something like brew remove --force drush.Install Composer
We're going to install multiple versions of Drush using Composer, so we need to make sure you have that installed first. Detailed instructions on how to install Composer globally are on their website, but here's the gist.curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer
Note: If this fails due to permissions, run the mv line again with sudo. You may also have to create the /usr/local/bin directory first, depending on your existing system.
- To confirm composer was successfully installed, type composer --version and you should see something like "Composer version 1.0-dev (...) 2016-01-20 11:17:40"
Okay, let's install Drush 8!cd /usr/local/bin
composer require drush/drush:8.0.x-dev
ln -s /usr/local/bin/drush-8/vendor/bin/drush /usr/local/bin/drush8
- The "composer require..." line will download the latest dev release, you could replace "8.0.x-dev" with "8.0.2", for example, to download that specific version.
- The "ln -s..." line creates a "symbolic link" called "drush8" in the /usr/local/bin directory to the location where Drush 8 is installed. This means that we can call it from anywhere on the system by typing "drush8 --version", for example.
Easy!Install Drush 7
Now, we'll install Drush 7!cd /usr/local/bin
composer require drush/drush:7.x-dev
ln -s /usr/local/bin/drush-7/vendor/bin/drush /usr/local/bin/drush7
- The "composer require..." line will download the latest dev release, you could replace "7.x-dev" with "7.1.0", for example, to download that specific version.
- The "ln -s..." line creates a "symbolic link" called "drush7" in the /usr/local/bin directory to the location where Drush 7 is installed. This means that we can call it from anywhere on the system by typing "drush7 --version", for example.
Now, if you're already used to typing something like "drush --version" (without the specific version number), remembering to use it can be a little cumbersome, so now, we're going to create a little shell script that will automatically use the correct one for each project based on a git config variable that we set.cd /usr/local/bin
- Press the "i" key to enter "insert" mode
- Paste the following
version=$(git config --get drush.version)
if [ "$version" = '7' ];
- Press "esc", then type ":wq" and press "enter" to save and quit this file
- Type chmod +x drush (This makes the "drush" script we just created executable.)
Now, when we type a command like "drush --version" it will use Drush 8 by default. In order to use Drush 7, we need to set a configuration variable in the git repo of the project that should use it.Set Drush 7 as the Required Version for a Project cd /path/to/project
git config drush.version 7
- The first time you run "drush --version" it should return something like "Drush Version : 8.0.0-rc3" showing that you're using Drush 8
- The "git config..." line declares that you want to use Drush 7 for this project
- The second time you run "drush --version" It should show somethign like "Drush Version : 7.1.0". If so, you're all set!
You might want/need to close and re-open all terminal windows to make sure it takes effect.
If you have any questions about, or issues with, this setup, let me know in the comments!Tags: DrushDrupal 7Drupal 8Command Lineplanet-drupal
In previous article we have seen how to declare the data accessible in a custom view in MyModule.
Now that the data from our tables mymodule_tb (and mymodule_tb_2) are available, let's create the list view.
First navigate to "/admin/structure/views/add" and create the view by entering basic information as per the example below.
After "save" you are redirected to "Edit" form where further settings will be set.1) Add fields from you source table
From this form, select the fields to display. We will select 2 here "name" and "type" (refer to the table structure declared in MyModule_views_data())
Three years ago, I ended 2012 with a call to the Drupal community to Get Off the Island. Mainly I wanted to encourage Drupal developers to prepare themselves for the major changes coming in Drupal 8 by connecting with other PHP projects and with the broader community, and called on people to attend non-Drupal conferences in order to visit and learn from other communities.
We are often challenged with the maintenance of existing projects that were developed by other agencies, or a new developer arrives and we need to quickly bring them on board. The complexity of legacy projects can be very high and the risk of breaking existing logic is something we want to avoid.
One way we like to look at a project before diving into the code is through its data structure. The different entities and their relations can tell us a lot about the business logic of the site and its internal logic. We assumed that if we could easily generate a graph with all the bundles, entities, and their relations this complex task would be easier.
Having done this for a while now, I believe our assumption was right. Taking our open-source Productivity project (Gizra's internal ERP/Project management system) as an example, it's much easier to look at the following graph and understand that Work session, Time tracking, Payment, and Github Issue bundles are pointing at a Project, which in turn points to an Account bundle. Github Issue can also reference itself.
If you use Drupal either in house or as part of a service to clients you're already aware of how versatile and useful it can be if utilised well. One of the benefits of using Drupal is that it's free, but there are other benefits available to you if you decide to join in with the community.
The TWG coding standards committee is announcing two coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The new process for proposing and ratifying changes is documented on the coding standards project page.
The two issues being proposed are:
- Please relax requirement for @file when using OO Class or Interface per file: 'ERROR | Missing file doc comment'
- [policy, then patch] Consistent .install file layout
These proposals will be re-evaluated during the next coding standards meeting currently scheduled for February 5th. At that point the discussion may be extended, or the policy may be dismissed or ratified and moved to the ‘update documentation’ step.
Acquia Developer Center Blog: Acquia U: "Jump in and own it. Kickstart your career." - meet Amy Parker
Amy Parker, the Director of Acquia University--aka Acquia U--and I sat down in Acquia's downtown Boston headquarters to talk about Acquia's technology boot camp. The course covers much more than Drupal; the curriculum is designed to produce people able to work in tech companies: Besides a whole lot of Drupal and related technologies, it includes agile methodologies, project management tools, troubleshooting tickets, presentation skills, and more. Listen to our whole conversation to learn more.
"If you think about it, the very senior-level, highly skilled Drupalists are already employed and there isn't a succession plan and there isn't a talent pipeline. This program is really not just about Acquia's ability to hire internally; it's about partnering with our community to be able to offer an opportunity to ramp up their teams."What is Acquia U?
Amy: "Acquia U is a 14-week, hands-on, intensive, technical boot camp to take people who have a strong interest in web technology and bring them into the world of Drupal. [At the end of the course], depending on their skills coming in, they're prepared to become people who can build websites using Drupal and integrate it into a larger digital platform and a digital strategy ... Entry level Drupalists!"
"Drupal is unknown to people entering into the career market in web technologies. The problem that we find from an education perspective is that it's not taught in a lot of high schools or universities," even among computer science majors.Interview video - 25 min. Origin story
A need arose in 2011--Amy mistakenly says 2001 in the recording--to hire more people faster and Acquia U was launched as an internal initiative, taught by Acquians. "It was very successful. They had nine people in the program. Eight completed the program. Eight were hired here at Acquia." And many are still at Acquia, while others have moved on to careers outside the company. "I don't consider that a loss, because those are Drupal evangelists out in other technology fields."Mission
Acquia U's mission is to help make Drupal better known overall, help create more interest and Drupalists, and connect people with careers in Drupal. It also has the ambition to try to fill the gap Amy describes thus: "There's no way that we can't not give back talent into the organisation. Acquia is struggling to hire. All Drupal companies are struggling to hire. If you think about it, the very senior-level, highly skilled Drupalists are already employed and there isn't a succession plan and there isn't a talent pipeline. This program is really not just about Acquia's ability to hire internally; it's about partnering with our community to be able to offer an opportunity to ramp up their teams."
"In the next year to two years, I would like to see this program filling the void of junior-level talent in a lot of different spaces: whether it's in a non-profit, at a partner company, a client company, at another digital, Drupal shop."The ideal candidate
"For me, it's about finding people who might not otherwise get a job here ... so I look in other places. If I think about it, somebody who's looking for a position at Acquia U may not know how to navigate a Drupal career path, so I go to places they may not have looked before. Going to the places where you might not think to traditionally find Drupalists is the place to go to find new Drupalists."
"I have a strong interest, as does Acquia, in hiring people in underserved populations: women ... veterans ... different age groups. My vision of the ideal candidate has nothing to do with age or background. The foundation of being successful here is potential. I define potential on:
- What's motivating them: "If I'm motivated by giving to the community or participating in something larger than myself, that's awesome."
- Curiosity: "One of my favorite questions [to ask] is 'What's the last creative thing that you did? What's the last thing that you did that was really interesting?'"
- "We look for people that are motivated by their sense of integrity and wanting to learn.""
"A good candidate, the people that are successful and come through the program ... are the people that demonstrate strong interest in something innovative, creative, fast-paced. They're looking for not just a job."More Amy and Acquia U on the web!
- Acquia Podcast with Keith Donaldson, Acquia U graduate, 2015: Drupal, the fastest way from idea to MVP
- Amy spoke with Brian Lewis in 2015 on Modules Unravelled Podcast 132, AcquiaU (here's the video of their conversation).
- Amy was a guest on DrupalEasy podcast 141 in 2014.
The holidays are a distant memory, and Drupal 8 contrib work is happening in full force. Time for another 2.x alpha. The past three weeks have seen bug fixes, test work, and many internal cleanups. But let's focus on the bigger changes.
Reminder: Commerce 2.x alphas are NOT production ready. No upgrade path is provided between alphas, a full reinstall is needed each time.
Each day, more Drupal 7 modules are being migrated over to Drupal 8 and new ones are being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules available for Drupal 8. This week: BigPipe.Tags: acquia drupal planetbigpipedrupal 8
Mediacurrent: DrupalCamp Atlanta 2015: A First Look at Behavior Driven Development with Behat in Drupal
Engineers and developers tend to be passionate about building something great, and Drupal is the ideal foundation.
In this presentation from DrupalCamp Atlanta 2015, I explain why testing is the best way to ensure sustainable quality in what you build. While Drupal already uses some great tools for this (simpletest, php code sniffer, php unit) I like to talk about another option: Behat, and the Behavior Driven Development paradigm that it encourages.
For individuals in the Drupal community who want to attend DrupalCon but are unable to do so due to financial considerations, the Drupal Association is pleased to offer scholarships and grants. Whether you need Drupal or Drupal needs you, we're here to help qualified individuals make their dreams of attending DrupalCon a reality.
So, how does it work? There's a bit of a difference between scholarships and grants, which were introduced for DrupalCon Prague. The difference can be summarized in the two following phrases:
I'm excited to be starting a new Drupal 8 project. I get to try new and shiny things. Only this time I'm breaking things along the way as I figure out what some of our new processes will be with Drupal 8.
Part of what I've been looking into is how to go about providing local environments to team members, building out the code-base, etc. With Drupal 7 I was pretty comfortable using .make files, install profiles and distributions. I wanted to give Drupal Composer a try. There are several other articles that discuss Drupal Composer and more specifically Drupal Project (Composer template for Drupal projects). I'll leave it up to you to read through those other articles.
I wanted to keep this short and sweet and point out an issue I ran into and what the work-around is in case anyone else runs into similar issues.
While running "composer install" I started to get the following error.
The "https://packagist.drupal-composer.org/p/provider-archived%241a0102814c28..." file could not be downloaded (HTTP/1.1 404 Not Found)
A good couple of hours was spent trying to track down what I may have done to break the process. I went to https://packagist.drupal-composer.org and at first inspection the site looked up. Then I started browsing for packages and noticed that when trying to view a package the server was returning a 500 error. This was the likely culprit of the 404 issue I was receiving.
Now that I know it's most likely not an issue with my composer.json file, my next task was figuring out how to work-around packagist.drupal-composer.org being essentially offline. I needed to get some work done.
On the off chance that packagist.drupal-composer.org was just another domain for packagist.org, I modified my composer.json file changing:
While I can't use "sudo composer create-project drupal-composer/drupal-project:~8.0 drupal --stability dev --no-interaction" mentioned in the articles linked to above, I was able to simply download the project template and then run "composer install". All of the packages downloaded without issue and things are starting to get back on track.
Hopefully this is just a random server down issue but in case anyone else runs into the same issue, maybe this will be helpful.
We recently launched our first Drupal 8 site--actually it’s this very site that you’re reading! While this wasn’t our first time using or developing for Drupal 8, it was our first full site build and launch on the new platform. As such, it was the first time we needed to handle Drupal 8 code deployments. While I’ve previously covered the benefits of using Jenkins, this post will take you through the steps to create a proper Drupal 8 deployment and how to integrate GitHub and Slack along the way. In other words, you’ll see our current recipe for deploying code automatically, consistently and transparently.First Things First: Some Assumptions
This post assumes you already have a Jenkins server up and running with the following plugins installed:
If you don’t yet have these things ready to go, getting a Jenkins server setup is well documented here. As is how to install Jenkins plugins. For us, we typically use a Linode instance running Ubuntu LTS for our Jenkins servers. This post also assumes that the external environment you’re trying to deploy to already has Drush for Drupal 8 installed.Example Deployment Script with Drush
Before we dive into setting up the Jenkins job to facilitate code deployments, I’d like to take a look at what exactly we’re trying to automate or delegate to our good friend Jenkins. At the heart of virtually any of our Drupal deployments (be them Drupal 7, 8 or otherwise) is a simple bash script that executes Drush command in succession. At a macro level, this typically means doing the following, regardless of version:
- SSH to the server
- Change directory to repository docroot
- Pull down latest code on the master branch
- Clear Drush cache
- Run database updates
- Update production configuration
- Clear Drupal caches
In Drupal 7, where we relied heavily on Features to deploy configuration, we would typically do something like this:echo "" echo "Switching to project docroot." cd /var/www/drupal-7-project/docroot echo "" echo "Pulling down latest code." git pull origin master echo "" echo "Clearing drush cache" drush cc drush echo "" echo "Run database updates." drush updb -y echo "" echo "Reverting features modules." drush fra -y echo "" echo "Clearing caches." echo "" drush cc all echo "" echo "Deployment complete."
In Drupal 8, we have the magical unicorn that is the Configuration Management System, so our deployments scripts now look something like this:
If you’re familiar with creating Jenkins jobs already and are just looking for a Drupal 8 deploy script, these next lines are for you.echo "" echo "Switching to project docroot." cd /var/www/chromatichq.com/docroot echo "" echo "Pulling down the latest code." git pull origin master echo "" echo "Clearing drush caches." drush cache-clear drush echo "" echo "Running database updates." drush updb -y echo "" echo "Importing configuration." drush config-import -y echo "" echo "Clearing caches." drush cr echo "" echo "Deployment complete."
Seriously, configuration management in Drupal 8 is amazing. Hat tip to all of those who worked on it. Bravo.
Another notable difference is that with Drupal 8, clearing caches uses the cache-rebuild Drush command or drush cr for short. drush cc all has been deprecated. R.I.P. little buddy. ⚰
If you have a site that needs to be put into "Maintenance mode" during deployments, you can handle that in Drupal 8 with drush sset system.maintenance_mode 1 to enable and drush sset system.maintenance_mode 0 to disable.Creating our Jenkins Slave & Job
Now that we’ve covered what it is we want Jenkins to handle automatically for us, let’s quickly run down the punch list of things we want to accomplish with our deployment before we dive into the actual how-to:
- Automatically kickoff our deployment script when merges to the master branch occur in GitHub
- Run our deployment script from above (deploys latest code, imports config, clears caches, etc.)
- Report deployment results back to Slack (success, failure, etc.)
For Jenkins to orchestrate anything on a remote box, it first needs to know about said box. In Jenkins parlance, this is known as a "node". In our case, since we’re connecting to a remote machine, we’ll use a “Dumb Slave”. Navigate to Manage Jenkins > Manage Nodes > New Node
At Chromatic our naming convention matches whatever we’ve named the machine in Ansible. For the purposes of this article, you can just name this something that makes sense to you. Example:** Drupal-Prod-01**
As part of the creation of this node, you’ll need to specify the Host and the Credentials Jenkins should use to access the box remotely. If you don’t yet have credentials added to Jenkins, you can do so at Jenkins > Credentials > Global credentials (unrestricted). From there things are pretty self-explanatory.Setup the Basics for our Jenkins Job
Now that we have a way for Jenkins to target a specific server (our slave node) we can start building our deployment job from scratch. Start by navigating to: Jenkins > New Item > Freestyle Project.
From there press "OK" and move on to setting up some basic information about your job, including Project Name, Description and the URL to your GitHub repository. Pro tip: take the time to add as much detail here, especially in the Description field as you can. You’ll thank yourself later when you have loads of jobs.Configure Slack Notification Settings (optional)
Assuming you’re interested in tying your deployment status messages to Slack and you’ve installed the Slack Notification Plugin, the next step is to tell Jenkins how/where to report to Slack. You do this under the Slack Notifications options area. As far as notifications go, we prefer to use only the "Notify Failure", “Notify Success” and “Notify Back To Normal” options. This is the right mix of useful information without becoming noisy. To allow Jenkins to connect to your Slack channels, you’ll need to follow these steps for adding a Jenkins integration. Then just fill in your Slack domain, the integration token from Slack and the channel you’d like to post to. These settings are hidden under “Advanced…”.Configure Where this Job Can Run
This is where we instruct Jenkins on which nodes the job is allowed to run. In this case, we’ll limit our job to the slave we created in step one: Drupal-8-Prod-01. This ensures that the job can’t run, even accidentally, on any other nodes that Jenkins knows about. Jenkins allows this to be one node, multiple nodes, or a group.Configure GitHub Repository Integration
Under "Source Code Management" we’ll specify our version control system, where are repository lives, the credentials used to access the repo and the branches to “listen” to. In our example, the settings look like this:
Here we’re using a jenkins system user on our servers that has read access on our GitHub repositories. You’ll want to configure credentials that make sense for your architecture. Our "Branch Specifier" (*/master) tells Jenkins to look for changes on the master branch or any remote name by using the wildcard, “*”.Configure Your Build Triggers
This is where the rubber meets the road in terms automation. At Chromatic, we typically opt for smaller, more frequent deployments instead of larger releases where there is a higher probability of regressions. Since we rely heavily on the GitHub pull request model, we often have many merges to master on any given day of development for an active project. So we configure our deployments to coincide with these merges. The following setup (provided via the GitHub Jenkins Plugin) allows us to automate this by selecting "Build when a change is pushed to GitHub".Setup Your Deployment Script
Here’s where we’ll implement the example deployment script I wrote about earlier in the post. This is the meat and potatoes of our job, or simply put, this is what Jenkins is going to do now that it finally knows how/when to do it.
Under "Build" choose “Add build step” and select “Execute shell”. Depending on your installed plugins, your list of options might vary.
Then add your deployment script to the textarea that Jenkins exposed to you. If you want somewhere to start, here is a gist of my job from above. When you’ve added your script it should look something like this:Last Step! Enable Slack Notifications
Although earlier in the job we configured our Slack integration, we still need to tell Jenkins to send any/all notifications back to Slack when a build is complete. You do this sort of thing under the "Add post-build action" menu. Select “Slack Notifications” and you’re good to go.
Our deployment job for Drupal 8 is now complete! Click "Save" and you should be able to start testing your deployments. To test the job itself, you can simply press “Build Now” on the following screen OR you can test your GitHub integration by making any change on the master branch (or whichever branch you configured). With the setup I’ve covered here, Jenkins will respond automatically to merges and hot-fix style commits to master. That is to say, when a PR is merged or when someone commits directly to master. Of course no one on your team would ever commit directly to master, would they?!Wrapping Up
Assuming everything is setup properly, you should now have a robust automatic deployment system for your Drupal 8 project! Having your deployments automated in this way keeps them consistent and adds transparency to your entire team.
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.
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.
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.
Beginning in version 8, Drupal does not load jQuery by default. Great - no issues for us! However, the long, shadowy spectre of jQuery haunted development.Even if you’re not using jQuery, it can still load for anonymous users.
You have your libraries.yml file free of any dependencies, and you’re deep into development when you notice jQuery is still loading. Why? Contrib modules can still require jQuery.
For us, the culprit was the Google Analytics module. It’s a great contributed module, but because of the overhead it brought, we decided to create a custom module and attach our tracking code separately.More to come.
I’m sure there will be other gotchas as D8 proliferates in the wild, but hopefully these two will save you some time in case you find yourself wondering, much like I was, why jQuery still cast its shadow. Now get back to it, and build something awesome.Correction