Samuel Mortenson: Getting creative with Drupal XSS
Samuel Mortenson: Chained Drupal CSRF to disable all blocks
Samuel Mortenson: Simplifying Drupal frontend with Single File Components
LostCarPark Drupal Blog: Drupal Advent Calendar day 3 - Markdown Easy
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
Michael J. Ross: Proprietary vs. Open Source CMSs
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.LostCarPark Drupal Blog: Drupal Advent Calendar day 2 - Subpathauto and Friends
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
The Drop Times: Costa Rica 2023: A Glimpse into Success at Drupal Camp
LostCarPark Drupal Blog: Drupal Advent Calendar day 1 - Gin Admin Theme
Welcome to the 2023 Drupal Advent Calendar. Behind today’s door, we find the Gin Admin Theme, with a fantastic write-up by Ludovic Favre (Grumpy74).
Since Drupal 10, Claro has been the default admin theme for Drupal websites. It added a new look and feel improving usability for Drupal site builders and administrators. But wouldn’t be amazing if you could add new features on top of it? Well, that’s exactly what Gin Admin Theme provides.
First of all, the Gin Admin theme maintainer, @saschaeggi, is a contributor on Claro theme and the Drupal Design System. This makes it hyper relevant in terms of…