OpenSense Labs: Why is Drupal great for multilingual sites

Planet Drupal - Sun, 2019/05/26 - 1:32pm
Why is Drupal great for multilingual sites Shankar Sun, 05/26/2019 - 17:02

World Economic Forum, an International Organisation for Public/Private Cooperation, has its digital presence not only in English language but other prominently spoken languages like Spanish, Chinese, French and Japanese as well. Rio Olympics 2016, which is also known for the infamous haul of 9 golds by Usain Bolt, had its online presence in both English and French. Oxfam, an international confederation of 19 organisations that has the objective of mobilising the power of people against poverty, has its website in Spanish and French languages other than English. What is common between all of them? Their websites are powered by Drupal which is one of the leaders in the open source content management system (CMS) market.


Built and maintained by an international community of developers, Drupal has been a marvellous solution for organisations around the globe that are in need of swiftly launching their websites that is tailored to a variety of language needs. As a matter of fact, Drupal 8, the latest version, was created keeping multilingual use in mind. But why should an organisation consider building a multilingual site in the first place? Let’s understand its significance before taking a plunge in exploring Drupal’s capabilities in building a localised site.

Significance of multilingual sites


English is certainly the most widely spoken language in the world and dominates the internet space. But it would be wrong to consider it is as the most preferred language. Chinese, Spanish, Arabic and many others, as you can see in the graph above, are spoken by millions of online users. So, optimising your site and going multilingual gives you a huge advantage.

Some of the major benefits of having a multilingual website are:

Source: DayTranslations

One of the most important benefits of going multilingual is that you can enhance communication as even though English has its preeminence over the online space. That doesn’t mean that everyone wants to buy from English language websites. Research from CSA Research says that people prefer to make purchases while browsing in their own native language as more than half of the people who were surveyed bought from sites that were available in their own language. Another important benefit is that you can expand your reach and cover a wider audience. Localised websites also result in increased client satisfaction. Multilingual SEO is of paramount importance too and localising your website into different languages helps improve your SERP (Search Engine Results Page) ranking locally across the globe.

Moreover, website localisation is efficacious and gives you a competitive advantage. In a survey by Content Marketing World, 60% of participating marketers agreed that there is a dearth of multilingual content marketing strategies. Therefore, not capitalising on the immense amount of opportunities that website localisation presents can prove detrimental to your business pursuits. You may lose out to a local business that is well known and also fare badly against another foreign company that is localising better. Also, not only you get to touch a wider demographic of the audience, you get the opportunity to increase your audience as you will be noticed by a massive pool of potential buyers for your product and services. And you do not get penalised for duplicated content on translated sites. Localising your website also bring about higher conversions and skyrocketed return on investment. Even if you cannot please everyone, you can please the majority of them when you make your site multilingual.

Considerations for turning your site multilingual

In order to develop a great multilingual site, there are some considerations that should be kept in mind.

Building a site in any language needs a clearly thought-out plan for content and needs a detailed picture of your business objectives and vision. For instance, you should know who the ideal customer for your products and services is and where does he or she live. And you should know which language will have a wider reach amongst your potential customers.

You would, then, require a wisely laid-out strategy. You can register top-level domains like .mx for Mexico or .fr for France. You must know that photographs, artwork, fonts, and colour choices carry different meanings across different cultures. Visitors should find it easy to navigate and find their native language microsite. Different languages should be used appropriately and nothing should come across as offensive or insensitive to the different cultures.

Most importantly, you need to determine the best technological solution for creating your localised site. A robust CMS like Drupal can be a remarkable option that can dovetail with your multilingual strategy.

Drupal in the mix

If you are in the need of quickly creating customised sites in any language of your choice or an intricate multilingual web application with dynamic, language-based displays, Drupal is a wonderful option. Without the need for any additional components, Drupal 8 can be installed in over 90+ languages. Drupal’s out-of-the-box support for language handling assists you in delivering localised digital experiences and saves time and money. Drupal 8 core comes with four core modules for localising content on the website.

Administering Language


The Language handling module lets you pick your choice from 94 languages.
 
Language configuration has been streamlined. Assign a language to everything from taxonomy terms to administration language. You can even delete the English language. Each user can also select his or her own language for the admin interface.
 
The detection of browser language can be easily configured with external language codes. There is also a built-in transliteration for the machine names.

Translating Interface

Interface translation module provides a central directory to manage interface. It has built-in translation UI for simplifying content editing. By allowing automatic downloads and updates, it lets users use any translation interface available in the Drupal community in any language supported by Drupal 8.
 
English language interface can be customized. You do not have to use English as your default language.

Translating Content



Content translation module is applicable to all of your content. It lets you translate everything from the pages to the taxonomy terms. It allows you to configure custom fields of a web content.
 
Like interface translation, the default language of your content can be flexibly configured. You can even hide or display the position of language selector.

Managing Configuration



Everything that comes with the configuration of your website can be translated using this module. Things like views, blocks, panels, field panels or text formats can be easily translated with its built-in responsive translation interface.
 
Moreover, there is a provision of an overview screen to help you in the process.

Case studies


Sevilla FC, founded in 1890, is one of the oldest football teams in Spain. A digital agency helped it to implement a series of quality and qantitative enhancement in its digital services via web, mobile and social media channels. Drupal turned out to be a fantastic option in their pursuit of improving the digital experience. Drupal’s in-built multilingual capabilities, top-of-the-line open source security, tremendous scalability, great content workflow tools and the support for agile project delivery were the major factors that made it the right choice for this project. With a continuous increase in the number of international fanbases of Sevilla FC, it was important to create a multilingual site. The multilingual capability of Drupal 8 streamlined the process of localising their website into multiple languages.

What if your native language is not available to choose from 90+ languages that the Drupal offers? OpenSense Labs leveraged Drupal 8 to provide a clean architecture and design for the betterment of digital presence of the Ministry of Finance in Somalia.


The remodelling of the website needed new content types with user-friendly navigation and the addition of a custom type of publication to publish annual reports. Agile development methodology helped the project to be completed within six weeks. And, as Somali isn’t available in the list of languages provided by Drupal 8’s out of the box solution, the flexible multilingual infrastructure of Drupal aided in adding it easily.

Conclusion

While English language internet users have been the primary source of the target of every business. There has been an unprecedented growth in the non-English language online users as well. Reaching them out is beneficial for widening your customer base and establishing their business in newer markets. Your content determines the website traffic, customer retention, and conversion rates. CMS is the warehouse of your web content. It is significant to choose the right CMS before even making your first move towards making your site multilingual.

Drupal 8 has made tremendous improvements to include the built-in multilingual feature. It delivers multilingual websites right out of the box. Its 4 key modules for language, interface, content, and configuration of your website helps in efficaciously building a multilingual site.

Drupal development is our forte and we are committed towards the provision for great digital experiences. To tap into newer markets with multilingual Drupal websites, reach us out at hello@opensenselabs.com.

blog banner blog image Drupal 8 Multilingual Site Drupal Multilingual Drupal multilingual site Blog Type Articles Is it a good read ? On
Categories:

Drupal blog: Drupal-powered Justice.gov sustains traffic surge from Mueller report post

Planet Drupal - Sat, 2019/05/25 - 12:47am

This blog has been edited and reposted with permission from Dries.
 

On the day that the Drupal-powered Justice.gov website released Special Counsel Robert Mueller's long-awaited report on Russian interference in the U.S. election, the site experienced a 7,000% increase in traffic.

The report was successfully delivered without interruption via Acquia, using Drupal. 

According to Federal Computer Week, by 5pm on April 18, there had already been 587 million site visits, with 247 million happening in the first hour the report was released. The site typically receives 8 million visits per day. 

There were no IT performance or availability issues during the release of the 142-MB report, which is ideal during these types of high-pressure events when the world is watching. Thus, no news is good news. 

Keeping sites like this up and available to the public is an important part of democracy and the freedom of information. 

I'm proud of Drupal and Acquia’s ability to deliver when it matters most!

Categories:

Gábor Hojtsy: Analysis of top uses of deprecated code in Drupal contributed projects in May 2019

Planet Drupal - Fri, 2019/05/24 - 3:00pm

Dwayne McDaniel did some thorough reporting of deprecated code use in all Drupal 8 contributed modules in March. Ultimately this kind of reporting would be best to have on drupal.org but while that is figured out, Dwayne's data set provides a very nice way to mine data about Drupal 9 readiness of contributed modules and to inform our tooling to improve the process. His original numbers showed that almost 44% of contributed modules had no deprecated code use at the time. What I was interested in was how to help the rest of the 56%.

Dwayne created an updated process and a new repository this week with fresh data. I was still curious so I delved right into the data and started mining it. A key question I was interested in is how much of the most widespread deprecations are actionable right now. An actionable deprecation is something core deprecated in a previous version that is not supported anymore, so you can update your code to remove the use of that API. Currently Drupal 8.6 and 8.7 are supported, so deprecations there should only be acted on for your custom code. However deprecations in and before 8.5 are entirely fine to act on.

First I counted the top list of deprecated APIs used from Dwayne's data across all of contributed projects. Then I wrote a script to collate api.drupal.org documentation to the deprecation notices. Ideally phpstan itself would report these messages directly and Matt Glaman is working on that. However since that is still blocked on the phpstan side, one needs a different data source to find the deprecation documentation for each occurrence, so I took to api.drupal.org to get that for now. Once that is found, we can categorize the deprecations into actionable, not actionable and actionable for custom code only. For the later case you know which core version you are using, and that should be an up to date minor version. So you don't need to deal with what core branches the community supports otherwise.

The results look really promising so far in terms of how much contributed modules can make progress on even today. If all already actionable deprecations get resolved, there will be very little left at least of the deprecations we already know.

A month ago Dezső Biczó created a set of proof of concept Rector fixes to automate some of these deprecation fixes, so I opened an issue with this new data set to try and cover the top ones that are not just actionable but approachable to automate.

As with all interesting data sets, this summary is just the tip of the iceberg. There is huge potential to mine this data set for other uses, such as finding modules that potential contributors at an event could contribute fixes to. I don't know yet how much I can continue to work with this data myself, and of course others doing analysis of their own would be more than welcome.

Are you a drupal.org project maintainer? Now would be a good time to fill in your Drupal 9 porting information in your project, so you can let contributors know how to best engage with your in the process towards Drupal 9.

https://t.co/hf2ENvlZSo projects can now specify Drupal 9 porting information, so *you* can direct *your* contributors to provide the most valuable help on the way to Drupal 9, fund the process or just step back (for now). Edit your project to help your contributors help you! pic.twitter.com/l1OWwOllBK

— The Drop is Always Moving (@DropIsMoving) May 21, 2019

Disclaimer: The data is based on the state of contributed projects on May 20, 2019 based on Drupal core's 8.8.x development branch on May 20, 2019. The lookup on api.drupal.org was not perfect and I found some bugs there that are being resolved as well so the data gets more accurate. Also, as contributed modules will get updated, there will be less uses of deprecated APIs. As core will introduce more deprecations, the data could get worse. There may also be phpstan Drupal integration bugs or missing features, such as not finding uses of deprecated global constants yet. This is a snapshot as the tools and state of code on all sides evolve, the resulting data will be different.

Categories:

Digital Echidna: Thoughts on all things digital: Smart Date Module Puts a Premium on Time, User Experience

Planet Drupal - Fri, 2019/05/24 - 12:05pm
Time is always of the essence. From a consumer perspective, you want to know when events take place, when something’s open or closed, how long a meeting or activity will last. And, from a development perspective, you want to be able to create a date…
Categories:

Agiledrop.com Blog: 7 questions you're probably asking yourself when considering Open Social

Planet Drupal - Fri, 2019/05/24 - 11:49am

Open Social is a Drupal distribution that enables anyone to quickly & easily set up a platform for their own community, no matter its size or needs. In this post, we'll take a look at the platform's powerful capabilities.

READ MORE
Categories:

OPTASY: Cache API in Drupal 8: How Is It Any Different from Drupal 7 Cache System?

Planet Drupal - Fri, 2019/05/24 - 10:19am
Cache API in Drupal 8: How Is It Any Different from Drupal 7 Cache System? radu.simileanu Fri, 05/24/2019 - 08:19

What makes the Cache API in Drupal 8 any better than Drupal 7's cache system? What's so revolutionary about it? Which of the old limitations does it remove? What are those new concepts and terminology that you should learn about?

And, most of all: how complex is it to set up a cache in Drupal 8 for a specific use case?

You might have already bumped into terms like “max-age”, "context cache" or "cache tags".
 

Categories:

Red Route: There isn't a module for that already?

Planet Drupal - Fri, 2019/05/24 - 1:00am

This article was originally posted on the Capgemini Engineering blog

Sometimes clients ask for the wrong thing. Sometimes developers build the wrong thing, because they didn't ask the right questions. If you're solving the wrong problem, it doesn't matter how elegant your solution is.

One of the most important services that we as developers and consultants can provide is being able to help guide our clients to what they need, rather than simply giving them what they want. Sometimes those two things are aligned, but more often than not, figuring out the right thing to build takes some discovering.

Why don't wants and needs match? It might be because the client hasn't spent enough time thinking about the question, or because they haven't approached it from the right angle. If that's the case, we can help them to do that, either by asking the right questions or by acting as their rubber duck, providing a sounding board for their ideas. Alternatively, it might be because, as a marketing or content specialist, they lack sufficient awareness of the potential technological solutions to the question, and we can offer that.

Once you've properly understood the problem, you can start to look for a solution. In this article, I'll talk about some examples of problems like this that we've recently helped clients to solve, and how those solutions led us to contribute two new Drupal modules.

There must be a module for that

Sometimes the problems are specific to the client, and the solutions need to be bespoke. Other times the problems are more general, and there's already a solution. One of the great things about open source is that somebody out there has probably faced the same problem before, and if you're lucky, they've shared their solution.

In general, I'd prefer to avoid writing custom code, for the same reasons that we aren't rolling our own CMS. There are currently over 43,000 contributed modules available for Drupal, some of which solve similar problems, so sometimes the difficult part is deciding which of the alternatives to choose.

Sometimes there isn't already a solution, or the solution isn't quite right for your needs. Whenever that's the case, and the problem is a generic one, we aim to open source the solutions that we build. Sometimes it's surprising that there isn't already a module available. Recently on my current project we came across two problems that felt like they should have been solved a long time ago, very generic issues for people editing content for the web - exactly the sort of thing that you'd expect someone in the Drupal community to have already built.

How hard could it be?

One area that sometimes causes friction between clients and vendors is around estimates. Unless you understand the underlying technology, it isn't always obvious why some things are easy and others are hard.

XKCD -tasks

Even experienced developers sometimes fail to grasp this - here's a recent example where I did exactly that.

We're building a site in Drupal 8, making heavy use of the Paragraphs module. When adding a webform to a paragraph field, there's a select list with all forms on the site, sorted alphabetically. To improve usability for the content editors, the client was asking for the list to be sorted by date, most recently created first. Still thinking in Drupal 6 and 7 mode, I thought it would be easy. Use a view for selection, order the view by date created, job done - probably no more than half an hour's work. Except that in Drupal 8, webforms are no longer nodes - they're configuration entities, so there is no creation date to order by. What I'd assumed would be trivial would in fact require major custom development, the cost of which wouldn't be justified by the business value of the feature. But there's almost always another way to do things, which won't be as time-consuming, and while it might not be what the client asked for, it's often close enough for what they need.

What's the real requirement?

In the example above, what the content editors really wanted was an easy way to find the relevant piece of content. The creation date seemed like the most obvious way to find it. If you jump to a solution before considering the problem, you can waste it going down blind alleys. I spent a while digging around in the code and the database before I realised sorting the list wouldn't be feasible. By enabling the Chosen module, we made the list searchable - not what the client had asked for, but it gave them what they needed, and provided a more general solution to help with other long select lists. As is so often the case, it was five minutes of development work, once I'd spent hours going down a blind alley.

This is a really good example of why it's so important to validate your assumptions before committing to anything, and why we should value customer collaboration over contract negotiation - for developers and end users to be able to have open conversations is enormously valuable to a smooth relationship, and it enables the team to deliver a more usable system.

Do you really need square pegs?

One area where junior developers sometimes struggle is in gauging the appropriate level of specificity to use in solving a problem. Appropriate specificity is particularly relevant when working with CSS, but also in terms of development work more generally. Should we be building something bespoke to solve this particular problem, or should we be thinking about it as one instance of a more generic problem? As I mentioned earlier, unless your problem is specific to your client's business, somebody has probably already solved it.

With a little careful thought, a problem that originally seemed specific may actually be general. For example, try to avoid building CMS components for one-off pieces of a design. If we make our CMS components more flexible, it makes the system more useful for content editors, and may even mean that the next requirement can be addressed without any extra development effort.

Sometimes there can be a sense that requirements are immutable, handed down from on high, carved into stone tablets. Because a client has asked for something, it becomes a commandment, rather than an item on a wish list. Requirements should always be questioned The further the distance between clients and developers, the harder it can be to ask questions. Distance isn't necessarily geographical - with good remote collaboration, and open lines of communication, developers in different time zones can build a healthy client relationship. Building that relationship enables developers to ask more questions and find out what the client really needs, and it also helps them to be able to push back and say no.

Work with the grain

It can be tempting to imagine that the digital is infinitely malleable; that because we're working with the virtual, anything is possible. When clients ask “can we do X?, I usually answer that it's possible, but the more relevant question is whether it's feasible.

Just as the web has a grain, most technologies have a certain way of working, and it's better to work with your framework rather than against it. Developers, designers and clients should work together to understand what's simple and what's complicated within the constraints. Is the extra complexity worth it, or would it be better to simplify things and deliver value quicker?

Sometimes that can feel like good cop, bad cop, where the designers offer the world, and developers say no. But the point isn't that I don't want to do the work, or that I want to charge clients more money. It's that I would much rather deliver quick wins by using existing solutions, rather than having developers spend time on tasks that don't bring business value, like banging their heads against the wall trying to bend a framework to match a "requirement" that nobody actually needs. It's better for everyone if developers are able to work on more interesting things.

Time is on my side

As an example of an issue where a little technical knowledge went a long way, we were looking at enabling client-side sorting of tables. Sometimes those tables would include dates. We found an appropriate module, and helped to get the Drupal 8 version working, but date formats can be tricky. What is readable to a human in one cultural context isn't necessarily easy for another, or for a computer, so it's useful to add some semantic markup to provide the relevant machine-readable data.

Drupal has pretty good facilities for managing date and time formats, so surely there must be a module already that allows editors to insert dates into body text? Apparently not, so I built CKEditor Datetime.

With some helpful tips from the community on Drupal Slack, I found some CKEditor examples, and then started plumbing it in to Drupal. Once I'd got that side of things sorted, I got some help from the plugin maintainer to get the actual sorting sorted. A really nice example of open source communities in action.

Every picture tells a story

Another challenge that was troubling our client's content team was knowing what their images would look like when they're rendered. Drupal helpfully generates image derivatives at different sizes, but when the different styles have different aspect ratios, it's important to be able to see what an image will look like in different contexts. This is especially important if you're using responsive images, where the same source image might be presented at multiple sizes depending on the size of the browser window.

To help content editors preview the different versions of an image, we built the Image Styles Display module. It alters the media entity page to show a preview of every image style in the site, along with a summary of the effects of that image style. If there are a lot of image styles, that might be overwhelming, and if the aspect ratio is the same as the original, there isn't much value in seeing the preview, so each preview is collapsible, using the summary/details element, and a configuration form controls which styles are expanded by default. A fairly simple idea, and a fairly simple module to build, so I was surprised that it didn't already exist.

I hope that these modules will be useful for you in your projects - please give them a try:

If you have any suggestions for improvement, please let me know using the issue queues.

Tags:  Capgemini Drupal open source development All tags
Categories:

Capgemini Engineering: There isn't a module for that already?

Planet Drupal - Fri, 2019/05/24 - 1:00am

Sometimes clients ask for the wrong thing. Sometimes developers build the wrong thing, because they didn’t ask the right questions. If you’re solving the wrong problem, it doesn’t matter how elegant your solution is.

One of the most important services that we as developers and consultants can provide is being able to help guide our clients to what they need, rather than simply giving them what they want. Sometimes those two things are aligned, but more often than not, figuring out the right thing to build takes some discovering.

Why don’t wants and needs match? It might be because the client hasn’t spent enough time thinking about the question, or because they haven’t approached it from the right angle. If that’s the case, we can help them to do that, either by asking the right questions or by acting as their rubber duck, providing a sounding board for their ideas. Alternatively, it might be because, as a marketing or content specialist, they lack sufficient awareness of the potential technological solutions to the question, and we can offer that.

Once you’ve properly understood the problem, you can start to look for a solution. In this article, I’ll talk about some examples of problems like this that we’ve recently helped clients to solve, and how those solutions led us to contribute two new Drupal modules.

There must be a module for that

Sometimes the problems are specific to the client, and the solutions need to be bespoke. Other times the problems are more general, and there’s already a solution. One of the great things about open source is that somebody out there has probably faced the same problem before, and if you’re lucky, they’ve shared their solution.

In general, I’d prefer to avoid writing custom code, for the same reasons that we aren’t rolling our own CMS. There are currently over 43,000 contributed modules available for Drupal, some of which solve similar problems, so sometimes the difficult part is deciding which of the alternatives to choose.

Sometimes there isn’t already a solution, or the solution isn’t quite right for your needs. Whenever that’s the case, and the problem is a generic one, we aim to open source the solutions that we build. Sometimes it’s surprising that there isn’t already a module available. Recently on my current project we came across two problems that felt like they should have been solved a long time ago, very generic issues for people editing content for the web - exactly the sort of thing that you’d expect someone in the Drupal community to have already built.

How hard could it be?

One area that sometimes causes friction between clients and vendors is around estimates. Unless you understand the underlying technology, it isn’t always obvious why some things are easy and others are hard.

XKCD -tasks

Even experienced developers sometimes fail to grasp this - here’s a recent example where I did exactly that.

We’re building a site in Drupal 8, making heavy use of the Paragraphs module. When adding a webform to a paragraph field, there’s a select list with all forms on the site, sorted alphabetically. To improve usability for the content editors, the client was asking for the list to be sorted by date, most recently created first. Still thinking in Drupal 6 and 7 mode, I thought it would be easy. Use a view for selection, order the view by date created, job done - probably no more than half an hour’s work. Except that in Drupal 8, webforms are no longer nodes - they’re configuration entities, so there is no creation date to order by. What I’d assumed would be trivial would in fact require major custom development, the cost of which wouldn’t be justified by the business value of the feature. But there’s almost always another way to do things, which won’t be as time-consuming, and while it might not be what the client asked for, it’s often close enough for what they need.

What’s the real requirement?

In the example above, what the content editors really wanted was an easy way to find the relevant piece of content. The creation date seemed like the most obvious way to find it. If you jump to a solution before considering the problem, you can waste it going down blind alleys. I spent a while digging around in the code and the database before I realised sorting the list wouldn’t be feasible. By enabling the Chosen module, we made the list searchable - not what the client had asked for, but it gave them what they needed, and provided a more general solution to help with other long select lists. As is so often the case, it was five minutes of development work, once I’d spent hours going down a blind alley.

This is a really good example of why it’s so important to validate your assumptions before committing to anything, and why we should value customer collaboration over contract negotiation - for developers and end users to be able to have open conversations is enormously valuable to a smooth relationship, and it enables the team to deliver a more usable system.

Do you really need square pegs?

One area where junior developers sometimes struggle is in gauging the appropriate level of specificity to use in solving a problem. Appropriate specificity is particularly relevant when working with CSS, but also in terms of development work more generally. Should we be building something bespoke to solve this particular problem, or should we be thinking about it as one instance of a more generic problem? As I mentioned earlier, unless your problem is specific to your client’s business, somebody has probably already solved it.

With a little careful thought, a problem that originally seemed specific may actually be general. For example, try to avoid building CMS components for one-off pieces of a design. If we make our CMS components more flexible, it makes the system more useful for content editors, and may even mean that the next requirement can be addressed without any extra development effort.

Sometimes there can be a sense that requirements are immutable, handed down from on high, carved into stone tablets. Because a client has asked for something, it becomes a commandment, rather than an item on a wish list. Requirements should always be questioned The further the distance between clients and developers, the harder it can be to ask questions. Distance isn’t necessarily geographical - with good remote collaboration, and open lines of communication, developers in different time zones can build a healthy client relationship. Building that relationship enables developers to ask more questions and find out what the client really needs, and it also helps them to be able to push back and say no.

Work with the grain

It can be tempting to imagine that the digital is infinitely malleable; that because we’re working with the virtual, anything is possible. When clients ask “can we do X?, I usually answer that it’s possible, but the more relevant question is whether it’s feasible.

Just as the web has a grain, most technologies have a certain way of working, and it’s better to work with your framework rather than against it. Developers, designers and clients should work together to understand what’s simple and what’s complicated within the constraints. Is the extra complexity worth it, or would it be better to simplify things and deliver value quicker?

Sometimes that can feel like good cop, bad cop, where the designers offer the world, and developers say no. But the point isn’t that I don’t want to do the work, or that I want to charge clients more money. It’s that I would much rather deliver quick wins by using existing solutions, rather than having developers spend time on tasks that don’t bring business value, like banging their heads against the wall trying to bend a framework to match a “requirement” that nobody actually needs. It’s better for everyone if developers are able to work on more interesting things.

Time is on my side

As an example of an issue where a little technical knowledge went a long way, we were looking at enabling client-side sorting of tables. Sometimes those tables would include dates. We found an appropriate module, and helped to get the Drupal 8 version working, but date formats can be tricky. What is readable to a human in one cultural context isn’t necessarily easy for another, or for a computer, so it’s useful to add some semantic markup to provide the relevant machine-readable data.

Drupal has pretty good facilities for managing date and time formats, so surely there must be a module already that allows editors to insert dates into body text? Apparently not, so I built CKEditor Datetime.

With some helpful tips from the community on Drupal Slack, I found some CKEditor examples, and then started plumbing it in to Drupal. Once I’d got that side of things sorted, I got some help from the plugin maintainer to get the actual sorting sorted. A really nice example of open source communities in action.

Every picture tells a story

Another challenge that was troubling our client’s content team was knowing what their images would look like when they’re rendered. Drupal helpfully generates image derivatives at different sizes, but when the different styles have different aspect ratios, it’s important to be able to see what an image will look like in different contexts. This is especially important if you’re using responsive images, where the same source image might be presented at multiple sizes depending on the size of the browser window.

To help content editors preview the different versions of an image, we built the Image Styles Display module. It alters the media entity page to show a preview of every image style in the site, along with a summary of the effects of that image style. If there are a lot of image styles, that might be overwhelming, and if the aspect ratio is the same as the original, there isn’t much value in seeing the preview, so each preview is collapsible, using the summary/details element, and a configuration form controls which styles are expanded by default. A fairly simple idea, and a fairly simple module to build, so I was surprised that it didn’t already exist.

I hope that these modules will be useful for you in your projects - please give them a try:

If you have any suggestions for improvement, please let me know using the issue queues.

There isn't a module for that already? was originally published by Capgemini at Capgemini Engineering on May 24, 2019.

Categories:

Lullabot: Lullabot Podcast: Layouts Revisited with Tim Plunkett

Planet Drupal - Thu, 2019/05/23 - 10:00pm

Mike and Matt invite Layout Initiative lead Tim Plunkett on the podcast to talk everything about Drupal's new Layout Builder, its use-cases, issues, and what's new in Drupal 8.7, and what's coming next!

Categories:

Dries Buytaert: Acquia delivers during Mueller report traffic surge

Planet Drupal - Thu, 2019/05/23 - 7:41pm

Last month, Special Counsel Robert Mueller's long-awaited report on Russian interference in the U.S. election was released on the Justice.gov website.

With the help of Acquia and Drupal, the report was successfully delivered without interruption, despite a 7,000% increase in traffic on its release date, according to the Ottawa Business Journal.

According to Federal Computer Week, by 5pm on the day of the report's release, there had already been 587 million site visits, with 247 million happening within the first hour.

During these types of high-pressure events when the world is watching, no news is good news. Keeping sites like this up and available to the public is an important part of democracy and the freedom of information. I'm proud of Acquia's and Drupal's ability to deliver when it matters most!

Categories:

Agaric Collective: How Stewarding the Digital Commons Keeps Your Software Secure, Stable and Innovative

Planet Drupal - Thu, 2019/05/23 - 5:54pm

We live amidst a Digital Commons - technology that is built with the principles of freedom and transparency baked into its code and design. It's maintained out in the open by the free software community. This commons is invisible to many of us, but the closer we are to the technology we use, the more that it comes into focus.We at Agaric are knee deep in this Digital Commons. Our name Agaric is a nod to the mycelial nature of the open web. We help create, maintain, and promote free and open-source software that make up this commons.

Read more and discuss at agaric.coop.

Categories:

Web Wash: Using Pattern Trigger (Regex) in Webform Conditional Logic in Drupal 8

Planet Drupal - Thu, 2019/05/23 - 4:15am

When you need to create survey style forms in Drupal 8 Webform is the clear winner. It's powerful enough to create all sorts of forms and you can even give it to your editor so they can create their own, after a little training, of course.

One part of Webform which I like is the ability to define conditional logic. For example, you can show or hide a text field based off a value from another element. You can also make an element conditionally required. It's a very useful part of Webform, and you do all of this through a UI, no custom code.

Defining simple conditional logic, check if element value has a single value, is pretty straightforward. But when you have to deal with multiple values, this is where things get tricky.

Categories:

TEN7 Blog's Drupal Posts: Episode 060: A Recap of Drupaldelphia 2019

Planet Drupal - Wed, 2019/05/22 - 5:44pm

In this week’s podcast TEN7’s DevOps Tess Flynn aka @socketwench is our guest, giving us her observations of the Drupaldelphia 2019 conference she recently attended, as well as a summary of her helpful session, “Return of the Clustering: Kubernetes for Drupal.”

Host: Ivan Stegic
Guest: Tess Flynn, TEN7 DevOps

In this podcast we'll discuss: 

Categories:

InternetDevels: Drupal multisite: how it works and when it is the best choice

Planet Drupal - Wed, 2019/05/22 - 3:40pm

Drupal allows to find the most effective solution for every business case. Large organizations often need more than one website but a collection of related sites, which would be easy to manage. To meet this need, there is the Drupal multisite feature that has become popular among education websites, government websites, corporate websites, and so on. Let’s explore what Drupal multisite is, how it works, and when it is the best choice.

Read more
Categories:

Lullabot: A Patch-less Composer Workflow for Drupal Using Forks

Planet Drupal - Wed, 2019/05/22 - 2:46pm

One of the significant advantages of using free and open-source software is the ability to fix bugs without being dependent on external teams or organizations. As PHP and JavaScript developers, our team deals with in-development bugs and new features daily. So how do we get these changes onto sites before they’re released upstream?

Categories:

OpenSense Labs: The Alternatives in Decoupled Drupal Ecosystem

Planet Drupal - Wed, 2019/05/22 - 2:34pm
The Alternatives in Decoupled Drupal Ecosystem Shankar Wed, 05/22/2019 - 22:48

More and more users want the content to be available via a host of different devices. Various new interfaces and devices are thronging the technology landscape and are touted to bring about sweeping changes. There are even talks of website-less future. Smart wearables, Internet of Things, conversational user interface etc. have been gaining traction and are changing the way we experience the internet. New web-enabled devices need the content that the websites do but in a different format which creates complications in the way we develop. Disseminating content can have different needs from one setup to another.


The content management system (CMS) is rife with labels such as ‘decoupled’ and ‘hybrid’ which requires to be dissected for a better understanding of their benefits. Decoupling the backend of a content management system (CMS) from the frontend can be a remarkable solution for a lot of issues that are caused when you move away from standard website-only deliveries. Decoupling the CMS streamlines the process of republishing the content across numerous channels ranging from websites to applications. Decoupled CMS is not new, but as the digital arena observes changes, it gets more and more important.

The Drupal Connect Source: Dries Buytaert’s blog

As one of the leaders in the CMS market, Drupal’s content as a service approach enables you to get out of the page-based mentality. It gives you the flexibility to separate the content management from the content display and allows you the front-end developers to build engrossing customer experiences.

Decoupled Drupal implementations are becoming ubiquitous due to its immense capability in giving a push to digital innovation

Decoupled Drupal implementations, which involves a full separation of concerns between the structure of your content and its presentation, are becoming ubiquitous due to Drupal’s immense capability in giving a push to digital innovation and being a great solution in adopting novel approaches.

Drupal Community has been working on a plenitude of API-first architectures by utilising its core REST, JSON:API and GraphQL features. But there are alternative solutions, too, available in decoupled Drupal ecosystem that can be of great significance. Let’s explore them:

RESTful Web Services and others

While RESTful Web services module helps in exposing entities and other resources as RESTful web API and is one of the most important modules when it comes to decoupled Drupal implementation, there are several others that can come handy as well.

Implementing the Apache CouchDB specification and focussing upon content staging use cases as part of the Drupal Deploy ecosystem, RELAXed Web Services module can be of immense help. The CouchDB helps in storing data within JSON documents that are exposed via a RESTful API and unlike Drupal’s core REST API, it enables not just GET, POST, DELETE but also PUT and COPY.

There’s a REST UI module that offers a user interface (UI) for the configuration of Drupal 8’s REST module. You can utilise Webform REST module that helps in retrieving and submitting webforms via REST. For protracting core’s REST Export views display in order to automatically converting any JSON string field to JSON in the output, REST Export Nested module can be useful. By offering a REST endpoint, REST menu items module can be helpful in retrieving menu items on the basis of menu name. And when you need to use REST for resetting the password, REST Password Request module can be helpful. It is worth noting that Webform REST, REST Export Nested and REST Password Request are not covered by Drupal’s security advisory policy but are really valuable.

JSON:API and others

JSON: API module is an essential tool when you are considering to format your JSON responses and is one of the most sought after options in decoupled Drupal implementations. But there is, again, plenty of options for availing more features and functionalities. 

When in need of overriding the defaults that are preconfigured upon the installation of JSON: API module, you can leverage JSON: API Extras. By offering interfaces to override default settings and registering new ones that the resultant API need to follow, JSON: API Extras can be hugely advantageous in aliasing resource names and paths, modifying field output via field enhancers, aliasing field names and so on. There is JSON API File module that enables enhanced files integration for JSON: API module. And for the websites that expose consumer-facing APIs through REST, JSON: API or something similar, Key auth module offers simple key-based authentication to every user.

For streamlined ingestion of content by other applications, Lightning API module gives you a standard API with authentication and authorisation and utilises JSON: API and OAuth2 standards through JSON API and Simple Oauth modules.

GraphQL and others

GraphQL module is great for exposing Drupal entities to your GraphQL client applications. There are some more useful modules based on GraphQL. To enable integration between GraphQL and Search API modules, there is a GraphQL Search API module. Injecting data into Twig templates by just adding a GraphQL query can be done with GraphQL Twig module. To expose Drupal content entity definitions through GraphQL via GraphQL Drupal module and develop forms or views for entities via front-end automatically, you have GraphQL Entity Definitions module.

OpenAPI and related modules

OpenAPI describes RESTful web services on the basis of the schema. There is OpenAPI module in Drupal, which is not covered by Drupal’s security advisory policies but can integrate well with both core REST and JSON: API for documentation of available entity routes in those services. And for implementing an API to display OpenAPI specifications inside a Drupal website, you get OpenAPI UI module. And ReDoc for OpenAPI UI module offers the ReDoc library, which is an Open API/ Swagger-generated API reference documentation, for displaying Open API specifications inside Drupal website. Then there is Swagger UI for OpenAPI UI module that gives you Swagger UI library in order to display OpenAPI specifications inside Drupal site. You can also utilise Schemata module that provides schemas for facilitating generated documentation and generated code.

Contentajs and related modules

The need for a Nodes.js proxy that acts as middleware between Drupal content API layer and Javascript application can be addressed with the help of Contenta.js.  For Contenta.js to function properly, Contenta JS Drupal module is needed. This module is part of the Contenta CMS Drupal distribution. The Node.js proxy is essential for decoupled Drupal because of data aggregation, server-side rendering and caching. Contenta.js constitutes multithreaded Node.js server, a Subrequests server for the facilitation of request aggregation, a Redis integration and simple approach to CORS (Cross-origin resource sharing).

There are several effective modules that are part of the Contenta CMS decoupled distribution and integrates perfectly with Contenta.js. You have Subrequest module that tells the system to execute multiple requests in a single bootstrap and then return everything. JSON-RPC module offers a lightweight protocol for remote procedure calls and serves as a canonical foundation for Drupal administrative actions that are relied upon more than just REST. To resolve path aliases, Decoupled Router module gives you an endpoint and redirects for entity relates routes.

In order to enable decoupled Drupal implementations to have variations on the basis of consumer who is making the request, you can use Consumers module. You can use Consumer Image Styles that integrates well with JSON: API for giving image styles to your images in the decoupled Drupal project. And there is Simple OAuth module for implementing OAuth 2.0 Authorisation Framework RFC.

Of relating to JavaScript frameworks

Decoupled Blocks module is great for progressive decoupling and enables front-end developers to write custom blocks in whatever javascript framework that they prefer to work on. If you want to implement using Vue.js, you can use Decoupled Blocks: Vuejs. It should be noted that both of these are not covered by Drupal’s security advisory policies.

React Comments comes as a drop-in replacement for the Drupal core comment module frontend.

Also, there is a jDrupal module, which is a JavaScript library and API for Drupal REST and can be leveraged for Drupal 8 application development.

Conclusion

With Drupal as the decoupled web content management, developers can get to use a plentitude of technologies to render the front end experience.

RESTful web services, GraphQL and JSON: API are not the only resources that you get in the decoupled Drupal ecosystem. In fact, there are plenty of other alternatives that can be of paramount importance.

Drupal development is our forte and bringing stupendous digital experience to our partners has been our prime objective. Contact us at hello@opensenselabs.com and let us know how you want us to be a part of your digital transformation goals.

blog banner blog image Decoupled Drupal Drupal module Blog Type Articles Is it a good read ? On
Categories:

Srijan Technologies: Layout Builder: A DIY Tool to Design a Website with Drupal 8

Planet Drupal - Wed, 2019/05/22 - 1:37pm

There's this millennial phrase "You snooze, you lose" and nowhere is it more applicable than for enterprises today. Opportunities to engage with your audience pop up fast and disappear faster, and you have to act quickly if you wish to leverage any of it. 

Categories:

Wim Leers: API-First Drupal: what's new in 8.7?

Planet Drupal - Wed, 2019/05/22 - 1:00pm

Drupal 8.7 was released with huge API-First improvements!

The REST API only got fairly small improvements in the 7th minor release of Drupal 8, because it reached a good level of maturity in 8.6 (where we added file uploads, exposed more of Drupal’s data model and improved DX.), and because we of course were busy with JSON:API :)

Thanks to everyone who contributed!

  1. JSON:API #2843147

    Need I say more? :) After keeping you informed about progress in October, November, December and January, followed by one of the most frantic Drupal core contribution periods I’ve ever experienced, the JSON:API module was committed to Drupal 8.7 on March 21, 2019.

    Surely you’re know thinking But when should I use Drupal’s JSON:API module instead of the REST module? Well, choose REST if you have non-entity data you want to expose. In all other cases, choose JSON:API.

    In short, after having seen people use the REST module for years, we believe JSON:API makes solving the most common needs an order of magnitude simpler — sometimes two. Many things that require a lot of client-side code, a lot of requests or even server-side code you get for free when using JSON:API. That’s why we added it, of course :) See Dries’ overview if you haven’t already. It includes a great video that Gabe recorded that shows how it simplifies common needs. And of course, check out the spec!

  2. datetime & daterange fields now respect standards #2926508

    They were always intended to respect standards, but didn’t.

    For a field configured to store date + time:

    "field_datetime":[{ "value": "2017-03-01T20:02:00", }] ⬇ "field_datetime":[{ "value": "2017-03-01T20:02:00+11:00", }]

    The site’s timezone is now present! This is now a valid RFC3339 datetime string.

    For a field configured to store date only:

    "field_dateonly":[{ "value": "2017-03-01T20:02:00", }] ⬇ "field_dateonly":[{ "value": "2017-03-01", }]

    Tme information used to be present despite this being a date-only field! RFC3339 only covers combined date and time representations. For date-only representations, we need to use ISO 8601. There isn’t a particular name for this date-only format, so we have to hardcode the format. See https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates.

    Note: backward compatibility is retained: a datetime string without timezone information is still accepted. This is discouraged though, and deprecated: it will be removed for Drupal 9.

    Previous Drupal 8 minor releases have fixed similar problems. But this one, for the first time ever, implements these improvements as a @DataType-level normalizer, rather than a @FieldType-level normalizer. Perhaps that sounds too far into the weeds, but … it means it fixed this problem in both rest.module and jsonapi.module! We want the entire ecosystem to follow this example.

  3. rest.module has proven to be maintainable!

    In the previous update, I proudly declared that Drupal 8 core’s rest.module was in a “maintainable” state. I’m glad to say that has proven to be true: six months later, the number of open issues still fit on “a single page” (fewer than 50). :) So don’t worry as a rest.module user: we still triage the issue queue, it’s still maintained. But new features will primarily appear for jsonapi.module.

Want more nuance and detail? See the REST: top priorities for Drupal 8.7.x issue on drupal.org.

Are you curious what we’re working on for Drupal 8.8? Want to follow along? Click the follow button at API-First: top priorities for Drupal 8.8.x — whenever things on the list are completed (or when the list gets longer), a comment gets posted. It’s the best way to follow along closely!1

Was this helpful? Let me know in the comments!

For reference, historical data:

  1. ~50 comments per six months — so very little noise. ↩︎

Categories:

Kalamuna Blog: The Giving Tree Called DrupalCon

Planet Drupal - Tue, 2019/05/21 - 11:26pm
The Giving Tree Called DrupalCon Ken Lo Tue, 05/21/2019 - 14:26

As a digital agency, we believe it’s important to remember the world that exists beyond our JIRA boards. We feel a genuine responsibility to always try to do something that can be of service to the greater good; especially when the opportunity to give a damn is so constant and pervasive.

Categories Community Conferences Drupal Fun Author The Kalamuna Team
Categories: