The Drupal Commerce 2.x development process has been one big adventure! Over the last 2.5 years we've accumulated 2,000 code commits in multiple repositories from over 70 contributors at dozens of agencies. With last week's release of a stable Commerce 2.0-rc2, we've started preparing to celebrate the full release with parties around the world.
Our plan is to release Commerce 2.0 on Wednesday, September 20th, just in time for us to show it off at DrupalCon Vienna. On September 21st, we are coordinating a series of release parties at the offices of a variety of contributing Drupal agencies, including 1xINTERNET, Acro Media, Actualys, Adapt, Blue Oak Interactive, Circle WF, MD Systems, Wunder, and more.
With over 1,500 sites reporting usage and a growing number of high quality case studies, we can all feel proud of what we've achieved together. Many of these projects directly contributed to the development of core and other essential features in Commerce 2.x, including promotions, coupons, shipping, etc. We've created a Drupal Commerce 2.0 party list and showcase that we'll be updating as we go, and we invite you to get in touch to be added or to find a party near you.
The release parties will give you and your team an opportunity to review the important new features and capabilities Commerce 2.x offers out of the box. We'll provide basic slides covering those topics, and we invite you to add to them for your part to reflect on your agency's experience and involvement with the project thus far. (e.g. What Commerce 2.x sites have you launched? How did those projects go? What parts were contributed back? etc.)
Any other ideas? Leave 'em in the comments and help spread the word!
DrupalCon Europe plays an important role in moving Drupal forward by uniting community members across countries for knowledge sharing, networking, and celebrating. Plus, the event is one of the largest events focused on contribution back to the project. However, with waning attendance and financial losses, it’s time to find a new path forward so it is financially sustainable and provides value to the European community. This blog covers the financial problem we need to solve and it is part of a series that includes:
The problem we need to solve for financial sustainability
The problem we need to solve to create unique value
Results from a proposal based on community input
A new path forward for DrupalCon Europe
DrupalCon is a human experience. We certainly want to focus on the people in the community: what they want to achieve and what that looks like through an improved experience. However, financially the event needs to at least break even for us to continue providing this special experience. That is why we are starting this conversation by framing DrupalCon Europe’s financial problems.
We know that financially-focused blogs can be downright boring and not everyone feels comfortable reading financial statements. So this post provides several kinds of reports to illustrate the problem and we do our best to spell out where the challenges lay. Feel free to leave questions in the comments and we will answer them.
Last year, the Drupal Association contracted with a new financial planner, Summit CPA. They provide a lot more resources and financial insight than we have had in the past. One of the biggest things we learned last September was that DrupalCon Europe loses money. In the past, we did not include staff costs as part of the event cost, so we operated under the understanding that DrupalCon Europe was breaking even at a minimum. Our DrupalCon team spends 50% of their time on this event. Marketing spends close to 50%, the sponsor sales team spends 30%, engineering spends about 15%, and finance spends about 20%. For DrupalCon Europe, the staff costs add up to $220,000 per event.
It wasn’t wrong to not include staff costs in the DrupalCon budget. It just didn’t give the true picture of how this particular program was performing. As we started our financial turnaround last year, we realized that we need each of our programs to be self-sustaining going forward. Except, DrupalCon Europe is not self-sustaining. That puts pressure on the viability of other programs like Drupal.org, which needs to be properly funded to support everyone in the community.Understanding Financials Through Comparison
One of the best ways to understand a situation is through comparison, so let’s look at DrupalCon Europe versus DrupalCon North America, which consistently operates at a profit due to several factors. We provide several reports below to help you see the comparison and the post walks you through those comparisons.
You will notice that all financials are in U.S dollars (USD). Since the European community works with different currencies, we felt it was less confusing and less prone to error if we kept our reports in USD.DrupalCon Reports
Profit & Loss: DrupalCon Baltimore vs DrupalCon Dublin
Ticket Cost Break Down: DrupalCon Baltimore vs DrupalCon Dublin
DrupalCon North America has a net income percentage of up to 38% and makes up 45% of Drupal Association’s annual revenue. Meanwhile, DrupalCon Europe operates at a loss. For example, DrupalCon Dublin lost $176,000 and had a net income percentage of -18%. DrupalCon Vienna is forecasted to lose over $200,000 even with the programming reductions that we made earlier in the year.DrupalCon Europe Financial Challenges
In short, DrupalCon Europe income is lower than DrupalCon North America due to fewer attendees and less sponsor support. However, expense per attendee is higher in Europe. Below is a summary of the main differences that make DrupalCon Europe unsustainable. We invite you to review the Profit & Loss statements and other financial reports so you can have more clarity around these points and possibly find ones we missed.Greater Expenses than DrupalCon North America
One of the biggest cost difference is related to the convention center. Both DrupalCon Europe and North America are held in this kind of venue due to the attendance size. While DrupalCon Europe has less attendees than the North American event, it is still large enough to require us to be in a convention center.
We looked at moving the event to a hotel, but wifi and catering costs make this option more expensive. Also, hotel-based conferences require a large room block reservation that the Drupal Association would have to financially guarantee, which is a big risk. The European event attendees tend to opt for other lodging options like AirBnB. It’s unlikely we can sell enough hotel rooms to meet the guarantee and will end up paying a large penalty.
By comparing DrupalCon Dublin expenses with DrupalCon Baltimore expenses, you can see that the expense 5710: Facility and Furnishing is $328,000 in Dublin and $129,000 for Baltimore. This is the main expense putting strain on DrupalCon Europe’s sustainability.
It’s also more expensive to send staff and our contracted production team from the United States to Europe for a marathon of an event (up to 10 days).Less Financial Support than DrupalCon North America
The challenge of funding an expensive, professional event like DrupalCon Europe comes down to two things: smaller attendance and less sponsor support. Here is a breakdown of how these two revenue items differ from DrupalCon North America.Attendees
Smaller attendance with higher expenses make the event unsustainable. DrupalCon Europe attracts about 1,700 - 1,800 attendees compared to DrupalCon North America, which has over 3,000 attendees. This means there is less ticket revenue to cover costs. And DrupalCon Europe attendance is decreasing each year by about 14% a year on average (if you average in Vienna's forecasted attendance), making it harder to cover costs in the future.
Another attendee difference is that DrupalCon North America attracts end users who are either leveling up their skills or evaluating Drupal or looking for a service provider. Having end users at DrupalCon attracts Drupal shop / digital agency sponsors who get new business by connecting from this audience. Meanwhile, DrupalCon Europe primarily attracts builders (developers, project managers, designers) from Drupal shops / digital agencies. There are very few end users attending DrupalCon Europe. This impacts sponsor revenue as many Drupal shops / digital agencies do not want to sponsor an event where they are much less likely to get a business opportunity.Sponsors
DrupalCon North America has about $850,000 in sponsor revenue while DrupalCon Europe has $300,000. There are a few reasons for this difference.
A big portion of DrupalCon North America’s sponsor revenue comes from North American Drupal shops / digital agencies. As mentioned, they sponsor because they can connect with the end user attendees who give them business opportunities. They also sponsor because the event is held in a country where they conduct business.
In Europe, and as mentioned above, Drupal shops / digital agencies are much less likely to get a qualified lead because it is primarily a developer event. Additionally, the Drupal shops / digital agencies in Europe support sales in their specific countries. As DrupalCon Europe moves around, sponsors find that the event is in a country where they don’t do business and therefore don’t want to sponsor.
As for the shops/ agencies who do sponsor, they do so to support the community. It’s simply getting harder for them to invest in the event as they chose to put those funds into marketing or operations. It is important to note that hosting and software companies do find value in supporting DrupalCon since they target the developer audience.A Study of Ticket Sales Profitability
Another way to see how the income and expense challenges make DrupalCon Europe unsustainable is to look at what the sale of a ticket covers and how much is left over to go towards paying expenses.
Here is a report that shows profitability of the early bird and the regular rate ticket for DrupalCon Dublin and DrupalCon Baltimore. It shows that the profitability is:
Early Bird Rate
Early Bird Rate
Ticket Profitability before sponsor income
Sponsor income per attendee
Total Ticket Profitability
Ticket Profitability before sponsor income
Sponsor income per attendee
Total Ticket Profitability
As you can see, we lose money for each DrupalCon Europe early bird ticket we sell. You may ask, why would we ever price a ticket that loses money? It’s a good question. When we priced this we did not include staff costs in the overall event costs. We were operating under the understanding that the ticket was making money. We can see now that when we include the staff costs to the overall event costs, this ticket type loses money.
You can also see that not only does the Dublin regular rate earn $300 less profit per ticket compared to Baltimore, that profitability needs to compensate for the losses accrued by the Dublin early bird ticket sales.
Looking more closely at the report, you can also see that having less DrupalCon Europe sponsor support puts the ticket sales profitability at an even greater disadvantage.
Clearly, DrupalCon Europe has a financial structural issue to solve for.Blockers to Financial Solutions
There are a few ways to solve the financial problem. Ticket prices could be increased, we could grow attendance to improve the profitability, we could stay in the same venue each year, or we could cap attendance and have a smaller DrupalCon to control costs. We looked at these options and found the following blockers to each solution.
Increase ticket prices.
We surveyed the European community and found that there was a strong resistance to increasing ticket prices even if more value was delivered. Many see this event as a community event that should be affordable or free. Many believe they pay through their code and non code contribution and don’t want to pay more in ticket costs. Many also told us they want the ticket price to be greatly reduced.
Grow ticket sales revenue by expanding who the event serves
Attract more “builders”. Both DrupalCon Europe and North America attract a “builder persona” who work at a digital agency or Drupal Shop (developer, project manager, designer, UX). However, North America attracts builders from end users as well whereas DrupalCon Europe does not. It has been challenging to grow the end user / builder attendee at DrupalCon Europe. Part of the challenge is that when an end user adopts Drupal, the Association does not know. There is no closed-loop system that tells the Drupal Association who is using the software. We have to rely on Drupal shops / digital agencies to provide this information or be our marketing channel. In Europe, several agencies said they don’t want their end user attending so they stay positioned as “the trusted source on how to Drupal”.
Attract “evaluators”. In North America, the event has a commercial element, attracting decision makers who want to meet with sponsors and learn more about Drupal. This not only grows ticket sales, but it also encourages the high level of sponsor support in North America. However, DrupalCon Europe attendees strongly request that we don’t include a marketing or commercial focus at DrupalCon Europe, keeping it a purely developer event.
Hold a smaller event to control costs.
We researched this over the past few months. Looking at a 1,000 - 1,200 person event, venue options that can meet our event needs are still too expensive. And after testing the smaller event concept, we found that many community members were dissatisfied with this direction.
For DrupalCon Vienna, we controlled costs by making the program smaller by reducing the Monday trainings and summits. We also eliminated other elements like the DrupalCon t-shirt. Despite these changes, we are still operating at a loss due to decreasing attendance. Many expressed they understood why we needed to make these changes, but were unhappy with them. We are grateful to the Drupal Austrian community for bridging this gap and hosting summits and trainings on the Monday before Drupalcon Vienna.
This part is a bit sensitive because I’m talking about staff. They gave permission to have these details shared with you.
Last year, when the Drupal Association reduced its staff to bring our expenses in line with our revenue, we eliminated work to match the smaller team capacity. After living with that reality for a year, we can see that we did not do a good job with DrupalCon.
The DrupalCon staff consists of Rachel Friesen, Director of Events, and Amanda, Gonser, Program Manager. Rachel is an operational wizard, who is committed to excellence, and cares deeply about delivering a special experience that meets our community’s needs. Rachel has incredibly streamlined the way we produce DrupalCon from site selections, budgeting, space planning, vendor management, sponsor support, marketing oversight, and so much more. She moves an army of people ranging from the board, staff, vendors, sponsors, and community members through a process that ensures that everything gets done on time with the best possible planning. I am always impressed how Rachel goes the extra mile (er, kilometer), to hear and address everyone’s needs and ideas. It is truly a balancing act.
Many of you likely know Amanda from the DrupalCon emails or you are one of the hundreds of volunteers who work with her. Amanda is high energy, bubbly, focused, and moves hundreds of people through a process that allows everyone to contribute in their special way; track chairs who pick sessions, trainers, local volunteers who create the local experience, a troupe of event photographers, room monitors, social media volunteers, and more. As with all people management, Amanda not only gives volunteers a structure to follow, but she invests time with them to foster relationships. We can not produce DrupalCon without our amazing and generous volunteers and they deserve a meaningful experience.
While producing DrupalCon, many people want to try new things like add a new program to DrupalCon five months before the event or create a new sponsor package. There are certainly great ideas that can level up the experience. Unfortunately, Rachel and Amanda simply do not have the capacity to entertain many new ideas. That’s frustrating for both of them because they want community members to realize their ideas. It’s equally frustrating to the community members. In the end it can create a lose-lose situation.
Over the year, we noticed that Rachel’s and Amanda’s calendar is booked every hour throughout each day. When we talk, they have little time as they run from one meeting to the next. It’s a frenetic pace. We moved to Jira this year and their burndown charts show that they can not complete everything they need to do within a sprint. This pace and high levels of stress are causing health issues.
Amanda did a capacity study. It showed that she is scheduled to do over 69 weeks of work in a year (and that doesn’t include sick or vacation time). Just a reminder, a year has 52 weeks. Rachel is in a very similar situation. We looked at which work we could eliminate, but at this point there is nothing. Naturally, the situation is untenable and must be addressed immediately.
Given how small our team is, the only way to address this is by adding another staff member or contractor. This means expenses will further increase for DrupalCon Europe. We can go this route, but in the end what this tells me is that we do not have the right operational model to support two DrupalCon per year - let alone the ability to scale back up to three per year.
I want to pause and thank Rachel and Amanda for pushing through this challenging time. Please join me in thanking them. I also want to thank the other Drupal Association staff for going above and beyond to make DrupalCon a special experience. You support Rachel and Amanda in so many ways to deliver a great event for the Drupal community.
Additionally, it can not be said enough how special our volunteers are. They contribute their time and talent while already having full lives that include jobs, family, friends, and other interests. Volunteers could choose to do many other things with their free time, yet they chose to create DrupalCon for all of us. Thank you.Summary
Phew! That was a longgg DrupalCon financial overview. Thanks for hanging in there. I hope sharing all that data and insight helps answer some of the questions we’ve seen in past blog comments and on Twitter this past year.
As you can see, solving DrupalCon Europe’s sustainability is critical, not only so this event can exist into the future, but so it doesn’t put strain on the sustainability of Drupal.org, which is clearly imperative for the project’s viability. We need to answer the question “how do we balance creating a valuable event with the financial realities of event production and the realities of staff capacity?”
But before we get into solutions, let’s look at what the community wants DrupalCon to achieve.
Our next blog in this series will be about the other problem to solve: How can DrupalCon Europe provide unique value?
This week, I spoke with Justin Rhodes (TheJustinRhodes). Justin has been part of the Drupal community for four years, and has attended four DrupalCons.
Greetings to everyone! It looks like “8” is a lucky number and 8/2017 is a lucky month for drupalers. By taking a little extra energy from the sun (which is pretty environmentally friendly), the Drupal community has made so many awesome things! It feels like yesterday that we offered you the July 2017 Drupal news summary, and now we’re moving on to the wrap-up of the hot and productive August 2017.Read more
Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll investigate W3C Validator, a module which helps in maintaining a properly coded site.
It’s impossible to create a system which is absolutely safe but Drupal developers try. Thanks to the big community of developers there is a lot of documentation and useful examples of the proper configuration of Drupal website security and keeping this configuration up-to-date.
This article focuses on discussing common server settings, the configuration of a web server, PHP, and a database, and, of course, Drupal. It provides clues which should help the server and website administrators to audit the security of the entire system.
Aegir with Docker would be one of the brilliant option for Better Drupal Development and Faster Deployments.
Docker, which solves the overhead of virtualization layer. And Aegir, which gives the best possible Drupal Multisite hosting.
- Prefer || or && Over or or and in Logical Operators - this issue needs more support in order to be ratified.
- Explicitly disallow yoda conditions
With "A Simple Timeline" contribution module in conjunction with the Drupal core module "Views" you can present a nicely looking and well organized vertical timeline of Drupal entities. It could be, for example, teasers. This is exactly what you will learn in this post.
For the purpose of this tutorial, I will use a sequence of the Summer Olympic Games of this century. Let's get started!
Drupal core announcements: 8.4.0 release candidate phase begins week of September 4; no Drupal 8.3.x or 7.x patch release planned
The release candidate phase for the 8.4.0 minor release begins the week of September 4. Starting that week, the 8.4.x branch will be subject to patch release restrictions. Closer to the 8.4.0 release on October 4, we will limit the changes to critical bugfixes and other high-priority changes. You can help by ensuring that the issue priority is set correctly for major-priority issues, and that the branch field is set to 8.5.x (for disruptive changes) or 8.4.x (for patch-release-safe bugfixes) as appropriate.
8.4.0 provides stable, production-ready releases for several modules that were previously experimental, including Workflows, Datetime Range, Layout Discovery, Media, and Inline Form Errors. The release also includes several critical bug fixes and many other improvements for REST, content moderation, authoring experience, performance, and automated testing. You can read a detailed list of improvements in the announcement of alpha1.
Minor versions may include changes to user interfaces, translatable strings, themes, internal APIs like render arrays and controllers, etc. (See the Drupal 8 backwards compatibility and internal API policy for details.) Developers and site owners should test the release candidate to prepare for these changes.
8.5.x will remain open for new development during the 8.4.x release candidate phase.
Drupal 8.4.0 will be released on October 4th, 2017.
September 6 is also a monthly core patch (bug fix) release window for Drupal 8 and 7, but no patch release is planned. This is also the final bug fix release window for 8.3.x (meaning 8.3.x will not receive further development or support aside from its final security release window on September 20). Drupal 8 sites should plan to update to Drupal 8.4.0 on October 4.
I had a devil of a time figuring out where captioning was coming from on my entity embeds.
Another team member had set it up, and I was just kind of baffled as to why captions were being offered on my entity embed forms.
It turns out that if you turn on captioning, you just get it for free on all of your embeds, and it's not configurable.
But... I don't want it for free!
Bah. Humbug. This free software doesn't have the features I think it should.
Alright, so here's how you turn off captioning:
This is part 2 of our series on developing a Decoupled Drupal Client Application with Ember. If you haven't yet read Part 1, it would be best to review Part1 first, as this article continues on with adding authentication and login form to our application. Shortly, we will explore how to create a new article but for that we will need to have authentication working so that we can pass in our credentials when posting our new article.
In the next few weeks, Mauricio Dinarte (dinarcon on drupal.org) will be traveling to deliver his expertise to multiple Drupal events in Europe and America. He is on a mission to continue sharing the knowledge gained from many years as an active member of the Drupal community. Over the last few years he has presented numerous sessions and full day trainings at more than 18 Drupal camp— so you may have been at one of his presentations about Drupal basic concepts, twig recipes, or D8 migrations!
In addition to touring, Mauricio is very active in both local and global communities. He serves as a lead organizer of the Nicaraguan Drupal community where he has trained dozens of people, some of whom have made Drupal their career. He is also a member of the Drupal Global Training - Community Working Group and was recently added to Drupal's MAINTENANERS.txt as part of the mentoring team.
Here is where Mauricio will be presenting next:
- Synergy DrupalCamp on September 2-3.
- DrupalCamp Antwerp on September 8-9.
- Global training Day in Frankfurt on September 12.
- DrupalCon Vienna on September 25-29. Sign up for his Intro to Drupal workshop, check out his session on Twig Recipes, the Global Training Days BoF, and Sprint Mentor Orientation BoFs. Also, join him and other mentors at the Friday sprints.
- Barcelona meetup on October 3.
- Madrid meetup on October 5.
- West London meetup on October 16.
- BADCamp on October 18-21.
Driven by passion to teach others what he has learned, Mauricio's skills go way beyond coding and he has been on a mission to take part in as many International Drupal Cons and Camps as humanly possible. If you happen to be in any of the cities on Mauricio's itinerary, please say hello to him and shake his hand for me. He has touched the lives of many developers and would-be developers, and started some on a path to follow in his footsteps.
After consultation with the various initiative teams + core committers, we have created a DRAFT of proposed product goals for Drupal 8.5 (feature freeze: January 29, 2018) and Drupal 8.6+ (date TBD; ~late summer 2018).
The overall goals are divided into the following priorities:
Let's face it, it's been a crappy year in many ways. Internally and externally there are pressures that have made all of us think "what's the point?"
Instead of a world where we build and move forward together there is conflict, uncertainty, and so many why moments. From the macro to the micro, communities and ecosystems are struggling. The ideals of open source software often feel exploited, and the feeling of wonderment and discovery as we build together has been cast aside to something that feels very much like... well, work.
Drupal has not been immune. Like I need to tell you that.
For those of us that are optimists, and change makers, and idealists, and believers, nothing hits home the impact of our work than stories about how we use this code called Drupal to create impact. I think the world needs a little of that right now.
So, we have a team, we have energy and we are ready to shine the crap out of the brilliance of the people behind, in front, and to the side of Drupal.
I for one am looking forward to us injecting so much positivity into this community that even the chronic eye rollers won’t be able to help but give a slight smile.
A highlight of DrupalCon: the live code commit! Photo by Michael Cannon
The first thing we are working on is getting a way to start collecting stories. We might use a form. Or we might build an entire website. Just coz we can. So how about y’all give me a *whoop* *whoop* and start thinking about helping the Drupal Spotlight Committee unlock stories of Drupal impact from across the globe. It’s going to be fun.
Acquia Developer Center Blog: Building an Open Source Photo Gallery with Face and Object Recognition (Part 2)
In part one of this two-part series, I explained why my Hackathon team wanted to build an open source photo gallery in Drupal 8, and integrate it with Amazon S3, Rekognition, and Lambda for face and object recognition.
In this post, I'll detail how we built it, then how you can set it up, too!Tags: acquia drupal planetawsrekognitionmedia entitymedia gallerylambda
The web has no shortage of digital trends that will pop up on your radar, and one whose momentum has increased over the last couple years is decoupling. In simple terms, the concept of decoupling means separating the frontend of your website from the backend. This means the components of a site that a visitor sees and interacts with (menus, page content, widgets) are built and displayed by software running in the web browser. The backend software, running on the server, accepts requests from the frontend for these different page components and returns them as essentially raw data.
With this full separation of concerns, each half of the website can focus on what it does best; the backend focusing on business logic and retrieval of data, the frontend focusing on display and user experience.How Do We Achieve This?
To do this, it helps to have a powerful and flexible content management system, which doesn’t require lots of custom programming and reinvention of the wheel. This is where Drupal comes in. We’ve done this quite successfully with Drupal due to its robust and flexible API. Drupal 8 pushes this even further with its API first approach, and superior set of APIs.
Things like the built-in RESTful web services and superior content modeling tools do most of the work of building that backend system. Eventually the backend will communicate effortlessly with frontend systems and other applications and third-party service. This makes Drupal an effective content hub for distributing your content to any application that needs it.
When introducing anything new there are various factors to consider. A decoupled fronted can improve perceived performance and enhance interactivity. It can also do something very difficult with a fully baked content management system, where all rendering is handled by the backend. It enables developers and development teams to design and build a frontend almost completely independently from how the backend is developed. Your templating system, how CSS is built and managed, preferred methods for design components, all this can be treated like a separate project. Your designers and frontend developers don’t even have to have skills specific to the CMS you are using.
Life, of course, is never perfect. The main drawbacks become apparent when really thinking about how all this affects the way your site is built and managed. When using a CMS like Drupal, you start losing a lot of the key features that make it the tool it is. Can you use Drupal’s site building tools to, for example, change the order of fields displayed on a page? Things like that are now being hard-coded into the frontend. We also start losing some of the multilingual features, it plays less nice with metatags and other SEO features, and potentially increases the amount of work and skills needed to build your website. Those aren’t all unsolvable problems, but you’ll need to consider them when deciding where you are willing to devote the development time to building a decoupled site.Two Approaches
If you understand the concept of separating your frontend and backend, you’ll start seeing two approaches while doing your research. “Headless” Drupal, which just means a fully decoupled frontend. The other is “progressive” decoupling. “What the heck is that?” you might say. Progressive decoupling blurs the line between what the frontend and backend are doing, rather than fully decoupling the two.
Progressive decoupling starts with a traditional website approach, with no decoupling, and the backend doing most of the work to produce the web page. Then, individual components that are deemed more interactive or take longer to produce are handled by the frontend. This approach plays a little more nicely with tools already present in your CMS, and is easier to implement on any existing website.New Hotness Can Burn
Decoupling a website is a great way to solve some problems of the traditional website module. We certainly advocate it for projects suffering from those problems. But, as with all technology, make sure your use case has the need before forcing technology onto it. The decoupling approach can revolutionize your site visitor’s experience, but if forced to fit it can create new problems, increase development time, and inflate your costs.
A simple site, with few frontend performance problems, largely static content, and little need for things like user- or region-specific content, is not likely to need something like a decoupled frontend. My advice: Let your requirements always inform your solution. Technology is great at solving problems, but don’t let it create them by misapplying it to your project. If you want to talk about whether decoupled Drupal might be right for you, please contact us.Tagged with Comments