Apr 03 2020
Apr 03

In a traditional Drupal website, Drupal is the end to end solution for serving users with pages. It is used to create, store and display content to the end-user. In a headless approach adding and storing are still done on Drupal but displaying is not.

Definition:

Headless Drupal is an approach to building Drupal websites, in which Drupal serves as the backend content repository. The frontend is built in different technologies and communicates with Drupal via an API. 

headless Drupal


In the graph, we can see that Drupal serves as the backend system. The frontend, which the client sees, is separate from Drupal. That is where the headless name comes from - Drupal does not have the top layer anymore (the head ;), but only exposes the APIs which the frontend consumes and uses as content sources.

The frontend can be built in various frameworks and programming languages. Mostly, however, this will be one of the below:

  • Javascript - vast majority of cases - frontends are mostly built on frameworks like React, Angular or Vue, which allow for quick creation of dynamic and interactive interfaces. If there is a requirement (eg for SEO purposes) to pre-render the pages on the server, Nextjs or Gatsby can help.
  • PHP - sometimes the frontend is built on a fast PHP framework like Symfony or Laravel. This would be done mostly when pre-rendering on the server is required. An additional upside is that since Drupal is built on PHP and uses Symfony, often the same team is capable of handling the frontend.
  • Any other - a website in any other technology which can talk to an API can consume content from Drupal. 

Why chose headless Drupal

There are many reasons why companies might choose to use a headless approach to Drupal. Below I will list the most common ones.

More consumers of content

These days brands communicate with their customers not only through their websites but via multiple channels. CMS, therefore, is not used only to send content to web browsers. It pushes content to various other places. You can read more about the changing marketing landscape in a post about Digital Experience Platforms

Drupal is fantastically positioned to be the source of content for various consumers. Apart from serving content for a frontend website, decoupled Drupal can serve content via an API to be consumed by various other mediums, in which the brand wants to be present:

  • mobile applications
  • IoT
  • kiosk displays
  • etc.

Microsite manager

Sometimes a company needs to create multiple websites which are separate (eg. one for each brand, event, promotion, country), but which will share a lot of content. In such a case, it might be easier to create one content engine (Drupal) which will deliver content to all the microsites. The microsites can be quickly created and closed whenever a need arises and the content can be contained in one content hub.

Need for an elegant UI

Drupal is fantastic for content creation, data storage etc, but it is written in PHP which is a server-side rendering engine. It the particular website or app or website requires a very elaborate UI or simply is interactive it probably has to be built in javascript.

Javascript allows us to create fantastic interactions which are easy to use for visitors and are fast. Libraries like Angular, React or Vue help developers quickly create complicated frontend applications. Progressive Web Applications - a standard published by Google is also gaining momentum and it requires an application to be built in javascript.

If you want to build an interactive web application, marrying drupal with a frontend Javascript framework is a really great option. For a tutorial, you can check out our article about combining drupal and react.

Diversification of teams

Drupal experts are very hard to come by. Some companies, to move quicker, decide to build the backend in Drupal and hand frontend off to a team specialising in a different technology, in which talent is more available or which is simpler to learn.

Another benefit of inviting various teams to work on one project is sharing best practices from various sources. This may results in much better end results than relying on one team to build the backend and frontend.

Reducing technological dependency on one platform

The bigger the system one builds on Drupal, the greater the reliance on it. Abstracting Drupal from serving the frontend, allows companies to be more dynamic in changing the frontend technologies, without having to rebuild or re-architect huge Drupal backends.

Many websites, which have to maintain a fresh, modern look undergo a re-design every few years. If the frontend is separated from the backend it is much easier to rebuild. In such cases, the overall cost of the website might turn out to be lower than if the Drupal website was being rebuilt.

Drupal is great for headless

Drupal is very often chosen when a headless CMS is required. The reason for this is because Drupal out of the box has most of the required functionality. It is one of the most mature CMSes and has fantastic APIs.

Drupal community is working very heavily to allow Drupal to be a great API-driven CMS. In 2016 an “Api First”  initiative was launched. Its aim was to coordinate the development effort to allow Drupal to be a fully headless CMS.

As of writing this, enormous progress has been made in allowing Drupal to serve and receive content via APIs. 

RESTful module

Since Drupal 8.2 there is a RESTful module available in Drupal core which out of the box allows for easy interaction with all standard entities available in Drupal (nodes, users, taxonomies, comments). Accompanied by REST UI module it allows for very fine-grained control of what can be accessed via the REST API and how.

Initially, this module was the standard for building headless Drupal installations. It comes however with a few pain points, what sometimes makes it quite difficult to work with.

  1. Returned data structures are by default derived from drupal arrays, which converted into JSON are not very user-friendly and difficult for frontend developers to navigate.
  2. Getting and liftering lists of entities it a bit troublesome. For each type of list and filter, a view in Drupal with particular fields and exposed filters have to be created. Frontend developers cannot easily ask for custom lists

Despite the downsides, RESTful was a fantastic step in the right direction.

JSON:API module

JSON:API module was shipped with Drupal 8.8. It has massively improved the REST experience with Drupal, making it an incredibly versatile system far superior to practically any CMS on the market.

JSON:API module exposes all entities in Drupal allowing for easy interactions, but it does so in a very elegant fashion:

  1. It is compliant with the JSON:API standard (https://jsonapi.org/) making it easy for anyone wanting to integrate with a Drupal website easy to understand the data structures without the need for a lot of custom documentation
  2. It allows to query for lists and filter by entity properties  and fields also following the JSON:API standard

The core JSON:API functionality is further extended by JSON:API Extras module, which allows for additional configurability of the endpoints.

The above features effectively turn Drupal into a super robust backend for frontend applications, where all data structures can be created using the Drupal UI, whilst the REST endpoints are automatically working out of the box without a need for any programming work.

An in-depth comparison of the two modules can be found here: https://www.drupal.org/docs/8/modules/jsonapi/jsonapi-vs-cores-rest-module


REST in Drupal is baked deep into the system

What is worth mentioning is that in both of the above, modules the REST APIs are not added to Drupal as an afterthought. They are deeply baked into Drupal core. Drupal access control, preprocessing of values, hooks, events etc. All these are automatically taken into account when an access point is queried just as it were when a Drupal node was requested in a more traditional fashion by accessing a URL via the browser. 

This gives Drupal a massive edge over other CMSes. Using REST, you can still extend and alter default behaviour in any way you want!

Headless vs progressively decoupled

In this article, we are discussing headless Drupal, but it is also worth mentioning that it is not the only way to add interactivity to a Drupal website. Another option is to create a progressively (or partly decoupled) Drupal architecture.

Progressive decoupling is an approach closer to a typical Drupal setup, where the initial request to the server is managed by Drupal and the page send back is assembled by Drupal. On the page, however, we embed interactive elements build in javascript, which then fetches data it needs by calling a REST API also provided by Drupal. 

This approach might make sense in the following scenarios:

  • Most of the website is not interactive but there are a few highly interactive elements which require Javascript.
  • The website uses external data sources which should be presented to the user but do not come from Drupal and are not well suited for Drupal (eg. time changing stock quotes) which can be pulled directly from the source by a JS app embedded in Drupal

If you are not sure which solution to choose, there is a great post by Dries Buytaert on how to decouple Drupal in 2019.

Important considerations

Development is more complicated and more expensive

A Headless infrastructure is more complex than a traditional Drupal website. This can cause additional difficulties and can increase costs. Deciding on a headless, you should consider whether the benefits outweigh the costs. 

Managing multiple teams

In a headless Drupal, there are 2 separate components (frontend and backend) and these have to be developed (at least to some extent) in coordination. Quite often, there will be separate developers or teams (backend and frontend) working on the website. Sometimes these are 2 different companies. This requires coordination and much more communication because data models have to be agreed, endpoints created and tested. It is true that in Drupal many of these might be available out of the box, but most probably there will be requirements for some custom ones.

Higher overall development costs

Overall development time will probably be higher since we now build 2 systems, and therefore development cost will also be higher than that of a comparable standard Drupal website, especially taking into account the coordination effort.

Higher subsequent maintenance costs

Maintenance of a decoupled system is more difficult. Tests are more important when you rely on REST APIs because changes to one system might make it not compatible with the other.

Deployments might have to be more orchestrated where changes to multiple both systems are deployed all at once. Alternatively, multiple versions of an API might be maintained, but that also adds to the cost. All of this might increase maintenance costs.

Also, security releases will be required more often since there will be a need to patch not one but at least 2 systems.

SEO (and other metadata consuming engines)

Google becomes better and better in indexing javascript content but still, it is safer and much more effective to be able to provide it all the content on the first request to the main URL. If your website heavily relies on traffic from search engines, a decoupled approach might not be the best solution.

You should also take other services into account. For example for content to be nicely shareable via Facebook and Twitter, each piece of content has to have a separate URL and what is also important, must return the basic data obtainable without javascript. At least for now, Facebook and Twitter when you share a link there, prepare the preview by querying the link without enabling javascript. The title, image and description information should, therefore, be available without the need to enable javascript.

Solutions:

Shareability - returning metadata information on routes

For Facebook and Twitter, it is enough to return a small part of websites content on each route. This can be even done, and sometimes is, by a simple script in a server-side language (in PHP or python etc) which, depending on the route queried, returns different metadata. The server, instead of serving a flat HTML file with a js application, parses a script and returns identical HTML with just the meta tags varying.

SEO  - Server-side rendering

For SEO purposes the above approach can also be used, but typically another way is more efficient. Assembling a complete page with content often requires quite a lot of logic, which then has to also be available in the frontend application. Writing the same page assembling logic both in a server-side language and then in javascript for the front-end does not make sense.

The developer community-created open source javascript frameworks based on React, which allow for the creation of javascript applications which render the page on the server and then enrich it with slick UI in the frontend. There are 2 most commonly used frameworks:

Both of these offer similar functionality and allow building of super-fast websites assembled in the backend and working super smoothly in the frontend. 

From Drupal perspective, development of a headless CMS is identical for a typical single page application.

Loss of some of the Drupal functionality

Drupal out of the box provides a lot of functionality. If Drupal is kept in the backend, a lot of this is no longer available. In particular:

  • Layout management  - drupal provides a highly configurable page layout management with region definition and an ability to place elements in various parts of the page without the need to code them in (eg placing a search window in the header or a menu in the footer). 
  • Account management screens- Drupal provides register, login, password reset functionality out of the box. If we intend to allow users to register, we will have to implement all the forms and connect them to the APIs.
  • Preview - If we create content in Drupal, we as an author can preview it before it is published. In a typical headless setup especially if content is available via many channels, the preview of all is not available. Often editor adds content without seeing the end result. If needed, it has to be separately architected and created to allow editors to preview their creations.

Summary

Headless Drupal is an interesting approach to build feature-rich interactive websites or build content hubs which power various content consuming websites and media. It is however not without disadvantages and careful consideration should be made before choosing this path. Hopefully, this article gave you sufficient information to chose. If not, we are always happy to consult your Drupal project.

Give us a shout!
 

Apr 03 2020
Apr 03

In a traditional Drupal website, Drupal is the end to end solution for serving users with pages. It is used to create, store and display content to the end-user. In a headless approach adding and storing are still done on Drupal but displaying is not.

Definition:

Headless Drupal is an approach to building Drupal websites, in which Drupal serves as the backend content repository. The frontend is built in different technologies and communicates with Drupal via an API. 

headless Drupal


In the graph, we can see that Drupal serves as the backend system. The frontend, which the client sees, is separate from Drupal. That is where the headless name comes from - Drupal does not have the top layer anymore (the head ;), but only exposes the APIs which the frontend consumes and uses as content sources.

The frontend can be built in various frameworks and programming languages. Mostly, however, this will be one of the below:

  • Javascript - vast majority of cases - frontends are mostly built on frameworks like React, Angular or Vue, which allow for quick creation of dynamic and interactive interfaces. If there is a requirement (eg for SEO purposes) to pre-render the pages on the server, Nextjs or Gatsby can help.
  • PHP - sometimes the frontend is built on a fast PHP framework like Symfony or Laravel. This would be done mostly when pre-rendering on the server is required. An additional upside is that since Drupal is built on PHP and uses Symfony, often the same team is capable of handling the frontend.
  • Any other - a website in any other technology which can talk to an API can consume content from Drupal. 

Why chose headless Drupal

There are many reasons why companies might choose to use a headless approach to Drupal. Below I will list the most common ones.

More consumers of content

These days brands communicate with their customers not only through their websites but via multiple channels. CMS, therefore, is not used only to send content to web browsers. It pushes content to various other places. You can read more about the changing marketing landscape in a post about Digital Experience Platforms

Drupal is fantastically positioned to be the source of content for various consumers. Apart from serving content for a frontend website, decoupled Drupal can serve content via an API to be consumed by various other mediums, in which the brand wants to be present:

  • mobile applications
  • IoT
  • kiosk displays
  • etc.

Microsite manager

Sometimes a company needs to create multiple websites which are separate (eg. one for each brand, event, promotion, country), but which will share a lot of content. In such a case, it might be easier to create one content engine (Drupal) which will deliver content to all the microsites. The microsites can be quickly created and closed whenever a need arises and the content can be contained in one content hub.

Need for an elegant UI

Drupal is fantastic for content creation, data storage etc, but it is written in PHP which is a server-side rendering engine. It the particular website or app or website requires a very elaborate UI or simply is interactive it probably has to be built in javascript.

Javascript allows us to create fantastic interactions which are easy to use for visitors and are fast. Libraries like Angular, React or Vue help developers quickly create complicated frontend applications. Progressive Web Applications - a standard published by Google is also gaining momentum and it requires an application to be built in javascript.

If you want to build an interactive web application, marrying drupal with a frontend Javascript framework is a really great option. For a tutorial, you can check out our article about combining drupal and react.

Diversification of teams

Drupal experts are very hard to come by. Some companies, to move quicker, decide to build the backend in Drupal and hand frontend off to a team specialising in a different technology, in which talent is more available or which is simpler to learn.

Another benefit of inviting various teams to work on one project is sharing best practices from various sources. This may results in much better end results than relying on one team to build the backend and frontend.

Reducing technological dependency on one platform

The bigger the system one builds on Drupal, the greater the reliance on it. Abstracting Drupal from serving the frontend, allows companies to be more dynamic in changing the frontend technologies, without having to rebuild or re-architect huge Drupal backends.

Many websites, which have to maintain a fresh, modern look undergo a re-design every few years. If the frontend is separated from the backend it is much easier to rebuild. In such cases, the overall cost of the website might turn out to be lower than if the Drupal website was being rebuilt.

Drupal is great for headless

Drupal is very often chosen when a headless CMS is required. The reason for this is because Drupal out of the box has most of the required functionality. It is one of the most mature CMSes and has fantastic APIs.

Drupal community is working very heavily to allow Drupal to be a great API-driven CMS. In 2016 an “Api First”  initiative was launched. Its aim was to coordinate the development effort to allow Drupal to be a fully headless CMS.

As of writing this, enormous progress has been made in allowing Drupal to serve and receive content via APIs. 

RESTful module

Since Drupal 8.2 there is a RESTful module available in Drupal core which out of the box allows for easy interaction with all standard entities available in Drupal (nodes, users, taxonomies, comments). Accompanied by REST UI module it allows for very fine-grained control of what can be accessed via the REST API and how.

Initially, this module was the standard for building headless Drupal installations. It comes however with a few pain points, what sometimes makes it quite difficult to work with.

  1. Returned data structures are by default derived from drupal arrays, which converted into JSON are not very user-friendly and difficult for frontend developers to navigate.
  2. Getting and liftering lists of entities it a bit troublesome. For each type of list and filter, a view in Drupal with particular fields and exposed filters have to be created. Frontend developers cannot easily ask for custom lists

Despite the downsides, RESTful was a fantastic step in the right direction.

JSON:API module

JSON:API module was shipped with Drupal 8.8. It has massively improved the REST experience with Drupal, making it an incredibly versatile system far superior to practically any CMS on the market.

JSON:API module exposes all entities in Drupal allowing for easy interactions, but it does so in a very elegant fashion:

  1. It is compliant with the JSON:API standard (https://jsonapi.org/) making it easy for anyone wanting to integrate with a Drupal website easy to understand the data structures without the need for a lot of custom documentation
  2. It allows to query for lists and filter by entity properties  and fields also following the JSON:API standard

The core JSON:API functionality is further extended by JSON:API Extras module, which allows for additional configurability of the endpoints.

The above features effectively turn Drupal into a super robust backend for frontend applications, where all data structures can be created using the Drupal UI, whilst the REST endpoints are automatically working out of the box without a need for any programming work.

An in-depth comparison of the two modules can be found here: https://www.drupal.org/docs/8/modules/jsonapi/jsonapi-vs-cores-rest-module


REST in Drupal is baked deep into the system

What is worth mentioning is that in both of the above, modules the REST APIs are not added to Drupal as an afterthought. They are deeply baked into Drupal core. Drupal access control, preprocessing of values, hooks, events etc. All these are automatically taken into account when an access point is queried just as it were when a Drupal node was requested in a more traditional fashion by accessing a URL via the browser. 

This gives Drupal a massive edge over other CMSes. Using REST, you can still extend and alter default behaviour in any way you want!

Headless vs progressively decoupled

In this article, we are discussing headless Drupal, but it is also worth mentioning that it is not the only way to add interactivity to a Drupal website. Another option is to create a progressively (or partly decoupled) Drupal architecture.

Progressive decoupling is an approach closer to a typical Drupal setup, where the initial request to the server is managed by Drupal and the page send back is assembled by Drupal. On the page, however, we embed interactive elements build in javascript, which then fetches data it needs by calling a REST API also provided by Drupal. 

This approach might make sense in the following scenarios:

  • Most of the website is not interactive but there are a few highly interactive elements which require Javascript.
  • The website uses external data sources which should be presented to the user but do not come from Drupal and are not well suited for Drupal (eg. time changing stock quotes) which can be pulled directly from the source by a JS app embedded in Drupal

If you are not sure which solution to choose, there is a great post by Dries Buytaert on how to decouple Drupal in 2019.

Important considerations

Development is more complicated and more expensive

A Headless infrastructure is more complex than a traditional Drupal website. This can cause additional difficulties and can increase costs. Deciding on a headless, you should consider whether the benefits outweigh the costs. 

Managing multiple teams

In a headless Drupal, there are 2 separate components (frontend and backend) and these have to be developed (at least to some extent) in coordination. Quite often, there will be separate developers or teams (backend and frontend) working on the website. Sometimes these are 2 different companies. This requires coordination and much more communication because data models have to be agreed, endpoints created and tested. It is true that in Drupal many of these might be available out of the box, but most probably there will be requirements for some custom ones.

Higher overall development costs

Overall development time will probably be higher since we now build 2 systems, and therefore development cost will also be higher than that of a comparable standard Drupal website, especially taking into account the coordination effort.

Higher subsequent maintenance costs

Maintenance of a decoupled system is more difficult. Tests are more important when you rely on REST APIs because changes to one system might make it not compatible with the other.

Deployments might have to be more orchestrated where changes to multiple both systems are deployed all at once. Alternatively, multiple versions of an API might be maintained, but that also adds to the cost. All of this might increase maintenance costs.

Also, security releases will be required more often since there will be a need to patch not one but at least 2 systems.

SEO (and other metadata consuming engines)

Google becomes better and better in indexing javascript content but still, it is safer and much more effective to be able to provide it all the content on the first request to the main URL. If your website heavily relies on traffic from search engines, a decoupled approach might not be the best solution.

You should also take other services into account. For example for content to be nicely shareable via Facebook and Twitter, each piece of content has to have a separate URL and what is also important, must return the basic data obtainable without javascript. At least for now, Facebook and Twitter when you share a link there, prepare the preview by querying the link without enabling javascript. The title, image and description information should, therefore, be available without the need to enable javascript.

Solutions:

Shareability - returning metadata information on routes

For Facebook and Twitter, it is enough to return a small part of websites content on each route. This can be even done, and sometimes is, by a simple script in a server-side language (in PHP or python etc) which, depending on the route queried, returns different metadata. The server, instead of serving a flat HTML file with a js application, parses a script and returns identical HTML with just the meta tags varying.

SEO  - Server-side rendering

For SEO purposes the above approach can also be used, but typically another way is more efficient. Assembling a complete page with content often requires quite a lot of logic, which then has to also be available in the frontend application. Writing the same page assembling logic both in a server-side language and then in javascript for the front-end does not make sense.

The developer community-created open source javascript frameworks based on React, which allow for the creation of javascript applications which render the page on the server and then enrich it with slick UI in the frontend. There are 2 most commonly used frameworks:

Both of these offer similar functionality and allow building of super-fast websites assembled in the backend and working super smoothly in the frontend. 

From Drupal perspective, development of a headless CMS is identical for a typical single page application.

Loss of some of the Drupal functionality

Drupal out of the box provides a lot of functionality. If Drupal is kept in the backend, a lot of this is no longer available. In particular:

  • Layout management  - drupal provides a highly configurable page layout management with region definition and an ability to place elements in various parts of the page without the need to code them in (eg placing a search window in the header or a menu in the footer). 
  • Account management screens- Drupal provides register, login, password reset functionality out of the box. If we intend to allow users to register, we will have to implement all the forms and connect them to the APIs.
  • Preview - If we create content in Drupal, we as an author can preview it before it is published. In a typical headless setup especially if content is available via many channels, the preview of all is not available. Often editor adds content without seeing the end result. If needed, it has to be separately architected and created to allow editors to preview their creations.

Summary

Headless Drupal is an interesting approach to build feature-rich interactive websites or build content hubs which power various content consuming websites and media. It is however not without disadvantages and careful consideration should be made before choosing this path. Hopefully, this article gave you sufficient information to chose. If not, we are always happy to consult your Drupal project.

Give us a shout!
 

Apr 02 2020
Apr 02

Corporate websites are often large and packed with many different functionalities. This makes building a website very time-consuming and, consequently, expensive. At Droptica, we have developed a way to build a corporate website on Drupal faster and cheaper. From this article, you will learn how we do it.

Your company's Drupal-based website does not have to be expensive

Drupal-based corporate websites are considered costly solutions. Developing high-quality Drupal websites from scratch using Drupal is labour-intensive, and the first effects of such a process are visible only after a few weeks of development works. Until now, only the largest companies could afford such an expense. 

That is why we decided to introduce ready-made Drupal-based implementation packages to our offer. An implementation package is a set of services and products selected so that they guarantee the client can build a complete high-quality website in a few weeks instead of carrying out a process lasting several months in the traditional model of building a website from scratch.

Each of our packages is based on our own Drupal distribution. We call it Droopler. Just moments after its installation, Droopler gives you powerful options and reduces the time it takes to build a website. By choosing our implementation package, you start with an extensive structure of pages, predefined visual elements and multifunctional menus. All of this is based on a professional technological structure, optimised in terms of SEO and speed of operation. 

Droopler 2.0.

Droopler's strength lies with the wealth of available (at the very start) elements 

Imagine that you can build your website just like you build toys from Lego bricks. You have ready-made parts and you just put them together. You do not have to be an HTML, CSS or PHP specialist. That is how Droopler works. Lego bricks are paragraphs. We have created a dozen or so. In addition, each one of them has several uses. So, you have over 100 different blocks to build every single subpage. These blocks fit together in any configuration and look nice whether you see them on a laptop or a phone.

For example, you can add a paragraph with a photo and a title, a paragraph with content, a paragraph with a gallery, and finally – a paragraph with a contact form. The process of creating such a subpage is very fast and intuitive. After selecting a given element, you just need to add the appropriate content, graphics or photos. 

If after some time or during the creation of the subpage you find that the order of the paragraphs used is incorrect, you can easily change their layout. Such a change requires only a few seconds of work. Droopler's capabilities mean that you can create different variants of every subpage. 

Marketers praise the ability of editing content in Droopler. The system saves them a lot of time. They can focus on effective management of corporate content, and not on solving problems with HTML or CSS.

What kind of a website will be created based on our package?

Droopler's capabilities are best seen live. The system's demo is available at https://demo.droopler.com/

This website shows that Droopler is a powerful tool for building large Drupal websites. The extensive main menu, product subpage, search engine and blog are just some of the basic functions available immediately. 

The demo shows a website of a fictitious company that needs a wide range of functionalities and modules on its website. The broad offer, news section, many types of content blocks, or extensive contact subpage, work perfectly on smartphone and laptop screens. 

Advanced features mean that even a company listed on the stock exchange will find here all the elements necessary to create its perfect website.

Droopler Demo

An implementation package is a good basis for a website's growth

Our ready-made implementation packages can be treated as non-expensive website starters, which look good right after the installation. Many small companies will be satisfied with the modern look that Droopler provides from the very first moments of operation – without changing anything in the code.

For medium- and large-sized companies, our Drupal distribution may constitute a great foundation for building unusual and non-standard solutions. 

Saving the costs at the initial stage of creating a website will be attractive for any kind of a business operation. Especially due to the fact that the money saved can be used for non-standard functionalities that are key and distinguishing for a given company.

It is this well-thought-of versatility that makes each of our packages a highest-quality open-source product. 

Droopler is flexible in terms of extension

We thought about the ability to modify Droopler from the very beginning of its development. The structure and nature of our distribution allow you to easily create non-standard and bespoke solutions. 

The developer does not create the code from scratch, but using ready-made elements, he can freely remodel, modify and adapt them to the client's needs. Such an approach saves time and – as a result – money while maintaining high quality.

[embedded content]

Drupal will make your company website the best

When you decide to build a company, website based on our experience with Drupal, you can be sure that we offer a product of the highest quality. The solutions we provide as part of our implementation packages are the work of the best world-class developers specialising in Drupal. 

Our experience gained over the years while working with large global companies is responsible for the fact that today we can provide an open-source product of similar quality, available to a wide group of clients. 

You can find the full offer of our implementation packages here.
 

Mar 30 2020
Mar 30

There are almost a million websites built on Drupal. The websites built on Drupal are growing ever bigger. In fact, Drupal is the main CMS contender if you want to build a big website and don't want to use expensive proprietary platforms. Website generators, headless CMSes and Digital Experience Platforms architected by massive corporations, all are built on Drupal.

Drupal, however, is a complex framework. Correct architecture and coding standards are a must to ensure the project’s long term success. Working with a knowledgeable partner can get you a long way compared to the situation you’d be in if you started with someone without Drupal experience. If you want to build a new system or a website or are just looking to get better service for an existing project, partnering with the best Drupal agency is the right way to ensure your project’s future success.

But how to choose a top Drupal agency

Before you start looking for a Drupal agency, there are a few things you should consider which will make your search much more effective.

Location

Where should the agency be located? Ideally, everyone prefers to work with companies located close, but despite Drupal being a popular CMS, Drupal companies do not reside around every corner. This is especially true if you want to find true experts. Luckily, technology has all but eliminated barriers for cooperation even over great distances and most agencies are really well experienced in working with remote clients.

The only 2 issues that might prove challenging when working with someone not from your immediate proximity are: time difference and language barriers.

1. Proximity

It is much easier to work when at least one hour of overlap exists between the working hours of client and agency teams. Lack of overlap requires additional planning and more explicit written communication on both sides to ensure predictable project progress. In Droptica we still manage to deliver successful projects with clients in California and Australia, but our project managers have to take the asynchronicity of communication much more into account... and sometimes also adapt working hours a bit to allow for an evening status call with a client, who just got to his office on the other side of the globe.

2. Lanuage

Language, of course, may also prove to be a barrier or at least an obstacle to overcome. If you are working with an agency from a different country, then, typically the language you will have to communicate will be English. 

Budget

It helps a lot to know what your development budget is. Most agencies are good at delivering projects of a particular size, eg: 

  • small - up to €10k, 
  • medium €10k - €100k, 
  • bigger: €100-€500k 
  • or big: over 500k€. 

It is very difficult for a small company to deliver a huge project because it lacks processes and experience to coordinate a bigger team and track progress in a longer timeframe. On the other hand, a massive agency will have a hard time fitting its process into a smaller budget.

Another reason to have a budget handy is that many agencies will ask you about it. A great drupal agency is contacted by many potential clients and will have a process in place to quickly determine if there is a fit. You do not have to give a concrete amount (you may not yet know it), but having an overall level of acceptable cost in mind helps everyone decide if the match is right. An experienced agency will ask you not to waste your and their time if there is a misalignment of expectations regarding the size of the project.

An agency of a freelancer?

You may consider choosing a freelancer instead of an agency. This might actually be a cost-efficient solution to your project, but there are a few things you should keep in mind.

A freelancer works solo - you will have placed a lot of reliance on one person. If for whatever reason your ways part, or even in the person becomes temporarily unavailable, you have to have a contingency plan in place. Realistically, the only sound plan is that you are the fallback expert, because there is no one else who knows your project. A freelancer is therefore a good option only when the project is not very important or is not yet live and timelines on delivery are not very tight.

A team of freelancers requires coordination - if you hire a group of freelancers to deliver your project, you will have to coordinate the effort. They will not know each other and will usually not have worked in the same fashion. To ensure a predictable outcome, you will have to put processes in place to ensure that what they deliver is coherent. People from various backgrounds and with various experiences may choose different technical solutions to the same problem. If every one of your freelancers works by himself without technological coordination, your project might be in jeopardy. A solid agency, on the other hand, will have processes and structures in place to ensure that the deliverables of all team members make sense. 

The interview process

When you have the basics ready, it’s time to search for the agencies and contact them. There are a plethora of lists with agencies on the internet and a quick search in google for a “Drupal agency” will result in quite a good starting list of companies to contact. I will leave you to do this piece yourself. 

I will however talk about how to vett the agencies. Below I will list topics worth covering with the agencies of choice. This is by no means a closed list, but it is a good list to start the discussion and int also contains the most important points.

Do not start from your project

You are probably super eager to get down to details of discussing your project. After all, that is why you are looking for a partner - to progress your project.

This, however, might make it difficult to learn more about the company and will make it very time consuming to choose the right one. Details are difficult and can take a lot of time and you will not really be able to go through them with 7 or even 5 companies - especially if you have to grant access to systems or designs and documentation. It is best to wait till you chose one or two final contenders.

My suggestion, would be to briefly describe the project, mentioning the size and timeline, but without going into a lot of details initially. The preview will allow the agency to decide whether your project is potentially interesting, but you will not get bogged down with detailed discussions yet. You will be able to make your evaluation much more easily.

Let talk about questions to ask:

How do they work, how do they want to go about your project

This is a very high-level open question which allows you to learn how the company operates. You will learn about the approach they take to managing project, communicating, etc. It gives you an initial sense of what to expect in terms of how your project will be handled. It is a great opening question to a more in depth discussion. Things to look for here are:

  • Does the company have a process?
  • Is the process organised and predictable?
  • Does what they propose fit into your organisation, are they willing to adapt?

Ask follow up questions if you have any. Follow up questions aim to specify the general information and are a great way to identify if the company actually walks the talk or is this just the salesman telling you what you want to hear.

Will the agency use a methodology to deliver the project? There are multiple approaches to project governance and they differ greatly. On one hand there are the agile methodologies, including SCRUM, which deliver results quickly, but require involvement from your side. On the other hand, there are all waterfall methodologies, which do not require involvement during the project, but require very detailed specifications and bring a risk of not meeting the expectations when the project is actually delivered.

Communication

Communication on a project is very important. If it is set correctly and matches the process it helps everyone keep track and move forward. Not organised formally, it will slow the project down.

Things to learn:

  • How will the communication be handled? 
  • Who will be your primary point of contact. 
  • Will you be able to  communicate with whole team or just the Project Manager?
  • What tools will you use to keep track of progress and contact each other.
  • How will requirements be gathered? Will there be an easy way for everyone to access them?

These questions are aimed at understanding how you will deliver your requirements and keep track of what is happening on your project.

In Droptica we typically have 4 main communication streams:

  • Jira (Project Management / ticketing system). Jira is the backbone of the project. All the tasks and their acceptance criteria are gathered there and progress is tracked. Using a ticketing system helps everyone understand what is to be done, what do we currently work on and what is to be delivered.
  • A documentation system - where we gather project documentation
  • Slack - a chat for the whole team and the client to quickly catch up and discuss issues, ask questions. 
  • Video-conferencing - daily status meetings, progress presentation, demo meetings etc are best done in an actual meeting. Also sometimes it might be easier to talk then to post a million messages on slack toa agree some detailed topic.

Maintenance

Building on Drupal is just the start. You have to understand how the agency will take care of you project after it is delivered. As any software solution, Drupal will require security upgrades. You also might want to develop the project further but in smaller increments. You should verify if the agency is able to provide you with such service or if you will have to look for new one once the initial development is finalised.

In Droptica, for example, we have a separate drupal support team, which takes ofer finalised projects, monitors and upgrades and performs any other maintenance tasks required. 

Examples of previous work

The best way to verify if the Drupal agency is able to deliver you project is to ask them about similar projects or projects of similar size. This is especially important if your project is not a standard website but something bigger. Many Drupal agencies have experience in building marketing websites but are not able to create and maintain a complex system with multiple users and business logic.

Of course it might be difficult to find an agency which has built something exactly similar to your project. What you want to verify here is whether the company has built things with similar or greater complexity or size of scope.

Prices, estimations and agreements

Once you have gone through the initial interview, you are ready to talk about prices. Depending on the project, its size and complexity, this might be a quick or quite a long process. It is best to narrow down the number of agencies you are talking to at this stage not get overwhelmed with questions. At this stage it also good to understand:

  • How does the agency calculate cost
  • What are the payment term the agency allows
  • How will you be able to monitor progress if there are installments or prepayments involved

When talking about costs, it is important to remember that price alone should not be the only factor you take into account. In software development, quality is almost always cheaper in the long term. If an agency delivers a solid project, you will not have to incur additional cost of fixing multiple bugs and it will be much cheaper to maintain the project over a long period of time. Choosing a cheap, but not so experienced agency, might result in a project that will eventually prove very expensive to maintain and the initial gains will quickly be consumed by upkeep costs.

Overall impression

While gathering all the information about the company, it is also good to look at the overall impression. How do you feel about the company and the people you are talking to. If you chose a drupal agency, you will most likely have to be in  a lot of contact. How does this make you feel? Is the cultural match right? Is the vibe you are getting positive? 

Good chemistry is quite important, it will make for a much nicer experience if you actually like the people you are working with on you Drupal project.

Summary

When you have all the facts, you have to make a choice. Do it wisely looking not only at the price but the overall picture. The expertise, communication, people -  all pieces of the puzzle. I hope that the above questions will make it much easier for you to choose the right Drupal agency for your project.

Good luck!

Mar 27 2020
Mar 27

More and more software development companies (and not only those) start to move to a remote work setup. On one hand, it is the mark of current times, on the other - a result of recent global changes. The Covid19 pandemic is just a catalyst of the changes. It is also a test of how well the companies are prepared for the new situation. Remote work setup is something completely different to companies for which it was always part of the culture and something else for those who suddenly have to redefine all their working habits.

Remote work as part of a business continuity plan

Business continuity planning is one of the hallmarks of strong companies. If an organization has a plan, it means that the management looks into the future and prepares the company for an unforeseen crisis. Guaranteeing uninterrupted service delivery is key to successfully serving the customers, especially in tough times when they have problems of their own. Being a solid rock to lean is the best gift a company can give to its customers.

Remote work is a perfect approach to ensuring uninterrupted service. Thanks to organizing delivery processes in such a way that they can be executed from anywhere, service companies, including software development agencies, can ensure that the risk of service interruption is minimal.

In Droptica we always worked in with a remote-first philosophy in mind. Thanks to this, the current Covid19 crisis did not impact the services we provide. We could provide our clients with security. They were not exposed to any risk.

Droptica works remotely from the beginning of the company. Thanks to this, all the processes we built and all the tools we use work remotely and deliver expected results.

Moving to remote is not easy

Moving to remote work is not as easy as transporting computers to your employees’ homes. Successful remote work is only viable if the processes in the company allow for remote work. Companies moving to remote setup will have to create these and it will not always be easy. On some situations, a change in the whole company culture will be necessary. If you add to that the fact that not everyone is effective when working from home, some companies might have a tough time adjusting. A company is a complex organism and to work correctly all parts must fit together. 

In Droptica, from the very beginning, also taking this into account in recruitment, we created teams which could work remotely. All the tools we chose and processes we architected had to always be suited for a distributed team. Thanks to this, the current move to fully remote did not require any changes to our daily operations. We still use the same tools and follow the same processes which worked for us and our clients successfully for years.

Tools - software

Luckily there are multiple tools which support distributed teams. Each company, however, has to create its own mix which matches its operational model and business processes. In Droptica we mostly use Slack, Jira, AWS and Github as our basic system tools. More information about the tools we use is available in a series of blog posts on the subject (link)

Tools - Hardware

Our employees’ mobility was always important to us. Thanks to the fact that all of our employees were always equipped with powerful laptops, remote work is super easy for us. Of course, to allow our programmers to be as effective as possible, we expect them to use a set of monitors. Each of our employees receives 2 additional monitors to supplement their laptop. We make sure that everyone has a well organised, ergonomic workplace.

Training, culture, organization

For the company to be successful as a distributed organisation, it has to place a great emphasis on the culture. There is a balance to be struck between the speed of responses to questions posted on messengers and such and the time required by developers to work focused (what is very important when you create code). The companies which got used to everyone being at the reach of a voice, when you could always walk over and ask a question will have to put a lot of work to adapt to achieve fast but efficient remote communication.

In Droptica we rely on SCRUM a lot to help us communicate. Thanks to SCRUM we hold meetings for specific reasons at predefined times. Apart from that, we worked out mechanisms of asynchronous and remote communication, which everyone to keep track of what is happening. Our team members are so used to working in a remote setup that they plan automatically plan around the fact that communication is asynchronous and deliver functionality without any interruptions.

Remote agency and the client

While switching to a remote firs setup, the company cannot forget about the client. Clients are the most important part of the production process in a Drupal agency. In the case of many companies, having to work remotely, new ways of communication and cooperation with clients will have to be established. This is especially the case if previously face to face meetings were the de-facto standard.

In Droptica we cooperate with clients remotely since the beginning. Majority of our clients reside in different countries than ours. Although we see each other online often (sometimes daily), direct personal contact is not required to communicate effectively and cooperate. Our employees are trained and experienced in remote work with clients from remote locations. Thanks to this, we are able to provide the service on the same level as always.

How to choose a remote agency

If you want to choose a distributed agency  as your vendor, it is worth checking if:

  • The agency actually works remotely and for how long
  • Has processes in place which support project delivery and if these make sense
  • Supports its developers in remote work including in organisation of their workstations 

For more information about choosing the correct vendor, check out our post about choosing the best drupal team.

Remote agencies are more effective

In 2014 Harvard Business Review published findings of an experiment in which one of the call-centre companies wanted to verify “if” and “to what extent” remote work impacts employee effectiveness. For nine months half of the employees worked from home while the second half worked from the office. It turned out that 13.5% of employees working remotely did more calls to potential clients compared to the office group. It was estimated that in the 9-month period the company earned $1900 per employee and gained and an additional working day worth of work.

Summary

Working with a distributed Drupal agency makes perfect sense and can actually save you a lot of headaches, especially in turbulent times. Finding the correct one however may be a bit more challenging as working remotely successfully requires correct culture, processes and tools, things which cannot be obtained overnight.

Mar 13 2020
Mar 13

Your company has a complex website to create. Drupal was chosen as the main technology. None of the PHP developers have done anything in Drupal before or they have little experience. If this is your case, read this text before starting the development of your project. You will learn the risks and you will be better prepared to start the works. 

Below you will find 9 important things to take a look at before launching the programming works. If you will take proper care of each of these areas, you will be able to implement the project efficiently. 

1. Ensure the right workflow in the team

Creating Drupal-based websites by one person is a completely different kettle of fish in comparison to working as part of a team. If you build a team of freelancers who have previously worked alone with Drupal, you should expect problems. If this is a team that knows PHP but has no experience with Drupal, you should expect even bigger problems. 

Before starting, you must establish common principles, a common way of working. You should establish the following: 

  • Working rules in the code repository (Git or others)
  • Coding standards
  • Code flow
  • Database and files flow
  • Distribution of tasks in such a way that they do not interfere with each other and that no works are being performed on the same pieces of code. If it is not possible, communicate often so as not to duplicate the works being performed.

Thanks to these establishments, the team will know how to work together and focus on implementing the programming tasks.

2. Implement the tasks in the same standard  

It often happens with Drupal that every programming task can be done in many ways. It is important to establish common rules.

One example is the way of creating the contents. It is worth to determine if the contents will be created using the Layout Builder, Paragraphs, Gutenberg module, or another similar solution. Using several modules at the same time may result in problems. 

There are many more such decisions to be made when using Drupal. It is good to establish common standards. 

A system of supervising the application of these rules is also necessary, e.g. if the deadline of a sprint or stage is drawing near, then you should not take any shortcuts but rather stick to the standards.

3. Get to know the configuration options in Drupal well 

It is a common problem if you employ PHP developers for Drupal works. They start to solve a lot of tasks by creating code. Sometimes they spend dozens of hours creating functionality that is already provided in Drupal.

In many cases, you just have to go to the right place in the administration panel, click around a few times, and that is it. 

It is the extensive configuration options of the Drupal's core and its modules that constitute the strength of Drupal. They allow you to save hundreds or even thousands of man-hours spent on programming works. 

Use the ready-made Drupal options in your project and save the client's money.

4. Get to know the Drupal's API well 

Getting to know the Drupal's API helps you accomplish many tasks faster than using only PHP. 

If someone is not familiar with the Drupal's API, they sometimes create functions or classes that are already in the Drupal's core. This can turn out to be a waste of time.

The lack of knowledge concerning the API sometimes may also cause errors that are difficult to detect. An example would be adding the common PHP redirection header ('Location: '.$newURL); in hook_entity_insert. If there are many modules in the system using this hook, it is possible that not all will be executed after adding such a redirection. 

You can find more examples like this. Before starting the works, it is good to familiarise yourself with the Drupal's operation. The very minimum would be to read one of the books describing the creation of modules for Drupal. 

The Examples module is another important source of knowledge. Here you will find a huge number of examples. It is good to look through the codes of this module.

5. Use the View-mode 

Entity view modes are a very useful functionality of the system. They allow you to customise the view of the content depending on where you want to display it. You can define any modes and use them many times. 

Beginner developers often create code for every view mode instead of selecting several different modes and configuring them. It is not worth it. It is better to use a ready-made mechanism in Drupal and complete the tasks faster. 

6. Create entities if you plan to create your own tables in the database

Some business requirements force you to create your own tables in the database. When working with Drupal, it is good to add such tables to the database while at the same time creating Entities. 

As a result, you get a table that is operated via Entity classes and you can easily integrate the data from such a table with the whole Drupal, e.g. with the Views module.
If you will not use Entities, you will have to program everything concerning this table, e.g. the forms or the data-displaying pages. 

7. Write automated tests

Drupal is usually used to create medium- and large-sized websites that are developed over many months or years. When extending the functionality, it may happen that you will break something that was already working correctly. 

If you do not want to perform regular manual checks in order to ensure that everything works correctly, you need to have automatic tests written. 

Drupal has a PHPUnit framework for automated testing. You can also use other frameworks, e.g. Codeception and the Visualception extension. 

8. Automate the application creation and the deployment to the production server

The process of implementing new changes to the production server and the process of creating a website within the local developer environment should be automated. Everyone on the team should use the same scripts to create the application.

You then eliminate the problems of differences between the environments, e.g. when someone has changed something in the configuration on one version, but not on the other. You do not know then what and how should work properly, misunderstandings arise, you waste the time unnecessarily.

All changes should be introduced via code. The team should use a code repository (e.g. Git). You can be sure then that you have the same configuration on every instance of the application. 

9. Advise the client if you can do something a little differently but much faster

Drupal offers a huge number of functionalities and additional modules. With them, you can create really large-sized websites. 

Sometimes a ready-made module does not meet the requirements of the specification in 100% but it is enough to have a talk with the client about it, and most often the client will agree to a small change in order to save time.

Final thoughts 

I listed above the most important things that you should pay attention to when creating your first major website based on Drupal CMS.

The Drupal development team at Droptica knows all about these issues. We save our clients' money and provide a lot of solid code in a short time. We do not have to focus on eliminating problems but only on providing value to the clients. 

If you plan to build a Drupal-based website, be sure to analyse the potential problems mentioned above, and you will achieve satisfactory results. 


 

Mar 02 2020
Mar 02

At Droptica, we attach great importance to proper onboarding of new employees, particularly by getting them started with Drupal. We also want to give people who do not know the system a chance to get to know it in a structured and easy manner after they join our team.

As a future developer working for Drupal agency, you will get an opportunity to take part in a structured training course with a specific scope. The duration of the course is always adapted to the skills of our new hires, but it usually takes anywhere from three to five weeks.

Drupal agency which will take care of you

Throughout the course, you will be mentored by a Project Manager and Lead Drupal Developers. You will also get a special project set up in JIRA for you, along with a number of tasks to complete. The Project Manager will take care of the training process and meetings, while our developers with extensive Drupal experience will keep tabs on your tasks and give you a helping hand should the need ever arise.

Never used Docker before? No problem!

You will start your Drupal training by configuring your working environment. You will get a PHPStorm license, as well as the necessary permissions, so you can use the same tools as we do.

During your training, you will have an opportunity to learn the ropes of various tools, such as GIT, Docker and Jenkins, as well as using them under Linux You will learn how to build a website locally in your working environment, and you will get a chance to showcase your PHP coding skills, as well as try your hand at styling pages based on the provided designs.

In the further part of the training, you will learn how to update modules, explore XDEBUG and get to know the ins and outs of the Bootstrap library. You will come across Drupal 7 and 8 since we work for clients who want to keep the previous version of that CMS on their websites.

SCRUM – discover one of the world’s most popular ways of working 

Our company prides itself on its agile model – we often employ SCRUM and its various elements in our projects. We want you to feel as if you’re already on a project while you’re training.

During your Drupal training course, you will get to know a wide variety of elements of this model first-hand – as much as the form of the course allows you to experience. During the so-called week-long Sprint, you will get to take part in a number of events.

These include meetings, such as the Daily Scrum, Sprint Planning, Sprint Retrospective and Demo (which replaces and simplifies the Sprint Review for the purpose of the training).

The Daily Scrum is a meeting with a maximum of 15 minutes, and it takes place every day. During this meeting, the developer talks about what they have done since yesterday, what they are going to do that day and whether they need help with anything, or if something is blocking them from moving forward with their tasks. The remaining meetings are only held once a week.

Sprint Planning enables us to define the scope of work to be done in the week to come. It kicks off the new Sprint by setting the tasks, which will be displayed on the Active dashboard in JIRA.

The Sprint Retrospective is a much longer meeting, during which we delve deeper into the course of the training and talk about how we can improve our collaboration and the process, based on last week’s experiences. All of this is very important to us, and we will be happy to listen to your feedback on your training.

The Demo is a perfect opportunity for you to present the results of your work was done throughout the week.

Getting better together

Based on the feedback from previous participants of our Drupal training course, we are constantly working to help new employees learn Drupal and our tools in the most effective way.

Here’s what one of our developers, who has been working with us for several months now, has to say about it:

Jakub Wozniak speaking

Our goal is to build elite and certified teams, specialised in Drupal.

We are currently focusing our efforts on growing our team, so we encourage you to apply for the job listings that can be found on our career page. You can learn the Drupal ropes, too!
 

Feb 27 2020
Feb 27

Schema.org metadata is one of the most important SEO optimisation issues. This is what the extensions of HTML documents that allow search engine robots to better understand the meaning of individual subpages of your website are being called. Handling the visitor's metadata in Drupal already since version 7. In this article, I will present different ways to implement them.

What do you need metadata for?

Modern search engines such as Google or Bing are no longer simple text indexing tools. They become more and more intelligent and read the page content with better and better results. They classify the content and show it in an interesting form. If you correctly tag the type of content and its basic parameters in the HTML code, it will open new SEO possibilities for you. As a professional Drupal agency that creates large websites, we attach great importance to SEO.

An example would be an event website. When you organise many events and put them on a website, Google reads the metadata contained in the list ("Event" content type, date, name, place, etc.) and presents them under the search result. In this way, you become more visible.

microdata-example-1

Metadata is also widely used in service and product reviews. Properly tagged ratings appear in the search engine in the form of stars, thanks to which they achieve a higher conversion rate:

microdata-example-2

Google currently supports a very limited set of metadata types. However, it can be expected that it will be expanded with new types of content in the future. It is a good idea then to add metadata just in case – to be one step ahead of the competition.

Metadata formats

Suppose you have the following HTML code on the page, welcoming a user named John. You would like to provide search engine robots with information about this user.

<p>Hi, I’m John.</p>

In order to do this, you will use the "Person" content-type defined by schema.org.

There are three main metadata formats, each with its own pros and cons. They are all supported by Google.

JSON-LD

This format is definitely the easiest to implement and it becomes more and more popular. It consists in adding a JSON object containing all metadata to the document (usually at the beginning) – in our example, it is the "Person" content type, which is – a person and their name, i.e. "John". This approach does not require tampering with the webpage's HTML code contained between the <p> tags, however, it is characterised by a substantial code redundancy. If you have metadata to provide, e.g. a longer description, you have to repeat it within the HTML code twice.

<script type="application/ld+json">
{
 "@context":"http://schema.org",
 "@type":"Person",
 "name":"John"
}
</script>

<p>Hi, I’m John.</p>

RDF

RDF offers a slightly different approach to content tagging. In order to avoid the redundancy characterising JSON-LD, you modify the already existing HTML code to indicate where the metadata occurs. In the example above, in accordance with the RDF specification, you find the HTML tag containing the "Person" content type and point where the person's name is located.

<p vocab="http://schema.org/" typeof="Person">
  Hi, I’m <span property="name">John</span>.
</p>

Microdata

Microdata is currently the most popular format, employing a principle similar to RDF. There is a good reason I put it at the end of this list, though. It is considered to be very limited. Despite its prevalence (it is estimated that about 75% of websites implementing metadata was using it in 2016), it is the least flexible of the specifications listed. This is why you will not find it in Drupal.

<p itemscope itemtype="http://schema.org/Person">
  Hi, I’m <span itemprop="name">John</span>.
</p>

Metadata in Drupal

Metadata implementation is possible in almost every tool used for website creation. All you need is access to templates containing the HTML tags of interest to you. In Drupal, the data is usually handled by two modules – one located in the RDF's core, and one created by the Schema.org Metatag community. I will briefly describe both of these solutions.

RDF module

The Drupal's built-in RDF module is used to map entity fields to the appropriate types of metadata. This mapping is carried out by using .yml files and is quite cumbersome – mainly due to the lack of official documentation and graphical interface. Let us assume that you have the "Event" content type, defining the name of the event (title), the location it will be held at (field_place), its date (field_date) and the ticket price (field_price). In order to tag the event page in accordance with the RDF standard, you create an rdf.mapping.node.event.yml configuration file and put it in the new foobar module in the config/install directory:

status: true
dependencies:
  config:
    - node.type.event
  module:
    - node
    - foobar
  enforced:
    module:
      - foobar
id: node.event
targetEntityType: node
bundle: event
types:
  - 'schema:Event'
fieldMappings:
  title:
    properties:
      - 'schema:name'
  field_date:
    properties:
      - 'schema:startDate'
  field_place:
    properties:
      - 'schema:location'
  field_price:
    properties:
      - 'schema:price'

Then you run the just created foobar module and look into the HTML code of the event website. There are already RDF tags within it.

<article role="article" about="/node/1" typeof="schema:Event">
  <div class="node__content clearfix">
    <div class="field__label">Place</div>
    <div property="schema:location" class="field__item">Wrocław</div>
    <div class="field__label">Date</div>
    <div class="field__item">
      <time datetime="2020-04-25T08:00:00Z" property="schema:startDate" class="datetime">Sat, 04/25/2020 - 08:00</time>
    </div>
    <div class="field__label">Price</div>
    <div property="schema:price" class="field__item">1000</div>
  </div>
</article>

Schema.org Metatag module

There is a much simpler and more straightforward method for implementing metadata, provided by the schema_metatag module, which is an extension of the popular Metatag project. It employs the JSON-LD format and allows adjusting the field mapping via a convenient admin panel. For our example concerning an event, it looks like this (after enabling the schema_event helper module):

microdata-module

Hints on the Google requirements are extremely useful here – they save a lot of time when you are optimising the website the final effect in the HTML code looks like this:

<script type="application/ld+json">{
    "@context": "https://schema.org",
    "@graph": [
        {
            "@type": "Event",
            "name": "DrupalCamp Poland",
            "startDate": "Sat, 04/25/2020 - 08:00",
            "location": {
                "@type": "Place",
                "name": "Wrocław"
            },
            "offers": {
                "@type": "Offer",
                "price": "1000"
            }
        }
    ]
}</script>

How to check the metadata correctness?

In order to ensure that your website is properly processed by search engine robots, you should check its code with Google's structured data testing tool. Errors in microdata implementation also appear in the Google Search Console. 
 

Feb 26 2020
Feb 26
Main blog post photo_Schema.org And Metadata in Drupal Schema.org metadata is one of the most important SEO optimisation issues. This is what the extensions of HTML documents that allow search engine robots to better understand the meaning of individual subpages of your website are being called. Handling the visitor's metadata in Drupal already since version 7. In this article, I will present different ways to implement them.
Feb 20 2020
Feb 20

DrupalCamp London is a great event for all Drupal agencies. It is a conference that brings together hundreds of Drupal experts from around the world. It's a great opportunity to meet people who use, develop, design and support the Drupal platform. Therefore, as usually we will be there this year as well.

Droptica is a sponsor of DrupalCamp London 2020

We are proud to sponsor and participate in this year's DrupalCamp London. The event will take place on March 13-15, 2020 in London.

Sponsor graphic

DrupalCamp London is expected to attract over 500 specialists from around the world. Join it you want to discover Drupal or learn about what's new in Drupal 9.

From our part, two lectures will be presented by Maciej Lukianski. As follow:

  1. Droopler 2.0 - business websites on Drupal
  2. Training PHP developers in Drupal (how we do it in Droptica)

Don't miss it! :)

We are part of the Drupal community

We are a leading Polish Drupal agency supporting the Drupal community. As an avid supporters of Open Source technology, we engage in initiatives, supporting new modules, and sponsoring or organizing local Drupal meetings as much as possible.

Let's meet at our stand

We invite everyone to the capital of Great Britain to join talented minds in Drupal during the three-day DrupalCamp in the heart of London. We also cordially invite you to visit our Droptica stand, where Drupal's personalized mascot will be waiting for you to grab.

Learn more about DrupalCamp London and how to participate here: https://drupalcamp.london/.

Can we count on your presence? :)

 

Feb 20 2020
Feb 20
Main picture blog post DrupalCamp London 2020 DrupalCamp London is a great event for all Drupal agencies. It is a conference that brings together hundreds of Drupal experts from around the world. It's a great opportunity to meet people who use, develop, design and support the Drupal platform. Therefore, as usually we will be there this year as well. Droptica is a sponsor of DrupalCamp London 2020 We are proud to sponsor and participate in this year's DrupalCamp London. The event will take place on March 13-15, 2020 in London.
Feb 14 2020
Feb 14

When creating an e-commerce platform for a given industry, one needs to adapt the system to specific types of products. Every product type has different characteristics, e.g. size, colour, etc. Check out how easily you can customise Drupal Commerce to sell any type of product.

We are happy to tell you how to easily add attributes to products for several selected industries. We are a Drupal agency and we deal with it every day.

Attributes are the characteristics of given product types. For example, when you sell your own original T-shirts, thanks to the attributes you do not have to add separate products when you want to add another shirt size or colour. You create one product, add a size and colour attribute, and create other versions of the same product.

Thanks to this, the customer can easily add to the basket the product variant they are interested in, without having to switch to another subpage with a different product.

Adding Product Variant E-commerce Platform

Product attributes in Drupal Commerce

This post is a continuation of the series covering the Commerce module used to add an e-commerce platform to Drupal Previous part from the basic Commerce configuration.

You add new attributes to the product variation. The product variation is associated with a reference to the product. Thanks to this, you create one product, e.g. a T-shirt with the Droptica logo, and you add variations with different attributes to it. The attribute can be the T-shirt's colour or size. Every variation can also have a different price.

Start by creating a new type of product – T-shirt
From the admin menu Commerce → Configuration → Products → Product types

E-commerce creating a new type of product

Add a new product.

→ enter label
→ check that the product should have many variations
→ Product variation type – by checking Create new, a new variation type will be created automatically with the same name as the product type, in this case – T-shirt. You can also choose an already existing variation type.

product variation type

If you set Create new in the variation field, after saving the new product type, by going to 
Commerce → Configuration → Products → Product variation types you will see a new variation type.

new variation type

Product attributes for a T-shirt/clothing store

Two typical attributes for this type of store are colour and size.

Colour.

The standard solution for colour choice is to create a linked colour, where – after clicking it – the appropriate variation of the product loads.

solution for colour

Drupal Commerce lets you achieve this effect very simply.

The list of attributes and the option of creating them is available in
Commerce → Product Attributes

Lista atrybutów

Add a new attribute by clicking the Add product attribute button

add its name – Colour
element type – for now, set the Select list,
and the product variation, to which it is to be linked – T-shirt,

Add product attribute button

After saving, add colour values as you like.

add colour values

Now create a new T-shirt product and add some variations to it to see how the attributes work. Set different prices for different variations – you will see then that after changing the attribute the price will change automatically.


The colour attribute can be found in the product variation creation form.

colour attribute

When you go to the main product page, the colour selection list will be visible. 

the colour selection list

Change a selection list to links with colours

To achieve this effect, you need to add a new module – Colour Field

After enabling the module, add a new field to the colour attribute.

You can do it in the same way as you would for any other entity in Drupal.

Go to Commerce → Product Attributes 

And choose the Manage fields link

Product attributes

Add a new Colour field

Colour field

Save the settings

color settings for color

The next step in the configuration is to change the display of the colour field in the tab for managing the appearance of the form, as well as the appearance of the field when the product is viewed.

Managing the form appearance

Set for both fields to be visible. This makes it possible to set the name of the colour and its HEX value when editing the attribute.

manage form display

Managing the display.

In this case, you leave only the colour display and hide its name. In the format set – Colour switch. 

Thanks to this, coloured squares with colours to choose from will appear. By clicking the settings cogwheel sign you can change the size of these squares or replace them with ovals. 

manage display

The last step is to change the settings in the attribute itself.

Go to its edit options.

Change the Element type to Rendered attribute and add hex values for individual colours. 

editor color

After saving the settings on the page, the products – instead of an attributes/selection list – will be linked coloured squares.

Attributes for an electronics store

Laptops are one of the products found in electronics stores.

Typical attributes for this product type are:

  • pre-installed operating system
  • RAM amount
  • SSD capacity

and some others, but for the purposes of this post, I will show you how to add these three.

Attributes are added in the same way as in the previous example concerning a T-shirt store.

The result of the configuration will be:

  • operating system selection list
  • clickable RAM amounts to choose from
  • radio buttons with SSD capacity selection

Image laptop

I assume that the store has already added the product type and the product variation – Laptop

Configuration for the operating system attribute.

the operating system attribute

RAM attribute configuration

RAM attribute configuration

SSD capacity attribute configuration

SSD capacity attribute configuration

Summary

As you can see, attributes can be added to the products in a Drupal Commerce-based store in a very quick and easy way. By implementing them, you will help the potential customers find the right product faster and give yourself a chance to increase the turnover.

Feb 07 2020
Feb 07

In Drupal 8.4.X and later releases, Drush 9 is the only supported and recommended version. One of the key changes introduced in this version is a new model of writing custom Drush commands. From now on, .inc files are obsolete and you will no longer use them for your commands, which are now classes based on AnnotatedCommand format.

The underlying structure of a module containing your custom Drush command will look as follows:

Module structure with custom Drush 9 command

Drush9_custom_commands.info.yml file

Default information file with basic information for the module.

name: Drush 9 Custom Commands
description: Example of Drush 9 custom command.
core: 8.x
type: module
package: Examples

Drush.services.yml file

Using the standard services.yml file will not work anymore, and it will lead to an error since Drush now expects you to use a separate drush.services.yml file with service definitions for your custom Drush commands.

services:
  drush9_custom_commands.commands:
    class: \Drupal\drush9_custom_commands\Commands\Drush9CustomCommands
    tags:
      - { name: drush.command }

Drush9CustomCommands.php file

As such, this is the most crucial file, including the entire definition for your commands. 

<?php

namespace Drupal\drush9_custom_commands\Commands;

use Drush\Commands\DrushCommands;

/**
 * A drush command file.
 *
 * @package Drupal\drush9_custom_commands\Commands
 */
class Drush9CustomCommands extends DrushCommands {

  /**
   * Drush command that displays the given text.
   *
   * @param string $text
   *   Argument with message to be displayed.
   * @command drush9_custom_commands:message
   * @aliases d9-message d9-msg
   * @option uppercase
   *   Uppercase the message.
   * @option reverse
   *   Reverse the message.
   * @usage drush9_custom_commands:message --uppercase --reverse drupal8
   */
  public function message($text = 'Hello world!', $options = ['uppercase' => FALSE, 'reverse' => FALSE]) {
    if ($options['uppercase']) {
      $text = strtoupper($text);
    }
    if ($options['reverse']) {
      $text = strrev($text);
    }
    $this->output()->writeln($text);
  }
  
}

Your commands class inherits from DrushCommands, and you can use it to include numerous commands, of which all are separate methods using annotations.

Some of the annotations available for use include:
@command – command definition, which needs to follow the module: command structure;
@aliases – aliases for your commands, separated with spaces;
@param – which defines the input parameters for your command;
@option – which defines the options available for your commands, which should be put in an associative array, where the name of the option is the key;
@usage – example showing how the command should be used.


Usage examples for the above command:

Drush d9-message 
Hello world!

drush d9-message --uppercase --reverse drupal8
8LAPURD   

Conclusions

At our Drupal agency, we are pretty sure that those who wrote their custom Drush commands before Drush 9 was released can notice quite a number of differences here, as we’re seeing a departure from the old way, which was well-known to Drupal 7 developers, towards the new Symphony-based solution. Those who haven’t had a chance to work with Drush commands yet will probably find the above example pretty boring. What can your custom Drush command be used for in practice? For example, recently I had an opportunity to integrate Drupal with an external blogging service. Using cron, the posts are added to Drupal at specified intervals. Thanks to a custom Drush command, I can run such an operation at any time without using UI. What is more, the parameter enables its user to download any number of posts using a numeric value or “all” setting. The above solution proved to be very useful during the initial migration when all the existing posts and entries had to be downloaded. What kind of processes are you going to make easier thanks to custom Drush commands?
 

Jan 21 2020
Jan 21

Deciding on a CMS these days is not a simple task. There are many things to take into account and lot at stake.

  • Business websites are more important then they ever were and if a business wants to communicate effectively, it needs a great website.
  • Budgets and lead times for new CMS deployments get bigger and projects more and more complex. Often, it is difficult to plan for a complete overhaul and businesses have to plan for a phased approach
  • The business moves faster and the CMS has to keep up the pace with changes in requirements and technology

All the above means that often a CMS re-deployment is a multistep project for many months or even years. One cannot allow for errors. Choosing incorrectly can set the business back years.

In this ever-changing, fast-paced environment Drupal stands out as one of the best choices available. Here is why:

Speed of delivery and flexibility

One of the great risks of licenced products is being left behind the market. If your vendor does not build the features you need, you might get left behind the competition.

By choosing Drupal, CTOs have great flexibility and are not bogged down by one vendor’s feature list. With Drupal and its hundreds of modules, they can build whatever they like. They are also free to extend Drupal, building unique advantages for their companies.

Another thing to consider is the vendor's capacity to deliver. With a licenced product, a company is often locked down with one vendor and if his capacity is reached, development slows down. With Drupal, even if one vendor is at capacity, a CTO can easily extend by adding another one. This is quite often a strategy large enterprise clients chose from the outset - work with multiple agencies in parallel.

Standards and best practices

Being an Open Source project, and a very successful one, Drupal has clearly defined best practices and standards. This helps CTOs in many ways:

  • It is easier to set expectations from vendors
  • It is easier to replace one vendor with another
  • It is possible to cooperate with multiple vendors, setting the requirements on the commonly accepted development standards at the same time

Budget considerations 

Being open-source, Drupal does not have a licence fee. Licences, when it comes to the Corporate Market, can be quite expensive. This is an immediate financial benefit to the CTOs organisation

Long term, typically services of companies operating in the Open Source are a bit lower than those of their counterparts offering licenced products. This is because the cost of licenced tooling, partnership fees etc ado not have to be recharged to the end customer.

Another way in which Open Source can help reduce costs is by access to a wider range of service providers. Of course, you should still choose companies that are reliable and trustworthy, but in the Open Source, there are many smaller agencies and outsourcing partners, who, in the right mix, can help reduce the overall development bill.

Drupal prides itself in having a very vibrant business community. A CTO can choose from a really wide range of Drupal service providers, starting from the really big, like Accenture, through medium Drupal focused agencies like Droptica, down to a few-person-shops or even freelancers.

It is also quite common to handle initial ideation and development close (e.g. same city) and then hand-off the big delivery tasks which require a lot of manpower to an outsourcing partner in a region with lower costs - like Central or Eastern Europe. With Drupal being popular all over the world, you can easily find talent everywhere.

Drupal is tried and tested

CTOs time perspective is usually at least 5 years into the future. Often more. Choosing a technological solution with such a timeframe in mind is not easy. There aren’t too many solutions which withstood the test of time. Most of the other Open Source frameworks and proprietary CMSs are on the market since just a few years. Others have their best times behind them.

Drupal withstood the test of time. It is on the market for over a decade and is still extremely strong. The vibrant community is growing the number of websites built on Drupal 8 is growing steadily. Choosing Drupal, the CTOs know they will have a growing framework to work on which will continue to have wide support and a plethora of vendors years to come.

Drupal 8 is fully Enterprise ready

With the release of Drupal 8, any gap between proprietary CMSes and their Open Source counterparts has disappeared. Drupal offers everything Corporate clients need. 

API First

CTOs know that integrations are more and more important. To answer that, Drupal has built an incredible API framework. Out of the box, most of Drupal is available via JSON API. This includes all the content and a lot of the configuration. 

Drupal API is also not just an afterthought. It is baked straight into Drupal core functionality. Thanks to this, all the Drupal features, like content access permissions, translations, entity states and more are automatically available via an API.

Multilingual

Drupal in the 7 version was already a fantastic multilingual CMS. Drupal 8 improved upon it even further. If you are building a multilingual website, there is absolutely no better alternative.

Workflow management

A typical case for an enterprise-level website is a content workflow. Drupal includes a workflow module out of the box, thanks to which, it works really great with all the other Drupal features and functionalities.

Versioning

Drupal allows for versioning content. Combined with a Workflow module this brings powerful editorial mechanisms to the table. All this is of course already included in Drupal default installation.

...and more

Drupal comes with many other prepackaged features which make it a great choice for any CTO.

Choosing Drupal is a safe bet

By choosing Drupal, CTOs chose a system which is a safe bet. Drupal will not stand in the way of the success of the project. It is a solid foundation to build on. Especially if the right vendors are chosen.
 

Jan 16 2020
Jan 16

So, you already have a Drupal-based website. Great! What now? Well, you should definitely start promoting it! Some claim that nothing is ever lost on the internet; however, it won’t hurt to help your potential customers find your website using some SEO tricks. What should you do to get your website to come out of the depths of Google search results right to the first page? The following ten elements are indispensable for any website, which aims to be included high in search results.

1. H1 heading – website title tag

As the name suggests, it’s the real number one – it stores information for users (and search engines) about the topic of the subpage. It is visible to the user in the form of a title in a blog article, or a name of an item or service on a product page, and because of that, it needs to be understandable to your potential customer. It should also contain some keywords.

Out of the box, Drupal requires the author of an item to include a title and makes it easy to edit it at a later time; however, there is still some room for error, for example, if the title was never actually included in the project.
This can happen when the main page or landing pages consist of several sections or blocks. When the first thing your visitor sees on your website is a text banner, make sure that its text exactly matches the H1 heading.

2. Title tag

Unlike H1, the content of the title tag is visible as the browser tab name and in search results, where it is displayed as the title of a given result – this is the large blue text at the top of the search result. In the vast majority of cases, H1 headers and Title tags are similar.

In the case of Drupal, the Metatags module enables you to set up titles in such a way that the Title is copied directly from H1 by default, but it can be edited manually, should the need ever arise. For example, if your H1 is longer than the commonly suggested 50-60 characters, you can shorten it for SEO purposes using a Title tag.

3. Description tag

The third part of the tag triumvirate – the three HTML tags of the greatest importance for your website. It’s never an easy task to describe a website in just a few dozen characters in the title, which is why search engines display a longer description, which is taken directly from the Description tag.

However, letting the search engine fill the field automatically based on other fields of the website is hardly the best way to show what the website is really about. The Metatags module mentioned above enables you to edit this field as well, which solves this issue.

To further optimise your website in terms of SEO, make sure that H1, Description and Title tags contain similar keywords. By doing so, you will make sure that neither search engine robots, nor users will have any doubts concerning the content on your website.

example of search engine results with title url and description visible

4. HTTPS

Your website should use the HTTPS protocol, and all links using HTTP should redirect to HTTPS. Why? Security, of course. Websites, which don’t use the secure protocol are considered inferior to those, which use encrypted connections, in a bid to motivate website administrators to take care of their users’ security. Make sure that your website does not scare the visitors away with security issue warnings, and they will be much more likely to trust you.

In Drupal, HTTPS is fully supported and using it should not be any problem at all – just make sure that your server is properly configured.

5. Robots.txt

The main directory of your website should have a robots.txt file with proper content – a file used to inform website robots as to how they should index your website.

Drupal supports robots.txt file out of the box, and by default, it is configured in such a way that administrative subpages are not indexed. The only thing you will need to add manually is a link to the site map, which is discussed in more detail below.

6. Site map

Search engines use site maps to index all the pages making up a given website, which allows them to include content that was published fairly recently.

In the case of Drupal, the Sitemap module allows you to manage the content of your site map effectively. The system will automatically update the map if you set rules for different content sets and make changes concerning selected subpages.  

7.  ALT attribute

Every image and graphic element used on the website should not only have an ALT attribute, but it should also be described in a few words. This may sometimes seem to be counterintuitive and complicated, especially when it comes to graphic elements illustrating more complex or abstract concepts; however, you can also take this great opportunity to saturate the site with even more keywords. By doing so, you will provide search engines with information about the content of the image and – more importantly – you will also help people with visual impairments to use and understand your website. The software used by such people to read the content of various websites detects and reads aloud the descriptions contained in the ALT attribute.

Examples of ALT description of the header image of this blog post: improper (above) and proper (below)

Drupal enables you to add the ALT attribute when you are adding a picture or a graphic element. The best way to go about it is to make this a mandatory thing – by doing so; you will make sure that your editors won’t forget about it and won’t have to go back and do this in future.

8. URLs

Plan your website’s structure in advance and make sure that all the product links are as user-friendly as possible – this will also make them SEO friendly.

What does it mean for the link to be user-friendly?

  • It means that it’s readable to the user.
  • It may contain a keyword.
  • The words are separated with hyphens.
  • All the included words are in the language of the page.
  • The link should not contain any content from saved user session or other sources.

Just take a look at the URL of this article! At Droptica, we are using the Pathauto module, which automatically creates user-friendly URLs for every path in the system and enables us to edit them manually if needed.

9. Redirections

There are some situations in which you should use redirections on your website. From the standpoint of SEO, the most important of them are:

  • Redirections to the actual content, if the URL linking to it has been changed.
  • Redirections to new locations related to content that has been deleted.
  • Avoiding duplicated content.

Drupal offers a number of features, which are useful in all of these cases, such as creating automatic redirections of URLs containing uppercase letters to their lowercase counterparts. In the previous section, we mentioned a module that enables you to create user-friendly URLs. Redirect is yet another module that is useful for handling redirections – it allows you to create redirections to pages without a forward-slash (“/”) from pages with a slash at the end of their URLs.

10. Mobile-friendly approach

More than half of traffic on the internet is generated by users browsing using mobile devices, no wonder why search engines started prioritising mobile-friendliness as an important indicator of whether a website is relevant to the user.

Thanks to its theme engine, Drupal enables you to create responsive websites.

Summary

In this article, we shared ten important tips, which you can apply to help your Drupal-based website successfully compete for the top positions in search engine results. However, this is the absolute minimum. If you want to achieve even better results, take a look at our e-book about SEO and Drupal. In addition to numerous tips and extensive explanations, you will also find a handy checklist to help you carry out an SEO audit on your own.

You can also take advantage of our services! We will carry out an in-depth professional SEO audit of your Drupal-based website and point out how you can develop it further to make it more visible in search engine results.

Jan 10 2020
Jan 10

The new, stable version 2.0 of Droopler – Droptica’s Drupal-powered distro is coming soon, offering numerous new features aimed primarily at corporate websites. 

You can already test the new release at demo.droopler.com, you can also install the latest beta version, which is available at drupal.org and github.com

Below, you can find a selection of the most important changes.

New demo

Let’s start with the most notable and striking change, which can be seen right after setting Droopler up. The new demo presenting Droopler’s features is now much more extensive and provides an excellent foundation for you to build your own website. It contains subpages, as well as a full demonstration of the new menu and the footer. You should also take a look at the mobile version of the menu.

New Droopler demo

Media and Media Library

2019 brought a very important new feature in Drupal – its version 8.8 introduced the stable Media Library module for managing multimedia on a website, and Droopler 2.0 takes full advantage of its capabilities. We got rid of the previous way of adding photos to paragraphs, which was deemed inconvenient and inflexible. Now, you can add all the media on the website using a special library with reusable elements. What is more, you are no longer limited to static images! Paragraphs can now be illustrated in the background with Vimeo and YouTube videos. Droopler 1.4 users can take advantage of the full migration path to version 2.0, which encompasses converting the “image” type fields to the new solution.

Droopler media library

Colours

Version 2.0 brings totally new and more dynamic colour schemes. Of course, if you want, you can stick to the existing colours. Various shades of blue were replaced with deep red, which is better suited to corporate websites. We decided to change both the backgrounds and small accents.

SEO and website performance

We made every effort to ensure that websites powered by Droopler rank as high as possible in search engines. We focused on optimising page loading speed according to Google Page Speed, we also improved accessibility standards. From now on, content editors can have an impact on SEO by changing types of paragraph headings (H1 through H5).

Choosing header type in Droopler

Mega Menu

Droopler 2.0 features a brand-new menu, similar to the features you can find on large corporate websites. You can configure each submenu to be displayed in columns, with graphic elements and different sets of links. The menu is fully compatible with mobile devices. In addition, we introduced another feature, allowing you to use a second menu with less important links. Easily configured social media icons are another important new feature.

MegaMenu in Droopler

New footer

We redesigned the footer – it is now divided into several areas and uses a column model. This approach makes it easier to create pages for large clients, who need it to fit several addresses and key links at the bottom of each page.

New footer in Droopler

Paragraph settings

You are now able to change paragraph settings in Droopler. Using a couple of checkboxes, you can now invert their colours or stretch them to the entire width of the page. Styling individual paragraphs was also made much easier than before. Before, you had to reference them in CSS stylesheets using less-than-convenient IDs. From now on, every paragraph on your website will be able to have its own class, assigned from the editing form.

Paragraph settings in Droopler

“Reference Content” paragraph

To date, Droopler offered no way to show users the list of the latest blog articles on a single subpage. The new “Reference Content” paragraph adds this feature – and makes it amazingly flexible, since it allows you to change its display settings and select articles, which will remain pinned. The remaining spaces will be filled with articles sorted in descending order, according to the publication date, allowing you to display, for example, two sponsored posts and two latest news posts.

New blog paragraph in Droopler

“Side by Side” paragraph

Ever since we started working on our distro, we paid close attention to the needs and behaviours of the users, which is why the subsequent Droopler releases included a variety of useful paragraphs, which divided the page into two columns, enabling users to add text, photos, maps, videos and galleries. However, there were some restrictions, which prevented them from using any combination of these types of content. Droopler 2.0 gets rid of these obstacles by introducing the universal “Side by Side” paragraph. Each of its columns can contain independent elements – as of now, the choices include text with a graphic background and a reference to an entity, for example a product.

New Side by Side paragraph in Droopler

Bugfixes

We squashed hundreds of bugs, including those reported by users on GitHub and drupal.org, which allowed us to build an even cleaner and more stable codebase, developed according to the latest standards. Many of Droptica’s frontend and backend experts worked on the 2.0 release, and the project repository saw more than 1000 new commits and 180 pull requests. We have improved adding content, in particular the integration with the Geysir module.

Updated libraries and drupal.org compatibility

Until recently, Droopler’s architecture was not fully compatible with a slightly outdated distribution building system on drupal.org, which – in some rare cases – led to conflicts and errors when updating the websites. We managed to overcome these issues for the 2.0 release. What is more, we already started working on adapting Droopler to make sure that it is compatible with the upcoming Drupal 9. In addition, we eliminated various bugs, which popped up in connection with various latest Drupal 8 features. All these improvements will lead to greater security and long-term support for your websites.
 

Apr 05 2019
Apr 05

You can find many comparisons between popular CMS systems on the internet. Whenever Drupal is mentioned in them, it is always described with words like: safe, open, regularly updated. Today I'm going to explain why it has such an opinion. I will also present evidence that the level of security claimed by the Drupal community is not just empty words.

Here are five reasons behind the Drupal's safety:

1. Open-sourceness

You'll probably say: most CMS systems are distributed using the Open Source model. Why would that be Drupal's advantage? But take a broader look at CMS ecosystems. Almost all are available under open licenses, but their modules, plug-ins and skins are also being distributed using a purely commercial model. In the case of WordPress – the sale of add-ons is quite popular, and it limits the openness of their code. 

The Drupal community has developed a completely different, centralised model. It mostly consists of free add-ons, available directly from the drupal.org website, additionally covered by an internal security programme. Such an approach somewhat complicates the creation of modules and skins, but at the same time – makes it difficult to smuggle malicious code. The centralised model also reveals its advantages in the case of discovering security flaws in Drupal itself. It was perfectly demonstrated by the recent SA-CORE-2019-003 security update, which covered not only the core, but also the popular modules.

2. Security Team

You can often hear about critical errors in Drupal. In 2018 and 2019 we had to deal with some highly critical updates, some of them were even named "Drupalgeddon". However, this is not a result of poor-quality code. It's a result of the titanic work being carried out by the community, especially its part dealing with security.

Drupal's Security Team currently consists of over 30 people from various companies and organisations from around the world. It has earned a well-deserved reputation – through efficiency and downright paranoid concentration on security issues. It is supported by volunteers – also working as part of paid "bug bounty" programmes.

3. Organisations' support

Based on the example of WordPress – security does not go hand in hand with reach. Though the way which a given CMS is being used is very important. Drupal is a system often chosen by large corporations and government agencies (some of them can be found on this list https://groups.drupal.org/government-sites). Even such giants as Tesla, Nokia, Harvard University, London and Los Angeles, as well as NASA have trusted him. Each of these organisations takes good care of the security measures on their websites and conducts innumerable internal audits. The vulnerabilities found are usually passed to the previously mentioned Security Team.

The support of big players is very important and necessary – thanks to this, an open-source project becomes a common good, the development of which will benefit everyone interested. As a curiosity, I would like to mention that at the beginning of 2019 the European Commission announced the EU FOSSA 2 (The European Commission Free and Open Source Software Audit) programme – the second largest beneficiary of which is actually Drupal. As part of the programme, the people tracking errors will receive a monetary reward, the amount of which depends on the significance of the reported vulnerability. There's € 89 000 in the pot.

4. Composer and the components of Symfony

Since version 8, Drupal is integrated with Symfony components. It's a huge leap forward, towards code standardisation. The use of proven modules, such as EventDispatcher, HttpFoundation/HttpKernel and Routing, relieves developers of the need to maintain their own solutions. At the same time, the Symfony community is gaining new developers and new sponsors. Thanks to this, the level of security is constantly rising, because the basic libraries are getting more and more "tight".

Symfony is not only a collection of libraries, it is also equipped with Composer – an excellent package manager created based on the npm model. It was already possible to use it with Drupal 7, but in version 8 it became a downright obligatory addition, without which it is hard to even imagine the ongoing maintenance of pages. It can deal with complex dependencies, downloading libraries other than PHP, patching and running installation scripts. Today, when the Composer's operation is very well-developed, it's safe to say that it's a milestone in updating the Drupal code.

5. Security mechanisms

I've already written about many organisational, money and design factors. I didn't, however, specifically mention what mechanisms protect a webmaster from an attack on his site. Here are some of them:

  • Users' passwords are stored in a hashed form, using salt and multiplicative hash function. This makes brute force attacks more difficult to carry out.
  • The site configuration can be saved to .yml files and compared to its previous version. What's more, you can save it in the code repository using the Features module. It's an excellent solution that greatly limits the possibility of unnoticed database infection.
  • Advanced permission management allows you to define user roles and assign them activities that they can perform on the site. The creators of Drupal put a lot of emphasis on this issue, and today it results in a high degree of security.
  • The error reporting system records every security breach, including missing .htaccess files in sensitive directories.
  • The update system allows for downloading and installing the latest versions of modules from the admin panel. It's very convenient on shared hostings, that do not always have the ability to use Composer.
  • The Twig language used to create templates has advanced mechanisms used to defend against XSS and CSRF attacks.
  • The extensive cache allows you to effectively defend against DoS attacks.
  • It is possible to fully encrypt the database.

It is worth adding that Drupal complies with the OWASP (Open Web Application Security Project) standard, defining the basic security principles that a modern web project must meet.

Apr 05 2019
Apr 05

You can find many comparisons between popular CMS systems on the internet. Whenever Drupal is mentioned in them, it is always described with words like: safe, open, regularly updated. Today I'm going to explain why it has such an opinion. I will also present evidence that the level of security claimed by the Drupal community is not just empty words.

Here are five reasons behind the Drupal's safety:

1. Open-sourceness

You'll probably say: most CMS systems are distributed using the Open Source model. Why would that be Drupal's advantage? But take a broader look at CMS ecosystems. Almost all are available under open licenses, but their modules, plug-ins and skins are also being distributed using a purely commercial model. In the case of WordPress – the sale of add-ons is quite popular, and it limits the openness of their code. 

The Drupal community has developed a completely different, centralised model. It mostly consists of free add-ons, available directly from the drupal.org website, additionally covered by an internal security programme. Such an approach somewhat complicates the creation of modules and skins, but at the same time – makes it difficult to smuggle malicious code. The centralised model also reveals its advantages in the case of discovering security flaws in Drupal itself. It was perfectly demonstrated by the recent SA-CORE-2019-003 security update, which covered not only the core, but also the popular modules.

2. Security Team

You can often hear about critical errors in Drupal. In 2018 and 2019 we had to deal with some highly critical updates, some of them were even named "Drupalgeddon". However, this is not a result of poor-quality code. It's a result of the titanic work being carried out by the community, especially its part dealing with security.

Drupal's Security Team currently consists of over 30 people from various companies and organisations from around the world. It has earned a well-deserved reputation – through efficiency and downright paranoid concentration on security issues. It is supported by volunteers – also working as part of paid "bug bounty" programmes.

3. Organisations' support

Based on the example of WordPress – security does not go hand in hand with reach. Though the way which a given CMS is being used is very important. Drupal is a system often chosen by large corporations and government agencies (some of them can be found on this list https://groups.drupal.org/government-sites). Even such giants as Tesla, Nokia, Harvard University, London and Los Angeles, as well as NASA have trusted him. Each of these organisations takes good care of the security measures on their websites and conducts innumerable internal audits. The vulnerabilities found are usually passed to the previously mentioned Drupal Security Team.

The support of big players is very important and necessary – thanks to this, an open-source project becomes a common good, the development of which will benefit everyone interested. As a curiosity, I would like to mention that at the beginning of 2019 the European Commission announced the EU FOSSA 2 (The European Commission Free and Open Source Software Audit) programme – the second largest beneficiary of which is actually Drupal. As part of the programme, the people tracking errors will receive a monetary reward, the amount of which depends on the significance of the reported vulnerability. There's € 89 000 in the pot.

4. Composer and the components of Symfony

Since version 8, Drupal is integrated with Symfony components. It's a huge leap forward, towards code standardisation. The use of proven modules, such as EventDispatcher, HttpFoundation/HttpKernel and Routing, relieves developers of the need to maintain their own solutions. At the same time, the Symfony community is gaining new developers and new sponsors. Thanks to this, the level of security is constantly rising, because the basic libraries are getting more and more "tight".

Symfony is not only a collection of libraries, it is also equipped with Composer – an excellent package manager created based on the npm model. It was already possible to use it with Drupal 7, but in version 8 it became a downright obligatory addition, without which it is hard to even imagine the ongoing maintenance of pages. It can deal with complex dependencies, downloading libraries other than PHP, patching and running installation scripts. Today, when the Composer's operation is very well-developed, it's safe to say that it's a milestone in updating the Drupal code.

5. Security mechanisms

I've already written about many organisational, money and design factors. I didn't, however, specifically mention what mechanisms protect a webmaster from an attack on his site. Here are some of them:

  • Users' passwords are stored in a hashed form, using salt and multiplicative hash function. This makes brute force attacks more difficult to carry out.
  • The site configuration can be saved to .yml files and compared to its previous version. What's more, you can save it in the code repository using the Features module. It's an excellent solution that greatly limits the possibility of unnoticed database infection.
  • Advanced permission management allows you to define user roles and assign them activities that they can perform on the site. The creators of Drupal put a lot of emphasis on this issue, and today it results in a high degree of security.
  • The error reporting system records every security breach, including missing .htaccess files in sensitive directories.
  • The update system allows for downloading and installing the latest versions of modules from the admin panel. It's very convenient on shared hostings, that do not always have the ability to use Composer.
  • The Twig language used to create templates has advanced mechanisms used to defend against XSS and CSRF attacks.
  • The extensive cache allows you to effectively defend against DoS attacks.
  • It is possible to fully encrypt the database.

It is worth adding that Drupal complies with the OWASP (Open Web Application Security Project) standard, defining the basic security principles that a modern web project must meet.

Mar 15 2019
Mar 15

As always at this time of the year, we set our course on DrupalCamp London 2019. DrupalCamp London is the event most awaited by us. This year our team was somewhat bigger. Grzesiek and Maciek were joined by Jaro. As always, we had great expectations and thirst for knowledge – and as always, we were fully satisfied.

Wykład Macka na DrupalCamp London 2019

High level of DrupalCamp London

The conference began with the inaugural presentation of a valued Google Chrome programmer, Rowan Merewood. Due to this, the participants gained a solid amount of knowledge regarding user experience and website optimisation at the start of the conference already. The level of successive lectures was rising higher and higher – a trend maintained to the very end.

Session Jaro DCL 2019

What's more, we are incredibly proud and satisfied with our own presentations. There were as many as six lectures delivered by Droptica this year! But more about it below:)

6 Droptica lectures

After the last DrupalCamp London 2018, we became convinced that one should never give up. Where did this come from? Last year we have failed to get to deliver even one lecture during the conference. We drew conclusions and moved forward. The objective? Gaining a chance to present our – quite considerable – knowledge during DrupalCamp 2019.

Grzesiek session DrupalCamp London 2019

We did it! In the end, DrupalCamp London has accepted as many as six of the presentations proposed by Droptica. We are bursting with pride! The conclusion? Obstinacy,company development, constant enhancement of knowledge and better preparation yielded better results then we have ever expected. As always, every small or big success gives us even more energy and motivation.

Jaro DrupalCamp London 2019

Below are the topics that we presented during the conference.

1. Maciej Łukiański:

  • Droopler distribution - How can you save even 100 man-days during development of a new website with Drupal.
  • Continuous integration in a Drupal project (docker, ansible, jenkins, …).

2. Grzegorz Bartman:

  • Workflow in distributed Drupal agency.
  • Scrum everywhere - how we implemented Scrum not only in software development projects.

3. Jarosław Bartman:

  • Drupal 8 SEO.
  • How to make Drupal editor-friendly.

Maciek session DrupalCamp London 2019

We are particularly proud of the distinction given to Jaro's presentation about Drupal 8 SEO during the conference's summary carried out by Richard Dewick from Drupal Centric. You can read more about it here.

DrupalCamp London 2019 with Droptica until the next year

The conference is over. The emotions slowly subside. Droptica would like to thank DrupalCamp London for a great event. The sponsors – for bringing the event to life, and
the organisers – for the effort put into its preparation. We are glad that during the conference we had a chance to meet many Drupal-buddies and make many new relationships.

Gadgets DrupalCamp London 2019

DrupalCamp London 2019 is getting better year by year. It makes us happy, because – as the proverb goes – the appetite comes with eating. We start the countdown to the next conference while keeping the practical and impressive conference gadgets with us for the time being. See you at the next DrupalCamp London!
 

Feb 27 2019
Feb 27

DrupalCamp London 2019 is approaching fast. Are you ready for another great time with Drupal? This year, 42 sessions on Drupal and related topics are scheduled. We hope, that with our help, you will choose the most promising lectures. Below are a few sessions you should definitely visit. We've picked topics both for experienced coders and beginners, as well as something for business owners, editors, marketers and others. 

1. Visual regression testing  

https://drupalcamp.london/session/visual-regression-testing-patterns

This talk will cover:

  • BackstopJS for visual regression testing on Pattern Lab patterns on a Drupal 8 theme. 
  • How to set up regression testing for each pattern and for the entire pattern library and the problems you could run into when setting up regression testing for patterns. 
  • The benefits of using this approach.

To take a part in this session, it’s best to have basic knowledge of how the integration of Drupal and Pattern Lab works. 

2. No Monkey Business Static Progressive Web Apps

https://drupalcamp.london/session/no-monkey-business-static-progressive-web-apps

This talk will cover:

  • An overview of the architecture used to deliver ii.co.uk.
  • How the GatsbyJS was used to generate static content from Drupal and other dynamic sources.
  • How these pages were further hydrated with React for dynamic content after the initial page load.
  • The custom cache handling implemented to keep content build pipelines.
  • Division of the responsibilities for content generation between GatsbyJS and Drupal.
  • Resolving the real-time preview issue without waiting for Gatsby's upcoming hosted paid preview service.

3. Layouts in Drupal: past, present and future

https://drupalcamp.london/session/layouts-drupal-past-present-and-future

This talk will cover:

  • The history of building layouts in Drupal. 
  • Using Node reference (CCK), Nodequeue and custom template to build newspaper and magazine style layouts in Drupal 5. 
  • Having a look at "page builders" like Panels, Context and Block Visibility Groups. 
  • Dividing into CSS Grid layouts and using plugins like Masonry and GridStack for more advanced grid style layouts. 
  • Alternative approaches like Paragraphs, ECK/IEF and Bricks to create custom layouts. 
  • The pros and cons of these layout approaches and if and why they are now outdated.
  • New Layout Builder and some possible new approaches for building layouts in Drupal.

4. Creating an enterprise level editorial experience for Drupal 8 using React

https://drupalcamp.london/session/creating-enterprise-level-editorial-experience-drupal-8-using-react

This talk will cover:

  • Recent project results where a decoupled application with React was created, allowing the edition of content directly in the frontend. Using the possibilities of React to the fullest. 
  • Sharing an editorial experience with 'in-place' editing, 'context-sensitive' editing, 'drag-n-drop' content placement and creation, and much more.
  • Presentation of the application and vision of what an enterprise level editorial experience should look like.
  • What to expect when going fully decoupled with editorial experience and how this approach fits into the development of Drupal.

5. Migrate to Drupal

https://drupalcamp.london/session/migrate-drupal

The talk will cover:

  • Migrations in Drupal 7 and Drupal 8
  • Effective communication to project stakeholders
  • Writing and running efficient migrations

To take a part in this session, it’s best to have basic PHP coding skills and understanding of Drupal site building.

6. Droopler distribution - How can you save even 100 man-days during the development of a new website with Drupal

https://drupalcamp.london/session/droopler-distribution-how-can-you-save-even-100-man-days-during-development-new-website

Maciej Lukianski will show you that you don't have to possess a budget of over ten thousand dollars if you need Drupal 8.

This talk will cover:

  • Droopler modules.
  • What paragraphs Droopler can offer to build your new page fast.
  • How simple it is to build a new landing page with Droopler in a live demo.
  • What ideas we have for the future functionalities of Droopler.

7. Drupal 8 SEO

https://drupalcamp.london/session/drupal-8-seo

This talk will cover:

  • Drupal modules, Google tools and external tools and how to use them to prepare an SEO strategy.
  • How to plan an SEO strategy for your website and how to compare your website with the competition.

8. Out of the Box Initiative Update

https://drupalcamp.london/session/out-box-initiative-update

This talk will cover:

  • The project in the past and present state of the initiative.
  • Targets for inclusion in Drupal 8.7.0
  • Ways to contribute to the project.
  • Plans for the more distant future.

9. Scrum everywhere - how we implemented Scrum not only in software development projects

https://drupalcamp.london/session/scrum-everywhere-how-we-implemented-scrum-not-only-software-development-projects

This talk will cover:

  • Using Scrum in the marketing team.
  • Using Scrum in QA team to improve software testing in the whole company.
  • Using Scrum for company management.
  • Using Scrum for the training of junior developers.

10. Accessibility in UX Design: How we redesigned The University of West London’s website for everyone

https://drupalcamp.london/session/accessibility-ux-design-how-we-redesigned-university-west-londons-website-everyone

This talk will cover:

  • Importance of accessibility in design, showcasing examples from industry giants such as Microsoft.
  • Highlights of accessible design.

11. How to start contributing to Drupal without code

https://drupalcamp.london/session/how-start-contributing-drupal-without-code

This talk will cover:

  • Non-code contributions and impactful ways to get involved in the Drupal project.
  • How to get started.

Summary

The talks presented by us are just a small part of what you will learn during DrupalCamp London 2019. Undoubtedly, the selection of the most important presentations out of 42 proposals is a real challenge. Perhaps the above list will help you choose. Certainly, the level of the conference will be as always deliberately high. Therefore, surely everyone will leave London with a huge dose of knowledge of Drupal innovations.

Feb 27 2019
Feb 27
A landscape of LondonDrupalCamp London 2019 is approaching fast. Are you ready for another great time with Drupal? This year, 42 sessions on Drupal and related topics are scheduled. This is a really tasty bit for any Drupal developer who can come. We hope, that with our help, you will choose the most promising lectures. Below are a few sessions you should definitely visit. We've picked topics both for experienced coders and beginners, as well as something for business owners, editors, marketers and others.  1. Visual regression testing   https://drupalcamp.london/session/visual-regression-testing-patterns This talk will cover:
Jan 11 2019
Jan 11

Automate actions on your Drupal-based website. This will enable it to run even more independently from your input.

Automated mailing, publishing new content at a specified time and redirects after meeting certain conditions are only some of the functionalities featured in the Rules module.

Rules is a tool that enables you to define automatic, conditionally executed actions, triggered by various types of events.

What are some examples of such automated actions? For example:

  • redirecting the user after logging in;
  • sending an e-mail after adding content;
  • publishing content at a specific time.

At the foundation of the module lies the Event – Condition – Action rule, with one caveat – the CONDITION does not have to be a part of this scheme.
An example scheme could be as follows:

  1. A user adds an entry – that’s the event.
  2. The type of the added entry is “Article” – that’s the condition.
  3. Notify the admin about somebody adding an entry via e-mail – that’s the action.

Installing and setting up the Rules module

Currently (January 2019), the module is still available in alpha4 version only, which means that some of its functionalities and features might not work properly, there might also still be some errors and bugs.
For the purposes of this article, we used the DEV version of the module.

The below example works and was tested on the configuration outlined below:
Drupal : 8.6.5
Rules : 8.x-3.x-dev
Typed Data : 8.x-1.0-alpha2

Download the modules and unpack them in the /modules/contrib directory.
Rules – https://www.drupal.org/project/rules
Typed Data – https://www.drupal.org/project/typed_data

If you are going to create rules with user roles in the conditions, for example, if you want to redirect users with an “administrator” role who log in to a specific site, you will need to add a patch: https://www.drupal.org/files/issues/2816157-10.patch. It will probably not be needed in the future, but as it stands, it is still required for the user role condition to work properly.

How to apply patches? – https://www.drupal.org/patch/apply.

Creating and testing your rules

We are now going to show you how to add a new rule, step by step: Redirecting to the /admin/people page after a user with the administrator role logs in to the website.

Add a new rule - /admin/confg/workflow/rules.
Add new rule

Fill in the fields:

  • Name your rule using the label field.
  • From the drop-down menu, select the event that will trigger your rule. In our case it is going to be “User has logged in”.

Add a condition.
Select the appropriate value, in our case, it is going to be "User has role(s)”.

Select the right condition

Now, you are going to deal with the hardest part of creating a rule, namely selecting the appropriate objects that the condition will work on. You have to be really careful here, because despite this field being validated, sometimes you might set erroneous values that will cause problems down the road.
In the USER section, switch the field from the automatic filling mode to the selection mode. Switch to the data selection.

This condition concerns users, since it is their role that you have to check, so you need to type “account” in the field.

In the ROLES section, put in the roles that will fulfil the condition. You need to put in the machine name. You can view it at /admin/people/roles page by editing a selected role. In our case, it is going to be “administrator”. You can add more roles, just keep in mind to add just one role per line.

In the MATCH ROLES section, if you have selected more than one role, you can set whether the user must have each of these roles (AND) or any of them (OR).

In the NEGATE section, you can select whether this condition should be met when the above settings are NOT MET – in this case, the action will be executed when each user logs in, except for those who have an administrator role.

Rules module conditions

Add an action.

+Add action button of module shown

Select Page redirect from the System section.

"Page redirect"action selected

Enter the address (internal or external) to which the user should be redirected after logging in.

redirection address (internal)

Save and test the rule.

In order to ensure that the rule works, clear Drupal’s cache.

Now log in and check if the redirection is working.

My redirection for the admin role does not work. What do I do?!

PHP throws an error:

  • make sure you have applied the patch mentioned above;
  • make sure that you used the “account” object in the USER section of the rule condition.

Redirection does not work after logging in:

  • make sure that the rule is saved correctly;
  • clear Drupal’s cache;
  • make sure that the role name in the condition is correct.

Discover the many possibilities of the Rules module.

The Rules module is a really powerful tool which enables you to build complex rules that will automate your website.

If you have an idea for using this tool in your project, but you need help, do not hesitate to contact us.

Jan 11 2019
Jan 11
Cog wheels Toda we will show you hot to automate actions on your Drupal-based website. This will enable it to run even more independently from your input. We create automated actions on various types of websites as part of our drupal development service. Automated mailing, publishing new content at a specified time and redirects after meeting certain conditions are only some of the functionalities featured in the Rules module. Rules is a tool that enables you to define automatic, conditionally executed actions, triggered by various types of events. What are some examples of such automated actions? For example:
Jan 03 2019
Jan 03

At Droptica, we designed, made and implemented a new design of an online store for mobile devices for one of the oldest publishers in Poland. We used Drupal 7 Commerce and did some search engine optimisation. The results? Increased sales.

The mobile view of redesigned page.

Publishing house

Three years ago we started cooperating with Wydawnictwo WAM Publishing House, one of the oldest Polish Catholic publishers. In addition to books on religious topics, they also publish scientific and popular science publications, with a total of about 150 titles a year. Their products include prayer books, catechisms, academic dissertations, literature, biographies, young adult books and cookbooks, including the famous recipes of Sister Anastasia.

“The most admirable work of our time” said Pope Pius XI about the "Apostleship of Prayer,” which was the source of the Krakow-based Wydawnictwo WAM Publishing House. It was founded in 1872 by the Jesuits. In practice, this means that WAM celebrated its 145th anniversary in 2017.

What is more, the publishing house received many awards and distinctions, including the Magellan Prize, 2014 Feniks Award and many more.
The publishing house also runs an online store and Deon.pl – social networking and news website.

The start of cooperation

We started our cooperation by building modules to improve purchasing on their website. Some of the notable examples include:

  • a module allowing users to send purchased products as gifts;
  • pick-up point selection;
  • integrating Drupal Commerce with Freshmail, which allowed the publishing house to target newsletters and send information about new products via e-mail.

Mobile version

A mobile view of another subpage.

Our task was to modernise the Drupal Commerce store mentioned above. It was nice and pleasant on the desktop; however mobile devices were another story. The store was designed and created a couple of years ago using Drupal 7 when mobile shopping was mostly unheard of. The times changed. The customer expects to be able to browse the goods, find out more about the products and purchase them using any mobile device.

Since the standards today are totally different than when the store was set up, the graphic design and layout had to be improved in order to make shopping from mobile devices more convenient.

There is no doubt that traffic and purchases from mobile devices are on the rise. At the same time, we should remember that even if the customer prefers to place the actual order using a computer (for example, because they might prefer to enter data using a standard keyboard), they often learn more about the offer and browse goods on a mobile phone or a tablet.

A view of menu for mobile version of the website
We had to act.

We started with the preparation of a new graphic design. Our graphic designer created a design tailored to mobile devices, which not only looks nice but also improves and facilitates interaction with the user.

We decided that not only we would change the layout, but we were also going to choose appropriate fonts, which would be better visible on mobile devices, and change the colours. The desktop look would remain unchanged.
After a few minor changes, the client accepted the new design and our developers started working on it.

A mobile view of the user account subsite.

We started by moving CSS to SASS pre-processor. Variables, mixins and a cleaner structure made working on changes in the graphic design faster and more efficient.

At the same time, our QA department started creating tests in Codeception. One of the main conditions was to leave the desktop layout unchanged, testing in Codeception was supposed to capture the current appearance and inform about possible undesirable changes in the course of later work.

After initial preparations, we started working on the layout change. Our main priority was the purchasing process – the cart page, payment method selection and delivery. Then we changed the product pages, information pages and search results.

A view of the product page for a mobile version of the service.
At the same time, we also developed new tests to make sure that changes in the code do not cause changes in other parts of the store, that would be difficult to notice otherwise.

It turned out that not only changes in SASS/CSS, but also additional JS code were required. For example, the website had a number of carousels with graphics. In order to make sure that they worked properly, we had to additionally change and expand the existing JavaScript code. We have added additional drop-down elements on subpages in smaller resolutions and we completely rebuilt the menu, together with the addition of the so-called sticky menu for mobile devices.

Before each implementation we performed automatic and manual tests, we analysed the entire purchasing process and checked the layout along the way. We checked everything in different environments and browsers. We fixed all the bugs that popped up and made sure that the layout was unified.
Throughout the process, we regularly implemented the results of our work, on average once per week.

Summary of changes

  • Improved layout for mobile devices – it is now clear, it attracts customers and makes it easier to navigate the site and make purchases.
  • Changes in the purchasing process (forms were adapted to the mobile layout) to speed up shopping and facilitate the choice of delivery and payment methods from smartphones and tablets.
  • Fixing bugs on mobile screens.
  • The website was adapted to current standards.
  • Implementing automatic testing, helping us catch bugs and saving developers' time.
  • Reduced session duration coupled with increased revenues for customers using mobile devices. This means that the customers find what they are looking for quicker than before.
  • Increase in purchases made using mobile devices by 200%.

The client was very satisfied with the new layout, but we were most satisfied with the sales growth. After a few months of measurements, it turned out that not only were more purchases made via the desktop version, but purchases made using mobile devices increased twofold in comparison to the same period in the previous year.

SEO

After completing the work on the mobile layout, we focused our efforts on SEO (search engine optimisation and positioning) in order to attract new customers, increase traffic on the website and add new information about products in search results.

We started from connecting the website to Google Search Console, a tool that allowed us to measure traffic on the website, improve performance and catch bugs. Then, we implemented changes based on the SEO audit, which included:

  • improving headlines;
  • adding a notification for editors if the optimal number of characters in the description tag is exceeded – the information in the tag is displayed as hints during searches;
  • adding a sitemap;
  • adding price and product availability to Google search results; 

Additionally, we optimised the size, proportions and quality of graphics on the website.

The size of graphics and page loading speed is important for Google Search optimisation. The faster the page loads, the greater the rank, which in turn increases the probability of ending up on a high position in search results.

Smaller graphics result in faster page loading times. A faster connection enables serving more customers. Fast page loading is also important for customers using smartphones and tablets, especially when their connection is weak and slow. Thanks to that, more people can conveniently browse the pages and shop more frequently.

Results of SEO work

  • Changes resulting in a higher position in search engine results.
  • Increased traffic from search engines (Google and others). Traffic increased by 50%.
  • Indexing all pages belonging to the Wydawnictwo WAM Publishing House bookstore. Google and other search engines now crawl the entire content of the pages, indexing all products and improving the publisher’s competitive edge.
  • Adding tools informing about traffic on the website.
  • The search results include additional information regarding price and availability.
  • Easier work for editors (SEO compliance information) when adding new items.

Summary

Work on the new mobile layout and SEO-related changes resulted in a number of benefits for the Wydawnictwo WAM Publishing House. The most important of these were:

  • A significant increase in website traffic and sales in the months following the implementation of the changes.
  • Increase in desktop sales by 50% compared to the previous year.
  • Increase in purchases made using mobile devices by 200% compared to the previous year.
  • 84% more new users.
  • A new layout that makes it easier for customers using smartphones and tablets to navigate and make purchases.
  • New layout and graphic design for mobile devices.
  • Quicker page loading times.
  • Reduced rejection rate.
  • Full GDPR compliance of the store.
  • Improved (simplified and sped up) purchasing process – from the shopping cart to selection of the delivery method.
  • Making sure that Google and other search engines crawl all content, products and items.
  • Additional product information in Google search results.
  • Easier work for editors working in the bookstore.
  • Compliance with current standards.
  • Introduction of automated tests that will make it easier and faster for developers to later work for the publishing house.

We continue our cooperation with Wydawnictwo WAM Publishing House. We are currently working on improving warehouse processes.

Jan 03 2019
Jan 03
Phone, Bible and headphones on top of the desk. At Droptica, we designed and implemented a new design of an online store for mobile devices for one of the oldest publishers in Poland. We used Drupal 7 Commerce and did some search engine optimisation. The results? Increased sales!
Dec 24 2018
Dec 24
Droopler.1.4 visualisation. Logo of the Drupal distribution in the background. Droopler 1.4 is now available and you can download it right now! Personally, I’ve been testing the 1.4-rc version on Droptica’s websites for a number of weeks and I can honestly say that the new version is a great improvement in terms of editing work. Finally, creating corporate websites in Drupal is a simple and pleasant affair. Custom drupal development can be now left for un-typical web-apps only.
Dec 20 2018
Dec 20
Droopler logo. Below, there are several hands holding baloons in shape of letters that are arranged to form a word Soon, we will be celebrating the first anniversary of the day Droopler – our open Drupal distribution for corporate websites – was released. It is a perfect time for some summaries and plans for the future. In this article, I’m going to show you how Droopler works and what awaits its users in the upcoming release.
Oct 05 2018
Oct 05

Drupal is an open-source platform that more than a million of people across the globe find useful for their content management purposes. They choose Drupal because of its flexibility, reliability, and security. However, not all of them know how to use it properly. Find out about the mistakes that Drupal beginners often make.
Let’s dive deeper and analyze the examples of developer’s activity that could make Drupal ineffective and see what to do to get better results right away!

Bad content structure

Without the proper plan in place, your content structure can end up with a messy, incoherent experience for the site visitors. Determining a good structure from the very start increase your website performance. 

Try to minimize the number of content types, fields and tables. Too many content types can confuse content creators so you need to standardize them. For instance, you don’t need both “news” and “article” types, as these are almost the same - leave one of them. Moreover, creating new fields for every content type is a waste of resources that also comes with worse performance. Avoid making similar fields, as it brings unnecessary complexity to your site. 

This is why it’s good to design the system before you start to implement the elements. Take time to think about the structure and decide how the Drupal architecture should look like to improve website’s performance. Make it as simple as possible and use only the unnecessary elements. 

New Drupal developers also have problems with the folder structure. To be more precise, it’s about setting up wrong folder structure and putting themes and modules in the folder on a root level rather than in separate folders. This is one of the serious mistakes, as it affects the process of upgrading to the latest version and make debugging a way more difficult. You will lose a lot of time trying to fix it, so focus on creating a proper folder structure in the beginning. 

Using unnecessary Drupal modules across the site

Inexperienced developers can be amazed by a plethora of modules available which leads to installing too many of them. Even if Drupal developers don’t make a use of all of the modules at the beginning, they think that they will need it later. If you’re one of these developers… stop doing this! 
You need to realize that the more elements you have, the slower is your website, not to mention the mess you have in the code. With that being said, review all the modules you have again and get rid of ones you don’t need. Also, too many modules can decrease website security, so think about that. 

Not removing previous versions of the modules

Speaking of modules, Drupal developers often forget to remove older versions of downloaded modules. Some of them simply don’t know that even if the module is placed into a different directory, Drupal may decide to use the older version. It’s because the folders are usually on the same level. 
Sometimes, the software can switch between various module versions so, as you can guess, it can cause some problems. And we all know you don’t need such unwanted surprises.

Choosing unsupported modules in Drupal

A large number of different modules can be a challenge for a Drupal beginner, especially when there are ones that cover all the functionalities you look for. Unsupported modules can cause some problems in the long run, for instance, because of the compatibility issues or bugs that will never be fixed. 
Before downloading a new module, check when the last update was made and read the description provided by the author. Note that some projects are marked unsupported for security reasons so think twice before you decide to use one of these, as you risk data breach.

Ignoring code standards

When several people are working on the same website, it’s important to have code standards in place. Without them, you risk wasting the time trying to understand other developer’s code. Don’t make the mistake and start by creating the guideline to improve the quality of the source code and the efficiency of the team. 

Applying Drupal code standards is a good practice, even if you are a single developer working on your own project. Think about the situation when you want to expand the project that requires another developer’s involvement. With documented standards, it will be much easier to start, so… draw conclusions. 

Never make Drupal beginners mistakes again

It’s not surprising that newbies make mistakes, they simply need time to learn about all the opportunities the system gives them. Drupal is a complex tool, so there’s a huge chance to create something that doesn’t work the way we wanted, especially when we don’t have proper knowledge and experience. 

The good news is that you can always ask questions - the Drupal community exceeded a million of users that are willing to help. Someday, you can also be handy by sharing your experience. 

Oct 05 2018
Oct 05

Drupal is an open-source platform that more than a million of people across the globe find useful for their content management purposes. They choose Drupal because of its flexibility, reliability, and security. However, not all of them know how to use it properly. Find out about the mistakes that Drupal beginners often make.
Let’s dive deeper and analyze the examples of developer’s activity that could make Drupal ineffective and see what to do to get better results right away!

Bad content structure

Without the proper plan in place, your content structure can end up with a messy, incoherent experience for the site visitors. Determining a good structure from the very start increase your website performance. 

Try to minimize the number of content types, fields and tables. Too many content types can confuse content creators so you need to standardize them. For instance, you don’t need both “news” and “article” types, as these are almost the same - leave one of them. Moreover, creating new fields for every content type is a waste of resources that also comes with worse performance. Avoid making similar fields, as it brings unnecessary complexity to your site. 

This is why it’s good to design the system before you start to implement the elements. Take time to think about the structure and decide how the Drupal architecture should look like to improve website’s performance. Make it as simple as possible and use only the unnecessary elements. 

New Drupal developers also have problems with the folder structure. To be more precise, it’s about setting up wrong folder structure and putting themes and modules in the folder on a root level rather than in separate folders. This is one of the serious mistakes, as it affects the process of upgrading to the latest version and make debugging a way more difficult. You will lose a lot of time trying to fix it, so focus on creating a proper folder structure in the beginning. 

Using unnecessary Drupal modules across the site

Inexperienced developers can be amazed by a plethora of modules available which leads to installing too many of them. Even if Drupal developers don’t make a use of all of the modules at the beginning, they think that they will need it later. If you’re one of these developers… stop doing this! 
You need to realize that the more elements you have, the slower is your website, not to mention the mess you have in the code. With that being said, review all the modules you have again and get rid of ones you don’t need. Also, too many modules can decrease website security, so think about that. 

Not removing previous versions of the modules

Speaking of modules, Drupal developers often forget to remove older versions of downloaded modules. Some of them simply don’t know that even if the module is placed into a different directory, Drupal may decide to use the older version. It’s because the folders are usually on the same level. 
Sometimes, the software can switch between various module versions so, as you can guess, it can cause some problems. And we all know you don’t need such unwanted surprises.

Choosing unsupported modules in Drupal

A large number of different modules can be a challenge for a Drupal beginner, especially when there are ones that cover all the functionalities you look for. Unsupported modules can cause some problems in the long run, for instance, because of the compatibility issues or bugs that will never be fixed. 
Before downloading a new module, check when the last update was made and read the description provided by the author. Note that some projects are marked unsupported for security reasons so think twice before you decide to use one of these, as you risk data breach.

Ignoring code standards

When several people are working on the same website, it’s important to have code standards in place. Without them, you risk wasting the time trying to understand other developer’s code. Don’t make the mistake and start by creating the guideline to improve the quality of the source code and the efficiency of the team. 

Applying Drupal code standards is a good practice, even if you are a single developer working on your own project. Think about the situation when you want to expand the project that requires another developer’s involvement. With documented standards, it will be much easier to start, so… draw conclusions. 

Never make Drupal beginners mistakes again

It’s not surprising that newbies make mistakes, they simply need time to learn about all the opportunities the system gives them. Drupal is a complex tool, so there’s a huge chance to create something that doesn’t work the way we wanted, especially when we don’t have proper knowledge and experience. 

The good news is that you can always ask questions - the Drupal community exceeded a million of users that are willing to help. Someday, you can also be handy by sharing your experience. 

Sep 26 2018
Sep 26

It’s been two years since the première of Drupal 8. We already got used to the differences between versions 7 and 8, and a lot of websites were created based on D8. Many Drupal 7-based websites are applications that use Drupal Commerce – an e-commerce module for Drupal. Many of the applications were set-up with the Commerce Kickstart distribution, which was based on this add-on. What’s the way to do it with D8? For a long time, only the alpha version was available, then a beta version was released. On the 20th of September 2017, we saw the release of version 2.0. As of today, the current version is 2.9. We'll see what’s new in DC and how it works with D8. For testing purposes, we are going to use DC 2.9 and Drupal 8.5.9 with Droopler distribution.

Set-up and requirements

According to the manual, it is recommended to install Drupal using Composer; set-up requires Drupal 8.5 or newer. We did not have any issues with the installation process. To install the newest DC, we used the following command:

composer require "drupal/commerce"

DC requires several additional modules (Address, Entity, Inline Entity Form, Entity Reference Revisions, Profile, State Machine). When using Composer, you don’t have to worry about installing them manually, as they will be added automatically. After successful set-up, the list of modules will grow by 12 new entries.

List of modules with new items sorted in alphabetical order

Functionality, modules and innovations

We have launched all the modules for the purpose of testing. The Commerce icon appeared on our main menu. At first glance, you can see a number of options that were not included in the standard version for D7. This includes:

  • Store types
  • Product attributes
  • Promotions
  • Order types
  • Order item types
  • Checkout flows
  • Product variation types.

Store and Store types

It allows you to define store types your website, “online” is added by default. Adding more store types may be useful if you have a network of brick and mortar stores or branches in different countries. These stores may have a country-specific offer but use the same database of all products kept in one place. You should remember that a product may belong to one or more stores; however, an order placed by the user is always assigned to one store.

Another interesting option is the possibility of creating stores by users on your website, allowing vendors to open their online stores on your platform, as well as create and sell their own products, just like ETSY. You can find out more about that functionality from Drupal Commerce documentation.

Product attributes

Allows you to add attributes to your products. There are three display options available: Select list, Radio button and Rendered attribute. These attributes can be assigned to types and used when adding new products.

Attributes - a selectable list with three available options

Promotions

DC provides you with a sub-module that allows you to add bonuses and discounts. The discount can be set for specific products or the entire order. The discount may be either a fixed amount or a percentage, and they can be assigned to a role, a shipping address, or an e-mail address. You can also limit promotions and special offers to a maximum order value or currency. In addition, you have the option to add start and end dates, limit the number of uses and decide whether a discount can be combined with other promotions. Admittedly, this is a great convenience. Compared to other e-commerce systems, these are the things that should already be standard. In D7, it was not so obvious, and it could cause quite a headache.

A view of addingthe promotion in Drupal Commerce 2

Order types

Another new thing in DC is a new approach to orders. You can now create several order types with different shopping paths, or even showing shopping cart in a different way. This is quite an interesting solution and it will certainly be useful for more complex projects, where products require a different business approach. Each type can have its own unique fields and rendering methods.

A view of order types page

Checkout flows

As mentioned above, in addition to the order types, you can set up many different shopping paths. They may vary depending on the type of order placed. The entire order process is displayed using plug-ins. By default, you can take advantage of Multistep; however, you can add your own plug-in and use it, for example, for one of several shopping paths. This is quite an interesting approach, thanks to which you won’t have to alter the single default path. You can check out how to create your own flow plug-in here: https://docs.drupalcommerce.org/commerce2/developer-guide/checkout/create-custom-checkout-flow

Adding your own module to the list of available plugins

Order item types

One could say that this is something like “Line item” from D7 – an item that stores order data and products, you can also define your own fields for storing other information.

Commerce 8 in action

Let's see how commerce works in practice.

Adding a product

A subpage to add a product. Some options created before are available to choose

As you can see, you can use the attributes and variations of the products that you have created earlier. Let’s add a product with several options to choose from.

Product sheet

Product page
Cart

A cart
The standard cart is a block with views, which can be easily and freely configured, like in D7.

Payments

We have included the default test payments available in the module for the purpose of our tests. If you want to use a ready-made gateway, you can go with:

PayPal - https://www.drupal.org/project/commerce_paypal - beta1

Tpay - https://www.drupal.org/project/commerce_tpay - rc2

Shipments

You can take advantage of a shipping module – Commerce Shipping beta4.

https://www.drupal.org/project/commerce_shipping

It is integrated with the physical model, thanks to which you can use automatic conversion of sizes and scales to the final shipping cost.

A view of "adding the package type" page

As for the shipment integration, I only managed to find an Alpha3 version for FedEx.

https://www.drupal.org/project/commerce_fedex

In addition, DC developers used the Address module.

The address fields are supported for more than 200 countries. They include locations, regions, voivodeships, Länder and so on from most countries of the world. In addition, you can create custom “Address zones” and assign special properties such as special shipping prices, taxes, etc.

Summary

Drupal Commerce has a number of basic functions and many interesting innovations operational and working, which is, of course, a huge advantage. In addition, the developers decided to provide users with more configuration options by default, compared to the D7 version. A typical site builder might have issues with building a store for a client, due to the lack of D7 modules and the fact that the majority of them is in alpha or beta version, which means that they may be unstable. If you don't develop advanced modules for the D8, it can be a huge obstacle, otherwise, you might have to develop them yourself.

What was great about DC was the fact that we were able to configure and set the basic functions of our store in a short time without any problems. More and more modules are released, and a large number of them is already available in stable versions. That is why the combination of Drupal 8 and Drupal Commerce is a tool that gives a lot of possibilities for implementing interesting projects.

You might ask whether you should go for a proven Commerce with D7 duo or try the innovations introduced in D8.

The answer is... It depends on the project, your development resources, as well as time and budget for developing elements that are not available or do not work properly with D8. It is worth mentioning that pages based on Drupal Commerce receive SPLASH AWARD on regular basis. Since 2014 the competition names the best Drupal sites. More on this topic here: https://www.emerce.nl/wire/frmwrk-wint-tweede-prijs-drupal-splash-awards

Splash award certificate for Drupal Commerce site

However, as of now, the project looks promising and we keep our fingers crossed for the further development of Commerce. If you need more information about DC, feel free to visit https://docs.drupalcommerce.org/

We also encourage you to read other articles on our blog!

Sep 21 2018
Sep 21

What to do with an old, outdated website that you would like to keep online? The perfect solution is to archive it to pure HTML code. We will demonstrate it on the example of a drupalcamp.pl website created in Droopler, based on Drupal 8.

Why archive pages at all?

Sometimes websites have their expiration date. It may result from the life cycle of the technology used to build it or simply because the website was created for an event or some special occasion. When you organise a music festival, for example, the website is no longer up to date and necessary after it ends. When you have long forgotten websites on your server, their code may be so outdated that it will turn into a threat in the future. If, for some reason, you want to keep your websites on the Internet, you have to take into account the cost of their constant maintenance and updating.

What are the costs of an unused website?

The cost of maintenance depends to a large extent on the technology used. Let's focus on Drupal 8 since it is one of the safest CMS available on the market. Updates to D8 are published monthly, and every six months a version containing new functionalities is published. This means you need to install a fresh release of Drupal 12 times a year and test our website to see if it's still working, so you can stay on top of updates. We know from experience that this can be very time-consuming.

On the other hand, if you decide against upgrading, your website is now at risk of being attacked and poses a threat to other websites on your server. Shortcomings in the security department may lead to much higher costs than updating your code on an ongoing basis.

The question arises – how to avoid maintenance costs and keep the website online? A great compromise between sentiment and cost-effectiveness is the conversion to pure HTML code.

What are the advantages and disadvantages of pure HTML?

Deploying websites written in pure HTML is in a sense a return to the roots. In the age of advanced CMSs, hardly anyone remembers that a website can be created without the use of server-side interpreted languages, such as PHP.

Why writing pages using HTML only was forgotten?

  • Due to difficulties in updating their content.
  • Because it is not possible to reuse the code for global elements (such as header, main menu, footer).
  • Due to the static nature of HTML, which makes it difficult to create administrative pages.

So why convert an unused Drupal 8 website to pure HTML?

  • This will result in a rapid increase in the speed of operation of all subpages, including those which have been the slowest so far.
  • It will be very difficult to attack the website if you configure the server properly.
  • Updating the code will become completely unnecessary, the cost of maintenance will be practically zero.

What will be the limitations of a website converted to HTML?

  • Changes to the content will become more time-consuming. The developer will include them in a local copy and then generate the HTML version for publication on the server.
  • Dynamic elements such as forms will stop working.

How to adapt a website for archiving?

Not every website is suitable for archiving right away. First of all, you should make sure that none of the subpages contains any elements requiring PHP scripts to work:

  • Contact forms (they can be replaced with embedded Google Forms).
  • Search engines (they can be replaced with Google search on the website).
  • Views Exposed Filters.
  • AJAX in views.

It is also necessary to disable error messages sent by the server – especially when copying a website from localhost. During archiving you should use settings as similar to production as possible, including CSS/JS aggregation and lack of additional diagnostic information generated by Twig.

At the beginning of the article, we promised to describe the conversion to HTML, based on a real example. Therefore, we are going to present the method of archiving the drupalcamp.pl website, dedicated to the DrupalCamp 2018 conference organised by us. This is a cyclical event, but each subsequent year we prepare a completely new website. Once DrupalCamp has taken place, we leave this page up as a souvenir, archived to HTML at a separate address.

The website of DrupalCamp conference in Wrocław.

What preparations did drupalcamp.pl require? First of all, we removed the subpages with the forms, which were no longer needed, since the conference has already ended. We made sure that all views worked without AJAX on the programme subpages. We also carried out a quick JS audit to eliminate potential code issues when PHP is disabled.

The archiving process

We use the httrack software, which is available under the GNU GPL3 license, in order to automatically archive pages. It is available for Windows, Linux, OSX and Android. We use httrack via a Linux console. There are plenty of switches and options available in the documentation, here is our command to make a 1:1 copy of a website, while maintaining the link structure:

httrack http://example.com -O output_dir --disable-security-limits --max-rate=99999999999 -K3 -X -%P -wqQ%v --robots=0 -N "%h%p/%n.%t"
  • --disable-security-limits - disables the built-in transfer limits, this is useful when our local server is the source.
  • --max-rate - sets the maximum transmission speed.
  • -%P - tries to recognise all possible links to files on the website.
  • -K3 - does not change the links on the pages.
  • -N "%h%p/%n.%t" - does not change file names.
  • -X - on the next command, deletes files from the archived version that were deleted in the original.
  • -wqQ%v - standard mode, silent, with a list of processed files on the screen.

The resulting page image is not yet completely finished. The subpages are in files such as about-us.html, instead of about-us/index.html. A simple script will fix this problem:

#!/bin/bash
for f in $(find output_dir/example.com -name "*.html" -type f); do 
        if [[ $f = *"/index.html" ]]; then
                echo "Omitting $f"              
        else
                echo "Processing $f"
                mkdir "${f%.html}"
                mv $f "${f%.html}/index.html"
        fi
done

The copy created in this way will be indistinguishable from the original to the observer. This is important for the preservation of existing positions in Internet search engines.

Httrack’s compatibility with Drupal

Drupal 8 is not fully compatible with httrack. The main problem is the responsive images presented via the <picture> tag. Proper conversion to HTML requires providing httrack with hints for additional downloads.

The drupalcamp.pl website that we archived is based on Droopler, an in-house, free of charge distribution of Drupal 8. In version 1.3 of Droopler, we have implemented full support for httrack, which helps with identifying and downloading all graphics files used on the website.

How did we “improve” the compatibility with httrack? We used a very simple solution in the form of hooks preparing a list of files to download. Hints for the bot are placed in the <head> section of the page, as subsequent <link> elements:

<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_2000/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=YkFsAytN" rel="droopler:c0527d:img0" />
<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_1200/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=OEsKzsbg" rel="droopler:c0527d:img1" />

These elements are recognised by httrack and downloaded to the copy. Thanks to this, we can maintain full responsiveness of the images. The excess code is usually deleted from the console by means of a regular expression.

Conversion results

The result of conversion to HTML is very satisfactory in our case. We’ve got a folder with files of a total size of about 20 MB. As one would expect, the access time to an HTML file is a few milliseconds, meaning that it is negligible. It remains very low even under heavy loads. So far, this value on the production server has oscillated around 200ms (of course for users who weren’t logged in, with active cache). Under the load, it increased to about 700ms.

We checked the correctness of export using Screaming Frog SEO Spider software. It did not detect 404 errors, which means that the archiving was 100% successful. Also, the browser consoles do not show any JS errors.

It can be expected that in the next few days the DrupalCamp 2018 website will be finally retired and replaced by pure HTML version. In this way, we will avoid the need to update it and, therefore, we won’t incur additional costs. If there is a need to make changes to the content, we will make them on a local version, based on Drupal, and then automatically generate a new HTML page. We encourage you to take advantage of our experience!

Sep 21 2018
Sep 21

What to do with an old, outdated website that you would like to keep online? The perfect solution is to archive it to pure HTML code. We will demonstrate it on the example of a drupalcamp.pl website created in Droopler, based on Drupal 8.

Why archive pages at all?

Sometimes websites have their expiration date. It may result from the life cycle of the technology used to build it or simply because the website was created for an event or some special occasion. When you organise a music festival, for example, the website is no longer up to date and necessary after it ends. When you have long forgotten websites on your server, their code may be so outdated that it will turn into a threat in the future. If, for some reason, you want to keep your websites on the Internet, you have to take into account the cost of their constant maintenance and updating.

What are the costs of an unused website?

The cost of maintenance depends to a large extent on the technology used. Let's focus on Drupal 8 since it is one of the safest CMS available on the market. Updates to D8 are published monthly, and every six months a version containing new functionalities is published. This means you need to install a fresh release of Drupal 12 times a year and test our website to see if it's still working, so you can stay on top of updates. We know from experience that this can be very time-consuming.

On the other hand, if you decide against upgrading, your website is now at risk of being attacked and poses a threat to other websites on your server. Shortcomings in the security department may lead to much higher costs than updating your code on an ongoing basis.

The question arises – how to avoid maintenance costs and keep the website online? A great compromise between sentiment and cost-effectiveness is the conversion to pure HTML code.

What are the advantages and disadvantages of pure HTML?

Deploying websites written in pure HTML is in a sense a return to the roots. In the age of advanced CMSs, hardly anyone remembers that a website can be created without the use of server-side interpreted languages, such as PHP.

Why writing pages using HTML only was forgotten?

  • Due to difficulties in updating their content.
  • Because it is not possible to reuse the code for global elements (such as header, main menu, footer).
  • Due to the static nature of HTML, which makes it difficult to create administrative pages.

So why convert an unused Drupal 8 website to pure HTML?

  • This will result in a rapid increase in the speed of operation of all subpages, including those which have been the slowest so far.
  • It will be very difficult to attack the website if you configure the server properly.
  • Updating the code will become completely unnecessary, the cost of maintenance will be practically zero.

What will be the limitations of a website converted to HTML?

  • Changes to the content will become more time-consuming. The developer will include them in a local copy and then generate the HTML version for publication on the server.
  • Dynamic elements such as forms will stop working.

How to adapt a website for archiving?

Not every website is suitable for archiving right away. First of all, you should make sure that none of the subpages contains any elements requiring PHP scripts to work:

  • Contact forms (they can be replaced with embedded Google Forms).
  • Search engines (they can be replaced with Google search on the website).
  • Views Exposed Filters.
  • AJAX in views.

It is also necessary to disable error messages sent by the server – especially when copying a website from localhost. During archiving you should use settings as similar to production as possible, including CSS/JS aggregation and lack of additional diagnostic information generated by Twig.

At the beginning of the article, we promised to describe the conversion to HTML, based on a real example. Therefore, we are going to present the method of archiving the drupalcamp.pl website, dedicated to the DrupalCamp 2018 conference organised by us. This is a cyclical event, but each subsequent year we prepare a completely new website. Once DrupalCamp has taken place, we leave this page up as a souvenir, archived to HTML at a separate address.

The website of DrupalCamp conference in Wrocław.

What preparations did drupalcamp.pl require? First of all, we removed the subpages with the forms, which were no longer needed, since the conference has already ended. We made sure that all views worked without AJAX on the programme subpages. We also carried out a quick JS audit to eliminate potential code issues when PHP is disabled.

The archiving process

We use the httrack software, which is available under the GNU GPL3 license, in order to automatically archive pages. It is available for Windows, Linux, OSX and Android. We use httrack via a Linux console. There are plenty of switches and options available in the documentation, here is our command to make a 1:1 copy of a website, while maintaining the link structure:

httrack http://example.com -O output_dir --disable-security-limits --max-rate=99999999999 -K3 -X -%P -wqQ%v --robots=0 -N "%h%p/%n.%t"
  • --disable-security-limits - disables the built-in transfer limits, this is useful when our local server is the source.
  • --max-rate - sets the maximum transmission speed.
  • -%P - tries to recognise all possible links to files on the website.
  • -K3 - does not change the links on the pages.
  • -N "%h%p/%n.%t" - does not change file names.
  • -X - on the next command, deletes files from the archived version that were deleted in the original.
  • -wqQ%v - standard mode, silent, with a list of processed files on the screen.

The resulting page image is not yet completely finished. The subpages are in files such as about-us.html, instead of about-us/index.html. A simple script will fix this problem:

#!/bin/bash
for f in $(find output_dir/example.com -name "*.html" -type f); do 
        if [[ $f = *"/index.html" ]]; then
                echo "Omitting $f"              
        else
                echo "Processing $f"
                mkdir "${f%.html}"
                mv $f "${f%.html}/index.html"
        fi
done

The copy created in this way will be indistinguishable from the original to the observer. This is important for the preservation of existing positions in Internet search engines.

Httrack’s compatibility with Drupal

Drupal 8 is not fully compatible with httrack. The main problem is the responsive images presented via the <picture> tag. Proper conversion to HTML requires providing httrack with hints for additional downloads.

The drupalcamp.pl website that we archived is based on Droopler, an in-house, free of charge distribution of Drupal 8. In version 1.3 of Droopler, we have implemented full support for httrack, which helps with identifying and downloading all graphics files used on the website.

How did we “improve” the compatibility with httrack? We used a very simple solution in the form of hooks preparing a list of files to download. Hints for the bot are placed in the <head> section of the page, as subsequent <link> elements:

<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_2000/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=YkFsAytN" rel="droopler:c0527d:img0" />
<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_1200/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=OEsKzsbg" rel="droopler:c0527d:img1" />

These elements are recognised by httrack and downloaded to the copy. Thanks to this, we can maintain full responsiveness of the images. The excess code is usually deleted from the console by means of a regular expression.

Conversion results

The result of conversion to HTML is very satisfactory in our case. We’ve got a folder with files of a total size of about 20 MB. As one would expect, the access time to an HTML file is a few milliseconds, meaning that it is negligible. It remains very low even under heavy loads. So far, this value on the production server has oscillated around 200ms (of course for users who weren’t logged in, with active cache). Under the load, it increased to about 700ms.

We checked the correctness of export using Screaming Frog SEO Spider software. It did not detect 404 errors, which means that the archiving was 100% successful. Also, the browser consoles do not show any JS errors.

It can be expected that in the next few days the DrupalCamp 2018 website will be finally retired and replaced by pure HTML version. In this way, we will avoid the need to update it and, therefore, we won’t incur additional costs. If there is a need to make changes to the content, we will make them on a local version, based on Drupal, and then automatically generate a new HTML page. We encourage you to take advantage of our experience!

Sep 21 2018
Sep 21

What to do with an old, outdated website that you would like to keep online? The perfect solution is to archive it to pure HTML code. We will demonstrate it on the example of a drupalcamp.pl website created in Droopler, based on Drupal 8.

Why archive pages at all?

Sometimes websites have their expiration date. It may result from the life cycle of the technology used to build it or simply because the website was created for an event or some special occasion. When you organise a music festival, for example, the website is no longer up to date and necessary after it ends. When you have long forgotten websites on your server, their code may be so outdated that it will turn into a threat in the future. If, for some reason, you want to keep your websites on the Internet, you have to take into account the cost of their constant maintenance and updating.

What are the costs of an unused website?

The cost of maintenance depends to a large extent on the technology used. Let's focus on Drupal 8 since it is one of the safest CMS available on the market. Updates to D8 are published monthly, and every six months a version containing new functionalities is published. This means you need to install a fresh release of Drupal 12 times a year and test our website to see if it's still working, so you can stay on top of updates. We know from experience that this can be very time-consuming.

On the other hand, if you decide against upgrading, your website is now at risk of being attacked and poses a threat to other websites on your server. Shortcomings in the security department may lead to much higher costs than updating your code on an ongoing basis.

The question arises – how to avoid maintenance costs and keep the website online? A great compromise between sentiment and cost-effectiveness is the conversion to pure HTML code.

What are the advantages and disadvantages of pure HTML?

Deploying websites written in pure HTML is in a sense a return to the roots. In the age of advanced CMSs, hardly anyone remembers that a website can be created without the use of server-side interpreted languages, such as PHP.

Why writing pages using HTML only was forgotten?

  • Due to difficulties in updating their content.
  • Because it is not possible to reuse the code for global elements (such as header, main menu, footer).
  • Due to the static nature of HTML, which makes it difficult to create administrative pages.

So why convert an unused Drupal 8 website to pure HTML?

  • This will result in a rapid increase in the speed of operation of all subpages, including those which have been the slowest so far.
  • It will be very difficult to attack the website if you configure the server properly.
  • Updating the code will become completely unnecessary, the cost of maintenance will be practically zero.

What will be the limitations of a website converted to HTML?

  • Changes to the content will become more time-consuming. The developer will include them in a local copy and then generate the HTML version for publication on the server.
  • Dynamic elements such as forms will stop working.

How to adapt a website for archiving?

Not every website is suitable for archiving right away. First of all, you should make sure that none of the subpages contains any elements requiring PHP scripts to work:

  • Contact forms (they can be replaced with embedded Google Forms).
  • Search engines (they can be replaced with Google search on the website).
  • Views Exposed Filters.
  • AJAX in views.

It is also necessary to disable error messages sent by the server – especially when copying a website from localhost. During archiving you should use settings as similar to production as possible, including CSS/JS aggregation and lack of additional diagnostic information generated by Twig.

At the beginning of the article, we promised to describe the conversion to HTML, based on a real example. Therefore, we are going to present the method of archiving the drupalcamp.pl website, dedicated to the DrupalCamp 2018 conference organised by us. This is a cyclical event, but each subsequent year we prepare a completely new website. Once DrupalCamp has taken place, we leave this page up as a souvenir, archived to HTML at a separate address.

The website of DrupalCamp conference in Wrocław.

What preparations did drupalcamp.pl require? First of all, we removed the subpages with the forms, which were no longer needed, since the conference has already ended. We made sure that all views worked without AJAX on the programme subpages. We also carried out a quick JS audit to eliminate potential code issues when PHP is disabled.

The archiving process

We use the httrack software, which is available under the GNU GPL3 license, in order to automatically archive pages. It is available for Windows, Linux, OSX and Android. We use httrack via a Linux console. There are plenty of switches and options available in the documentation, here is our command to make a 1:1 copy of a website, while maintaining the link structure:

httrack http://example.com -O output_dir --disable-security-limits --max-rate=99999999999 -K3 -X -%P -wqQ%v --robots=0 -N "%h%p/%n.%t"
  • --disable-security-limits - disables the built-in transfer limits, this is useful when our local server is the source.
  • --max-rate - sets the maximum transmission speed.
  • -%P - tries to recognise all possible links to files on the website.
  • -K3 - does not change the links on the pages.
  • -N "%h%p/%n.%t" - does not change file names.
  • -X - on the next command, deletes files from the archived version that were deleted in the original.
  • -wqQ%v - standard mode, silent, with a list of processed files on the screen.

The resulting page image is not yet completely finished. The subpages are in files such as about-us.html, instead of about-us/index.html. A simple script will fix this problem:

#!/bin/bash
for f in $(find output_dir/example.com -name "*.html" -type f); do 
        if [[ $f = *"/index.html" ]]; then
                echo "Omitting $f"              
        else
                echo "Processing $f"
                mkdir "${f%.html}"
                mv $f "${f%.html}/index.html"
        fi
done

The copy created in this way will be indistinguishable from the original to the observer. This is important for the preservation of existing positions in Internet search engines.

Httrack’s compatibility with Drupal

Drupal 8 is not fully compatible with httrack. The main problem is the responsive images presented via the <picture> tag. Proper conversion to HTML requires providing httrack with hints for additional downloads.

The drupalcamp.pl website that we archived is based on Droopler, an in-house, free of charge distribution of Drupal 8. In version 1.3 of Droopler, we have implemented full support for httrack, which helps with identifying and downloading all graphics files used on the website.

How did we “improve” the compatibility with httrack? We used a very simple solution in the form of hooks preparing a list of files to download. Hints for the bot are placed in the <head> section of the page, as subsequent <link> elements:

<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_2000/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=YkFsAytN" rel="droopler:c0527d:img0" />
<link href="https://www.droptica.com/sites/default/files/styles/responsive_image_1200/public/blog/node_52/35080887_779262195604057_3638740630118596608_o.jpg?itok=OEsKzsbg" rel="droopler:c0527d:img1" />

These elements are recognised by httrack and downloaded to the copy. Thanks to this, we can maintain full responsiveness of the images. The excess code is usually deleted from the console by means of a regular expression.

Conversion results

The result of conversion to HTML is very satisfactory in our case. We’ve got a folder with files of a total size of about 20 MB. As one would expect, the access time to an HTML file is a few milliseconds, meaning that it is negligible. It remains very low even under heavy loads. So far, this value on the production server has oscillated around 200ms (of course for users who weren’t logged in, with active cache). Under the load, it increased to about 700ms.

We checked the correctness of export using Screaming Frog SEO Spider software. It did not detect 404 errors, which means that the archiving was 100% successful. Also, the browser consoles do not show any JS errors.

It can be expected that in the next few days the DrupalCamp 2018 website will be finally retired and replaced by pure HTML version. In this way, we will avoid the need to update it and, therefore, we won’t incur additional costs. If there is a need to make changes to the content, we will make them on a local version, based on Drupal, and then automatically generate a new HTML page. We encourage you to take advantage of our experience!

Sep 19 2018
Sep 19

At Droptica we have always wanted to solve the problem of time-consuming creation of Drupal 8-based small pages from scratch. Finally, we have been able to achieve satisfactory results with Droopler. Version 1.3 is even better.

Why did we make Droopler?

We regularly make small pages for our needs (for example for marketing campaigns or events like DrupalCamp Poland) as well as for our clients.

Making a small website from scratch is time-consuming with Drupal 8, especially if you compare it to Drupal 7 or WordPress. It takes a lot of time to create a nice template that will work well on mobile devices, be easy to expand and comfortable to change.

We considered other technologies for small websites, but then we would have to learn all the processes connected with the new technology. And these would all be processes that we already have in place for Drupal 8 – automated testing, automated deployment to the production server, automated security updates and so on. For these reasons, we have decided to adapt Drupal to our needs.

Maximum flexibility

Our goal was to build a system that would allow you to easily add new subpages. Subpages are supposed to look good on your computer, phone and tablet without the need for using CSS. At the same time, the editor needs to be able to create a wide variety of subpages, and not only those containing the title and text.

We have used Paragraphs and prepared ready-made section types (paragraphs), which can be used to create subpages. Each subpage comprises one or more sections. Sections can be arranged in any order and multiple sections can be inserted on one subpage. Immediately after entering the content and graphics, the sections look very pretty. The editor doesn't need to do anything more – nor do they need any developer support when adding new subpages.

Droopler – it really hits the mark!

The editors are amazed! We have already deployed several dozen pages based on Droopler. Every time, the people who enter the content mention the following advantages of Droopler:

  • each subpage looks very nice,
  • high flexibility, there is no limit to subpages or sections within a subpage,
  • no programming work required to make the website look very good,
  • no worries about the correctness of the HTML code – no need to worry whether, for example, an inserted element will display correctly on the subpage,
  • SEO optimisation, often websites that were switched to Droopler from other systems had better positions in Google search results.

Droopler is a flexible system for creating pretty-looking content and at the same time a platform for virtually unlimited development because it is based on Drupal 8.

Drupal 8 also ensures high security. The Drupal Security Team continuously monitors the system code and releases new versions immediately if any bugs are found.

What's new in Droopler 1.3?

Currently, the latest version of Droopler is 1.3. In this version, we have 13 paragraphs for the types of content used to add subpages – 13 different sections available, which you can use to build any number of subpages.

One of the new paragraphs is side embed. This paragraph allows you to embed external content such as a Google map or a YouTube video in a pretty-looking section. It is perfectly suited for use on the contact page. Video embedding can be used on the page listing clips from recent events in the company, among many other examples. This is just one paragraph – but it gives a lot of possibilities.

Droopler sidebar with embedded content in form of google map

Another new addition to the system is a paragraph for creating a photo gallery. You can now easily build multiple galleries within a single page.

Droopler paragraph with gallery

Version 1.3 offers 6 new paragraphs. You can see them all at https://demo.droopler.com

Droopler is also a blog because these days, everyone needs a blog on the company's website

Most traffic to the websites on the Internet is driven by Google search results. And what matters to Google is basically good content and a lot of it. That's why we've added a blog to Droopler.

Droopler blog is also made up of paragraphs. There is fewer of them, but they are enough to create beautifully looking content. Paragraphs make it easy to embed even full-screen photos into your content. Of course, everything looks nice and pretty on mobile devices as well.

A blog with flexible subpages is a set of very convenient tools for every marketing expert. Building different types of websites for different industries and sectors is simple and enjoyable. Examples of industry websites can be found in the demo: https://demo.droopler.com

Plans for future versions

We are going to continue to develop the system. We often use Droopler for our websites, and our customers use Droopler more and more often. It has already been downloaded more than 600 times from https://www.drupal.org/project/droopler!

We have a long list of changes that we want to implement in the system. One of the larger modules will be a module for product presentation. You will be able to add products with photos, descriptions, categories and tags to the system. There will also be a special page listing products with the option of filtering with the use of Faceted API and Search API. This module will be perfect for production companies and distributors. Together with the existing components, it will enable a very nice presentation of the company's offer on the Internet.

How to get started?

Droopler is free and based on Drupal 8. You can download Droopler from www.droopler.com. A full description of the installation can be found on our blog.
We encourage you to download it and see for yourselves. It's really worth it!

Sep 05 2018
Sep 05

At the last DrupalCon in Nashville, you could hear a lot of interesting lectures. I have chosen ten lectures for you, which I consider to be one of the most interesting. You can find the entire playlist of DrupalCon lectures at https://www.youtube.com/playlist?list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m
Below are some of the lectures you cannot miss.

1. Weather.com’s Project Moonracer – Decoupled User Interfaces

This session will show you how the Weather.com team manages content. An interesting lecture for everyone who plans big changes in the content editing interface in their project.

https://www.youtube.com/watch?v=zn04u3mAQ8o&index=16&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

2. Media module in core: Setting up a Drupal 8 media library

Media in the Drupal core. Using media with Drupal has never been easier. After this session, you will know how to use the Media module in Drupal 8 in your projects.

https://www.youtube.com/watch?v=grYtgcZyQBA&index=88&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

3. Creating a modern web application

DrupalCon is not only about Drupal. During this session, you will learn how to create a modern web application using Symfony, Doctrine, ReactJS, Redux, Redux-Saga, Ant Design and DVA.

https://www.youtube.com/watch?v=p30Fbdu7qBE&index=80&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

4. Build banging sites with BPM: Bricks, Paragraphs and Modifiers

An interesting lecture for site builders. In this presentation, you will learn how to create flexible pages using tools such as Bricks, Paragraphs and Modifiers.

https://www.youtube.com/watch?v=p30Fbdu7qBE&index=80&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

5. Everybody Loves Performance: Easy Audits and Low-Hanging Fruit

In this presentation, you will learn about some useful tools for testing your website’s performance and what to look for in particular.

https://www.youtube.com/watch?v=JwtJKWbY9V8&index=57&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

6. How Memory Works in PHP and its Hidden Costs

A session for PHP programmers. In this presentation, you will learn a little about how PHP uses memory when it runs your code.

https://www.youtube.com/watch?v=naZUWzM2Wsw&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m&index=103

7. How Layout Builder will change everything

Layout Builder is another module that will be included in the Drupal core. The module is still included among the “experimental” modules, but it is worth keeping an eye on it now and see its possibilities ahead of time.

https://www.youtube.com/watch?v=xTuOeyx9JLQ&index=125&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

8. Crazy Tricks with Views

Some interesting examples using plug-ins and hooks to create your own filters, manipulate view results, or create facet views that go beyond the ready-made widgets.

https://www.youtube.com/watch?v=X6_FyInRQ-I&index=157&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

9. Drupal 8, where did the code go? From info hook to the plugin

A session for those who program in Drupal 7 and haven’t yet moved to Drupal 8. In this session, you will learn about the differences in creating things such as blocks between Drupal 7 and Drupal 8.

https://www.youtube.com/watch?v=hf3TbM6wuO0&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m&index=11

10. Advanced Configuration Management in Drupal 8

Configuration management in Drupal 8 is now available in Drupal core. A lot of people still use Features in Drupal 8, but from this presentation, you will learn how to manage the configuration for multi-site pages and you will learn about the modules useful for configuration management.

https://www.youtube.com/watch?v=Es_K8tIMKks&index=50&list=PLpeDXSh4nHjRRbzQW5D6PQVFPrTuh5y8m

DrupalCon’s lectures are always at a very high level, which is why it is worth going to the next big conference – DrupalEurope 2018. In Germany, you will be able to listen live to equally interesting lectures on Drupal and more – coming up in September!

Aug 27 2018
Aug 27

DrupalEurope is this year’s largest European conference devoted to Drupal. In previous years, each edition of the conference (formerly known as DrupalCon) was attended by about 2000 participants. We already know the programme of the conference with 162 hours of lectures over the course of three days! I decided to go through the programme and make a list of 13 lectures that I think are worth seeing.

1. Driesnote

On Wednesday, 12th of September at 9:00 a.m. Dries Buytaert will talk about the status of Drupal 8. This is a lecture I always attend at DrupalCon. You can learn interesting things about Drupal usage statistics and the system development plans. It's definitely worth attending if you want to know what will happen with Drupal in the coming months.

2. Using React with Drupal. The Basics.

It is actually more of a workshop, rather than a lecture, but in my opinion it’s simply worth going there. The popularity of modern frameworks such as React, Vue and Angular is increasingly growing. At Droptica, we also work with more and more projects using React. If you don't know the React.js library yet, this workshop is a must-see for you. If you already know React, it’s also worth going - if only to see the approach to the subject of another developer.

The lecture will be conducted by Martin Spencer from 1xINTERNET GmbH https://www.drupaleurope.org/session/using-react-drupal-basics

3. Progressive Web Apps for all Drupal sites

PWA brings the possibilities of native mobile applications to websites. I’ve been watching PWA implementations for several months now and there has been a lot of them, and the future is going to bring even more.
At Droptica, we implemented PWA in the TrainingRealm application. Currently, we are working on connecting Vue Storefront with Drupal Commerce, which also implements PWA.

The lecture will be conducted by Chris Ruppel
 https://www.drupaleurope.org/session/progressive-web-apps-all-drupal-sites

4. How we built a government video platform using Vue.js in just 100 days

I love case study lectures, since they allow me to learn about real issues during project implementations, as well as their solutions. In this case study, you can see a combination of all the new trends in online technologies: Drupal 8, Vue.js and media streaming.

The lecture will be conducted by four developers from Digitalist Group https://www.drupaleurope.org/session/how-we-built-government-video-platform-using-vuejs-just-100-days

5. Introducing the Gutenberg content editor for Drupal 8

Personally, I am a fan of the Paragraphs module, which we use in Droopler – our Drupal distribution for creating small websites and for marketing departments. However, I will be happy to learn more about the Gutenberg editor. If it’s stable, then its implementation in Drupal may be a big change for people who work with content on a daily basis.

The lecture will be conducted by Per Andre Rønsen from Frontkom 
https://www.drupaleurope.org/session/introducing-gutenberg-content-editor-drupal-8

6. Drupal distributions panel

Distributions are close to Droptica’s heart, since we run our own distribution – Droopler. In Drupal 8, building a distribution is not as burdensome as in the case of Drupal 7. I see a great potential in the development of distributions and I’ll be happy to listen to the experiences of other developers of such projects.

The panel discussion will be attended by: Cristina Chumillas (Ymbra), Moritz Arendt (GoalGorilla), Miro Dietiker (MD Systems
Kampaweb), Christoph Breidert (1xINTERNET GmbH), Bojan Zivanovic (Commerce Guys), Mohammed J. Razem (Vardot), Keith Jay (Five Mile), Daniel Bosen (Burda Magazine Holding GmbH), Ted Bowman (Acquia) https://www.drupaleurope.org/session/drupal-distributions-panel

7. Drupal 8 migrations by example

It’s time for yet another workshop on our lecture list! It grabbed my attention from the second I noticed the description: “No PHP coding required.” At Droptica, we migrated many websites to Drupal 8, but in most cases YML files alone were not enough. I’ll happily listen to someone else’s experiences with migration to D8.

The workshop will be conducted by Mauricio Dinarte from Agaric https://www.drupaleurope.org/session/drupal-8-migrations-example

8. Autosave and concurrent editing in Drupal 8

The topic of comfortable content editing in Drupal has been very close to my heart in recent months. We have clients who create large amounts of content in their Drupal systems every day, and every slightest improvement to this process is important to them. The modules presented during this lecture can streamline the process of creating content.

The lecture will be conducted by Hristo Chonov from bio.logis GIM GmbH https://www.drupaleurope.org/session/autosave-and-concurrent-editing-drupal-8

9. Creating an enterprise level editorial experience for Drupal 8 using React

Another lecture devoted to content editing and React that is definitely worth seeing. Convenient editing of content in systems where it is abundant is very important can save a lot of time.

The lecture will be conducted by Ruben Teijeiro from 1xINTERNET https://www.drupaleurope.org/session/creating-enterprise-level-editorial-experience-drupal-8-using-react

10. OpenSource meets Enterprise - how Drupal and SAP Hybris can team up

Drupal 8 and SAP in the same lecture – this has to be interesting. I'm always interested in integrating Drupal with other systems, especially large enterprise systems.

The lecture will be conducted by Jan Pilarzeck from Trio-interactive https://www.drupaleurope.org/session/opensource-meets-enterprise-how-drupal-and-sap-hybris-can-team

11. Successfully Proving Enterprise Drupal 8 at Bayer

Bayer, a large international corporation, needs no introductions. This lecture on using Drupal 8 as a platform for over 2000 websites is definitely worth seeing.

The lecture will be conducted by George Steven from Bayer https://www.drupaleurope.org/session/successfully-proving-enterprise-drupal-8-bayer

12. Open Source E-commerce solutions: Stop to compare, start to analyse

Choosing an e-commerce platform is always a difficult task. Many times, we have implemented online shops based on Drupal Commerce, but I am also aware of the existence of strong competition such as Prestashop, Magento, WooCommerce and Sylius. This lecture will be particularly interesting for everybody working with e-commerce implementations.

The lecture will be conducted by Mathieu Le Cain and Fabien Clément from L'équipe.tech https://www.drupaleurope.org/session/open-source-e-commerce-solutions-stop-compare-start-analyze

13. The king is dead, long live the king - or how Hooks were superseded by object-oriented alternatives in Commerce 2.x.

Well-written and clean code guarantees stable operation of the application and its convenient expansion in the future. This lecture seems to be a must-see for every developer planning to use Drupal Commerce.

The lecture will be conducted by Andreas Albers and Jakub Piasecki (one of the best Polish Drupal developers) from Linkfactory A/S https://www.drupaleurope.org/session/king-dead-long-live-king-or-how-hooks-were-superseded-object-oriented-alternatives-commerce

Summary

The above list is a list of lectures that I definitely want to see (unfortunately, I’ll probably have to watch some of them after the conference due to various meetings during the event). Looking back at the previous DrupalCon conferences, the level of the lectures should be high. The speakers are always well-prepared for their lectures.

If you're still thinking about going to DrupalEurope, I think it's definitely worth buying a ticket. You can gain a ton of knowledge, and the event also gives you an opportunity to talk to people who do what you do every day from all over the world. I always come back from these events with a lot of new ideas, which I systematically implement at Droptica.
 

Jul 18 2018
Jul 18

At Droptica, remote work is something ordinary. From the very first day, we had two offices in Wrocław and Gdańsk. Recently, we also opened our third office in Rzeszów. Every day, developers, testers, graphic designers and other specialists work together in each of these locations. In addition, 90% of our clients come from abroad, like in the case of most software houses. Throughout several years, we have developed methods of effective and efficient cooperation in a dispersed team. We are constantly improving our work model, testing new tools and ways of working. In this article, you will learn how our system works today.

Project management support system

Since the beginning of Droptica’s existence, we have been using Redmine. Redmine had several add-ons, including Backlogs module supporting work in the Scrum model. These days, we are using Jira, since it works even better with Scrum. Both systems help us to control what is going on with the projects. Each of the projects is divided into sprints, and each sprint is divided further into specific tasks. All information about the realisation of every task is saved and stored in Jira. Our clients also have access to our Jira for full transparency. In our opinion, such a system is a necessity. Without it, it would be difficult, if not impossible, to control what is going on with the project, especially in the case of projects running for many months. E-mail communication is completely unsuitable for this purpose.

Two communication speeds

Project management support systems are very useful, but not sufficient for efficient implementation of the project. Members of the team must be able to communicate comfortably and quickly. If the team works in one office, it is enough to just talk to somebody and ask. In the case of a dispersed team, this issue becomes quite complex. Writing an e-mail or adding a ticket in Jira to ask a quick question takes time. Most often, you have to do the following:

  • open Jira;
  • find a project;
  • find the right task;
  • add a comment;
  • check in a while if there is an answer;

This process often takes far more time than simply asking the question and getting an answer, especially when it’s a “yes/no” type of question.  

At Droptica, we solve this problem by communicating using Slack. Thanks to this application, our distributed team works as if all the members were located in one office. We communicate quickly and efficiently. We eliminate unnecessary e-mails, phone calls and video conferences. The number of comments to tasks in Jira also goes way down – this is helpful because they often make it difficult to analyse the status of work on a given task. 

Slack at Droptica

We set up several channels for each project. Channels are used to eliminate as many notifications and as much communication via e-mails as possible and to split up messages thematically.

Most often, we set up the following chat channels:

  • projectname chat – a channel for internal communication regarding the project. This channel is used by the entire development team, as well as project support team (DevOps, testers, etc.);
  • projectname client - a channel available to the client and the development team. This channel is a place for communicating with the client, asking quick questions about tasks, setting up meeting dates, calls, etc;
  • channels with notifications from the systems used in connection with a given project, such as Jira, Jenkins, GitHub, Bitbucket, etc. Usually, each system gets its own channel. Every person can join channels that are important for them and eliminate notifications that are not important or redundant, for example, a graphic designer does not need to read GitHub notifications.

Before Slack, we used group chats on Skype, then we moved on to HipChat for a while. We found Slack to be the best solution that fits our needs perfectly and we do not plan to move to any other solution any time soon. It is also important that our clients often already use Slack, which makes it easy for them to join our channels as another organisation.

Other tools supporting remote working

Daily Scrum

There is no Scrum without Daily Scrum. In a dispersed team, it is necessary to conduct a video conference once a day. Sometimes such calls are also attended by the representative of the client, who is often hundreds or thousands of miles away from our offices. We conduct these meetings using several tools, depending on the preferences of the team or our client. Usually, we go for Google Hangouts Meet, but sometimes we resort to Zoom.us and Skype For Business.

Scrum Retrospective

For this purpose, we use a simple Google Docs sheet. We have a sheet with the following columns:

  • drop - what we should stop doing if it's possible;
  • keep - what is good and what we should keep doing;
  • improve - what needs to be improved;
  • add - what we need to add in order to better carry out the work on the project.

The worksheet contains a history of all retrospectives in the form that is easy to view and edit. The document is available to all team members, regardless of their location. This is working very well for us.

Code review

We review the code on GitHub or Bitbucket, depending on the project. These systems allow to easily browse the code and add comments to selected script lines. There is no need for one person to come to the other person's desk to view the quality of the code.

We also have several internal tools and scripts for automating tests that support Drupal development.

Good remote working practices

In my opinion, it is not possible to rely only on communication via e-mail or Jira. Video conferences and telephone calls are necessary to better understand each other. This greatly improves communication within the development team and between the client and the team. One could say that working according to the Scrum methodology forces us to do so. Every day, we carry out Daily Scrum in the form of a video chat. We also often have video calls with customers, for example during the Sprint Review or during the Backlog Refinement. Every once in a while, we also meet with the client at our office or we pay them a visit.

It is also important for the communication process to work in a way that does not disturb others too often. Slack is a very useful tool, but it can also lead to too many unnecessary messages, which can be distracting and interrupt work. The team should be aware of this and use Slack only when necessary and send messages only to those who need them. We try to never involve people whose presence is not necessary in a given case.

Is remote working better than working in one office?

Having the entire team working in one office certainly makes communication much easier. However, it also has its drawbacks – for example, it makes it much easier to disturb somebody while working with unnecessary discussions. Sometimes this can reduce productivity.

At Droptica we combine remote work with office work, which enables us to take advantage of both models. If necessary, we build teams working at just one office.
More than one location gives us a competitive advantage because we have access to more specialists from three cities and their general areas. This allows us to build great development teams for our clients.

The fact that Droptica has multiple offices also forces all of our team members to learn how to work remotely. That’s why all of our experts know how to work with a remote client right away.

Summary

At Droptica, we developed a remote working system that works very well for us. I think that such a model is by no means worse than working in one office, additionally, it also offers many benefits. If you are looking for a team of Drupal, PHP, Symfony or ReactJS experts, we will be happy to assist you and show you that communication with a remote team can also be great.

Jul 18 2018
Jul 18

At Droptica, remote work is something ordinary. From the very first day, we had two offices in Wrocław and Gdańsk. Recently, we also opened our third office in Rzeszów. Every day, developers, testers, graphic designers and other specialists work together in each of these locations. In addition, 90% of our clients come from abroad, like in the case of most software houses. Throughout several years, we have developed methods of effective and efficient cooperation in a dispersed team. We are constantly improving our work model, testing new tools and ways of working. In this article, you will learn how our system works today.

Project management support system

Since the beginning of Droptica’s existence, we have been using Redmine. Redmine had several add-ons, including Backlogs module supporting work in the Scrum model. These days, we are using Jira, since it works even better with Scrum. Both systems help us to control what is going on with the projects. Each of the projects is divided into sprints, and each sprint is divided further into specific tasks. All information about the realisation of every task is saved and stored in Jira. Our clients also have access to our Jira for full transparency. In our opinion, such a system is a necessity. Without it, it would be difficult, if not impossible, to control what is going on with the project, especially in the case of projects running for many months. E-mail communication is completely unsuitable for this purpose.

Two communication speeds

Project management support systems are very useful, but not sufficient for efficient implementation of the project. Members of the team must be able to communicate comfortably and quickly. If the team works in one office, it is enough to just talk to somebody and ask. In the case of a dispersed team, this issue becomes quite complex. Writing an e-mail or adding a ticket in Jira to ask a quick question takes time. Most often, you have to do the following:

  • open Jira;
  • find a project;
  • find the right task;
  • add a comment;
  • check in a while if there is an answer;

This process often takes far more time than simply asking the question and getting an answer, especially when it’s a “yes/no” type of question.  

At Droptica, we solve this problem by communicating using Slack. Thanks to this application, our distributed team works as if all the members were located in one office. We communicate quickly and efficiently. We eliminate unnecessary e-mails, phone calls and video conferences. The number of comments to tasks in Jira also goes way down – this is helpful because they often make it difficult to analyse the status of work on a given task. 

Slack at Droptica

We set up several channels for each project. Channels are used to eliminate as many notifications and as much communication via e-mails as possible and to split up messages thematically.

Most often, we set up the following chat channels:

  • projectname chat – a channel for internal communication regarding the project. This channel is used by the entire development team, as well as project support team (DevOps, testers, etc.);
  • projectname client - a channel available to the client and the development team. This channel is a place for communicating with the client, asking quick questions about tasks, setting up meeting dates, calls, etc;
  • channels with notifications from the systems used in connection with a given project, such as Jira, Jenkins, GitHub, Bitbucket, etc. Usually, each system gets its own channel. Every person can join channels that are important for them and eliminate notifications that are not important or redundant, for example, a graphic designer does not need to read GitHub notifications.

Before Slack, we used group chats on Skype, then we moved on to HipChat for a while. We found Slack to be the best solution that fits our needs perfectly and we do not plan to move to any other solution any time soon. It is also important that our clients often already use Slack, which makes it easy for them to join our channels as another organisation.

Other tools supporting remote working

Daily Scrum

There is no Scrum without Daily Scrum. In a dispersed team, it is necessary to conduct a video conference once a day. Sometimes such calls are also attended by the representative of the client, who is often hundreds or thousands of miles away from our offices. We conduct these meetings using several tools, depending on the preferences of the team or our client. Usually, we go for Google Hangouts Meet, but sometimes we resort to Zoom.us and Skype For Business.

Scrum Retrospective

For this purpose, we use a simple Google Docs sheet. We have a sheet with the following columns:

  • drop - what we should stop doing if it's possible;
  • keep - what is good and what we should keep doing;
  • improve - what needs to be improved;
  • add - what we need to add in order to better carry out the work on the project.

The worksheet contains a history of all retrospectives in the form that is easy to view and edit. The document is available to all team members, regardless of their location. This is working very well for us.

Code review

We review the code on GitHub or Bitbucket, depending on the project. These systems allow to easily browse the code and add comments to selected script lines. There is no need for one person to come to the other person's desk to view the quality of the code.

We also have several internal tools and scripts for automating tests that support Drupal development.

Good remote working practices

In my opinion, it is not possible to rely only on communication via e-mail or Jira. Video conferences and telephone calls are necessary to better understand each other. This greatly improves communication within the development team and between the client and the team. One could say that working according to the Scrum methodology forces us to do so. Every day, we carry out Daily Scrum in the form of a video chat. We also often have video calls with customers, for example during the Sprint Review or during the Backlog Refinement. Every once in a while, we also meet with the client at our office or we pay them a visit.

It is also important for the communication process to work in a way that does not disturb others too often. Slack is a very useful tool, but it can also lead to too many unnecessary messages, which can be distracting and interrupt work. The team should be aware of this and use Slack only when necessary and send messages only to those who need them. We try to never involve people whose presence is not necessary in a given case.

Is remote working better than working in one office?

Having the entire team working in one office certainly makes communication much easier. However, it also has its drawbacks – for example, it makes it much easier to disturb somebody while working with unnecessary discussions. Sometimes this can reduce productivity.

At Droptica we combine remote work with office work, which enables us to take advantage of both models. If necessary, we build teams working at just one office.
More than one location gives us a competitive advantage because we have access to more specialists from three cities and their general areas. This allows us to build great development teams for our clients.

The fact that Droptica has multiple offices also forces all of our team members to learn how to work remotely. That’s why all of our experts know how to work with a remote client right away.

Summary

At Droptica, we developed a remote working system that works very well for us. I think that such a model is by no means worse than working in one office, additionally, it also offers many benefits. If you are looking for a team of Drupal, PHP, Symfony or ReactJS experts, we will be happy to assist you and show you that communication with a remote team can also be great.

Jul 18 2018
Jul 18

Droptica helps clients from all over the world to complete and implement their projects. Each of these clients has already developed their way of working. Everyone is different. In this article, I have collected the most common ways and systems of cooperation between Droptica and our clients.

Why do we work a little differently with every client?

We are Agile. We always want to maximise the results of our work, so our development team always adjusts and adapts their way of working to the client’s needs.
The elements that are adapted and changed the most often include:

  • project implementation methods (SCRUM, Kanban, etc.);
  • number of people in the team;
  • roles in the team (backend developers, frontend developers, QA, UX/UI, etc.);
  • the method of communication; Tools: JIRA, Slack, telephone or video calls, meetings;
  • frequency of communications;
  • communication channels (who, with whom);
  • implementation standards (some clients consider application performance to be the most important, others focus on implementing and providing new functionalities on a regular basis, while another group focuses on aesthetics and want their application to look good).

On the basis of these factors, I have identified several models of cooperation with clients, which are used the most often at Droptica.

Model 1: Product Owner at the client, with the rest of the team at Droptica

This is probably the most popular model employed at Droptica. We use it mainly when the end client comes to us. In most cases, the client already has a web system based on Drupal, Symfony or React and needs developers to develop the system further. Product Owner has a vision of application development and looks for a team that can efficiently perform the envisioned tasks.

In this model, we have a great impact on the development of the system. Our team not only performs assigned programming tasks but also proposes directions of development of the system and suggests improvements. In addition to developing basic functionalities, we also design user interfaces (UX/UI) and often carry out A/B tests that show us the best solutions for the client.

We use this model to develop WydawnictwoWAM.pl website. This is what the client has to say about us and about working in this model: 

"We established cooperation with Droptica around two years ago to develop our online store available at http://www.wydawnictwowam.pl. Both the quality of all the works carried out, as well as our cooperation were stellar. The technical solutions suggested and implemented by Droptica were a great help and often improved the value of our system, often exceeding our initial expectations. Cooperation with Droptica is characterised by very friendly, direct and precise communication on their part. Thanks to that, we were – and constantly are – able to define and detail all the tasks related to the development of our sales platform. We also appreciate their very clear settlement system, which allows us to better plan and allocate funds for development. In other words, we definitely recommend working with Droptica".

Model 2: Product Owner, QA, PM on the client’s side, software developers provided by Droptica

In this model, we provide our customers with solid development support. Most of the project planning and management process is carried out by the client, while our experts carry out specific development tasks.
It is a kind of cooperation that we usually go for with large companies and corporations, expanding their Drupal, PHP and ReactJS teams.
As a rule, in such a model we work on servers and project management systems provided by the client. We adapt to their processes.

Mixed models

Other models are usually combinations of the two models presented above. For example, Droptica provides not only developers but also testers, while the entire project is managed by the client. We also sometimes work on projects where we collaborate with other software developers from the client's company, working not as an independent development team, but a part of a larger team.

We are Agile

We are flexible regarding the form of cooperation with our clients; however, we like the first model the most. In that model, we take on a great deal of responsibility for the project and we are able to influence the direction of development together with the client. This gives us great satisfaction, and we offer numerous ideas for improving the system, which allows our clients to better achieve their business goals.

Would you like to learn more about our work models? Contact us at [email protected] and we'll be happy to talk to you.
 

 

Jul 10 2018
Jul 10
Drupal is fantastic for all sorts of websites and applications. It excels especially at large, complex content projects. If you know what you are doing, you can often cut development time substantially compared to other tools made for the same purpose.  Drupal's versatility, however, is a 2-edged sword. With great flexibility, extensive API and an abundance of modules created by the community, it takes a long time to get up to speed. Often there is not enough time on a project to go through Drupal's steep learning curve.  The more experienced your team is, the more benefits of Drupal you will reap and the less technical debt you will acquire, and the more successful your project will be in the end. Looking for a Drupal team There are a few critical elements you should consider when you are looking for to outsource a Drupal project:

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web