As a part of my ongoing work on Tome, a Drupal static site generator, I’ve become interested in providing a solution for static searches. If you have a static site there’s typically no backend to do any server side processing, which means that search has to be done on the client or through a third party service. After researching some existing solutions I found Lunr, a JavaScript based search engine that provides a simple API for indexing and searching content.

Six months ago I started work on Tome, a static site generator for Drupal 8. After lots of rewrites and long nights, Tome has finally reached the beta phase of testing and development! 🎊 Up until now, I haven’t invested a lot of time in communicating what I’m doing, why I made Tome, or why static Drupal is hard, so now seems like a good time to stop and reflect on things before I write more code.

Note: This exploit was fixed over a year ago as a part of SA-CORE-2017-002/CVE-2017-6919, so unless your Drupal 8 site is really, really out of date, you should not be affected. When I do security research on Drupal core, I tend to focus on one class of vulnerability and pursue that until I find something.

I recently celebrated my five-year anniversary on Drupal.org, and wanted to write about how I work on issues day-to-day and my general contribution “vibe”. My Drupal.org account was created the week I started working at Acquia as a part of their employee on-boarding, and I only really used it to search issues and post an occasional comment at first. I know a lot of people in the community have grand stories about how they found Drupal, but mine is rather boring, unfortunately.

Last week I published the Twig Components Drupal module - the latest in a series of projects aiming to combine Twig, Web Components, and PHP. I wanted to write about why I’m doing this work, and why developers should care.

In the world of web security, cross-site scripting (XSS) vulnerabilities are extremely common, and will continue to be a problem as web applications become increasingly complex. According to a 2016 report by Bugcrowd, a popular bug bounty site, “XSS vulnerabilities account for 66% of valid submissions, followed by 20% categorized as CSRF” (source).

Note: The exploit discussed in this post was never included in a stable core release, so don’t freak out! The Drupal security team quickly fixed this while 8.3.x was still in development. One method I commonly use when auditing Drupal 8 code is to find routes that are accessible to anonymous users, or that check permissions which are commonly assigned to authenticated users. The purpose of this kind of audit is to find an access bypass vulnerability, or a route that is otherwise an easy target for denial of service or remote code execution attacks.

Drupal Advent Calendar day 3 - Markdown Easy james Sun, 12/03/2023 - 07:00

Welcome back to day 3 of the Drupal Advent Calendar. Behind today’s door Mike Anello (ultimike) introduces us to the Markdown Easy module.

I’m Mike Anello from DrupalEasy and I’m the maintainer of the Markdown Easy module - a relatively new contrib module I created in order to add a Markdown filter to text formats that doesn’t require a whole lot of configuration. 

Background

Most Drupal site-builders who are familiar with Markdown syntax use the Markdown module. Unfortunately, the Markdown module has had an inconsistent record of timely updates (especially for Drupal 10 compatibility until…

Tags

• Markdown
• Markdown Easy

Proprietary vs. Open Source CMSs Michael J. Ross 2023-12-02

If and when your organization needs a new website, in most cases the best approach is to build it upon a content management system (CMS), which is like a framework that allows the website owner to easily add and modify text and multimedia content by themselves, without having to rely upon any web developers or designers — who typically begin the process by identifying the needed capabilities of the site, configuring the CMS to make that possible, and crafting its visual design.

There are two general categories of CMSs from which you can choose: Open source or proprietary. Open source systems, as their name implies, consist of source code that is open to inspection by anyone, including the thousands of web developers who contribute to each CMS project, especially any group of them dedicated to finding and fixing security vulnerabilities in the code. Consequently, any such flaws in open source CMSs — such as WordPress and Drupal — are usually detected and repaired faster than those in commercial, homemade, or other proprietary systems. The security teams of open source projects typically comprise numerous skilled programmers who have diverse technical backgrounds and who take great pride in the quality of their work; after all, their names are clearly associated with the projects to which they are dedicated. This is quite unlike the unknown programmers who work at commercial firms and receive little publicity, especially when another security hole is discovered in the CMSs built and licensed by their employers.

In my experience as a web developer tasked countless times with replacing legacy websites built on proprietary platforms, clients who had allowed themselves to get locked into using such systems oftentimes find it much more difficult to transition away from any such platform, for several reasons: Each CMS has a unique way of storing page content, menu structure, content types, tags and tag assignments, etc. within its database. In turn, each one has a unique database design, making it prohibitively difficult to write code to try to automate the process of transitioning to an alternative platform (assuming such code has not already been produced by programmers who had faced the arduous process in the past). As a result, most such projects mean that your developers and content administrators will have to do most of that work by scratch.

Another downside to proprietary website systems is that the original developers who implemented the legacy system can even make it intentionally difficult to be replaced (perhaps thinking that this provides them with better job security). For instance, one of my former clients, a healthcare organization, hired me to replace a closed and heavily-licensed CMS, with something much more open and easily maintained. (For this particular project, I chose Drupal.) Not only was the legacy CMS poorly built and difficult to replace, but the original web firm had even gone to the trouble of encrypting on disk all of the client's PDF documents, and only decrypting them when displayed to users of the website. When the client asked the original developers (who knew they were being replaced) to decrypt the client's documents, they refused. As a result, one the project manager was compelled to view every one of those PDF documents online and then save the decrypted document, for use within the new website.

There are numerous other disadvantages to choosing a closed or otherwise proprietary website system. But for these reasons alone, if nothing else, you are almost always better off going with an open source CMS.

Copyright © 2023 Michael J. Ross. All rights reserved.

Drupal Advent Calendar day 2 - Subpathauto and Friends james Sat, 12/02/2023 - 07:00

Welcome to the second day of the Drupal Advent Calendar. Behind today’s door, Josh Mitchell (joshuami) tells us about the Subpathauto module, and some neat tricks when using it in conjunction with other modules.

If you are a Drupal developer, you probably already know about the Pathauto module. A huge number of sites use Pathauto to create friendly URLs as opposed to Drupal defaults using IDs such as /node/1. 

These friendly URLs are as good for humans as for the machines determining search engine rankings. You can create a path alias for any entity type in Drupal: nodes (content), taxonomy…

Tags

• Subpathauto