Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 6 hours 43 min ago

Community Working Group posts: Encouraging healthy conversations in the Drupal community

Mon, 01/25/2021 - 16:11

If you've spent any time in the Drupal community (specifically the issue queues, forums, and Drupal Slack workspace channels), you may have noticed that while the vast majority of discussions are positive, every now and then tempers flare up or less-than-helpful comments are posted. 

To continue to grow a healthy community, we all must work under the assumption that no one intentionally uses language to hurt others. Even so, despite our best efforts we sometimes still use words or phrases that are discouraging, harmful, or offensive to others. We are all human beings who make mistakes, but as members of a shared community, it’s our responsibility to lift each other up and encourage the best in each other. 

When observing negative behavior in the Drupal community, it can be difficult and/or uncomfortable to interject ourselves and find the right words to get conversations moving in a healthy direction. To address this, starting with an idea discussed at a Community Working Group (CWG) workshop at DrupalCon Seattle, the CWG Community Health team has been working on a communication initiative for the Drupal community. It consists of a series of de-escalation templates we have dubbed “Nudges”.

“Nudges”

The team has written five nudges that community members can use when they are faced with one of these uncomfortable situations in the Drupal community. We selected topics that we feel can have the most impact and are easy to understand. Each “nudge” provides context as to why the comment may be harmful and relevant links including our Code of Conduct and Values and Principles.

The “nudges” created to date are as follows:

Inclusive language - gendered terms

This discussion appears to include the use of gendered language in a comment. Gendered language can be harmful to our community because it can signal that we assume that people’s participation in the community is determined by gender.

The shift to gender-neutral language promotes gender equality. Please respect the pronouns that community members provide in their profiles.

For more information, please refer to Drupal’s Values and Principles about treating each other with dignity and respect.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Inclusive language - ableist terms

This discussion appears to include the use of ableist language in a comment. Ableist language can be harmful to our community because it can devalue challenges experienced by people with disabilities.

For more information, please refer to Drupal’s Values and Principles about treating each other with dignity and respect.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Gatekeeping knowledge

This discussion appears to discourage contribution from some participants by assuming a level of education or exposure to information. This can discourage folks that are new to a conversation from asking for help or getting involved. Consider providing the new contributor with links to help them learn the topic or concept.

For more information, please refer to Drupal’s Values and Principles #3 of fostering a learning environment: long-term contributors should be role models by admitting their own shortcomings and mistakes, being vulnerable, and by giving others the same respect that was once given to them. To keep learning read this article about not feigning surprise.

Principle #9 can also be useful here: be constructively honest, and relentlessly optimistic. You can be optimistic and supportive by giving suggestions for how to improve their contributions. By being helpful, you encourage people to accept feedback and act on it.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Cultural differences

This discussion appears to have escalated due to the inclusion of culturally-specific language. This may be harmful to our community as stereotypes can exclude or tokenize community members, devaluing their individual contribution and value. Please avoid language that imposes an identity on an individual or group.

We should be mindful that not all words and phrases translate to have the same meaning. Please be mindful that different cultures may appreciate different levels of directness in their communication styles and that may impact how words are presented or interpreted.

For more information, please refer to Drupal’s Values and Principles about treating each other with dignity and respect.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Escalating emotions

This discussion appears to include escalating emotions, creating the opportunity for miscommunication. The invested parties are encouraged to take a break from this discussion to help gain perspective. It is important to the community that all members are shown the appropriate amount of respect and openness when working together. Additionally, there are resources offered by the Drupal community to aid conflict resolution should those be needed.

For more information, please refer to Drupal’s Values and Principles of seeking first to understand, then to be understood. Assume best intentions of other contributors and suspend judgment until you have invested time to understand decisions, ask questions, and listen. Before expressing a disagreement, make a serious attempt to understand the reasons behind the decision.

This comment is provided as a service (currently being tested) of the Drupal Community Health Team as part of a project to encourage all participants to engage in positive discourse. For more information, please visit https://www.drupal.org/project/drupal_cwg/issues/3129687

Testing strategy

Over the next few months, members of the Community Health Team will be testing these "nudges” in Drupal.org issue queues, forums, and Drupal Slack workspace channels. For now, this will be done by copying and pasting the nudge text and formatting directly into an issue comment or Slack message. Our goal is to create a nudge widget that allows community members to insert one of the pre-written nudges via a token in issue queue and forum comments.

We feel that a gradual introduction to help prevent overuse of these nudges is necessary as overuse may produce its own sort of gatekeeping. This could lead to desensitization to the “nudge” initiative, negating our efforts. The CWG’s mission is to ensure a positive space that is inclusive to all of our members. 

These are early days for “nudges”. We are looking forward to hearing from other community members on how we can improve on this idea. We have been having weekly meetings for nudges and have been documenting everything we've been doing in the Community Working Group issue queue - let us know if you'd like to get involved!

Thanks

Current community members who have been working on this task include: AmyJune Hineline (volkswagenchick), Neil Drumm (drumm), George Matthes (watsonerror), Darren Oh, Donna Bungard, JD Flynn (dorficus), George DeMet, and Mike Anello (ultimike).
 

CTI Digital: [Video] Digital challenges faced by UK Universities

Mon, 01/25/2021 - 10:15

Newly engineered opportunities have opened the doors for Higher Education institutions to pioneer student, researcher, and funding recruitment. From deeper data applications to mass-scale live debates, the Higher Education sector is going through a digital transformation, with varying rates and approaches.

New data and accessibility regulations, as well as pressure on student recruitment from COVID-19, have required Higher Education institutions to accelerate these 'digital transformation roadmaps'.

DrupalEasy: Get more out of Address fields with Address Map (& Directions) Link module

Mon, 01/25/2021 - 10:00

If you're like most modern Drupal developers, you use the excellent Address module to collect country-aware address data on entities that require it. But, what do you do with the output of address data?

Granted, you can use the Geofield module ecosystem to turn that address data into embedded maps on your site, but if you're looking for a simpler solution, consider using the Address Map (& Directions) Link module - this module does one thing and does it well: it allows you to link the address to an external mapping service of your choice via additional settings on the default Address formatter.

So, the next time you use the Address field, consider this easy solution to improve the usefulness of that data!

OpenSense Labs: Can the Drupal and Angular partnership benefit you?

Fri, 01/22/2021 - 13:53
Can the Drupal and Angular partnership benefit you? Gurpreet Kaur Fri, 01/22/2021 - 18:23

The way websites are perceived has changed a lot recently. The audience has started demanding more and more from the web and web developers have to provide for all the demands. What this has resulted in is the transformation of websites for the better. 

The features that today’s sites are packed with were hardly even imaginable a decade ago. A website, a web application or a mobile application, all can do wonders for the users, satiating them with their experiences. 

So, when building a website, you have to be extremely considerate of the software you use and the technologies that accompany it as it is these that will make an astounding difference in your site’s overall appeal. 

On the same note, I will try to enlighten you about one such software and technology pair that has made websites as appealing as both their developers and users want them to be, and that is Drupal and Angular. So, let’s get right on it.

Drupal’s Essence 

In essence, Drupal is a provider of innovative digital experiences that set your websites apart from the ordinary. 

Being a content management software, Drupal can make websites that actually set standards for others to follow. Convenient content authoring, impeccable performance and outstanding security are some of Drupal’s most renowned features. Whether you want flexibility and modularity or integrated digital frameworks, Drupal can ease your needs. 

With multiple add-ons;
With numerous modules; 
With several themes; 
With various distributions; 
And with multitudinal mix and match options, Drupal’s core abilities are magnified by a landslide. 

Now, the Drupal 9 has paved the way for an even more delightful web building experience. Known to be the easiest upgrade in over a decade, it is going to take Drupal 8’s innovative streak even further. Here’s everything you will want to know about Drupal 9.

NBC, MTV UK, Amnesty International and University of Oxford are some of the elite clientele of Drupal and their websites are a true epitome of Drupal’s abilities. 

Make something amazing, for anyone”  - a motto of a kind should have been pretty self explanatory of Drupal’s essence, but it has acquired bragging rights and rightfully so. Hence, a little more elaborated boasting was mandatory.  

Taking the Headless Route 

Drupal’s abilities, features and all that it encompasses has made it one of a kind. At the top of the list of its unique abilities is its ‘headlessness’. I know this is going to sound strange, but it is a fact and a very beneficial one at that. 

Like I mentioned above, Drupal has all the features to make a web experience up and running and quite smoothly too. Having so many modules, themes and distributions, web builders would not find any need to look for additional features in their site. The entire web project would be placed inside Drupal and it would be entirely responsible for all of the project's needs. 

However, sometimes developers want to try more and Drupal lets them. It essentially removes its head, that is the presentation layer, to make room for a different one, that is other frontend technologies, and lets the developers only utilise it for its body, that would be its backend capabilities. So, in a truly Headless Drupal architecture, you would only use Drupal as a content repository and nothing else. This is also known as Decoupled Drupal, since you are going to be separating the couple, the frontend from the backend. 

When you go headless, you will be parting with Drupal’s frontend capabilities, but the separation does not have to be final. Decoupled Drupal comes with two options for you to choose from; 

  • One is the fully decoupled Drupal or the Headless Drupal. This completely segregates the two ends of a web project. Drupal takes command of the backend, while other frontend technologies, like JavaScript take hold of the frontend; both being connected by an API for the transmission of the information. 
  • Then there is the less final, progressively decoupled Drupal. In this architecture, you are still left with some of Drupal’s frontend capabilities. This means you can combine other frontend technologies to work with Drupal and get the most for your website, without losing Drupal out-of-the-box capabilities.  
Do you benefit from the going Headless?

Drupal has numerous benefits when you use it as a whole for building projects from the ground up; however, the decoupled Drupal comes with a tad more advantages. That is why it is becoming a vogue today, with several traditional Drupal sites converting themselves into the decoupled ones. 

So, yes, you will indeed benefit from taking the headless route. 

Aids in publishing on multiple platforms 

Going Headless makes it very easy to publish content on multiple platforms, be it your primary website, social media handles, intra sites or even print and media. The write once, publish everywhere features lets you capitalise all the IOT devices and publish on them.

Aids in maximising user experience 

The growth of your online business is directly proportional to the user experience you provide. The better the UX, the higher the conversions. UX is further dependent on your site’s performance. Having two separate ends enhances it, the request time is reduced with a client-side server and your site would be nothing but speedy.

Aids in making your team independent 

When you have a separated front and backend, that means you have the power to work faster. The frontend developers will only be focused on the user interface and the backend developers will only need to worry about those needs. Your teams can even make changes on their respective layers without having to worry about impeding the work of the other. All of this results in faster work speed and increased efficiency.  

Aids in enhancing creativity 

Drupal is a robust software, yet it can be stuff sometimes. You have to follow its guidelines and set standards or the work won’t get done. This hampers the development team’s creative flair. However, by adopting other, more flexible, frontend technologies through decoupling, you can let your creativity run free. 

Aids in faster upgrades 

Headless Drupal separation of concerns makes it simple to upgrade without impeding on your site’s current workings. It also gives you the opportunity to test on a dummy web service, which acts as a mockup, aiding you further in making revisions to your site.

Aids in taking advantage of JavaScript 

The final and probably the most compelling advantage of decoupled Drupal is the use of JavaScript. JS has the ability to make websites extremely interactive, with features like destructed assignment and arrow functions in the latest version. Since site interactivity with the user has taken precedence over anything else, decoupling has become more of a need. React, Angular and Vue are some of the most eminent JS frameworks that are used when going Headless. 

To know everything about headless Drupal and its suitability, read our blog, “When to move from monolithic to decoupled Drupal architecture.”

In Comes AngularJS

Now that we have discussed one part of the title, let’s move on to the second, which is AngularJS. You may know that a major reason behind going headless is the fact that it allows the user to incorporate other frontend technologies into Drupal and get the desired web building experience and the product as well. AngularJS is one such technology. Let’s get into its details.

What is AngularJS?

We ended the headless Drupal discussion at JavaScript, so it is only wise to begin the new one with JavaScript as well. AngularJS operates on JavaScript, being an open-source front-end web framework. It helps you create dynamic web pages through its structured framework. 

HTML’s template language is integral when building web projects. However, there is one problem with its use. HTML has proven its potential for static documents, however, when dynamic views come to play, it becomes lacklustre and chaotic. Now, in such a scenario, AngularJS comes in to save you. It allows you to extend the HTML vocabulary for your project, paving way for your developers to work in an environment that is expressive, readable and fast to develop. 

There aren’t many frameworks that have the ability to solve the HTML conundrum, what they do instead is abstract away HTML, CSS and JS or they might manipulate the DOM. covering up the problem is not really a solution and AngularJS provides an extension of HTML, making it worthy for dynamic views. 

The crowning jewel of AngularJS is its ability to adapt. It can easily be modified or replaced to make it suitable for any of your development needs. Whatever your workflow and feature require, AngularJS has the ability to provide. The fact that it is completely extensive and compatible with other libraries. 

Talking about the technologies Angular belongs to, it is part of the so-called MEAN stack. The MEAN refers to MangoDB, Express, Angular and Node.js. The combination of these four accounts for a firm ecosystem that is also backed by full-stack developers.

Let's look at AngularJS’ market share to understand its prominence even more. 

(a)

 

(b)

 

(c) | Source: SimilarTech

All of these numbers are pretty self-explanatory of AngularJS’ popularity in the market. 

What are the benefits?

Built in 2010 by Google, which is to this date responsible for its maintenance along with an entire community of developers and companies, AngularJS is quite a technology to utilise for your project’s development. It’s numerous benefits will make you believe me even more. 

Angular is flexible 

Angular by nature, or maybe its build, is extremely lightweight and concise. What this translates into is a working environment that is so extensible that you would be able to create things you never deemed possible. 

Angular uses directives 

Like we discussed above, Angular is unique because it is able to extend HTML. And this is possible because of Directives. Through these, special behaviours are assigned to the Document Object Model, which in turn enables your developers and engineers to use HTML and create dynamic and rich content. 

Angular binds your data two ways 

It is a known fact that Angular gives your developers the power of developing at a much faster rate. Multiple views, asynchronous technique, SEO friendly development are amongst a few of the immensely impressive features of Angular. And all these are possible because it works on the MVC architecture.  Because the Model-View-Controller framework synchronises the Model and the View, so when one changes, the other changes automatically. And work gets done faster. 

Angular injects dependencies 

When developers code, all the different pieces of that code have to interact with each other. This interaction also means that they are going to be affected by each other;s changes. This scenario is defined as dependencies. 

AngularJS solves this issue of dependencies in code simply by decoupling them using injectors. A dependency injector has the ability of making individual components easy to manage, test and reuse; maybe even more than before. 

Angular aids testing 

Lastly, AngularJS also makes unit testing pretty convenient for you. It has a built-in setup that makes testing the code much simpler and faster for your developers. 

The things you can do using AngularJS are much more advanced than Drupal’s frontend capabilities. So, combining the two is going to be a partnership that will make work wonders for your web project. 

The best of both worlds

Up until now we have been talking Decoupled Drupal and Angular individually and they have certainly been impressive enough. Both Drupal and Angular are equipped to build projects that will cater to any and all of your needs.

When paired together, they seem to be packing a punch. Your web projects will be able to accomplish so much more. Let’s have a look at some of the most intriguing features.  

Performance that will leave you spellbound 

A site’s performance is what sets it apart from others, it is what will keep your visitors scrolling through your pages and finally clicking on that coveted Buy Now tab. So, how do Drupal and Angular together help in improving your site’s performance?

If I talk about Drupal, it provides functionality in tons. Just working with drupal can make your site perform impeccably. Now, if you combine the Angular technology with it, you will end up with a performance that would be even better. That is because you will be able to offload business logic to AngularJS as it is client-side, you would not be able to do it completely, but even some part of the offload can be extremely effective. 

Furthermore, when you go Headless and take up Angular, you would use the latter for theming and presentation, while Drupal would only be responsible for the backend data source. This would enable you to move the display logic to the client-side, helping you in streamlining the backend. The resultant site is going to end up as fast as The Flash himself, for lack of a better metaphor.

Coding that will free up your developers 

When you use Drupal to build a regular, basic website, you would not need to write a lot of code and the development work would also be quite minimal. Yes, a basic Drupal site would not be feature packed and that is where AngularJS would enter. 

AngularJS will take an ordinary Drupal site and make it extraordinary, so to speak. Angular can make sites more interactive, more dynamic and richer in experience, and complex coding would not be a prominent part of this picture. 

By using directives, HTML, plain objects and other features, the JS framework requires very little effort from your developers in terms of coding. Despite the minimal efforts, you will still end up with the interactive pages that were only possible to get with a complete JS coding. 

Logic that will clean up your code structure 

You remember we talked about the MVC architecture in the previous section? I would have to be redundant and mention it again since it serves a lot of benefits when going headless. 

The Model-View-Controller architecture works on a principle that essentially segregates itself into three parts; 

Business logic;
Controller logic; 
And model logic. 

This results in a separation of your application logic from the user interface. And why is that essential? Because it aids in making the code structure cleaner, without much redundancy and more clarity. 

Imagine if one of your developers has to leave in the middle of your project. This could become devastating for your project, but an isolated code would make it extremely convenient for any other developer to pick up the left pieces and continue with the same effectiveness as before. 

AngularJS and Drupal also work well together because the MVC framework helps in eliminating a lot of backend logic from Drupal. Consequently, your site will turn out to be both extremely lightweight and efficient.

Security that will keep you shielded

Both Drupal and Angular are backed by a massive community. This means that there all the security features are always under scrutiny and the chance of things going sideways is slim to none. 

Add to this the fact the Drupal’s security protocol, if followed to the T will provide you an assurance of safety that not many CMSs can. Further adding to this, the combination of Headless Drupal and AngularJS will enable an extra layer of security to your site because there won't be any direct server-side interaction, the browser will only communicate with AngularJS.

The result of all of this would be that your site will become immune to malicious code that the notorious hackers are known to inject in your databases. And all would be well in the web world.

Everything about leveraging decoupled Drupal and different frontend technologies can be accessed here

Summing Up 

When decoupling is considered, tapping into the available frontend technologies is the paramount concern. JavaScript is most definitely at the forefront of the developers’ mind for the presentation layers. 

Angular is one of the flag bearers of JavaScript, and Drupal is a prominent name in the CMS world. Be it dynamic sites or interactive interfaces, the possibilities of with the combination of these two powerhouses. So, when are you taking them up?

blog banner blog image Drupal Angular Decoupled Drupal Headless Drupal Frontend technologies Blog Type Articles Is it a good read ? On

Golems GABB: Updating Drupal websites: benefits and options

Fri, 01/22/2021 - 13:29
Updating Drupal websites: benefits and options Editor Fri, 01/22/2021 - 14:29

It’s no secret that all software products work significantly better when updated. Drupal is no exception. All websites built with the Drupal CMS benefit immensely from the regular updates of the Drupal core, modules, and themes. On the contrary, ignoring these procedures can bring trouble.

Discover more about the importance of and the options for updating Drupal websites from today’s blog post by the Golems team of Drupal experts.

What are Drupal updates compared to upgrades?

While speaking about Drupal updates, we need to make the terminology clear. You will often hear both the terms “updates” and “upgrades.” While they are sometimes used interchangeably, the standard and the most common practice is to:

DrupalCon News: Submit your interest to serve on a DrupalCon committee

Thu, 01/21/2021 - 21:04

DrupalCon is enhanced through the time and talent contributed by volunteers, and we offer a number of opportunities to influence and support the design and implementation of the event. We’ve put together an overview of the volunteer opportunities for your review and consideration. If one or more of the roles aligns with your interests and availability, submit your interest form.

Drupal.org blog: A Non-Code Community Contribution Opportunity: Become a Site Moderator

Thu, 01/21/2021 - 19:28

Our community is in need of additional drupal.org site moderators (formerly "webmasters") to assist day-to-day site moderation tasks.

Over the past few years, the number of active site moderators in the Drupal.org site moderators queue https://www.drupal.org/project/issues/site_moderators?categories=All has decreased significantly. Recognizing that this isn't a sustainable situation, the current active site moderators have embarked on an effort to recruit new volunteers.

Responsibilities of a site moderator

Site moderators are primarily tasked with responding to issues in the Drupal.org site moderators issue queue and the ongoing on-boarding of new community members. These tasks include:

  • Responding to issues in the Drupal.org site moderators issue queue.
  • Reviewing posts flagged as spam, deleting spam, and blocking users who post spam on Drupal.org web sites.
  • Confirming new Drupal.org users.
  • Responding to reports of projects posted on Drupal.org that do not meet community norms.
  • Other related tasks as described on the Moderation and maintenance documentation page https://www.drupal.org/drupalorg/docs/maintenance.
Process to become a site moderator

In order to become a site moderator, there are a few easy steps:

  1. Familiarize yourself with site moderator responsibilities via the project https://www.drupal.org/project/site_moderators and the Site Moderator role description. https://www.drupal.org/community/contributor-guide/role/drupalorg-site_moderators
  2. Announce your intent to start participating in the #drupalorg-site-moderators channel in the Drupal Slack workspace.
  3. Begin participating in site moderator issues https://www.drupal.org/project/issues/site_moderators?categories=All - it is recommended that at first you ask questions and propose solutions to issues in a way that current site moderators can provide useful feedback.
  4. Once you have participated in the site moderator issue queue enough that you feel that you have a good handle on its various processes, open a new issue in the queue asking for the Drupal.org "site administrator" role. It is highly recommended that you are active in the issue queue and Drupal Slack workspace channel, and have interacted with the other active site maintainers before applying for this elevated role.
Why donate your time to Drupal?

If you've made it this far, then the obvious question is "why should I become a Drupal.org site moderator?" Develop and exercise your people-skills while helping the Drupal community become a more sustainable, welcoming, friendly, and productive place. Regardless if you’re a developer, becoming a site moderator is a pretty straightforward way to build those skills.

In addition:

  • You'll work with other site moderators around the globe, building up your Drupal community network.
  • You'll have the opportunity to help nurture new community members in a meaningful way.
  • You'll have the opportunity to earn contribution credits.
  • Having the "site moderator" role is a position of leadership in our community. https://www.drupal.org/about/values-and-principles#choose-to-lead
  • If you or your organization uses Drupal and is looking for a way to give back, this is a small thing that will have a big impact.
First step

Interested? If you have any questions, pop into the Drupal Slack workspace #drupalorg channel and ask away. When you're ready, start with steps 1 and 2 above and start your journey!

Thanks to Donna Bungard (dbungard https://www.drupal.org/u/dbungard), Darren Oh (https://www.drupal.org/u/darren-oh), Jordana Fung ( jordana https://www.drupal.org/u/jordana), and Mike Anello (ultimike https://www.drupal.org/u/ultimike) for assisting with this blog post. 

Innoraft Drupal Blogs: UNDERSTANDING THE MOBILE APP DEVELOPMENT LIFECYCLE

Thu, 01/21/2021 - 18:56
UNDERSTANDING THE MOBILE APP DEVELOPMENT LIFECYCLE

Mobile app development is not rocket science in today's day and age. Making a good mobile application, however, is a process that requires a very lengthy pre-planning process. It could be as simple as launching the IDE, putting a few items together, doing a quick round of screening, and uploading it to an App Store, all achieved in half a day's work, to create your mobile application. Or you can render it a deeply engaged process involving comprehensive up-front design, QA testing on a range of platforms, accessibility testing, a complete beta lifecycle, and then various forms of deploying it. Your vision is given form by the direction you chose.

souvik Thu, 01/21/2021 - 23:26 Drupal Planet Drupal 7 Drupal 8 user friendly website Web Design website development services web developers

Nonprofit Drupal posts: January Drupal for Nonprofits Chat

Thu, 01/21/2021 - 16:25

Our normally scheduled call to chat about all things Drupal and nonprofits will happen TODAY, Thursday, January 21, at 1pm ET / 10am PT. (Convert to your local time zone.)

No set agenda this month, so we'll have plenty of time to discuss whatever Drupal-related thoughts are on your mind. 

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes

This free call is sponsored by NTEN.org and open to everyone.

View notes of previous months' calls.

Mediacurrent: Drupal Paragraphs: The Bridge to Better Content Architecture

Thu, 01/21/2021 - 14:35
Problem: The Power (and Pitfall) of Paragraphs

With great content modeling powers comes great responsibility for Drupal developers. 

While building a website, you may face the challenge of creating multiple paragraphs without much reuse. This can contribute to a poor content architecture that will burden you for the lifetime of your application. This issue can come about when a developer is building out paragraphs and decides to generate multiple paragraphs with similar fields or new fields that perform the same functionality as other fields. 

For example, let’s say a developer is tasked with building a normal Text Paragraph which is just one textarea field, which is simple enough. Now, let’s say a client comes to that developer and ask if the Text Paragraph could have a header field, and a subheader field. Usually, a developer might decide to just create a new paragraph, maybe call it a Card Paragraph, that has a new header field, subheader field, and a new body field. Well, what if you could just reuse the body field from the Text Paragraph? There is a way to do that by using Form Displays and the default Paragraphs reference field widget. Of course, the example above is simple, but there might be better cases which will be explained below.

Solution: Reuse Paragraphs and Form Displays

Mediacurrent’s Rain CMS  is an open source project that comes bundled with ready-to-use content types and paragraphs. One of those is the Card paragraph. The Card paragraph by itself might just have a title, media, body, and layout field. This is pretty useful as its own componentized item that can be reused on other components. Now let’s say you have another paragraph that is called a Breaker, which essentially is almost like a Card Paragraph but might have some variation. This Breaker paragraph might reuse the same title, body, but also has an extra field called right body for any text that might need to be put on the right column.

The way one can keep reusing the Card paragraphs, with other paragraphs that get created in the future is to add more fields onto the Card paragraph itself.

As displayed above we have a ton of fields added on to the Card Paragraph. One might say that why are you doing this, wouldn’t all these fields get displayed on the frontend. Technically yes at first, but there is a way to limit what fields get displayed on the Card paragraph itself and then a step on getting the Breaker paragraph to utilize the same fields coming from the Card paragraph.

This method is using what’s called view modes in the Form Display configuration. What you want to do is go into Managed Form Display in the CMS for the Card paragraph that you just created and take a look at what displays are available.

As you can see above we already have some displays created in the Rain distribution we are using. We have the Default, Breaker, Carousel, Column, Card Compound, and Overlay Breaker. These are all Form Display’s which are used for other Paragraph variations. 

Creating a new display is easy; you want to go to the bottom under the Default view mode and hit Custom Display Settings, which should drop down the above selection. As displayed in the screenshot there are some that are enabled and disabled. You can create a new one by clicking Managed form modes.

Now that we sidetracked a bit and explained how view modes work and how they are created, let's dive back in and talk about how you can now create this Card variation paragraph which is called the Breaker. Since we have a display already enabled for the Breaker what you want to do is click on the Breaker and see what fields are enabled by default.

 

Shown above this has the title, body, and the new body right field which is technically still part of the Card Paragraph, but just using a different form display. If you compare this display with the default display you can see that different fields are enabled and disabled, which allows for flexibility for reusability. Now that we see that the fields needed for the Breaker have been created or enabled, let’s go create the Breaker paragraph.

We then add a description and say that this is a breaker that will have content with two columns. If you remember above we have a body field and a body right, this is used to create these two columns.

When creating your Breaker paragraph make sure to add all the fields that are unique to this breaker like Line Break, and Show Two Columns which have specific functionality for the Breaker, but you also want to create a Paragraph reference field called Card which will allow you to reference a Card.

So how do you get it so this Card field shows the fields that you want from the Card Paragraph? Well, that’s why we worked on using the view mode on the Form Display for the Card Paragraph. What you want to do is the following.

Under the Breaker paragraph go to the Managed Form Display. Then under the Card field, you can use any widget that has the Form Display mode available. This will allow you to use the Form Display mode option in the widget to target the right display mode you want to use from the Card. Select the Breaker display mode.

Once this is done, hit save.  Now what you should expect is that whenever you go to create a breaker and you use the card field it should show the fields that are specified on the Card Breaker view mode.

Building Paragraphs the Smart Way 

Now whenever you as a developer get tasked with building out a paragraph, make sure to ask yourself: What can I do to reuse fields and displays as much as possible? I hope this guide will help you to make smart decisions for a better content architecture going forward.

Innoraft Drupal Blogs: ENTERPRISE WEBSITE DEVELOPMENT

Thu, 01/21/2021 - 14:11
ENTERPRISE WEBSITE DEVELOPMENT

It's essential that companies have a presence online in the digitalised global economy. Enterprise web development is thus, naturally, an important opportunity for a company to achieve online exposure and enter a broader audience. Web creation for business is essentially the method of creating a company-level website.
Enterprises run the gamut from mid-sized to large-scale enterprises and institutions (governmental, for-profit or non-profit) to organizations and collectives (healthcare, education, philanthropy, or any other group with a common purpose or similar goals).

souvik Thu, 01/21/2021 - 18:41 Drupal Planet Drupal 7 Drupal 8 user friendly website Web Design website development services web developers

Dropsolid: DrupalCon 2020, the aftermath

Thu, 01/21/2021 - 14:08
21 Jan Els Knevels

“Tell me and I forget, teach me and I may remember, involve me and I learn.” Wise words of a man whose head still appears on the 100 dollar bills in America. With Benjamin Franklin’s thoughts in the back of our minds, Dropsolid heads to DrupalCon every year. With one primary goal: learning. Learning from and teaching to a fantastic Drupal community. Because only by knowing what is really alive in this community we can make Dropsolid the most successful Martech company, with a focus on Open DXP solutions with Drupal at its core. So we put our money where our mouth is and we went out to investigate. For several years now we’ve been launching a survey in which we donate 15 minutes of open source contribution time for every completed form to develop Drupal even further. But we also exchanged ideas with like minded visitors and we conducted interesting follow-up conversations with listeners of all our sessions. What we’ve learned from this? We’ll tell you all about it below!

 

         

What keeps a Drupal developer up at night?

 

Jamstack & Drupal, match made in heaven?

Developers, in our survey but also at DrupalCon, have put a huge focus on the integration between the new JAMstack world (Javascript, APIs & Markup) and Drupal itself. Drupal allows to push results directly to the browser. More and more we also see that components, built in React, Vue.js, Ember or Angular are taking over some of the responsibility here. To such an extent even that the Drupal core team has decided to build a react component for the menu in Drupal. In addition, concepts such as keeping Drupal 7, 8 and 9 up to date have also been discussed on several occasions with even the outlook of automatic updates being hugely beneficial!

 

Data is the new gold

Some developers are convinced that data is the new gold and this of course raises the concept of data ownership and the fear of being dependent on external vendors. There were a number of discussions at DrupalCon about how Drupal can deal with this and what standard privacy protection measures Drupal could take with new installations.

 

Rising star: DXP

What did come as a big surprise is that developers are not yet completely familiar with the concept of DXP. More than half of our surveyed developers said they had never heard of it. At Dropsolid, Drupal is a permanent pillar of content management in our DXP projects, and it has become our mission to put DXPs on the map!

 

Opportunities for Drupal developers in the future

From our research, the many conversations and responses to our sessions at DrupalCon, we noted that developers in general are less involved in the end-user experience and customer journeys of (potential) customers. They have a limited view on the different platforms a brand uses to connect with its customers and how exactly that happens. Not necessarily a problem? But also not that unimportant! Keeping the end goal in mind is important for every position in a company. The communication between the different departments runs smoother when this is clear to everyone, the noses are in the same direction and everyone speaks the same language. Just think of the gap between business and development: how do you get a concept really sharp without all departments having a clear view of the core objective?

It could be the perfect time, for you as a Drupal developer, to expand your horizon. If you, as a developer, have an overview of the end user's goal, show a healthy interest in the optimal customer experience for your client and understand the needs of this new market? Then you are already one giant step ahead. It’s precisely these profiles that fill the gaps in the current market and make big career opportunities possible.

 

3 things business owners can learn from this 
  1. A good connection between the different departments, in particular business and IT, is priceless and an absolute must for every company.
  2. The balance between customer experience and operational excellence has to be in harmony.
  3. A lot of agency owners are worried about the previously listed roadblocks, and yet there is an obvious solution that is emerging: a Digital Experience Platform (DXP).
DXP to the rescue

Introducing a DXP into your business offers solutions for many problems. But what exactly does it provide? We’ll dive in deeper below.

Advantage 1: your team works closer together

A DXP brings teams closer to each other because everyone is working on one and the same framework. The end user is put in the center and the needs, wishes and goals of each individual are fulfilled this way. Doing so, companies can easily create a safe, maintenance-friendly and digital environment that offers an excellent experience to the visitor. The various employees, both developers and marketeers, ensure an excellent experience by co-creating as a cohesive team and achieving the end result together. The involvement of both parties increases, which of course benefits the quality.

Advantage 2: increase of productivity

Increased productivity: among other things, the integration of Gitlab provides a boost in productivity. In this blog we dive deeper into this integration, we list the benefits and clarify with a short demo.

Read the blog Advantage 3: a DXP is very accessible

Turning Drupal into a DXP… Really, it sounds more difficult than it actually is. Even for mid sized enterprises, it’s very accessible. We are by your side the entire way and will get you started with a solid foundation so your company can enjoy all the benefits a DXP has to offer. And we promise, there are many! In this technical webinar, our CTO, Nick Veenhof, explains exactly how to get started.

Watch the replay DXP: an opportunity you can’t miss out on

In 2021, we're focusing even more on personalized, digital and progressive customer experiences. Mid-sized enterprises can also easily jump on that boat this year by turning their Drupal into a DXP. Not sure if your company is ready for this? Simply test it with our free trial. We’ll guide you, your company and your team from A to Z.

Get your free trial

Innoraft Drupal Blogs: Why Choose Drupal Over Any Other CMS?

Thu, 01/21/2021 - 14:00
Why Choose Drupal Over Any Other CMS?

The dilemma of choosing the more suitable CMS from a range of possible CMS options can be overwhelming.' is a major question that comes to mind when thinking forward towards development.

souvik Thu, 01/21/2021 - 18:30 Drupal Planet Drupal Development Drupal Drupal 7 Drupal 8 user friendly website Web Design website development services web developers

ADCI Solutions: Web design trends in 2021

Thu, 01/21/2021 - 10:17

New year, new web design trends. This means that it is time to start updating your Drupal websites. Don't panic, there are not many things that need to be changed or upgraded. Check our article on web visual and technological trends that will be popular for websites and mobile applications in 2021.

You can find the link here.

 

Security advisories: Drupal core - Critical - Third-party libraries - SA-CORE-2021-001

Wed, 01/20/2021 - 18:10
Project: Drupal coreDate: 2021-January-20Security risk: Critical 18∕25 AC:Complex/A:User/CI:All/II:All/E:Exploit/TD:UncommonVulnerability: Third-party librariesDescription: 

The Drupal project uses the pear Archive_Tar library, which has released a security update that impacts Drupal. For more information please see:

Exploits may be possible if Drupal is configured to allow .tar, .tar.gz, .bz2, or .tlz file uploads and processes them.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.9.x are end-of-life and do not receive security coverage.

Disable uploads of .tar, .tar.gz, .bz2, or .tlz files to mitigate the vulnerability.

Reported By: Fixed By: 

OpenSense Labs: Comparing web services implementations: REST vs JSON:API vs GraphQL

Wed, 01/20/2021 - 14:08
Comparing web services implementations: REST vs JSON:API vs GraphQL Gurpreet Kaur Wed, 01/20/2021 - 18:38

People today do not like to be confined, if I talk about development teams, they would hold up flags stating the same. Since development and innovation go hand in hand and constraint is the biggest enemy of innovation, you can’t tell me they are wrong to have that notion. 

Talking specifically about web developments, there are a lot of areas to explore and a lot of technologies to help you do that. So, why limit yourself, when you don't have to? Drupal has brought such an impressive trend forward that has simply satiated the developer’s desire for innovation and that is the headless approach

Unlike before, when your entire project had to be nestled inside one CMS, Drupal now gives you the opportunity to explore new technologies to your heart’s desire. This is possible because the presentation layer and the backend content become two separate entities. Drupal acts as the content repository and a frontend technology of your liking takes care of, of course, the frontend part of website architecture.

To provide a connection between the separated development aspects of the project, enters the API. An API layer is a necessity when going headless, because it transmits all the information from the front to the backend and vice-versa. 

And the three available APIs in Drupal, REST, JSON and GraphQL, are the reason behind me writing this blog. Although the purpose of all three is the same, they are quite different from one another. Today, we would be highlighting their meanings, their pros and cons and all the visible distinctions they have. So, let’s begin. 

Decoding the APIs 


REST, JSON and GraphQL bring in a similar outcome when they are used for decoupling Drupal. Yes, they are different too. And we would get into the difference between REST, JSON and GraphQL soon. Before that it is essential to understand their history, origin and what they were intended for because the differences actually start from there. 

REST 

REST was developed by Roy Fielding in the year 2000, the purpose behind its development was to provide a software architectural design for APIs. In simple terms, it provided an easy path for one computer to interact with another by utilising an HTTP protocol. The communication between the two computers is not stored on the server, meaning it is stateless; rather the client sessions are stored on a client-side server. 

There are six constraints necessary to implement REST in the complete sense. 

  • It needs a separated client and server; 
  • It needs to be able to make independent calls;
  • It needs to able to store cacheable data;
  • It needs to have a uniform interface;
  • It is a layered system; 
  • Finally, it needs a code-on-demand. 

REST offers a great deal of functionality without a lot of effort. For instance, if you are working on someone else’s RESTful API, you would not need a special library or special initialisation. Yes, your developers need to design their own data model using REST, but the HTTP conventions at play make programming a breeze. 

To know how REST plays a key role in decoupling Drupal, read our blog REST APIs in Drupal.

JSON: API  

JSON stands for JavaScript Object Notation. Built in May of 2013, it was designed as an encoding scheme, eliminating the need for ad-hoc code for every application to communicate with servers, which use a defined way for the same. JSON: API, like the name says, is a specification for building APIs using JSON. 

With JSON: API, communication between the server and the client becomes extremely convenient. It not only formats the way a request should be written, but the responses also come in a formatted manner. The primary aim of JSON: API is to lessen the number of requests and shrink the size of the package, all using HTTP protocol. 

Broadly stated; 

  • JSON reduces the number of requests and amount of data being transmitted; 
  • It requires zero configuration; 
  • It uses the same JSON access scheme for every piece of data, making caching very effective;
  • It offers quite a few features and gives you, as the client, the opportunity to turn them on or off. 

To know how JSON:API plays a key role in decoupling Drupal, read our blog, JSON API in Drupal.

GraphQL 

While JSON can work alongside REST, GraphQL was designed as an alternate to it and some of its inconveniences. Built in 2012 by Facebook, it acts as a cross-platform data query and manipulation language. Its servers are available in numerous popular languages, being Java, JavaScript, Ruby, Python, C#, amongst others. 

The features of GraphQL are that; 

  • It allows users to request data from multiple resources in a single request.
  • It can be used to make ad-hoc queries to one endpoint and access all the needed data.
  • It gives the client the opportunity to specify the exact type of data needed from the server. 
  • All of these add to its predictable data structure, making it readable as well as efficient. 

It was in 2015, after GraphQL was open-sourced that it became truly popular. Now its development is governed by The GraphQL Foundation, which is hosted by the Linux Foundation. 

To know how GraphQL plays a key role in decoupling Drupal, read our blog, GraphQL in Drupal.

Now that we know the basics of all the three APIs, let us have a look at their popularity status, before beginning the comparison. 

A glimpse at the popularity of the three APIs. Source: State of API Report 2020REST vs JSON vs GraphQL 

Now let’s get down to the details and understand why choosing one over the other two could be in your best interest. Let’s start with the differences between REST, JSON:API and GraphQL.

How efficient is the data retrieval?


One of the most important aspects for an API is the way its fetches data. It could require one or more requests. Therefore, this aspect is also referred to as its request efficiency. Getting multiple data responses in a single request has to be an ideal, so let’s see how REST, JSON: API and GraphQL here. 

REST 

The REST API is innately built to capitalise one resource per request. This works perfectly as long as you only need to retrieve a single piece of data like an article. However, if you need more than that, the number of requests you would have to type in separately would be equivalent to the amount of data you need. 

One article = one request 
Two articles = two requests
Two articles and the author information stored in a different field = Two requests for the articles + a long wait for the completion of those requests + two additional requests for the author information. 

This sums up REST’s request efficiency to the T. You require to be equipped to handle a number of requests, which can ultimately stall your user experience, making it seem to go at a snail’s pace. No sugar-coating here, there are going to be a lot of round trips. 

And the problem with a lot of round trips is a lot of extra information you do not even need. This is because there is a possibility that a REST API endpoint might not have the required data for an application. As a result, the said application will not get everything it needs in a single trip, making multiple trips the only option. It's safe to say that REST over-fetches and the verbose responses can be a problem.

JSON: API 

JSON: API does not suffer from the multiple request conundrum. One single request can give you everything you want, be it one article, two or ten along with the author’s information, I kid you not. 

This is possible because JSON: API implements a concept called ‘sparse fields.’ What this does is list the desired resource fields together for easy fetching. You can have as many fields as possible. If you feel the fields are too long and would not be cacheable, you can simply omit a few sparse fieldsets to cache the request. 

Another thing to remember is that the servers can choose sensible defaults, so your developers would need to be a little diligent to avoid over-fetching. 

GraphQL 

Coming to GraphQL, it was also designed in a similar fashion to JSON: API and is competent enough to eliminate the problem of over-fetching and avoid sending multiple requests. 

GraphQL has its own queries, schema and resolvers that aid the developers in creating API calls with particular data requirements in mind. Moreover, by mandating clear-cut additions to every resource field in every query and ensuring the developers cannot skip any of it,  it is able to avoid multiple round trips. Thereby, making over-fetching information a thing of the past. 

The only problem here can be that the queries may become too large, and consequently, cannot be cached. 

How is the code executed?


Using an API for calls involves the execution of a code on the server. This code helps in computing, calling another API or loading data from a database. All three of the APIs use a code, however, the code is implemented varies a little.

REST 

Route handlers are utilised for execution upon a REST call. These are basically functions for specific URLs. 

  • First the server receives the call and retrieves the URL path and GET; 
  • Then the functions are noted and the servers begins finding the same by matching GET and the path; 
  • After that the result is generated, since the server would have executed the function; 
  • In the final step, once the result is serialised by the API library, it is ready for the client to see. 

GraphQL

GraphQL operates in a relatively similar manner. The only difference is that it uses functions for a field within a type, like a Query type, instead of using functions for specific URLs.  

Route handlers are replaced by resolvers in GraphQL, they are still functions though.

  • After the call is made and the server has received a request, the GraphQL query is retrieved. 
  • The query is then examined and the resolver is called upon for every field. 
  • Finally, the result is added to the response by the GraphQL library and it is ready for the client to see. 

It should be noted that GraphQL offers much more flexibility as multiple fields can be requested in one request, and the same field can be called multiple times in one query.  The fact they let you know where you performance needs fine-tuning makes resolvers excellent trackers as well. 

This is simply not possible in REST and JSON. Do you see the difference in implementation? 

How do the API endpoints play a role?

Many a time, it is seen that once the API is designed and the endpoints are sealed, the applications require frontend iterations that cannot be avoided. You must know that the endpoints aid an application to receive the required data just by accessing it quickly in the view, so you could call them essential even. 

However, the endpoints can pose a bit of a problem for the iterations, especially when they need to be quick. Since, in such an instance, changes in the API endpoints have to be made for every change in the frontend, the backend gets tedious for no reason at all. The data required for the same can be on the heavier side or the lighter side, which ultimately hampers the productivity. 

So, which API offers the solution?

It is neither REST, nor JSON. GraphQL’s flexibility makes it easy for the developers to write queries mentioning the specific data needs along with iterations for the development of the frontend, without the backend having to bear the brunt.

Moreover, GraphQL’s queries help developers on retrieving specific data elements and provide insights to the user as to which elements are popular and which aren’t amongst the clients.  

Why doesn’t REST? 

The answer is simple, REST has the entire data in a single API endpoint. Being a user, you won’t be able to gain insights on the use of specific data as the whole of it always returned. 

How good is the API exploration?


Understanding your API and knowing about all of its resources and that too quickly and with ease is always going to benefit your developers. In this aspect, all three perform pretty contrastingly. 

REST 

REST gives a lacklustre performance in API exploration to be honest. The interactivity is pretty substandard as the navigation links are seldom available. 

In terms of the schema, it would only be programmable and validatable, if you are going to be using the OpenAPI standard. The auto-generation of the documentation also depends on the same. 

JSON: API 

JSON performs better than REST. The observation of the available field and links in JSON: API’s responses helps in its exploration and makes its interactivity quite good. You can explore it using a web browser, cURL or Postman

Browsing from one resource to the next, debugging or even trying to develop on top of an HTTP-based API, like REST, can be done through a web browser alongside JSON. 

GraphQL 

GraphQL is indeed the front-runner here. It has an impressive feature, known as the GraphiQL, due to which its API exploration is unparalleled. It is an in-browser IDE, which allows the developers to create queries repeatedly. 

What is even more impressive is the fact the queries get auto-completed based on the suggestions it provides and you get real-time results. 

Let’s focus on schema now 


Schemas are important for the development team, the frontend and the backend equally. It is because once a schema has been defined, your team would know the data structure and can work in parallel. Creating dummy test data as well as testing the application would be easy for the frontend developers. All in all, the productivity and efficiency levels elevate. 

REST

REST does have an associated expected resource schema since it is a set of standard verbiage. Despite this, there is nothing that is specifically stated in them. 

JSON: API 

In terms of schema validation and programming, it does define a generic one, however, a reliable field-level schema is yet to be seen. Simply put, JSON is basic with regards to schema. 

GraphQL

The fact that GraphQL functions completely on schemas makes it a pro in this regard. The schema used here is Schema Definition Language or SDL. What this means is that GraphQL uses a type system that sets out the types in an API because all the types are included in SDL. Thus, defining the way a client should access data on the server becomes easy. 

To conclude this point, I would want to say that when there is immense complexity in the schema and resource relationships, it can pose a disadvantage for the API.  

How simple is to operate it? 


Operating an API essentially involves everything, from installing and configuring it to scaling and making it secure. REST, JSON: API and GraphQL, all perform well enough to make themselves easy to operate. Let’s see how. 

REST 

REST is quite simple to use, a walk in the park for a pro developer. It is because REST is dependent on the conventional HTTP verbiage and techniques. You would not need to transform the underlying resources by much, since it can be supported by almost anything. It also has a lot of tools available for the developers, however, these are dependent on their customisation before they can be implemented. 

In terms of scaling, REST is extremely scalable, handling high traffic websites is no problem at all. To take advantage of the same, you can make use of a reverse proxy like Varnish or CDN. Another plus point of REST is that it has limited points of failure, being the server and the client. 

JSON: API 

JSON: API is more or less the same as REST in terms of its operational simplicity, so much so that you can move from REST to JSON: API without any extensive costs. 

  • It also relies on HTTP; 
  • It is also extremely scalable; 
  • It also has numerous developer tools, but unlike REST, JSON: API does not need customised implementations; 
  • Lastly, JSON also has fewer failure points. 

GraphQL 

GraphQL is the odd one out here. It isn’t as simple to use as the other two. It necessitates specific relational structure and specific mechanisms for interlocking. You would be thinkin that how is this complex? Let me ask you to focus on word specific, what this means is that you might need to restructure your entire API with regards to resource logic. And you must know that such restructuring would cost you time, money and a boatload of efforts. 

Even in terms of scalability, GraphQL does not fare very well. The most basic requests also tend to use GET requests. For you to truly capitalise GraphQL, your servers would need their own tooling. If I talk about the points of failure here, even those are many, including client, server, client-side caching and client and build tooling. 

What about being secure?


The kind of security an API offers is also an important consideration in choosing it. A drastic difference is noted in REST and GraphQL. Let’s see what that is. 

REST 

REST is the most secure amongst the three. The intrinsic security features in REST are the reason for the achievement. 

  • There are different APU authentication methods, inclusive of HTTP authentication;
  • There are the JSON Web Tokens for sensitive data in HTTP headers;
  • There are also the standard OAuth 2.0 mechanisms for sensitive data in JSON structure. 

JSON:API

JSON:API is on a similar footing to REST in terms of security. The reason being the fact that like REST it exposes little resources.  

GraphQL 

It is not like GraphQL is not secure, it is; however, the security has to be manually attained. It is not secure by default and it is not as mature as REST in this regard. 

When the user has to apply authentication and authorisation measures on top of data validation, the chances of unpredictable authorisation checks rise. Now, do I have to tell you that such an event is bound to jeopardise your security? 

How is the API design pinpointed?


If an API has to perform well for every use case, you have to make it do so. By creating such design choices that are a result of your understanding of the users’ needs. You cannot just go with the flow, evaluating how your users are going to be interacting with your API and getting an understanding of the same is key for your API’s design. 

REST

For REST, this exercise of deciphering the user requirements must happen before the API can be implemented. 

GraphQL 

As for GraphQL, this apprehension can be delayed a little. By profiling the queries, you would be able to tell their complexity level and pinpoint the sluggish queries to get to an understanding of user’s consumption of the API. 

What about their use in Drupal?  


Drupal is an important player when it comes to building websites and managing their content. With decoupling Drupal becoming more and more popular, it has become crucial to understand how the APIs perform alongside Drupal. 

REST 

Talking about the installation and configuration of REST, it can be complicated at best. The fact that the REST module has to be accompanied by the REST UI module does not ease the complexity. 

With REST, the clients that cannot create queries with the needed filters on their own, since the REST module does not support client-generated collection queries. This is often referred to as decoupled filtering.  

JSON:API 

JSON:API module landed in Drupal core in Drupal 8.7. JSON:API’s configuration is as easy as ABC, there is simply nothing to configure. JSON is a clear winner in this aspect. 

Moving to client-generated queries, JSON does offer its clients this luxury. They can generate their own content queries and they won't need a server-side configuration for the same. JSON’s ability to manage access control mechanisms offered by Drupal make changing an incoming query easy. This is a default feature in JSON:API.

GraphQL 

The installation of GraphQL is also not as complicated as REST, but it isn’t as easy as JSON as well. This is because it does mandate some level of configuration from you. 

Similar to JSON, GraphQL also offers decoupled filtering with client generated queries. A less common trend amongst GraphQL projects is seeking permissions for persisted queries over client-generated queries; entailing a return to the conventional Views-like pattern.

In addition to these three major Drupal web services, explore other alternatives in the decoupled Drupal ecosystem worthy of a trial. Read everything about decoupled Drupal, the architecture-level differences between headless and traditional setups, different ways to decouple Drupal, and the skills required to build a Decoupled Drupal web application to know more.

Concluding with the basics 

To sum up, let us look at the fundamental nature of the three APIs, which entails two aspects; simplicity and functionality. 

In terms of simplicity, REST is a winner. A second would be rewarded to JSON, while GraphQL would not and could not be described as simple, complex and that too immensely with major implementations coming your way would be a more accurate description. In terms of functionality, GraphQL does offer the most. If you choose JSON over GraphQL, you would end up parting with some of its features unfound in JSON. 

All three are powerful and efficient in what they can do for your application. The question is how much complexity are you willing to take up with that power?

blog banner blog image JSON:API REST API GraphQL Drupal Web Services Blog Type Articles Is it a good read ? On

Amazee Labs: Contributing 12 Patches in 12 Months… again!

Wed, 01/20/2021 - 08:31
<img src="https://www.amazeelabs.com/sites/default/files/styles/leading_image/public/images/current-affairs/12-Patches-12-Months.jpg?h=994a2424&amp;itok=ifURidYR" width="1120" height="630" alt="Contributing 12 Patches in 12 Months in 2021" title="Contributing 12 Patches in 12 Months… again!" class="image-style-leading-image" /> In 2019, I set myself a goal of contributing one patch each month to Drupal and that's how #12months12patches came to be a Slack channel at Amazee Labs. The results of that challenge are reflected in this blog post from last year.

BADCamp News: Drupal Global Contrib Weekend at San Francisco Drupal User Group - Introduction to issue forks and merge requests

Wed, 01/20/2021 - 01:31
Drupal Global Contrib Weekend at San Francisco Drupal User Group - Introduction to issue forks and merge requests Wed, 01/20/2021 - 12:00 volkswagenchick Tue, 01/19/2021 - 16:31 Next week kicks off Drupal Global Contribution Weekend, January 29-31, a virtual worldwide event everyone can participate in from anywhere in the world. Want to give back to the Drupal Community in the form of code but you're not acquainted with the new contrib process? Here’s your chance to get ready for the weekend. Now that our meetups are online, join the San Francisco community in learning how to create issue forks and merger requests. Drupal Planet

Dcycle: Adding continuous integration (CI) to your workflow

Wed, 01/20/2021 - 01:00

This post is aimed at web development teams and is not tied to a specific technology. We will aim to not get more technical than is needed, but rather to explore what Continuous integration (CI) is, and how it can help save teams money within a month of it being set up.

What is continuous integration?

Although several definitions of CI have been proposed, we will use the following definition in the context of this post:

Cotinuous integration (CI) is the practice of running any number of tests, automatically, on a project, periodically and/or whenever the code changes. For CI practitioners, the number one priority is for tests to always be passing.

A simple example, please

Here is the very simplest example I can think of:

Let’s say you’re maintaining an old-school HTML website (no fancy stuff like databases or PHP), your team may decide to set up CI to make sure a file called “index.html” exists in your codebase: if it exists, your test passes; if it is absent, your test fails.

Checks may be run every time your code is changed.

Your team might store code on GitHub, and link a cloud CI provider such as CircleCI to your codebase, having it trigger every time your code changes.

You will then define a script which is your definition of “what it means for your your codebase to pass”: checking for the existence of “index.html” is a one-line script.

A more complex example

Although the example above has value, it is very simple, and you may soon find yourself wanting to add higher-value tests to your script. This ability to add complexity over time is a powerful feature of CI: getting started is simple, and you can add as many tests as you want over time depending on your available resources.

Let’s say your team is maintaining a Drupal or Wordpress codebase with lots of complex code, your team may set up a CI server that:

  • checks for broken links on the live environment every so often;
  • checks every few minutes that the live environment is responding and has some expected keywords on its front page;
  • every so often, checks that the live environment adheres to certain Accessibility standards;
  • every so often, checks that the live environment is not reporting any errors;
  • on every code change, perform some static analysis on custom PHP code: for example, that a function which expects an array as an argument is never called with a string.
  • on every code change, make sure PHP code adheres to coding standards (for example, functions should have comments; and indenting should be correct).
  • on every code change, create a dummy Drupal or Wordpress site with a dummy database and make sure your site fires up, and run some end-to-end tests against it.
  • etc., etc.

A cloud-based tool such as CircleCI can work well to check the codebase when it is changed; and a hosted tool such as Jenkins might be a good fit for running periodic checks (such as a sanity check making sure the production environment works).

The above example corresponds to real-world checks I perform on lost of projects I maintain; and both CircleCI and Jenkins are tools I have been using for years.

So how much does all this cost?

“How much does this cost?” is actually the wrong question. “How much can I save?” is a better way of putting it. Consider the following graph, the horizontal axis is time, and the vertical axis is cumulative project cost.

// set the dimensions and margins of the graph var margin = {top: 10, right: 30, bottom: 30, left: 60}, width = 460 - margin.left - margin.right, height = 400 - margin.top - margin.bottom; // append the svg object to the body of the page var svg = d3.select("#ci") .append("svg") .attr("width", width + margin.left + margin.right) .attr("height", height + margin.top + margin.bottom) .append("g") .attr("transform", "translate(" + margin.left + "," + margin.top + ")"); //Read the data d3.csv("/data/posts/2021-01-13/ci.csv", function(data) { // group the data: I want to draw one line per group var sumstat = d3.nest() // nest function allows to group the calculation per level of a factor .key(function(d) { return d.name;}) .entries(data); // Add X axis --> it is a date format var x = d3.scaleLinear() .domain(d3.extent(data, function(d) { return d.year; })) .range([ 0, width ]); svg.append("g") .attr("transform", "translate(0," + height + ")") .call(d3.axisBottom(x).ticks(0).tickFormat(() => "")); // Add Y axis var y = d3.scaleLinear() .domain([0, d3.max(data, function(d) { return +d.n; })]) .range([ height, 0 ]); svg.append("g") .call(d3.axisLeft(y).ticks(0).tickFormat(() => "")); // color palette var res = sumstat.map(function(d){ return d.key }) // list of group names var color = d3.scaleOrdinal() .domain(res) .range(['#e41a1c','#377eb8','#4daf4a','#984ea3','#ff7f00','#ffff33','#a65628','#f781bf','#999999']) // Draw the line svg.selectAll(".line") .data(sumstat) .enter() .append("path") .attr("fill", "none") .attr("stroke", function(d){ return color(d.key) }) .attr("stroke-width", 1.5) .attr("d", function(d){ return d3.line() .x(function(d) { return x(d.year); }) .y(function(d) { return y(+d.n); }) .curve(d3.curveMonotoneX) (d.values) }) }) // https://stackoverflow.com/questions/19787925 d3.svg.axis().tickValues([])
  • The red line is business as usual: because we are not maintaining CI scripts or setting up tests, the up-front cost is low. But eventually you’ll lose control of your codebase and spend all your time putting out fires (I call this the “technical debt wall”).
  • The blue line is the CI approach, higher up-front cost to set things up, but eventually you’ll get less errors.
  • Where the two lines intersect, I call the “sweet spot”. That’s when you start saving money. Your “sweet spot” is not months or years away: I firmly believe it should happen within a month. If it takes longer than a month, you’re overengineering your CI system.
So what are these up-front costs?

The up-front costs are:

  • Creating a simple script which defines what it means for your code “to work”. If you find this intimidating, just have your script check for a file that must be present, as in the simple example presented earlier.
  • Make sure your code is tracked in GitHub or BitBucket.
  • Make sure your entire team accepts the principle that making tests pass is the number one priority. This is crucial. If you start accepting failing tests, then CI becomes a useless burden. This also means every member of your team must agree with every test that is performed. If a test is not important enough to warrant dropping everything when it fails, then you should not have that test in your codebase.
  • Integrate a simple, free CI cloud provider like CircleCI and make sure it works.

All of the above, together, can take between an hour and a day.

How about the ongoing costs?

Ongoing costs are closely relate to the complexity of your CI setup. If you are just testing for an “index.html” file, your ongoing costs are close to zero, but may include:

  • dealing with errors and updates in the CI script itself. Don’t forget the CI script is computer code, and like any computer code, it needs to be maintained.
  • updating the CI script to deal with API changes in the cloud CI provider.
  • fixing false negatives. For example, someone may change the filename from index.html to index.htm, which might require you to fix your test script to also test for index.htm in addition to index.html.
  • onboarding new team members to understand the importance of making sure tests always are passing.

If your tests are super simple (such as checking that an “index.html” file exists), the above costs are low, probably less than one hour a month.

If your tests are complex (as in our second example, above), you might set aside 5 to 10 hours a month for ongoing costs.

Obviously, if your ongoing costs are higher than your savings, then you are “over-testing”.

So what are the benefits?

The fundamental trick of CI is to keep your benefits higher than your costs. Let’s go back to our simple “index.html” example:

  • We have already established that there are minimal up-front and ongoing costs.
  • There are also ongoing savings: once you know that your index.html file is guaranteed to exist, your manual testing time decreases.
  • The cost in lost revenue, lost confidence, and debugging time in case someone accidentally deletes index.html from your website would be considerable high.

Based on the above, you can conclude whether it’s worth implementing CI.

Continuous improvement of your CI setup

Checking for “index.html” is probably of very low value, but once you’ve done that, you’ve also set up the foundation to improve your script. Every time you feel your CI script has a positive cost-benefit ratio, it is time to improve your CI script. In practice, I have found that in projects under active development, the CI setup gets constantly improved.

Specifically, any time a problem makes its way to production, it should be a gut reaction to introduce a fix, along with a test to make sure the problem never happens again.

The key is making incremental improvements, making sure your cost-benefit ratio is always positive.

Docker and containerization

Docker, and containerization generally, embed software and configuration in computer code along with your project code.

The widespread adoption of Docker and containerization in recent years has been crucial for CI. Without containerization, let’s say you want to run PHP static analysis, start a database with a Drupal site, run end-to-end tests, you need to install a bunch of software on your CI server (or your laptop), make sure the versions and configuration are in sync with your local development setups. This is simply too expensive.

Docker makes all this easy: simply put, Docker abstracts all the software and configuration, making software act the same on any computer that has Docker installed.

If you are not using Docker and you’d like to see how simple this makes things, install and launch Docker Desktop on your computer, give it 6Gb RAM instead of the default 2Gb in its preferences, then you’ll be able to run all tests on my Drupal Starterkit project, without any additional fiddling with configuration of software:

cd ~/Desktop && git clone https://github.com/dcycle/starterkit-drupal8site.git cd starterkit-drupal8site ./scripts/ci.sh

It should take about 10 minutes to run all tests and it will not add any software to your computer; everything is done on throwaway “containers”. (In general, tests become a lot more frustrating to developers as they take longer to run; which is why I have a policy of not accepting tests which take more than 20 minutes to run.)

The amount of software packages and configuration required to run all the tests in this example is enormous: database servers and configuration, passwords, permissions, PHPUnit, the right version of PHP and Apache or Nginx…; however it’s all defined in Docker files and in code, not on host computers.

Which is why you can run the tests in three lines of code!

This makes it possible to run these complex tests on your computer without installing any software other than Docker.

This also makes it possible to run these exact tests, sans extra configuration, on CircleCI or other CI providers which support virtual machines with Docker preinstalled. In fact, that’s exactly what we’re doing with the Drupal Starterkit. CircleCI even provides a cute badge to indicate whether tests are passing.

Click on the badge below to see test results on CircleCI, which should be identical to the results on your computer if you ran the the above script (you’ll need to log in with your GitHub or BitBucket account).

Security

Whether you are using a cloud service such as CircleCI, or hosting your own CI server with Jenkins or other software, be aware that it adds a potential attack vector for hackers, especially because by design, CI software needs access to your codebase.

In early 2021, a vulnerability was discovered in JetBrains TeamCity (Widely Used Software Company May Be Entry Point for Huge U.S. Hacking, New York Times, January 6th, 2021) in relation to the major SolarWinds hack.

Make sure you have a solid security policy, including the Principle of Least Privilege (POLP) and other industry-standard security approaches; also make sure your codebase, even if it’s private, does not contain any sensitive data, including API keys.

Conclusion

With continuous integration (CI), you can let computers do the grunt work of looking for bugs in your codebase, liberating your developers to do more productive work, reducing the number of bugs that make it into production, and increasing the level of confidence of all stakeholders in your software, and deploying frequently.

And, above all, saving money.

CI can be as simple or as complex as you need: start small, then let your CI process grow as your team becomes more comfortable with it.

This post is aimed at web development teams and is not tied to a specific technology. We will aim to not get more technical than is needed, but rather to explore what Continuous integration (CI) is, and how it can help save teams money within a month of it being set up.

Redfin Solutions: Design for Better Communication with Developers

Tue, 01/19/2021 - 19:09
As a designer and front-end developer, the infamous designer-developer handoff has often been between me and myself. Having spent a lot of time in both roles, as well as having worked closely with other designers and developers, I’ve learned a few practices that help me to answer developer questions right from the start.