Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Nov 11 2020
Nov 11

Part 1| Part 2 | Part 3
Drupal 7 was supposed to go end-of-life in June of this year, when Drupal 9 was released, but owing to the coronavirus pandemic, Drupal maintainers have extended the Drupal 7 end-of-life to November 2021 due to the significant proportion of Drupal site owners who are still on that version. Tag1 Quo, Tag1's extended support service for Drupal, offers you peace of mind when it comes to receiving all of the important security updates that Drupal 7 Extended Support (D7ES) vendors maintain. But Tag1 Quo goes well beyond the minimum requirements of the D7ES program, because we cover all of your contributed modules and notify you right away of security patches that need your attention.

[embedded content]


In this special three-part series, join Tag1's Jeremy Andrews (Founder and CEO), Michael Meyers (Managing Director), and your Tag1 Team Talks host Preston So (Editor in Chief) for a wide-ranging conversation about extended support in Drupal, what Drupal 7 site owners need to know today about extended support, and how Tag1 Quo is the optimal solution among D7ES vendors for your mission-critical Drupal 7 implementations. When it comes to Drupal 7 past end-of-life, Tag1 has your back.

Part 1| Part 2 | Part 3

For a transcript of this talk, see Transcript: Drupal 7 extended support- Pt. 2: An overview of the Tag1 Quo Drupal 7 extended support service & how it works. - Tag1 TeamTalk #028.2.

Photo by Tim Mossholder on Unsplash

Nov 09 2020
Nov 09

Part 1 | Part 2

Drupal is notorious for its "everyone has a voice" approach to open-source development, but it isn't easy to reach consensus across thousands of people with different backgrounds and opinions. In addition, Drupal has witnessed countless paradigm shifts in its lengthy history, both in the surrounding world of web development and in its internal workings. As Drupal has grown to power over two percent of the websites on the entire internet, many new workflows and governance structures have had to be put in place to guarantee the continued longevity of the Drupal community. In addition, with end-of-life quickly approaching for Drupal 7, contributors now have to juggle a widening range of versions.

[embedded content]

In this very special two-part series, join Angie Byron (Senior Director, Product and Community Development at Acquia), Michael Meyers (Managing Director at Tag1 Consulting), and your Core Confidential host Preston So (Editor in Chief at Tag1 Consulting), for a fireside chat with the one and only Angie Byron. We dove into some of the amazing (and not so amazing) things Angie has seen over the course of her fifteen years deeply involved in Drupal core development as well as what people need to know about Drupal core today and in the near future.

Part 1 | Part 2

For a transcript of this video, see Transcript: Core Confidential with Angie Byron (webchick) : The many faces of Drupal over 15 years - Pt. 2.

Photo by Jr Korpa on Unsplash

Nov 02 2020
Nov 02

Part 1 | Part 2

Open-source software development isn't easy. There are few people who know this more intimately well than Angie Byron (webchick), who is one of the best-known community leaders in the Drupal ecosystem and Senior Director, Product and Community Development at Acquia. Over the course of Angie's fifteen years in Drupal contribution, the content management system has undergone a series of disruptive and significant changes that have reinvented the community multiple times over. As cat-herder of over 30,000 developers all around the world, Angie has had her fair share of experiences in Drupal core development.

Drupal is notorious for its "everyone has a voice" approach to open-source development, but it isn't easy to reach consensus across thousands of people with different backgrounds and opinions. In addition, Drupal has witnessed countless paradigm shifts in its lengthy history, both in the surrounding world of web development and in its internal workings. As Drupal has grown to power over two percent of the websites on the entire internet, many new workflows and governance structures have had to be put in place to guarantee the continued longevity of the Drupal community. In addition, with end-of-life quickly approaching for Drupal 7, contributors now have to juggle a widening range of versions.

[embedded content]


In this very special two-part series, join Angie Byron (Senior Director, Product and Community Development at Acquia), Michael Meyers (Managing Director at Tag1 Consulting), and your Core Confidential host Preston So (Editor in Chief at Tag1 Consulting), for a fireside chat with the one and only Angie Byron. We dove into some of the amazing (and not so amazing) things Angie has seen over the course of her fifteen years deeply involved in Drupal core development as well as what people need to know about Drupal core today and in the near future.

Links

How automatic updates finally made it to Drupal

Revisiting DrupalCon Global: Drupal 7 and Drupal 8 End of Life

For a transcript of this video, see Transcript: Core Confidential #3.1 Core Confidential with Angie Byron (webchick) : Learning about 15 Years of Drupal Contribution - Pt. 1.

Part 1 | Part 2

Photo by Jr Korpa on Unsplash

Aug 12 2020
Aug 12

Throughout Drupal's history, contributors have rallied around Drupal.org as the single source of truth for both the code running Drupal and the infrastructure powering Drupal's issue queues, source control, and automated testing. As the Drupal Association continues on its journey to integrate GitLab features with Drupal.org, we're beginning to see the first glimpses of how Drupal contribution and issue management will evolve thanks to cutting-edge functionality like merge requests and issue forks in GitLab. But what happens with all of the surrounding tooling for Drupal.org, including DrupalCI and the longstanding issue queues themselves?

Soon, for the first time, Drupal contributors will be able to create merge requests and issue forks that make reviewing, suggesting changes to, and testing code much easier across the board. All activity will be reported back to the issue on Drupal.org, but contributors will be able to provide direct code comments and code review on the merge request as well. With Drupal.org's massive store of metadata, landing on the optimal solution required significant discovery and evaluation of how Drupal contribution would change in light of the move to GitLab. And with an initial beta launched just before DrupalCon Global this year, there are already more than a hundred projects in the Drupal ecosystem participating in the program.

In another special edition of our Tag1 Team Talks series, learn about what features will be part of Drupal.org's support for merge requests and issue forks, what the future of DrupalCI looks like in light of modern approaches to automated testing, and how you can not only take advantage of the ongoing beta but also how you can get involved as a contributor to one of the most important initiatives in Drupal's history. Join Tim Lehnen (Chief Technology Officer, Drupal Association), Neil Drumm (Senior Technologist, Drupal Association), Michael Meyers (Managing Director, Tag1 Consulting), and your host Preston So (Editor in Chief, Tag1 Consulting) for a fireside chat about the future of contribution and collaboration on Drupal.org.

[embedded content]

---

Links

For a transcript of this video, see Transcript: The inside story on Drupal.org's coming support for merge requests and issue forks - Tag1 TeamTalk #022.

Photo by Clay Banks on Unsplash

Aug 10 2020
Aug 10

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7

Slow or intermittent connections are an all-too-common case that many users face when attempting to work with applications. Offline-enabled applications are a particularly challenging use case because they require synchronization and a local understanding of data. Thankfully, with the help of Yjs, an open-source real-time collaboration framework, and IndexedDB, a browser-based local database optimized for offline content, anyone can build an offline-enabled application that also includes features for rich collaboration. When combined with the functionality provided by y-indexeddb, the adapter for IndexedDB in Yjs, developers can make use of a wide variety of features that aid progress towards an authentically offline-first application.

A short while ago, I (Preston So, Editor in Chief at Tag1 and author of Decoupled Drupal in Practice) had the unique opportunity to moderate an enthralling dialogue on the Tag1 Team Talks show about how Yjs empowers offline-first applications with the support of my Tag1 co-workers Kevin Jahns (creator of Yjs and Real-Time Collaboration Systems Lead at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), and Michael Meyers (Managing Director at Tag1). In this blog series, we take a look at how to build offline applications with Yjs. In this installment, we cover how offline editing could function in Drupal and the important question of how Web Workers figure into the equation.

How offline editing could work in Drupal

Before we kick off our discussion of offline editing and its prospective incorporation into Drupal, I encourage you to check out the first and second installments of this blog series about offline editing with Yjs in order to gain a complete understanding of what is involved when building offline applications, particularly the spectrum of possibilities enabled by technologies like Service Workers and IndexedDB. The previous installment of this series also includes discussion of y-indexeddb, the Yjs adapter for IndexedDB and a key bridge for offline functionality.

Illustrating offline editing examples

During our Tag1 Team Talks episode, Fabian encouraged the audience to consider a real-world use case when it comes to content management that many practitioners of content management systems (CMS) are doubtlessly familiar with. Consider a situation in which you have dozens of tabs open, and you are editing content in your CMS of choice. Now consider the scenario in which you leave your computer and return later to continue working, forgetting in the process that you have a Drupal article open in your CMS on your browser.

Then, in the Drupal CMS, you return to your administrative interface, logging in and editing your content, which is all present thanks to offline persistence of your data locally. Everything you have modified in the content is already present automatically; you don’t have to do anything else. Now, you can access your content on another tab in your browser of a different draft that you had edited previously. This illustrates the importance of counting on conflict resolution when it comes to managing offline editing on varied systems.

Now consider another scenario in which we are editing a Drupal.org issue. Upon a typical computer crash and power outage, we lose access to the internet and thus connectivity to the most up-to-date status of an issue on Drupal.org. If the Drupal.org issue were to be connected locally to our IndexedDB database via y-indexeddb, all of the content we had created for a particular issue would still be available, and therefore we wouldn’t lose any content in the process of reconnecting.

This is a significant problem that often seems insurmountable, especially given the fact that Drupal’s Autosave module, which permits automatic saves on keystrokes in Drupal’s editorial interface, can prove problematic in this environment. After all, what happens when a save to the server is impossible due to the lack of a stable connection? Though other APIs exist, such as HTML5 Local Storage, this approach only works to some extent and does not alleviate the fact that multiple tabs containing different modifications to the same content may be open at the same time on a user’s browser.

Service Workers and IndexedDB

Kevin offered another compelling use case during our comprehensive conversation on our recent Tag1 Team Talks episode about enabling Yjs offline editing. While a web browser crashing or losing internet connectivity is nothing new, flight passengers have unique situations that require substantial delays in synchronizing once again with the server. (For instance, your correspondent is, at this very moment, writing this blog post offline on a plane without any access to the internet, even though other modifications could be occurring in the content I’m currently editing.)

Fortunately, because Service Workers have access to your local IndexedDB database, the browser will be able to successfully sync your content to your server such that other applications can see what you edited, as soon as you reconnect. This means that you can create offline-enabled applications that are progressively enhanced and also support use cases in Drupal that require collaboratively edited documents to be made possible through the emerging web technologies we have described over the course of this series.

Supporting collaborative editing in Drupal

Consider, for example, the case of a document in Drupal that is collaboratively edited over the course of time by many users. You, however, are a user who has just gone offline. Nonetheless, you immediately see content display in Drupal, because there is no need to wait for the server, because all local content is served from the IndexedDB database that is currently housing your data offline. And instead of exchanging the entire document, y-indexeddb will ensure that only the parts that are modified are exchanged.

In the process, the server will send to you an update of the content that was created in the meantime by other users while you were disconnected, and you will, in a corresponding fashion, submit to the server an update representing the content you modified and updated over the course of your offline editing. Thus, we can see that y-indexeddb is a compelling enhancement to any web application that requires collaboration if you wish to build an offline-first application that also comes with effective performance optimizations out of the box. As Fabian joked on our recent Tag1 Team Talks episode, such offline-first functionality is nothing short of material from a James Bond movie, because if there’s no internet, you can still ensure that data is sent to the server in any secret agent scenario.

What about Web Workers?

Service Workers and IndexedDB are the stars when it comes to enabling offline-enabled applications with collaborative editing, but how do Web Workers figure in the picture? Web Workers, after all, are an additional browser API available in addition to Service Workers that allow applications to perform computationally complex calculations. For instance, if you need to perform major reconciliation on a Yjs document that is being collaboratively edited, you can initialize a Web Worker that retrieves a Yjs document from the local IndexedDB database and performs said calculations before executing an extremely expensive synchronization job to match up with the data held by the server.

In addition, if you wish to render an HTML page based on the data that is present in the Yjs document and subsequently send it to the main thread, Web Workers make these heavy computations possible with as much efficiency as possible. And in the process, this also allows you to exchnage data through IndexedDB across browser contexts. In short, IndexedDB is a local database that multiple processes can access concurrently and leverage to accomplish different necessary tasks.

Extending Service Workers with WebSockets

The aforementioned Service Worker in question, as Kevin admits, may also wish to establish a WebSocket connection to the server in order to synchronize the data or even leverage a different technology besides WebSockets to sync the data as needed. The main thread, that is, your website, doesn’t necessarily need to sync data through WebSockets in a real-time fashion. During our Tag1 Team Talks episode, Fabian illustrated a case in which many changes on your local environment need to be synchronized without conflicts to the server, something achievable thanks to Yjs.

Conflict resolution through Yjs still engenders some latency, and after all, as end users, we are loath to wait even more than a few seconds for content to be updated. Many of us react with annoyance when presented with a spinning loader reflecting the extensive content synchronization required. If you place all of this capacity in a Web Worker instead, you can proceed to modify your document and view live changes that have been synchronized with the server, and all of this occurs in the background. A Web Worker gives you a means for all the interactions to occur without blocking the interaction that users conduct, a very important consideration for performance enthusiasts.

Conclusion

Modern web development has wrought many changes in the front-end landscape, but perhaps no emergence of new web technologies has been as influential for enterprise organizations as the advent of offline-enabled applications that allow collaborators to synchronize changes to the server as needed but retain all functionality when connectivity is unavailable. Fortunately, with the increasing popularity of Yjs, an open-source real-time collaboration framework, and IndexedDB, a local database solution for housing data needed offline, developers have never had it easier when it comes to implementing offline applications that also support collaborative editing.

In this blog post, we traced some of the ways in which offline applications can be at the forefront rather than an afterthought in Drupal’s own ecosystem. We also analyzed how Web Workers can enhance an offline application to provide even more functionality. In the next installment in this multi-part blog series about offline editing with Yjs, we discuss how y-webrtc, the subject of a previous Tag1 Team Talks episode, intersects with the features that Yjs provides for offline collaboration.

Special thanks to Fabian Franz, Kevin Jahns, and Michael Meyers for their feedback during the writing process.

Links

About Yjs Demos Peer-to-peer shared types

Yjs paper

IndexedDB API

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7

Photo by NESA by Makers on Unsplash

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