Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 4 hours 53 min ago

Flocon de toile | Freelance Drupal: Set up workflows with State machine on Drupal 8

30 November 2017 - 5:00am
We saw in a previous post how to set up a publishing process on Drupal 8 with the modules Content moderation and Workflows. We will address here a similar problematic but relying this time on the module State machine, module that will allow us to set up one or more business workflow on any Drupal entity. Note that the state machine module is one of the essential components of Drupal Commerce 2.x. Let's take a closer look at how state machines work.
Categories: Drupal

Drupal Association blog: I’m here, and I'm listening

30 November 2017 - 12:30am

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.

Anyway, until we do meet face to face at a Drupal event, I’m always available either on Twitter, on IRC as rachel_norfolk, drupal.slack.com or via my Drupal Contact Form.

I’m here, and I’m listening. Let’s talk!

Categories: Drupal

Community: Community Governance Meeting Takeaways

29 November 2017 - 2:05pm
Introduction

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
Facilitators

Listed alphabetically by Drupal.org username:

Categories: Drupal

Drupal Association blog: Please allow me to introduce myself

29 November 2017 - 9:01am

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.

I’m here to serve you, Drupal community. Feel free to ping me @brookecan or email me at brooke@association.drupal.org. Let’s get ready for Nashville 2018!

- htownbrooke

Categories: Drupal

Lullabot: Decoupled Drupal Hard Problems: Routing

29 November 2017 - 7:00am

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).

The Contenta CMS distribution already includes the Decoupled Router module for routing as we recommend this pattern for decoupled routing.

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.

Photo by William Bout on Unsplash.

Categories: Drupal

Mediacurrent: Diversity at Mediacurrent: A Path Forward

29 November 2017 - 6:53am

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.

Categories: Drupal

Colorfield: Drupal 8, React, Vue, JSON API and ES6 learning resources

29 November 2017 - 1:24am
Drupal 8, React, Vue, JSON API and ES6 learning resources christophe Wed, 29/11/2017 - 10:24

Start by Contenta or Reservoir and if you are still hungry, here are some clues.

Categories: Drupal

Tag1 Consulting: Background Image - A New Drupal 8 Module

28 November 2017 - 5:00pm
Introducing a new, easy to use, Drupal 8 module for background images: https://www.drupal.org/project/background_image If your site is designed around utilizing background images, then this module is for you! Whether you need a surgical implementation that only administrators/developers can implement or provide the ability to allow users to attach their own background images to entities, this module has you covered.Read more markcarver Tue, 11/28/2017 - 17:00
Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Drupal meetup with two great sessions

28 November 2017 - 4:51pm
In the middle of November, we organized a Drupal meetup. Meetup is a great way to connect web developers, designers, and other web enthusiasts. We were hosting two lecturers, David Ličen from Slovenia and Philipp Melab from Austria. In this blog post, you can learn, what they shared with us.   David Ličen, Slovenia: “Drupal point of Vue” The Drupal point of Vue session, led by David Ličen, was a very good introduction to the decoupled Drupal, where the web application and server are separated. Session attendees were acquainted with the basics of a very simple yet powerful JavaScript… READ MORE
Categories: Drupal

PreviousNext: Workflows: A new tool in the toolbox

28 November 2017 - 3:26pm
Share:

At DrupalSouth 2017, I presented a session on the new Workflows module, which just went stable in Drupal 8.4.0. Workflows was split out from content moderation as a separate module, and can be used independently to create custom workflows. In this presentation, I gave a demonstration of how to create a basic workflow for an issue tracker.

by Kim Pepper / 29 November 2017

Since 2011 we have had access to a content moderation tool in Drupal 7 in the form of Workbench Moderation. This module introduced the concept of Draft ➡ Review ➡ Published workflows, with different user roles having specific permissions to move from one state to the next.

Unfortunately, the underlying Drupal core revision API was not designed to deal with this, and there were some pretty crazy workarounds.

Content moderation has long been a key feature request for Drupal, and so effort was made to port Workbench Moderation across to Drupal 8. 

Content Moderation drove a lot of cleanup in Drupal core APIs, including proper support for forward revisions, and adding revision support to other content entities besides Content Types, such as Custom Blocks. More are on the way.

In Drupal 8.3, the Workflows module was split out of Content Moderation. Why you may ask? Well, because the Workflows module provides the state machine engine that Content Moderation relies on.

What is a State Machine?

A state machine defines a set of states and rules on how you can transition between those states.

A door state machine

In our simple example of a door, it can only be opened, closed or locked. However, you can't go directly from locked to open, you need to unlock it first.

Content Moderation Workflow Configuration

Content Moderation provides a set of Workflow states and transitions by default.

Content Moderation StatesContent Moderation Transitions

If we were to put this together in a state machine diagram, it would look like the following:

Content Moderation State Machine

From the above diagram, it becomes clear what the allowed transitions are between states.

So now Workflows has been configured with our Content Moderation states and transitions, what is left for Content Moderation to do?

What Does Content Moderation Do?

It turns out quite a lot. Remember, that Workflows only provides the state machine. It in no way prescribes how you should manage the current state of a particular entity.

Content Moderation provides:

  • Default Workflows configuration
  • A fairly complex WorkflowType plugin which works with the Revision API.
  • Storage for individual states on content entities
  • Configuration of which entity bundles (Content types, etc.) should have Content Moderation
  • A number of admin forms for configuring the workflows and how they apply
  • Permissions
Building an Issue Tracker

We want to build a very simple issue tracker for our example. The state machine diagram is the following:

Issue Tracker State Machine

That's the simple bits out of the way. Now, in order to build an issue tracker, we will need to replicate the rest what Content Moderation does!

Fortunately there is a module that can do most of the heavy lifting for us.

Workflows Field

“This module provides a field which allows you to store states on any content entity and ensure the states change according to transitions defined by the core workflows module.” 

Perfect! Let's download and install it.

Next we want to add a new Workflow. We can assign it a label of Issue Status and you'll see that we have a new Workflows Field option in the Workflow Type dropdown.

Add new workflow

We can then configure the desire Workflows states and transitions.

Issue StatesIssue Transitions

Thats the our Workflows configured. Now we need to create a new Issue content type to attach our workflow to. It's assumed you know how to create a content type already. If not, check out the User Guide.

Next, we need to add our Workflows Field to our Issue content type. Follow the usual steps to add a field, and in the drop down choose Workflows as the field type, and our previously created Issue Status workflow.

Add workflows fieldTest it out!

Now we can test our our workflow by creating a new Issue from the Content page. If everything was configured correctly, we should see a new field on the edit form for Status.

Issue status form

Given the transitions we defined in our workflow, we should only be allowed to see certain values in the drop-down, depending on the current state.

Testing workflow constraintsWhat next?

That's it for setting up and configuring a custom workflow using Workflows Field. Some next steps would be:

  • Add permissions for certain users (there's an issue for that #2904573 )
  • Add email notifications
How would you use the new Workflows API?

Let me know in the comments!

Tagged Workflows, Content Moderation

Posted by Kim Pepper
Technical Director

Dated 29 November 2017

Add new comment
Categories: Drupal

DrupalCon News: Calling all Drupalers!

28 November 2017 - 12:36pm

We want to hear your voice at DrupalCon. 

Categories: Drupal

Acro Media: Video: Recurring Billing, Now Baked Right In to Drupal Commerce 2

28 November 2017 - 11:06am

If you ever have need of timed or delayed payments, we have some good news: recurring billing (also known as subscriptions) is new and improved in Commerce 2. Check out this week's High5 episode and learn more!

What is recurring billing?

It's anything where we want to have a transaction happen after the initial time when a customer is on our site. That might be monthly or yearly, or it might be when you want the last half of the payment to go through in a couple days or a week.

How does it work?

It's not like we store pictures of everyone's credit cards and just keep applying charges to them. Instead, we store tokens, or references to the credit cards. This is much safer because it means that even if the site got hacked, no one would have access to your actual banking information. At no point does Commerce ever store your actual credit card.

If you're interested in reading more about tokenization, Wikipedia has a lot of good information on the subject. 

How is this different from Commerce 1?

We sort of had tokenization (a.k.a card on file) in Commerce 1. It was a contrib module and wasn't actually part of Commerce itself. Some payment gateways supported it, some didn't, some did but only partially… it was much more of an ad hoc thing.

Now, tokenization is built into Commerce, so any major payment gateway that gets set up and has the capacity to store tokens (which is most of them), will do so. You don't need to do anything special for your payment gateway to handle recurring billings. As long as we have that token, we can keep making charges to it until that token becomes invalid (i.e. the card gets cancelled).

It was actually a credit to Commerce 1 that it had tokenization at all. It's a complex thing. For instance, if a payment doesn't go through, do we have to cancel the subscription? Do we have to get the product back? Do we do that immediately, or give them a window of time to put in the new card? A lot of ecommerce setups just avoided that entirely, so it was definitely a strength of Commerce 1, and now it's really a strength of Commerce 2.

The bottom line

Recurring billing rocks, and is now built right into Commerce 2. 

Categories: Drupal

Jacob Rockowitz: Removing paid promotions from the Webform module and not asking for forgiveness

28 November 2017 - 9:00am

I have decided to remove paid promotions from the Webform module to focus on promoting the Drupal Community as a whole, the Drupal Association, and Webform module, I am also comfortable stating that I am not asking for forgiveness for my decision.

It is important that the Drupal community understand that I reached out to Lingotek and chose to promote their services within the Webform module's UX. Lingotek has made and continues to make amazing contributions to Drupal and the community. I want to thank them for allowing me to promote their services in such an experimental way.

Removing the paid promotion

I documented my original intentions in a blog post about promoting paid services within the Drupal community. I have come to fully agree with lslinnet's comment...

The Drupal community needs to explore ways to help support and fund core contributors and project maintainers. The goal of the paid promotion experiment was to see how everyone, including myself, felt about this concept.

The Discussion

MortenDK's (mortendk) very upset and direct tweet triggered the largest debate...

A few responses resonated with me, including one by kevinquillen and this one by tedbow:

Yes, the promotions of third-party services within a module's UX could open some floodgates that could create a horrendous user experience and first impression of Drupal. First impressions are very...Read More

Categories: Drupal

Acquia Developer Center Blog: Creating a Decoupled Drupal Application in 30 Minutes with Lightning, BLT, and DrupalVM

28 November 2017 - 8:43am

Acquia’s Professional Services team recently released an open-source application that demonstrates how Drupal and Node.js can easily be paired to create beautiful and functional decoupled applications. See how easy it was to create the Drupal backend using a combination of Acquia and Drupal community projects such as Lightning, BLT, and DrupalVM. This will allow you to follow the same process to rapidly create your own custom decoupled applications.

Tags: acquia drupal planet
Categories: Drupal

Promet Source: Drupal Commerce: Powering ALA.org on Giving Tuesday

28 November 2017 - 8:34am
Promet Source is proud to partner with the American Library Association (ALA) to deliver a flawless user experience with Drupal Commerce on Giving Tuesday, and every day of the year. Related: ALA | Empowering Association Fundraising with Drupal Commerce
Categories: Drupal

Drupal 8 Rules: #d8rules status update November 2017

28 November 2017 - 5:13am

Hi everyone,

it's been since March 2016 when we posted our last update on reaching Milestone 2 for porting Rules to Drupal 8. In the last 1.5 years, we haven't made significant progress because of limited resources available to contribute to the module. From an initiative perspective this is unfortunate, because we would like to fulfill the mission of providing a stable release for the Rules module in Drupal 8.

During DrupalCon Vienna we had various good talks but nothing confirmed yet. Our overall status summary is:

  • Milestones 1 & 2 have been completed

  • Milestone 3 is still pending

So we are at 70% of providing a stable release for Rules in Drupal 8

Fago can’t dedicate time required to develop the module further. What Rules is really missing at the moment is development capacity to help finish the last milestone. We have some early alpha releases out and are “only” missing 30% to complete development but to provide Rules’ capabilities to the ecosystem this investment would be really needed. If we look at the usage statistics, we can see that more than 5000 Drupal 8 sites already rely on Rules and there is a potential for almost 300,000 Drupal 7 sites with active Rules installations to migrate. It would be great to have all of them not rely on alphaware that doesn’t have an upgrade path or security coverage.

Various supporters already have helped us achieve 2 out of 3 milestones. Especially in the last weeks we have seen good activity in the Rules issue queue. Still, the Rules initiative won’t get much further without dedicated development capacity available. Even if we got more funding today, fago the current principal maintainer of the Rules module wouldn’t have enough capacity to do the work himself. So, if you are or if you know a good developer that could work on Rules, thanks for reaching out in the issue queue or contacting me directly via drupal.org.

We are hosting initiative meetings every second Thursday. Details and agenda can be found in our roadmap issue.

Best,

Josef / dasjo

 

Categories: Drupal

Valuebound: Drupal Commerce: Splitting a package into multiple shipments using Packer & PackerManager

28 November 2017 - 5:04am

Drupal 8 commerce shipping contributed module introduced an extendable and prioritized concept of Packer and PackerManager. Packer allows sites to automatically split an order into multiple shipments based on stock location, weight, dimensions, or some other criteria.

Let’s see what Packer and PackerManager do.

Packer and PackerManager
  1. Packer: Creates one or more shipments for a given order. We can create an end number of Commerce Packer class, which implements `Drupal\commerce_shipping\Packer\PackerInterface`. PackerInterface provides abstract methods:
    1. applies:
Categories: Drupal

InternetDevels: Drupal 8: multilingual from interface to content

28 November 2017 - 4:33am

In every corner of the world, your potential customers are waiting for your website to start “speaking” their language. And it’s easy to provide that with Drupal 8, a true polyglot among CMSs. Unmatched multilingual capacities are among Drupal 8’s most lucrative features that inspire website owners to choose “the great eight” — either to get a website or to upgrade their existing one. Well, it’s really hard to resist!

Read more
Categories: Drupal

Drupal Association blog: Drupal Association Board Meeting Announcement

27 November 2017 - 2:21pm

The Drupal Association board meeting and executive session moved from Wednesday, November 28 to Tuesday, December 12 at noon ET / 1700 GMT. The board meeting is virtual and open to the public and it will be followed by a closed executive session. Go here to join the board meeting. Below is the agenda for both the board meeting and executive session.

Board Meeting Agenda:
  • Approve 27 September, 2017 board meeting minutes
  • Vote: Bylaws Changes
  • Vote: Extend Community At-large board member seats to expire in November rather than January
  • Operational Update
  • Q&A from community
Executive Session
  • Executive Update
  • Board nomination committee discussion and vote in board members
  • Vote to approve Q3 financial statements
  • Discussion 2018 committees and meeting schedule
Categories: Drupal

DrupalCon News: Meet the new face of DrupalCon

27 November 2017 - 1:22pm

First introduced at the DrupalCon Baltimore closing session, we're very pleased to announce that the new brand for DrupalCon is now live. Take a look to see how the new brand evokes all aspects of the Drupal project and community - from the technical to the human.

Categories: Drupal

Pages