Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 28 2020
Jul 28

In a previous blog post and video, we looked at the code that controls the display of link previews on Facebook. This is outlined by Facebook's Open Graph protocol, where we modify the <meta> tags within the <head> of our HTML web page to say what the title, description, image, and other info should appear in our preview.  

In that post, I showed how to manually modify those HTML tags. While it's good to learn what's going on behind the scenes, in reality, it would be kinda crazy to ask your content editors to modify this code for each piece of content they add. In fact, if you're using a CMS, it would be impossible for them to do so.  

So instead, let's allow the CMS to make our jobs easier. In this video, let's look at the Drupal Metatag module and the included Metatag: Open Graph module to save us time and make our job easier. At the end of this, we will have added <meta> tags in the <head> of our article to reflect how we want our preview on Facebook to appear.  

[embedded content]

Install the Modules

First, let's download the Metatag module. Inside of this module are many sub-modules, each of which is designed to handle the expected meta tags for other social networks, search engines and products.  

For this tutorial, you'll only need to enable the Metatag and Metatag: Open Graph modules. Although we are going to be dealing with Facebook link previews, we will not require the Metatag: Facebook module for this tutorial.

Create Metatag Field on Content Type

In order to give your editors the ability to change the meta information that gets printed to the <head>, we need to add a field to our content type.   

  • Go to Structure > Content Types > Manage Fields on the content type you want to affect
  • Click Add Field > General > Meta tags
  • Give your field a name ('Metatags' will do)
  • Save Settings  

Now when we go to add or edit a piece of content of this type, we have a collapsible 'Metatags' group on the right hand side of the page. It has a few different sections:  

  • Basic Tags
  • Advanced
  • Open Graph  

We can write inside of these fields and when we do, this will add the <meta> tags to our page. This gives your editors control over what gets printed in those tags and (eventually) what can be shown in the Facebook link preview.  

But we can also set some defaults. For instance, there's a lot options in the 'Advanced' section. Some of these fields we may never use, so let's turn them off and configure some others.

Configuring our Metatag Field

A new option appears on the Configuration page when we go to the Search and Metatag section. Click that and go to the Settings tab at the top of the page.

Hiding the Advanced Section

On that page, we get a list of different entities, including the content type that we just added the field to. Opening that section, it shows the Basic, Advanced, and Open Graph areas we saw before. Because none of them are checked, they all appear, but if we check the boxes next to Basic and Open Graph, now only those two sections will appear on our content type.

Hard-Coding Defaults

There are some Metatag fields that we probably don't expect our editors to fill out or have to change. So, we can set the default. For example, if we have an Article content type, we probably want to set the Facebook Open Graph og:type value to article. To change this:  

  • Go to Configuration > Search and Metatag
  • Scroll to the Content section and click Edit
  • Open the Open Graph section and in the Content type field, type article
  • Click Save  

Now, the og:type meta tag will be filled in automatically with the value article. This works for a value that remains constant, but what about fields that change on every piece of content, like the Title field? 

Setting Dynamic Defaults with the Token Module

First, install and enable the Token module.  

To set the Facebook Open Graph tags to match what we add in our content, we have to use the Token browser at the top of the page to select the field value we need. In this example, we'll set the og:title to match the node title:  

  • Open the Open Graph section and click on the Title field, making sure your text cursor is on the field
  • Scroll to the top of the page and click Browse available tokens. A draggable modal window will appear
  • Open the Nodes section
  • Click on [node:title]

This will insert [node:title]in the Title field, automatically putting in that piece of content's Title. You can repeat this for other fields.

A Note on Images

One of the Open Graph tags you probably want to automatically fill in is the og:image field. When configuring the default for this with the Token module, it might be tempting just to click on the image field on your content type, such as [node:field_image].

This won't work. We need the URL of the image, and this token does not provide that.  

Instead, you have to open the triangle beside the field, which reveals the different available Image Styles. Open the appropriate style, and get the URL of it, which appears like so: [node:field_image:large:url].

Wrapping Up

Setting up sensible defaults for your content editors is a great idea, and the Metatag module lets you get very specific with the data. And of course, these fields are editable on the content in case your editors do need to override them.

Jul 23 2020
Jul 23

Last week wrapped up DrupalCon Global 2020, the first virtual edition of the biggest Drupal learning and networking event in the world.

Like pretty much everything in 2020, things are different this year and will be looked on in the future with an asterisk. When sports teams win their championships this year, there will be a little footnote at the bottom of future statistics books noting that they won in 2020, the year of the pandemic. The team won, but under strange circumstances, so maybe consider it a different win than other years.

I think we'll be talking about this DrupalCon in the same way for years to come. With an asterisk. Not because it was a failure (it certainly wasn't it was a huge success), but because it will influence future DrupalCons.

If you've read any Twitter threads or other blog posts about this year's conference, you'll probably hear, "It was a great virtual conference, but it just wasn't the same as real life."

Totally agree. But I'm going to break down the different aspects of the 'Con:


This year's conference used Hopin to manage the video and chat for the stage, sessions, and exhibition hall. I had never used Hopin before, but the signup process via the Drupal Association's emails were seamless.

On the morning of July 14, before the conference got started, there was already some buzz. On the right-hand side of the screen was a chat window that everybody at the conference could see. On another tab was a list of polls people could answer, and you could see a list of all the people that were attending the conference.

Like a real-life conference, you could "walk" (i.e., click) to a different hall and see what's going on. There was a main stage, session rooms, the exhibition hall, and a Networking tab which mimics the halls of a real conference where you meet folks. The Networking tab allowed you to be matched up with a random person and chat.

Now, this isn't how networking in real life works: in reality, you get introduced by somebody else or some eye contact is made and a conversation isn't initiated. So at first glance, the Networking tab doesn't mimic how conference networking happens. But there's an advantage to this I didn't see before writing this: I might get matched up with somebody I wouldn't think to approach at an in-person conference.

And maybe that's a lesson to learn: our networking software doesn't need to mirror the real-world exactly for it to be better.

Video and Sound Quality

At 9:30 AM ET, the conference officially began and our opening speakers, Tim Lehnen and Heather Rocker took the stage... from their homes. The video and sound quality was fantastic with just the two of them on stage. I'm sure mountains of rehearsals took place, but there was never seemingly any large lag or awkward "Could you repeat that?" or "Can you see my screen?"

screenshot displaying the DrupalCon virtual streaming interface

Less than two minutes after starting, more than 800 people were watching. And it held up. So too during the sessions.

I did have issues with the video when there were lots of people sharing their video at the same time, such as in BOFs ('Birds of a Feather', essentially small groups that gather together to discuss a shared topic of interest), This was not a limitation of Hopin, but I think of my 2015 MacBook Pro laptop. Fans ran wild.

Having a bunch of people hanging out in a room adds a nice personal feeling. But maybe a recommendation for the future: when you get more than 6 people in a session, tell all but two people to turn off their video.


In brief: the chat worked well. There was an ever present chat for the entire conference which you could join, but then also a chat just for the session itself. Thumbs up.

Live Closed Captioning

A welcome addition to those with hearing difficulties, each session had live captioning provided by StreamText. Although I personally didn't have a need for it, it's fantastic that this was available and is now expected as default at conferences. The captions not only showed what was said, but also who was talking.

A series of tweets about the live closed captioning feature at DrupalCon 2020

Browser Issues

My primary browser is Safari. When visiting the Exhibition Hall, I ran into a bug where it would auto-scroll through all of the sponsors and the page became unresponsive. Not the Drupal Association's fault (they don't operate Hopin), but it's still surprising to me that web services built these days aren't built for all browsers.

I didn't try on my phone or tablet, but from what my colleagues told me, the experience on an iPhone was less than ideal.


After comparing notes with my colleague Suzanne, who was a presenter at DrupalCon and was also presenting at another online conference the same week using another tool called MaestroConference, Hopin clearly has a lot of the virtual conference experience features figured out. There's room for improvement, but this is way better than being on a series of Zoom calls all day long.

Session Experience

The meat of a DrupalCon are the sessions where you get to learn new things. How did it fare this year?

As an attendee, I actually preferred this format! The presenter showed their video and their slides, either of which I could enlarge if I clicked on them, but the user chat was the best part: in real-time the audience could provide commentary and share tips. So if the presenter mentioned a module or a project, somebody in the chat would usually link to it. If somebody asked a question in the chat that was directed generally, somebody would usually answer.

A poll where 77% of respondents said that in-session interaction has been enhanced by the virtual DrupalCon experience

As a presenter, I could see a river of comments being distracting. Also: there was no obvious feature to share a comment as a question saved for the end, which would be a big help for the presenter. Also, threaded comments would have been useful to help organize the conversation.

BOF Experience

Even as somebody who has gone to many DrupalCons, I still felt nervous about speaking up in BOFs (Birds of a Feather), especially if one of the people leading the session was somebody with notoriety in the community.

With this year's format, I felt way more comfortable joining in. You could join a BOF and just type in the chat section, or you could share your mic and video and be a "presenter" in the BOF. I did this several times and didn't feel the nervousness that I usually felt in normal conferences.

Maybe it had to do with wanting to support the person leading the BOF and if I chimed in with my video it made their job easier? Whatever it was, the intimidation did not feel so high this time around.

One of the first BOFs I attended was discussing the role of the Classy base theme in future versions of Drupal. Does it make sense to keep Classy as a Core theme when Drupal has now adopted a continuous upgrade path? In this BOF was a contributor who has been in the community for a long time, John Albin, and I've appreciated his work over the years. In a real-life conference, I may have been too shy to join in and speak up, but with Hopin, I felt comfortable to turn my mic and video on and join the conversation.

Another BOF was discussing how to do Drupal on a low budget. A lot of the web projects that get noticed are high-profile, big budget sites. But in my web developer experience, most of the projects I have done were smaller side-gig projects that can't afford $400/month hosting. More like, $100 / year hosting.

In this BOF, a small group of us talked about the limits of shared hosting and some ways we can get around them. This felt like a conversation that needs to happen more in our community: if we don't address the issues that lower-budget clients have, then we should not be shocked that Wordpress and Squarespace grab those clients.

DrupalCon as an Experience

My first DrupalCon was in Denver in 2012. I was a freelancer at the time and went to the conference alone, not knowing anybody that was going to be there, save maybe a few usernames that I recognized.

This was the biggest conference I had been to up to that date, and the Denver Convention Center still has to be the largest conference center I've visited. It's just massive, making my first few steps into DrupalCon intimidating.

But luckily, back in Denver, there was a friendly circle of people that I joined in conversation and they quickly invited me out to go for dinner and drinks. I'll never forget that (thanks Matthew Saunders!) I had a blast that evening, meeting a bunch of other new faces that the group introduced me to. And then throughout the rest of the conference there was a launching pad of people that I could wave to in-between sessions and during breaks. You felt like you belonged there.

It should be noted, mentorship programs have been put in place for people who are new to DrupalCon, who may have been just like me back 8 years ago in Denver. They also adapted for this conference so people felt welcomed virtually.

2020 as a DrupalCon Veteran

If you go to enough DrupalCons, you'll learn the lingo, inside jokes, and the traditions that carry on each year. Some of those jokes lived on in the chat in this year's conference:

  • "The Wi-Fi is holding up this year!"
  • "Please sit in the middle of the row and don't block the doors!"
  • "Please record how much coffee you drank so we can get an estimate on how much we drank in total"

These quotes will make sense to you if you've been to DrupalCons before. They're fun little things about the conference, and it's good to see them being reinvented in this new circumstance.

But for somebody that this is their first DrupalCon? This will be lost on them. Nobody's fault of course, but it'll be different for them.

2020 as a DrupalCon Novice

According to the poll put in the Hopin chat, this was a lot of people's first time coming to a DrupalCon 35% at the time I took this screenshot.

A poll showing that 35% of attendees in 2020 were DrupalCon novices

This is truly fantastic news that new people are interested and engaged! But my fear is that they won't get that same feeling of group acceptance that I felt at my first DrupalCon in 2012. Not that they aren't accepted and welcomed by the community, but the limitations of any virtual conference are that it can't deliver that same attendee experience -- and I'm not sure if it ever can.

One of the biggest things I learned from DrupalCon 2012 in Denver was how to network and meet people, and that week was a crash course. In the span of a week, I must have talked to at least 300 people and took handfuls of business cards (including one from my current employer, Evolving Web, who I didn't even know at the time!)

As mentioned, there was the networking tab in Hopin, which is great, but I'm not sure if it's a replacement for meeting people in real-life. But maybe this is the new way we'll have to network.

Future DrupalCons

At the start of this post, I said this would be the DrupalCon with the asterisk, the outlier conference that we'll talk about for years to come. Not only because it was the oddest one, but because it will affect all future DrupalCons.

At previous conferences, I had heard the idea floated around that we should do a fully virtual conference, but it never came to fruition. We only did it when our arm was twisted and we had to.

DrupalCon Barcelona is coming up in December, and at the time of this writing, it's still planned to go ahead in-person. Let's say that does happen: what if some people don't feel comfortable about going, but still want to virtually attend? Will we need to organize our conferences for the virtual crowd and the in-person crowd?

Next, the concern of travel-related climate change is real. If this DrupalCon was such a success and it led to less carbon emissions, wouldn't it be our duty to no longer do in-person conferences, despite the loss of 'oh-you-had-to-be-there' stories and experiences?

And, accessibility: this was the most accessible DrupalCon ever. In terms of travel, finances, and physical mobility, you could easily argue this was the most equitable conference we have organized yet. If we go back to 'normal', in-person-only conferences, less people will be able to join because of previous family commitments and finances. Is that a decision that we are willing to make?

A Success

With all the barriers put up on the organizers of this conference over the last months, I can say with certainty that this was a very successful DrupalCon that exceeded my expectations of what a virtual conference can look like.

I think we have some lessons learned and have some tough choices to make for the future, but the organizers should be proud.

Thank you for your work!

May 29 2020
May 29

In a recent Drupal training, I got a question about a replacement for the Drupal 7 Nodequeue module for Drupal 8 and other future versions. What this module allowed you to do was sort your content in whichever order you preferred.  

In Drupal, we make lists of content using Views and out of the box, and we have the ability to sort this content in different ways, such as:  

  • Date created
  • Date updated
  • Alphabetically  

But what if I want a list of content sorted in whichever order that I want? This is what Nodequeue allowed me to do: let me sort my content arbitrarily.  

Unfortunately, the Nodequeue module no longer exists for Drupal 8. But good news: there's a replacement called Entityqueue. This module does everything that Nodequeue lets us do in Drupal 7, and more.  

But content creation in Drupal has changed since Drupal 7. Many people are now using the Paragraphs module to lay out their content, so in this video tutorial, I'll be showing you two different methods of custom sorting:  

  • Entityqueue in Views
  • Paragraphs with Content Reference  

[embedded content]

Entityqueue in Views

After installing the module, we have a new option in Admin > Structure called Entityqueues. By default, there are no queues, so we create one:  

  • Name: Featured Content
  • Queue Type: Simple queue
  • Type of Items to Queue: Content
  • Content Type: Article (or whichever content you'll be sorting)  

After saving our queue, we have two different ways of adding content to the queue. We click 'Edit items' and type in the title of the content in the autocomplete field, click 'Add item', and click 'Save.'  

Another way to add items to the queue is to go to the content and click 'Edit'. Now, a new tab appears at the top of the page that says 'Entityqueue.' This will show a list of the queues this could be added to (it could be more than one). Click 'Add to queue' to add it.  

After adding it, we might want to rearrange the order of the items inside of that queue. Click the 'Edit subqueue items' and drag them around.  

For this tutorial, I've assumed you've already created a View of your content that you'd like to sort. Now, how do we get what we see in our View to match our queue?

Add Relationship to Your View  

The magic of Entityqueues comes from the relationship that we add in Views: whatever happens with our queue can be matched in our View. To add the relationship do the following:  

  • Open the 'Advanced' section of your View
  • Click 'Add' on 'Relationships'
  • Check the box next to 'Content queue' (found in the Entityqueue category)
  • Click 'Add and configure relationships'
  • Check the radio button for the queue that you made (if you've made more than one, they will all show up here)
  • Check 'Require this relationship'  

After doing this, the View will now only show content that has been added to the queue. Great!   

However, the order of our content might be incorrect. How do we get the sorting to match what's in our queue?

Add Sorting Criteria

If you've made no changes to the sorting criteria on your View, your content is likely being sorted by 'Content: Authored on (desc).' Basically, it's being sorted by the date the content was created. We need to remove this sorting criteria:  

  • Click on 'Content: Authored on (desc)'
  • Click 'Remove'  

Now, we need to add a new sort criteria that matches what is in our queue:  

  • In 'Sort Criteria' click 'Add'
  • Check the box next to 'Content Queue Position' (found in the Entityqueue category)
  • Click 'Add and configure sort criteria'
  • Click 'Apply' (you can leave the default settings)  

And now, our View content and order matches what is in our Entityqueue!

Paragraph Type with Content Reference

Although Drupal 7 did have support for the Paragraphs module, this method of laying out content has really gained popularity since Drupal 8 was released in 2016. To keep this tutorial brief, I won't go into all the details of creating new Paragraph types, but here are the basics.  

After downloading and installing the module, we have a new section in Admin > Structure called Paragraph types:  

  • Click 'Add paragraph type'
  • Label: 'Featured Content'
  • Description: 'Content that can be added and sorted arbitrarily'
  • Click 'Save'
  • Click 'Add field'

Add a new 'Content' (reference) field:  

  • Label: 'Featured Content'
  • Allowed Number of Values: unlimited
  • Restrict to Content: 'Article'
  • Click 'Save'  

On your Paragraphs-enabled content type, you now have the option to add a 'Featured Content' paragraph. This will display an auto-complete field (similar to Entityqueue) where you can type the Title of the content you want to feature. You can add multiple items, and rearrange them how you'd like.  

By default, what's shown is a simple link to the content, but this can be modified at the theme layer to display however you'd like, such as a slideshow of the featured content (but that's beyond the scope of this tutorial).

Comparing the Two Methods

From an Editor's perspective, it seems like there's less steps involved going with the Paragraphs approach, so why use that over Entityqueue? There's advantages to both methods and you have to choose which is right for your scenario.

If you have a Paragraphs-enabled content type, going down the Paragraphs route may be the simplest option. Editors just add the Paragraph to the page and begin typing and re-ordering the content. However, this features content in only one location on the site.  

With Entityqueue, though there's a few more steps from the Editor's perspective (and you may want to create a menu item so they can get to the queues quicker), if you need content to be sorted and featured in multiple places on your site, this is the route to go. In the video, I created a Views Page which has a relationship with my queue, but I quickly created a Block, which inherits all the settings I had from my page) and I can now place this in a region and have the two show the same content in the same order.

Wrapping Up

Nodequeue was a great Drupal 7 module, and luckily its spirit lives on (okay, that sentence might be a bit puffed up). But Entityqueue offers a great alternative and even includes some features that Nodequeue didn't, like being able to sort other entities like users and taxonomy terms.  

And content entry in Drupal 8 has evolved with the Paragraphs module, which also offers us a nice, easy-to-use method of sorting content in whichever order we'd like. To get more in-depth web development training, check out our training page or sign-up for a tutorial.

Mar 06 2018
Mar 06

After many years of development, Bootstrap had an official 4.0 release on January 18th, 2018. Bootstrap has been a popular front-end framework for several years and the release of the new version is really exciting!

Because of its popularity, there have always been lots of new front-end developers looking to learn Bootstrap and with the recent release of Bootstrap 4, I’ve been writing a Bootstrap & SASS course for Evolving Web. If you’re interested in learning Bootstrap 4 and SASS, you can find out about the course over here.

This post outlines a few of the differences between Bootstrap 3 and Bootstrap 4.


When Bootstrap 3 was first released in 2013, the only CSS pre-compiler option was to use LESS. A few years later, a SASS version was released.

From the get-go, Bootstrap is SASS only. This may sound like bad news, but the CSS community has rallied around SASS over LESS for the last few years. By creating a single SASS-based codebase, this means developers can focus on only one branch of the framework.

The Bootstrap documentation has information on many build tools that you can use to compile the SASS files.


In Bootstrap 3, the layout and grid system was based on the CSS float property. This worked well for most people. Bootstrap 4 is now based on Flexbox. If you're not familiar with Flexbox, check out this guide from CSS tricks.

Basing the layout and grid system on Flexbox allows for some handy options when creating your layouts.

One quick example: Have you ever had a grid of “cards” of varying content length that you wanted to all be the same height? Before, you would have to use some JavaScript to detect the height of the tallest one, then apply that height with inline CSS to get them to match. 

With Flexbox? You can do this with a purely CSS solution. Just one example where Flexbox makes layout much easier. 

Grid System

If you’ve used Bootstrap 3, you’re likely familiar with the list of breakpoint prefixes:

  • xs (extra small)
  • sm (small)
  • md (medium)
  • lg (large)

If you wanted to create different column layouts for each screen size, you would use these prefixes in your CSS classes, such as: ‘col-sm-6 col-md-9’.

The default breakpoints for these media queries were a little bit limiting too (though you could override them if you prefer). Here’s how they stacked up:

  • col-xs-* : (phones, less than 768px)
  • col-sm-* : (tablets, 768px and up)
  • col-md-* : (desktops, 992px and up)
  • col-lg-* : (large desktops, 1200px and up)

In Bootstrap 4, these media queries, breakpoints, and prefixes have changed. Here’s the list with their media queries:

  • col-* : (extra small, less than 576px)
  • col-sm-* : (small, 575px and up)
  • col-md-* : (medium, 768px and up)
  • col-lg-* : (large, 992px and up)
  • col-xl-* :  (extra large, 1140px and up)

In Bootstrap 4’s defaults, we’ve been given another breakpoint, “extra large”.

The other thing to note is that we no longer write a prefix for “extra small”. We simply write ‘col-*’ and it’s implied that it’s extra small.

One frustrating thing I found about Bootstrap 3 was layout options for smartphones, especially ones with larger screens. It always felt a little bit underbaked. But now with two breakpoints underneath the “tablet” breakpoint, this makes layout on those devices much easier.

One more thing to note with Bootstrap 4’s grid system is that, with Flexbox, if you don’t use a column prefix on your div elements, Flexbox is smart enough to figure out the width of each one. Or, if you have a 3-column layout, and only give a column prefix to one of those columns, the other two columns will have expand to fill the remaining space in the rest of the row.

Utility Classes

While using Bootstrap 3, I often found I had to write a separate file for little ‘helper’ CSS classes. Sometimes, I just want to add a little bit of margin or padding on a single element, so I had to create a specific CSS class so that I could apply it to my element.

Luckily, in Bootstrap 4, there’s a full set of default utilities that allow you to apply things like colors, positioning, border styles, alignment, and visibility of elements.

Want to add a border to an element, but only on the top? There’s a utility class for that. Want to add some some padding on just the right-hand side of an image? Yep, utility class for that. Want to float an element to the right, but only on medium-sized screens? You got it.

Browser Support

Bootstrap 3 supported all major mobile browsers and Internet Explorer 8+, though some CSS3 and HTML5 properties weren’t fully supported.

Bootstrap 4 also supports all major mobile browsers, however official support for Internet Explorer 8 and 9 has been removed. The framework only officially supports Internet Explorer 10 and up.


This may seem strange to say, but one thing I love about Bootstrap 4 reading the documentation.

When visiting a section in Bootstrap 3’s documentation, you were presented with a very long page detailing everything within that section. Mentally, I found this taxing.

In Bootstrap 4, each section has sub-sections with their own page. This may seem like a small thing, but I found I was much more focused on the thing that I was trying to accomplish while reading the documentation. The Bootstrap framework comes with a lot of bells and whistles and, in Bootstrap 3, I constantly found myself reading something, scrolling down a bit too far, and then getting distracted by another component.

Bootstrap 4’s documentation structure also makes more sense to me and seem much more human-centric. The sections now are:

  • Getting Started
  • Layout
  • Content
  • Components
  • Utilities
  • Extend

The ‘Content’ section is essentially for how basic typography, images, and tables are displayed in the browser, while 'Components' focus on functional elements like buttons, navigation, forms, etc. 

And if you ever get confused, the documentation also has an auto-complete search box that quickly gets you to the sub-section you're looking for.

Using Bootstrap 4 with Drupal

Now that Bootstrap 4 is out and ready to use, there are many Drupal front-end developers eager to start using it. For the moment, the Bootstrap theme doesn't have a release that uses Bootstrap 4, but you can use it yourself by downloading the SASS files and compiling them along with your own styles in your theme.

Creating a theme from scratch like this has downsides (you have to figure out where to put classes, and do the work of deciding which parts of Bootstrap to use) but it also gives you more flexibility in how you adopt the framework. If you have experience creating Drupal themes and want to take advantage of Bootstrap 4's features, this is a great approach. 


The changes between Bootstrap 3 and Bootstrap 4 are significant, but there are lots of improvements to take advantage of. It won't be hard for Bootstrap users to adapt to the new version of the framework, and it will be easier to pick up for those learning Bootstrap for the first time. But it will take time to upgrade from Bootstrap 3 to Bootstrap 4 on your existing projects.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web