In our 4 part series on "Faster Drupal", we have so far published three different articles on:
- Faster Drupal: Part 1: Caching
- Faster Drupal: Part 2: Aggregation, CDN and Image Optimization
- Faster Drupal: Part 3: Theming
If you haven't already read those parts, go ahead and check them out! Now let's get to our beloved CSS/JS stuff!Faster Drupal - Part 4: CSS/JS Tips
We’ve come to find this amazing blog post by Charlie Gerard, The first three items are from her blog post, I added the TL;DR version that we need for this guide but it's worth checking:
CSS: Avoid modifying layout wherever possible: Changes to some CSS properties will require the whole layout to be updated. For example, properties like width, height, top, left (also referred to as “geometric properties”), require the layout to be calculated and the render tree to be updated.
CSS: The descendant selector can be expensive: in an example like this: #nav a The browser is going to assess all the links on the page before settling to the ones actually inside our #nav section. A more performant way to do this would be to add a specific selector of .navigation-link on each <a> inside our #nav element. CSS: Browser reads selectors from right to left, so less selector the better
- CSS: Some CSS properties are more expensive than others. What this means is that they take longer to paint.
Some of these expensive properties include:
- position: fixed
- Check to see if you are overriding your CSS selectors, there are IDE tools for that
- Avoid duplicated CSS selectors, in large scale websites I’m pretty sure you can find a lot of them
- Avoid !important declaration
- The Drupal core will call attached behaviors when the DOM (the object representation of the HTML) is fully loaded and on each AJAX response altering the DOM.
- Conditionally load assets where necessary! You have some JS or CSS only being used for certain nodes/content-types/pages? Load those files for those necessary pages only
- Consider component-based themes that handle assets per component such as bootstrap_storybook
- Use the async attribute
- Use the defer attribute
- Make sure your scripts are placed at the bottom of the page (ideally at the end of the body) unless you really need it to be in the head..
- Be sure to deliver the lightest possible font format. And also note the order of fonts loading is important as well. The preferred order of web font formats are as follows:
- Try vanilla JS instead of jQuery: I mean we all love jQuery and it has saved us a lot of time and headache in the past, however nowadays you might not need jQuery for most of day-to-day operations.
That said.. Sometimes you gotta do what you gotta do, but even then: do yourself a favour and use the latest jQuery available, not the default which comes with Drupal core to get the most updated library.
- In Drupal 8 you can go one step further: Since D8 jQuery is not automatically loaded in the frontend so you can remove the jquery dependency from your theme's libraries and just use Vanilla JS!
- Consider making a CSS/Image sprite out of your icons, especially if your users are still heavily using HTTP1.1.
On the other hand if most of your traffic si via HTTP2 the number of your requests to the server are not really an issue (but don't go crazy)!
Are we done with this list? Never! We would like to continuously improve it.
We would also love to have your comments and suggestions!
Written by Sohail Lajevardi
Developer at Ramsalt Lab
Our normally scheduled call to chat about all things Drupal and nonprofits will happen TOMORROW, Thursday, August 20, at 1pm ET / 10am PT. (Convert to your local time zone.)
No set agenda this month -- we can discuss whatever Drupal related thoughts are on your mind. If you would like to contribute to the conversation, please join us.
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes
This free call is sponsored by NTEN.org but open to everyone.
- Join the call: https://us02web.zoom.us/j/329736027
- Meeting ID: 329 736 027
- One tap mobile:
+13017158592,,329736027# US (Germantown)
+13126266799,,329736027# US (Chicago)
- Dial by your location:
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 929 205 6099 US (New York)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
- Find your local number: https://us02web.zoom.us/u/kegAvyuFSW
- Follow along on Google Docs: https://nten.org/drupal/notes
- Follow along on Twitter: #npdrupal
Following up with the Continuous Deployment, Infrastructure as Code, and Drupal series, where we used DigitalOcean as the cloud provider, in this article we will see how to set up a continuous deployment workflow that uses Google Cloud. Based on the promise of the Cloud Native Foundation, it should be very similar.
First of all, Drupal is not dead. But I would argue it's not in healthy place relative to competing projects as it was in its heyday, in the early 2010s.
In this blog post, I will explore the problem the Drupal community finds itself in five years after a major release that broke backwards compatibility in almost every subsystem, forcing a laborious upgrade process and process shift that left many users in the dust.
I've written about this in the past, most famously in my post Drupal 8 successes and failures. I'm not going to rehash the details from that post, but I did want to focus on what I think is the primary reason for this graph's downward trajectory since 2016:Jeff Geerling August 19, 2020
We can’t believe DrupalCon Global was a month ago. As we’re looking ahead to future DrupalCons in 2020 and 2021, we wanted to begin by looking back at DrupalCon Global 2020.
Find out why the jump from Drupal 8 to 9 really no big deal.
When a new product rolls out, it raises a lot of interest. The Drupal 9 release is no exception. This interest is easy to understand because new versions of Drupal bring new digital opportunities. Today, interactions with potential customers have shifted into the virtual sphere, so websites have an especially important mission to perform.Read more
Exactly two years ago, I decided to step up and nominate myself to run for the board of the Drupal Association.
You might wonder, how does someone decide to volunteer hundreds of hours of their time to sit on the board of a non-profit organization? What's the motivation?Stepping Forward
To be elected to the board of the Drupal Association, you have to nominate yourself. To me, nominating yourself feels strange, like telling all your friends at the dog park that your dog is cuter than theirs. Telling people to vote for you in an open source "do-ocracy" feels like the opposite of standard behaviour.
Volunteering for a board position might seem like a big career leap; something you're not qualified to do. But I think in most volunteer board positions, really wanting the job is the most important prerequisite.What Motivates My Volunteerism
Earlier this year at a Drupal Association board retreat, we went around the table and answered the question “Why Drupal?”.
Not “Why do we use Drupal the software?”, but rather “Why are we each personally passionate about Drupal and the community that creates and supports it?”.
The answers were varied and heartfelt.
People volunteer for a board because they truly care about the vision of the organization they serve. That motivation has to be there.
It's also about the board members and staff you get to work with—volunteering with a group of talented people from around the world is inspiring. And even though the Drupal Association is small, it accomplishes a lot.
Over the past two years, highlights have included:
- Transforming a massive conference into a virtual event
- A successful fundraising campaign, Drupal Cares
- Releasing Drupal 9
- Launching a security product for Drupal
- Initiating Scholarship and Talent Programs to increase diversity and inclusion in the Drupal community
🧰 🔧 Join Suzanne for our upcoming free webinar, How to Use Assistive Technology to Improve Web Accessibility, on September 9! You'll discover all kinds of tools and techniques that you can use to unlock valuable insights about your website's accessibility. Save your spot today!.Getting Perspective
If you are motivated by the vision of a non-profit organization, think about stepping up to volunteer for the board. Over my two-year term, not only have I had a chance to contribute to a really unique and inspiring community, I’ve also learned a lot of practical leadership skills from fellow board members and the staff of the Drupal Association. And I've gotten a much broader perspective of what marketing and community engagement looks like in a global organization, beyond the 30-person agency that I run.
While I’m sad to leave my board position now that my term is up, I also now have more skills, and more confidence to continue contributing to marketing Drupal and growing the community around it. The Promote Drupal initiative in particular is a unique opportunity to amplify the Drupal brand around the globe, and I'll be continuing to push Promote Drupal forward.Step Up and Nominate Yourself
If you are elected to the board of the Drupal Association, you’ll get a chance to serve with the most dedicated groups of volunteers you’ll ever encounter. And if you nominate yourself and aren’t elected, just the act of making a video of your “Drupal story” is a really great experience (even if you’re an introvert like me, and it puts you outside your comfort zone).
If you're thinking about it, I highly recommend that you go ahead and nominate yourself.+ more awesome articles by Evolving Web
Lucius Digital: Sending html mails in Drupal 8/9 programmatically. An example Drupal module including Twig template
We read a lot of great Drupal content last month, covering a few different topics. Check out our recap of July’s top Drupal blog posts and see which insights we found the most interesting.READ MORE
Specbee: How to create and apply a patch with Git Diff and Git Apply commands for your Drupal website
Git has been a reliable version control tool for a large number of closed and opensource projects. With Drupal being an extremely collaborative opensource content management framework, a trackable, transparent and distributed version control system like Git is a perfect fit. Git replaced a long-time version control partner – CVS – in early 2011 and became every Drupal contributor’s favorite tool for its security, distributed nature, agile workflow and of course, being opensource!
If you’re a Drupal developer, you should be familiar with patches already. Patches are like band-aids. They are small pieces of code that are added on top of already existing code files to support it or to fix any issues. Different types of patches include bug fixes, security vulnerability fixes, performance enhancements, styling fixes, etc. If you are a regular contributor to the Drupal project, you should know that to fix an issue in Drupal core or contributed modules, you need to submit a patch to an issue in the issues queue. These patches are then examined and tested by the module maintainer and applied if found beneficial.
What does the Git Diff command do?
There are different ways to apply Git patch. Let’s learn more about various Git Diff commands and how to create / apply a patch with the help of git diff and git apply. We will assume that you have already cloned/obtained a copy of the project in your local repository and have pulled the latest changes so you’re not working on an older version of the project. Take a look at some Github best practices here.
Git diff is a command used to output the changes between two sources inside the git repository. The data sources can be two different branches, commits, files, etc.
The common use cases of git diff commands are listed below.
This command will output all the modified changes which are not added to git or staged.
• $ git diff filename
This will output the changes of that current file to its previous committed state.
• $ git diff branch_name
This will output the modifications of the current branch to the mentioned branch to its previous committed state.
• $ git diff --staged path/to/file
Once the changes are added to Git or moved to staging, you will not be able to see the diff of the files. To see the staged changes, you can use diff with --staged or --cached option.
• $ git diff commit_id1 commit_id2
To see the difference between any two commits you can use this git diff command where you need to mention the two commit ids.
Creating a Git patch with git diff
If you want to see the list of commits made in the Git repo, use the command $ git log. This will list out all the commits (starting from the latest commit) along with their respective commit ids, the author (developer) and the date it was committed on.
To create a Git patch, we can use any of the git diff commands to get the changes. We then need to save the changes to a file which can be used as below.
Apply the Git Patch
Drupal developers will want to apply Git patches frequently to update changes or to fix bugs. Developers will create a patch file which can be used by other developers according to their need. To apply a git patch to the current branch use the following command.
In the above example I have created a patch file called my_custom_patch_file.patch and I am applying that patch to my current branch. After applying a patch, you can see the modification in the status.
There might be a situation when the developer does not have write access to the project but still wants to suggest a change or fix a bug. The best way to go around that is to create a patch file. And because patches are additions to the code, testing and reviewing them is easy. This brief guide aims at helping Drupal developers get more familiar with git diff and git apply commands to be able to efficiently create and apply git patches as needed. Contact us to know more about how we can help you with your next Drupal website.Drupal Planet Drupal Tutorial Drupal Development Drupal Shefali ShettyApr 05, 2017 Subscribe For Our Newsletter And Stay Updated Subscribe
Leave us a CommentShefali ShettyApr 05, 2017 Recent Posts Image How to create and apply a patch with Git Diff and Git Apply commands for your Drupal website Image Improving Drupal 9 Performance with modules, best coding practices and the right server configuration Image Top Drupal 8 (and 9) Modules for Intuitive Website Navigation Want to extract the maximum out of Drupal? TALK TO US Featured Success Stories
Know more about our technology driven approach to recreate the content management workflow for 7.ailink
Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.link
Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.link
Recently, I ran into a strange issue with a Drupal site. Phrases that were based on a count, using the formatPlural() method to determine the correct phrase to report a count, were all translated with the phrase meant for a count of 1. All of them said e.g. 1 vraag or 1 reactie (Dutch for 1 question and 1 comment), even when there we more than one, or in some cases no questions, comments, or whatever the relevant phrase was.
Gábor Hojtsy: Evolving the Upgrade Status user interface - a work in progress you can help influence
Last time I posted an update on Upgrade Status was four months ago. It is fair to say the Drupal contributed project landscape has changed quite a bit in the meantime and Upgrade Status should evolve too. Why? The primary role of Upgrade Status is to help get your site components updated for Drupal 9 compatibility. Most of your site components are contributed modules. In many cases, either your local copies or the remote available updates will already be compatible. 38% of Drupal 8 compatible modules are now Drupal 9 compatible (3535 out of 9258) and most others have a patch waiting to land to either improve or complete compatibility.The changing role of Upgrade Status
Therefore the role of Upgrade Status for contributed projects is more to make you realize that you are one of (a) already compatible (b) will be compatible with an update or (c) should work with the maintainer on existing issues. As opposed to scanning for problems locally and trying to fix it for yourself. But the current 2.x version of Upgrade Status does not do the job of indicating most of these. Without running the (lengthy) scans on your projects, it does not know which local projects are already compatible. And although it has access to information about whether remote updates are Drupal 9 compatible or not, it will not display them. Look at this screenshot:
We only know the Consumers project update is going to solve your Drupal 9 compatibility issues because the maintainer kindly explained that in their Drupal 9 plan. This requires manual work and is not going to happen universally (eg. as shown below neither Chaos Tools nor Markdown specify a Drupal 9 plan). For projects like Consumers, there is not even a good reason to run our lengthy compatibility checking locally because we know the remote update is available and is going to be compatible. Plus we already know from the local info file that the local version is not yet compatible and requires that update. So if we would provide all this "new" data, the user could understand the situation and decide to not even run a compatibility scan but update the project. So the first step (hopefully) improving the Upgrade Status experience was to add more raw data about local and remote Drupal 9 compatibility. Then it looks like this:
The new "Local 9-ready" column shows if the project is already ready locally (without scanning the project, based on info files in the project). The new "Drupal.org 9-ready" column shows if the remote update is Drupal 9 compatible or not (based on information already provided to core's update module). So what we can see from this example is that Chaos Tools will be entirely resolved with an update, no need to run a problem scan locally. Markdown will not be entirely resolved but is worth updating either way because likely there will be less issues. Not all projects will specify a Drupal 9 plan to go by as discussed above. But if there was no plan specified, we could still link to the issue queue. I don't think applying issue tags consistently is possible to expect from all contributors, so we cannot link to an issue tag search. The link goes to a drupal.org issue search for "Drupal 9" issues in the project. This is the fastest way to get to a place to collaborate with the maintainers of Markdown, given no Drupal 9 plan posted.Deciding on the next step for each project
So more raw data is great, right? Well, it probably makes the display a lot more confusing. Based on what you read out about the data you would do different things to different projects. For the 2.x version Joe at Drupalize.me published a great post about how to read the data. But what if the module would make suggestions for next steps instead of you needing to carefully examine each part of the data. We could still give users the source data, but save a lot of time to compare data points as to whether a project should be updated or needs more work, etc. Enter the next step suggestion engine I built following extensive discussions with Ofer Shaal. The possible next steps for projects are:
- Remove: if you have uninstalled projects on your site, there is likely no point in investing effort keeping them up to date.
- Update: if your project has a remote update, that is the best course of action; even if Drupal 9 compatibility is not entirely done there, it is likely improved.
- Collaborate with maintainer: contributed projects that are up to date could still have issues; instead of fixing locally, there is high probability that there are issues (including but not limited to from Project Update Bot) in the queue, so better start collaborating instead of fixing locally.
- Scan: unless your custom project's info files specify Drupal 9 compatibility already, the suggested next step is to scan them
- Fix with rector: for custom projects there is a 40+% likeliness that there is at least one problem we find that is rector-fixable, we suggest you use rector as your next step to avoid needless manual work (again) in this case
- Fix manually: if you scanned and there were no rectorable fixes, as a last resort we suggest you fix issues manually
Instead of grouping by custom/contributed and under that installed/uninstalled, the 3.x branch now groups results based on the next suggested step. The raw data is still shown and users can still do whatever they decide if they do not agree with the suggested next step.
This is the state of the module's user interface right after installation. We can already deduct a lot of information from local Drupal 9 readiness, update information and status of projects. For the single custom project in this test setup, we can only move forward with scanning it for problems. The numeric counters of problems found overall were removed, because in the current state of contributed projects rapidly getting ready, counting their individual issues together does not really inform about anything useful.Overview of status of your site
Usage of Upgrade Status has always been a three-step process. First you need to help the module gather data (run available update checks, run scanning of projects). Second, you would attempt to fix the problems found (update modules, run rector, etc.). Then you scan again and verify compatibility improved. So instead of putting this into documentation, I designed a summary view for the top of the page, that helps you go through the data gathering, the compatibility fixing and the celebratory steps. Here is how that looks like for my test site:
- The data gathering steps ensure the module works with the best data possible. Having a way to accurately identify project versions is important, so projects are suggested for that (unless already installed). Having up to date available updates information is important, so it is possible to run that directly from here. There are projects where scanning on this UI is the next step to gather the required data (to move to "Fix with rector" or "Fix manually"). On this site I have one of those test modules. And finally, the UI indicates you can scan either project as you see fit.
- Based on the data available, the second columns shows all the next step suggestions for fixing compatibility issues. Projects to remove because they are uninstalled anyway, projects to update, collaborate on, fix with rector, and so on. If your environment is incompatible that also shows up here with a link to details.
- Finally there is a column to review what's ready to go. If your environment looks all good, that would show up here, as well as all the projects that are already compatible. A little circle chart shows how far along you are.
Check out the current user interface on the left and the new work in progress on the right. A summary of differences:
- The current UI is almost a blank slate and is not aware of project status locally or update's compatibility remotely.
- On the current UI to gather data you need to run the full scanner on everything. Then you need to decide on next steps based on your reading of the data.
- On the current UI the available updates refresh and the suggestion to improve version identification with the deploy modules is sort of hidden under "help text blindess", rather than being an active part of the UI.
- The new UI is actionable immediately with categories of projects by next step.
- The count summaries of problems found is gone, the focus is more on the projects rather than the individual problems. (Even though that data is entirely accessible).
I believe that more than two months after Drupal 9's release, the role of Upgrade Status is increasingly not to tell you to do fixes locally but to allow you to obtain the fixes already made and collaborate on fixes being developed for contributed projects. And for custom projects, it should suggest you the most automated way forward (rector preferred) that will result in least work to execute. These were the guiding principles of the new user interface. I built it all in the 3.x branch of Upgrade Status, and you can try it out in 8.x-3.0-alpha1. There are definitely spots for improvement and there are probably things I still did not consider. Feedback would be great either as comments here or support requests on the issue queue. Thanks for your input, it is going to help make this better!