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

Project: 
Date: 
2021-January-20
Vulnerability: 
Third-party libraries
Description: 
The Drupal project uses the pear Archive_Tar library, which has released a security update that impacts Drupal. For more information please see:

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

Solution: 

Install the latest version:

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

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

Fixed By: 

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

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

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

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

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

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

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

Decoding the APIs 

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

REST 

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

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

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

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

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

JSON: API  

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

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

Broadly stated; 

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

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

GraphQL 

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

The features of GraphQL are that; 

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

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

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

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

A bar graph shows the standing of different web services against each other.
A glimpse at the popularity of the three APIs. Source: State of API Report 2020

REST vs JSON vs GraphQL 

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

How efficient is the data retrieval?

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

REST 

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

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

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

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

JSON: API 

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

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

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

GraphQL 

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

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

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

How is the code executed?

The distinction between REST and GraphQL is shown with regards to code execution.
Using an API for calls involves the execution of a code on the server. This code helps in computing, calling another API or loading data from a database. All three of the APIs use a code, however, the code is implemented varies a little.

REST 

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

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

GraphQL

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

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

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

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

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

How do the API endpoints play a role?

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

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

So, which API offers the solution?

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

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

Why doesn’t REST? 

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

How good is the API exploration?

A distinction is shown between the three APIs, REST, JSON and GraphQL, in three circles with regards to API exploration.
Understanding your API and knowing about all of its resources and that too quickly and with ease is always going to benefit your developers. In this aspect, all three perform pretty contrastingly. 

REST 

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

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

JSON: API 

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

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

GraphQL 

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

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

Let’s focus on schema now 

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

REST

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

JSON: API 

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

GraphQL

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

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

How simple is to operate it? 

The operational distinction is shown between the three APIs in three circles.
Operating an API essentially involves everything, from installing and configuring it to scaling and making it secure. REST, JSON: API and GraphQL, all perform well enough to make themselves easy to operate. Let’s see how. 

REST 

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

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

JSON: API 

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

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

GraphQL 

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

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

What about being secure?

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

REST 

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

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

JSON:API

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

GraphQL 

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

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

How is the API design pinpointed?

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

REST

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

GraphQL 

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

What about their use in Drupal?  

The distinction for Drupal installation and configuration is shown between the three APIs in three circles.
Drupal is an important player when it comes to building websites and managing their content. With decoupling Drupal becoming more and more popular, it has become crucial to understand how the APIs perform alongside Drupal. 

REST 

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

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

JSON:API 

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

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

GraphQL 

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

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

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

Concluding with the basics 

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

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

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

blog banner
Athletes are seen standing on the start line of a race.

blog image
Three arrows can be racing on the road.

Blog Type
Is it a good read ?
On

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

<img src=”https://www.amazeelabs.com/sites/default/files/styles/leading_image/public/images/current-affairs/12-Patches-12-Months.jpg?h=994a2424&amp;itok=ifURidYR” width=”1120″ height=”630″ alt=”Contributing 12 Patches in 12 Months in 2021″ title=”Contributing 12 Patches in 12 Months… again!” class=”image-style-leading-image” />

In 2019, I set myself a goal of contributing one patch each month to Drupal and that’s how #12months12patches came to be a Slack channel at Amazee Labs. The results of that challenge are reflected in this blog post from last year.

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

Drupal Global Contrib Weekend at San Francisco Drupal User Group – Introduction to issue forks and merge requests

volkswagenchick
Tue, 01/19/2021 – 16:31

Next week kicks off Drupal Global Contribution Weekend, January 29-31, a virtual worldwide event everyone can participate in from anywhere in the world.

Want to give back to the Drupal Community in the form of code but you’re not acquainted with the new contrib process? Here’s your chance to get ready for the weekend. Now that our meetups are online, join the San Francisco community in learning how to create issue forks and merger requests.

Ben’s SEO Blog: 7 SEO Goals For Business: Optimization For The Right Reasons


Selecting the right SEO goals is a critical first step in your digital marketing campaign. As with any long-term endeavor, knowing your marketing end goals and working directly toward them saves time, money, and stress.

Great SEO cannot be done in a vacuum. It depends on business goals, the needs of the sales and customer support team, and intimate knowledge of the competitive landscape in which you work. Engage the critical stakeholders in each area of your business and work together to come up with a list of needs. You may be surprised at how SEO can help each team meet its objectives.

It’s important to identify and select the right goals before implementing any SEO strategy and get continual buy-in from your team. Combine and categorize ideas to find the ones that…
Read the full article: 7 SEO Goals For Business: Optimization For The Right Reasons

Agaric Collective: Drupal toolbar not working in dev environments in Firefox? Here’s why.

Drupal’s toolbar second level of menu options and dropdown not showing? Look for “Uncaught DOMException: The quota has been exceeded.” errors, as viewable in the Firefox web console. If you see them, the problem is likely due to sites sharing a top-level domain—which is likely if you are using a local development environment like DDEV, and you working on way too many sites at once—combined with a pretty bad Firefox bug that will be fixed in the next release.

To quote Nathan Monfils:

  1. Everything from your public domain (abc.tld) counts against your quota, even if it is in a seemingly unrelated subdomain (e.g. my-app.example.com and intranet.example.com).
  2. The quota is not recomputed properly, requiring a firefox restart after clearing your data on other subdomains

Note this may affect all sorts of applications, not just Drupal, when you have them running on multiple subdomains of the same top-level domain. So this isn’t just about local development environments (and i dislike that DDEV shares their own top-level domain across all the instances you are working on, and while it can be changed i’ve accepted its way of doing things so i’m on the same page with other developers by default).

Sure, closing more tabs and restarting Firefox could (predictably) have fixed this—and a lot else that’s wrong with me, according to everyone i know—but why do that when i can open more tabs and learn precisely how broken everything around me really is?

Read more and discuss at agaric.coop.

Specbee: Drupal 9.1 and its compatibility with PHP 8 – Learn what’s new and how to check compatibility

Drupal 9.1 and its compatibility with PHP 8 – Learn what’s new and how to check compatibility
Pradosh
19 Jan, 2021

“Update before you get outdated”. 

PHP 8 is here and is now supported in Drupal 9.1 and its dependencies! November 2020 saw the big release of PHP 8. We call it a big release because of the exciting new features and optimizations it comes loaded with (which we will be talking about shortly). 

Drupal 8.9 and 9.0 are however marked incompatible with PHP 8. They are still compatible with PHP 7.3 and PHP 7.4 – which happens to be the last major PHP update. PHP 7.4 will stop receiving active support from the community from November 2021. And thus, updating your website to Drupal 9.1 will be a good idea now.

Drupal 10, which is scheduled to release in June 2022, will mandate compatibility with PHP 8. Read on to find out about the amazing features PHP 8 has to offer and how you can check if your Drupal version is compatible with PHP 8.
Drupal 9.1 Compatibility with PHP 8

 

What’s new with PHP 8 (Notable Changes)

    1. JIT Compiler

JIT stands for just-in-time compilation. Starting from PHP 5.5, Zend VM became part of PHP. But 8.0 introduced JIT to address some long struggling PHP performance issues. For better performance PHP was based on OPCache using OPCode. This is precompiled code given to the processor as commands. However, it is not very native to the machine language. On the other hand, JIT provides actual machine code with a mechanism to work together with OPCache. JIT does not work automatically. We need to configure this in the php.ini file.

    2. The null safe operator

You must be familiar with the null coalescing operator (??) which worked as:

  
$value = $var1 ?? $var2

It checks for the null value of $var1 and returns it. If it is not null, it returns $var2. But it does not work with method calls. Here, the null safe operator comes into the picture.

  
$value = $obj->getData()?->getValue();

Here you can call the getValue() method; even if no method $obj->getData() returns null, the code will not crash. It will return null. On the other hand, using the null coalescing operator:

  
$value = $obj->getData()->getValue() ?? null; 

..will throw an error.

    3. Named argument

PHP 8 allows you to now pass named arguments to functions. It does not depend upon the argument order. Instead, you can pass the argument name.

  
function named_arg_example(String $arg1, $string $arg2, $string $arg3) {}

named_arg_example(
      arg1: ‘arg1 value’,
arg3: ‘arg3 value’,
arg2: ‘arg2 value’,
);

    4. Match expression

Match expression is like the switch statement, except that it does not require a break statement.

  
$value = match($check) {
0 => ‘Value is zero’,
  1, 2, 3 => ‘Value is non zero and less than 4’’
}

There are many other great new features added to PHP 8 like the constructor property promotion, Attributes, Constant type errors for internal functions, Saner string to number comparison, etc. More details can be found here.

How to perform a Compatibility Check with PHP 8 on Drupal

You can use this method to check if your version of Drupal is compatible with PHP 8 or not. For that, you will need to first make sure you have the required package – phpcompatibility – which you can download here.

Next, you should already be having Drupal installed. If not, you will need to install Drupal 9 in your system. Using composer to install Drupal is the recommended way. For information about composer installation please refer this document

STEP 1: Drupal Installation

Use this Composer command to install recommended version of Drupal

  
composer create-project drupal/recommended-project [my_site_name_dir]

You will need to change [my_site_name_dir] with the folder name you want to install Drupal into.

STEP 2: Installing the required Package

After installing Drupal, you will have composer.json in your Drupal root directory. Open it in text editor and add the following code:

  
"require-dev": {
    "phpcompatibility/php-compatibility": "*"
},

If you already have require-dev section in your composer.json file, just add

“phpcompatibility/php-compatibility”: “*”  to the list.

Next, you need to provide location info to the PHP code sniffer by adding the following lines to composer.json

  
 "scripts": {
    "post-install-cmd": ""vendor/bin/phpcs" --config-set 
installed_paths vendor/phpcompatibility/php-compatibility",
    "post-update-cmd" : ""vendor/bin/phpcs" --config-set 
installed_paths vendor/phpcompatibility/php-compatibility"
}

And then run:

  
 composer update --lock

It will install phpcompatibility and other required packages.

STEP 3: Compatibility Check

Now, use this command to check PHP compatibility for the project 

  
vendor/bin/phpcs -p [directorypath] --standard=PHPCompatibility 
--runtime-set testVersion [php version] --extensions=[file extensions] 
--report-full==[path/to/report-file]

You need to replace the directory path with the directory path that the test will run on. In our case it is ‘.’ because we want to run the test in current directory (All Drupal files and folder). You should also replace the [php version] with the version you want to check compatibility with – which in this case will be 8.0. Replace the [file extensions] with file extensions like php, module, inc, install, etc. The report-full gives you the flexibility to store the report log in a file. So you will need to provide the path for the log file.

So, for our case, the command will be: 

  
vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set 
testVersion 8.0 --extensions=php,module,install,inc 
--report-full==./drupal9-php8-compatibility.txt

It will take a few minutes and you will get a drupal9-php8-compatibility.txt file, where you can check the reported log.

Shefali ShettyApr 05, 2017

 

OpenSense Labs: CMS and Static Site Generators

CMS and Static Site Generators
Gurpreet Kaur
Mon, 01/18/2021 – 22:16

Websites have entered a new playing field now, at least compared to what they used to be a few decades ago. They are not one-dimensional anymore. They represent a multitude of different business agendas that are essential for growth and visibility.

Websites are not just limited to words, their world has widened progressively. From animations to social media integration, websites today can do it all. A major reason for these advancements in websites and their build is the software they are built on. And that is going to be the highlight of this blog.  

We will talk about the Content Management Systems and the Static Site Generators and shed light on their uses, their suitability and whether they can work in sync or not? So let’s begin. 

Understanding a CMS 

There is a time line showing the emergence of various open source CMSs.
Source: Opensource.com

Commencing with the veterans, CMS or a Content Management System have been around for almost two decades (Drupal, one of the world leaders in web content management, was initially released on 15th January 2001). Despite being that old, the conventions they are built on and the features they have been added with over the years have resulted in CMSs being as modern as modern as can be. 

From easing the workload off of the bloggers’ shoulders to making newspaper editors happy; from catering for corporations and their digital marketing team to aiding numerous government departments online and transparent, a CMS has a wide audience. 

If I had to define a CMS, I would simply call it the one-stop destination for all your website’s content needs. It manages, organises and publishes web content. What is more impressive is that content authors can create, edit, contribute and publish on their own, they do not need to be dependent on developers for that. A CMS offers a collaborative environment to build and present websites, allowing multiple users to work with it at once. Terms like Web Content Management and Digital Experience Platform are being thrown around today and they are nothing, but a modern variant of a CMS. 

Getting into the meaning of CMS a little further, you would hear two versions of it and they are essentially its break down. 

  • First would be the Content Management Application. This makes marketers, merchandisers and content creators self-reliant. They can do the contextual heavy-lifting on their own with a CMA without the requirement of a code, so, none of the guys or girls from IT would be needed. 
  • Next is the Content Delivery Application. This is basically the foundation for your content; the back-end aspect that placed your content into templates to be further presented as one website. So, what your audiences see is provided by the CDA. 

Both of these together make a CMS whole for your use. 

Moving further, after the meaning, it is time to get a brief understanding of the various categories of a CMS. Based upon different categorisations, there are seven in all.

Based on the CMS’ role 

Traditional 

Most often, a traditional CMS is used on really simple marketing sites. I have used the term simple to describe it because it is just that, be it the layout or general functionality. You can create and edit your content using a WYSIWYG or HTML editor and it would display the content as per the CSS you have used.

With a traditional CMS, your entire site is encompassed by one software. The frontend and the backend are closely connected through it, hence, it is also referred to as a Coupled CMS. 

Decoupled 

Unlike its traditional counterpart, the decoupled CMS separated the frontend from the backend. This means they work independent of each other and a change in the presentation layer does not necessarily affect the backend repository. Through decoupling, you get the features of more than one software to base your site’s architecture on. 

Headless 

A headless CMS is more or less similar to a decoupled one. When you take up a headless CMS, your content would always remain the same, however, each of your clients, be it an app, a device, or a browser, would be obligated for the presentation of the content. 

The code in this instance is not in the CMS, rather it is an API that is used for communication and data sharing amongst the two software. This way developers can consume content through an API and content authors can start adding content at the same time. If you are looking for the ‘one size fits all’ approach, this is where you will find your answer. 

Based on cost and ownership 

Open source 

Open source CMSs are the ones that are free of cost, at least initially. You do not need to pay for any license fee for its installation; however, there can be costs that you may incur for add-on templates and more such features. 

Open Source CMSs are pretty popular today, the reason being their thriving community of developers. This results in the veterans redistributing and modifying the code, which not only leads to perpetual software improvements, but also helps the newbies in making progress. 

Proprietary 

A proprietary CMS is the exact opposite of an open source CMS, meaning it is commercial and mandates a licensing fee along with annual or monthly payments. In return for the payments, you would get an out-of-the-box system to meet all your companies requirements, continuous support and built-in functionality.

Based on the location 

On premises 

As the name suggests, this is a CMS that has a physical presence within the company’s premises. The high degree of control it offers to its users is the reason for its popularity. However, the humongous investment and the chances of human error dampen its potential. 

Cloud-based 

The name gives it away. Such a CMS is hosted on the cloud and delivered through the web. It is essentially the combination of web hosting, web software components and technical support. It provides fast implementation and deployment along with accessibility from across the globe on any device.

Why choose a CMS? 

Moving further, let’s now delve into the multitudinal features that are packed inside a CMS making it a suitable choice for you and your organisation’s virtual needs.

If I had to broadly categorise all the features of a CMS, I would end up with three major categories, which will sum up the true potential of this software. 

Content and its production needs

Producing content is the primary reason anyone takes on a CMS. It is true if you are a blogger and it is also true if you work for an educational institution and its online persona. It is the content that speaks for itself, when it comes to your site and it needs to be pristine, for lack of a better word. And CMSs help you achieve a level of control over your content production that you desire.

  • Starting with the edits, the WYSIWYG editor could be deemed as the heart and soul of a CMS. It provides you formatted text in paragraphs with quotes, superscripts, underlines as well as images and videos. Your authors would not have to work around codes for sure. 
  • Focusing on the media, images are an important part of it. Every CMS has room for them, they can be uploaded directly from your computer or archives, either within the content or you can add them in the page itself. The same is true for pdfs, animations and videos. Videos also have the option of being embedded through Youtube. 
  • Furthermore, CMSs also support multilingual and multi-channel sites. This eases the pressure off of the content authors and makes localised projects easy to run. 

Content and its presentation needs

Presentation is all about design, how it is done and how it would be showcased to the end user. There are a lot of design considerations that a CMS can help you with. 

  • A CMS would have you sorted with the right font and its size and the right colours and contrast. 
  • A CMS would have your sorted with the right responsiveness for your site. 
  • A CMS would have you sorted with the right URLs and URL logic. 
  • A CMS would have you sorted with the right templating tools to change your layout. 
  • A CMS would have you sorted with the right hierarchy for your site as well as provide the right prominence to the aspects that need it. 
  • Finally, a CMS would have your site sorted for all the right accessibility protocols to make it universally accessible. 

Content and its distribution needs

Once the content is produced, its distribution comes into play. This has a direct impact on your site’s visibility. And CMSs ensure that you get the most out of it. 

  • The foremost part of distribution needs is metadata. This helps in tagging, categorising and describing your content. It includes everything from keyword insertion to identifying the distribution channels and placing access restrictions on the content. 
  • Secondly, CMSs also come equipped with automated marketing tools like analytics and A/B testing that help you understand user behaviour and help you capitalise it. You would just have to define the parameters and the automation would do the rest, be it publishing on your site or email marketing. 

Content and its management needs

Then comes the management of your content, it is a perpetual process that helps in providing an ease to the editors and developers that streamlines the builds and updates of a website. 

  • For one, a CMS helps you plan and execute the publishing of your content. You can actually schedule when and what to post and where to post it. You can also decide when something would be available for the audience to see and when it won’t be like an events’ post. Once the event has happened, it won’t need to be on your site anymore and a CMS helps with that. 
  • CMSs also help you to figure out user roles and implement them. This helps in ensuring that sensitive information is only accessible to the users who have the clearance. A manager and a director are going to have different roles, so does a premium member and a regular member of your site. 
  • Finally CMS helps you in avoiding instances where you delete something important and its recovery becomes impossible. Version control and revisions are a feature that has to be in your CMS, if you want the powers to bring back the lost content. 

Apart from these main categories, CMSs are also renowned for their security, their scalability and user friendliness. There is one more thing to add and that is the fact that a CMS can go above and beyond it capabilities by integrating itself to third-parties and combining their features with its own, a headless CMS is an example of the same. Drupal is one of the most popular CMSs, when it comes to going headless. Read our blog, Decoupled Drupal Architecture to know more about it.

Understanding a new vogue: Static Site Generators 

Before understanding a static site generator, let’s shed some light on static sites, since these are what it builds. A static site is the one that is designed in a way that it remains static, fixed and constant, during its design, its storage on a server and even upon its delivery to the user’s web browser. This is the attribute that differs it from a dynamic, it never changes, from the developers desktop to the end user’s, it remains as-is.

Coming to Static Site Generators or SSG, in the most basic of terms they apply data and content to templates and create a view of a webpage. This view is then shown to end users of a site. 

Now let’s get a little technical, you know that an SSG will only create static sites, it does so by creating a series of HTML pages that get deployed to an HTTP server. There would only be files and folders, which points to no database and no server-side rendering.

Developers using an SSG, create a static site and deploy it to the server, so when a user requests a page, all the server has to do is find the matching file and route it towards the user. 

If I talk about the difference between an SSG and a conventional web application stack or a CMS, I would say that it is in the view of webpages. While an SSG keeps all the views possibly needed for a site at hand well in advance, a traditional stack waits until a page has been requested and then generates the view.

Why did SSG come along?

Static Site Generators act differently than a CMS, they are more aligned with the needs of static sites. However, their emergence has a bigger story to tell. 

Yes, CMSs are quite popular today, yet there is a drawback to that. With the rising acclaim of CMSs, some of them have become more prone to cyberattacks. The lead in security hacks goes to WordPress, with almost 90% of all hacks being experienced by it as reported by ITPRO reports of 2020. But, Drupal is considered the most secure CMS as can be seen in Sucuri’s 2019 Website Threat Research Report.

Then there is the issue of performance. CMS sites operate mainly upon their servers, meaning they do the heavy-lifting. If a request is sent, it would mean the server taking the charge of the page assembly from templates and content every time. This also means that for every user visiting your site, the PHP code would have to be run to start up, communicate with the database, create an HTTP response based on the recovered data, send it to the server and then finally, an HTML file is returned to the user’s browser to display the content after interpretation. All of this may impede the performance of the site built on CMS when compared to the one powered by a static site generator. But, it’s not like CMSes give you low-performance websites. They do have provisions for delivering high performance websites. It depends upon which CMS you go with. If web performance is your concern, Drupal can be your go-to option.

An SSG is a solution to these two conundrums, hence, it emerged with a bang. 

What can a Static Site Generator do for you?

there is clock in the middle with the benefits of a CMS written around it.Static Site Generators solve a lot of the issues that a CMS cannot, consequently they can provide you a lot for your site’s well-being. 

SSG means better security 

In an SSG, the need for a server is non-existent and this is the reason it provides more security. As we have already established that an SSG is rendered well in advance and its ready-to-serve infrastructure helps remove any malicious intent upon your site. This infrastructure essentially eliminates the need for servers, they do not need to perform any logic or work. 

Apart from this, with SSG, you would not need to access databases, execute logical operations or alter resources for each independent view. As a result, there is an easy hosting infrastructure as well as an enhanced security because of the lack of physical servers required for fulfilling requests. 

SSG means elevated performance 

A website’s performance is concerned with its speed and request time, and SSG provides in this area as well. Whenever a page is requested, it involves a whole bunch of mechanism to get it displayed for the visitors. There is the distance it has to cover, the systems it has to interact with along with the work that those systems do. All of these take up time, shadowing your performance. 

Since an SSG site does not mandate such a lengthy iteration per visitor request, it reduces the travel time. This is done through delivering the work directly from a CDN, a distributed network of caches, which aids in avoiding system interaction. Resultantly, your performance soars 

SSG means higher scalability 

When an SSG builds a site, it is often considered pre-built. I mean that is what building all the views in advance of an actual request could be defined as, right? So, with a pre-built site, you have less work on your hands. For instance, a spike in traffic would not mandate you to add in more computing power to handle each additional request, since you have already done all the work beforehand. You would also be able to cache everything in the CDN and serve it directly to the user. As a result, SSG sites offer scalability by default. 

When should you choose a Static site generator?

Now that you know how an SSG can benefit you, it is time to understand the scenarios that would mandate taking up a static site generator and all its advantages. 

When building complex site is the goal 

If you want your website to deliver more complexity, in terms of the kind of features it provides, SSG becomes a good choice. There are many that come equipped to provide you client-side features that are ready to go. 

When creating and displaying content is the only goal

Here SSG is a suitable choice because it would generate pages and URLs for you. And these pages would give you a 100% control over what is being displayed, meaning the output would always be in your hands; content pages need that. 

When generating numerous pages is the goal 

A static site generator can create pages at a great speed. It might not be seconds, but it is quite fast. So, when creating websites that would need a lot of pages to be created, SSG’s speed comes in quite handy. 

When templating needs are complex as well 

An SSG is a powerful software, it has the ability to assess your site’s visual style and content along with its behaviour and functionality. This feature becomes fruitful, when building a website with diverse templating needs. Vue and React based SSGs would definitely help you get the versatility you need on your website, along with the standard use of concept of code reuse on your site. 

I would like to add just one more thing, and that is the fact that your team must be familiar with the static site generator that you are going to end up using. There are a lot in the market. If your team is familiar with .net, use and SSG powered with it. On the other hand if it finds JavaScript more familiar territory, go with an SSG based on that. Let your development team be a part of the discussion, when the suitability of a static site generator is being decided. 

Are Static Site Generators always the right option? 

Coming from the suitability, you would think that an SSG is a great choice. Don’t get me wrong, it is. However, it isn’t a universal software. There are instances when it may not be the right choice. So, let’s delve into these scenarios.

Not when you do not have development experience 

Static Site Generators become a tad bit difficult for amateur developers. Your developers ought to have experience to reap all its benefits. The building process is considered to be more difficult than that of a CMS, something that finding plugins for pre-built pages acn become a chore. Furthermore, there isn’t a huge community out there to help you in the development part, if you are a beginner. 

Not when you need a site built urgently 

You have to understand the urgency and SSGs are not the best of friends. From learning the build process to developing the template code, everything needs time. 

There are development scripts to be me made;
There is the complication of customised them;
There is the additional process of creating and setting Markdown files;

All of these account to more time requirements for the development process. Think of it like this, you are going to be doing all the grunt work beforehand, and that would necessitate more time. 

Not when you need server-side functionality 

When partnering with an SSG, you would be parting with some, if not many, interactive functions on your site. For instance, user logins would be difficult to create, so would web forms and discussion forums. However, there are certain options like lunr.js search and Disqus commenting to help you with your sites interactivity. I would say that these options are pretty limited.

Not when your site has to have hundreds of pages

You might think that I am contradicting myself, however, I am not. Static site generators can create a website with a thousand pages, yet the process can become tedious and awkward. For a thousand or so pages, the content editing and publishing would be cumbersome. Along with this real-time updates could get delayed and like I mentioned before build times rise consequently.

Not when website consistency is a priority 

Lastly, SSG sites offer a lot of flexibility. That should be a good thing, however, it does have a side effect and that is on your site’s consistency. This is because anything that is found in the Markdown files can be rendered as page content. Consequently, users get the chance to include scripts, widgets and other undesired items. 

Can a CMS and an SSG work together? 

Yes, a CMS and an SSG can work together and pretty efficiently at that. However, that partnership is only possible in a headless CMS. This is because a headless CMS gives room for other frontend technology to come and play and in this case that technology is found in static site generators. 

A headless CMS is pretty versatile, choosing a static site to go as its head could help you get most of the benefits that both, the static site and headless CMS, come along with. This partnership indeed has a lot to offer. Let’s find out what that is. 
Two hands shaking can be seen on the left, with the benefits of a CMS and static site generators' partnership.

Proffers easy deployment via APIs

SSGs are quite straightforward to use, especially with an API, which is the connecting force between the SSG and the CMS. Pulling data from an API for generating and deploying a static PWA to any web host or Content Delivery Network is a breeze. 

Proffers ease to the marketing team 

When you work only with an SSG, you would face difficulties as it puts a lot of boundations on the marketing team. This isn’t a problem when you partner with a CMS. 

Proffers easy editing and workflow 

Conventionally, SSGs do not have a WYSIWYG editor or workflow capabilities for the tracking and collaboration of content. You might think that it is only needed for dynamic sites, but that isn’t the case. Static sites also need that. Since CMSs have that capability, they become ideal for content before actually running the SSG; the perfect contextual partnership. 

Proffers easy updates to sites 

With a CMS, you can easily change and update the content. With an SSG, the same changes can be pulled up through the APIs and a new static site can be generated every time they are incurred. All the developers have to do is set a tool up for content pulling and generation. As a result, your site would always be up-to-date and the users would not need to be processed whenever they visit your site. 

To check out some examples of how CMS and SSG can come together, read how Drupal and Gatsby can be leveraged for developing blazing fast websites. You can also go through the benefits of going ultra-minimalistic with the combination of Metalsmith and Drupal.

Conclusion 

In the end, all I want to say is that both a CMS and an SSG have their own set of features and capabilities that make them excellent at what they do, making their users more than happy. However, when it comes to getting the best out of both of them, there is only one kind of CMS that can help you reap the benefits of this dynamic. It is up to you to decide whether you want to use them together or individually.  
 

blog banner
Two puzzle pieces are being joined together.

blog image
There is sunflower alongside a heartshaped stone, which is half see.

Blog Type
Is it a good read ?
On