This year at Acquia Engage, the Commonwealth of Massachusetts launched Mass.gov on Drupal 8. Holly St. Clair, the Chief Digital Officer of the Commonwealth of Massachusetts, joined me during my keynote to share how Mass.gov is making constituents' interactions with the state fast, easy, meaningful, and "wicked awesome".
Since its founding, Acquia has been headquartered in Massachusetts, so it was very exciting to celebrate this milestone with the Mass.gov team.Constituents at the center
Today, 76% of constituents prefer to interact with their government online. Before Mass.gov switched to Drupal it struggled to provide a constituent-centric experience. For example, a student looking for information on tuition assistance on Mass.gov would have to sort through 7 different government websites before finding relevant information.
To better serve residents, businesses and visitors, the Mass.gov team took a data-driven approach. After analyzing site data, they discovered that 10% of the content serviced 89% of site traffic. This means that up to 90% of the content on Mass.gov was either redundant, out-of-date or distracting. The digital services team used this insight to develop a site architecture and content strategy that prioritized the needs and interests of citizens. In one year, the team at Mass.gov moved a 15-year-old site from a legacy CMS to Acquia and Drupal.
The team at Mass.gov also incorporated user testing into every step of the redesign process, including usability, information architecture and accessibility. In addition to inviting over 330,000 users to provide feedback on the pilot site, the Mass.gov team partnered with the Perkins School for the Blind to deliver meaningful accessibility that surpasses compliance requirements. This approach has earned Mass.gov a score of 80.7 on the System Usability Scale; 12 percent higher than the reported average.Open from the start
As an early adopter of Drupal 8, the Commonwealth of Massachusetts decided to open source the code that powers Mass.gov. Everyone can see the code that make Mass.gov work, point out problems, suggest improvements, or use the code for their own state. It's inspiring to see the Commonwealth of Massachusetts fully embraced the unique innovation and collaboration model inherent to open source. I wish more governments would do the sameCongratulations Mass.gov
The new Mass.gov is engaging, intuitive and above all else, wicked awesome. Congratulations Mass.gov!
As a Drupal professional you might have heard of Flood Table (user session management) but didn’t give much thought to it.
Having little theoretical knowledge of the core behavior of Drupal is not bad. So allow me to explain what user session management is all about? And how it can protect you from bot or malware. I will also share few #Tweaks that help you to understand how to Flood & Unblock user from your site.
Drupal 6 does not provide security from login attempt attack from Core until you enable login security contributed module. In Drupal 7, however, the core has an in-built functionality to …
It seems strange to me that the very first thing I need to do as the Drupal Association’s new Community Liaison is say something; given that the primary focus of the role is to listen to you, the Drupal Community.
Speaking at MoldCamp in Chișinău, Moldova. Used with permission of Drupal Moldova.
I’ve had the privilege of getting to know the Drupal Community over many years; from my first DrupalCamp in Leeds back in 2011, through volunteering at DrupalCon London, co-organising Drupal ScienceCamp in Cambridge and now being part of the team that organises the Mentored Sprints at DrupalCon and spending time as a member of the Community Working Group. It is a Community of wonderfully diverse and interesting individuals who I love working with.
Our hope with my role as Community Liaison is to continually improve both the Community’s understanding of the Drupal Association’s purpose and mission and especially the Drupal Association’s understanding of this diverse Community. We are here to support the Drupal Community and we do that best when we understand the Drupal Community, in all its forms.
In Antwerp for DupalCampBE, helping work on the future of DrupalCon Europe
I will be trying to get involved with as many groups that work with the Drupal Association as possible over the next few months, in an effort to help support their activities and our mutual understanding. I will also be a “go to person”, both online and in-person to find out things about the Drupal Association.
Of course, there is only one of me and the Drupal Association’s mission is quite tightly defined so there are things I won’t be doing in this role:
- I won’t be affecting the future technical direction of Drupal (other than through my continuing desire to keep up occasionally contributing to Drupal Core!).
- I’m here to facilitate and support, not enact change myself. I won’t be managing the Community, I’ll be helping the Community manage itself.
- I won’t be able to visit every Drupal event - it’s just not possible!
- Finally, I will be making a phased withdrawal from being a full member of the Community Working Group between now and the end of the year. While several Association board members have served on the CWG in the past without issue, we agreed that in this case, it made sense to avoid any conflicts that might arise because I was aware of incidents that had not been shared with other Association staff members. In my new role, I will meet regularly with CWG members to discuss different ways that the Association can support the Drupal Community; however, I will not be not be privy to any incident reports unless they are escalated to the Association by the CWG.
I will continue to find any excuse to ride my motorbike to Drupal events, though - I just can’t help that! (Current wish-list is to ride a Harley-Davidson to BADCamp - happy to hear about places to visit on the way!)
Idris (my motorbike) at Buzludzha, on the way to Drupalaton
I’m sure that the things I get involved in will evolve over time and I hope that you will help me to ensure we’re always giving the best support to the Drupal Community.
I know I will make mistakes along the way. I hope you can help me recognise them, own them and learn from them.
I’m here, and I’m listening. Let’s talk!
As part of ongoing efforts to improve Drupal’s community governance, the Drupal Community Working Group (CWG) was tasked by the Drupal Association and Dries Buytaert with defining next steps in the process. The CWG solicited volunteers from the Drupal community interested in governance, creating a group of community members to strategize how to involve as many people as possible. This new group then decided to hold public meetings to get feedback on next steps from the community.
The group facilitated a series of meetings in an effort to solicit feedback from a broad range of community members. Meetings were held in Slack, were offered at different times to support differences in timezones, and were facilitated by community members from different regions of the world, including North America, Latin America, and South Asia. The group tried to create a space for as many different people to share their voice as possible (for example, one meeting was held specifically to hear from community members who identify as women).
As noted within this blog post, the goal of these meetings was to solicit actionable feedback from the community and provide results back to project leadership (Dries Buytaert) and the Drupal Association. We strongly encourage community members to read the full transcripts of the meetings, which we have captured below, and provide additional context beyond this summary.
While we felt it was important to distill the meeting transcripts into summaries, we also made a conscious effort to avoid adding personal bias by misrepresenting or distorting the voice of the community members who participated in this activity. Each facilitator, most with a review and voting of priorities from the meeting attendees, defined a set of takeaways from their meeting. Our group has subsequently added our perspective to an executive summary, in which we identify patterns and priorities community members raised. The key takeaways and executive summary are found in subsequent sections.
Our group held a total of 13 meetings, with a total of 102 attendees, representing 56 unique participants (many attendees participated in multiple meetings). Efforts were made to encourage participation from the global community, but we did not request participant demographics to share in this post (which, in hindsight, would have been helpful).
We encourage community members to review the key takeaways and our executive summary below with an independent and critical eye. We also encourage community members to share their perspectives as we continue on this important journey of evolving our community governance.Executive Summary
The following points are grouped thematically, not by priority, though the members of this group agree that creation of a values statement is the highest priority:
- A community values statement is needed before making governance changes. This statement should come directly from leadership.
- Governance should evolve over time to remain sustainable. Consider a group of community members to regularly evaluate our policies, procedures, and governance structure.
- The Drupal Association, project leadership, and the community need to define the community, its membership, and its boundaries; at the very least for better communication and understanding of intentions and expectations. We need to define the communal roles for users, contributors, and maintainers.
- The Drupal Association, project leadership, and the community need to clearly define leadership, leadership positions, and the higher standard for those positions.
- The Drupal Association, project leadership, and the community need to clearly document governance structures, policies, and procedures so that anyone can find and understand them.
- The Community Working Group and the community need to improve the community code of conduct so that it is clearer and more actionable, particularly with regard to harassment. The Drupal Association should also review the DrupalCon Code of Conduct and its policies for enforcing it. Consider other tools that articulate the responsibilities of community participation like an etiquette guide, and conflict of interest policy.
- The Community Working Group and the community need to define the areas where community expectations exist (issue queues, camps, Slack, etc.)
- The Community Working Group and the Drupal Association needs to create well-defined processes and procedures for when members violate these expectations.
- Community matters should have escalation points that go to groups, not an individual. Those groups should contain a majority of community members.
- The community needs to improve its outreach to smaller local and regional communities around the world in a more structured and consistent way, providing resources that allow them to participate more fully in the global Drupal community with the same communal standards.
- The Drupal Association, project leadership, and the community should take greater responsibility in setting standards for events that carry the Drupal name.
- The community should develop a communication strategy around community documentation, dissemination, discoverability, organization, and ease of use for onboarding new community members.
- The community, project leadership, the Community Working Group, and the Drupal Association) should engage other communities and experts to be informed and identify best practices in governance.
As many of the items discussed in these meetings currently are the responsibility of the Drupal Association and/or project leadership, it is the recommendation of this group that they convene to discuss and process these takeaways, and then provide the community with a clear roadmap for what changes to governance they will take the lead on, and what role the community should play in helping to support those efforts. This roadmap should also be clear about what changes (if any) should be led by the community.Key Takeaways From Each Meeting
Nikki Stevens / October 2 / Link to full transcript / 11 attendees
- We need to define what “contributor” means when we talk about “contributor community”
- We need to figure out where the community is/what its boundaries are.
- We need a values statement
- That values statement should include D&I as part of it, not as an addendum.
Adam Bergstein / October 6 / Link to full transcript / 10 attendees
- It strikes me that having all the information in a single place that is easily digestible would help a lot. I would be tempted to suggest talking with Gabor about his Rocketship thing and if it could be adapted to hold all the info and ongoing issues.
- It's a personal bugbear of mine that the way we disseminate info across the project is a bit unorganised. Very hard to find anything.
- I'd love to see drupal.org/community be reworked and owned by a working group
- What people often seem to devalue is discoverability. Lots of info is out there if you know where to find it. how do you find the things you don’t know exist. Like meetings. Having them all in one place like that would rock.
- I'm seriously open to having a community communication strategy created and implemented. Just wanted you all to know that. I've asked the team at a minimum to create a blog section on d.o/community so there is one place for community news from groups like CWG.
- My gut feeling is that we need to surface the current state of governance somewhere in the most clear way possible - then use that as a base to evolve governance to make it clear how a group is “official”.
- One of my learnings in Vienna is that sometimes, people need the DA or Dries to just name a group so the world knows a group is official and so that group feel empowered. So if this group needs that done, let me know. I don't want to overstep or assume or get in the way … just offering help where I can.
- I feel that if more people are present here, more perspectives from the community can be heard. Post to general before meeting starts.
- So, do we need to define Community as wider than DA membership? Does it include businesses etc? Does it include clients? Does it include DA staff? Does it include that Dries guy?
- Maybe we need to invite people to the meeting? Maybe the WeeklyDrop should have a little announcement about each governance meeting? there's also /r/reddit. Are we reaching out to all our different channels?
David Hernandez / October 7 / Link to full transcript / 8 attendees
- Define values before governance.
- Define who we are as a community. What does membership mean?
- What is the scope of the community?
- How do you a define groups or individuals that will be involved/appointed?
David Hernandez / October 7/8 / Link to full transcript / 5 attendees
- Governance needs to evolve over time.
- What are other orgs doing for evolving governance? We should look beyond open source and/or developer-centric organizations.
- We should bring it outside help/consultants.
- There will be some who resent/want to resist input from an outsider/expert while it would lend legitimacy to the process for others. Working with community members is essential.
- Forming a core group of DA/community/consultant with formal oversight of talks would allay some fears about wasting time talking.
Mike Anello / October 9 / Link to full transcript / 2 attendees
- There have been discussions in open source communities at the Sustain conference about what makes projects sustainable. These could be good concepts to embrace when evolving our governance structure(s).
George DeMet / October 12 / Link to full transcript / 14 attendees
- While the community may include anyone who interacts with Drupal in any way, there is a distinction between those who just use Drupal and those who deliberately choose to be a part of it in some way.
- Understanding the rights and responsibilities that come with being part of the Drupal community is a responsibility that’s shared between various institutions but also relies on how we hold ourselves accountable to each other.
- Leaders help set expectations by setting and upholding rules in a way that reflects the shared values of the community.
- Building an inclusive and diverse community requires being able to understand and appreciate those with backgrounds and cultures different from our own.
- We should support participation by positive people who represent the values of the project. Note: In post-meeting discussion, it was agreed that this point failed to capture an important aspect of the conversation that occurred, which was that we should also not be afraid to reject individuals who persist in engaging in toxic behavior after having received warnings about the negative impact their behavior is having on others.
- We should avoid a focus on “punishment” for those whose behavior has a negative impact on others, but we need processes and procedures in place to identify and deal with trolls and other bad actors.
- Governance will need to change and evolve over time as the project and the people involved with it change.
David Hernandez / October 24 / Link to full transcript / 10 attendees
- CWG needs some path of escalation to a group, not an individual, and that group should be made up of community members.
- The group of community members should also be qualified to handle these matters. Subject matter experts, experience, etc.
- The community needs some mechanism by which to know certain problematic community members exist.
- Camp organizers need a way to vet speakers, volunteers, and attendees.
- If the DA allows camps to use their financing, the DA should take a greater role ensuring the camps follow a defined standard.
- There may be value in having a blacklist of known bad actors that is public so the community is aware.
- Camp organizers should ensure safety at their event, as a requirement, not nice to have.
- The DA should leverage the licensing of the Drupal trademark to ensure events that use the Drupal name are safe.
Adam Bergstein / October 25 / Link to full transcript / 6 attendees
- i have seen some etiquette guides that have example interactions.
- Giving people guidelines on how to give feedback, for example, in the issue queues needs to be right in people’s faces as they are giving that feedback. It helps them do a better job.
- When you flag someone's post in various ways carefully scripted messages get put up that are designed to encourage positive behavior.
- We could do more to help onboard new members and provide them with resources to help navigate the community. Other communities have clearer documentation for getting started: https://kubernetes.io/community/ and https://kubernetes.io/docs/tutorials/stateless-application/hello-minikub... I would respectfully suggest a section of d.o really isn't good enough. It needs to be the right messages in the right place throughout our infrastructure.
- Celebrate success (through recognition system?) when people improve. It's not enough just to tell people off all the time.
- Who in the community would perform this? it sounds like it would be self-monitored and we would just ask other community members to interact with specific interactions; enhancements to d.o and automation; allow the previous person to mark the reply as "helpful"; My understanding is that would mostly be dev workflow and issue queues.
- Drupal Association efforts may overlap with governance initiatives. Members should review https://www.drupal.org/drupalorg/roadmap/community-initiatives and https://www.drupal.org/drupalorg/roadmap
- The worst place on the internet /r/politics puts this above their comment forms "In general, be courteous to others. Attack ideas, not users. Personal insults, shill or troll accusations, hate speech, and other incivility violations can result in a permanent ban." Keep it short and simple.
- Regarding the issue queue commenting, don't forget the forums. they still exist. So it isn't just an issue commenting concern. gdo too. We should also include other community spaces like Slack, IRC, and in-person events.
Shyamala Rajaram/ October 26 / Link to Full Transcript / 4 attendees
- The DA or someone helping send experienced contributors to smaller events. Provide grants and scholarships to bring people to more Local events.
- Importance being placed on local communities and in-person connections.
Fatima Khalid / October 27 / Link to Full Transcript / 7 attendees
- There’s a fundamental need for a values statement. It’s critical that project leadership put out a strong statement of values. Ideally we’d like to see our values statement include more than one-word descriptors
- Discussed the equality vs equity comic: `https://images-cdn.9gag.com/photo/ajAerM1_700b_v2.jpg ` We need to define that equity is a value we want to see achieved - this the kind of thing we would like to see in a values statement. We want to see systemic barriers to participation removed. It would help to also define those barriers
- We want a governance policy:
- A statement of values (see above)
- Define the leaders and groups that uphold those values,
- Define the code of conduct that ensures those values are maintained
- Define the consequences for not meeting those values through code of conduct violations.
- We want a conflict of interest policy
- Mediation between two parties isn’t always appropriate when there is a big power differential between
- individuals or when the issue is problematic actions one person did towards one person or multiple people or actions that affected an entire community.
- Documentation of who handles what kind of issues
- We need a model for better communication.
- We want standards for what people can expect to be communicated, how, and when, because our communication processes are not well-known or well-defined.
Shyamala Rajaram/ October 28 / Link to Full Transcript / 6 attendees
- Inside out approach (instead of bottom up or top down) and is about looking at what's strong and what works in a community and how to get more of it.
- Need for Paid “Community Organiser” roles
- Toolkits as distributions and collaboration platforms as ways to have connection and sharing of information
- Common the Drupalers regularly conducting meetups for GTD and code sprints - starting meetup, code sprints with a slide on Drupal Governance, Code of conduct is a way to create awareness.
- Recognise that any volunteer tasks are difficult and imperfect. That we need to support volunteers at all times. know that the community cares and we do. More ways to recognize!
- Look to other processes in similar communities to identify strategies that could work for us" (edited)
Alanna Burke / October 30 / Link to Full Transcript / 6 attendees
- This was a meeting for women-identified participants only. There were 7 total participants.
- We need a clear values statement, which should include why this statement is necessary - why not having one is adversely affecting the community and what the purpose is.
- Instead of worrying about getting the whole community on board, the statement should reflect how things are going forward, full stop.
- We need a very clear CoC, which should include as much as we possibly can (look at examples like Geek Feminism) (most agreed to this, one did not) to be clear so there is no question what is not allowed and what the consequences will be. Use language like "includes but is not limited to"
- Implementation details to be worked out later (do you agree to CoC by creating a d.o account? downloading Drupal? etc)
- It is also important that the CoC not be worded in a way that it can be applied differently to different people. There should be tiered consequences appropriate for the action.
- We should have some kind of mechanism for changing and improving the governance systems we put in place, so that they don't become stale or malfunction when something comes up. We are a community that practices agile development, so why not extend the process to include our governance? It should be flexible & resilient.
- Reach out to other communities - what have they dealt with? How? What are gaps and strengths? There must be things that we can learn from other similar communities. Maybe we could start a team to work on this.
Kenny Abarca / November 03, 2017 / Link to Full Transcript / 15 attendees
- People agreed that Drupal CoC should apply on Drupal Camps and other Drupal events throughout the world.
- From the above, the conversation went on to discuss the approach and complexity of having it implemented globally and even criteria for defining what a Drupal event is.
- When organizing Drupal community events, people should be aware that there’s a set of standards that apply and they should commit or at least be aware of them before putting together an event.
- “Drupal governance should automatically apply to events containing the word Drupal”. Attendees discussed the approach.
- Involvement of CWG in matters related to Drupal Camps.
- Attendees discussed Dries ownership of the Drupal trademark and how governance would be applied under those circumstances.
- Defining guidelines to solve issues at Cons & Camps, who to contact and where to go.
- There should be some control or moderation over events that get created on groups.drupal.org
Listed alphabetically by Drupal.org username:
Hello, Drupal community! My name is Brooke Candelaria, and I’m excited to join the Drupal Association as your new conference director. This is a significant opportunity to support a smart, creative and ambitious community by helping to build event experiences that foster deep learning, meaningful connections, astounding ideas, new partnerships, project incubations and, of course, fun.
Working at the heart of the open source community is an honor and a privilege. This community knows how to collaborate exceedingly well. This community views ‘that can’t be done’ as a throw-down and will mobilize a sprint to do it. This community is glued together by shared purpose, and individually our members want to be part of something bigger than themselves. This is why we’re working hard to ensure that DrupalCon provides purposeful community-based experiences that you can’t get elsewhere.
I’ve been working in communications, PR and event management roles in the tech community for many years. Originally from upstate New York, I’ve worked in Boston, London, Austin and Houston. I worked on the LinuxWorld tradeshow at a time when open source was attracting attention from a large cross-section. Most recently, I’ve been serving the Python user community - also a very dedicated and enthusiastic base.
I’ve been living in Houston for a decade. It’s a vast and diverse city where we compensate for oppressive heat and hurricanes with our Southern hospitality, vibrant art scene and more than 10,000 restaurants. Oh, and did I mention the World Champion Houston Astros?
When not hosting guests at our AirBnB, I’m all about travel (especially international), volunteering, cooking and participating in local cultural events.
As part of the Decoupled Hard Problems series, in this fourth article, I'll discuss some of the challenges surrounding routing, custom paths and URL aliases in decoupled projects.Decoupled Routing
It's a Wednesday afternoon, and I'm using the time that Lullabot gives me for professional development to contribute to Contenta CMS. Someone asks me a question about routing for a React application with a decoupled Drupal back-end, so I decide to share it with the rest of the Contenta Slack community and a lengthy conversation ensues. I realize the many tendrils that begin when we separate our routes and paths from a more traditional Drupal setup, especially if we need to think about routing across multiple different consumers.
It's tempting to think about decoupled Drupal as a back-end plus a JS front-end application. In other words, a website. That is a common use case, probably the most common. Indeed, if we can restrict our decoupled architecture to a single consumer, we can move as many features as we want to the server side. Fantastic, now the editors who use the CMS have many routing tools at their disposal. They can, for instance, configure the URL alias for a given node. URL aliases allow content editors to specify the route of a web page that displays a piece of content. As Drupal developers, we tend to make no distinction between such pieces of content and the web page that Drupal automatically generates for it. That's because Drupal hides the complexity involved by making reasonable assumptions:
- It assumes that we need a web page for each node. Each of those has a route node/<nid> and they can have a custom route (aka URL alias).
- It means that it is okay to add presentation information in the content model. This makes it easy to tell the Twig template how to display the content (like field_position = 'top-left') in order to render it as the editor intended.
Unfortunately, when we are building a decoupled back-end, we cannot assume that our pieces of content will be displayed in a web page, even if our initial project is a website. That is because when we eventually need a second consumer, we will need to make amends all over the project to undo those assumptions before adding the new consumer.
Understand the hidden costs of decoupling in full. If those costs are acceptable—because we will take advantage of other aspects of decoupling—then a rigorous separation of concerns that assigns all the presentation logic to the front-end will pay off. It takes more time to implement, but it will be worth it when the time comes to add new consumers. While it may save time to use the server side to deal with routing on the assumption that our consumer will be a single website, as soon as a new consumer gets added those savings turn into losses. And, after all, if there is only a website, we should strongly consider a monolithic Drupal site.undefined
After working with Drupal or other modern CMSes, it's easy to assume that content editors can just input what they need for SEO purposes and all the front-ends will follow. But let's take a step back to think about routes:
- Routes are critical only for website clients. Native applications can also benefit from them, but they can function with just the resource IDs on the API.
- Routes are important for deep linking in web and native applications. When we use a web search engine in our phone and click a link, we expect the native app to open on that particular content if we have it installed. That is done by mapping the web URL to the app link.
- Links are a great way to share content. We want users to share links, and then let the appropriate app on the recipient's mobile device open if they have it installed.
It seems clear that even non-browser-centric applications care about the routes of our consumers. Luckily, Drupal considers the URL alias to be part of the content, so it's available to the consumers. But our consumers' routing needs may vary significantly.Routing From a Web Consumer
Let's imagine that a request to http://cms.contentacms.io/recipes/4-hour-lamb-stew hits our React application. The routing component will know that it needs to use the recipes resource and find the node that has a URL alias of /4-hour-lamb-stew. Contenta can handle this request with JSON API and Fieldable Path—both part of the distribution. With the response to that query, the React app builds all the components and displays the results to the user.
It is important to note the two implicit assumptions in this scenario. The first is that the inbound URL can be tokenized to extract the resource to query. In our case, the URL tells us that we want to query the /api/recipes resource to find a single item that has a particular URL alias. We know that because the URL in the React side contains /recipes/... What happens if the SEO team decides that the content should be under https://cms.contentacms.io/4-hour-lamb-stew? How will React know that it needs to query the /api/recipes resource and not /api/articles?
The second assumption is that there is a web page that represents a node. When we have a decoupled architecture, we cannot guarantee a one-to-one mapping between nodes and pages. Though it's common to have the content model aligned with the routes, let's explore an example where that's not the case. Suppose we have a seasonal page in our food magazine for the summer season (accessible under /summer). It consists of two recipes, and an article, and a manually selected hero image. We can build that easily in our React application by querying and rendering the content. However, everything—except for the data in the nodes and images—lives in the react application. Where does the editor go to change the route for that page?
On top of that, SEO will want it so that when a URL alias changes (either editorially or in the front-end code) a redirect occurs, so people using the old URL can still access the content. Note that a change in the node title could trigger a change in the URL alias via Pathauto. That is a problem even in the "easy" situation. If the alias changes to https://cms.contentacms.io/recipes/four-hour-stewed-lamb, we need our React application to still respond to the old https://cms.contentacms.io/recipes/4-hour-lamb-stew. The old link may have been shared in social networks, linked to from other sites, etc. The problem is that there is no recipe with an alias of /recipes/4-hour-lamb-stew anymore, so the Fieldable Path solution will not cover all cases.Possible Solutions
In monolithic Drupal, we'd solve the aforementioned SEO issue by using the Redirect module, which keeps track of old path aliases and can respond to them with a redirect to the new one. In decoupled Drupal, we can use that same module along with the new Decoupled Router module (created as part of the research for this article).
Pages—or visualizations—that comprise a disconnected selection of entities—our /summer page example—are hard to manage from the back-end. A possible solution could be to use JSON API to query the entities generated by Page Manager. Another possible solution would be to create a content type, with its corresponding resource, specific for that presentation in that particular consumer. Depending on how specific that content type is for the consumer, that will take us to the Back-end For Front-end pattern, which incurs other considerations and maintenance costs.
For the case where multiple consumers claim the same route but have that route resolve to different nodes, we can try the Contextual Aliases module.The Decoupled Router
Decoupled Router is an endpoint that receives a front-end path and tries to resolve it to an entity. To do so it follows as many redirects and URL aliases as necessary. In the example of /recipes/four-hour-stewed-lamb it would follow the redirect down to /recipes/4-hour-lamb-stew and resolve that URL alias to node:1234. The endpoint provides some interesting information about the route and the underlying entity.undefined
In a previous post, we discussed how multiple requests degrade performance significantly. With that in mind, making an extra request to resolve the redirects and aliases seems less attractive. We can solve this problem using the Subrequests module. Like we discussed in detail, we can use response tokens to combine several requests in one.
Imagine that we want to resolve /bread and display the title and image. However, we don’t know if /bread will resolve into an article or a recipe. We could use Subrequests to resolve the path and the JSON API entity in a single request.undefined
In the request above, we provide the path we want to resolve. Then we get the following response.undefined
To summarize, we can use Decoupled Router in combination with Subrequests to resolve multiple levels of redirects and URL aliases and get the JSON API data all in a single request. This solution is generic enough that it serves in almost all cases.Conclusion
Routing in decoupled applications becomes challenging because of three factors:
- Instead of one route, we have to think about (at least) two, one for the front-end and one for the back-end. We can mitigate this by keeping them both in sync.
- Multiple consumers may decide different routing patterns. This can be mitigated by reaching an agreement among consumers. Another alternative is to use Contextual Aliases along with Consumers. When we want back-end changes that only affect a particular consumer, we can use the Consumers module to make that dependency explicit. See the Consumer Image Styles module—explained in a previous article—for an example on how to do this.
- Some visualizations in some of the consumers don’t have a one-to-one correspondence with an entity in the data model. This is solved by introducing dedicated content types for those visualizations. That implies that we have access to both back-end and front-end. A custom resource based on Page Manager could work as well.
In general, whenever we need editorial control we'll have to turn to the back-end CMS. Unfortunately, the back-end affects all consumers, not just one. That may or may not be acceptable, depending on each project. We will need to make sure to consider this when thinking through paths and aliases on our next decoupled Drupal project.
Lucky for us, every project has constraints we can leverage. That is true even when working on the most challenging back-end of all—a public API that powers an unknown number of 3rd-party consumers. For the problem of routing we can leverage these constraints to use the mitigations listed above.
Hopefully, this article will give you some solutions for your Decoupled Drupal Hard Problems.
The issue of workforce diversity has been in the news a lot lately, and rightfully so. Diversity data is pretty dismal, particularly in the technology industry. Essentially, there is a long history of white males disproportionately holding leadership roles and minorities being immensely underrepresented. You already knew that though.