Planet Drupal

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

OpenSense Labs: How to implement Configuration management strategies in Drupal 9?

Mon, 11/02/2020 - 14:11
How to implement Configuration management strategies in Drupal 9? Shalini Rawat Mon, 11/02/2020 - 18:41

Configuration management is an increasingly important foundation in the technology world that is supposed to solve all the woes faced by modern Content Management Systems (CMS). Be it Drupal or any other CMS, configuration management has made things easier than ever before and has positively impacted business and its related activities. There is no denying the fact that configuration management is important for any business as the term configuration is what makes your system work. 

With the increase in the number of Drupal 9 installations, there is a simultaneous increase in the number of burning questions on Drupal 9 that have sprung up. One of the key questions is around Drupal 9 configuration management strategies. However, configuration management in Drupal 9 is not as easy as upgrading to Drupal 9.

Therefore, if you are here to know what it takes to implement Drupal 9 configuration management strategies, then you are in luck! In this blog, we will be giving a detailed insight into Drupal 9 management strategies, followed by the factors to drive the same. But before we start, let’s take a step back and understand what configuration management actually is all about in Drupal. 

Configuration Management: An overview

To begin with, configuration management is a form of IT service management that is held responsible to establish and maintain the consistency of a product's performance, functional, and physical attributes with regards to the requirements, design, and operational information throughout its lifecycle. The prime objective of configuration management is to make sure that you can review, test, and predictably deploy all configuration changes to production environments.  

The configuration is the collection of admin settings that determine how the site functions, as opposed to the content of the site which is typically captured and deployed through YAML files. In Drupal, site configuration data is stored in a consistent manner which typically includes everything, right from the list of enabled modules to content types, taxonomy vocabularies, fields, and views. Configuration management has come a long way in the Drupal world. In other words,  the former has undergone necessary changes and has transformed a lot from what it was in Drupal 7 and Drupal 8. 

In Drupal 7, both configuration and content were kept safe in the database. As a result, contributed modules like Features were assigned the task of moving configuration to other environments. Drupal 7 configuration was going well, however, the configuration wasn’t effortless as it could be which eventually led to the change in configuration management in the later version i.e. Drupal 8.

Drupal 8 being the latest configuration improvement after Drupal 7, was able to deliver better and faster configuration management. In Drupal 8 Core, configuration for most site settings as well as for the definition of structural pieces can be exported easily with one click of a button or a single drush command. Further, you were allowed to commit and merge configuration changes in source code control, deploy the configuration, and then import it into the destination environment. Having a configuration management roadmap also helped with improvements made in Drupal 8 releases. For instance, the support for creating new sites from existing configuration was included in Drupal 8.6.

Configuration management strategies in Drupal 9

Drupal 9 configuration management is a bit rough process that comes along with some problems to wrestle with. In other words, there are some significant challenges in the pathway of Drupal 9 configuration management that do require some additional strategy or planning to better understand how you will utilize the configuration management system. Some common configuration strategies include the following-

1.  Apply Complete Config Sync:

Overview:

  • all configuration is transferred into a configuration sync directory 
  • config split and config ignore enhances the core config system
  • drush manages config imports/exports
  • ideal automated config imports during deployments
  • config imports should occur following database updates

Appropriate for both site and profile config splits, this strategy can work wonders when you have a common set of configurations (90% or greater) that is shared across all splits and further deploys the split and/or config ignore to handle specific cases wherever necessary. Not to mention, this strategy can go wrong if you have a large platform and each profile/site has a large quantity of unique/bespoke configuration. 

2.  Apply Partial Config Sync:

Overview:

  • config is kept in module/profile/theme config directories and installed only when the respective parent container is installed
  • database updates and drush make the necessary updates to config 
  • contributed modules such as config split/config ignore are generally not required 

Regardless of being flexible in nature, this strategy often ends up with multisite platforms which are almost impossible to update owing to the unintended consequences of changes and development. Moreover, unlike the monolithic approach, the partial approach does not have paradigms that can help you keep troubles at bay. As a result, this strategy puts you in a predicament which is certainly difficult to get rid of. 

Factors to consider while formulating a strategy

One of the biggest mistakes that any developer can make is to start planning without considering the best factors. Sounds bizarre? Well, this happens for real. It has been observed that most of the Drupal-based sites value the end-product more than what they have on their plate because of which the development team leads to failure. 
 
As a matter of fact, creating the product breakdown structure i.e. pre-considering the necessary factors can help you deliver the end product in the most efficient manner. There are three key factors that are of supreme importance and required to be considered.

Differentiate between a single site, multisite and many sites

Configuration management strategies in Drupal 9 are highly driven by the architectural considerations and decisions that cannot be overlooked.   

  • Single Sites: It includes one single site running a single codebase, database, and file system.
  • Multisites: It includes sites with a single codebase but separate databases and file systems.
  • Many Sites: It includes sites with separate codebases, databases, and file systems that still somehow derive from a templated/distributed codebase.

Note: While a single site may consume the configuration stored in their codebases entirely, multisites and many sites are much less straightforward and have at least some varied config.

Find variation in features

Next in the row is feature variation which focuses on the commonality of features that you provide on your platform. 

For example- you are building a multisite codebase where your customers want to have a hero carousel but have clashes relating to the hero banner. One of the customers demands a horizontally scrolling carousel with a background image and call to action. On the contrary, another customer demands a vertically scrolling carousel with a background video. In such a scenario, a common feature is a carousel that needs to be taken into consideration while creating a configuration management strategy. There are two ways to perform this- 

  • Build two hero carousels that offer the same things with little or variation.
  • Build one hero carousel that offers a few extra fields to allow changing the scroll direction, background type, etc.
Group the identified features 

Once you have successfully identified the features, it’s time for you to invest some time in grouping these features. Generally feature grouping falls under four major categories.  

  • All Drupal sites share the same config 
  • Sites are categorized into profiles/distributions. Further sites within these groups share the same config 
  • Regardless of the fact that each site requires individual configuration, they still share the majority of their config 
  • Each site possesses bespoke configuration and is entirely unique in nature.
Tools of the trade

When it comes to Drupal 9, formulating a configuration management strategy won’t suffice. That is to say, you might need to arm yourself with some key modules/approaches that can help you sail through the complex Drupal process. In a separate blog, we listed down the must-have modules to start your Drupal 9 project. Here, we will throw light on some Drupal 9 modules that will help strengthen your configuration management strategies. Let’s have a look at them. 

Configuration Split Module

The config split module enables you to define sets of configurations that are required to be exported to separate directories when exporting and get merged together when importing. Further, you can also define in settings.php which of these aforesaid sets should remain active and further consider for the export and import.

Configuration Ignore Module

The config ignore module is basically a tool that helps you keep the configuration you want, in place. If you would like the system.site configuration (including the site name, slogan, email, etc.) to remain untouched, on your live site, no matter what the configuration in the config folder is, then this module is what you are looking for. Also, this module is the best way to save yourself from the grueling devel settings that change every time you import configuration.

“Installed” Configuration 

Tied up with a module/theme/profile, this config is installed when that thing is installed. Not to mention, the feature module uses the same approach that the installed config uses. 

Conclusion

To conclude, we hope this article has summed up everything that you have been looking for. While Drupal 9 configuration management is still a complex process, it is indeed a great step forward in a world that constantly undergoes technological shifts. Further, configuration management in Drupal 9 requires a team of professionals that are proficient enough to understand how configuration management works, what is it capable of, where its shortcomings are, and how to merge and resolve conflict. 

Want to learn more about Drupal 9 configuration management? Contact us at hello@opensenselabs.com and our industry experts will help you spot and resolve the issues encountered at the strategy stage.

blog banner blog image Drupal Drupal 9 Drupal modules Configuration Management Blog Type Articles Is it a good read ? On

Centarro: Centarro joins the virtual DrupalCamp Oslo 2020

Sat, 10/31/2020 - 18:33

Like many other events, DrupalCamp Oslo went virtual this year. In person events are still my favorite, but this did give me the chance to participate in the event for the first time! I joined in to provide an update on the state of the API-First work in the Drupal Commerce ecosystem.

We were excited to take part in the event, as we've often collaborated with the Norwegian Drupal team at Ny Media on Drupal Commerce contributions and on the occasional client project. One of our favorite outcomes was the Commerce Pricelist port to Drupal 8 developed as part of the Akademika.no case study.

We've been busy developing Centarro Commerce, our headless commerce SaaS, which means expanding the API-First capabilities of Drupal Commerce. For instance, we just added support for on-site payment gateways over our Commerce API. We also expanded our shipping integration with the ability to trigger shipment notifications in the latest Commerce Shipping release.

DrupalCamp Oslo was live-streamed on YouTube, so you can catch my talk about "API Driven Drupal Commerce" on the recording.

Read more

OSTraining: OSTips - Check Modules and Themes for Move to Drupal 9

Fri, 10/30/2020 - 16:10

We all know that Drupal 9 is here, but is your site ready?

In this video, I'm going to share with you 3 ways to check to see if your modules and themes are ready to move to Drupal 9.

Alright, let's go.

OpenSense Labs: The Collaboration Between Designers And Developers During Code Review

Fri, 10/30/2020 - 14:09
The Collaboration Between Designers And Developers During Code Review Tuba Ayyubi Sat, 10/31/2020 - 01:15

Code reviews help in identifying bugs before the testing phase. Many people skip this step and think of it as an ongoing practice during the development stage but code reviews have proven to be a great assurance strategy. Getting your work reviewed and reviewing other people’s work is an excellent way to learn and grow. 

A collaborative environment among different teams is the need of the hour. Today, when things have gone digital, collaboration and communication gaps need to be given more importance to keep the workflow consistent. 

A happy and smooth collaboration between the designers and developers is important but is a little difficult. The idea of someone else reviewing your work might sound scary. For a designer, having someone not as creative review their work is like a threat to their creativity. And likewise, for a developer, getting their codes and programs reviewed by a designer is not easy to take. But if you think of it as many ideas coming from different sources and collaborating together to make something bigger and better, it will be easier for you to let other people look into your work.

So how do we get the two teams to get along? We will get to it, but first, let’s look at why and how code review is important.

Why do a code review? 

When you have someone who reviews your work, and also when you know someone is going to review your work, helps in increasing the quality of your code and makes it an error-free one. According to The 2018 State of Code Review by SmartBear, 73% of people said that code review helps share knowledge across their team and 53% said that code reviews help in mentoring less experienced developers.

Code review plays an important role in building a collaborative culture among the team members. When more than one person is involved in a code review process, it should not just be 'my code' or 'your code', it should become 'our code'.

A few principles that need consideration are as follows: 

  • Face to face discussions.
  • Feedbacks should be given for the work and not the author.
  • Never forget to praise the good.
  • Suggest, Don’t command.

These principles, if followed, make code review a positive force instead of a negative and disappointing one. The teams must allow each other to ask questions and clear their doubts without any hesitation and keep motivating each other to build something great together.

If doing a review holds such advantages, why only do it for code?

For a business to run efficiently, the design and development teams need to come together. And to truly maximize the outcomes, the teams should be able to work as teams. Collaboration, communication, and consistency have to be a part of the process. If this is not done, you will have to deal with frustrated team members, unhappy clients, lengthy rants, many missed deadlines, and whatnot. To stop such things from happening, let’s look at these steps that will help in strengthening the collaboration between designers and developers. Learn more about the importance of code review here.

Steps to consider for the designers for the code review process
Kickoff calls

It’s important to understand your client’s requirements, but along with that, it is also important for the team to understand every little detail of the project.

Before starting any review, all of the team members should make sure that they are on the same page and are clear about the objectives and the details of the project. To ensure this, start every project with a kickoff call. This will clear any doubt or concerns before starting the review. 

All the phases of the project should be organized in a way that is understandable by everyone.

Information sharing

You might have someone to research or look for little details around the project, but this is an important step that needs both designers and developers to research, as it lays the groundwork for all the decisions that are made for the project later during the review. Everyone involved should have information beforehand about the project. 

The developer should be made aware of the initial plans so that if any of the ideas cross the limitations of the project, they can be removed before initiating the review. Remember, finding defects before launching is what we need to do. And also, verify that those defects are fixed, not just found. Once you have sorted them out, you can start driving meaningful process improvements. 

Designing

This is the phase where the designer works alone. Here the designer needs to work on the components that have already been approved by the developer. This will make sure that there is a consistent pattern and the basic elements hold on to the best practices. 

This helps the designer to focus on the designing part and create the best user experience. There is nothing for them to worry about building anything from the base. 

Prototyping

Once the designer is done with the designing part, the project needs to be pushed for feedback. Instead of sending screenshots of the project, it's better to send a functioning version that the reviewers can interact with.

In this phase, the developer needs to be a part of the review process too. So, in case there is an issue about how a design will be implemented, the developer can sort it out before development starts.

The Handoff 

After the review of the prototype is done, you have successfully cleared the first step that decreases the gap between designers and developers. This step involves testing each other's work for both designers and developers. There are many tools out there that do the work for them, such as, Sketch, InVision, and Unite UX.

The designers have to layout the design specifications, that include:

  • Font size and styles
  • UI functionality
  • Typography
  • HEX codes
  • User flows
  • Row and column layouts
  • Spacing
Building

With the help of certain tools, the developers now don't need to worry about the process of translating design into code. These tools fully optimize the time that your team spends on code reviews. They don't have to download and translate everything on their own. They can easily focus on refining the final product, programming functionality, and connecting the right data sources.

Testing

This is an important step and skipping this is as big a risk as skipping the complete code review process. The designer needs to be involved with the app during the QA phase. The tools will help in simplifying things down, but the designer's approval plays an important role in the end product. This is where the designer’s and developer’s patience comes into light. 

You both need to trust each other and give each other time to understand each other’s work. You need to respect each other’s disciplines so that you can both give and receive criticism on each other’s work positively. You don’t really have to master these abilities, but you have to consider them to maintain a healthy environment and do beneficial reviews.

Launch

This stage is all about reviews and feedback. It brings two teams together for one last before the project closes. The developer is responsible for the execution of the app. Designers and developers should discuss what went wrong, what could have been done, the improvements, the losses, and several ways that will strengthen their work in future projects and give better results. Read more about incorporating healthy code review approaches here.

Wrapping up

The designer-developer gap needs to be fixed and we hope that these steps will help you gain a better perspective and help teams collaborate better.

Never forget to appreciate each other’s work. Make the code review process a positive one instead of a demotivating one. Make sure that this gap doesn’t become a roadblock for the amazing ideas in your head. 

Let’s remember one thing: Good ideas always survive reviews!

blog banner blog image Code review web development Web Developer Design Web Designer Blog Type Articles Is it a good read ? On

OpenSense Labs: When to Move From Monolithic to Decoupled Drupal Architecture?

Fri, 10/30/2020 - 14:09
When to Move From Monolithic to Decoupled Drupal Architecture? Gurpreet Kaur Fri, 10/30/2020 - 20:39

Building websites is not uncommon today, but what might be uncommon is building websites that will set the benchmark for all others to follow. Just stuffing your site with features on top of features is not going to achieve that benchmark, what may achieve it is the understanding of the needs and requirements of your business and consequently your site. The more the merrier is a great ideology to live by in life, but sometimes a website needs you to hold back your horses. 

If I talk about Drupal websites specifically, there are two roads to choose from while building them. You can either choose the traditional Drupal, which will encompass your whole site and build it from the ground up or you can choose to capitalise Drupal in parts as you may see fit and take leverage of other front end technologies as well, which forms the Decoupled Drupal

This scenario is often considered as crossroads for many and choosing either of the two becomes an insurmountable task. With numerous questions running through the web builders’ minds like;

When is the monolithic Drupal architecture appropriate and when it isn’t?
When is the decoupled Drupal architecture needed?
What are the benefits of the decoupled Drupal architecture and are there any drawbacks?

To appease all of your worries, I am going to go into the nitty gritty details to make your decision of moving from the Monolithic architecture to the Decoupled architecture an easy one. All you have to do is sit back and read. Before that, you can check out the difference between monolithic and decoupled Drupal architectures here.

The Monolithic Suitability  

Before making the pivotal call of switching to the Decoupled architecture, you have to analyse whether your current architecture is really in need of a change or not. A move to the Decoupled Drupal is going to cost you, in terms of money, time and efforts of your entire team, and if you realise later on that the advantages of the Monolithic Drupal architecture were working just fine for you, now that would be a situation you would definitely not want to find yourself in.


So, let us understand suitability and appropriateness of the traditional Drupal approach by asking ourselves all the right questions and take it from there. 

Are you comfortable with using Drupal as is?

The traditional Drupal comes equipped with a lot of modules that enhance the functionality of your front end with just a click of the mouse. From making images turn into presentations to installing Google maps on your website, everything can be done by turning on the module provided for the specific need. If you are comfortable with this sort of system and website is doing well, you should stick to the monolithic approach.

What if you only have the most basic editorial needs?

The editorial needs are different for different categories of websites. Some rely highly on user interactivity and some don’t. In the latter’s case, decoupling is not required.  A news or a blogging site needs to have simplified features like content preview, layout management and in-line editing. With decoupling, these become complex and would only hamper the performance. If you cannot afford the added complexity, Monolithic approach would be more suitable to you.

Is it worth it for you to lose functionality?

The Decoupled approach essentially makes you part with some of the best Drupal features. If losing them is not worth it for you, you must reconsider the move. Certain features like UI localisation, account management screens and cross-site scripting, which enhances security, are inherent in Drupal and cannot be paralleled by a client-side framework. 

What is your budget constraint?

Drupal, being an open source software, is free. So, the traditional Drupal approach does not make you stretch your budget at all. However, the same cannot be said for the decoupled architecture. Not only would the development cost be high, but the maintenance costs will also be considerable. After all, you would be paying for experienced developers for their front end knowledge. So, can your budget handle that? 

Can you manage multiple teams? 

The coupled Drupal does not need multiple teams to manage the front and back ends, one team can do it all and managing one team is better than multiple teams. It is because communication and coordination is a given in a single team. Data models would be decided by it, endpoints would be created by it and tested by it without the involvement of a whole other department. If things are working for you this way and you know managing multiple teams or hiring different companies for the different aspects would be too much for you, the coupled Drupal is best for you.

Are your needs aligned with the Monolithic architecture’s frontend capabilities? 

This is the final question to ask. If the answer is yes, you should not make the move to the decoupled architecture. And if you know that you need more than the traditional Drupal can give you, like more control over the presentation layer, you must take the steps to make the switch.

The Decoupled Necessity 

Now that you know when the coupled Drupal is suitable, it is time to focus on the Decoupled approach. Like we have discussed above, the Decoupled approach becomes a tad bit more complicated to handle, yet website developers have been taking it up and with good reason. The decoupled approach counters all the pitfalls that the traditional approach may bring on you. And that is why it is often regarded as a need, which cannot be neglected. 


So, let us find out exactly when is the Decoupled Drupal architecture needed.

Do you wish to cater multiple channels and microsites?

The primary reason for choosing Decoupled architecture is the fact that it allows you to pull multiple content from its content repository and use it across varying channels. Many businesses often have multiple websites called microsites that they have to build on the go. In such situations Drupal becomes a need, because even if the microsites are no longer needed, the content would always be stored on it. Even if a brand wants to transcend its line of communication with its users past its website, Drupal can make it happen solely as a backend operator.

Do you wish to fancy up your website to be more interactive?

Making a web project increasingly interactive has become the need of the hour today. A web project needs to have an app like interaction with animations and transitions. Having complex user flows is also welcome. All of this means you will have to fancy up the code building your website with advanced JavaScript frameworks. Angular, Vue and React can easily do that and make your UI both elegant and interactive with the Decoupled approach.

Do you wish to benefit from diversification? 

Diversification of team in developing web applications may seem like too much of a challenge, but it is a challenge worth taking. The world is filled with experienced developers, who know what they are doing on the frontend, specialising in each and every aspect of the same. And if you look at Drupal specialists, the number isn’t as impressive as the former. So, if you want to benefit from the collaboration of various teams and get the best possible results, the Decoupled approach becomes necessary. A team with thorough knowledge of both Drupal for the backend and JavaScript and static site generators for the front end will essentially make you experience a result like never before.

Do you wish to become more independent?

If you use Drupal both for the front and backend, your project would be entirely dependent on it. There are developers who are alright with being reliant on one technology and there are developers who aren’t. If you fall in the latter category, the decoupled approach lets you be independent on the presentational aspect of your project. You can use other technologies and become as dynamic as you want to be. Such self-reliance also makes redesigning more convenient than it otherwise would be.

Plus, having free reigns over the front end is definitely going to give you the liberty to try out all of the latest and trending technologies there.

Do you wish to build an application?

If you are planning to build an app of your own, the Decoupled approach can be of great help for you. It can easily manage your content, data and even the users, while you focus on the presentation layer worry free.

Do you wish to not use all of Drupal’s frontend assets?

Drupal has numerous in-built features. From node edit screens to node view pages and admin screens, the list is quite extensive. What often happens is that all of these features become a burden and working around Drupal’s numerous screens becomes problematic. If you use Drupal just as a content repository, you would not have to worry about this hassle. You will be able to create with only what you want on the front end and still be able to tap Drupal’s impressive backend capabilities with the Decoupled Drupal architecture. Read more about the different options of decouplin Drupal here

The Decoupled Bonuses 

If your needs match to the ones that are mentioned above, then it is time to switch to Decoupled Drupal and it would be a prudent investment to make. The benefits of the Decoupled Drupal architecture are not just for the developers, it is for everyone involved in the web projects, the marketers included. The entire business feels the advantageous energy, when decoupling has been taken up.  

Write once, publish everywhere

Websites are dependent on their content as much as they are dependent on their performance. With the decoupling of Drupal, you get an opportunity to make your content shine and that too in more than one place. The diverse online mediums, encompassing all IOT devices, can easily be taken advantage of by a few clicks. The impressive blog that you just wrote for your primary website need not be limited to it, it can be published simultaneously to your microsites and your social media accounts amongst other platforms. This is what is meant by “write once, publish everywhere.”


Improves user experience

The people who are going to use your website are the ones who need to be kept in mind when building it, so user experience is a key aspect. With the decoupled Drupal, you can build the UX of your site specifically for the needs of the user and shine. Let us try to understand how it can happen in the decoupled Drupal and not in the conventional one. Take a website that mandates constant re-rendering of content as an illustration. Now you tell me, is Drupal more equipped to handle such a need or is JavaScript the better option? I am sure you would go with JS because that is its forte. And decoupling lets you choose JS as many times as you want, leading to a better experience for your audience.

Moreover, UX is directly related to the performance of websites, which also improves through decoupling, although some might contend it. See when you decouple, you get more control and flexibility over the front end. With the client-side framework at work here, the request time lessens and can any user be possibly unhappy with that?

Capitalises JavaScript Framework

When creating interactive websites is at play, it pains me to say it but Drupal may seem a little underwhelming. It is JavaScript that can make the feat of interactivity on websites seem like a walk in the park. With JavaScript’s ES6 version and all its new features like destructed assignment and arrow functions, developers can get things done smoothly and swiftly. The traditional architecture will not let you do that. Since businesses all over the world are becoming reliant on interactive websites, the fully decoupled Drupal is becoming more and more appealing.

Gets work done faster 

I believe I have said this more than a couple of times and I need to say it again; the separation of front end and back end lets the developers work at their own pace. By decoupling Drupal, you will be speeding up your development process because it provides a clear separation between duties and work is done faster. The front-end will simply work on the UI and the backend will keep working in parallel to create suitable data structures for the former. So, your developers will be working at the same time and getting things done with no interruptions in their work. 

Another way to understand this is, content creators will not need to focus on the presentational aspects and the front end developers do not need to worry about the semantics of the content fields or their relationships. The former will work on the content and the latter would oversee the styles and layout tweaks. At the same time, a backend developer would not concern himself with the way a data point would be presented on the frontend. All of this is bound to enhance an organisation’s speed of work and its efficiency. Simply put, the decoupled approach personifies smooth working.

Gives the opportunity to be creative

With a decoupled architecture, you can let your creativity run free. Having worked with Drupal in the traditional sense, I know there are a lot of constraints, even the integration of Twig may pose some challenges while creating unique designs. However, when you go the decoupled route, all of it changes. You can build dynamic components using your creativity without letting Drupal’s rigidness hold you back.

Boosts upgrades

The decoupled Drupal boosts a website’s prospects of getting upgraded. You might have guessed this one from all the advantages above and your guess is right. A website has to undergo enhancements after some time, there is no refuting this fact. Many a time, the upgrade is put on halt because it would affect the current workings. However, with the decoupled Drupal’s departmentalisation, the front end can do an entire overhaul and the backend would continue to work like nothing is happening and vice-versa. Launching a new brand design has never been this easy.

On top of this, the decoupled Drupal also gives you the chance to build an application on the front end against a dummy web service API, which has the sole purpose of being a testing field. Since such kind of flexibility is unfound in the traditional Drupal architecture, decoupling proves to be extremely advantageous when it comes to revisions and upgrades. Check out some of the decoupled Drupal succes stories here

The Decoupled Fallout

With all that we have discussed so far, you might have come to a conclusion that decoupling is the right choice for you. It may even be, but you cannot make the decision until you have the full picture in front of you. There are indeed certain challenges in the decoupled Drupal architecture that have to be overcome in order to gain its advantages. Let us find out what they are.


Loses Drupal’s out-of-the-box features

As you may know Drupal comes with numerous out-of-the-box features, even if you are never going to implement all of them in your web projects, knowing they are there is still a benefit. Now, when you decouple Drupal, you have to part with many of them. A fully decoupled Drupal architecture will have none of the monolithic architecture’s frontend capabilities and that to many is a big disadvantage.

You will end up losing all of the following:

  • Security features like form validation and text sanitisation only come with the monolithic architecture.
  • Contextualisation features like in-place editing, previewing the content’s live result while editing and contextual links would be lost in the move. 
  • Content layout and display modules like Display Suites and Panels stop working when the front end is decoupled. So, getting variable displays for your content and constructing layouts would become difficult.
  • Notifications for possible system failure would no longer be sent to you in a decoupled architecture.
  • Drupal’s accessibility features that focus on user’s disabilities would not be embedded in the front-end code and you would have to be extra diligent for the needs of all users of screen readers.
Bugs become hard to identify web of systems 

The decoupled Drupal essentially becomes a web of systems. Although this has its own advantages, the disadvantages cannot be ignored. The most prominent being debugging. When you have more than one software working to build one cohesive website and a problem arises, it becomes extremely difficult to identify and catch it. The break could be in the request or it could be in the API, you would have to scour through everything to find out.

Creates more chances of failing 

Decoupling mandates a new hosting stack for your organisation’s infrastructure because of the separation of concerns. Traditionally Drupal is hosted on LAMP stack, Linux, Apache, MySQL, PHP, while JavaScript is hosted on a MERN or MEAN stack, MongoDB, Express, React/Angular, Node.js. This becomes problematic as one failure will lead to many. Supposedly, if proper caching isn’t provided by a Drupal site’s web service, whatever data your website would receive would most likely be obsolete. Therefore, decoupling Drupal paves way for an additional point of failure.


Brings coding complexities 

While building a decoupled infrastructure, you have to be very careful in the coding. It needs to be overseen that the front end logic does not get encoded into the API. If it were to happen, circular dependencies would be created, which would ultimately negate the purpose of decoupling. 


Increases the expense 

While monolithic Drupal, being open source is free for all, the decoupled Drupal is not. The need for new infrastructure and solutions to replace the ones provided by the coupled architecture would increase your development expenses. 

Apart from this, getting the nod on investment from the stakeholders to build a great content API, which otherwise would have been free, is no easy task. Furthermore, the maintenance of the decoupled aspects can often mean taking up temporary coupled remedies. And this stands against the initial investment objective; it’s a paradox, if you ask me.

The Bottom Line 

Now that you know everything about the Decoupled Drupal architecture, its suitability and the ways it would benefit you, it is up to you to make the final call of moving in its direction. The fact that decoupling Drupal has been gaining grounds in recent times should be the sole reason for making the switch. The buzz around it may compel you to take its route. However, your needs must be the paramount aspect in your decision. If you believe decoupling is aligned with them and the merits of Decoupled Drupal are easily overweighing the demerits, only then should you make the call for the move: because only then will you see a positive outcome from the move. 

blog banner blog image Decoupled Drupal Architecture Headless Drupal Monolithic Drupal Architecture Traditional Drupal Architecture Drupal Drupal Architecture Blog Type Articles Is it a good read ? On

1xINTERNET blog: 1xINTERNET with two Splash Awards!

Fri, 10/30/2020 - 13:00
The German and Austrian Splash awards took place yesterday. The yearly event that was virtual this year, turned out to be a lot of fun, with great hosts and guests. 

OpenSense Labs: The Role Of Frontend Developers To Help Close The Gap Between Development And Design Teams

Fri, 10/30/2020 - 06:03
The Role Of Frontend Developers To Help Close The Gap Between Development And Design Teams Tuba Ayyubi Fri, 10/30/2020 - 10:33

If you have worked with a designer, you probably have heard them complain a lot about giving feedback to developers to correct font sizes, spacing, or layout aspects. This can lead to a weakening of trust between developers and designers. Developers are often misunderstood on being ignorant about the details given by the design team

For instance, after a designer has spent their time working on designs for a website, and put a solid effort in every little detail of the design and the designs have been approved by the client. After a few weeks of the developers working on the technical part, the designers are asked to review the website. They get excited and open the website to see a very different one. They start noticing spacing, wrong fonts and colors used, etc. The designers get frustrated looking at all the details and that’s where the gap begins.

What could have been the problem? Well, maybe the communication gap turned out to be the cause of the misunderstandings between the two. These misunderstandings give rise to many questions. How many times did the two have a conversation? Were there motion prototypes? How did the handover look? Was there a handover meeting?

In this article, I will take you through some important points that will give you a better understanding of how to bridge the gap between the developers and the designers. But before that let’s understand the problems that arise during handover between the two.

Designer-Developer Handover

The handover of the design details from the designer to the developer is likely to happen at some point. It is important to plan out some time for a meeting that will help in giving a clear understanding of both.

There is no doubt that there can be initial hiccups once the two teams start working together. And this is why handover meetings are important. The opinions of the two can be contrasting but are definitely worth the effort. Always remember to ask questions on every page, design, feature, visual, component, etc. Ask for clarification wherever necessary. 

Compromise and build

The developers need to talk to the designers about something that they find wrong in the designs or maybe if they are unable to implement it for a reason. They should make sure they use non-technical terms while explaining. Instead of saying things like, ‘this can’t be built’ ‘we cannot build this’, back your points with valid reasons. If needed, give suggestions and alternative solutions that can be used to improve the designs and make it easier for the developers to implement. To look at an example, read the complete guide on website redesign strategy here.

What hinders the path of cross-collaboration?

The main challenge that disrupts collaboration between the design and development team is the way with which each team approaches problems. As the design is user-oriented, designers mainly specialize in user experience while the dev team is solution-oriented, the developers mainly target the features that aren't a part of the solution.

In fact, the approach of every team is correct in the context within which they operate but to bridge this gap between the two teams, they need to make more and more communication.

Communication is important

Communication between the two is very important. As discussed above, the design-dev meeting can reduce a lot of misunderstandings, so will conversations. It is important for both of them to talk to each other, collaborate, give each other ideas during the early phases of the project. Both of them have different roles and obviously very different perspectives. Learn more about the significance of communication between developers and designers here.

The Missing Link - Frontend Engineering

When the designers are done with the designing part, the development team comes in. This is where the ignoring of the details in the design components starts and the focus only shifts to the ‘functionality’ part. And that’s when the websites created start looking completely off from the visual designs. The front end developers are a big help in this situation. They reduce the gap between the visual composition and the functional page. 

The front-end developers have a good experience in CSS, JS, and XHTML that help them in creating functional prototypes that are very close to the visual compositions. With the involvement of front-end developers, the development team can easily concentrate on the functionality part and the design team does not need to worry about the ignorance of their work.

Let’s look at what steps the front-end developers can take to bridge this gap between designers and developers: 

  • Review specifications: To deliver a product that meets the branding guidelines and does not disappoint later, the developers should review the specs and notes beforehand and suggest changes as soon as possible, because deviating from the approved design in the later stages can cost you a lot. For instance, atomic design methodology can be very handy.
  • Understand user interactions: The front end developers can involve themselves in research to make sure you empathize with the users. This process will help you gain a better understanding of why you need to collaborate with designers. 
  • Give feedbacks: The frontend developers can share their insights with the designers, based on their experiences in visual designing, prototyping, and wireframing. Your feedback and reviews on a regular basis matter a lot even if you do not have experience in these fields. And in case you suggest changes in design, it will help your project manager to effectively manage your client's expectations. 
  • Ask questions: Ask relatable and good questions to remove the miscommunication norm in the workspace. This helps you avoid design requests at the last minute. You can also ask the designers for a quick informal review if you are confused on what to ask. 
  • Check-In Frequently: It is important to check in with the designers to help the developers become even more familiar with the project than they already are. Checking in frequently brings the team together and makes it easy for both the teams to approach each other and communicate effectively.
Conclusion

If both the teams are able to create a collaborative environment and give each other’s suggestions importance and try to have a better understanding of each other’s work, it becomes easy for them to work together and respect each other. The front end developers are a great help, always. Their suggestions and interest in design and development are heard more during the meetings!

blog banner blog image Blog Type Articles Is it a good read ? On

DEV :: Drupal, Skepticism and Spaceships...: Reusable content in Paragraphs

Thu, 10/29/2020 - 20:42
Reusable content in Paragraphs Unifex Fri, 10/30/2020 - 08:42

While it's not possible to reuse paragraphs you can create a paragraph type that mimics this behaviour.

Prep reusable content.

  1. Create your various Custom Block Types at Administration > Structure > Block layout > Custom block library. This should already have a Basic block.
  2. Create your reusable content using these block types at Administration > Structure > Block layout. Click Add custom block, select the Block type you want, fill in the content for it.

Add a Block Paragraph Type.

  1. Administration > Structure > Paragraphs types > Add Paragraph type.
  2. Add a Reference > Other field.
  3. For the Type of item to reference select Custom block
  4. Under Reference Type your Custom block types will appear. Select those you want available.

Prep Content Types: Any content types that already have a Paragraphs based field will need to have that field edited and your new Block paragraph type included.

And your done. Your reusable content is now available for selection as an embeddable Paragraph type.

As I was writing this up I was testing it on a project I'm working on to a) ensure it worked and b) I got the steps right. It's very likely that this will end up in that project.

Drupal Paragraphs Planet Drupal

Drupal Association blog: Participate in the Drupal Business Survey 2020!

Thu, 10/29/2020 - 20:06

Share your vision on the business side of Drupal in 2020! Agencies One Shoe, Exove and the Drupal Association are calling all Drupal agency leaders to take part in the annual and already the fifth Drupal Business Survey. 

The Drupal Business Survey aims to gain insight into the key issues that Drupal agency leaders nowadays face. It includes questions about the business strategy of Drupal companies, the impact of Covid-19, Drupal community contribution and about the future of Drupal. Read the 2016, 2017, 2018 and 2019 reports for previous analyses. Now it’s time to contribute to a new overview of the state of Drupal business in a year that’s influenced by so many factors.

Take the Survey

Your response will be used to generate an anonymized, aggregate report about the state of the Drupal business ecosystem. The survey is open until Monday, November 16th. The results and insights of this survey will be shared with you, officially published on Drupal.org and discussed on the Drupal CEO Virtual Drinks on December 9 at DrupalCon Europe

Take part in this survey and contribute to the Drupal project: your opinion is of great value!

Phase2: Migrating Paragraphs to Layout Builder in Drupal

Thu, 10/29/2020 - 18:21

There have been many site-builder tools for building flexible layouts in Drupal including Field Collection, Panels, and Paragraphs. But only one of them is part of Drupal core: Layout Builder. Layout Builder provides a clean and user friendly drag-and-drop editorial experience. But don’t take my word for it. If you haven’t read the amazing blog post, The Big, Bad Layout Builder Explainer by Caroline Casals you owe it to yourself to do so. Go ahead, I’ll wait.

Promet Source: What are Heuristics? How Do They Apply to UI/UX?

Thu, 10/29/2020 - 17:34
Heuristics is one of those words that sounds extremely academic, but whose meaning is refreshingly simple. Essentially, heuristics refer to rules of thumb, mental shortcuts -- or the kinds of decision-making frameworks that we engage in every day. Sometimes we do so consciously, other times, we act in a more automatic manner, based on past experience.  In the world of website UI/UX, heuristics are often discussed from the perspective of a website’s “must haves,” and they can serve as very helpful guidelines for ensuring that all bases are covered when developing a site. 

Ben's SEO Blog: 6 Tips to Rock Drupal 8 SEO

Thu, 10/29/2020 - 16:55

Drupal is phenomenal for SEO. When you use Drupal 8 for your content management system, you have a powerful tool to rock search engine optimization. Working with Drupal websites for the past 12 years, I've experienced firsthand just how quickly search engines respond to a well-optimized Drupal website. I’ve seen customers triple their traffic in weeks after upgrading from another platform. I’ve seen competitive advantages from site-wide optimizations like RDF or AMP that put my clients on the cutting edge of SEO because they use Drupal. The benefits are a faster website, higher rankings, and more traffic.

One of the main reasons Drupal is the content management system of choice for complex enterprise websites is the fact that it has been built from square one with the... Read the full article: 6 Tips to Rock Drupal 8 SEO

Acro Media: Why Business Automation Rocks and How Drupal is Helping | Acro Media

Thu, 10/29/2020 - 00:08

Getting bogged down in the day-to-day, repetitive tasks that a business requires is not only a drain on your mental health, but it could also become a hindrance to growing and scaling your business. Add up the time from all the little tasks you do in a day. If you could automate one-third of those tasks, think about how much more your business could grow! Read on to learn more about business automation and how Drupal could be the answer to your business woes.

What is business automation?
  • Business automation is a strategy in which a business like yours finds a way to automate processes and manual tasks to reduce costs/time.
Why does business automation matter?
  • The time savings that come from having solid business processes and automation setup, is time that you and your staff get to leverage to grow your business.
Why Drupal is great for business automation
  • Since Drupal is an open source platform, it gives business owners a huge opportunity to build custom integrations that can drastically reduce workload and help with business automation.
What is business automation?

Business automation is a strategy in which a business like yours finds a way to automate processes and manual tasks to reduce costs/time. This is normally accomplished through third party software and integrations.

Business automation can be applied in many areas of a company, including, but not limited to:

  • Marketing & Sales
  • Project Management & Product Development
  • Accounting & Inventory
Why does business automation matter?

At the end of the day what we are trying to do is save time. Think about it… if you can save 30 hours a month because you have solid business processes and automation setup, that's an extra 30 hours a month you and your staff get to leverage to grow your business.

Business automation is a powerful thing, it gives you the ability to scale your business much faster than if you had to do things manually. Here are the steps you should be taking to work on your business automation.

  1. What recurring tasks and processes do you and your staff currently have? Also, take a look at any swivel chair processes you may have and see if they can be eliminated.
  2. Is there a tool, integration or software that is designed to automate this task?
  3. What is the price of that tool and does it justify the time and money saved for automating that specific task?

Follow those three steps over and over again when trying to find ways to automate your business and you will be well on your way to increasing efficiency in your business.

Why Drupal is great for business automation

This one is simple. Since Drupal is an open source platform, it gives business owners a huge opportunity to build custom integrations that can drastically reduce workload and help with business automation.

Yes, lots of software as a service (SAAS) platforms have plugins and apps that can integrate with their system. But, for the most part, these integrations, modules and APIs are very standard. The moment a business requires something custom that they need their website to integrate with, all these other platforms fail to pan out. On the other hand, if your software is open source, and your business needs a custom integration, it’s most likely it can be built on Drupal due to the open source framework. Just ask some of our clients!

Bar Codes Talk

Selling barcodes & labels is a very complex business. It’s a very unique product that requires a lot of unique solutions. In our time working with Bar Codes Talk our main mission has always been the same, how can we streamline the fulfillment process for both barcodes and labels? With some hard work and custom modules, we have created some awesome integrations that have helped with all of this.

  • Nicelabel/NiceForm Module: Communicates with NiceForm (label printing software) and automatically puts the labels purchased in the printing queue.
  • Hubspot: Automatically inputs all Bar Codes Talk customers into the Hubspot CRM and separates each customer into different sales tiers based on their purchase.
  • Stamps: Communicates with the Stamps.com API for enhanced USPS shipping automation during the shipping fulfillment process.

Click here to see Bar Codes Talk full case study.

The Vault Pro Scooters

The Vault Pro Scooters is a client of ours who was struggling with their shipping/fulfillment process. Their staff was performing a lot of the shipping tasks manually, which was eating up a huge portion of their time that they could be using somewhere else.

In this specific scenario, we flew out one of our lead developers to their office/warehouse to analyze and study their shipping/fulfillment process. Because of this, we were able to use the Drupal platform to eliminate a lot of the manual tasks they were performing during the shipping and fulfillment process.

Here are some other modules that have helped automate and streamline their business.

  • Commerce Fulfillment: Allows The Vault to create shipments on their website and automatically send shipment information to FedEx and USPS to generate shipping labels for printing.
  • FedEx Crossborder: Integrates with FedEx's Crossborder platform to automatically provide international shipping rates and submit international order information to FedEx. The Vault then just ships order to FedEx's distribution center and FedEx handles shipping the order to the customer.
  • Commerce Stock: Automatically updates product stock when purchases are made, either through the online check or through the Point of Sale.
  • Drupal POS: We built a POS specifically for the Pro Vault Scooters. The great thing about the POS is that it is built on Drupal. Now all the Pro Vault Scooters inventory, content, product info, pricing, customer data, digital assets, and functionality are all stored in one system. With this one system, you are equipped with an infinite amount of data for personalization, marketing automation, real-time analytics, and business logic. Click here to learn about our POS.
How Acro Media is contributing to business automation

We know the importance of business automation, and while it’s hard for us to know exactly what your business could benefit most from, we tried to create something that could help the majority of our clients.

This is why we created a Drupal Quickbooks integration! Now you can automate all the boring, manual accounting tasks. This integration will sync and automate all your product orders, customers, refunds, credit memos, invoicing… and much more.

If you are looking to save a huge amount of time every month in Quickbooks, you can learn more about our Drupal Quickbooks integration here.

Other Drupal modules that help with business automation

Please note that to be able to use the modules below you will need to own or have access to a subscription for these products.

Hubspot Module: Hubspot is an amazing CRM and marketing tool used by many companies. Some features are free and others are paid. This module facilitates the submission of webforms to the HubSpot Leads API to help in tracking leads through Hubspot.

Mailchimp Module: Mailchimp, in simple terms, is an awesome email marketing tool. This module makes it possible to connect Mailchimp directly with your website helping you automate and build lists that can be directly synced from your Drupal site into Mailchimp.

Marketo Module: The Marketo Module helps you integrate the tracking capabilities offered by the Marketo Automation tool. Webform integration and user registration are key features of this module which also helps you in assessing your website’s ability to capture lead data.

Amazon Module: Syncs your Drupal store with your Amazon store. If you're removing items, adding items, selling items, this module will keep both stores updated and in sync automatically.

eBay Module: Syncs your Drupal store with your eBay account. If you're removing items, adding items, selling items, this module will keep both stores updated and in sync automatically.

CRM Modules: Drupal integrates with many different CRM platforms. If you are currently using any popular CRM, it is most likely there is a Drupal module that will integrate directly with that CRM.

The anything your business needs Module: This is the beauty of Drupal and open source. We can create just about any module for any integration with any software or third party tool you might be using. If there isn’t a module that does what you need, we can build it! This is why Drupal is so superior when it comes to integrations and business automation.

Other cool automation tools

I want to finish this post by giving a list of some other cool tools you can use to help with business and marketing automation. Some of them are free and some of them are paid. Check them out and let us know what you think.

Buffer (free & paid): Looking for a simple way to automate your social media marketing, then this is a tool you need.

Mailchimp (free & paid): If you are looking to do email marketing (which you should), then Mailchimp is a great software we use for most of our clients. It allows you to send automated emails based on customer behaviour and preferences. You can get started with pre-built Workflows or use their built-in segmentation and targeting options to build custom rules.

Spark Shipping (paid): Spark Shipping is dropshipping software that integrates with your existing E-commerce store to automate order fulfillment, provide dropshipping automation and Amazon repricing. If you don’t do dropshipping, you can ignore this one.

IFTTT (free & paid): This tool has a TON (over 340 services) of different apps and integrations that can be automated. Rather than me explaining everything, I suggest you check it out and see what it can do for you.

Conclusion

Now that you know how powerful business automation can be for your business, you should take the time to follow the steps I outlined at the beginning of this article, to find out what you can be automating and see if what tools and integrations can help you automate those tasks.

Feeling a little overwhelmed and need an extra set of hands? Our ecommerce software consultants are business automation pros and would love to chat with you about your business and help you find ways to streamline things so that you can focus more time and energy on the important things that will help you grow your business. Reach out at any time. We are always here to help.

Editor’s Note: This article was originally published on August 24, 2016, and has been updated for freshness, accuracy and comprehensiveness.

Bounteous.com: Connecting PHPStorm and Lando Databases for Highly Productive Drupal Development

Wed, 10/28/2020 - 16:31
Connecting PHPStorm to a Lando local Drupal application database allows developers to see how data is flowing behind the scenes within the Drupal database.

Agiledrop.com Blog: Top Drupal blog posts from September 2020

Wed, 10/28/2020 - 14:30

Check out our recap of the top Drupal articles from September and get up to speed with some of the project’s latest developments.

READ MORE

Droptica: How Drupal Multisite Works under the Hood

Wed, 10/28/2020 - 14:11

A Drupal multisite is an installation which allows us to use one codebase to serve multiple websites. In this post, I will explain in detail how Drupal multisite works, what approaches can be taken to set up a multisite installation. I will also explain some of the settings that may be important for a multisite which are not applicable when we build just one website on Drupal.

The basics of a default Drupal multisite

A Drupal website comprises a few major things:

  1. Drupal core
  2. Contrib and custom modules
  3. Theme
  4. Database
  5. Configuration

When a request from the browser is handled by Drupal, one of the first things Drupal does is bootstrapping the database and loading configuration. From the database and configuration the system knows:

  • which from the available modules and themes are enabled,
  • how everything is set up:
    • where are public and private files folders,
    • which blocks are where,
    • what content is available,
    • what is on the front page,
    • which menus are in which regions, what links are in which menus, 
    • pretty much everything else about how the website is configured. 

To connect to the database, Drupal reads the connection information which is held in the settings.php file (which typically sits in /sites/default folder).

Notice the default folder. It is called default because it is a fallback folder when no other folders are found. In a single Drupal install, typically no other folders are set up and most websites are run from the default folder.

In a multisite installation, however, we set up separate folders for separate websites.

For example:

  • /sites/example-one.com
  • /sites/example-two.com

If we create such folders, a new request will examine the base domain (base URL as Drupal calls it) and will try to match it to the correct folder. The order is as follows:

When a request with a base URL of www.example-one.com comes in, Drupal checks if there is:

  1. A folder named /sites/www.example-one.com and looks for settings.php there.
  2. If there is not, Drupal will check a higher-order domain folder - /sites/example-one.com in this case. 
  3. If it does not find settings.php there, it will move to the /sites/default.
We achieved a multisite - many websites on one codebase

If we have 2 folders for 2 different domains, we can have 2 separate settings.php files which connect Drupal to two separate databases, which load separate configurations and use various enabled modules and themes.

In essence, we end up with 2 different websites, which have their own databases, content, files and configurations, even though they sit on one Drupal code.

If we add additional folders, we get additional websites without the need to duplicate code.

Drupal can run hundreds of websites from one installation like this.

Sites.php file helps to map domains for folders

To help with the mappings of base URLs to folders, Drupal offers a sites.php file which can be used to assign base URLs to correct folders.

In the /sites/ folder we are offered a file which is called example.sites.php. Change its name to sites.php and Drupal will use it. The configuration of mappings is quite simple:

$sites['an-old-domain-to-map.coom'] = 'example-one.com;

This file allows us to map several domains to one website if we need to and helps a lot with development because development environments typically have different URLs than production ones.

$sites['localhost.example'] = 'example.com';

Some dev teams use this feature also to keep the sites folder clearer when there are hundreds of websites with various domains sometimes in foreign languages. The dev team can have short clear folder names.

$sites['nom-de-domaine-de-marque-tres-long.fr '] = 'brand-x-fr;

This is also sometimes useful if the domain for one of the websites changes.

Which website can use which modules

Typically, we are used to a situation where

  • all modules are placed in the modules directory (or sites/all/modules in Drupal 7 and previous versions),
  • all themes are placed in the themes directory (or sites/all/themes in Drupal 7 and previous versions).

If we have one website on the system, there is no need for any other configuration. We add only the modules we need.

In a multisite installation, however, there might be a need to specify which websites can use which modules or themes. In a large system with hundreds of websites and administrators, such restrictions might be crucial to only allow such functionalities on each website which work well together.

We can control this in 2 ways:

1. Via installation profiles

Each website on Drupal is built on an installation profile. Typically this is the standard or minimal profile which is shipped by Drupal out of the box. You chose between these when you install Drupal and you can see them in the /core/profiles folder. None of these 2 profiles has any modules or themes but a profile can provide these.

Drupal for example ships with a demo_umami profile which is a demo profile and includes both: a demo_umami_content module and an umami theme. If you install a standard installation, you will not have access to the umami theme from the admin panel for example.

If you have to control which websites have access to which themes or modules you place these in your custom installation profiles. Only the websites installed on a particular installation profile will be able to access and use what it provides.

What is cool is that profiles allow for inheritance. You can, for example, create one profile with drupal commerce modules and then 2 additional child profiles which will then be able to access the Drupal commerce modules.

While performing Drupal services for our clients we have implemented various scenarios with different levels of granularity. You could even create a child profile for each website to be able to have very granular control. This might however be a bit of an overkill.

2. Per website modules via the website folder

Modules and themes can be also added to the website folder. In our example, we could put them into:

  • sites/example-one.com/modules
  • sites/example-one.com/themes

Modules and themes placed in these directories will only be available to website example-one.com.

As a rule of thumb, you should probably avoid having too many modules here since it probably goes against the concept of a multisite to have completely different code for each website, but sometimes there is a need to add a few per-website tweaks or create for each a subtheme for a website which overrides a few things in a shared base theme.

Updating code once, running update 100 times

One of the great things about a multisite is reduced maintenance. If you have 100 websites on one system and a new version of Drupal comes out, you only have to update the code once instead of 100 times.

That said, remember that settings and databases are separate for all 100 websites. You do have to run the update.php script for each one separately!

Summary

Above I explained in detail how Drupal multisite works under the hood. In essence, it is a very simple and yet a powerful feature of Drupal which allows companies to reduce maintenance and technical debt and keep maintainers sane if they have to maintain many websites.

rachel_norfolk: The value of identity and the $5 income stream

Wed, 10/28/2020 - 11:39
The value of identity and the $5 income stream

Whilst I have really enjoyed building this little website, and slowly beginning to write a little more, one thing that has troubled me the whole time is how to facilitate conversation on the topics I bring up in a way that I can believe that the person making a comment is actually who they say they are. Or, at least, they are the same person I interact with on other platforms as that identity.

"Oh that's easy!", I hear you say, "Just use a tool that allows someone to login using their identity elsewhere - lots of ways to do that, such as OpenID."

Tags

ADCI Solutions: What is Altmetrics?

Wed, 10/28/2020 - 06:01

Authors of scientific articles, institutes, and foundations that sponsor research should know how their works affect science and the world. With the growth of the Internet, the old measurement ways of this impact failed to run the gamut. Links of articles refer to social media, Wikipedia, and personal blogs, but no one included them into account - there was no possibility to do it but in 2010, the term "altmetrics" and tools "altmetrics" were created.

In our new article about the evolution of the infometrics, which solves the problem of analyzing scientific publications, we tell about the way to track altmetrics on your Drupal site using our module.

Mediacurrent: Setting up CSS Modules + Sass in a Gatsby Website

Tue, 10/27/2020 - 18:11

For many years styling websites with CSS has been pretty standard. A CSS stylesheet exists somewhere in your project which provides styles for your pages or components. Even with the introduction of CSS preprocessors like Sass, Less, Stylus, and PostCSS to mention a few, the ultimate result is for stylesheets to serve styles to your pages and website.  

With the introduction of JavaScript frameworks such as React, NextJS, and others, the approaches for writing and serving CSS styles have become more complex and at times controversial. Things like CSS-in-JS (Reactjs.org defines this as “a pattern where CSS is composed using JavaScript instead of defined in external files"), can make some people question whether we are getting ourselves in trouble and whether we will regret going in this direction. It wouldn’t be the first time we find ourselves undoing practices we have followed for years because we realized there was a better way.

In GatsbyJS, a library of React, we can use different methods for styling a website.  Some of these approaches include:

  • Plain CSS
  • Inline styles
  • Styled Components
  • CSS Modules
  • Others

In most cases, people who lack the in-depth knowledge of CSS will opt for the easier way possible to style a website.  This is not always the best way to go about it, but unfortunately, it is the reality.  As someone who has worked with CSS for many years, I could technically pick any of the approaches above and accomplish my goal of styling a website, but I see issues with some of those practices and prefer to use an approach that provides flexibility, control, and best practices.

Choosing a Styling Method 

Working for an agency where we build websites for clients of all sizes, many times the method we choose for doing something depends on the client’s preferences or skill level of their team.  Meaning that we want to build a website that a client could take over and maintain on their own after our engagement with the client has scaled down.  So even if I have a personal preference but the client has no experience or desire to work with that approach, I would need to provide a way for the client to work with a system or approach that may be more comfortable to them.

The one thing to keep in mind when choosing a method for styling your websites, Gatsby or otherwise, is that at the end of the day, we are producing plain CSS and as such, it should be well-written, and easy to maintain and scale. I am a fan of keeping styles simple, flat, and to a minimum. I don’t see the point of using over-engineered methods that complicate the most simple task.

CSS Modules

My approach of choice for styling React or Gatsby websites is CSS Modules because it most closely resembles the traditional way of styling websites I have grown accustomed to. As I alluded to before, my ultimate goal is to write proper CSS, following best practices, while leveraging styles scope, performance, and scalability. CSS Modules allows me to do all these things while providing an environment I am familiar with. I am not against learning new ways of doing things (I welcome them), but if new approaches don’t offer significant benefits, I don’t see the need of complicating my life and that of clients who will interact with my code.

In a typical Gatsby website, CSS Modules works out of the box without any special configuration. You can create any CSS files in your project, import them into the components you are working with and your styles will work. This is great and can get you very far if you are working with a simple website. However, this only works with plain CSS and not Sass. I personally like Sass because it provides features that are currently not available in CSS. Things like Mixins and nesting to mention a few. I will use Sass and SCSS interchangeably in this post to refer to the preprocessing process of compiling SCSS into plain CSS code.

Add Sass to Your Gatsby Website

Adding Sass to a Gatsby website is relatively easy. It’s a two-step process that includes installing a Gatsby plugin and adding a line of code to gatsby-config.js. Let’s do this now:

  1. While In your Gatsby project root directory, run the following command to install the gatsby-plugin-sass and node-sass plugins:

    npm install node-sass gatsby-plugin-sass
    Gatsby-plugin-sass has a dependency of node-sass and therefore we need to install both.
     
  2. Edit gatsby-config.js (located in the root of you gatsby project), by adding the new plugin to the plugins array:

    plugins: [`gatsby-plugin-sass`]
    If you already have other plugins in place, you can add each new plugin in a new line within the array.

That’s it! Now Sass is available on your site.

Updating CSS Modules to use Sass

Now that we have Sass available, the last thing to do is to update CSS Modules to use Sass versus plain CSS. This is a two-step process:

  1. Rename any existing .css files to use .scss
  2. Update any imports of these files to also use .scss

Now you can take advantage of CSS Modules and Sass for writing great styles. Let’s go over a quick example of how CSS Modules works.

Using CSS Modules and Sass in Gatsby

Consider the following HTML/JS in your Gatsby Component (hero):

import React from 'react'; import PropTypes from 'prop-types'; import Image from 'gatsby-image'; import Heading from '../Heading'; import Link from '../Link'; import {fluidImage} from '../../global/js/customPropTypes'; const Hero = ({ title, image, body, path }) => { return ( <section> <div> <Image fluid={image} /> </div> <div> <Heading> {title} </Heading> <div> {body} </div> <Link to={path}>Learn more</Link> </div> </section> ); }; export default Hero; Hero.propTypes = { title: PropTypes.string, body: PropTypes.string, image: fluidImage, path: PropTypes.string };

Styling the Hero component above with CSS Modules will require we create a stylesheet for the Hero. Assuming you have a Hero folder inside components, which has an index.js for the component’s markup and JavaScript, create a file called hero.scss with the following code:

.hero { background-color:$color-white; position: relative; } .media { img { display: block; height: auto; max-width: 100%; } } .content { left: 50%; position: absolute; transform: translate(-50%, -50%); top: 50%; } .title { color: $color-secondary; }


And finally, you would update index.js by first importing the hero’s stylesheet as follows:

import styles from './hero.scss';


Then adding the respective CSS classes to each of the HTML elements in the Hero component. The end result of index.js would look like this:

import React from 'react'; import PropTypes from 'prop-types'; import Image from 'gatsby-image'; import Heading from '../Heading'; import Link from '../Link'; import styles from './hero.scss'; import {fluidImage} from '../../global/js/customPropTypes'; const Hero = ({ title, image, body, path }) => { return ( <section className={styles.hero}> <div className={styles.media}> <Image fluid={image}></Image> </div> <div className={styles.content}> <Heading classes={styles.title} headingLevel={1}> {title} </Heading> <div className={styles.body}> {body} </div> <Link to={path}>Read the full article</Link> </div> </section> ); }; export default Hero; Hero.propTypes = { title: PropTypes.string, body: PropTypes.string, image: fluidImage, path: PropTypes.string };
  • When we imported the Hero styles into the component we used styles as the namespace in the import.
  • To apply each of the CSS classes found in hero.scss to the markup in index.js we are using the className attribute since class is a reserved keyword in React/Gatsby.
  • Then in curly brackets we apply each class by prefixing them with styles. For example:  <section className={styles.hero}> <div className={styles.media}> … </section>

     

If you render this component in the browser, what you will see as a result when you inspect the code is something similar to:

  • Main things to note from the image above are the CSS classes added after css-modules--. These are the classes we created in hero.scss.
  • The end of the class names (i.e. akrigl, woitn, w95ls9), are dynamic strings created by CSS Modules which ensure they are unique CSS classes.  This prevents issues of regression and styles from leaking into other parts of your website.
  • CSS Modules restricts the scope of its styles to only the component they are written for.

 

In closing

I like CSS Modules because it provides a familiar approach to working with Sass similar to that of a traditional Sass project. This works well with clients who are not well-versed in React or Gatsby but still want to be able to update styles.