webjoke.de

After the huge success of the DrupalCon Portland competition, the Drupal Association is excited to announce that the t-shirt design contest will be returning for DrupalCon Atlanta! 

We want to see the Drupal community's design ideas for the official t-shirt, available for all attendees to wear and enjoy. Do you have a fantastic idea in mind? Let’s see your creativity!

The winner will get THEIR design on the front of the official t-shirt for DrupalCon Atlanta 2025!

What the judges are looking for

Judges are looking for a combination of creativity, impact, and relevance to the Drupal community. A design that tells a story and aligns with the values and aspirations of DrupalCon attendees is likely to capture attention.

While exploring bold ideas, consider how your design will resonate with a diverse audience. Think of classic elements that make a T-shirt memorable while pushing creative boundaries.  Avoid overcomplicating things; sometimes less is more, especially if every element adds value to the message. 

Now, for the finer details…

Your design must include the DrupalCon Atlanta Logo and will only be featured on the front of the t-shirt. Sponsor logos will be added to the t-shirt sleeves after the design is finalized. 

Specs: 

• PNG or PDF preferred
• 16 inches tall, 13 inches wide
• graphics need to be 300 dpi

All designs must be submitted by 31 December 2024 at 23:59 UTC, after which the submission form will close.

The Drupal Association will then select four designs to go forward to a public vote.

The top four designs, as chosen by the Drupal Association, will then be voted upon by the public, with voting closing on 18 January at 23:59 UTC. 

The winning design will be printed on the front of the official DrupalCon Atlanta 2025 t-shirt and the winner will receive a complimentary ticket to their choice of either DrupalCon Atlanta 2025 or DrupalCon North America 2026.

How to enter

Simply create your design, then fill out our submission form by 18 December to submit your final design. We also ask that you include a sentence or two describing why you chose your design and how it represents the Drupal community.

So, what are you waiting for? Submit your design now, and please help us spread the word throughout the Drupal community!

Good luck!

** Drupal Association staff and members of the DrupalCon Atlanta Steering Committee will not be permitted to enter this contest.**

Alex Moreno recounts his experience at DrupalCamp Berlin, held at the historic Alte Münze, where vibrant discussions on Drupal’s future, AI integration, and PHP’s evolution took centre stage. The event showcased the Drupal community's commitment to innovation and collaboration, from inspiring sessions by industry leaders to the retro-futuristic charm of Berlin’s C-base hackerspace. Sponsored by Pantheon, Alex reflects on how the event, the city, and people left a lasting impression.

In the above video, we’ll take our first look at Drupal CMS Beta, part of the Drupal Starshot initiative. This initiative aims to provide a downloadable packaged version of Drupal with pre-installed and configured contributed modules.

In the show notes below, you’ll learn about the Drupal Starshot Initiative, Drupal CMS, and how to install it using DDEV.

We’ll then explore Drupal CMS’s functionality and examine some modules included in the packaged solution.

Drupal Advent Calendar day 2 - Starshot Installer james Mon, 12/02/2024 - 09:00

It’s day 2 of the Drupal Advent calendar and today we’re taking a look at the first step to any new website built with Drupal CMS, the site installer.

The previous Drupal installer wasn’t terrible, but it required a lot of steps, and typically needed a lot more work, finding and installing modules, when the initial install was complete.

The new installer has tried to simplify the process as much as possible, and offers a friendlier interface.

The primary question it asks is what are the main goals of your site:

At present, there are six options, but these are expected to be expanded in the future…

Tags

• Drupal CMS
• Installer

Last week, I released a new version of the Override Node Options module - version 8.x-2.9.

This version makes the module compatible with Drupal 11 and, as there are no breaking changes, it's still compatible with Drupal 9 and 10.

It's great to see the module used on many Drupal 8+ websites and distributions such as LocalGov Drupal.

Whilst the overall number of installations has been consistent, the number of Drupal 7 installations has decreased whilst the Drupal 8+ version installations have increased.

With a Drupal 11-compatible version now available, I hope it continues to increase.

Drupal Advent Calendar day 1 - Starshot: a Brief Introduction to Drupal CMS james Sun, 12/01/2024 - 09:00

Welcome to this year’s Drupal Advent Calendar, and this year the focus is on the most important Drupal initiative in quite some time.

Code named Starshot, it aims to take Drupal to a new level of user friendliness and ease of use.

Over recent versions, Drupal has become incredibly powerful, and it now powers many enterprise websites for major corporations, governments, and NGOs around the world.

Starshot was announced by the founder of the Drupal project, Dries Buytaert, at DrupalCon Portland, in April of this year. This proposed a new default installation of Drupal with many extra features, and…

Tags

• Drupal Starshot

One of the common needs, or at least desires, for CRM users is to link their CRM to some kind of constituent portal. There are several ways your can architect a good data pattern for your constituent portal. The trick is picking the right one for your organization.

This is the first in a series on what your choices are, and now to select the right one. The architecture you select will drive the implementation cost, maintenance costs, and scalability.

The Purpose of Your Constituent Portal

Before deciding on the architecture of your portal, you need to have a clear understanding of its intended purpose and expected scale. The purpose of the portal will also dictate the direction(s) data flows, and the scale will help you plan the long term costs.

If you can’t clearly state why you need a constituent portal, you don’t need one.

Different organizations have different reasons to create portals. Companies that sell products may want a warranty or support portal. Nonprofits often want a donor portal that provides tax recipes and allowed recurring donors to update their gift information. Member organizations want a place for members to see their benefits, update their information, and renew their memberships. And so on.

The purpose of your portal will determine the direction that data flows through it. There are essentially three directions that data can move.

Outbound Data

You can send data from your organization to your constituent. That could be things like receipts, memberships status, or product warranty information. Anything that is data you have, that your member might need to see, but not update.

Data Exchange

You can allow constituents to update information. That could be address changes, support requests, donation schedule updates, event registration details, and more.

Data Network

Your third option is to allow you constituents to exchange information with each other. This could be a any form of member community where they engage with each other.

When planning a network, remember you have to plan for content moderation and acceptable use policies.

Primary Portal Data Architectures

To support your portal, whatever the data flow is, there are three main data architectures you can choose from, each which a different strengths and weaknesses. The more complex your architecture the more options you will have for what it can support, but it will also increase costs and maintenance efforts. Bigger is not always better – sometimes it’s just more expensive.

1. All-in-One Constituent Portals

In an all-in-one solution your constituent portal is part of your CRM. For obvious reasons this is the type of portal that your CRM vendor wants to sell you. In Salesforce land this means Experience Cloud. There are also many nonprofit-focused CRMs which include one in their solution. When your portal is part of your CRM you get a bunch of advantages:

• Data all lives in one place. There is no data sync to worry about setting up or maintaining.
• You have one vendor. That means you can centralize your support arrangement and billing.
• They are often fastest to implement. They are designed to be fast to market to help make them the obvious choice.
• They generally do not require a developer. Again, your CRM vendor really wants you to select this path, so they clear as many hurdles as they can.
• There is only one technology stack. By leveraging the technology of your CRM your investments in learning that technology carry over, at least in part, to your portal.

There are also downsides:

• New template system to learn. The CRM’s portal likely has a different template system than the CMS on your main web site. That may be hard to make match your primary online branding.
• The vendors make a lot of assumptions. To provide that ease listed above they make assumptions about how data flows, security, user experience, and how other elements should work – those assumptions may not match your ideal solution.
• Costs often scale linearly. There are usually license costs that are scaled based on user count meaning your costs grow as the portal grows at more or less a 1:1 rate. While there are price breaks and other incentives this is the right expectation to have for estimating.

2. External Constituent Portal

In this pattern an external constituent portal moves the user experience from within your main CRM’s sphere of influence into a separate platform. In my career I’ve mostly built these with Salesforce as the CRM and Drupal as the portal platform – it’s a powerful pairing. The strengths and weaknesses here are more or less the mirror of the all-in-one portal.

• You web team may already know the technology. If you use the same technology as your web developers use for your main web site(s) they already know who to handle design and branding.
• You have greater control over the User Experience. The assumptions that go into the portal are yours not the ones imposed by the CRM.
• You have greater control over security, along with data flow and formats. Since they aren’t built around assumptions you don’t control you have greater control and freedom.
• Costs typically grow more slowly. It is less common to have per-user license costs in this context so the cost curve is likely closer to logarithmic.

The downsides:

• You have to handle data synchronization. The two systems means data has to pass back and forth.
• You have two difference vendors/platforms. When you had one system everything was centralized, now you have two different systems handling constituent data.
• This design typically is harder to implement. All those short cuts your CRM provider had in mind for you are gone. Even if you use purpose built solution it’s going to take more time and effort.
• This approach generally requires a developer and/or data architect. To implement this pattern you need someone who understands both platforms – ideally both for setup and support.

3. External Constituent Portals with Data Proxy

In some situations it makes sense to insert a data proxy, or API layer, between your main CRM and your constituent portal. This creates a layer of abstraction, security, and data augmentation that can benefit a lot of organizations. While this is the most complex of the three main architectures it is one I find is frequently overlooked – in part, I suspect, because no one partner benefits from selling it.

This setup certainly isn’t for everyone, but when it’s the right fit it makes a huge difference. It also creates a significant number of iterations – all of those arrows could be one directional or two directional.

An extra data layer makes the most sense when data from your CRM is going to multiple places and/or needs to be augmented by an external data source. For example think about an organization that provides trail maps for hiking or paddling. All that data about trails does not need to be in your CRM, but you probably want to know which members are interested in which trails. An organization like that may have a portal for members, a web site to find trails for non-members, apps for iPhone and Android, and perhaps a public API for other people to use to build their own web sites with. That’s a lot of API calls all with different data sets, all of which need to be very fast.

Your CRM is designed to be very stable and reliable – it is not designed to be very fast. What’s more, you often have limits on the number of API calls you get in your package with extra fees charged if you go over. By inserting another layer between your CRM and other needs you can bypass these limitations.

There is another added benefit to this design pattern, and that is increased security. By creating an additional layer in your system you are able to create a separation of concerns between the various systems. Each should have access to only the data is absolutely needs from any of the others.

How to Pick?

There are lots of considerations that go into selecting the right architecture for your project – which is why that’s getting it’s own post soon.

The post Architectures for Constituent Portals appeared first on Spinning Code.

The Splash Awards 2024 marks a decade of celebrating innovation and excellence in Drupal, putting the spotlight on agencies and users who push boundaries in the field. Bert Boerland, Chairman of the Drupal Netherlands Foundation, reflects on the journey from a bold idea in 2014 to a prestigious event that now inspires entries from around the globe. From overcoming challenges in jury selection to dreaming of a pan-European “Euro Splash Awards,” Bert shares insights and memorable moments from the awards’ evolution. Interview by Esmeralda Braad-Tijhoff.

Your Go-To Source for Drupal Answers, direct from trusted sources only.

This week I fixed lots and lots of accessibility issues.

DrupalCon Vienna 2025 has onboarded The Drop Times as its official Media Partner. Join us in Austria's capital from October 14-17, 2025, for Europe's biggest Drupal event. Stay tuned to The Drop Times for exclusive updates, insights, and all things Drupal leading up to the conference.

Unleashing Flexibility: How Headless Drupal is Shaping the Future of Content Delivery bhavinhjoshi Thu, 11/28/2024 - 10:57

Headless Drupal is changing the course for content management systems by offering a fresh approach to how digital content is delivered across platforms.

At its core, headless Drupal separates the backend (where content is stored and managed) from the frontend (where content is displayed). This decoupling allows for a greater range of flexibility and customization in how content is presented to users, leading to faster, more dynamic websites that can easily integrate with a multitude of modern tech stacks.

Why choose headless? 

The benefits are abundant. By going headless, organizations can seamlessly deploy content across diverse platforms—from mobile apps and kiosks to IoT devices. This means a blog post, product description, or interactive experience can be shared consistently, regardless of where or how it is consumed.

However, embracing headless architecture is not without its challenges. Managing separate systems can introduce complexity. Multiple moving parts can sometimes lead to increased difficulty in synchronizing the backend with various frontends. Fortunately, Drupal's API-first architecture mitigates these challenges by providing a strong foundation for developers to build upon, ensuring a cohesive integration between systems.

The real excitement comes with the capability to pair Drupal's robust backend with cutting-edge front-end technologies like React, Vue.js, or Angular. This combination results in richer, more engaging user experiences that cater to modern audiences' expectations for speed and interactivity. Developers have the freedom to innovate and tailor the user interface to meet the unique needs of their audience, unencumbered by traditional constraints.

Moreover, businesses are positioned to benefit tremendously from headless Drupal. They gain the ability to bring new features to market rapidly, allowing them to stay ahead in today’s fast-paced digital landscape. Scalability becomes less of a concern, as the architecture easily accommodates growth and a wide variety of digital touchpoints.

Headless Drupal doesn't just promise flexibility; it delivers adaptability essential for future-proofing digital strategies. In an era where customer engagement is king, and technology continues to evolve at unprecedented speeds, having a versatile and powerful content management system is indispensable.

The question isn't just whether headless Drupal is the future—it's about understanding how this evolution in content management can redefine your digital strategy to better connect with users across every platform.

Headless Drupal Drupal Planet Add new comment

The end of Drupal 7 support is approaching (January 5, 2025), which means this system’s users need to migrate to a newer version. This article explains how to move smoothly from Drupal 7 to Drupal 11, the key steps, and what to pay attention to. I encourage you to read the article or watch the video in the “Nowoczesny Drupal” series.

Is your website the driving engine of your higher ed institution and a powerful catalyst for its goals? Is it effectively attracting prospective students, inspiring alumni, and building a vibrant community? There are always new strategies to boost your website's impact and ensure the answer is a resounding "yes"! As a team that specializes in higher education website design & development, we are passionate about sharing useful tips that can help those in this sector.

Craft Your Perfect Proposal: MidCamp 2025 Session Proposal Workshop

Learn how to upgrade Drupal with Composer, ensuring seamless updates, compatibility, and enhanced security.

Developed by Anand Toshniwal, a Python script now automates the creation of .component.yml files for Single Directory Components in Drupal. Simplifying workflows and improving accuracy, this tool supports projects like the Starshot Demo Design System, enhancing efficiency for developers.

With just 12 days remaining, DrupalCon Singapore 2024 is set to bring the global Drupal community together from 9 to 11 December at the PARKROYAL COLLECTION Marina Bay. This dynamic event will feature three days of inspiring sessions, hands-on training, and the inaugural Splash Awards in Asia, celebrating innovative Drupal projects. Hosted by the Drupal Asia Steering Committee and supported by the Drupal Association, the conference reflects the vibrant, collaborative nature of the Drupal ecosystem, offering attendees a unique opportunity to learn, network, and celebrate in one of Asia’s most dynamic cities.

That’s a lot of sites!

Yes, it is! 10+ years ago we migrated 200 sites to a new server - and in 2024 we set up Cloudflare protection for well over 1000 sites.

Aegir is a hosting system built in Drupal, for Drupal. It lets you create and manage Drupal sites and all their databases, filesystems and virtual hosts. With Aegir, it’s easy to manage hundreds or thousands of sites via a simple UI. Each site has a node to represent it, and this project stored a whole bunch of additional Cloudflare metadata against the Site Nodes.

Keeping a PaaS product online at all times comes with a high level of responsibility. After code quality assurance and testing, DDOS attacks of all sizes and types are a high risk threat. The cost of protecting our availability, unsurprisingly, was non-trivial and became a point requiring fresh research and investment. Reducing the general load and the potential attack load on our servers would serve to support our quality of service.

In the Spring of 2024 we set up a proof of concept using Cloudflare, which would allow us to make a significant ongoing cost saving whilst also playing with some really cool APIs.

The plan

In order to put all our sites behind Cloudflare, we needed to:

* Get Aegir talking to Cloudflare via their API, and build the automatic processes to support the setup process
* Create a clear interface for starting and tracking setup per site
* Create a clear dashboard for tracking progress overall
* Go! Change the nameserver records for every domain, to point to Cloudflare

Here are some of the key interesting parts of our story (which had negligible downtime, btw!)

Interacting with Cloudflare’s API

It was greatly pleasing to find that Cloudflare let you do almost everything over an API (given the right authentication!). Given the scale of their company, it shouldn’t be a huge surprise I suppose!

With 1000 sites approx. to deal with, there was a strong drive to automate as much of this process as possible. So there was much celebration when it became clear that we would be able to do almost every step automatically, including:

* create everything we needed for the site domain, with an appropriate plan under our chosen account
* upload DNS records, query them and update them
* perform real-time ownership verification and SSL validation

Simple admin setup - Obtain DNS records for hundreds of domains, store them against Site Nodes, press GO

A large portion of the domains (about 500) are under our control, so we were able to bulk export the DNS records, process and save them against their Aegir Site Nodes. Some simple processing removed the SOA and NS records so that we would be able to send the records straight to Cloudflare when setup started.
These ‘easy’ sites, for which we had the DNS records, would be processed in bulk with a lot of Go! button clicks, and then making the relevant nameserver changes with the domain provider.
(The domain provider did offer to do bulk updates for us, but there seemed to be a 24h delay before action was taken - so it was quicker to do these changes ourselves.)
 

Cropped screen grab of our progress pie chart

 

 

Creating a self-service setup mechanism via Drupal config + settings.php

Domains that we only had nameserver control for would have to be updated by the customer. But how would they know what nameservers to set up, and how would they trigger the setup process? Stats to the rescue!
As part of the Drupal 10 rebuild of the platform we added a Statistics module, which collects a selection of data points from each site and passes them to the corresponding node on Aegir for storage. They’re then aggregated and sent back to the sites so that customers can compare their performance to the cohort averages.
We created a form interface for the user to trigger setup when ready, and then smuggled the outputs over to Aegir in amongst the performance stats

I'm excited to share the first version of Drupal Starshot's product strategy, a document that aims to guide the development and marketing of Drupal Starshot. To read it, download the full Drupal Starshot strategy document as a PDF (8 MB).

This strategy document is the result of a collaborative effort among the Drupal Starshot leadership team, the Drupal Starshot Advisory Council, and the Drupal Core Committers. We also tested it with marketers who provided feedback and validation.

Drupal Starshot and Drupal Core

Drupal Starshot is the temporary name for an initiative that extends the capabilities of Drupal Core. Drupal Starshot aims to broaden Drupal's appeal to marketers and a wider range of project budgets. Our ultimate goal is to increase Drupal's adoption, solidify Drupal's position as a leading CMS, and champion an Open Web.

For more context, please watch my DrupalCon Portland keynote.

It's important to note that Drupal Starshot and Drupal Core will have separate, yet complementary, product strategies. Drupal Starshot will focus on empowering marketers and expanding Drupal's presence in the mid-market, while Drupal Core will prioritize the needs of developers and more technical users. I'll write more about the Drupal Core product strategy in a future blog post once we have finalized it. Together, these two strategies will form a comprehensive vision for Drupal as a product.

Why a product strategy?

By defining our goals, target audience and necessary features, we can more effectively guide contributors and ensure that everyone is working towards a common vision. This product strategy will serve as a foundation for our development roadmap, our marketing efforts, enabling Drupal Certified Partners, and more.

Drupal Starshot product strategy TL;DR

For the detailed product strategy, please read the full Drupal Starshot strategy document (8 MB, PDF). Below is a summary.

Drupal Starshot aims to be the gold standard for marketers that want to build great digital experiences.

We'd like to expand Drupal's reach by focusing on two strategic shifts:

1. Prioritizing Drupal for content creators, marketers, web managers, and web designers so they can independently build websites. A key goal is to empower these marketing professionals to build and manage their websites independently without relying on developers or having to use the command line or an IDE.
2. Extending Drupal's presence in the mid-market segment, targeting projects with total budgets between $30,000 and $120,000 USD (€25,000 to €100,000).

Drupal Starshot will differentiate itself from competitors by providing:

1. A thoughtfully designed platform for marketers, balancing ease of use with flexibility. It includes smart defaults, best practices for common marketing tasks, marketing-focused editorial tools, and helpful learning resources.
2. A growth-oriented approach. Start simple with Drupal Starshot's user-friendly tools, and unlock advanced features as your site grows or you gain expertise. With sophisticated content modeling, efficient content reuse across channels, and robust integrations with other leading marketing technologies, ambitious marketers won't face the limitations of other CMSs and will have the flexibility to scale their site as needed.
3. AI-assisted site building tools to simplify complex tasks, making Drupal accessible to a wider range of users.
4. Drupal's existing competitive advantages such as extensibility, scalability, security, accessibility, multilingual support, and more.

What about ambitious site builders?

In the past, we used the term ambitious site builders to describe Drupal's target audience. Although this term doesn't appear in the product strategy document, it remains relevant.

While the strategy document is publicly available, it is primarily an internal guide. It outlines our plans but doesn't dictate our marketing language. Our product strategy's language purposly aligns with terms used by our target users, based on persona research and interviews.

To me, "ambitious site builders" includes all Drupal users, from those working with Drupal Core (more technically skilled) to those working with Drupal Starshot (less technical). Both groups are ambitious, with Drupal Starshot specifically targeting "ambitious marketers" or "ambitious no-code developers".

Give feedback

The product strategy is a living document, and we value input. We invite you to share your thoughts, suggestions, and questions in the product strategy feedback issue within the Drupal Starshot issue queue.

Get involved

There are many opportunities to get involved with Drupal Starshot, whether you're a marketer, developer, designer, writer, project manager, or simply passionate about the future of Drupal. To learn more about how you can contribute to Drupal Starshot, visit https://drupal.org/starshot.

Thank you

I'd like to thank the Drupal Starshot leadership team, the Drupal Starshot Advisory Council, and the Drupal Core Committers for their input on the strategy. I'm also grateful for the marketers who provided feedback on our strategy, helping us refine our approach.