Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jun 30 2021
Jun 30

Infinite scrolling is a technique used to show more content as the user scrolls down a page eliminating the need for the user to click to go to the next page. This is commonly implemented in popular social media apps.

This tutorial will demonstrate how to use the Views Infinite Scroll module to achieve this and also show options that can be used to customize the user interaction with the infinite scrolling behavior.

We will show you how to:

  • Install the module
  • Set up a simple view
  • Add the infinite scroll behavior
  • Customize the infinite scrolling behavior.

Drupal Views Series

Table of Contents

Getting Started

We can easily install Views Infinite Scroll using Composer:

composer require drupal/views_infinite_scroll

To enable you can use Drush:

drush en views_infinite_scroll -y

Step 1: Set up your View

For the purposes of this tutorial, we are assuming you already have a content type set up and have already generated enough content for it.

We are going to create a simple View that lists Articles (Title and Body fields).

Go to Structure -> Views -> Add view

Here is a screenshot of our simple View. There is nothing fancy. We are only listing published Articles and have created a Page display for it.

If you’re new to Views then check out our “Getting Started with Views” tutorial.

Step 2: Adding the Pager

In the Pager settings of your View, change the type to “Infinite Scroll” (leaving all the settings as default for now).

Also, in the Advanced section of your View, set “Use AJAX” to “yes”.

Here is how our View settings looks now:

Save your View and go to the URL of the View page to test out your Infinite Scroll. You should now see a “Load More” button in the pager section of your View page that looks like this:

And that’s it! You now have infinite scrolling for your View. However, there are more options that can be configured for your Infinite Scroll. These are all optional as we shall demonstrate them now.

Step 3 (Optional): Replace the button text

You can add tokens to your Infinite Scroll button to enhance the user’s experience.

In the pager section of your Views configuration page, open the settings of your Infinite Scroll pager as shown in the screenshot below:

Set the button text to “Load @next_page_count more (Total @total)” as shown in the screenshot below:

Now your Views Infinite Scroll Pager button text will look like this:

@next_page_count” and “@total” are called “tokens” in Drupal. The tokens are replaced with actual data automatically.

View Infinite Scroll supports the following tokens:

  • @next_page_count
  • @remaining_items_count
  • @total

Step 4 (Optional): Automatically Load Content

Currently, users would have to click on the “Load More” button to get the next set of content. The Views Infinite Scroll page has an option to automatically load content (without the need to click on the button).

Go to the settings of your Views Infinite Scroll pager and check the box “Automatically Load Content” and click on Apply.

Save your View and then test it. As you scroll to the bottom of your View, another set of content should automatically be loaded.

Warning: Enabling this setting means that the user never actually gets to the footer of your page until they have exhausted loading all of your content. For example, if you had 1000 articles, it would take a very long time to see the footer. This means that if you had important links in your Footer (like Privacy policy links etc), it’s almost unreachable.

Step 5 (Optional): Exposing Options to the User

Views Infinite Scroll allows you to expose settings to allow the user to control selected displays options. We will demonstrate by doing an example. In the Settings of your Views Infinite Scroll Pager, scroll to the “Expose Options” and check “Allow user to control the number of items displayed in this view”, then click on Apply and save your View.

This results in the following being added to the top of your View page:

This specific option will allow the user to select how many results are returned everytime they click on the “Load More” button.

Summary

Views Infinite Scroll is a neat module that allows you to add infinite scrolling behavior to your View. We have shown how you can use this module to achieve this infinite scrolling behavior and also demonstrated a few of its customizations along with one of it’s biggest pitfalls.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Jun 23 2021
Jun 23
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

In Drupal, content is stored in the database. Views is a query builder that allows the user to extract content from the database and output it in various displays such as tables and lists. With Views, the user does not have to know or write any SQL queries. If you want to create a page or block in Drupal that lists any kind of content based on different filter criteria, you should use Views!

In this tutorial, we will explain what Drupal Views are and how to create it. We will also demonstrate some simple customizations such as page settings, filters, sorting, display options, exposed filters, permissions, creating a View Block and creating an admin page using Views. By the end of this tutorial, you will know how to create and customize a Drupal View.

Drupal Views Series

Table of Contents

Getting Started

As of Drupal 8, Views already comes packaged with Drupal core so there is no need to download anything. If you installed Drupal using the standard installation profile then it’ll be already installed.

Go to Extend and make sure Views and Views UI are installed.

How to Create a View

In this section, we will walk you through the process of creating a very simple View that lists  published Articles using the teaser view mode.

First, ensure you have enough article content on your website and ensure you are logged in as the administrator. Now let’s create the View.

1. Go to Structure -> Views (admin/structure/views) and click on “Add view”.

2. On the “Add view” page, fill out the fields as suggested in the screenshot below. All we are doing here is giving the view a name, selecting “Article” in View Settings and ticking the box “Create a page”. Every other field can be left as the default for now. Click on “Save and edit” when you are finished.

Views Creation Screen – Figure 1

And that’s it! You have successfully created your View. If you were to go to “/latest-articles” you can see the output of your View.

We will now explain the major parts of the Views configuration screen. We have highlighted different sections of the Views configuration screen in the screenshot below and labelled each section with a number for easier reference and explanation.

Views Config Screen – Figure 2

Label 1 – As the name suggests, this is the title of the View. This is the text that will appear as the title of the /latest-articles page.

Label 2 – This determines the output style of the view. Frontend themers can use this to style the output by overriding the default templates provided by Views. There are also contributed modules that can extend and provide more options such as Views Slideshow.

Label 3 – This determines how each row result of the View should be displayed. Currently it’s set to “Content” which allows us to choose different view modes like Teaser or Full Content. If you want to show just specific fields of your Articles, you can change it from “Content” to “Fields”. Then, you can select the fields you want to display in Views Config Screen Label 4.

Label 4 – Based on which Format style you choose above, this section will allow you to choose the specific fields to display.

Label 5 – This section allows you to define criteria for filtering your View results. Currently we are only showing published articles.

Label 6 – As the name suggests, we can define how to sort the View results. You can also sort on your content type fields by adding them here.

Label 7 – This is the path for your View page.

Label 8 – If you want to add your View page to any of your Drupal menus, this is where you can do it.

Label 9 – In this section you can define specific permissions for who is allowed to access your View.

Customizing your View

Let’s say we want to customize our current View to display a table layout with just Title and Body fields of the Article content type. But we also wanted to allow the user to input a text string that will filter the results against the Title. We will refer to the labelling in Figure 2 to help with our explanation.

1. Update the Format (Views Config Screen Label 2). Set it to Table. You can leave the default Table settings.

2. In doing Step 1, you may notice that Views automatically added the Title field in the Fields section (Label 4). Let’s add the Body field as well.

Click on “Add” in the Field section:

In the “Add fields” popup, search for “body” and click on “Add and configure fields”.

On the “Configure field: Content Body”, you can leave all the defaults and just click on Apply.

3. Now let’s demonstrate how to allow the user to enter text into a field that will automatically search against the Title field. In Drupal Views, this is called an “exposed filter”.

To create this exposed filter, click on “Add” in the Filter Criteria section (Label 5).

Then search for Title in the next screen and click on “Add and configure filter criteria”.

On the next screen, check the box “Expose this filter to visitors, to allow them to change it”. More options will automatically become available. Make sure to set the Operator to “Contains” and then click on “Apply”.

Tip: “Contains” means Views will use the string entered by the user and execute a SQL search in the database for any string that contains the characters entered in that order, i.e., “...LIKE %usertext%...” in SQL.

4. Now that we have set the Table Format, Title/Body fields and exposed filters, it’s time to save the View. This step can be easy to miss so don’t forget it!

Now if you view the actual View page, the View output should look like this:

Create Block using Views

A View Block is just a regular Drupal block except it originates from Views.

For demonstration purposes, let’s say we wanted to create a block version of the View page we created above.

There are two ways to do this. You can either click on “+Add” or click on “Duplicate as Block”. Both options are shown below:

Once you have done that you will notice you will now have “Block Settings” instead of “Page Settings”. This makes sense since now we are dealing with a Drupal Block.

Go ahead and save your View. Once the View is saved, a Drupal block is automatically generated and will be listed alongside all the other Drupal blocks.

Place the block anywhere in your Drupal site as you normally would place any Drupal block into a region. Here is a quick video of how to place a Drupal block into a region. We placed ours in the left sidebar and it looks like this:

You will notice our exposed filter is not being displayed in our Block. There is one extra step involved if you want to get exposed filters to work in View blocks. On the View configuration screen, inside of Advanced, set “Use AJAX” to yes and save your View. Here is how that looks:

Now our Views Block has the exposed filter which looks like this:

Create Admin Page using Views

Let’s say we wanted to use the View page we created above but place it within the admin UI and only accessible to a person with elevated permissions (in other words, not anonymous users). This is a screenshot of the end result we are trying to achieve:

There are a few things we need to edit in our existing View to achieve this. All of the changes we have to make will be in the Page Settings of our View config screen (See Figure 2). We need to update three things:

  1. Label 7 – Update the Path
  2. Label 8 – Update the Menu
  3. Label 9 – Update the Access Permission

1. Updating the Path: In the Views config screen, update the Path to “admin/content/latest-articles”.

2. Update the Menu: In the Views config screen, update the Menu. Clicking on “No menu” will take you to the Menu item entry config screen. On this screen, choose Menu Tab for Type, enter a Menu link title and set the Parent to “” and then click on Apply.

3. Update the Access: We can do this either by defining the Permission or by defining the role. For this tutorial, we will define the permission. In the Views config screen, click on “View published content” and change it to “Access the content overview page”.

4. Save your View!

Now if you go to “admin/content/latest-articles” as a logged in user, you should see your View page. If you tried going to this same page as an anonymous user you should get Access Denied.

Summary

In this tutorial, we introduced you to Views and some of its potential capabilities by providing some simple customizations. We specifically concentrated on demonstrating how to create a View Page and a View Block which list published Articles and also included a View exposed filter which allows the user to enter a text string to search against the Title. We also touched on how you can create an admin page using Views by updating its path, menu and permissions.

Views, which is in Drupal core as of version 8, is a very powerful tool and can be highly configured and customized. We hope we helped in getting you introduced to Views and the potential it has.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Jun 15 2021
Jun 15
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

When someone tweets a link from your website, Twitter can use Twitter Cards to attach rich photos, videos and media to Tweets.

By doing some minimal configuration changes on your Drupal site using the Metatag Module and the Twitter Cards submodule, users can see a “Card” added below the tweet that contains neatly formatted information coming from your website, as shown in Image 1 below.

Image 1 shows an example of a “Card”.

The cards are generated using HTML markup in the HEAD region of your Drupal site; that’s why the Metatag module is used.

Twitter will scrape your site and generate the card using the HTML meta tags.

Table of Contents

Twitter Cards

There are four variations of Twitter cards. They are:

  1. Summary Card – Displays Title, description, and thumbnail
  2. Summary Card with Large Image – As the name suggests, similar to Summary Card but with a larger image
  3. App Card – A Card with a direct download to a mobile app. Use this Card to drive app downloads
  4. Player Card – Displays video/audio/media.

Image 1 above shows a “Card” of type Summary with Large Image.

In this tutorial, we will look at the steps involved in setting up the “Summary Card with Large Image” Twitter Card.

Getting Started

The Metatag module has a dependency on the Token module. However, if you download and enable the Drupal module using Composer and Drush, the dependency is automatically taken care of as we will show you now.

Use composer to download the module:

composer require drupal/metatag

Once the Metatag module is downloaded using composer, the Token module, which is a dependency, will be downloaded automatically.

Then enable the “Metatag: Twitter Card” submodule:

drush en metatag_twitter_cards -y

The above Drush command will automatically enable the Metatag: Twitter Card submodule, Metatag module and Token module.

Finally, it is always a good idea to clear the cache after enabling Drupal modules:

drush cr

Configure Twitter Cards

By default, Twitter Cards can be added to any content type. We will now configure the Twitter Cards for the Article Content type.

1. Go to Configuration > Metatag (admin/config/search/metatag) and click on “Add default meta tags”.

2. On the next page, select “Article” (or whatever content type you want to configure) from the Type dropdown.

3. Then click on Save. This is required for the correct tokens to appear in the “Browse available tokens” window.

4. Edit the “Content: Article” configuration from the Metatag page.

5. Click on “Twitter cards” to expand the field set and then select “Summary Card with large image” from the Twitter card type dropdown.

6. Now, we have to add tokens into the correct fields. Click “Browse available tokens.” then click on Nodes.

NOTE: If you can’t see “Nodes”, this means you need to save the “default meta tag” option first then edit it again.

Fill in the following fields:

  • Description: [node:summary]
  • Site’s Twitter account: Add your twitter account, i.e., @webwashnet
  • Title: [node:title]
  • Page URL: [node:url]
  • Image URL: [node:field_image] (adjust the field name accordingly)
  • Image alternative text: [node:field_image:alt] (adjust the field name accordingly)

Find Image Field Token

For this type of Twitter card, an image field must exist in your content type. We will show you how to use Token to grab that image data. Click on “Browse available tokens”.

Then drill down by going to Nodes -> Image. This assumes you’re using the Image (field_image) field on the Article content type.

The token should be [node:field_image].

Once you have found the image entity URL, make sure your mouse focus is in the empty Image URL Twitter Card meta tag field, and then click on the image entity URL token value. This will copy/paste the token value into the Image URL field.

Find Image Field Token on Media Asset

If you’re using a media field instead of an image field for handling assets, then use the following token, [node:field_media:entity:thumbnail] (change the field_media name accordingly).

7. Configure any extra fields as needed, then scroll down and click on Save.

8. Once you have filled out the other Twitter Card fields with their respective token values, you should validate the end result markup using the Twitter Card Validator tool. We will now show you how to validate your Twitter card.

As you can see, Twitter successfully recognised our “Summary with large image” card and displayed the information correctly.

NOTE: You’ll need to make sure your website is publicly accessible for the validator tool to work.

View HTML Source

If you want to see the generated markup, view the HTML source on your Drupal site and look for the “twitter:*” meta tags.

Summary

Twitter can display a neatly formatted version of your website’s content whenever someone’s tweets a link to your content. There are various types of Twitter cards depending on your needs.

We have shown how you can use the Metatag module and Twitter Cards submodule to configure Drupal 8 to correctly send your website’s content to Twitter and how to validate your markup to ensure Twitter correctly parses your website content.

FAQ

Q: I changed the default meta tag configuration, but the tags are not changing?

Try clearing the site cache. Go to Configuration > Performance and click on “Clear all caches”.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

May 31 2021
May 31
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

Drupal comes with a toolbar which is useful when administering a Drupal site. If you log in and have the correct permissions, you’ll see a toolbar across the top of the page that allows you to access back-end configuration pages.

The Admin Toolbar module extends the functionality of the toolbar and gives you lots of extra features such as drop-down menus, access to cache and cron settings and an autocomplete search.

In this tutorial, you will learn how to install and configure Admin Toolbar and its sub-modules.

Table of Contents

Getting Started

Let’s begin by downloading the Admin Toolbar module.

Run the following Composer command:

composer require drupal/admin_toolbar

Then go to Extend and install Admin Toolbar and its three sub-modules.

Functionality around the toolbar is spread across four modules in total. Here’s a breakdown of what each module does.

Admin Toolbar

Provides an improved drop-down menu interface to the site toolbar.

Admin Toolbar Extra Tools

Adds menu links like Flush cache, Run Cron, Run updates, and Logout under the Drupal icon

Admin Toolbar Links Access Filter

Provides a workaround for the common problem that users with ‘Use the administration pages and help’ permission see menu links they don’t have access permission for. Once the issue https://www.drupal.org/node/296693 be solved, this module will be deprecated.

Admin Toolbar Search

Provides quick search functionality for configuration pages.

Let’s take a look at each module in more detail.

This module is the base module of Admin Toolbar. After installation, it provides drop-down functionality on top of the standard toolbar.

There is a new version 3.0.0 released recently, which requires Drupal 8.8 or above. With this version, a new configuration form was introduced to limit the number of bundles to display in the drop-down menu, resulting in performance issues.

To configure this new mechanism, go to:

Admin > Configuration > User interface > Admin Toolbar Tools

The default value is 20, but can be modified here. Just pay attention to the warning on this page which says ‘Loading a large number of items can cause performance issues.’. We can leave it 20 by default to start with.

This sub-module adds extra drop-down functionality to the base module by providing the following additional functions:

  • Additional menu items are available in the drop-down functionality
  • An extra Drupal logo icon will be attached to the left corner of the Admin Toolbar, which provides additional functions in a convenient manner:
  • Index – provides a list of functions indexed in alphabetical order
  • Flush all caches – flush all caches, or individual caches of the system.
  • Run cron – run a cron job immediately, instead of waiting for the default time period of 3 hours.
  • Run update – run a system update process, generally after system or module updates.
  • Logout – provide fast access to the logout function.

This sub-module offers a workaround for users which have the ‘Use the administration pages and help’ permission but not access to the specific pages. Menu items are still visible even if the user doesn’t have access.

Once https://www.drupal.org/node/296693 is fixed this module will be deprecated.

This sub-module doesn’t require any configuration, just install and you’re done.

An ‘Admin toolbar quick search’ box is provided on the Admin Toolbar. This is useful for beginners, site builders or administrators who are not familiar with Drupal. They can find the functions they are looking for, administrative or configuration pages by searching here.

Summary

Admin Toolbar is a must-have module on any Drupal site. It gives site administrators and builders a better user experience when managing content and configuration.

I especially like the quick search functionality offered by “Admin Toolbar Search”. This makes it easy to search for configuration pages.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

May 18 2021
May 18
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

Creating a block using views is pretty straightforward. You could create a block to display a list of published articles or ones that have been promoted to the front page. Then you can add that block into any theme region.

But you may encounter a situation where you no longer have any articles which are published and then you end up with an empty block.

Views comes with a feature that allows you to hide a block if no results are returned and this is what will be covered in this tutorial.

Table of Contents

Getting Started with a Simple Example

We need to display a block that lists all articles that have been promoted to the front page. This can easily be achieved by using a custom views block

The views configuration will look something similar to the following:

This is a block created from views, and we can place the block on the sidebar, like the following:

The criteria of the views setting is based on some articles having the ‘Promoted to front page’ option checked.

The Problem

However, sometimes articles may not be promoted at all.  As a result, there are no results returned from the views setup above, and the block will look like this:

How to Fix It

To avoid this situation, we can choose to Hide the Block when no results are returned.  In fact, there is an option of ‘Hide block if the view output is empty’ at the bottom corner of the views setting, which a lot of people might easily overlook.

Simply enable this option, and it is done.

With this option enabled, the block will disappear when the view returns no results, like the image below:

Summary

This ‘Hide block if the view output is empty’ option is actually one which is very useful, but it can be easily overlooked.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

May 12 2021
May 12
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

When someone shares a Facebook post with a link to your website, Facebook lets you control how your website content appears to others by parsing your Open Graph (OG) markup.

By doing some minimal configuration changes on your Drupal site using the Metatag Module and the Metatag: Open Graph sub module, you can define what specific content can be shown on Facebook regardless of whether it’s shared from the desktop or mobile web or a mobile app.

It is easier to explain by showing the end result of what we are trying to accomplish. For example, the homepage of www.webwash.net has the following OG markup inside of the :

If someone posted www.webwash.net to Facebook, then Facebook would parse the OG markup like this:

And the end result would look like this:

You can clearly see the corresponding OG tags for the content.

If you want to learn more about the OG tags. Click here for a detailed list and explanations of the Facebook OG tags.

In this tutorial, we are going to show you how to configure a content type to dynamically populate the Facebook OG tags using the Metagtag module and Metatag Open Graph sub module.

Table of Contents

Getting Started

The Metatag module has a dependency on the Token module. However, if you download and enable the Drupal module using composer and drush, the dependency is automatically taken care of as we will show you now.

Use Composer to download the module:

composer require drupal/metatag

Once the Metatag module is downloaded using composer, the Token module, which is a dependency, will be downloaded automatically.

Then enable the “Metatag: Open Graph” sub module:

drush en metatag_open_graph -y

The above drush command will automatically enable the Metatag: Open Graph sub module, Metatag module and Token module.

Finally, it is always a good idea to clear the cache after enabling Drupal modules:

drush cr

By default, Open Graph can be added to any content type. We will now configure Open Graph for the Article Content type.

1. Go to Configuration > Search and meta data > Metatag and click on “Add default meta tags”.

2. On the next page, select “Article” (or whatever content type you want to configure)  from the Type dropdown.

3. Then click on Save. This is required for the correct tokens to appear in the “Browse available tokens” window.

4. Edit the “Content: Article” configuration from the Metatag page.

5. Then in the Open Graph fieldset on the same page, click to expand it. You will now notice quite an exhaustive list of OG tags that you can populate. Firstly, we are going to demonstrate how to populate the Image OG tag.

For this to be successful, your Article content must have at least an image field. We will show you how to use Token to grab that image data.

Click on “Browse available tokens”.

From the Token window click on Nodes to drill down and find the content type fields.

NOTE: If you can’t see “Nodes”, this means you need to save the “default meta tag” option first then edit it again.

Fill in the following fields:

  • Content type: article
  • Page URL: [node:url]
  • Title: [node:title]
  • Description: [node:summary]
  • Image URL: [node:field_image] (adjust the field name accordingly)

Find Image Field Token

To use an image stored in an image field, click on “Browse available tokens”.

Then drill down by going to Nodes -> Image. This assumes you’re using the Image (field_image) field on the Article content type.

The token should be [node:field_image].

Find Image Field Token on Media Asset

If you’re using a media field instead of an image field for handling assets, then use the following token, [node:field_media:entity:thumbnail] (change the field_media name accordingly).

6.After you fill out all of your OG tags fields, click on Save and clear the Drupal cache. If you do not clear your cache, the OG fields may not populate for existing content.

7. Once you have filled out the other OG fields with their respective token values, you should validate the resulting OG markup using the Facebook Sharing Debugger tool. We will now show you how to validate your OG markup.

NOTE: Your website has to be publicly accessible for the debug tool to work.

8. First we need to create a test Article node (make sure to upload an image to our image field). Our test article looks like this:

9. Paste the url for this node into the Facebook Sharing Debugger tool. The output should look like:

As you can see, Facebook successfully parsed our OG markup and displayed the information correctly.

Summary

Facebook lets you control your website’s content whenever someone’s shares a link to your content regardless of whether it’s shared from the desktop or mobile web or a mobile app. Facebook does this by parsing the Open Graph (OG) markup provided by your website. We have shown how you can use the Metatag module and Metatag Open Graph sub module to configure Drupal 8 to correctly generate the OG markup needed by Facebook and we have also shown how to validate your OG markup to ensure Facebook correctly parses your website content.

FAQ

Q: I changed the default meta tag configuration, but the tags are not changing?
Try clearing the site cache. Go to Configuration > Performance and click on “Clear all caches”.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Apr 27 2021
Apr 27
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

File Management Series

Removing files from Drupal is more tricky than you might think. There has been another tutorial about this using the module File Delete.  It requires going through a cycle of minimum 6 hours.  By default, Drupal protects files from removal which are still being used and referenced in other content. Instead of directly deleting a file, the linked usages need to be cleared first, and the files marked as temporary, then finally the system will remove them during cleanup.

This is actually a good policy. However, sometimes it’s annoying to wait for a few hours before these files are being cleaned up. In particular, if we are sure these files are unused or orphaned, there is another module called Fancy File Delete, which solves this problem.

Fancy File Delete allows you to delete files straight away without having to wait.

However, great care must be taken when using this module, because it has a ‘force delete’ option. Use of this module should be restricted to experienced administrators.

Table of Contents

Getting Started

Before we begin, go download and install Fancy File Delete.

Using the following Drush commands:

composer require drupal/fancy_file_delete

NOTE: The module requires the Views Bulk Operations (VBO) module which will be downloaded when you run the above command.

Deleting Files

To follow a proper procedure to delete files, administrators should still go through the proper file handling process by removing them from the nodes and the media library first, even though these processes can be bypassed using this module.

After installing and enabling the modules, go to Admin >> Configuration >>  Content authoring >> Fancy File Delete. In the first tab ‘Info’, it shows a brief description on how to use the module.

Enter the ‘List’ tab, a list of all the files in the system can be found from here.  Select the file(s) to be deleted using the checkbox in front of each file, then select ‘Delete Files’ in the ‘Action’ option on the top of the page, then click the ‘Apply to selected items’ button.

Note that there is another option for Action, which is ‘FORCE Delete Files (No Turning Back!)’.  When a file cannot be deleted, try this option but handle with care.

Can’t See Action Drop-Down

If you can’t see the Action drop-down on the list page that means you’ll need to reconfigure the view.

1. Edit the List view by clicking on the pencil icon.

2. Once you’re editing the view, click on the “Views bulk operations” field.

3. Enable the actions by clicking “Select all”.

Then save the view and you should see the Action drop-down.

Delete Files manually by FID

As can be seen above, there is a File ID for each file.  Files can be deleted using this FID by entering them under the ‘Manual’ tab. Just enter the FIDs of the files to be deleted, one per line, and press the ‘Engage’ button.

Deleting Orphaned and Unmanaged Files

Additional options are available to delete orphaned and unmanaged files if the system detects them.

Deleting Files from the ‘Files’ or ‘Image’ Fields

Note that in the above procedure using ‘Fancy File Delete’ module, it is not a requirement to remove them from the nodes first:

  • It bypasses the default file delete procedure in Drupal, and therefore it should be handled with care.
  • Files deleted will also be removed from previous node revisions too.
  • Files deleted will also be removed from the list of files under Admin >> Content >> Files
  • Files deleted are permanently removed totally from the system, including the physical file in the server.
  • It does not require waiting for the minimum 6 hours requirement.

When the files are uploaded through the media module and deleted without first removing them from the nodes and the media library first, this ‘Fancy File Delete’ module still remove the files same as above, except the following:

  • Files deleted will still be removed both physically from the server and from the list of files under Admin >> Content >> Files, like above.
  • The file will not be shown in node because it is empty, but an empty entity will remain both in the node and in the media library.

Using Drush

If you use Drush, you can delete files straight away using the “drush entity:delete” command.

For example:

drush entity:delete file 1

This command will remove the file from the Files page and delete it from the file system and you won’t have to wait.

Summary

This module offers a more straightforward and efficient way to remove files from a Drupal site permanently. It is powerful and capable of bypassing the default file handling procedures in Drupal. But that also means bypassing the file protection mechanism of Drupal. It handles file deletion in an efficient manner which is an advantage, but it is also a disadvantage at the same time.

On a large site where there are more users and content authors. When deleting files are granted to more people, it is difficult to guarantee that everybody is careful enough to understand the underlying structure and relationships between files and content. There is a higher risk of accidental deletion of files. In such situations, a better protection mechanism might be necessary.

On a small site or in a small team where content is easier to manage and control, efficiency might be preferred.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Apr 21 2021
Apr 21

Dealing with constant upgrades and changes to the project requirements is not just the despair of all developers, but also dents the pockets of the clients. When discussing the project development - time and cost go hand in hand. The more the development time, the higher will be the cost. 

Resolving these hurdles is easy with, Drupal distributions as these

(1) make project development less costly to both build and maintain and 

(2) make it more commercially interesting

Leading media and publishing enterprises across the globe are already testifying the positive impact that Drupal has made on their digital business. By enabling a professional editing experience, multi-channel publishing, and personalization distributions are revolutionizing the way media and publishing houses approach Drupal.

media-publishing-drupal-statisticsSource: Drupal.org

But, what is a Drupal Distribution?

Drupal Distribution accelerates website development not just by saving time and cost but it provides quality code with out-of-the-box Industry-standard features. Maintenance of distribution is simpler because updates for all its modules and features can be performed in one shot!

According to Drupal.org “Distributions provide site features and functions for a specific type of site as a single download containing Drupal core, contributed modules, themes, and predefined configuration. They make it possible to quickly set up a complex, use-specific site in fewer steps than installing and configuring elements individually.”

Distributions provide site features and functions for a specific type of site as a single download containing Drupal core, contributed modules, themes, and predefined configuration.

Looking to redesign or start your website using Drupal in 2021? Explore the detailed comparison of the top media publishing distributions that are EzContent, Rain, Varbase, and Thunder to choose the right solution for you.

Top 4 Media & Publishing Drupal Distributions for 2021

Content Listing from EzContent

Content Listing from EzContent


    • Structured content for SEO: With EzContent you can not only easily create structured content but also provides a range of approaches to enable search engine optimization (SEO), including flexible fields, built-in metatags, Schema.org usage, and a large library of available components for rich text, media, and other common content needs.

Component Library EzContentComponent Library EzContent


    • A page builder for landing pages: With EzContent’s page builder, editors can create layouts on the fly without any dependency on developers. They can use the convenient drag-and-drop interface to easily place reusable components onto pages as needed. Similar components can be reused by configuring in different variations.

Drag & Drop Layout Builder EzContentDrag & Drop Layout Builder EzContent


    • An API-ready decoupled CMS: EzContent provides OOB Headless, CMS integration with Gatsby, React, and Angular. Thanks to EzContent distribution, editors are still empowered with legacy CMS features like previewing unpublished content, placing blocks and content using Layout Builder. Ready to use open-sourced Angular and React starter kits are available.

Choice of Frontends, OOB starter LitsChoice of Frontends, OOB starter Lits


    • AI-powered content generation: For content, leverage auto-tagging and auto caption to generate meaningful and contextual tags driven by Google AI and AWS Rekognition.

    • Now you can also manage and perform an intelligent search leveraging image recognition, image detection, and Deep Learning algorithms. Generate auto Podcast out of Article Content on the fly while curating content with help of Google AI.

auto-tagging-ezcontentAuto-tagging for Images

  • Thunder

    Thunder was designed by Hubert Burda Media and released as open-source software under the GNU General Public License in 2016. It consists of the current Drupal functionality, lots of handpicked publisher-centric modules with custom enhancements.

    Key Features & Pros of Thunder

    • Publisher Features: Create articles dynamically with paragraphs. Using paragraphs, you can add text, pictures, videos, Instagram, or Twitter Cardscards to your article with a WYSIWYG editor. — Change the order of elements by dragging and dropping the content wherever you like it.

    • LiveBlog: Cover events in real-time with the liveblog.

    • Google AMP: With the integration to Google AMP, you can deliver not only text but also images, galleries, videos, as well as Instagram and Twitter cards.

    • Improved media handling: With the help of the media browser, it’s very easy to add pictures, galleries, or videos to your article. You can upload new pictures to the media browser by just drag & drop.

    • Mobile-Friendly theme: With the Thunder installation, you get a responsive theme for the frontend and backend.

  • Varbase

    Varbase is an enhanced Drupal distribution launched in Feb 2019. It is packed with adaptive functionalities and essential modules that speed up your development and provides you with standardized configurations. The essence of Varbase lies within the basic concept of DRY (Don’t Repeat Yourself). It removes the need to perform repetitive tasks with the help of its modules, features, configurations that are included in the Drupal project.

    Key Features & Pros of Varbase

    • Publisher Features, Flexible Content Structure & Categorisation: The flexible content architecture allows for custom pages, layouts, and integrations for your special use cases. Content is organized through a predefined and scalable structure for better navigation.

    • Media Management: Full-Feature libraries to provide an appealing way to display media galleries.

    • Multilingual options with localized and translated content, translated interface, date formats, country flags, modern fonts, and more.

    • Mobile-Friendly theme: Fully optimized for mobile.

  • Rain

    Mediacurrent created the Rain Install Profile in May 2019. Rain comes prepackaged and pre-configured with components

    Key Features & Pros of Rain

    • The rain has a strong content model & focuses on editor features. It combines content, administrative & editorial features with a base theme and style guide. It also implements Components based theme, meaning components can be reused, and a build-in style guide.

    • Rain has a preconfigured API for exposing content to other applications in the JSON format. Rain can be paired with frameworks like Gatsby

Metric Comparison:

Screenshot 2021-04-22 at 1.01.06 PM

We did not forget Acquia Lightning!

The list of media publishing distribution is incomplete without mentioning Acquia Lightning. However, Acquia is ending support for the Lightning distribution in November 2021, simultaneously with Drupal 8.

Read the official announcement here

Conclusion

There are a lot of distributions to choose from. Evaluate what your product requires, map it with the vision of the distribution. Do check the roadmap, backlog, compatibility, and maintenance for the distribution.

If you’re looking for a smart distribution, OOB Components, and you want to be flexible on a choice of frontend, EzContent provides a starter kit to save your development time by 30%. 

Apr 15 2021
Apr 15
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

File Management Series

In Drupal, files can be uploaded to the site for users to view or download. This can be easily achieved by creating a file or image field on content types.

In the back end, a list of all the files uploaded can be viewed by the administrator, by going to Administration > Content > Files (admin/content/files).

Files uploaded can be easily removed from the individual content pages (see the image below), but removing them entirely from the system is another story. You might be surprised that you cannot find a button, a link or an option to remove these deleted files entirely from the system.

After deleting files on content, if you go to the Files (admin/content/files) page, you will find the deleted files are still there, and the status still shows ‘Permanent’, even though they are already removed from the nodes. It seems very confusing. Removing files from content and removing files from the system are two different things in Drupal.

To remove files from the system, we need to add the file delete function. This can be achieved by installing the File Delete module.

Table of Contents

Getting Started

The File Delete module adds the ability to delete files from within the administration menu.

To download the module run the following Composer command:

composer require drupal/file_delete

How to Configure

After installing the module, we need to add a ‘Delete link’ to the Files page.  We can do that by going to Administration > Structure > Views and edit the views of the Files list. By default, the name of the views is ‘Files’:

To add the ‘Delete link’, we need to add a field called ‘Link to delete File’ in this views, which appears like the following image:

Select this field.  We can keep everything by default, and then click ‘apply’ and save the views.  Next, go to Administration > Content > Files, and there we shall see the ‘delete’ link there, like the following:

How to Use

With this ‘delete link’, we can remove the delete files from the system by clicking on the ‘delete link’ shown in the above diagram. Note that Drupal will protect all the files, and will not allow files to be deleted when they are being used in any content.  If you try to delete a file which is still being used in a node, you will see this following error message.

The Tricky Part

In some cases, even if you have deleted the files from the nodes, and the files are no longer visible in the nodes, you might still find this error message disallowing you to remove the file from the system.

But that might be correct because these files might still be used in content. The nodes where these files came from might have more than one revision. These files removed from the current revision might still be attached to the previous revisions.

When this happens, check out the nodes again for multiple revisions, like the following example:

Only when all attachments (including the old revisions) are cleared, then these files can really be removed from the system. So in summary, when we delete the files, we need to make sure that these files are not being used in any content, including the old revisions.

The File Status

Even though you can successful remove deleted files from the system using the ‘Delete link”, you will still find the following:

  • The file is still on the list
  • The status of the file is changed from ‘Permanent’ to ‘Temporary’
  • The file is used in 0 places (that means it is not used with any nodes)

Following is an example how it will look like:

But why do these deleted files showing ‘temporarily’ status still appear in the list?  Here is why …

In fact, the files removal process has already been initiated. Drupal will delete the file in the following sequence:

  1. Change the status from ‘Permanent’ to ‘Temporary’
  2. Wait for a minimum of 6 hours
  3. Upon the next cron-run after 6 hours, the system will really remove these temporary files

That is why you still see these deleted files in the list within this 6-hour period.  This is how Drupal manages temporary files.

Temporary File Management

If you go to Administration > Configuration > Media > File system, you will find a configuration and explanation at the bottom of the page:

Here it says temporary files will be deleted in the next cron run after 6 hours. Note that 6 hours is the minimum. This ‘6 hours’ setting can be changed, but 6 hours is already the minimum.  See the following options for the configuration:

With the ‘Media’ module, files can also be added as media documents instead of a ‘File’ field.  These files added as media documents can also be deleted, but it will be a little bit different in the operation. Again, the system will not allow deleting files that are still being used.

To delete such files added as media entities, pay attention to the following:

  1. Confirm that the media is not being used on the site first.
  2. Go to Administration > Content > Media to the list of media entities, and delete the designated items here first.
  3. Next go to Administration > Content > Files, and then delete the designated files here.

It will go through the 6-hour cycle described above, but we should leave it to the system to handle it from here.

The Files list is within the administration area, accessible by the administrator. But if other users will require access to this area to delete the files, user permissions need to be configured specifically to this module.

Using Drush

If you use Drush, you can delete files straight away using the “drush entity:delete” command.

For example:

drush entity:delete file ID

This command will remove the file from the Files page and delete it from the file system and you won’t have to wait.

Summary

The file delete procedure in Drupal is not that user-friendly. The module provides the ability to delete files in Drupal.  The procedure for deleting files is a little bit complicated, due to the fact that files can be used therefore associated with different entities in the system.  Also, for this reason, it is suggested that file delete be handled by an experienced administrator with the right permission and access to the administration area.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Mar 23 2021
Mar 23
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

File Management Series

Drupal doesn’t support the ability to replace existing files. You can create and delete files, but you can’t replace a file without using a module. If you try to upload a file with the same name Drupal will append “_0”, “_1”, etc… to the filename and increment it.

Luckily two modules can help with replacing files, and they’re called Media Entity File Replace and File Replace.

What is the main difference between Media Entity File Replace and File Replace?

Both modules will replace “files” whilst retaining the original file’s filename by performing an “overwrite” function in the backend. In Drupal, an uploaded “file” can be a “media entity” or a “file entity”.

As the module names suggest, the main difference is that Media Entity File Replace works at the media entity level, whereas File Replace works at the file entity level.

Table of Contents

This module allows editors to replace files at the media entity level by overwriting the existing media files. Because it overwrites the files, the filename and path are exactly retained.

You should use this module to allow content editors to replace media entity files whilst keeping the same filename and path as the original file.

Getting Started

1. Download and enable the module. This module requires no additional libraries and can simply be installed with composer which is the recommended way.

To install using Composer:

composer require drupal/media_entity_file_replace

If you get the following error when using Composer:

  [InvalidArgumentException]
  Could not find a version of package drupal/media_entity_file_replace matching your minimum-stability (stable). Require it with an explicit version constraint allowing its desired stability.

Then specify the version:

composer require drupal/media_entity_file_replace:^1.0-beta3

To enable the module using Drush:

drush en media_entity_file_replace

2. Clear the cache. You can easily clear the cache via the Drupal admin UI at admin/config/development/performance or by the drush command:

drush cr

A quick overview of this step is adding a media field to an existing content type and uploading an actual media document. If you already have a media field in your content type and an uploaded media file then you can skip to step 3.

A. For any content type (we will use the default Drupal Article content type in this tutorial), add a Media field and check “Document” as the Reference type. See Image 1 below.
B. Go to Content >> Media and click on “Add Media”. At the next page, select “Document” and proceed to upload a file. Note the filename.

Image 1 – Enable “Document” reference type for the newly created Media field in the Article content type

3. Now enable the “Replace file” widget that comes from the Media Entity File Replace module.

Go to Structure >> Media Types >> Document >> Manage Form Display and enable the “Replace file” widget. This widget is disabled by default. See Image 2 below. You will not be able to replace a file until you enable this widget.

It’s a good idea to position the “Replace file” widget right under the file widget as shown in Image 2 so that when a user is editing a file, the “Replace file” widget is right under the file that they want to replace.

Image 2 –  Enable the “Replace file” widget in the Document media type found under “Manage Form Display”.

Without this module and widget enabled, the default Drupal interface will appear as in Image 3.

Image 3 – The default Drupal 8 interface to replace a media file.

4. Now if you go to Content >> Media and edit the document media that we uploaded in Step 2.B, you will see the “Replace file” widget as shown in Image 4 below. Notice that the default Drupal widget is automatically removed (see the difference between Image 3 and Image 4).

Image 4 – The “Replace file” widget coming from the Media Entity File Replace module

5. Go ahead and replace the original uploaded file with a new file with a different filename. Upon replacing the file, if you left the default option “Overwrite original file” checked, then Drupal will upload the new file and set the old file for deletion. Even if your new file has a new file name, Drupal will store the new file whilst retaining the filename of the original file. Note that the filename is the same as that noted from Step 2.B.

If you click on the new uploaded file even after doing a refresh in the browser, you may still see the old content of the original file. You must do a hard refresh in your browser to see the contents of the newly uploaded file.

More information: How to do a hard refresh in Chrome, Firefox and IE.

File Replace

This module allows editors to replace files at the file entity level by overwriting the existing files. Because it overwrites the files, the filename and path are exactly retained.

You should use this module if you want to allow content editors to replace file entities whilst keeping exactly the same filename and path as the original file. It is useful in cases where existing files in Drupal need to be updated occasionally.

Getting Started

1. Download and enable the module. This module requires no additional libraries and can simply be installed with composer which is the recommended way.

Using Composer:

composer require drupal/file_replace

To enable the module using Drush:

drush en file_replace

2. Clear the cache. You can easily clear the cache via the Drupal admin UI at admin/config/development/performance or by the drush command:

drush cr

3. There is one extra manual step that you must do. Because this module only provides the “Replace page” for each file upload, it does not provide a link to this page from the Drupal UI. You can access the “Replace page” directly by typing the URL into the browser. You can manually type the following URL into the browser:

admin/content/files/replace/{{ fid }}

Where {{ fid }} is the file id of the file you want to replace. For example, if the fid was 6, then you would go to:

admin/content/files/replace/6

This is not ideal. We will show you how to link to the page from the default Drupal Files overview page. (The outcome we are trying to achieve is shown in Image 11.)

Go to Content >> Files and click on “Edit view” as shown in Image 5.

Image 5 – On the Files overview page, click on the Edit icon to the top right to edit the View.

Alternatively, you can go to Structure >> Views and edit the Files view as shown in Image 6.

Image 6 – Editing the Files view found on the View listing page.

4. Add a Custom text field to the Files View as shown in Image 7.

Image 7 – Adding a Custom text field to the Files view.

5. Then add some custom text for the text of the link. See Image 8

Image 8 – Adding custom text for the link anchor text

Also, edit the “Rewrite Results” section and enter the following in the “Link path”:

admin/content/files/replace/{{ fid }}

You can also enter custom text in the “Title text” field although this is just for aesthetic purposes. See Image 9 below.

Image 9 – Rewriting the results of the link to include a relative path.

Now click on “Apply (all displays)” and save your View.

6. The last step is to enable the “Replace files” permission for the role that you want. See Image 10.

Image 10 – Enable the permission “Replace files” for your role.

7. Now go to the Files overview page at Content >> Files and you will see a “replace” link as shown in Image 11.

Image 11 – Showing the custom “replace” link created from editing the Files view

Click on the “replace” link next to the file you want to replace and this will take you to another page where you can upload a new file as shown in Image 12.

Image 12 – The “Replace file” page provided by the File Replace  module.

Common Pitfall – Caching

Static files served by Drupal are usually cached externally (outside of Drupal) by services such as Varnish, Content Delivery Network (CDN) and the user’s browser. By default, a user’s browser will not pick up the content of the newly uploaded file until after the max-age header which is set in .htaccess for two weeks for static files. In other words, if you replace a file and do nothing, end users will see the new file content after two weeks (unless they locally do a hard refresh).

Clearing Drupal’s internal cache will not solve this caching caveat because Drupal is not involved with serving static files. This is the job of your webserver.

There are a few options worth mentioning:

Summary

Drupal does not retain filenames for uploaded files that are replaced or overwritten. Additionally, Drupal stores uploaded files as either media entities or file entities depending on your set up. This tutorial demonstrated how to retain existing file names when replacing media or file entities. There are two contributed modules you can use to solve this problem and they are Media Entity File Replace and File Replace. These modules will allow you to overwrite existing media and files respectively, whilst keeping their original filenames.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Mar 02 2021
Mar 02
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

The “Long text and summary” field has a formatter called “Summary or trimmed”. This formatter allows you to trim text to a specified set length which is important if you’re displaying a list of articles. The last thing you want is to have an article display 1000 words on the homepage.

However, this default “Summary or trimmed” formatter cannot trim the summary. If the author enters in lots of text into the summary it’ll display everything.

The Smart Trim module offers a field formatter for trimming text fields. Additional settings are available more than the default “Summary or trimmed” option – an improvement over the default formatter.

Smart Trim can also apply to Text (Plain) and Text (Plain, Long) fields which, by default, do not have the “Trimmed” option available.

Table of Contents

Getting Started

Before we can begin, go download the Smart Trim module.

Using Composer:

Composer require drupal/smart_trim

Once downloaded go and install the module.

How to Use Smart Trimmed Formatter

1. Go to Structure > “Content types” and click on the “Manage display” on a content type row.

2. Under the “Format” of text fields, an option of “Smart trimmed” will be available.  Select this option.

3. After the “Smart trimmed” option is selected, click on the cogwheel on the right.  More configuration settings are available. (The Summary option is not available for text fields without summary.)

4. Configure the settings accordingly, then click Update and save.

Format Settings

Trim units

Trimming of text can be applied to characters or words. This takes care of word-boundary issues on trimming.

Suffix

Suffix can be appended to the trimmed text, such as “…”.

Display more link?

When enabled, a link of “More” will be added to the bottom of the page. This will allow the user an option to view the entire page.

Summary

This option is only available when using the “Text (formatted, long, with summary)” field. Three options are available:

  • Use summary if present, and do not trim
  • Use summary if present, and honor trim settings
  • Do not use summary

These options allow overriding of the summary.

Strip HTML

This option will Strip out any HTML when displayed. This is important if you’re truncating text because you could display an opening HTML tag but not close which could break the site styling.

Summary

The Smart Trim module provides a more powerful trimming formatter than what is offered out-of-the-box. Best of all, it can be used on any type of text field.

FAQ

Q:  Can I use this module for all text fields?

Yes, it can be applied to all default text fields, plain or formatted, short or long.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Feb 22 2021
Feb 22
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

This tutorial will demonstrate how to use the Custom Permissions module.

By default in Drupal, user permissions in the Drupal backend are not very granular.

For example, if you want to give a role the ability to edit only the “Basic site settings” in the Drupal admin UI. In Drupal, this can be achieved by giving the access permissions “administer site configuration”. However, with this permission enabled, the role will also have the ability to edit other site settings which you may not want a user to have access to.

Enter the Custom Permissions module.

With this module, you could solve the above problem by creating an extra custom permission to edit only the “Basic site settings” page without assigning the “administer site configuration”.

This light-weight module will allow you to specify the exact admin route (or path) that you want to give permissions to without giving the role access to everything in the administration section.

In this tutorial, you’ll learn how to create a custom permission which will only have access to the “Basic site settings” page. We’ll be using the 8.x-2.x version of the module.

Table of Contents

Difference between 1.x and 2.x?

Both versions accomplish the same functionality, but the difference is that when specifying the page you want to give access to, version 8.x-2.x uses routes and version 8.x-1.x uses paths.

Diagram 1 – Version 8.x-1.x using paths Diagram 2 – Version 8.x-2.x using routes

How to Find out the Route Name

A route in Drupal is a path which is defined for Drupal to return some sort of content on. Routes are defined in a module’s MODULE_NAME.routing.yml file. There can be routes defined in contributed, custom or Drupal core modules.

For Drupal core routes (paths in the Drupal core admin UI), you would want to text-search for the path in: web/core/modules/system/system.routing.yml

For contributed or custom routes, search in the relevant modules’s “.routing.yml” file.

In our example, the block of code in system.routing.yml for our path “admin/config/system/site-information” is:

system.site_information_settings:
   path: '/admin/config/system/site-information'
   defaults:
     _form: '\Drupal\system\Form\SiteInformationForm'
     _title: 'Basic site settings'
   requirements:
     _permission: 'administer site configuration'

The route name is bolded above to show you what the route name will be. The exact route name is: system.site_information_settings.

Using Devel

If you prefer not to search through code to find the route name, look at using the Devel module. Devel comes with a Routes Info page which lists all the active routes and its paths, and you can filter the page. This makes it easy to find the correct route.

Once the module is installed click on the Devel link in the toolbar then “Routes Info”.

On the “Routes Info” page you’ll see a long list of routes and its paths.

Getting Started

This module requires no additional libraries and can simply be downloaded with Composer.

Using Composer:

composer require drupal/config_perms

Installing the module with above composer command will install version 8.x-2.x of the module.

Once downloaded go and install the module.

How to create a Custom Permission

In this tutorial, we are going to create a custom permission to allow a role to access and update only the “Basic site settings” page in the Drupal admin UI.

1. Once the module is installed, go to People > Custom permissions.

You’ll notice that the module comes with four default custom permissions.

2. Click on the “Add permission” button, and you will get an additional row to add a new permission.

3. Give your new permission an admin human-readable name and click on “Save”. Note that this name is only visible to the site admin. The route that we want to use for the “Basic site settings” is “system.site_information_settings”.

4. Go to People > Roles and edit the permissions of the role that you want to assign this new custom permission too. We will use the “Authenticated user” role in this example.

5. Scroll to “Custom Permissions” and you will see the new custom permission human-readable name you created in Step 3. Enable it.

6. For the new role to access the administration pages in Drupal, you also have to enable “Use the administration pages and help”. You can also enable “Use the toolbar” so the user can see the enabled permission in the admin toolbar although this is just for convenience and not a requirement for this tutorial.

7. Now, the user with the role “Authenticated user” will have access to the following permission as shown below:

Summary

Drupal, by default, may not always define granular permissions to certain administrative pages. Typically, a role can be given all or no access to administrative pages.

Using the contributed module Custom Permissions (version 8.x-2.x) you can define custom permissions for specific Drupal admin pages. This module provides finer granular permissions for specific Drupal routes/paths.

Editorial Team

About Editorial Team

Web development experts producing the best tutorials on the web. Want to join our team? Get paid to write tutorials.

Feb 11 2021
Feb 11

Last week one of our clients was asking me about how they should think about the myriad of options for website hosting, and it inspired me to share a few thoughts. 

The different kinds of hosting

I think about hosting for WordPress and Drupal websites as falling into one of three groups. We’re going to compare the options using an example of a fairly common size of website — one with traffic (as reported by Google Analytics) in the range of 50,000–100,000 visitors per month. Adjust accordingly for your situation. 

  • “Low cost/low frills” hosting — Inexpensive website hosting would cost in the range of $50–$1,000/yr for a site with our example amount of traffic. Examples of lower cost hosts include GoDaddy, Bluehost, etc.  Though inexpensive, these kinds of hosts have none of the infrastructure that’s needed to do ongoing web development in a safe/controlled way such as the ability to spin up a copy of the website at the click of a button, make a change, get approval from stakeholders, then deploy to the live site. Also, if you get a traffic spike, you will likely see much slower page loads. 
  • “Unmanaged”, “Bare metal”, or “DIY” hosting — Our example website will likely cost in the range of $500–$2,500/yr. Examples of this type of hosting include: AWS, Rackspace, Linode, etc. or just a computer in your closet. Here you get a server, but that’s it. You have to set up all the software, put security measures in place, and set up the workflow so that you can get stuff done. Then it’s your responsibility to keep that all maintained year over year, perhaps even to install and maintain firewalls for security purposes. 
  • “Serverless” hosting¹ It’s not that there aren’t servers, they’re just transparent to you. Our example website would likely cost in the range of $2500–5000/yr. Examples of this kind of hosting: Pantheon, WP Engine, Acquia, Platform.sh. These hosts are very specialized for WordPress and/or Drupal websites. You just plug in your code and database, and you’re off. Because they’re highly specialized, they have all the security/performance/workflow/operations in place that 90% of Drupal/WordPress websites need.

How to decide?

I recommend two guiding principles when it comes to these kinds of decisions:

  1. The cost of services (like hosting) are much cheaper than the cost of people. Whether that’s the time that your staff is spending maintaining a server, or if you’re working with an agency like Advomatic, then your monthly subscription with us. Maybe even 10x.  So saving $1,000/yr on hosting is only worth it if it costs less than a handful of hours per year of someone’s time. 
  2. Prioritize putting as much of your budget towards advancing your organization’s mission as possible. If two options have a similar cost, we should go with the option that will burn fewer brain cells doing “maintenance” and other manual tasks, and instead choose the option where we can spend more of our time thinking strategically and advancing the mission.

This means that you should probably disregard the “unmanaged/bare/DIY” group. Whoever manages the site will spend too much time running security updates, and doing other maintenance and monitoring tasks. 

We also encourage you to disregard the “low cost” group. Your team will waste too much time tripping over the limitations, and cleaning up mistakes that could be prevented on a more robust platform.

So that leaves the “serverless” group. With these, you’ll get the tools that will help streamline every change made to your website. Many of the rote tasks are also taken care of as part of the package. 

Doing vs. Thinking

It’s easy to get caught up in doing stuff. And it’s easy to make little decisions over time that mean you spend all your days just trying to keep up with the doing. The decision that you make about hosting is one way that you can get things back on track to be more focused on the strategy of how to make your website better. 

¹ The more technical members of the audience will know that “serverless” is technically a bit different.  You’d instead call this “platform-as-a-service” or “infrastructure-as-a-service”. But we said we’d avoid buzzwords.

Jan 13 2021
Jan 13
[embedded content]

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

The roles and permissions system in Drupal is powerful, but it can be tricky to configure correctly. Some permissions give a role too much privileged access where others aren’t granular enough.

An excellent example of this is if you need to create a role to manage user accounts.

Drupal comes with the permission “Administer users” which lets you create user accounts, only give this permission to trusted users.

The above mention permission allows you to create user accounts but you can’t assign them roles without “Administer roles and permissions”. But this permission (“Administer roles and permissions”), will enable you to assign any roles, including the default Administrator role.

From this:

To this:

In some circumstances, you don’t want users who can create user accounts to have the ability to assign any roles, especially the Administrator role.

What if you want to control exactly which roles can be assigned? This is where Role Delegation can help.

Table of Contents

Getting Started

To get started, download and install Role Delegation.

composer require drupal/role_delegation

Using Role Delegation

All the module does is offer granular permissions for assigning roles.

Once the module is installed, go to People > Permissions and search for the Role Delegation section.

You’ll notice that you get a specific permission for each role, and you also get the “Assign all roles” for absolute power.

All you need to do is give one of the “Assign {role} role” permission and they’ll be able to assign users into that role.

Assign Role

Once a role has been assigned a few “Role Delegation” permissions, they can assign roles in two ways.

First, if you edit an account you should see the Roles checkbox below Status.

The module adds a new tab on user accounts called Roles. This page has all the allowed roles as checkboxes.

Select a role and click on Save to assign them.

Summary

The functionality that Role Delegation offers should be in Drupal core in my opinion. If you need to control which roles can be assigned then it’s a useful module to add to your Drupal site building toolbox.

FAQ

Q: I can’t see the “Administer roles and permissions” permission on my site?

It was changed from “Administer permissions” to “Administer roles and permissions” in Drupal 9.1.

Ivan Zugec

About Ivan Zugec

Ivan is the founder of WebWash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 12 years and has successfully completed several large Drupal projects in Australia.

Jan 11 2021
Jan 11

Whether you are running your business into B2B space or B2C space, the need for agility and speed in workflow management is indispensable. Because eventually, clients also expect faster delivery of the project/application to catch up with their customers’ requirements.

However, if developers do not use any standard tools, it can add unnecessary overhead and eat away their development time. Also, given that they are coming from different backgrounds and skillsets, it would become difficult for stakeholders to set up projects, onboard developers, troubleshooting, and even train them as large-scale projects come with complex requirements.

That is why it’s critical to have a standardized development environment across the teams. This blog guides you on using Lando software (an open-source tool that provides a single local development environment for all the developers’ projects) with Drupal 9 composer, PHP & SCSS Linters, and a multisite architecture scenario.

How Lando Provides a Standard Development Environment?

Setting up the project from ground level to managing configurations and distributing it to each developer, including frontend & backend,  becomes tedious due to various aspects, including different machines, a different configuration of the machine, and different OS.

And that’s where Lando software comes into the picture.

What is Lando Software?

It is an open-source, cross-platform, local development environment, and DevOps tool built on Docker container technology. Its flexibility to work with most of the major languages, frameworks, and services helps developers of all skill sets and levels to specify simple or complex requirements for their projects and then quickly get to work on them.

Some of the benefits of Lando include-

  1. Maintaining standardization across project/application.
  2. Offering speedy development(prebuilt configuration of the composer, drush).
  3. Add tooling to extend it from services. 
  4. Recommends out-of-the-box settings that are customizable.
  5. Automates the complex steps involved in unit testing, linting, compiling, or other recurring workflows.

How to Use Lando With Drupal 9’s Composer.json for Faster Development?

Consider a scenario when a developer has been replaced in the team with the new developer for the existing Drupal project. The new developer might not be familiar with the OS that others are using. Here, it would become difficult for him/her to install the composer quickly. And hence, this would delay his/her onboarding process.

However, if the team is already using Lando for development, it would take care of the operating system’s bottleneck itself. In fact, the composer is already built in the recipe (Recipes in Lando are the highest level abstraction and contain common combinations of routing, services, and tooling) of Drupal 9 and is also compatible with different OS. The only thing is developers should know how to use it.

code written in maroon background

Steps to Use Lando with Drupal 9’s composer.json

The prerequisite for this setup is that your local development machine should be compatible with Docker and Lando and installed successfully without any glitches. Make sure when you are running docker setup, other ports are not conflicting with Lando setup.

Here are the steps to be followed-

  1. You need to clone this  Drupal 9 open source git repository.(Ex:

    git clone  [email protected]:AbhayPai/drupal9.git)

  2. Change the directory to the cloned repository. (Ex: cd drupal9)

  3. Start your app using the lando start command. Before you begin, you can change some parameters in .lando.yml as per the need of your application.

This repository would give you some common tools that include linting of PHP, linting of SCSS, linting of js files, and compiling of SCSS files and services like node.js and npm to directly connect with the Lando app. You do not need to go inside any container after starting your application. By default, this repository is only able to lint custom themes and is flexible enough to extend it to custom modules and profiles.

How to Use PHP Linters With Drupal in Lando

As Drupal is one of the largest open-source communities, millions of developers contribute and offer coding solutions in different ways. To standardize the coding practices and make the modules easy-to-maintain and readable, varying from indentation, whitespaces to operators, casting, line length, and many more, Drupal has a core package that takes care of these standard practices automatically when configured in the project. In general, these are called PHP Linters.

Following are the steps to configure the PHP linter in the project-

  1. Download dependencies package of Drupal coder using `lando composer requires drupal/coder`.
  2. Define a file for linter standard or copy file from Drupal core in your project folder where all standards are predefined in the XML file. It resides in core/phpcs.xml.dist.
  3. Configure a tool of `lint:PHP` within the .lando.yml file like the below example-

code written in black background

4.  Confirm if tooling is configured correctly just by using the ‘lando’ command to list all tooling. code written in white background

5.  Use this newly configured tool in your project using ‘lando ’. In this case, it is ‘lando lint:php:themes’

code written in maroon background

This automating tool which is configured with Lando software will help developers save time for finding and fixing these issues and will also ensure best practices are followed in the project repository.

How to Use SCSS Linters With Drupal in Lando

SCSS is a preprocessor used for writing CSS or CSS3 in any modern-day project. This SCSS is used because it helps developers to write less code and remove redundancy in the repetition of classname and other properties which are frequently used in the project.

The purpose of using SCSS linter in the project is to ensure that the quality of the code is high and easily maintainable for future enhancement. Further, it would save time in development and faster delivery of the projects.

Following are the steps that need to be followed for configuring the SCSS linter in our project-

  1. Configure node service and install gulp inside that service within .lando.yml file.
    code written in black background
  2. Configure tool for using npm with Lando within .lando.yml file.
    code written in black background
  3. Confirm if tooling is configured correctly just by using the ‘lando’ command to list all tooling.
    code written in white background
  4. Create a package JSON file and install and configure the stylinter package in the project.
  5. Create a new script in the package.json file for triggering stylinter.
    code written in black background
  6. Configure the tool to trigger this using lando.
    code written in black background
  7. Confirm if tooling is configured correctly just by using the ‘lando’ command to list all tooling.
    code written in white background
  8. Run this tooling command and Lando will lint it automatically.
    code written in maroon bavkground

This automation tool integrated with Lando for SCSS linter will ensure that best practices and code hygiene is followed in the project repository.

How Can Lando Help in Reducing Developers’ Efforts While Building Drupal Multisite Architecture?

Let’s take a scenario where your project ( client’s website) is live now and running smoothly. Now the client wants to create multiple new sites in alignment with the existing site. For instance, the new sites should have custom modules, themes, profiles, etc. to ensure brand consistency. 

Here, Drupal would come in handy as it would simplify the multisite architecture and speed up the local development setup with Lando through some minor tweaks in configuration files.

For setting up multisite architecture in an existing project, you need to follow below steps- 

  1. Configure .lando.yml file to setup app server URL for the new website
    code written in black background
  2. Configure database server for setting up this site with the new website
    code written in black background
  3. Configure drupal settings like sites,php, and folder structure for site2; to leverage this Lando configuration
    code written in black background
    code written in black background
  4. Rebuild configuration for setting up this new website.
    code written in maroon background

The minor tweaks in the existing project would help you extend existing Lando projects/websites to build multi-site architecture via local development and accelerate the delivery process for the client.

Conclusion

If you have come this far, Dhanyavaad (thank you). I hope that this article would help you in speeding up the development process & hence, faster project delivery, knowledge transferring of your application/project with Drupal, and leveraging Lando at its best by using inbuilt composer for automation in local development environments.

Now that you are armed with the knowledge and Lando’s benefits, what are you waiting for? Get started now!

Dec 15 2020
Dec 15

Every aesthetically pleasing website has a common ground - a good theme. An attractive theme can bring the website’s visuals to life and facilitate you to create a powerful brand identity. But that’s just one part of the story!

The website theme, beyond being beautiful, should cater to great user experiences also. 

And that’s how you prepare a robust yet enticing website - maintaining design & the best usability practices hand-in-hand are the key to increase conversion rates.

The launch of Drupal 9 in June encouraged the community to make it high up on their agenda to revamp its user experience and ensure friendliness for every stakeholder - designers, editors, marketers, and developers, of course. 

With an emphasis on Olivero, a modern front-end theme designed to exhibit the CMS in its best light; front-end developers can expect plenty of benefits from it. 

It will empower them to bring that magical touch to the websites by utilizing their creativity along with modern tools and frameworks to define layout, styles, typography, buttons, color schemes, and many more, to drive the visuals and engagements of the website/ application.

This blog walks you through Drupal's soon-to-be default theme - Olivero and how front-end developers can leverage it for designing a great website.

Olivero and its Benefits

Olivero is going to be a new default front-end theme that is expected to be rolled out in Drupal 9.2. It is designed to give Drupal a flamboyant look and feel. Olivero is also going to be compatible with the Drupal 8 website as a contributed theme.

Currently, Bartik, a ten-year-old theme, initially created for D7, is being used. It is certainly mobile-responsive and had some outstanding features to meet D8’s mobile-first requirements. However, the development has outdated the design. 

Thus, the need for a new front-end theme emerged to showcase Drupal’s strength appropriately.

Drupal Trivia

Olivero is named after a female programmer, Rachel Olivero, an outstanding supporter/ programmer of website accessibility. Sadly, she passed away in 2019. To honor her, the Drupal community kept her name alive with this beautiful theme. The idea is to showcase patience, generosity, and inclusiveness - the qualities of Rachel that the theme should also epitomize.

 

Benefits of Olivero Theme in Drupal 9

The Olivero theme is intended to give Drupal websites an eye-pleasing view apart from ensuring,

  • Simplicity- declutters by eliminating the colors, effects, and visual elements that make the theme look and feel too heavy.
  • Professional look - encompass all the design elements, for instance, negative space and high contrast, to grab users’ attention.
  • Accessibility- designed with WCAG AA conformity in mind, from functionality to layout, to colors, all components will be accessible for everyone. 

Drupal Trivia

The blind federation conducted an accessibility test to evaluate the Olivero theme for visually impaired users. They were happy and satisfied with its design and high responsiveness.

  • Flexibility- facilitates Drupal front-end developers with multiple options to choose from - be it button styles, headers, or logo styles to text titles, and many more.
  • Compatibility - supports modern browsers’ features & various engagement modes. The creators have ensured that the theme supports recent Drupal updates and features for websites such as Layout builder, media embeds, second-level navigation, and many more.

Get the Hang Of Olivero’s Exciting Features

Here are the features of Olivero that you can leverage for designing your next Drupal website-

A. Bright color palette

Websites leveraging Olivero’s color scheme will look beautiful with a base color of bright blue. Besides being attractive, it would boost Drupal’s brand recognition. Several permutations and combinations of darker and lighter colors and shades would provide website improved accessibility.

Screen Shot 2020-12-15 at 11.23.46 AM

A bright color palette in Olivero theme

B. Simple and elegant forms & buttons

The forms and buttons added in the new theme are user-friendly, distinguishable, and accessible. Forms comprise a left color bar, and their labels are placed above the fields to abide by the website accessibility requirements and guidelines. 

The buttons inform users about clickable action. The theme also has a filled primary button style and a secondary button style which is an outlined version of the button.

The buttons’ different modes are present default in Olivero, unlike other themes where you need to define these modes. 

The four modes are- Default, Hover, Focus, and Active

8 rectangles in white background

Button modes in the new theme

C. Typography

Typography provides scale to maintain uniform sizing, line height, and spacing throughout the design. The base font used for body copy is 18px. The size can be tweaked for smaller screen sizes.

Consistency, throughout line height and spacing, has been a key objective when setting the scale for typography.

D. Flexible header and navigation options

Navigation options can cater to any website’s needs. The header can fold into a hamburger button menu when scrolling, allowing the user to access the menu easily on long pages. 

The secondary dropdown menus are also supported by Olivero, thus saving coding efforts of developers unlike Bartik where they need to reinvent the wheel time & again.

E. Vertical Rhythm

Vertical rhythm ensures the correct spacing arrangement of the text. It calculates line-height, font size, and margin or padding to maintain equal space throughout the website. 

F. UI Patterns

The header is designed flexibly so that it can accommodate the text titles and or logos of varied width and height. 

On scroll down, the header will fall into a hamburger-button menu, to let the user access the menu or longer pages.

G. Site branding variations

You can tweak the theme settings to change the background color and width of the site-branding to incorporate different types of logos and long text.

white background with text and boxes

Flexible site-branding options in Olivero

H. Forms

These simple yet modern forms consist of elements that enhance the design, while still being recognizable, usable, and accessible. 

The left color bar highlights the form element and labels are added above the form field to avoid confusion. Form fields have a consistent look to indicate to users that they are a form element. States such as focus, disabled, and errors have also been accounted for.

3 field boxes

Highlighting error state in the form

I. Tables

Table divider lines are designed such that it improves readability. Olivero's theme will also support the responsive table features of Drupal. 

J. Sidebar

Only one sidebar is implemented to stop competition for space on the screen. It improves readability and allows content to look more rich and prominent on the screen. Editors can showcase related posts and other types of utility blocks too. 

The sidebar also offers good support and space.

Text written in white background

One sidebar aimed at improving readability

K. RTL Support

Olivero theme supports right-to-left languages as required by Drupal core. It also supports better display and multilingual functionality. For example, Arabic, Hebrew, Persian, and Urdu support RTL writing and so does Drupal.

text written from right to left in white background

RTL support in Olivero

L. Messages

Messages intent to inform users for they need to consume important information or provide feedback on an action already taken. 

Messages are visible as they are designed with bright colors to highlight the message and yet don’t mess up with the readability of the message itself. 

Text written in white background

Displaying messages per their type (error, alert, and success message)

M. Breadcrumbs

Breadcrumbs in Olivero are placed near the top of the page above the page title to help users keep track of documents or websites. 

A visual cue informs users about more breadcrumbs which they can access later by swiping left to right or right to left. This feature is not part of MVP. 

Text written in white background

Breadcrumbs to keep track of pages

N. Color module

This feature is not part of the initial release. However, this or similar functionality might be included later. 

Challenges That Olivero is Going To solve for front-end developers

Olivero is a modern theme with a magnificent look and feel. It can help front-end developers in simplifying their work. See how-

1. Lighter theme with up-to-date design elements

Unlike Bartik which used outdated graphical elements such as drop shadow and gradient, it uses a layout builder, grid system, hamburger menu, to name a few, to ensure that the site remains lightweight and responsive.

2. Low code

There is little or no coding required in CSS to determine the presentation of a web document and for adding content blocks anywhere. 

There are few other scenarios that simplifies the work of front-end developers -

  • Bartik doesn’t offer a secondary menu while Olivero does. This saves the coding efforts of front-end developers 
  • If any other theme is used, the hamburger menu is not available. Olivero theme is mobile-friendly. It encapsulates the menu automatically via the hamburger menu feature. No coding is required for it.

3. Scalability

Even on enlarging page size, it won’t break. Instead, it would give you a clear view as always. This makes Olivero more responsive.

4. Compatibility with other browsers

Bartik is not compatible with other browsers like Internet Explorer 11 while Olivero is. Front-end developers need not write code separately to ensure the support to all the functionality and features of the browsers. 

5. Code compilation/ testing

Olivero has CSS Grid Layout that can handle both columns and rows. It is a powerful layout system that helps developers write code hassle-free. They can write code in a nested structure to make it compact, easy to understand and increase readability. 

6. Extensibility with PostCSS Standalone technology

PostCSS is an accessible tool that empowers front-end developers to easily contribute to in the form of custom plugins. 

It simplifies the writing of CSS stylesheets by keeping code simple and facilitating understanding of dependent selectors and media queries within the stylesheet. 

During the development of the Olivero theme, there were several PostCSS plugins that were leveraged to make the CSS more readable and reduce the probability of breaking the page.

Conclusion

Olivero is a modern theme that is going to be the new default theme for Drupal from version 9.2. Front-end developers can use this flexible and scalable framework to improve work efficiency and create exquisite websites. 

Figure out how your enterprise can leverage Olivero’s constructive features to empower your front-end developers. Meanwhile, let’s wait for this beautiful theme!

Nov 09 2020
Nov 09

[embedded content]

Sarah Durham (00:02):

Hey everybody. Welcome to today’s webinar. I am Sarah Durham, and I am going to briefly introduce my colleagues. They will talk a little bit more in a minute and also we’d love you to introduce yourself as people start to arrive. If you are comfortable doing so, you’ll see a chat panel. And if you could chat in to us your name, the name of your organization, your pronouns, and where you are, where you are geographically, so who you are and where you are, would be great. Theresa, you want to say hi. 

Theresa Gutierrez Jacobs (00:50):

Hi, I’m Theresa Gutierrez Jacobs. I am a project manager at Advomatic. And for today, I’m going to just quickly chat my email. If you have any, I don’t know, tech issues or questions or anything like that, that is more tech related to this webinar. Feel free to reach out to me via my email. Otherwise, you can always chat or ask questions, particularly for this webinar here. And Dave, you want to say a quick hi, before we get rolling.

Dave Hansen-Lange (01:18):

Hello. I’m Dave Hansen-Lange and where I am, I’m about an hour from Toronto. I’m the director of technical strategy at Advomatic. I’ve been with Advomatic for about 13 years. And I’ve been doing work with nonprofits in the web for maybe about 15 or 17 years.

Sarah Durham (01:42):

Okay. So we’ve got a bunch of people who are already with us, a few more people who might join us in the next couple of minutes, but just to keep the ball rolling and use your time thoughtfully, we’re going to dig into our content for today. And as I said a little bit earlier, I will reintroduce myself. I’m Sarah Durham, I’m the CEO of Advomatic and also Advomatic sister agency, Big Duck. Some of you may have noticed that the Zoom we’re using today is a Big Duck/Advomatic shared Zoom. So if you’re wondering what the connection is, there’s some common leadership across both companies. For those of you who might know Big Duck, but don’t know Advomatic, Advomatic builds sturdy sites that support change. We build, and we support websites in Drupal and in WordPress. And Advomatic has been around now for, I think almost 15 years, although it’s partnership and collaboration with Big Duck and my coming into the company is relatively new.

Sarah Durham (02:43):

It’s about, I’ve been in it about two years. And so Dave is going to really take us through our topic today. And Dave, you could advance to your next slide, if you would like, which is this, what should you do with your Drupal 7 website? So Dave’s gonna talk us through why this is an issue and a few other things in a minute. What I am going to do throughout this conversation is I am going to be monitoring both the chat that you can see in the bottom of your screen, a little button that says chat. And if you click on that, you have the ability to either chat privately to the panelists. So if you want to ask a question confidentially, or you don’t want everybody who’s here to see it, just chat to the panelists and only Dave and Theresa and I will see it.

Sarah Durham (03:26):

If you want to chat to everybody and share who you are, like shout out to Rick, who’s already done that. He’s from the National Council of Nonprofits and he’s in the DC area. If you want to share your information with the panelists or to everybody, you can chat to all attendees. Also, you have the ability to specifically ask questions. There’s a Q&A feature in Zoom Webinar. And that will give me the ability to keep an eye on your questions. And some of them I can type back to you and others will be addressed verbally. So throughout the presentation, I’ll be monitoring all of that and we will address your questions perhaps as we go on, certainly at the end if it doesn’t make sense to do so in the webinar. So don’t hesitate to chat, don’t hesitate to ask questions. We are recording today’s session and Theresa will be sending out an email with a link to that recording and the transcript and the resources we’re mentioning later this week or early next week. So you will have all of this and you can share it with any colleagues if that is useful. So with that, we are going to get rolling over to you, Dave, and thanks, Theresa.

Dave Hansen-Lange (04:44):

Okay. Thank you, Sarah. All right. So to kick things off before we get into the details of all the different things that you can do with your website and what might be best for you I thought we should start with some backstory about like, why we’re at this spot and like, what does end of life even mean? Like, it’s software, how can software… and it really all comes down to security. And just to explain a little bit about how security in Drupal works, there is the Drupal security team, and that’s a team of about a dozen people all across the world. And then there’s a group of people even wider than that who contribute things to the team and say, Oh, this could be a problem. We should look into this. And people on the security team, you know, a lot of their time is paid for by their employers or their clients, but a lot of their time they’re just volunteering for free.

Dave Hansen-Lange (05:50):

And you know, there’s a lot of commitment there. Like, they have weeks on call and stuff like that, because security is very important to the Drupal community. And so we don’t want to have those people working forever for free. So the Drupal community at large has decided, okay, thank you for your time of service, people on the Drupal security team, we will let you go after this date. Some of those people work on AAA too. But people are generally committed for like Drupal 7. And so the original date for the end of Drupal 7 was going to be November, 2021. But then COVID happened and the Drupal community decided, okay, there’s this extenuating circumstance. We’ll give everybody one more year to figure out what they’re going to do. So now that the end of life date for Drupal 7 is November 2022, two years from now. 

Dave Hansen-Lange (06:56):

Drupal 8, just as an aside, it’s not really what we’re talking about today. Drupal 8, the end of life is November 2021, a year from now. That’s not what we’re talking about today. And thankfully, if you do have any AAA sites, the situation is a lot simpler. And if you want to get into that a little bit more possibly we could at the end of the presentation. Okay. So today we are going to first cover: these are the options that you have in dealing with your Drupal 7 websites. Then we’re going to look at some example scenarios. And by that, I mean like, okay, here’s an organization, they have a website like this, and because of that, they might consider scenario x. And then I’m going to pass things over to Sarah. And Sarah is going to dive into more of the organizational things, like, how do you plan for this and how do you work with this within your organization? All right. 

Sarah Durham (08:15):

Hang on one second, Dave, before we dig into this, I also just want to remind everybody feel free to chat in questions and comments as you go, and we’re going to take pauses in between each of these sections. So if you have, as Dave goes through the options, if you have a specific question about one of the options, and it seems like it’s universal to some of the other people who are participating today, I’ll probably pop in and ask that otherwise we’ll save Q&A for the end. Alright, sorry for the interruption.

Dave Hansen-Lange (08:41):

No, no, all good. I’m also going to be muting every now and then to take a sip of tea. I’ve got a sore throat. It’s not, COVID, it’s just a cold. And yeah, so I’ll be pausing too, as I go. Okay. So what are your options? So I’ve grouped these into four main options, and these are listed in terms of most expensive, to least expensive, most expensive option being start from scratch and build a new website for most people with a Drupal 7 website your main options are move to Drupal 9 or create something in WordPress. There’s some other options that you might consider, but those are the two that are applicable to most people. Option B is upgrade to Drupal 9 and immediately you’re probably thinking what is upgrading to Drupal 9? How is that different from building a website and Drupal 8? And I’ll explain that when we get there, another option is to switch to something called Backdrop. Many of you have probably never heard of Backdrop. And so I’ll start us out by what exactly that means. Or you could just stay on Drupal 7. And even though it has end of life, that there still are ways to keep going on, on your Drupal 7 website.

Dave Hansen-Lange (10:15):

So moving to a new website like I mentioned the main options for most people are Drupal 9 or WordPress. And so just by saying those two names in the same sentence, we immediately get into the topic of like what’s better Drupal or WordPress and what is right for me? I will touch on this a little bit now, and sort of back up a little bit and say that for starters, it’s really hard to make an unbiased and fair assessment of the two. But in a general sense, Drupal 9 is really great for people that, or on websites and organizations that want to do something a little bit more complicated, a little bit more ambitious, a little bit more technological, with more moving parts. And WordPress is generally more applicable to the organizations whose website, in many ways might be similar to other websites. And yeah, that is a little bit vague. I don’t want to dive too deeply into this topic right now. 

Dave Hansen-Lange (11:54):

If you want, we can come back to this in the Q&A at the end. And we also have another webinar that we did a couple months ago on this topic more generally. And if you’re just, if you can, we can send along a link to that as well. One last thing on this, though, I will say that when most people compare Drupal and WordPress, they’re not really comparing Drupal and WordPress, they’re comparing the website that someone built for them in Drupal or the website that someone built for them in WordPress. And because of that, they’re often comparing the skills of those people who built the website and not necessarily the underlying technology. And that’s part of the reason why this is such a sticky, thorny issue with a lot of people being on one side or the other there about moving to a new website. You don’t have to do the whole entire thing. You can find ways to do this in bits and pieces. I’ll show some examples of that later, but we’re at this point of rethinking what should we generally do with our Drupal website. It’s a great time to think, okay, this section, do we need it anymore? Should it be here? Is there a better way to do this then when we created this website however many years ago?

Dave Hansen-Lange (13:30):

Since many of you may not have seen modern Drupal I’m going to show you, or we’re pressed, I’m going to show you some slides here. So on the left, what we see is I am editing a page on a website and I want to add a new component which is a common term that we use these days, a new component to the page. I can browse through this library of available components and then add one.

Dave Hansen-Lange (14:00):

Or how it’s going to appear on the page. There’s many ways to do this in Drupal. Drupal is kind of known for having many ways to solve a problem. What we see in this screenshot is a tool called paragraphs. That’s a tool that we’ve been using for this problem pretty successfully on several websites. There’s other tools within Drupal 9. You may have heard the term layout builder and there was a couple of smaller ones as well on the right side. We see the administrative listing of all the content on your website for each site, it’s going to be a little bit different, what you decide to list here. But this is just one example of how it looks and comparing this to WordPress on the left. This is also how WordPress looks when you want to add a new component to the page. And so the right column there, we see, the available components that you have, again, on the right, a screenshot that’s WordPress of a list of all the content on the website.

Dave Hansen-Lange (15:20):

Looking at these two sets of screenshots, there’s a couple things that might sort of immediately come to mind. WordPress, the administrative interface generally looks a little bit more polished.

Dave Hansen-Lange (15:39):

In some ways WordPress can be a little bit all over the place in that each plugin or each new thing that you add to your website tends to design things its own way and do its thing its own way and it’s WordPress. Compared to Drupal, each new thing works in a very consistent manner. So it’s easy to move around from section to section on the website. All that to say is really either is probably a big step forward from where you are with your Drupal 7 website.

Dave Hansen-Lange (16:18):

All right, so which Drupal 7 website is this going to be most applicable to, or maybe you shouldn’t at all consider this option? If you are really frustrated with any part of your website, be that like how the content of this is organized, or just the general backend experience the design of the website, if there’s anything about it that you’d just want to just toss and start again fresh, this is a good option to consider. But like I mentioned, when I listed these four main options, creating a new website is going to be the most expensive of the options. And in the age of COVID, many of you are probably dealing with some tight budgets. So one of the other options may be the better choice. Also, this might not be a good choice for you if your existing site is very complex. And one way to think about this is like you built your website so many years ago, let’s say it was five years ago. And you put all this work into doing that initial build, but then over those five years, you’ve also put in some work, to make the website more and more better. And in this new version of the website that you’re gonna create, you want to encompass all of that. 

Dave Hansen-Lange (17:52):

It’s going to be a pretty big project. And so it’s just one way to consider looking at your options.

Okay. Option B, I don’t have a handsome, single flat you can upgrade to Drupal net. So how is this different from just creating a new websiteIn AAA? Drupal 9 has these built-in tools that can take your Drupal 7 website and take all those, all that content, all the content structure all the menus, everything that’s stored in the backend of the website and upgrade it and make it work in a new Drupal 9 website. But what you don’t get is any of the, how that content is presented to visitors, all of that stuff. If you go through this upgrade process, you still need to come up with or you still need to rebuild the way that it’s presented to visitors. Maybe, maybe you’re happy with the design of your Drupal 7 website. And so you can just redo that same design in Drupal 9 or another option since we’re here and we’re creating a new website and Drupal 9, you might want to take advantage of that and do a new design.

Dave Hansen-Lange (19:31):

And so, because of all those things, it’s going to be still a big chunk of work, not as big as just doing a clean slate and starting from scratch. But still a lot of work involved. One thing you do need to look into before you get too far down this road is like, are there any ways in which we solve the problem in Drupal 7, that just there’s no equivalent in Drupal 9. And that has sometimes happened because the Drupal 7 way of solving a problem, one example would be locations. Let’s say you got a content type in Drupal 7 called offices of your organization and they’re storing their address and location. That’s almost certainly done in a very different way in Drupal 9. And there isn’t a way to directly go from one to the other, at least not directly in the same sense of this upgrade process that I talked about before. There may be these situations like that, and you’ll have to do something custom or something else. That’s a little bit more complicated. It’s just important that, you know, these things happen upfront before you get into moving down this road.

Dave Hansen-Lange (21:00):

So who is this good for? I mentioned, you’re going to get the same stuff in the backend as you have now. So it’s, if you’re happy with that, great, consider this option. I mentioned that the visual presentation, you’ve got to redo that. So if you want a fresh design, this might be an option for you. Again, avoid if budget is tight, like I mentioned, it’s still a fairly complicated procedure. All right. A third option is to switch to Backdrop.

Dave Hansen-Lange (21:39):

So Backdrop, I said earlier that your main options are WordPress or Drupal. What’s this, what’s this new Backdrop thing? Backdrop is kind of like a different flavor of Drupal. And in the technical parlance, Backdrop is a fork of Drupal 7. And what does cutlery have to do with software? Absolutely nothing. So by fork, we mean fork in the road. You may know that Drupal and WordPress are open-source software. And that means that anybody, anybody really who has the time available to do it, can jump into the project. You got a problem with the way something works, you want to make it better, you can just do that and you can contribute something and get it rolled into the software. But what that also means is that if you don’t like how something works, you can just take it, copy it, and roll with it.

Dave Hansen-Lange (22:42):

And that’s what’s happened with, with Backdrop so well. Drupal 8 was being developed. There were many people in the community who thought, “Oh, no, like Drupal 8 is looking great and all, but it’s going to be really hard for websites that are on Drupal 7 to get to Drupal 8 and whatever it comes in the future. And they were right. That’s, that’s why we’re here. That’s why we’re having this webinar. And so what they did was they took Drupal 7, copied it, called it Backdrop and started to evolve it and evolve it in some of the same ways that AAA has evolved only keeping with the Drupal 7 way of doing things and the Drupal 7 styles. And so you have an option to take your website and sort of just take that fork in the road and start moving down the Backdrop trail.

Dave Hansen-Lange (23:42):

What this is going to look like for your website is that you’re still gonna have the existing content structure things in the backend of the website, just like that, upgrading to Drupal 9 option. It’s all going to look very similar, if not identical, but different from that upgrade to Drupal 9 option. You can still keep the visitor-facing portion of the website. If it’s going to need a little bit of tweaking to get onto that Backdrop fork in the road. But that is going to be relatively much smaller, a much lighter lift. Not to say that you must keep your existing design, you can make some changes and revisions. You might even consider doing a full redesign. But yeah, you don’t have to, as you’ve heard me describe this, you may be thinking fundamentally that the steps involved, it’s pretty similar to the upgrade to Drupal 9.

Dave Hansen-Lange (25:00):

It is, but still, it is almost certainly cheaper than upgrading to Drupal 9. And mainly the reason is because like I mentioned, it is just Drupal 7 evolved. So the changes that you have to make to your existing website are just immensely smaller, some increased risk. So what I mean by this well, like anybody who works with websites for a nonprofit is probably going to know WordPress, and probably getting to know the word Drupal, probably not going to know the word Backdrop, because it is such a much smaller community. Where there might be that there’s about half a million Drupal websites out there. There may be like a few thousand Backdrop websites out there. And because of that, there’s enough momentum in the community that we know that Backdrop will be here for two years, maybe four years, but it’s harder to sort of see deeper into the future. Whereas Drupal, you know, half a million websites. We know it’s, there’s a lot of people working on this, a lot of organizations, big and small, it’s going to be here for probably at least another 10 years, if not longer. Backdrop, much smaller community. There’s just not as much certainty about the future. 

Dave Hansen-Lange (26:44):

But with that said, Backdrop has committed to like the same sort of upgrade structure that Drupal 8 and Drupal 9 have committed to being. We’re not going to do a huge change again in the future. We’re going to make all these incremental changes that will make it much easier for you to stay up to date and evolve your website over time.

Dave Hansen-Lange (27:12):

Great. I thought it important to show some visuals about what Backdrop looks like and looking at these, you might be thinking, “Oh, this looks pretty similar to my Drupal 7 website, but the colors and fonts are more contemporary”. And you are a hundred percent correct in thinking that like I mentioned, it really is Drupal 7 evolved. But there is more to it. There are some easier things on the technical side of how to work with Backdrop compared to Drupal 7. There’s some different ways of managing page layouts. There’s other new features in Backdrop that Drupal 7 doesn’t have. But the thing is, if you take this sort of upgrade from Drupal 7 to backdrop trajectory, you’re not going to get those things all of a sudden. If you want to take advantage of Backdrop’s fancier ways of laying out content on a page then you’re going to have to have a small project to enable that feature. At first, you’re still going to be working in the same paradigms as you are with Drupal 7. So who is Backdrop great for? Anyone who has a lot of custom code. I was talking earlier about like, why you might want to avoid building a new website and Drupal 9 is if you’ve got a lot of custom stuff. Here in this option, and this would be a good option for you because all that custom stuff probably doesn’t need to change very much, probably needs to change a little. But if it’s not going to be all that significant, this is a good option for you.

Dave Hansen-Lange (29:16):

If you are happy with your existing design that’s going to need a little bit of touch-ups to move to Backdrop. I was trying to be consistent here and come up with a reason why you should avoid Backdrop. I couldn’t really come up with one. I think everyone should at least consider this option. It’s kind of like the middle of the road option. You might not choose this option if you’re wanting to do a full redesign, but if all the rest of the things line up for you, then you could do a full redesign in Backdrop. It would be fine. I guess the only reason that I can think of now is that if you are super concerned about keeping the website that you have the same fundamentally as it is now, four, five years into the future, 7 years into the future—because the future is a little less defined for Backdrop—you may want to avoid it in that case.

Dave Hansen-Lange (30:35):

All right. And the last option stay on Drupal 7. I mentioned even though Drupal 7 has reached end of life, there are ways to continue on with it. If you had any websites that were on Drupal 6 and you were in this sort of situation for Drupal 6’s website, when it reached its end of life, there was a program started called the extended support for Drupal 6. This Drupal 7 version of that program is fundamentally identical. And what this is is that I mentioned that many of the security team are volunteering their time. And so this program gets around by trying to force people to volunteer their time by saying it’s a paid program. The Drupal community has vetted several Drupal agencies to offer this extended support service. And what that means is that as security issues come up, maybe there’s a security issue that comes up in Drupal 8 that might also apply to Drupal 7 this, this team of extended support people work on fixing that problem in Drupal 7.

Dave Hansen-Lange (32:11):

And so there’s kind of two ways to take advantage of this: Number one, you sign up with one of the extended support vendors. You’ll be able to find that list through some links that we’re going to send at the end. One of the mandates of this is that they release all of their fixes publicly. It’s happened for Drupal 6 as well. And so if you are technically savvy or you’ve got someone at your disposal who’s technically savvy and can sort out the details and apply these fixes as they come up, this could be a good option for you, too.

Dave Hansen-Lange (33:08):

I think it’s important though, to like, take a step back at this point and talk about why you might think about security in different ways. And one way to think about security is kind of like two groups of websites on the internet—those who security is really important for, for whatever reason. Maybe they’re doing something that some people find controversial and they have people who are trying to hack into their website. Maybe you are processing credit cards on your website and you, you know, someone might want to try and break in and steal those credit cards. Maybe you are a news outlet and you get hundreds or hundreds of thousands of people viewing your content every day. And if someone could break in and get some sort of message out to those people, that might be an incentive as well. So that’s like one group of websites, people who have some sort of special security concern. And then there’s kind of everybody else—everybody who knows that security is fundamentally important, but it’s not more important than it is for everyone else in this group.

Dave Hansen-Lange (34:33):

It’s just the nature of how I described that most organizations are going to be in this group where security is important, but not more important than anyone else. Some are going to be in this heightened group of security. And for those people, they need to think about things more than just like, am I getting the bare necessity basics? Or am I really doing all that I’m responsible for ensuring the security is as good as it can be. And for those people, this may not be the best option in that you’re not on the most recent and currently secure thing you were on, this thing that’s on extended support. And whether that rationale is purely technical, or if it’s purely optics in that if something were to ever happen to your website and it was discovered, “Oh, they’re running this version of Drupal that was created 10 years ago”. 

Dave Hansen-Lange (35:38):

How can that be responsible? And then there’s all sorts of politics involved. I mean, it’s a situation you want to completely avoid, but for those of us who are in the group of security as important, but not more important than anyone else, this can be a very reasonable option to consider. So stay on Drupal 7, if you have a really tight budget. And I admit that budget is in the eye of the beholder. For some of you a roomy budget would be a tight budget and vice versa. Like I was talking about, if you don’t have any special security requirements avoid, if your site needs a facelift or if you’re frustrated with the backend. So like I mentioned, this is keeping the same website and keeping it the same. And so if you want to rip something out and try again, this is probably not the option for you.

Sarah Durham (36:56):

Okay. So, Dave, I’m just going to jump in here for a second before we continue with your sample scenarios. We’ve got about 20 minutes left in our time together, so we’re going to need to move pretty quickly through our sample scenarios and through the make a plan section. But we did get a really good question that I’d love you to try to answer for us before we continue on. It’s from our friend, Rita, and Rita asks, if you choose to migrate or upgrade to Backdrop, what would that mean for your future options to upgrade to Drupal 9?

Dave Hansen-Lange (37:29):

I don’t think it really changes the landscape for that at all. Whether you’re upgrading from Drupal 7 or from Backdrop, it’s fundamentally the same thing. It is technically almost identical and that’s because well, Backdrop has gone on this new trail at a foundational level. The way the content is stored, it’s fundamentally the same. And so if you want to pull that content out of either version of those websites into a new Drupal 9 website, it’s going to be the same process. That could change though, as it’s a fork in the road. So Backdrop could go further one way, while well, Drupal 7 is not moving anywhere at this point, but it could continue to move on in a way that’s more different from Drupal 7. But in my opinion, it’s unlikely to change all that much for the foreseeable year or two.

Sarah Durham (38:37):

Okay, great. So, so back over to you.

Dave Hansen-Lange (38:40):

Okay. So like I mentioned, those options, they were great in theory, but now let’s try and put some of this to practice. I’m going to show, I think, four, maybe five example websites and what is unique or different about those websites and why they might choose one option over the other. As you’re looking through this, you might think, “Oh, that’s nothing like my website”. But I’m going to try and pull some things out here that hopefully are going to apply or at least show some things that you should consider. And you also might recognize some of these websites. Don’t focus on that. We’re going to focus on what is it about these websites? I’m also not going to tell you anything about these websites that isn’t something… Sorry, everything that I’m going to tell you about these websites is something that you could just go to the website, look at and figure out for yourself.

Dave Hansen-Lange (39:45):

So there’s not going to be any sort of like private information here that I’m gonna show either. So in this first example, we’re going to look at the ACLU. On the left here, we see what their website homepage used to look like. On the right side, we’re going to see what the homepage looks like now. And the prior version of the website, that was Drupal 7. The homepage, and I say that specifically, the homepage, is now WordPress. You may remember back when I talked about the option of creating a new website that you don’t have to do the whole thing. Here’s just the homepage. And they’ve actually done the same thing with the blog section. It used to be Drupal on the left. Now it’s WordPress on the right. You don’t have to do with everything.

Dave Hansen-Lange (40:44):

So this is an example of a case on the ACLU website. And like, this is just one really long page here that is cut up into three pieces. See at the top, this is all just fairly straightforward content. But then in this section, things start to get more complicated. Like there’s all these other bits of content elsewhere on the website that are related to this case. That’s something that you can do in WordPress, but the more complicated those relationships get, the more awkward it gets to do in WordPress. Then down here at the bottom of the page, things get super complicated. Visually it doesn’t look too bad, but that’s because I think the design was done well. There’s hundreds of legal documents that relate to this case, all in these groupings and hierarchy and get super complicated. WordPress is not the best tool for this kind of job. And so this part of the website is still on Drupal. It’s still going to be on Drupal for now. It might evolve in the future, but that’s where it is for now.

Dave Hansen-Lange (42:03):

Another section of the website, there is this sort of intermediary thing where you could show an action within like an article or a blog post or something to say, “Okay, come take this action”. And during the redesign or in moving bits to WordPress, you know, if you’ve stepped back and thought, is this useful? Is this complicated? Is there a way to do this simpler? And this sort of intermediary thing was just checked and now there’s just links to actions and there’s other ways to show actions without this complicated section of the website. Please consider for your website: What should I get rid of? There’s almost always something. 

Dave Hansen-Lange (43:11):

Looking at a different organization, here is one that’s a Drupal 7 website. But you might be thinking, “Oh, this design, it looks fairly current”. And you’d be correct because this organization went through a redesign, I want to say, like, two years ago. And so because of that, looking at those four main options, they can probably throw the create-a-new-website option out because the design still looks great. As long as they’re happy with how the content works on the backend, they could really choose any of the other three options. And, yeah, so consider that.

Dave Hansen-Lange (43:47):

Next, we have a municipality. When I was talking about the option of staying on Drupal 7, that’s maybe not the best option for a municipality in the news all the time. We hear stories of like such-and-such municipality, their website has been hacked, or their computer systems have been taken over by ransomware. And so just the optics of staying on Drupal 7 might not be the best choice for them. The design looks, doesn’t look as fresh as those first two options that we showed. But let me guess a municipality kind of has different requirements in that the number one goal is not a flashy design, it’s getting information out to its residents.

Dave Hansen-Lange (44:32):

And so there may be a way for them to choose one of the non-design related options. And at the same time, maybe consider how it can do any sort of restructuring to better present the information that people need to find. Here’s another organization. In looking at the screenshot, you might be thinking the same things that this organization thinks about this website and that the design is very text-heavy, and it is not quite as engaging as they would really like it to be. And so for this organization, one of the first two options is probably the best choice: creating a new website completely or upgrading this to Drupal 9 with a new design.

Dave Hansen-Lange (45:43):

Lastly, we’re going to look here at, this is not so much a website, but a web platform. AFT has 1,300 websites on this one platform for States and Locals within a state. And the center one up top here, this is for a campaign website. And this is an example of a few things: One, it’s not their primary website, it’s not aft.org. And so if you’ve got more than one website, you don’t have to choose the same option for all of them. You can choose different options. Number two, there’s a lot of custom stuff involved here, as you might imagine. Some stuff around creating a new website, around connecting the information altogether. So because of that, you might lean more to one of the options that works better for custom stuff and doesn’t require recreating all of their custom stuff in a brand new website.

Sarah Durham (47:07):

Thank you, Dave. So a quick question, before we talk about where you go from here. Just want to confirm the ACLU, the sections of the ACLU site that are still in Drupal, or are those WordPress? 

Dave Hansen-Lange (47:22):

That is in Drupal. Yes. 

Sarah Durham (47:26):

Okay, so Dave is going to be advancing some slides for me. So I will ask you, Dave, to go onto the next slide. And basically, before we flip over to your questions and discussion, and in the remaining time we have together, what I want to get you thinking about is how to make a plan. And it’s interesting we’re doing this today because actually I had a call with somebody at a higher ed institution this morning, who’s got an old site and they are debating what their options are. They were describing a lot of feelings of being overwhelmed. I think that, you know, these days with the reality of what’s going on in the world with COVID, with elections, all that kind of stuff, tackling these kinds of big projects is feeling pretty daunting. So I wrote an article about planning and we’ll share links to that article and a bunch of other things.

Sarah Durham (48:20):

Dave has also written a really helpful post about Drupal 7’s end-of-life. At the end of this webinar and also in the follow-up email, we’ll send you one of the things I wrote. The first step is to make a plan and you don’t have to have all the answers. You’ve just got to begin by getting your team on the same page about the implications. I think that’s one of the big barriers that a lot of people are facing is that they’ve got these Drupal sites and there is a real challenge coming up, a real cliff coming up for many of you that you’ve got to begin to get your team aligned around so that you can budget and plan appropriately. Next slide please, Dave. So I recommend that you come up with a plan, which you could do in five slides or in two pages.

Sarah Durham (49:05):

And the intention of this plan is actually to give you an internal document you can use to get your team on the same page and build some buy-in. So you can see first you’d start by outlining the situation. I think we’ve given you some of the ammunition for that conversation and in today’s session or in the articles we’ll share with you, and what the risk is to your organization. You might want to outline some options if it’s clear to you and the people on your team where you should go from Drupal 7. You might go forward with outlining some options or making a recommendation, but honestly, if you’re not sure which way to go, a good partner should help you get there, too. So if you don’t have the answers already in mind, if it’s not clear to you which way to go, it might be that you map out a few options.

Sarah Durham (49:52):

But your recommendation might be more to find a partner to help you navigate that. Of course Advomatic can do that. We would love to help you make a decision about this, and we do regularly do that as part of our work. There are many people you could work with who could do that. I think one of the things that’s also really important in your plan is mapping out a timeline, not so much for the build or the upgrade that you might do, but all the things leading up to it. If you are looking ahead and thinking what you really need to do is rebuild your website or do a significant upgrade, that’s going to take time and a lot of work, and you’re going to want to get your team on the same page about when the budget needs to be approved, and when you’re going to get rolling so that you’re doing it hopefully well in advance of some of the deadlines that are going to be important within your organization and within the Drupal 7 end-of-life timeline.

Sarah Durham (50:49):

You know, in the non-profit sector, one of the key pieces that is in my experience kind of do-or-die for many big projects is building buy-in. So with that plan in mind, I would encourage you to have some conversations, share it, get it into the budgeting process and kind of keep it alive because very often you know, you mentioned these things once or twice, but there’s so many things going on that are taking up so much attention and energy for the leaders of organizations today that I think you’re going to have a little bit of work to do to keep it alive, which is the next step. My next slide. Also, keeping it alive is about not just writing this plan and sending it to people, but keep nudging and keep bringing it up. If you know what your milestones are when people are talking about budgets or budgets are getting approved, you know, those are great opportunities to research, collate your plan and go from there.

Sarah Durham (51:47):

Now, many organizations that we work with and talk to are already doing this, and they’re already talking to us and other people about what they’re doing. And a partner can also help you figure out your timeline. So there are a lot of ways to do this. You don’t have to do the heavy lifting on your own. But what you don’t want to do is you don’t want to wait until you’re, you know, a couple of months away from these deadlines if they pose significant risks or implications for your organization. So we have a few minutes left to go before the top of our hour. And I want to hear a little bit from you. So if you’ve got questions or comments, you can either use the Q&A feature, which you will see at the bottom of your screen, or you can chat them in to Dave and I, as we go. And we’re going to stop sharing our screen. Now we’ll take a few questions and while you chat those in, I also want to just remind everybody that we are going to be sending out a follow-up link to the recording here. And Theresa is also going to chat out a couple of the articles we mentioned. Dave has written a really helpful article about D7 end-of-life. He’s also written an article about D8 and there’s an article I’ve written that’s about how you, how you plan for this change. So Theresa will chat those all out.

Sarah Durham (53:17):

Okay, Dave, first question for you. Somebody is chatting in about administrators and they’re thinking, well, actually, this is sort of a double-barreled question. Let’s take it in two parts. First in option A, you talked about building a new site as option A. You specifically talked about WordPress and Drupal. Both of those are open source technologies. Why are you talking just about WordPress and Drupal and not any other systems?

Dave Hansen-Lange (53:46):

One of the things that I also talked about was like, kind of the momentum of these projects, like Drupal is large. WordPress is ginormous. And there’s lots of movement in those projects. There’s lots of momentum as soon as someone has a new idea or a new technology pops up on the internet, like things move quickly. And there’s a way to do it on your website in short order. And I also talked about the security group, that’s not the official title, but like there’s ways like that in which you’re getting the benefits of someone else volunteering their time for your website, which you just don’t get in in some of the other options that you have.

Sarah Durham (54:37):

Okay, thank you. And the second part of this question was about comparing WordPress and Drupal about administrators and the options there. This person is talking about how there’s lots of different people in their organization, who right now have different layers of access in Drupal 7. And they’re wondering if there are any recommendations you have for new platforms based on that kind of complexity.

Dave Hansen-Lange (55:01):

Yeah, so like the area of editorial permissions and controls, like that’s one of the big differentiators between Drupal and WordPress. WordPress has some basic systems around this role can do this, or this role can do that. In Drupal, we can make things a whole lot more complicated, like people who manage this section of the website, they can upload images. Other people can use those images, but only the original group of people can edit them or ways of more complicated things that you can do in Drupal.

Sarah Durham (55:38):

Okay, so there’s a question here about the difference between a Drupal new build and a Drupal upgrade in terms of cost. And actually, would you mind just bringing it up again, cause somebody chatted to me that they arrived a bit late and they didn’t see your slide. I think it’s your slide number six, which outlines all the options. Let’s just quickly go back to that slide for a second and share that. And I think that the question that just got chatted into me relates to this. So on slide six, you mapped out a bunch of different options ranging from building a new site to staying on Drupal 7. And those were ranked, as you talked about them from most expensive to least expensive. So you said building a new site is the most expensive, staying on Drupal 7 is the least expensive, and then the upgrade or the switching to Backdrop were in between. So the question is about the cost differential between building a new site in Drupal 9 and upgrading in Drupal 9. I assume that there are additional costs for design, for UX, things like that, and building a new website, but how significant is that differential? What other variables inform the cost difference there?

Dave Hansen-Lange (57:06):

Yeah, so I talked about sort of in any of these higher options… well, no, let me rephrase that. In the two middle options, you have the option of how much redesign you want to do, of course. And that’s probably the biggest thing that affects how big or small upgrading to Drupal 9, that project is going to be. But let’s say you wanted to redesign and compare upgrading to Drupal 9 versus creating a new website in Drupal 9. It’s difficult to be put on the spot, but I don’t know, 80%, 90% since you’re doing a full redesign. Upgrading to Drupal 9 and moving to a new website, they start to become more similar. The more you’re redesigning, the similar in cost.

Sarah Durham (58:01):

Okay, thank you. That sounds like what we were expecting. So I am just skimming through your questions and it looks like a couple of other questions that we have here are pretty unique to specific organizations, so I’m going to follow up directly with those organizations since we are just about out of time. I want to thank Theresa and Dave for joining us today. Dave, thank you for imparting your wisdom on this topic. And I want to thank everybody who took the time to log in and watch this. I hope this has been helpful for you. If you have specific questions or concerns or things you want to pick our brain about, you can always email us at [email protected] or [email protected]. We’d be happy to get on the phone with you, talk a little bit about your situation if that is of use to you. And again, Theresa will be sending out a link to these articles and the recording to you in just a few days. So thank you, all. And thank you all for the excellent work you do to make the world a better place. Be well, thanks.

Sep 30 2020
Sep 30

Our Drupal contributions history

Srijan has been part of the Drupal community for over 12 years. From very early on, we (Srijan) have been contributing to the Drupal project in multiple ways, from sponsoring nearly all DrupalCons since 2013, to regularly contributing code to core and contrib projects.

Many of our people have been mentors for new contributors at DrupalCons and local meetups. For the past 2-3 years, we even had a dedicated open-source community manager within the organization.


One of the earliest Drupal.org media case studies, published in 2009

Due to the COVID pandemic, we had a fairly large bench earlier this year. Given this, we decided to create three dedicated contribution teams to leverage this time efficiently and increase our contributions. During the same time, Drupal India Association (DIA) had set out a big-hairy-audacious-goal (BHAG) of putting DIA among the highest contributors globally.

Years of contributions and the above 2 events improved our overall ranking in the Drupal marketplace.

Where we fell short

Highly motivated by the dual goal of putting DIA on the marketplace and improving Srijan's ranking in the marketplace, some of our team members digressed from the objective and started "gathering contribution credits".

Soon we realized that out of the 25 contributors, a few were making mistakes like "assigning/unassigning issues without comments", or "submitting duplicate patches", meanwhile gathering credits intentionally or unintentionally in the process.

We acted immediately, realizing our mistake that we had not conducted a D.O "contributions code of conduct" training — as most of them were first-timer contributors.

We asked some of our seasoned contributors to organize a code of conduct training. These contributors led an internal training session to reiterate the Drupal code of conduct as well as build an internal best practices checklist for contributors at Srijan.


                        A screenshot from the training session

While this session helped in improving the quality of the contributions, we still noticed that a few people were not following all the best practices. Community members were still tagging Srijan and registering their complaints…we acted again.

This time we ‘painstakingly’ made a comprehensive report to identify the key issues and the defaulters.

The following unhealthy practices were identified and each team member was evaluated against these-

  1. Assigning/unassigning without comments
  2. Hopping/hijacking issues - i.e.,not reading the issue history and submitting incomplete patches
  3. Submitting duplicate patches
  4. Incorrect patches, or patches without comments/screenshots

Self-evaluation form filled by each team member, against each issue worked on

This detailed evaluation process took about 2 weeks to complete but helped us address the quality issues. These evaluation sheets will be maintained regularly going forward.

Conclusion

With the above steps, we eventually succeeded in putting a stop to the breach of the ‘code of conduct’ by a few overzealous (or careless) contributors.

We should have done a "code of conduct training" and set up a monitoring system so that we could have avoided these incidents. But that’s the benefit of hindsight.

On behalf of Srijan, I would like to apologize to the Drupal module maintainers and core contributors (including other Srijan contributors) who had to face unnecessary challenges due to some of our nonchalant actions.

Srijan is and will remain among the leading contributors to the Drupal community and a responsible one at that.

The purpose of this post is to address our problem of being tagged on Slack in the Drupal group, rectify them with the right practices, and share this learning experience with others to help them avoid these slip-ups.

I would like to end this post by highlighting some of the positive attention that Srijan’s contribution teams have received during the past few months.

Sep 07 2020
Sep 07

In a typical scenario of staging or production, developers seldom have the option to use the debugger so they turn to the logging functionality to resolve system issues.

One of the most underutilized tools at the developer’s disposal, ideally, logs should be the first thing that developers should look at when trying to resolve a system error or spending time tracking down a gnarly bug.

This blog will walk you through the Drupal module, Monolog, that logs the messages of the site (words, errors, notices, & warnings) in the file to fix issues swiftly without impacting the site performance. Find out how it can be installed and how it works.

The ABC of Monolog Module

In a typical scenario, a module trying to log the debug information in the database table has to connect to the database every time, making the whole process tedious. Additionally, the gradual increase in table size starts hampering the site performance.

Contrary to this, another way of logging the site messages without impacting the site performance is by saving these messages in the file. Whenever the site will be down due to fatal errors, the messages can be checked from the log file.

Monolog is one of the modules in Drupal that saves messages (words, errors, notices, warnings) in the file to save the system from the overhead of buffering logs and network errors.A laptop showcasing Drupal logo and error

 The Monolog module integrates Drupal with the Monolog library to offer a better logging solution. It can send logs to files, sockets,   inboxes, databases, and various web services. In a nutshell, it allows you to define a logging pipeline. 

 When it logs something, it dispatches it along that pipeline to whichever files, services, emails, etc. you have defined.

Benefits of Monolog Module

It offers the following benefits

  • Enhanced system performance

Monolog logs system messages as per the defined file system/structure, thereby enhancing the overall performance of the application and system.

  • A multitude of handlers

The multiple handlers defined in monolog can be integrated hassle-free to send log messages into an email, Slack, etc.

  • Easy to install

The Monolog module is easy to install as it does not require any external library and server for configurations

  • Complete watchdog integration

The Monolog module consists of full watchdog integration, making it easier to work with core and contributed modules out of the box.

  • Configurable logging levels

The Monolog module is PSR-3  (PHP Standards Recommendation). As a result of which, it enables interoperability to help you change the logging library for another that implements PSR-3 without too much headache.

Why is Monolog Important?

Drupal core logging offers minimal features to developers for defining a log message type, “attention level,” and then saving all the log messages to a destination, usually Syslog; even when the logging can be redirected to another destination. All the log messages, including those where critical problems are listed, are stored at the same place with trivial logged information.

Whenever the site encounters an unexpected issue, site owners try to find the cause behind it. Though all the information is written to the log system by Drupal, it quickly gets overwritten with newer log messages on an active site. Once it happens, it becomes difficult to recover because they all stay in the same log stream along with PHP errors and warnings and all the other types of system logs.

This is why the Monolog module comes in handy. With it, you can send critical logs to email, HipChat, or NewRelic, normal logs to a persistent backend, and debug to a simple pre-defined log file.

The clear separation of information by concerns extensively improves access to the specific log information that is relevant and useful in any given situation. 

In fact, you can use this module to write operational logs related to the content and user actions to a particular stream so the site owner can gain access to that information instantly without going through all the unnecessary or irrelevant log messages.

At the same time, a system administrator can see all system logs on a different stream, and receive critical messages only via email.

How to Install the Monolog Module?

The monolog module can be installed by using the composer.

Black background with commands

The Monolog module does not have any configuration form in the backend, and all the configuration is done in services files. You can follow the below-mentioned steps for the same-

  1. Create a site specific services.yml (monolog.services.yml, for example) in the same folder of your settings.php and then add this line to settings.php itself:

$settings['container_yamls'][] = 'sites/default/monolog.services.yml';

 

2.   The simplest configuration that allows Monolog to log to a rotating file could be-

parameters:
monolog.channel_handlers:
default: ['rotating_file']
monolog.processors: ['message_placeholder', 'current_user', 'request_uri', 'ip', 'referer']

services:
monolog.handler.rotating_file:
class: Monolog\Handler\RotatingFileHandler
arguments: ['private://logs/debug.log', 10, 'monolog.level.debug']

3.  This configuration will log every message with a log level greater (or equal) than debug to a file called debug.log located into the logs folder in your private file system. Since data will be rotated every day, the maximum number of files that you can keep would be 10.

Role of Handlers & Processors in Monolog’s Functionality

Handlers are accountable for saving the message to the file, database, or sending it to a mail. In Drupal Monolog’s default monolog.services.yml, several handlers are defined, for instance, monolog.handler.browser_console, monolog.handler.chrome_php, monolog.handler.fire_php, etc. These are registered as services in the Drupal Service Container. You can define as many handlers as you need. Each handler has a name (that should be under the monolog.handler. namespace), an implementing class, and a list of arguments. 

Mapping among logger channels and Monolog handlers is done by defining parameters. Under the monolog.channel_handlers parameter, it is possible to determine where to send logs from a specific channel. The default mapping should exist as the fallback one. In the previous example, all logs were sent to the monolog.handler.rotating_file handler. 

Note -  Only the handler name is used instead of the full-service name.

The following example will send all PHP specific logs to a separate file:

parameters:
monolog.channel_handlers:
default: ['rotating_file']
monolog.processors: ['message_placeholder', 'current_user', 'request_uri', 'ip', 'referer']

services:
monolog.handler.rotating_file:
class: Monolog\Handler\RotatingFileHandler
arguments: ['private://logs/debug.log', 10, 'monolog.level.debug']

It method will write the corresponding message to the private://logs/php.log file.

On the other hand, a processor is a PHP callable used to process the log message-

monolog.processors: ['message_placeholder', 'current_user', 'request_uri', 'ip', 'referrer']

Monolog can alter the messages being written to a logging facility using processors. The module provides a set of already defined processors to add information like the current user, the request URI, the client IP, and so on.

Processors are defined as services under the monolog. processor. namespace. We can also use the Devel module or Drupal Console to find all of them.

'Message_placeholder': text of message

'Current_user' : logged in user

'Request_uri' : requested url

'Ip' : ip address of user

‘'Referer': url from where the user has arrived to the page.

code written in black background

How to log custom messages in a custom module using Monolog? 

To log custom messages, add the below-mentioned code in your custom module-

\Drupal::logger('php')->debug('debug message');

It will successfully write the corresponding message to the private://logs/debug.log file.

E.g 

\Drupal::logger('php')->debug('Data added using cron');

code written in black background

Conclusion

The Monolog module offers complete flexibility to help you capture the right information and leverage it for troubleshooting and monitoring. Once you have configured your applications to log all the useful information, you can send these logs to a platform where it can be used for in-depth analysis and collaborative troubleshooting.

Install the module for speedy development and resolve errors hassle-free.

Aug 17 2020
Aug 17

Contributing back to the community has always been vital in Srijan’s culture. We did take a back seat for some time like everyone in the industry; however, it was just a little pause. In the early days of 2020, we set some new year goals and community contribution was one not to be missed. As you read along, you would walk through our journey so far.

Status Quo Ante

In March, Srijan was on the first page of the Drupal Marketplace when we thought to initiate the contribution process. Simply put, we were holding a rank between fifteen to the seventeenth position.

While I started working as a Community Manager in the March-end, I was made responsible for improving Srijan’s ranking in the Marketplace.

Never had I imagined then that such a massive epidemic was at our doorstep.

Financial Q1 & COVID Hit

The COVID-19 pandemic that started in March-end led to the cancelation of all the upcoming events. Further, the extended lockdown worked as a catalyst for increasing the ambiguity among the team members on what to plan in future agenda and how long will it take to end.

An enormous number of employees were put on the bench as the project engagement reduced considerably across the globe due to COVID uncertainties. That’s when it struck us that we should leverage this situation to turn it into a positive opportunity for us. An opportunity where we can learn, improve our position in the Marketplace, and most importantly, don’t let Srijanites feel demotivated due to such unprecedented times.

See what we did to give our best-

  1. In the first week of April, we started anew by creating three teams for the time being and kickstarting our efforts to chase our end goal. 
  2. These teams were accountable for running contributions as full-fledged Projects (i.e., teams working in collaboration and performing all Agile ceremonies simultaneously) apart from an additional small group that focuses on contributions as an ongoing task.
  3. As we picked up our pace in mid-April, the team discussions took place following which there were some training sessions provided, and documentation was done for the newbies as well as for others to seek reference. 
  4. Gradually, the team started picking issues, and by the end of April, we were able to contribute satisfactorily, irrespective of the improvement in our rankings. However, this beginning made us feel content.

As said, hard work pays off; eventually, May & June proved fruitful for us. These were the months when the rank improved drastically, and we were now within the top 5 contributors in the Marketplace globally and at the top position in India.

Vertical bars of different colors and lengths-graph

The graph shows the number of patches submitted in total for different Issue types in May & June.

Not only did the teams were proficient by now, but we were also ready with the recorded training sessions and startup guide for the future newcomers to join. We traveled a long way to achieve our goal, but the journey was far more adventurous and taught us things that made our future brighter.

We learned in our journey...

While the teams had gained up to the speed of working for core issues, some unhealthy practices came into the light, such as too many comments on a single issue, or to & fro of assignment and un-assignment, etc., were being followed within the community. 

As everyone learns from their own mistakes, so did we. The teams were run through the sessions by the experienced contributors, where they elucidated the best practices to adopt while working on the issues.

All's well that ends well

By the end of June, we made it to the top 4!Graph to show month-wise rank

The graph shows Srijan’s ranking on Drupal Marketplace from March to June 2020

The ultimate goal

To reach our ultimate goal, we were continually putting efforts to maintain our position in the top 5 quality contributors. Below is the graph to help you understand the scenario betterGraph with vertical bars of various lengthThe percentage of Drupal Core Credits with the Total Credits, as of July 1, 2020, for top 4 Contributors.

Our position as of August 12, 2020, i.e., in the second quarter of the year, was 2nd, and maintaining it requires some serious strategic planning and continuous implementation. 

The credits are evaluated every 90 days. You may lose the hard-earned position if the constant efforts are not dedicated. Given this, it is essential to foresee things and act accordingly.

This is all about the contribution journey of Srijan in the first quarter of 2020. As George Herbert said, “Where there is a will, there is a way,” we have now successfully achieved the second position in the marketplace. 

To know this another exciting journey of ours, where we achieved the second position, you ought to stay tuned for the next blog. 

Meanwhile, keep contributing to the community! :)

Jun 30 2020
Jun 30

Consider a situation wherein your car indicators are placed near the glove compartment, the horn near the back seat, ignition turn on/off button near the fuel tank, and steering wheel with the button to open the side doors. How infeasible it would be!

A man sitting on chair and working on system

Of course, nobody will ever want to drive such a non-ergonomic car that can cause a threat to human life.

Likewise, for content marketers and publishers who create and publish content, their editorial experience must be seamless. It implies that they should be able to publish quality content in less time ahead of their competitors.

This blog is an attempt to interconnect the long-proven Japanese concepts of manufacturing - Kaizen and 5S’ technique with the editorial experience in the digital world to help companies implement it through Drupal and make their teams more productive for content creation and publishing.

 

Applying Manufacturing Concepts to Editorial Workflows in Publishing

Whether you have realized or not, you do have an editorial workflow. It is simply the way your content gets published.

However, if you have never given it much thought or attention, your team’s workflow is likely undefined, unclear, and unhelpful. It probably changes from article to article, and steps are missed or completed out of order.

See how manufacturing concepts can be applied to improve editorial workflow -

Getting into Editors’ Shoes

Engineer at the assembly line

Advancement in technology can facilitate editors to produce good   quality content and with high quantity. Though leveraging it the right   way can only ensure the productivity and quality of the work.

For an engineer on a manufacturing assembly line, carefully studying each step from pulling an electric screwdriver hanging from the ceiling and 5 screws from a bucket kept right near the waist level to eventually gripping those screws in the car.

Likewise, for editorial teams, it’s important to understand tasks that are repeated by the majority of the users and categorize them in high, medium, and low-frequency High Time tasks.

Understanding Key Pain Areas

A man stamding and operating system


Editors and publishers when working in collaboration should be able to maximize efficiency and revenue for the business. Stakeholders should emphasize the use of a specific mindset and tools to create efficiency and value. Here are some pain points that enterprises must resolve to help address those challenges-

American Society of Quality teaches a concept of FMEA (Failure Mode Effect Analysis) which can be directly applied to Editorial experience betterment
"Failure modes" means the ways, or modes, in which something might cause delays or complicate the workflow

"Effects analysis" refers to studying the consequences/results of those.

Focus on the tasks that hold the highest chances of occurrence and their consequences on the editorial experience and on business outcomes

Examples of Failure Modes and Effects

Failure Mode

Effects

Long Content Forms

Time Delays, Frustration for teams

Excessive clicks to complete a form

Time Delays for publishing, complicated workflow

Multiple Screen Navigations

Possible loss of information, time delays

One body field for all content

Difficult to manage changes, Low-richness of content

Applying Lean Manufacturing 5S’ technique for better Editorial Experience

The term 5S is taken from five Japanese words -

  • Seiri
  • Seiton
  • Seiso
  • Seiketsu
  • Shitsuke

When translated in English, these words become-

  • Sort
  • Set in Order
  • Shine
  • Standardize
  • Sustain

Here, each “S” represents one part of the five-step process that can improve the overall functioning of a business. Let’s get in detail of each “S”.

1. Sort:  This involves going through all the tools(buttons), furniture(fields), equipment(process), etc. in a work area(content management system) to find what needs to be present and what can be removed. 

  • When was this item(field) last used?
  • What is the purpose of this item(field)?
  • How frequently is it used?
  • Who uses it?
  • Does it need to be here?

Logical Grouping of Fields: When was the last time you cribbed about the monologue like marketing forms or a job application which took you years to complete?

day comLong and Verbose Content Forms vs Logical Grouped Forms with Form tips

Now think wearing editors’ hat who have to create content using those long forms 10, 20, 50, 100 times a day, these just prove as a hindrance for editors to create and innovate with their content

Logical Grouping of fields via the Field Group module makes the form short and easy for editors to only pick and add information in the fields which are concerned to them.

Form Tip is another intuitive feature to avoid long-form(black box in the screenshot on right) and give editors some info about the info that needs to be added in the field.


2. Set in Order

Once the clutter is gone, it's easier to see what's what. Now workgroups can come up with their strategies for sorting through the remaining items.

  • Collapsible Fields is another way to reduce the length of the form and collapse the fields which are not used widely in all content

a rectangular white bar with text

vehicles moving on road

  • Conditional Fields  is another way to reduce the   number of fields on the form, show/hide fields   based on condition, eg. the ‘Primary Image  Summary’ field for an image will appear only if  there is an image uploaded to an article (As seen  for ‘Primary Image’ field in Screenshot) 
  • Number of Clicks - Carefully minimize the number of clicks to achieve a task 


gif showing various rich multimedia formats

Rich Multimedia Features- Helps  creating a modular content structure with different logical fragments of content rather than just one large body field. Use this to add rich social media features like Embeds, Slideshows, Videos, Audio Podcasts.

two sections divided on white background

  • Taxonomy Manager  allows editors to manage all the master content and vocabularies in the system in an intuitive interface

8 sections divided showing people

Gives a selection view for images and videos  

text on white background

Helps listing the items together for a section of the website


3.  Shine:

The Shine stage of 5S focuses on styling and theming of the interface for the creation and publishing of content for editors. 

  • Giving editors much larger space to write and manage content contrary to the traditional content forms
  • Max Length Helps defining field limits to make sure the user doesn’t exceed the limits 
  • Colors and Font: Use clear visible font-size which are not stressful to the eye. Use solid colors for the header/footer menu of content entry screens for better visibility of text.  

two images juxtaposed on white backgroundHeader/footer menu of content entry screens for better visibility of text

4. Standardize: Use standardized field types to supplement faster creation of content.

Anubhav 4.0

Some industry-standard field types that can be used are mentioned below:

-  A long list of options: Eg. the country field can be configured using Auto-complete deluxe 

- Multiple values in a field: Eg. Keywords field can be configured using Chosen fields; it’s quick and gives a fast response if the user wants to remove an item

- Hierarchical items can be configured using SHS

There are a few more industry-standard features that should be added to the interface for standardizing editorial experience:

Auto-Save of Progress

 If the user's browser or machine   dies while editing an article; the   edits will be presented to the user the next time they return to the article

a dialog box on white background

  Content Locking 

When a user is editing an article, any other user that attempts to edit the same article will be blocked from doing so and notified that the content is already being edited. fields on white background

5. Sustain: This is the last of the 5S’. It is not only about keeping the 5S running smoothly, but also about keeping everyone in the organization involved.

video in  white backgroundTraining and Onboarding: Quick Editorial onboarding for the editors which means the teams can self-learn on creating content and publishing content without specialized training. 

Saves a lot of time and money to onboard a new publishing interface.

Summing up-

Though 5S is quite a simple concept, beginning a new program of it can feel daunting.

You can start by rolling out a plan with practical steps such as deciding the departments and individuals to be involved, what training will be needed, and what tools will be helpful in executing the process.

Determining these concrete steps would help you successfully carry out the process of 5S implementation. Besides, Drupal has the potential to enhance the editorial workflow significantly through its powerful modules and distributions.

Jun 26 2020
Jun 26

Drupal 9 was launched on June 3, 2020. Given this, it would be necessary for enterprises to upgrade to it later or sooner to acquire complete functionality and retain the ability to receive security updates within the bi-yearly cycles.

In the past, migrating from one version to another has been similar to moving from another CMS to Drupal, bringing in more time and fatigue.

However, the upgrade from D7/8 to D9 is much easier and painless. Let’s dive into more details and understand as to why moving on to Drupal 9 would be a better choice.

Why Should You Upgrade?

With the end of life approaching for Drupal 7 and 8 soon, operating the website on them securely and with complete functionality won’t be a feasible option.

At the same time, it might also be overwhelming for Drupal 7/8 site owners to know that their website will need the upgrade, especially when their site is running absolutely fine; thereby, resulting in confusion among them.

Here are 3 reasons why you should consider upgrading your site to Drupal 9:

  1. The Drupal security team will soon no longer provide support or security advisories, wavering your website’s and its users’ cybersecurity
  2. D7 and 8 releases’ on all project pages will be flagged as ‘not supported’. D7/ 8 may be flagged as insecure in 3rd party scans making the integration with other third-party tools and systems challenging
  3. Leading hosting services providers like Acquia and Pantheon will also soon withdraw their support from D7 leaving you without many options but to assume hosting responsibility for maintaining your application and server level configurations

The good news for Drupal 7/8 site owners is that even when it goes out of official support in November 2022, remaining Drupal 7/8 sites won't stop working at that point.

Should an Existing Drupal 7 Site Be Upgraded to Drupal 8 or 9?

One of the major reasons that more than seven hundred thousand Drupal 7 sites still haven’t migrated to Drupal 8, is due to the known challenges in the migration process. And with the majority of people on Drupal 7, it is quite likely that most of them did not want to upgrade their CMS twice in the span of one year.

A safe bet seems to be migrating from Drupal 7 to Drupal 9. But will the site be secure? Let’s get to know a few facts.

Since D8 and D9 are similar except for deprecated codes removed and third-party updates in D9, it would be a feasible option for enterprises to migrate to D9 instead of D8 - to save them from constantly going through the same process and investing time, money, and efforts unnecessarily.

What’s New in Drupal 9?

There are innumerable capabilities added in Drupal 9 which further will be consistently updated biannually to help enterprises stay up-to-date.

Now once you upgrade your system to D9, you won’t require to make major changes the next time you plan to update it to a newer version. 

Here are some of the new capabilities that are added to D9-

  1. Backward compatible

    Drupal 9 is backward compatible, i.e., it is compatible with its predecessor, Drupal 8. That being said, D9 will be able to use modules, configurations, and data created on D8 of the same software, unlike the case with D7 and D8.
    Additionally, preserving this functionality won’t burden Drupal with historical baggage and so the performance of the system will remain unaffected. The Drupal community has also focused on breaking code and not the data.
    This way, Drupal will remain fast, clutter-free, and yet an up-to-date technology.

  2. Faster and Better Performance

    Drupal 9 has taken it further to extend its support for responsive images, wherein mobiles can display the best-sized images and hence, consume fewer amounts of data.
    In a recent webinar by Dries, he mentioned that Drupal 9.1 onwards versions/updates will witness the innovation and pave the way for faster and better performances of the websites. Drupal 9.1 update is just six months post the release of Drupal 9. Meanwhile, here are some of the features of D9 that you can leverage for efficient workflows-

        A.  BigPipe increasing page view performance and supporting faster initial page loading

        B.  Content Workflow allowing you to define multiple workflows

        C.  Multilingual capabilities

        D.  Structure Content- Drupal 9 comes in with an array of available fields, encompassing phone, email,       data, and time.

  3. Cleaner code base

    Drupal 9 has removed the support for deprecated codes in D8. This implementation will ensure that the code marked as deprecated will no longer be supported and used in the Drupal ecosystem. 
    The motive behind this is to make D9 a cleaner version so that whenever the modules in D8 want to become compatible with D9, they need to first eliminate the deprecated code. 
    Thus, the end result is clear- to make the code more nimble and improve the website’s performance.

  4. Newer Major Versions of Symfony and Twig

    Symfony 3 will be replaced with Symfony 4 or 5 after November 2021. Also, the Drupal community can introduce an upgrade to Twig 2.0. These upgrades will only result in enhanced performance, improved developer experience, and enhanced security.

  5. Panelizer will be removed and replaced 

    What’s new in Drupal 9? Well, the panelizer will be replaced with the Layout Builder, the “star” module of the moment.

  6. Headless CMS

    Drupal 8 and 9 both come with an API-first approach. Dries also mentioned in the webinar that the Drupal community is vigorously capitalizing on Headless CMS so that it can enhance users’ experience with the powerful front-end of the website with Javascript framework like React or Angular. 

The essential features of Drupal Headless CMS are-

  • Front-End Freedom
  • Create Once, Publish Anywhere
  • API-First Approach
  • Easier Resourcing

Drupal 9 is more usable, accessible, inclusive, flexible and scalable than previous versions, with the following updated features-

  • It will be significantly easier for marketers to use D9
  • Simple than ever to maintain and upgrade for developers
  • D9 is experimenting with its headless or decoupled capabilities

Additionally, you can also learn from our previous blog where we have explained how to find and fix the deprecated code - Site Owner’s Guide to a Smooth Drupal 9 Upgrade Experience.

Why Remove Deprecated Code in Drupal 9?

To ensure that the D8 modules remain compatible with D9, it’s typically essential to remove deprecated codes- 

  1. The all-new Drupal 9 ready code gets deployed on Drupal 8 sites and issues can be tested.
  2. It is a continuation of the fully-tested and stable codebase of Drupal 8

With time, the effort is being made to make Drupal better. There are functions that have been around for a long time but will not be a good fit in the latest release. Most were deprecated in Drupal 8.7.0, which will be removed in Drupal 9.

To sum it all, the key to achieving this smooth transition to Drupal 9 is to rollout your migration plan within deadlines and save yourself from any unnecessary hassle later on.

Srijan is working with leading enterprises to help them migrate their digital web properties to Drupal 9 for better user experience. 

If you are also looking for a smooth upgrade/migration process for your enterprise’s system, we are all ears and excited to assist you. Contact Us!

Jun 03 2020
Jun 03

Drupal 9 will be launched today. After so much hard work, collaboration, anticipation and excitement, it is finally here.

Although a lot of discussion is happening around the upgrade and possibilities it brings along, the final product can only be as good as the process itself.

The good and important news is that moving from Drupal 8 to Drupal 9 should be really easy — radically easier than migrating from Drupal 7 to Drupal 8.

As a site owner, here’s what you need to know about the new release and what to take care of to make the process easier without many glitches.

The Drupal 9 Release and Timeline

The goal of Drupal 9 is to make it an easy upgrade as much as feasible from Drupal 8. Unlike most of the previous upgrades, D9 will be different in terms of:

  • Updates of dependencies to versions that stay supported.
  • Removal of our own code that we deprecated with removal before Drupal 9's release.

The new release will be a cleaned-up version of Drupal 8. Built on the same code base with deprecated code removed and third-party dependencies updated, Drupal 9 is not a reinvention of Drupal.

a horizontal table with Drupal versions

The next question is what happens to Drupal 7 and 8, then?

One of the major dependencies of Drupal 8 is on Symfony 3. Since Symfony 3 enters the end of life in November 2021, Drupal 8 support will be lifted around the same time. A long-term-support (LTS) minor release of Drupal 8 will be released alongside Drupal 9 and supported until November 2021.

No new features will be added to Drupal 8 and no new minor releases will be made available of Drupal 8. It will only receive patch releases after which.

Drupal 7 will also stop receiving community support after November 2021.

Data migration features in Drupal core to move from Drupal 7 to Drupal 9 will be active until then since they are required for a stable migration. 

The Upgrade and The Tips

The only caveat is that you need to manage is the "deprecated code". Here’s what you need to take note of, for an easiest upgrade experience to Drupal 9:

drupal 9.0 api

  1. Keep Core Up-to-Date: As mentioned above, Drupal 9 is Drupal 8.9 - deprecated parts plus dependencies updated.

    If your site doesn't use deprecated code that is scheduled for removal in Drupal 9, your upgrade to Drupal 9 will be easy. In fact, it should be as easy as a minor version upgrade (like upgrading from Drupal 8.6 to Drupal 8.7).

  2. Keep Modules Up-to-Date: Although Drupal 9 will not have new features (other than those provided by updated dependencies). While most modules will improve Drupal 9 compatibility, to ensure you don’t lose them in the upgrade, keep them updated.

    The key benefit of Drupal 9 over previous versions is that the platform will be supported with security fixes much later after support is lifted from 8. For contributed modules, the pace of Drupal 9 updates will depend on the module maintainers.

  3. Check Custom Codes for Deprecation: In case of any custom code on the site, you can use the deprecation checking and correction tools and fix issues locally. Tools you can use to check code depreciation:
    1. Drupal Check (read more her about PHP version compatibility check
    2. Rector (Read more about Rector here)

      Further, you can also use an IDE or code editor that understands deprecations (@deprecated annotations particularly) or Drupal 8’s branch of Upgrade Status for full site reporting.

What is Deprecated Code?

Deprecated code is referred to as the functions and API’s which are being replaced with new and better versions. In the journey from Drupal 8 from Drupal 9, you will experience API changes, with the new implementation is already present in core along with older one. We have to replace older code/API usage with the new.

Here is an example of the deprecated function:

* @deprecated in Drupal 8.5.0 and will be removed before Drupal 9.0.0. * Use \Drupal\Core\Messenger\MessengerInterface::addMessage() instead. */ function drupal_set_message($message = NULL, $type = 'status', $repeat = FALSE) { @trigger_error('drupal_set_message() is deprecated in Drupal 8.5.0 and will be removed before Drupal 9.0.0. Use \Drupal\Core\Messenger\MessengerInterface::addMessage() instead. See https://www.drupal.org/node/2774931', E_USER_DEPRECATED); $messenger = \Drupal::messenger(); if (isset($message)) { $messenger->addMessage($message, $type, $repeat); } return $messenger->all(); }

In above example the function drupal_set_message is deprecated and has to be replaced with:

\Drupal\Core\Messenger\MessengerInterface::addMessage()

Ways to Find and Fix Deprecated Code in your Drupal Project

As mentioned above , you can find and fix your deprecated code in the following ways:

  1. Drupal Check: It's a library developed by Matt Glaman. Check the git code here. For installation and usage, you can refer to the readme. 
    In case you want to install using Composer, prepare using composer global require mglaman/drupal-check. You can also read more about the composer check
    1. Get into your project/Drupal root directory
    2. Choose the module you want to check for deprecations
    3. Run drupal-check --help for help items. Here, I am using watchdog_prune module for demonstration.
      run : drupal-check -d watchdog_prune
      The output will be something similar to the image shared below:
      deprecated-code-1-srijan
    4. You will, now, have the report of deprecated code to fix.
    5. Let say it is giving us File src/Form/WatchdogPruneSettings.php containing issue : Call to deprecated function drupal_set_message(). In this case just navigate to the body of function as in this case drupal_set_message()

      You will notice that the the documentation under red box reads that the function is deprecated and what we need to do instead
      Ways to Find and Fix Deprecated Code in your Drupal Project
      Now replace the current code with the recommendation and you are done.

2. Drupal Upgrade Status Module: This module checks the list of projects you have installed and shows their availability for newer versions of Drupal core.
      1. Use the Upgrade Status module form
      2. Download and install module using composer: composer require drupal/upgrade_status
      3. Install the module and navigate to URL using admin user: /admin/reports/upgrade
      4. You can run a complete project/ individual module scan
      5. Fix the deprecated code in the same way as mentioned above.

Wrapping Up

Because Drupal 9 is an extended version of Drupal 8, for site owners, this means that it should be much easier to upgrade. But keeping custom codes and module updated needs to be meticulously planned.

Have questions around Drupal 9 upgrade and how it might impact your site? Experts at Srijan are all ears, connect with us to chalk out the right course to Drupal 9.

Jun 01 2020
Jun 01

Many organizations are running into the challenge of managing content on their multiple websites for gaining centralized control and ensuring its secure flow.

Taking a piece-by-piece approach and allocating teams to work on each site separately drives the higher cost of maintenance, development, results in complex infrastructures, and inefficiencies in the process.

While content cannot be shared and shipped using CMI tools unlike configurations, Drupal modules can be utilized for sharing content among different sites or different instances of the same site.

This blog sheds light on the features that enterprises should not overlook while leveraging Drupal modules and also examines the benefits & limitations of the Entity share module and the cases in which it makes the biggest difference.

A Cost-effective Solution to Manage Content Across Sites 

Entity Share module helps enterprises achieve a workflow where subsites of a multisite architecture can share a piece of content across without disrupting the workflow at their respective ends. Besides, it also keeps UI experience and cost-effectiveness in check.

The module works for a setup where each of the sites have different databases. It provides easy means to share entities like nodes, taxonomy terms, media, etc on the basis of endpoints obtained from the JSON:API module via basic authentication.

Note- The websites sharing content among each other are designated by the terms, Server, and Client. The server (site) being the one from where content is shared and the client (site) is the one that takes in shared content.

Installation and Configuration Process of Entity Share Module

Follow these steps to install and configure the module-

  1. The entity_share module of desired version might be installed either via composer using
  2. Thereafter the module needs to be enabled using the drush command “drush en entity_share”.

  3. Next step is to create channels on the server site containing exact data to be exposed from its end. Channel configuration can be done after enabling the entity_share_server v.i.a command “ drush en entity_share_server” which is a submodule present within entity_share. Additional filtering and sorting rules can be set on these channels as required after navigation through

    Configuration-> Web Services-> Entity Share-> Channels.

    text fields in white backgroundThe specification of an authorized user is a must to access this channel. 
    text fields in white background
  4. The client site, on the other hand, contains remote data that comprises the remote/server URL that it needs data from and authorization details like user and password to connect to the server which is provided after enabling the submodule entity_share_client using command “drush en entity_share_client”. Note this module needs to be enabled on the site that will pull shared content.

    Navigate to Configuration-> Web Services-> Entity Share-> Remote Websites and configure the remote settings. Ensure that the username and password in the Basic Auth section is the same as the credentials of the user that has access to entity share channels on the server end configured earlier.

    text fields in white background
  5. After successful authentication, all the shared content (from server end) will be available to the client site at [client_base_url]/admin/content/entity_share/pull to be pulled and displayed at its end. 


    This provides an added advantage to the client-side where it can accept the shared content only after complete verification. The shared content simply does not get created as soon as the server shares it.

    Moreover, the interface that the module provides for the entities to be pulled is user-friendly and easily understandable. It clearly depicts newly created and already pulled content along with its synchronization status. In case the content after being shared and pulled gets edited either at the server or client-side, the status gets immediately updated.

text fields in white background

Use Case of Entity Share

We implemented Entity Share module for a client project 

Recently Srijan came across a requirement where one of its established clients had local websites in regional languages distributed across many countries in the world.

Our main objective was to provide them with a solution where the administrator or central authority would be able to share some content like news updates, press releases, etc from the main/corporate website without affecting the rest of the content at each end. 

Additionally, a necessity of central control over each of the shared content/nodes was required where any change on the main site would be available on the client end to be pulled again or re-synchronized. 

Similarly, if a client site made any change on the content at its end, changes would appear on the corporate/main to be synced. The entity share module was best suited for such a scenario. 

We configured channels and remote sites as described above and the functionality was achieved. One of the custom functionalities added was to set the default status of the node being pulled into the Draft state so that the content editor can review the same before publishing. 

Despite the fact that Entity Share module is not yet identified as secure since a lot of inaccessible data is exposed using JSON:API endpoints, we implemented it for the client project. 

Because an extra security layer can be implemented to the web server configuration level by blocking requests from unwanted sources and allowing only trusted sources to fetch data. No third party expensive integrations were required. It matched with the clients’ requirements and also simplified our process of adding custom functionalities to it.

Benefits of Entity Share Module

It offers the following benefits-

  1. Authorized access- The module provides content exposure to a site ensuring authentication. Without proper authentication, no site can have access to the channel data exposed from the server website.
  2. Enhanced security for verifying content- The client site has a choice to pull data from the available list of content shared with it. This allows an extra layer of security that allows the administrator/editor of the client site to verify data at its end before synchronizing it. A link to the content/entity being shared is available beside each item in the list of entities present in the respective channel.
  3. Different versions to detect changes, if made- The module lets you view the difference between the already pulled entity and the entity on the server end, in case anyone of them gets changed.

    Given this, you have to install a module called diff to let you view revisions of an entity. Although the module has issues depicting differences in the reference fields; developers have an opportunity here to contribute to the community by finding an appropriate solution to the same.

  4. Multilingual support- Translated entities may be shared among sites provided the language is configured on both the ends. Even in the case where the default language of the server and the client site is different, this module is appropriate to use. 
    The client site may add appropriate translations based on the pulled content at its respective end.
  5. Auto-creation of referenced entities- All the referenced entities are auto-created based on UUID when a content/entity gets pulled if not present on the client end. Hence referenced paragraphs, images, and media that contain references to such fields need not be present on the client end before pulling content. They will be automatically created and linked.
  6. Clean and simple user interface- Lastly, the UI interface that entity_share provides for pulling/synchronizing content is easy to use. The entity pull access might be given to a specific user/editor of the website without developer intervention, once configured properly.

Limitations of Entity Share Module

Like other modules mentioned above, entity_share has limitations too:

  1. The entity when pulled on the client site, is displayed in the same state, i.e., published/unpublished as that on the main/server website. It implies that the module doesn’t obey customized editorial workflow and moderation process. Editors can’t take appropriate action of passing content through various workflow states such as draft, ready for review, approved and then published.

    For example - A published content when pulled is directly assigned a state from the pulled reference i.e published rather than in draft mode.

    However, there is a possibility to change this functionality by subscribing to the event

    \Drupal\entity_share_client\Event\EntityListDataAlterEvent

    provided by entity_share_client module to alter the status of the content being pulled.

    Likewise, other events are also available in the module that can be used to   tweak any functionality as and when required.

  2. The revision history of the node gets affected after pulling an already pulled entity that has been edited on the client end as well. This is because the changed timestamp that the JSON:API endpoint provides gets added to the client-side as it is after synchronization.

    This also needs to be fixed in the module to allow pull operations without affecting revisions on both ends. You can find another related issues  too.

Instead of using exorbitant and ineffective Drupal modules for content management across the various sites, give a try to Entity share module, it is a cost-effective solution that can be optimized as per enterprises' requirements.

Looking for a similar solution? Drop us a line and our team will get back to you.

Aug 24 2016
Aug 24

The Winnipeg City’s NOW (Neighbourhoods Of Winnipeg) Portal is an initiative to create a complete neighbourhood web portal for its citizens. At the core of the project we have a set of about 47 fully linked, integrated and structured datasets of things of interests to Winnipegers. The focal point of the portal is Winnipeg’s 236 neighbourhoods, which define the main structure of the portal. The portal has six main sections: topics of interests, maps, history, census, images and economic development. The portal is meant to be used by citizens to find things of interest in their neibourhood, to learn their history, to see the images of the things of interest, to find tools to help economic development, etc.

The NOW portal is not new; Structured Dynamics was also its main technical contractor for its first release in 2013. However we just finished to help Winnipeg City’s NOW team to migrate their older NOW portal from OSF 1.x to OSF 3.x and from Drupal 6 to Drupal 7; we also trained them on the new system. Major improvements accompany this upgrade, but the user interface design is essentially the same.

The first thing I will do is to introduce each major section of the portal and I will explain the main features of each. Then I will discuss the new improvements of the portal.

Datasets

A NOW portal user won’t notice any of this, but the main feature of the portal is the data it uses. The portal manages 47 datasets (and growing) of fully structured, integrated and linked datasets of things of interests to Winnipegers. What the portal does is to manage entities. Each kind of entity (swimming pools, parks, places, images, addresses, streets, etc.) are defined with multiple properties and values. Several of the entities reference other entities in other datasets (for example, an assessment parcel from the Assessment Parcels dataset references neighbourhoods entities and property addresses entities from their respective datasets).

The fact that these datasets are fully structured and integrated means that we can leverage these characteristics to create a powerful search experience by enabling filtering of the information on any of the properties, to bias the searches depending where a keyword search match occurs, etc.

Here is the list of all the 47 datasets that currently exists in the portal:

  1. Aboriginal Service Providers
  2. Arenas
  3. Neighbourhoods of Winnipeg City
  4. Streets
  5. Economic Development Images
  6. Recreation & Leisure Images
  7. Neighbourhoods Images
  8. Volunteer Images
  9. Library Images
  10. Parks Images
  11. Census 2006
  12. Census 2001
  13. Winnipeg Internal Websites
  14. Winnipeg External Websites
  15. Heritage Buildings and Resources
  16. NOW Local Content Dataset
  17. Outdoor Swimming Pools
  18. Zoning Parcels
  19. School Divisions
  20. Property Addresses
  21. Wading Pools
  22. Electoral wards of Winnipeg City
  23. Assessment Parcels
  24. Libraries
  25. Community Centres
  26. Police Service Centers
  27. Community Gardens
  28. Leisure Centres
  29. Parks and Open Spaces
  30. Community Committee
  31. Commercial real estates
  32. Sports and Recreation Facilities
  33. Community Characterization Areas
  34. Indoor Swimming Pools
  35. Neighbourhood Clusters
  36. Fire and Paramedic Stations
  37. Bus Stops
  38. Fire and Paramedic Service Images
  39. Animal Services Images
  40. Skateboard Parks
  41. Daycare Nurseries
  42. Indoor Soccer Fields
  43. Schools
  44. Truck Routes
  45. Fire Stations
  46. Paramedic Stations
  47. Spray Parks Pads

Structured Search

The most useful feature of the portal to me is its full-text search engine. It is simple, clean and quite effective. The search engine is configured to try to give the most relevant results a NOW portal user may be searching. For example, it will positively bias some results that comes from some specific datasets, or matches that occurs in specific property values. The goal of this biasing is to improve the quality of the returned results. This is somewhat easy to do since the context of the portal is well known and we can easily boost scoring of search results since everything is fully structured.

Another major gain is that all the search results are fully templated. The search results do not simply return a title and some description for your search results. It does template all the information the system has about the matched results, but also displays the most relevant information to the users in the search results.

For example, if I search for a indoor swimming pool, in most of the cases it may be to call the front desk to get some information about the pool. This is why different key information will be displayed directly in the search results. That way, most of the users won’t even have to click on the result to get the information they were looking for directly in the search results page.

Here is an example of a search for the keywords main street. As you can notice, you are getting different kind of results. Each result is templated to get the core information about these entities. You have the possibility to focus on particular kind of entities, or to filter by their location in specific neighbourhoods.

now--search-1

Templated Search Results

Now let’s see some of the kind of entities that can be searched on the portal and how they are presented to the users.

Here is an example of an assessment parcel that is located in the St. John’s neighbourhood. The address, the value, the type and the location of the parcel on a map is displayed directly into the search results.

now--template-search-assessment-pacels

Another kind of entity that can be searched are the property addresses. These are located on a map, the value of the parcels and the building and the zoning of the address is displayed. The property is also linked to its assessment parcel entity which can be clicked to get additional information about the parcel.

now--template-search-property-address

Another interesting type of entity that can be searched are the streets. What is interesting in this case is that you get the complete outline of the street directly on a map. That way you know where it starts and where it ends and where it is located in the city.

now--template-search-street

There are more than a thousand geo-localized images of all different things in the city that can be searched. A thumbnail of the image and the location of the thing that appears on the image appears in the search results.

now--template-search-heritage-building-image

If you were searching for a nursery for your new born child, then you can quickly see the name, location on a map and the phone number of the nursery directly in the search result.

now--template-search-nurseries

There are just a few examples of the fifty different kind of entities that can appear like this in the search results.

Mapping

The mapping tool is another powerful feature of the portal. You can search like if you were using the full-text search engine (the top search box on the portal) however you will only get the results that can be geo-localized on a map. You can also simply browse entities from a dataset or you can filter entities by their properties/values. You can persist entities you find on the map and save the map for future reference.

In the example below, it shows that someone searched for a street (main street) and then he persisted it on the map. Then he search for other things like nurseries and selected the ones that are near the street he persisted, etc. That way he can visualize the different known entities in the portal on a map to better understand where things are located in the city, what exists near a certain location, within a neighbourhood, etc.

now--map

Census Analysis

Census information is vital to the good development of a city. They are necessary to understand the trends of a sector, who populates it, etc., such that the city and other organizations may properly plan their projects to have has much impact as possible.

These are some of the reason why one of the main section of the site is dedicated to census data. Key census indicators have been configured in the portal. Then users can select different kind of regions (neighbourhood clusters, community areas and electoral wards) to get the numbers for each of these indicators. Then they can select multiple of these regions to compare each other. A chart view and a table view is available for presenting the census data.

now--census

History, Images & Points of Interest

The City took the time to write the history of each of its neighbourhoods. In additional to that, they hired professional photographs to photograph the points of interests of the city, to geo-localize them and to write a description for each of these photos. Because of this dedication, users of the portal can learn a much about the city in general and the neighbourhood they live in. This is what the History and Image sections of the website are about.

now--history

Historic buildings are displayed on a map and they can be browsed from there.

now--history-heritage-buildings

Images of points of interests in the neighbourhood are also located on a map.

now--history-heritage-resources

Find Your Neighbourhood

Ever wondered in which neighbourhood you live in? No problem, go on the home page, put your address in the Find your Neighbourhood section and you will know it right away. From there you can learn more about your neighbourhood like its history, the points of interest, etc.

now--find-your-neighbourhood

Your address will be located on a map, and your neighbourhood will be outlined around it. Not only you will know in which neighbourhood you live, but you will also know where you live within it. From there you can click on the name of the neigbourhood to get to the neighbourhood’s page and start learning more about it like its history, to see photos of points of interest that exists in your neighbourhood, etc.

now--find-your-neighbourhood-result

Browsing Content by Topic

Because all the content of the portal is fully structured, it is easy to browse its content using a well defined topic structure. The city developed its own ontology that is used to help the users browse the content of the portal by browsing topics of interest. In the example below, I clicked the Economic Development node and then the Land use topic. Finally I clicked the Map button to display things that are related to land use: in this case, zoning and assessment parcels are displayed to the user.

This is another way to find meaningful and interesting content from the portal.

now--topics

Depending on the topic you choose, and the kind of information related to that topic, you may end up with different options like a map, a list of links to documents related to that topic, etc.

Export Content

Now that I made an overview of each of the main features of the portal, let’s go back to the geeky things. The first thing I said about this portal is that at its core, all information it manages is fully structured, integrated and linked data. If you get to the page of an entity, you have the possibility to see the underlying data that exists about it in the system. You simply have to click the Export tab at the top of the entity’s page. Then you will have access to the description of that entity in multiple different formats.

now--export-entity

In the future, the City should (or at least I hope will) make the whole set of datasets fully downloadable. Right now you only have access to that information via that export feature per entity. I hope because this NOW portal is fully disconnected from another initiative by the city: data.winnipeg.ca, which uses Socrata. The problem is that barely any of the datasets from NOW are available on data.winnipeg.ca, and the ones that are appearing are the raw ones (semi-structured, un-documented, un-integrated and non-linked) all the normalization work, the integration work, the linkage work done by the NOW team hasn’t been leveraged to really improve the data.winnipeg.ca datasets catalog.

New with the upgrades

Those who are familiar with the NOW portal will notice a few changes. The user interface did not change that much, but multiple little things got improved in the process. I will cover the most notable of these changes.

The major changes that happened are in the backend of the portal. The data management in OSF for Drupal 7 is incompatible with what was available in Drupal 6. The management of the entities became easier, the configuration of OSF networks became a breeze. A revisioning system has been added, the user interface is more intuitive, etc. There is no comparison possible. However, portal users’ won’t notice any of this, since these are all site administrator functions.

The first thing that users will notice is the completely new full-text search engine. The underlying search engine is almost the same, but the presentation is far better. All entity types have gotten their own special template, which are displayed in a special way in the search results. Most of the time results should be much more relevant, filtering is easier and cleaner. The search experience is much better in my view.

The overall site performance is much better since different caching strategies have been put in place in OSF 3.x and OSF for Drupal. This means that most of the features of the portal should react more swiftly.

Now every type of entity managed by the portal is templated: their webpage is templated in specific ways to optimize the information they want to convey to users along with their search result “mini page” when they get returned as the result of a search query.

Multi-linguality is now fully supported by the portal, however not everything is currently templated. However expect a fully translated NOW portal in French in the future.

Creating a Network of Portals

One of the most interesting features that goes with this upgrade is that the NOW portal is now in a position to participate into a network of OSF instances. What does that mean? Well, it means that the NOW portal could create partnerships with other local (regional, national or international) organizations to share datasets (and their maintenance costs).

Are there other organizations that uses this kind of system? Well, there is at least another one right in Winnipeg City: MyPeg.ca, also developed by Structured Dynamics. MyPeg uses RDF to model its information and uses OSF to manage its information. MyPeg is a non-profit organization that uses census (and other indicator) data to do studies on the well being of Winnipegers. The team behind MyPeg.ca are research experts in indicator data. Their indicator datasets (which includes census data) is top notch.

Let’s hypothetize that there would be interest between the two groups to start collaborating. Let’s say that the NOW portal would like to use MyPeg’s census datasets instead of its own since they are more complete, accurate and include a larger number of important indicators. What they basically want is to outsource the creation and maintenance of the census/indicators data to a local, dedicated and highly professional organization. The only things they would need to do is to:

  1. Formalize their relationship by signing a usage agreement
  2. The NOW portal would need to configure the MyPeg.ca OSF network into their OSF for Drupal instance
  3. The NOW portal would need to register the datasets it want to use from MyPeg.ca.

Once these 3 steps are done, taking no more than a couple of minutes, then the system administrators of the NOW portal could start using the MyPeg.ca indicator datasets like they were existing on their own network. (The reverse could also be true for MyPeg.) Everything would be transparent to them. From then on, all the fixes and updates performed by MyPeg.ca to their indicator datasets would immediately appear on the NOW portal and accessible to its users.

This is one possibility to collaborate. Another possibility would be to simply on a routine basis (every month, every 6 months, every year) share the serialized datasets such that the NOW portal re-import the dataset from the files shared by MyPeg.ca. This is also possible since both organizations use the same Ontology to describe the indicator data. This means that no modification is required by the City to take that new information into account, they only have to import and update their local datasets. This is the beauty of ontologies.

Conclusion

The new NOW portal is a great service for citizens of Winnipeg City. It is also a really good example of a web portal that leverages fully structured, integrated and linked data. To me, the NOW portal is a really good example of the features that should go along with a municipal data portal.

Oct 13 2014
Oct 13

A whirlwind tour of dozens of useful contributed modules for building Drupal 7 sites.

There are many really useful contributed modules to take your site beyond the basics of Drupal core. There are modules to improve, allow, and/or help with everything from administration to workflow, from paths to views, and beyond.

One factor to consider when choosing contributed modules is the recommendations of other experienced Drupallers. So in the list below I've noted some Drupal-as-a-Service (DaaS) platforms that have included a module in their service, which is essentially groups of experienced Drupallers indicating they find a module useful (and reliable enough) for a very large number of sites. I've also noted when at least some of a module's features are part of core in Drupal 8, which is an indication that very senior indeed Drupallers consider it useful for most sites.

  • (This functionality is part of core in Drupal 8.) indicates some/all of module's functionality is part of core in Drupal 8.
  • (This module is included in Stanford Sites.) indicates module is included in Stanford Sites.
  • (This module is included in Drupal Gardens.) indicates module was included in the late, lamented Drupal Gardens.

A key principle of module usage is to use as many as you need, but no more. Some of the modules (or their submodules) listed below are really useful when you are building or configuring the site, but don't need to be enabled for just visiting it or editing its content and so should normally be disabled on live/production sites.

  • (This module should only be enabled on live/production site if truly required by content editors.) indicates module should only be enabled on live/production site if truly required by content editors.

Essentials

These are modules that I install on essentially every site I build.

Administration menu (drupal.org/project/admin_menu(This module is included in Stanford Sites.) Provides a dropdown menu to most administrative tasks and other common destinations (to users with the proper permissions). (Don't forget to disable the core Toolbar module when using this.) Administration views (drupal.org/project/admin_views) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) Requires Views, Views Bulk Operations, Chaos Tool Suite, Entity API.
"Replaces administrative overview/listing pages with actual views for superior usability" —in other words, you can customize them! Advanced help (drupal.org/project/advanced_help(This module is included in Stanford Sites.) Displays advanced help and documentation. Many contributed modules' help and documentation are primarily available through this module. (This module should only be enabled on live/production site if truly required by content editors.) Chaos tool suite (drupal.org/project/ctools) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) A helper module required by Administration views, Views and a number of other modules. Date (drupal.org/project/date) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides "a flexible date/time field type (Date field) and a Date API that other modules can use." Entity API (drupal.org/project/entity(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Required by Administration views and Views bulk operations.
Extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Libraries API (drupal.org/project/libraries(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides a common repository for external (non-Drupal) libraries in sites/all/libraries and sites//libraries for use by contributed modules. Module filter (drupal.org/project/module_filter(This module is included in Stanford Sites.) Tames the modules list page, so you can quickly find the module you are looking for without tons of scrolling or having to rely on the browser's search feature. (This module should only be enabled on live/production site if truly required by content editors.) Pathauto (drupal.org/project/pathauto(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Token.
Provides a mechanism for modules to automatically generate URL aliases for the content they manage. Human-friendly URLs (e.g.,"about" rather than "node/72") are important for accessibility, usability, and SEO. Pathologic (drupal.org/project/pathologic(This module is included in Stanford Sites.) A filter that helps avoid broken links and incorrect paths in general text fields (e.g., Body, etc.). These tend to arise when full URLs ("http://sample.edu/about") or relative path URLs ("about") are used in general text fields instead of absolute path URLs ("/about") for internal content. Redirect (drupal.org/project/redirect(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Redirects users from one URL to another. When used with Pathauto, "automatically generates path redirects to ensure that URL alias changes do not break existing links." This is considered the best practice for SEO and usability. Token (drupal.org/project/token(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) The basic token API is now a part of Drupal 7 core, but this module provides a browsable token UI, as well as field & profile tokens that did not make it into core for Drupal 7. Transliteration (drupal.org/project/transliteration(This module is included in Stanford Sites.) Provides a central transliteration service (converting Unicode text to US-ASCII) to other Drupal modules (e.g., Pathauto), and sanitizes file names while uploading. Views (drupal.org/project/views) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Chaos tool suite.
Required by Administration views and Views bulk operations.
Creates customized lists and displays from already entered content. Along with fields, this is the heart of adding content once but being free to display it multiple places and multiple ways. (For those familiar with relational databases, fields & Views let you use the power of relational databases to wrangle your content, while still keeping content adding and editing as simple as word processing and online shopping.) Submodules include views_ui (This module should only be enabled on live/production site if truly required by content editors.) Views Bulk Operations (drupal.org/project/views_bulk_operations(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Views and Entity API.
Required by Administration views.
Exposes new Views style 'Bulk Operations' for selecting multiple nodes and performing actions on them all at once. Wysiwyg (drupal.org/project/wysiwyg) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires installation of (non-Drupal) editor libraries.
Allows users to edit contents with rich text editors such as CKeditor (This functionality is part of core in Drupal 8.) and TinyMCE. Permits inclusion of more than one rich text editor in the same site. Wysiwyg filter (drupal.org/project/wysiwyg_filter(This module is included in Stanford Sites.) "Provides an input filter that allows site administrators to configure which HTML elements, attributes and style properties are allowed" (based on whitelists). This lets administrators permit content editors to include images in general text fields without giving them access to Full HTML. (Allowing Full HTML is a security risk and just generally a Bad Idea.)

Frequently used

These are modules I install on many sites, but not all of them need the functionality provided.

Fields

Address Field (drupal.org/project/addressfield)"Defines a new field type to store international postal addresses, implementing a subset of the top-level address elements defined in the xNAL standard"Automatic entity label (drupal.org/project/auto_entitylabel) Allows automatic generation of entity label fields, such as node titles. (Replaces Automatic node titles module.) Email field (drupal.org/project/email) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) Provides a field type for email addresses. Entity Reference (drupal.org/project/entityreference) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Requires Entity API and Chaos tool suite.
Provides a field type that can reference arbitrary entities (nodes, etc.). Can display the field either as a link to the entity or as a rendered entity (for example, it can show either a link to a node or the node itself).Field collection (drupal.org/project/field_collection) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Field Group (drupal.org/project/field_group(This module is included in Stanford Sites.) Link (drupal.org/project/link) (This functionality is part of core in Drupal 8.) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) Provides a link field type. This allows association of a link title with a link URL, while permitting either to be optional.Smart trim (drupal.org/project/smart_trim(This module is included in Stanford Sites.)

Views

Better exposed filters (drupal.org/project/better_exposed_filters(This module is included in Stanford Sites.) "[R]eplaces the Views' default single- or multi-select boxes with radio buttons or checkboxes, respectively. Description fields and Select All/None links can be added to exposed filters to make for a better user experience." Calendar (drupal.org/project/calendar(This module is included in Stanford Sites.) Enables displaying views containing date fields in calendar formats. Can display information by day, week, month, or year in either pages or blocks. Date iCal (drupal.org/project/date_ical(This module is included in Stanford Sites.)"provides a plugin for Views to enable exporting your site's calendar as an iCal feed, and a plugin for Feeds to enable importing external iCal feeds into your site's calendar."EVA: Entity Views Attachment (drupal.org/project/eva)"Provides a Views display plugin that allows the output of a View to be attached to the content of any Drupal entity", such as a node, user profile, comment, etc.Views data export (drupal.org/project/views_data_export(This module is included in Stanford Sites.) Provides a way to export data from views to CSV, Microsoft XLS, Microsoft DOC, plain TXT, or XML. Views Datasource () (This module is included in Stanford Sites.)Views field view (http://drupal.org/project/views_field_view(This module is included in Stanford Sites.) Allows users to embed a view as a field in a view. A new field handler is made available, so this can also be used in area (header/footer/empty) handlers as well as rows.Views slideshow (http://drupal.org/project/views_slideshow(This module is included in Stanford Sites.)"Views Slideshow can be used to create a slideshow of any content (not just images) that can appear in a View." 

Blocks

Bean (drupal.org/project/bean(This module is included in Stanford Sites.) Allows the definition of block types (like content types, only for blocks instead of nodes). This has various benefits, including making it easy to add distinct fields to blocks, use WYSIWYG editors for block content, and the like. Block class (drupal.org/project/block_class(This module is included in Stanford Sites.) Lets site builders add CSS classes to any block through the block's configuration interface. This lets you really take advantage of the block-centric responsive design of themes like Open Framework and Stanford Framework. Block title link (drupal.org/project/block_titlelink(This module is included in Stanford Sites.) Allows site builders to turn a block's title into a link.Menu block () (This module is included in Stanford Sites.)

Context

Context (drupal.org/project/context(This module is included in Stanford Sites.)Allows site builders more fine-grained control over what is shown, where it is shown, and how it is shown ("reactions") on any given page based on a much wider and more flexible range of criteria/"conditions" than Drupal core. There is a lot of power in this module: with it you can have the same block show up in the header of one page but in the footer of others or have different themes depending on the path and much, much more. Context accordion (drupal.org/project/context_accordion(This module is included in Stanford Sites.) Requires Context
Improves the user interface (UI) of the Context module by adding a nice javascript accordion effect.Context HTTP headers (drupal.org/project/context_http_headers) (This module is included in Stanford Sites.)Requires Context
"Provides a set of Context reactions that allow you to set HTTP Response Headers for each context on your site. It is a generalized framework for response header handling that allows the sending of any arbitrary header value(s)." You can thank Whitehouse.gov for this one! Context list (drupal.org/project/context_list(This module is included in Stanford Sites.)Requires Context
Improves the administration experience of the Context module by providing "a list of contexts, their conditions and reactions in a simple view … The intention of this module is to provide a means of inspecting all contexts in one easy screen." Context list active (drupal.org/project/context_list_active(This module is included in Stanford Sites.)Requires Context
Like the Context list module, but lists the contexts, conditions, and reactions only for the current page. Context respect (drupal.org/project/context_respect(This module is included in Stanford Sites.)Requires Context
"Extends the Context module by making it respect default block settings. This makes it so you can retain your block visibility when assigning them into various Contexts." Context user agent (drupal.org/project/context_useragent(This module is included in Stanford Sites.)Requires Context
"Adds a new condition to the Context module that allows performing regular expression tests on the useragent string ($_SERVER['HTTP_USER_AGENT']). This allows adding different reactions based on the user's browser, operating system, or other needed contexts that may be found in the useragent string."  Delta (drupal.org/project/delta(This module is included in Stanford Sites.) Requires Context
Allows site builders "to make duplicates of your theme settings for any context on your site. This gives you the ability for alternative layouts as a reaction in Context" Contextual Block Class(es) (drupal.org/project/cbc(This module is included in Stanford Sites.)Requires Context
Allows site builders "to contextualize block classes" 

Appearance/Theme

Colorbox (drupal.org/project/colorbox) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)CSS injector (drupal.org/project/css_injector(This module is included in Stanford Sites.)Allows site builders to add new CSS (and override the theme's CSS) without editing (or even access to) the theme's files on the server. Display suite (drupal.org/project/ds(This module is included in Stanford Sites.) "[A]llows you to take full control over how your content is displayed using a drag and drop interface. Arrange your nodes, views, comments, user data etc. the way you want" by defining custom view modes. Site builders can define how one piece of content should be displayed in different places such as teaser lists, search results, the full node, views, etc."JS injector (drupal.org/project/js_injector) (This module is included in Stanford Sites.)Like CSS injector, only for JavaScript (SJ).

Development

Bundle copy (drupal.org/project/bundle_copy(This module is included in Stanford Sites.) Allows administrators to export and import content types and other entity definitions (taxonomy, user, field definitions, field groups). This is great for sharing structures between sites, instead of rebuilding them by hand each time. (Note, it does not import/export the content/data, just the structure/definitions.)Features (drupal.org/project/features) (This module is included in Stanford Sites.)"Enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case."Strongarm () (This module is included in Stanford Sites.)

Data Import

Feeds (drupal.org/project/feeds(This module is included in Stanford Sites.) "Import or aggregate data as nodes, users, taxonomy terms or simple database records." Feeds JSONPath Parser (drupal.org/project/feeds_jsonpath_parser(This module is included in Stanford Sites.)Feeds Tamper (drupal.org/project/feeds_tamper) (This module is included in Stanford Sites.)Feeds XPath Parser (drupal.org/project/feeds_xpathparser) (This module is included in Stanford Sites.)Path redirect import () (This module is included in Stanford Sites.)

Files and Images

File entity (fieldable files) (drupal.org/project/file_entity(This module is included in Stanford Sites.)"File entity provides interfaces for managing files. It also extends the core file entity, allowing files to be fieldable, grouped into types, viewed (using display modes) and formatted using field formatters."File (Field) Paths (drupal.org/project/filefield_paths(This module is included in Stanford Sites.)Requires Token. 
Adds the ability to use node tokens in destination paths and filenames. FileField Sources (drupal.org/project/filefield_sources) Extends file and image fields to allow referencing existing files, remote files, and server files.Insert (drupal.org/project/insert(This module is included in Stanford Sites.)Adds a button to file and image fields so images and links to files may be inserted inline into general text fields (e.g., the Body field).

Other

Backup and migrate ( drupal.org/project/backup_migrate (This module is included in Stanford Sites.) "Back up and restore your Drupal MySQL database, code, and files or migrate a site between environments. Backup and Migrate supports gzip, bzip and zip compression as well as automatic scheduled backups." [I use this when I can't use shell scripts in the command line on the server.] Better formats (drupal.org/project/better_formats(This module is included in Stanford Sites.) Adds more flexibility and control to Drupal's core text format system. It allows site builders to: set allowed text formats and/or default order of text formats per field; hide format tips and/or hide more format tips link per role; and hide format selection per role per entity. Bibliography module (drupal.org/project/biblio(This module is included in Stanford Sites.) For managing and displaying lists of scholarly publications, including importing from PubMed, BibTex, RIS, MARC, EndNotee and XML and exporting to BibTex, EndNote, and XML. Output styles include AMA, APA, Chicago, CSE, MLA and others. Content Access (drupal.org/project/content_access(This module is included in Stanford Sites.) Allows granular control of access to content by content types and, optionally, specific nodes by role and author, by specificing independent view, edit and delete permissions. Custom breadcrumbs (drupal.org/project/custom_breadcrumbs(This module is included in Stanford Sites.)"Allows you to create and modify your own breadcrumbs based on node type." (Breadcrumbs are that trail of links indicating the way to your current page, usually displayed just above or below the page title.) Diff (drupal.org/project/diff(This module is included in Stanford Sites.) "[A]llows pretty viewing of all added/changed/deleted words between revisions." Drupal Commerce (drupal.org/project/commerce)Flag () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Google analytics (drupal.org/project/google_analytics(This module is included in Stanford Sites.) (This module is included in Drupal Gardens.) "Adds the Google Analytics web statistics tracking system to your website."Inline entity form ()"Provides a widget for inline management (creation, modification, removal) of referenced entities. … Existing entities can also be referenced." This solves the chicken or egg problem for referencing content that hasn't been created yet!Job Scheduler (drupal.org/project/job_scheduler) (This module is included in Stanford Sites.)An API (helper module) "for scheduling tasks once at a predetermined time or periodically at a fixed interval."JW Player() (This module is included in Stanford Sites.) Link checker (drupal.org/project/linkchecker) Periodically checks for broken links in node types, blocks and cck fields and reports the results.Menu position () (This module is included in Stanford Sites.)Metatag () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Mollom () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Node clone () (This module is included in Stanford Sites.)Node convert (drupal.org/project/node_convert(This module is included in Stanford Sites.) (This module should only be enabled on live/production site if truly required by content editors.)Node form columns () (This module is included in Stanford Sites.)Panels ()Relation () (This module is included in Stanford Sites.) Rules (drupal.org/project/rules) (This module is included in Stanford Sites.) Lets you define conditionally executed actions based on occurring events. In other words, add logic/processing without having to code a custom module. Also required/used by many other modules. Services () (This module is included in Stanford Sites.)Site verification () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Taxonomy manager () (This module is included in Stanford Sites.)Universally Unique IDentifier () (This module is included in Stanford Sites.)Webform () (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)Workbench (drupal.org/project/workbench) (This module is included in Stanford Sites.) Workbench access (drupal.org/project/workbench_access) (This module is included in Stanford Sites.) Workbench moderation (drupal.org/project/workbench_moderation) (This module is included in Stanford Sites.) XML sitemap (drupal.org/project/xmlsitemap) (This module is included in Stanford Sites.) (This module is included in Drupal Gardens.)
Apr 30 2014
Apr 30

In this screencast, I will show you how you can leverage the semantic power of the OSF Search endpoint into Drupal using OSF for Drupal. You will see how you can configure the OSF SearchAPI module, how you can turn any property into a filtering facet and how you can display the facets into blocks.

Then I will briefly show you how you can create new search results templates and how the template selection works using type inference.

Finally I will show you how you can enable and disable inference in the search feature, and how you can leverage the semantic structure of your data to change the relevancy of the search results returned. You have all the leisure to boost different characteristics of your data to return more relevant results to your users.


tut_14_blog_400
Apr 29 2014
Apr 29

In this screencast, I will show you how you can use ontologies to specify the field types to use for the classes and properties we map into Drupal using OSF Entities mapping process. Once the field types will be configured for each Datatype property, I will run the mapping process to generate new fields that will use the configured field types. Once done, I will show you the impact of this configuration into the fields and fields instances that are being created into Drupal.

The second part of this screencast focus on the configuration of the field widgets that are being used by each field. Then I will update a few entities using the new forms. I will tell you how you can modify the form by re-ordering the fields, by changing their titles or other configuration options such as their cardinality.

OSF Entities supports the following 18 field types and 34 field widgets.


tut_13_blog_400
Apr 23 2014
Apr 23

This screencast will introduce you to the OSF for Drupal features that let you export Drupal Entities in one of the following supported serializations:

  • RDF+XML (RDF in XML)
  • RDF+N3 (RDF in N3)
  • structJSON (Internal OSF RDF serialization in JSON)
  • structXML (Internal OSF RDF serialization in XML)
  • ironJSON (irON serialization in JSON)
  • commON (CSV serialization to be used in spreadsheet applications)

I will show you how you can use OSF for Drupal to export entire datasets of Entities, or how to export Entities individually. You will see how you can configure Drupal such that different users roles get access to these functionalities.

I will also briefly discuss how you can create new converters to support more data formats.

Finally, I will show you how Drupal can be used as a linked data platform with a feature that makes every Drupal Entities dereferencable on the Web1. You will see how you can use cURL to export the Entities‘ descriptions using their URI in one of the 6 supported serialization formats.


tut_11_blog_400 
Apr 22 2014
Apr 22

This screencast will quickly introduce you to ontologies, and will explain you what are their rules in the Open Semantic Framework (OSF).

You will see how you can manage ontologies in OSF using the OSF for Drupal web interface. You will be able to import, create, update, delete and export ontologies. You will see how you can search within imported ontologies, how you can manage their permissions.

Finally you will see how you can manage the ontologies themselves: how you can create, update and delete classes, properties and named individuals using the Web user interface.


tut_10_blog_400
Apr 21 2014
Apr 21

In this screencast, you will discover how you can use the OSF for Drupal user interface to browse, filter and search for Resource entities that have been indexed in Open Semantic Framework (OSF) datasets. You will see how you can use it to manage what you want to expose on your Drupal portal.

Then you will see how you can create, update, delete and export Resource entities using Drupal.

Finally you will discover the revisioning system, and the revisioning user interface that is available to the Drupal administrators.


tut_9_blog_400
Apr 18 2014
Apr 18

This screencast introduces you to another one of the most important OSF for Drupal connector: the OSF FieldStorage module. What this module does is to create a new FieldStorage type for Drupal7. It enables Drupal7 to save the values of its Content Types fields into another storage system than the default one (i.e MySQL in most of the cases).

Because of the way that the Field system has been designed in Drupal7, it is possible to save the values of different fields that compose the same Content Type bundle into different field storage system. For example, if your Content Type bundle is composed of 10 fields, then 4 of them could be saved into MySQL and 6 of them into OSF.

The main purpose of the OSF FieldStorage module is to be able to save Drupal local Content Type information into OSF. What that means is that all your Drupal7 local content then become accessible, manageable and manipulatable using the 27 Open Semantic Framework (OSF) web services endpoints. Your local Drupal content can then be shared with other Drupal instances that could use OSF for Drupal to connect to that same OSF instance and seamlessly republish/re-purpose that local content from the other Drupal portal.

Here is the documentation of the architecture of this connector module.

This is the power of the OSF FieldStorage connector module. It supports the following Drupal features:

  1. Full FieldStorage API
  2. Entities caching
  3. Revisioning
  4. SearchAPI
  5. 29 field widgets
  6. Export feature in 6 formats

In this screencast, you will be introduced to Drupal7’s Field system. Then you will see how the OSF FieldStorage module creates a new FieldStorage type for Drupal7 and how it can be used. Then you will see how to configure the OSF FieldStorage module: to creating new Content Type fields that uses this osf_fieldstorage type, how to map these fields to RDF, how to use one of the 29 supported field widgets, etc.

Finally, you will see how you can synchronize existing Content Type pages (that was created before OSF for Drupal was installed on your Drupal instance) into a OSF instance.


tut_8_blog_400
Apr 17 2014
Apr 17

This screencast introduces you to one of the most important OSF for Drupal connector: the OSF Entities module. This module creates a new Entity Type called Resource. The description of these entities is managed directly into the Open Semantic Framework (OSF). All the calls to the core entity API function like: entity_load(), entity_save(), entity_create() and entity_delete() are operated with different calls to different OSF web service endpoints.

What this means for a Drupal developer is that they can use Drupal’s Entity API to manage instance records that are hosted remotely in a OSF instance. They don’t have to know how OSF works in order to take advantage of it. They just have to use the API they are used to use. This new Entity Type supports the following Drupal features:

  1. Full Entity API
  2. Entities caching
  3. Revisioning
  4. SearchAPI
  5. Templates selection with inference on their type
  6. 29 field widgets
  7. Export feature in 6 formats

The screencast introduces you to the following aspects of the OSF Entities module:

  1. Introduction to the architecture of the OSF Entities module
  2. Exposing the available entities in OSF into Drupal Bundles and Fields
  3. Browsing and searching for Resource entities
  4. Managing Resource Type bundles
  5. Introduction to the OSF Entity Reference field widget
  6. Creating and updating Resource entities

tut_7_blog_400
Apr 16 2014
Apr 16

In this new screencast, I first introduce the concept of a dataset: what it is, what it is used for and how it works. I will also outline the characteristics of datasets in the Open Semantic Framework (OSF) such as having a set of permissions for group of users, a unique identifier, etc.

Then I explain how datasets are being used by OSF for Drupal, and how they can be managed using a Drupal portal: how to import, create, register, change permissions to datasets. Then I explain how datasets can become searchable using the SearchAPI or be disabled in the web portal.

Finally I cover the OSF Entities administrators search and browse utility which can be used by Drupal administrators to browse and search for all entities that are accessible to the Drupal portal: even the ones that are indexed in datasets that are not yet registered to the portal.

tut_6_blog_400
Apr 15 2014
Apr 15

In this screencast, I explain how we can link (register) one or multiple OSF Web Services networks to a single OSF for Drupal instance. I discuss how this OSF Web Services mechanism can be used to bring datasets from multiple different OSF instances into the same Drupal portal. I also cover how we can use the same OSF Web Services network as the backend for multiple Drupal portals (which uses OSF for Drupal).

We briefly discuss the distributed aspect of the Open Semantic Framework (OSF), but this topic will be discussed more in deep in a subsequent screencast.

tut_5_blog_400
 
May 05 2012
May 05

Or: The What, When, Where, Why, and especially How

Versions of this talk has been presented at:

What are modules?

Drupal is designed to be modular. Instead of always having every possible tool or feature in every site's code, you can just have those you're actually going to use.

Drupal core —what you get when you install Drupal— is like a very basic box of Lego™: a platform and some basic bricks (modules) to get you started. You can do a lot with just those basics, but usually you'll want more.

That's where contributed modules come in. Contributed modules are packages of code that extend or enhance Drupal core to add additional (or alternate) functionality and features. These modules have been "contributed" back to the Drupal community by their authors.

When should you use contributed modules?

"The Drupal Way" can be summed up as both "Don't re-invent the wheel" and "Share and share alike". Although you may be perfectly capable of writing your own custom module to add some feature/functionality to your Drupal site, you should always first check to see if there is an existing module that does (or nearly does) what you want.

Using contributed modules not only saves initial coding time, it also makes it significantly easier for you and, especially, others to maintain the site in the future. Contributed modules also benefit from multiple eyes and multiple users to find problems and improve code.

Where can you find contributed modules?

Contributed modules live on Drupal.org, specifically, at http://drupal.org/project/modules. You can search the module list and filter it by category, Drupal version, and status. You can also sort based on most installed, title, author, last release date, etc.

Why should you choose one module over another?

Choosing which contributed modules to use is an art. There isn't an easy list of objective criteria to be checked off. There are, however, various factors that should be weighed when evaluating modules:

  • Suitability for your purpose
  • Release status
  • Recommendations by experienced Drupallers
  • Usage statistics (http://drupal.org/project/usage/[module_name])
  • Issue queue (not just outstanding issues, but response time, etc.)
  • Development activity
  • Author & maintainers

For more about how to choose modules, see Karen Stevenson's excellent session at DrupalCon Munich 2012 There Might (Not) Be a Module for That.

How do you install modules (step-by-step)?

For both Drupal 6.x and Drupal 7.x, there are just four major steps to adding a contributed module to a Drupal site:

  1. Upload the module code
  2. Enable the module
  3. Set permissions for the module
  4. Configure the module

The four steps in detail

  1. Upload the module code
    • Upload (install) the module's file directory into the sites/all/modules/ directory
    • Preferably, upload as a compressed archive (.zip, .tar.gz) and expand the archive on the server (rather than expanding on your desktop and uploading as a folder with individual files). This is both quicker and avoids potential problems with file permissions or invisible files not making the transition.
  2. Enable the module
    1. Go to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Enable (check) the relevant module and sub-module(s), if any.
    3. Scroll down to the very bottom of the page and click the Save configuration button.
  3. Set permissions for the module
    1. Go to:
      • Drupal 6: Administer->Site building->Modules, then click Administration by Module page in the third paragraph down (/admin/by-module).
      • Drupal 7: Modules (/admin/modules).
    2. Find the relevant module.
    3. If present for that module:
      • Drupal 6: Click Configure permissions
      • Drupal 7: Click Permissions
    4. Set permissions as appropriate.
    5. Scroll down to the bottom of the page and click the Save permissions button.
  4. Configure the module
    1. Go to:
      • Drupal 6: Administer->Site building->Modules, then click Administration by Module page in the third paragraph down (/admin/by-module).
      • Drupal 7: Modules (/admin/modules)
    2. Find the relevant module.
    3. If present for that module:
      • Drupal 6: Click [Module name] settings and, in turn, any other link(s) (besides Configure permissions or Get help)
      • Drupal 7: Click Configure
    4. Configure as appropriate.
    5. Don't forget to Save any configuration changes!

How do you uninstall modules (step-by-step)?

For both Drupal 6.x and Drupal 7.x, there are just three major steps to removing a contributed module from a Drupal site:

  1. Disable the module
  2. Uninstall the module
  3. Delete the module code

The three steps in detail

  1. Disable the module
    1. Go to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Disable (uncheck) the relevant module and sub-module(s), if any.
    3. Scroll down to the very bottom of the page and click the Save configuration button.
  2. Uninstall the module
    1. Return to the Modules administration page:
      • Drupal 6: Administer->Site building->Modules (/admin/build/modules).
      • Drupal 7: Modules (/admin/modules).
    2. Click the Uninstall tab.
    3. Select (check) the relevant module.
    4. Click the Uninstall button. 
    5. When asked "Would you like to continue with uninstalling the above?", confirm by clicking the Uninstall button.
  3. Delete the module code
    • Remove the module's file directory from the sites/all/modules/ directory
Mar 21 2012
Mar 21

(This is the second installment of a multipart series. The first installment was Hiring Drupal professionals, part 1: Know what you need.)

So, you're advertising/searching for the kind of Drupaller you need, now what? How can you know if you've found them?

This can be quite a challenge if you aren't very familiar with Drupal yourself. But the general principles are the same as for hiring any other kind of professional outside your own sphere of expertise. You want to look at their reputation, talk to references, check out their prior work, and watch for warning signs. Of course, there are some Drupal specific details for doing these things, too.

But before you can look at their reputation, prior work, and the like, first you need to know who they are. 

Who are they?

If they are an individual freelancer, do they use their own name in advertisements and on their website? If they use a company name, can you easily find out their real name on their website?

For a company, do they advertise under their company name? Can you easily find out the real names of those working for the company on their website? When checking reputations, you need to consider not only the reputation of the company as a whole, but also the reputation of the individuals associated with the company, especially those running the company and the individuals assigned to your project.

In short, you need to know who you're dealing with, and so should avoid any freelancer or company who is reluctant to let you know.

Who are they online?

If you haven't already found their professional or company website, ask for the URL. Ask if they have LinkedIn profiles, and if so, ask to see it. (If you can't see it without being in their network, ask to be connected, if only temporarily.) Ask if they have a professional Twitter account, and if so, what their Twitter handle/username is.

There are lots of good Drupallers who don't have LinkedIn profiles and/or professional Twitter accounts, but for those who do, checking them can help you confirm a positive impression (or improve a negative impression). 

Note that a pitiful website isn't necessarily a warning sign —the cobbler's children have no shoes and all that— but no website at all is strange for people who build websites for a living.

Who are they to Drupal?

Ask for their Drupal.org user number or a link to their Drupal.org user profile. (For example, my user number is 237528 and my profile can be found at http://drupal.org/user/237528). It is okay if they give you their Drupal.org username instead, though it requires more work on your part. (You can find a user's profile by searching for their username on Drupal.org and then, on the results page, clicking the "Users" link under "Or search for…".)

Not having a lot of activity on their Drupal.org account isn't necessarily a warning sign, but not having a Drupal.org account at all is strange for a professional Drupaller.

Warning signs

  • Advertising semi-anonymously, with only a phone number or first name and phone number. (For example, on Craig's List, stay away from ads that don't include either a company name or an individual freelancer's full name in the ad.)
  • No website. 
  • Website doesn't list any real names.
  • (Drupal specific) Won't tell you Drupal.org user number/profile link
  • (Drupal specific) Doesn't have a Drupal.org account

Now what?

So, you've advertised/searched for the kind of Drupaller you need and you know who the people who've responded are, now what? How can you know if any of these people are who you want? Stay tuned for the next installment in this series! (And I promise there won't be as big a gap between Part 2 and Part 3 as there was between Part 1 and Part 2!)

Jun 19 2011
Jun 19

I've been asked what I meant by "The Drupal Way" in my Drupallets blog post Hiring Drupal professionals, part 1: Know what you need.

In the Drupal community, "Drupal Way" is used in two related, erm, ways. The primary meaning is a general ethos or guiding philosophy, but it also gets used to refer to specific applications of that ethos. In my blog post, I was referencing the general principle, The Drupal Way, as a whole. But google "the drupal way" and you will find lots of hits talking about specific applications of the Drupal way, that is, the Drupal way to do X or the Drupal way to do Y.

The Drupal Way, the ethos, permeates every aspect of Drupal, from coding to content. It is the very essence of the Drupal community. It can be explained many different ways, but I like to boil it down to this:

Don't re-invent the wheel.

Or, put another way:

Share and share alike.

Drupal is not just open source; it is also modular by design. Thus it is not just licensed to share, it is designed to share —easily and flexibly— because by sharing (by not re-inventing the wheel) we all benefit. We can build better, more robust websites more quickly if we take advantage of one another's work than if we do everything ourselves from scratch.

This design and ethos goes beyond the mere existence of contributed modules to add features and functionality. If modules are like Lego bricks, the API(s) are the pegs that let you snap them together firmly to build your creation. Yes, you could lash some bricks together using duct tape, but the result just isn't going to be as good; further, it'll make it harder down the line to make improvements and updates.

Even more fundamental is Drupal's separation of visual appearance (themes) from structure/functionality (core & modules) from site content. Keeping these distinct makes sharing and reusing that much easier. For example, no need to build a whole new site structure and migrate all your content every time you want to totally change the site's visual appearance —just upload a new theme and click a few buttons.

And then there is content. I don't think it is a coincidence that CCK (Content Construction Kit, now in Drupal 7 core as fields) and Views were developed in Drupal. These contributed modules are simply —brilliantly— extensions of The Drupal Way to content. They, and various other Drupal modules as well, make it easy to enter content once but use it many times in many places in many different ways in your site. (For you relational database fans out there: think of a Drupal site as one gorgeous web-enabled relational database for your content. Or, as I heard someone put it: a Drupal site is essentially "things and lists of things". But more on that in another post…)

Finally, it should be noted that The Drupal Way is a guiding ethos, not rigid step-by-step instructions. Not re-inventing the wheel doesn't mean using the exact same wheel for every project. As often as you will hear "There's a module for that…" you will hear "There's different ways you can do that…"

So there you have it: Don't re-invent the wheel. This is the whole Drupal Way. The rest is commentary — and now go learn. (with apologies to Hillel…)

Update: Others' commentary on The Drupal Way

I'll be keeping an ongoing list of other good discussions of The Drupal Way (and/or not re-inventing the wheel). Please post or contact me if you know of any others!

Jun 06 2011
Jun 06

(This is the first installment of a multipart series.)

As a Drupal trainer and consultant, I've been getting a lot of phone calls lately either asking if I have trainees to recommend or else hoping that the "consultant" in my job title is a synonym for developer. (It's not: I'm the kind of consultant who helps you figure out what to do rather than the kind that does it for you.) People are having a really hard time finding experienced Drupallers to hire.

At the same time, I've become aware of more and more Drupal projects that went horribly awry because the freelancer or shop hired, though perfectly good PHP coders, didn't really know or understand Drupal. (In just in the last few months, I've personally had not one but two clients who were site-rescue refugees from the same freelancer!)

Unfortunately, the increasing popularity of Drupal can add up to a double whammy for those trying to hire Drupal help. Not only is there a shortage of experienced Drupallers, but there is an increasing number of inexperienced Drupallers offering their services. And these difficulties are compounded by the fact that many of those seeking to hire, quite naturally, don't know very much about Drupal.

So how do you find good Drupallers so your project actually gets the power, flexibility, and ease of use for content creators/managers that led you chose Drupal in the first place?

The first step is to ask for the right thing. There are different kinds of Drupal professionals and most clients and companies seeking to hire Drupallers don't understand or ask for the kind they need.

Besides end users, there are three broad categories of Drupallers: themers, site builders, and module developers. Of these, only module developers actually need to be PHP ninjas

Themers are responsible for the site's graphic design, which in Drupal is independent from the site structure and content. A Drupal site's entire visual design can be completely changed with literally just a couple mouse clicks. (For a demonstration of the independence of content and theme, visit Drupal Gardens —note how the content remains constant as you change from theme to theme.)

Themers come in two flavors: those who customize existing themes (subthemers) & those who create entirely new themes. Only the latter need significant PHP skills, but even then, graphic design and CSS mastery are much more important. For subthemers, PHP doesn't hurt, but isn't vital; often only custom CSS is needed.

Site builders put together the site's structure —the data types, displays, menus, navigation, entry forms, access control, administration, and other functionality for the site's content.

Site builders have even less need for mad PHP skills. Much more important is information architecture, usability, accessibility, and the like. Very complex, feature-rich Drupal sites can be built using only existing core and contributed modules. Indeed, while having familiarity with PHP can help, you actively do not want someone whose first instinct is to code to solve problems. For Drupal, custom PHP should be the last resort, not the first. Re-coding the wheel defeats the purpose and advantage of using Drupal!

If custom PHP is needed for a site —that is, if there is some functionality needed that can't be achieved using existing contributed modules— then it should go in a custom module, which is where module developers come in.

For module developers, of course, PHP is a must. But to be a good module developer, you also need to have good site building skills; you need to understand and appreciate The Drupal Way and also have mastery not just of PHP, but of the Drupal API (and certain contributed module APIs).

I should clarify that there aren't impenetrable divides between these three broad groups. Many themers are also site builders, many site builders are also at least subthemers, etc. and naturally there are various specializations that overlap or even fall somewhat outside these broad three, such as performance optimizers who get into server configuration, etc.

Unfortunately, clients and companies new to Drupal rarely know much about Drupal beyond that it is a CMS based on PHP and databases. So they understandably, but detrimentally, focus on the PHP bit, advertise for "Drupal developers", and emphasize PHP skills in their criteria.

But in a labor market where any kind of experienced Drupaller is in short supply and where there are more good site builders than good module developers, advertising for module developers (which is effectively what advertising for a "Drupal developer" with PHP skills is) when what you need is a good site builder is not the best recipe for success. Good site builders know when to bring in a themer or module developer, but trying to hire a module developer before you even know if you actually need one just frustrates everyone.

Worse, remember those decent PHP coders who don't really know Drupal? They tend to be attracted to "Drupal developer" positions that emphasize PHP skills, too. And that's how sites end up with custom PHP code that is not only totally unnecessary but located in the wrong place (e.g., hacked core/contributed modules or everything in a single theme page.tpl.php file instead of in a custom module where it belongs) and an unsustainable site that doesn't work properly.

You're much more likely to be successful finding and hiring a good Drupal professional if you know what kind you need and ask for it by name. If you're new to Drupal, start by looking for a "Drupal site builder" and emphasize Drupal knowledge and web best practices, not PHP skills. If you already have a site builder but need a graphics professional for your visual design, look for a "Drupal themer" and emphasize graphic design and CSS skills as well as Drupal theming knowledge. If you already have a site builder but determined that existing modules can't do what you need, then it's time to look for a "Drupal module developer" (not just a "Drupal developer") and emphasize Drupal module development knowledge, especially Drupal core and contributed module APIs and best practices.

So, you're advertising/searching for the kind of Drupaller you need, now what? How can you know if you've found them? See the next installment in this series: Hiring Drupal professionals, part 2: Know who they are

[Added 5 Jun 2012] Especially for larger projects, a more expansive discussion of the different roles involved in creating (Drupal) websites can be found in Randall Knutson's great blog post Why Web Development is Like Building a House over at LevelTen. (Just make sure to translate their use of "Developer" to "Site builder"!)

May 28 2011
May 28

Updated! This is the version that I presented at Drupal Camp Sacramento Area at 10 am on 28 May 2011, updated & expanded from the version I presented at DrupalCamp @ Stanford at 10 am on 2 April 2011.

Session description

More than three score and ten useful contributed modules for building Drupal sites.

There are many really useful contributed modules to take your site beyond the basics of Drupal core. There are modules to improve, allow, and/or help with everything from accessibility to workflow, from images to input formats, and beyond.

This session will be of interest to beginner and intermediate Drupallers, as well as those who manage or hire Drupallers or who are just trying to decide whether to use Drupal.

(This functionality is part of core in Drupal 7.) indicates some or all of the module's functionality is part of core in Drupal 7.

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