Oct 18 2019
Oct 18

This is a beginner’s tutorial that will quickly get you up and running with media entities and a media entity browser in Drupal 8.

One of the best parts of Drupal 8 is the in-core feature of media entities. This allows Drupal to manage resources that otherwise it would not be able to. It accomplishes this by creating a bridge relationship between Drupal’s CMS, media files and external sources. It’s basically an entity referencing all kinds of media files like images, videos, documents or other external sources like Tweets, embed videos, etc.

This tutorial is for the core “media” module set up, not to be confused with the contributed module “media_entity” module. If your Drupal setup already has this module and its sub-modules enabled in your setup, you may want to migrate your setup to the core module “media” following the instructions on the project page at https://www.drupal.org/project/media_entity

First Things First, Enable the Media Module:

Enable the media module (NOT entity_media). The “media” module comes with Drupal core so you don’t need to install it. All you have to do is enable it.

Using the Drush command:

drush en media -y

- Or: In the Drupal’s interface, go to /admin/modules, search for media in the search box, check the Media module and install to enable the module.

Configure or Create Media types:

Once the Media module is enabled, it will create the basic media types. You can find these under the structure menu. Media types are entity types just like nodes allowing you to add custom fields and adjust or make new displays to your needs.

To keep things simple in this tutorial, I will concentrate on the “Image” Media type. But you can apply the same principals to any other type. The difference will be on how the sources are being added and display just like node types.

Display the ”name” field (optional) :

It’s my personal preference to always enable the “Name” field in the forms of media types. This way you will be forced to add a name to your media type that you can later use for searching in the media browser.
(For even more searching options, you can add taxonomy tag field to group resources and so on. But for this example, let’s keep it simple.)

For this example navigate to /admin/structure/media/manage/image/form-display

Now drag into the content area “Name” field and drag to hide or disable all other fields with the exception of the “Image” field, so all you have displayed on the form is the image and name field. This will come in handy when creating the media browser view in the next step.

Installing the Entity Browser Modules and Creating Media Browsers:

The media browser is what you will use to pick and add new images to the content where the media entity reference field is being used. It basically adds a widget for your field. The media entities can also be managed via the content page in the “Media” tab.

Install these Modules: Chaos Tools, Entity Browser:

composer require drupal/ctools
composer require drupal/entity_browser
composer require drupal/inline_entity_form

Then enable Chaos Tools, Entity Browser, and Entity Browser IEF.

drush en ctools, entity_browser, inline_entity_form, entity_browser_entity_form

- Or: In the Drupal’s interface, go to /admin/modules  Ctools, Entity Browser, and Entity Browser IEF (you may have to enable the entity browser first).

Create a View to Use in the Media Browser.

We create this view first, in order to use it in the media browser we will create later, to list the available images in the media browser.

1. Go to /admin/structure/views/add:

  • Name your new view “Image Media Entity Browser Listing” 
  • View Settings: Show: Media of type: Image sorted by: Newest first
  • Click on Save and Edit

2. Now Configure the view:

  • Top left under “Displays” click on the “+Add” button and select “Entity browser”
  • FORMAT: pick Table
  • Add FIELDS:
    • Name
    • Thumbnail - options:
      • Label: Thumbnail
      • Formatter: Image
      • Image Style: Thumbnail
    • Entity browser bulk select form - options:
      • Label: Select
  • Rearrange the fields in this order: Entity Select, Thumbnail, Name
    • Name (media) - options:
      • Check the “Expose this filer to visitors”
      • Label: Search by name
      • Operator: Contains
  • Save the view.

Create the Entity Browser for Image media:

Got to /admin/config/content/entity_browser and click on the “+Add Entity Browser” button.

  • General Setting tab:
    • Label: Image Media Entity Browser
  • Widget Settings tab:
    • Add widget plugin:
      • View - options:
        • Label: Image Library
        • Submit button text: Select
        • View, view display: Media Browser: Image Media Entity Browser Listing
      • Entity Form - options:
        • Label: Image Upload
        • Submit button text: Upload
        • Entity type: Media
        • Bundle: Image
        • Form mode: Default

Create a Media Entity Reference Field to Use the Image Media Browser

Congrats! So you already set up the media entities and the media browser. Now all you have to do is start using it on your content builds.

Now, whenever you’re creating content, you will have a field that opens the media browser on a modal window with options to search, select, and upload new images.

That’s it! - Now all you have to do is repeat the process, configure things to your preferences and soon you will be a pro on media entities. Next, I’ll add a few other recommendations if you want to improve upon your setup.

Recommended modules that can add more power to your entity setups:

  • embed
  • video_embed_field
  • entity_embed
  • dropzonejs

Migrating Existing File Fields:

If you are working on an existing Drupal 8 setup and you want to migrate old file fields to a media entity field, follow this tutorial for instructions: Basic Migration Of File Fields To Media Entities.

Happy coding!

Oct 18 2019
Oct 18

The Migrate File to Media module provides an easy way to migrate old file fields like images, files, videos, etc, into the media entities with a few drush commands.

So you can have an understanding of how the migration process works, In this tutorial, we will run through a few quick step-by-step instructions on how to migrate specific image field types to image entity reference fields.

Media Module

The core media module is what creates the “media” entity types. If you haven’t set this up yet, or if you are not too familiar with media entity setup, I highly recommend following this tutorial “Drupal 8 Basic Media And Media Browser Setup For Beginners”, before you continue with this tutorial. 

If you still want to continue with a basic setup of media entities, simply enable/install the core media module that already comes with Drupal 8 core (NOT the media_entity module). Upon installation, it will automatically create a few media entity bundles for you, including the image media bundle we will be using for this tutorial.

Migrate File to Media module

Now for the migration, install the “Migrate File to Media module” - ( Only compatible with Drush 9 and up )

composer require drupal/migrate_file_to_media

Enable the “migrate_file_to_media” module:

drush en migrate_file_to_media

It will warn you that it will enable the following (“migrate”,”migrate_drupal”, “migate_plus” and “migrate_tools”) if they’re not enabled yet.

Once we have all of this in place, we can start using some simple commands to do the work for us. However, first, we need to create some mapping so that the migration module knows from what source fields to what destination fields.


We can’t migrate a source without a road map and destination. In the example of this tutorial, we will be performing a migration of the field “field_image” (image field type), in the content bundle “article” (node entity type) into a new media entity reference field that we will be creating using drush commands.

When migrating a site with a vast amount of content, I recommend to become familiar with the site’s content structure, the document where all the images are located, and in what content type bundles.

Generate the destination media field in the article node types using drush:

drush migrate:file-media-fields node article image image

Command bisection:

drush migrate:file-media-fields [entity_type] [bundle] [source_field_type] [destination_media_bundle]

  • [entity_type]: (The parent entity type) In the case of our example, it is a node content type. But other bundle types, like paragraphs or taxonomies for example, can be used.
  • [bundle]: (The parent bundle type) In this example, the “article”
  • [source_field_type]: (The source field type) This will be the source field type. Not to be confused with the name of the field, but the type of field. When running the command, this will check for all the fields of type “image” as in this tutorial.
  • [destination_media_bundle]: (The destination field media bundle) This will be the destination field bundle type. This will create a media entity reference field of type “images” for every image field found on the parent node bundle type. It will also give it the same name with the suffix of “_media” as in this tutorial.


Ok, so we created the destination. Now let’s create the roadmap so that the migration knows where and how to migrate data from the old to new by generating some YML files.

Before generating the YML files, we need to generate/create a custom module where the new files will reside: (Just generate the module, don’t enable it yet.)

Basic module drupal generate command, run on web-root:

drupal generate:module
# Note: follow the instructions on the screen and give it the machine name “basic_migration_example”

- Or: Module generate command with all options for this tutorial, run on your web-root:

drupal generate:module --module="Basic Migration Example 101" --machine-name="basic_migration_example" --module-path="modules/custom" --description="Basic Migration Tutorial 101" --core="8.x" --package="Custom" --features-bundle=”no” --test=”yes” --dependencies=”no” --twigtemplate=”no” --composer --module-file

Once the module is generated, clear the cache:

drush cr

Now we are ready to start generating the YML files, run:

drush generate yml-migrate_file_to_media_migration_media

You will get something like this. For this tutorial please follow the instructions as follows:

Welcome to yml-migrate_file_to_media_migration_media generator!


 Module machine name:
 ➤ basic_migration_example

 Module name:
 ➤ Basic Migration Example 101

 Plugin label [Example]:
 ➤ article_media_basic_migration

 Plugin ID [example]:
 ➤ article_media_basic_migration

 Migration Group [media]:
 ➤ ( Press Enter Button to use suggested "media" )

 Entity Type [node]:
 ➤ ( Press Enter Button to use suggested "node")

 Source Bundle:
 ➤ article

 Source Field Names (comma separated) [field_image]:
 ➤ ( Press Enter Button to use suggested "field_image" )

 Target Media Type [image]:
 ➤ ( Press Enter Button to use suggested "image" )

 Target Field [field_media_image]:
 ➤ ( Press Enter Button to use suggested "field_media_image" )
# Be sure to use the name of the field inside the Media Entity for the Target Field, and not the name of the media field on the node. 
 Language Code [en]:
 ➤ ( Press Enter Button to use suggested "en" )

 Translation languages (comma separated) [none]:
 ➤ ( Press Enter Button "none" )

The new files will be created in your new module folder /config/install.

There will be two YML files generated per migration ID, these file names will be suffixed with _step1 and _step2. You can open these files and adjust them as needed, but for this tutorial, the configuration we gave it on the YML generation process is just what we need.

If you want to look at YML examples, you will find some under the migrate_file_to_media module folder: modules/contrib/migrate_file_to_media/migrate_file_to_media_example/

Once you install/enable the new module we just created for this migration, all the YML configurations will be loaded to your Drupal 8 database setup.

Editing Migration Configurations after installation:

Once loaded into the system, if you need to make modifications, you need to get familiarized with the configuration management interface and how it all works to make changes. Here is a good read on that: https://www.ostraining.com/blog/drupal/config/

Install a New Module and YML files:

Ok, so now that the YML files are created, let’s enable/install the new module, and the new YML configuration files will be added to the system as well.

Enable new custom module:

drush en basic_migration_example

And now, check the migration status by running: (This will also give you the generated migration ids)

drush migrate:status

You will get a result of something like this:

Group Migration ID Status Total Imported Unprs media article-media-basic-migration_step1 Idle 3 0 3 media article-media-basic-migration_step2 Idle 3 0 3            

Duplicate File Detection (!)

– This is an important step, DO NOT SKIP – In order to run migrations, first you need to run a file duplication check for all migrations.

drush migrate:duplicate-file-detection [migration-id]

For our tutorial, run file duplication checks run “_step1” of the migration. You will have to do this for every first instance of your migrations one by one as I have not been able to figure out another way to make this command just run through all in one command.

For this tutorial, run:

drush migrate:duplicate-file-detection article_media_basic_migration_step1

Check for existing medias (optional)

If you already have images or files loaded in the medias entities run this command to check for media duplicates:

drush migrate:duplicate-media-detection image --all
# Run: drush migrate:duplicate-media-detection -help for extra options 

Migration time:

Now, if all is set up correctly, we can run a migration:

Migrate all migration of media group by group id:

drush migrate:import --group=media 

- Or: Run single migration by ids:

drush migrate:import article_media_basic_migration_step1 
drush migrate:import article_media_basic_migration_step2 

If it all goes well, you should see that the imported will match the total and unprocessed will be 0. Run:

drush migrate:status

Results should look like this:

Group Migration ID Status Total Imported Unprs media article-media-basic-migration_step1 Idle 3 3 0 media article-media-basic-migration_step2 Idle 3 3 0            

Take a look at the content of your article. You will now see that the new fields have been populated with the right image media entity reference. Just adjust your displays to show the new media field and hide or remove them altogether with the old image field when all your migration is complete.

A few more drush migration commands that may come useful:

  • drush migrate –help
  • drush migrate:rollback
  • drush migrate:stop
  • drush migrate:reset-status
  • drush migrate:import  [_OPTIONS_] :
    • –feedback - Frequency of progress messages, in seconds or items processed ( great for debugging)
    • –update - In addition to processing unimported items from the source, update previously-imported items with new data
    • –group - Name of the migration group to run
    • –idlist - A comma-delimited list of ids to import or rollback. If unspecified, migrate imports all pending items or rolls back all items for the content set.
    • –limit - Limit on the length of each migration process, expressed in seconds or number of items
    • –rollback - Rollback specified migration(s) if applicable
    • –stop - Stop specified migration(s) if applicable
    • Less commonly used options:
      • –file_function - Override file function to use when migrating images
      • –force - Force an operation to run, even if all dependencies are not satisfied
      • –needs-update - Reimport up to 10K records where needs_update=1. This option is only needed when your Drupal DB is on a different DB server from your source data. Otherwise, these records get migrated with just migrate-import.
      • –instrument - Capture performance information (timer, memory, or all)

Further information on Drush Migrate Tools commands visit: https://www.drupal.org/node/1561820

Happy coding!

Sep 12 2019
Sep 12

The profession of building websites has seen many changes in the last few years. SEO, website performance, multi-screen responsiveness, and accessibility are no longer luxuries. On top of that, tools have emerged that have improved the development experience and simplified scalability. Finding a modern CMS or framework that can incorporate ALL of these considerations is difficult. Especially when the flexibility to be able to create unique websites is also important. This is where Drupal 8 outshines other frameworks.

Here is a list of major benefits that you are missing out on if your website is built in Drupal 7 (or below), WordPress, or most other common content management systems.

1. Website Accessibility, Security, and Scalability  

Accessibility - One of the major changes in web development these days is the standard of building sites that are easily accessible by all visitors no matter their abilities or disabilities. For some clients, this is no longer a luxury but a regulation. For others, there is no law, but they can be opening themselves up to discrimination lawsuits by not making an effort to build a site that is accessible. A well-implemented Drupal 8 site can automate many aspects of accessibility and facilitate best practices in maintaining the accessibility of the site. Compliance will also help your website gain points with major search engines.

Security - One reason that major companies and government agencies move to Drupal is because of its fast security updates, and the large community of experienced developers who stand behind it. Drupal 8’s adoption of standard technologies, such as Composer, makes it a lot easier to keep your site up to date and secure. This also means less time fixing the code and more time improving and adding new features.

Scalability - In the past whenever there was a new major release of Drupal, version 6 to 7, it wasn’t just an update. It really meant a full install of the new version of the Drupal core, then maliciously and painfully rebuilding and migrating custom code, configurations, users, and all of the content from the old site to the new site. In other words, hundreds of hours of rebuilding and months before the new site was ready. After Drupal 8, that will no longer be a problem. Drupal 8 was built to allow major updates without having to rebuild the site. Three to five years down the road, all you may need is a fresh facelift to have your website up to date with new trends. So taking the time to architect a well built Drupal 8 site will pay off in the long run.

2. Drupal 8 as API first

Drupal 8 was created as an API (Application Programming Interface), making it more powerful than ever. It now has the ability to skip the generation of all the HTML markup and simply serving the data required to be implemented on the front end of the website, allowing other technologies like javascript to serve dynamically generated pages specifically targeted to the user.

Best of all, it can be used to connect back and forth with other APIs to get any information you want to serve and share as a service. All of this is already built into Drupal 8 to serve any data without having to write one single line of code.

If you haven’t wrapped your mind around what this means yet. Let me give you a couple of examples of this: “Web Apps” & “Mobile apps”. These can be developed to use the same data living in Drupal 8. Your Drupal site becomes the backbone content management system without having to update multiple sources of data to keep things in sync. Think about it… your website, your mobile apps, your own intranet, and content from other places all managed in one place, making one perfect ecosystem.

3. Development  

Drupal 8 was completely recoded from scratch with all new improved code.  Many things that were a constant hassle in the older versions are now a breeze to build.

Migration of old to new: If you have a website with large amounts of content, for example, news, products, or blogs, setting up an automated migrating of all the data into Drupal 8 is possible from almost any source. Yes, that even means if your old website was built in WordPress.

One of my favorite development improvements for sure is Configuration Management. Now you are able to export and import configuration changes from a live site to your local development, or vice versa, without affecting content. That feature alone has cut hundreds of hours from my development workflow. This not only helps reduce the cost of overall development but it gives developers time to concentrate on getting the features built and not wasting time deploying already built features manually.

The implementation of Composer as the dependency manager to install and maintain modules, custom code, and patches, makes it super easy to create copies of your website in a development environment and automatically turn on all the development helper features by just having a few files on hand that are environment-aware. With a few simple commands to sync code and configurations, you are ready to develop and deploy in no time.

After a couple of years of developing in Drupal 8, I wonder how I was able to do without all the new development features for so long.

Drupal 8 is a dream-machine for large or small websites. All of these features make it quick to build a simple website and powerful enough to build the largest, most complex websites.  Drupal’s flexible and innovative system is only limited by your imagination.

Happy coding!

Mar 28 2019
Mar 28

There are a lot of migration articles online that explain how to edit YAML configurations and custom migration plugins, so I am skipping over that.

You should be familiar with the full migration concepts first.  But before you start the migration process, you will need to clean up a few things from the old D7 site as well as prepare the new D8 site to make it able to take the old data including installing new modules for specific field types. That is what this article is about.

By cleaning up data before and after migration things will go more smoothly, minimizing the need to write complicated YAML or PHP scripts.

IMPORTANT NOTE: Do not work directly from the live D7 site. It’s best to backup and export your D7 database to a new database first. This way you will be able to clean up the database content with a few SQL commands.

Now for the workarounds… including some helper SQL commands I use when doing a Drupal 7 to Drupal 8 migration.

1. The annoying “value cannot be NULL errors” in body_value on import.

This can happen in any field, but for this example, I will use the “body_value” column in the “body__value” table. For the sake of this example, this field is required by the default body field in D8.

In the old D7 database, “body_value” sometimes may be NULL. The simple fix, if you can get away with it, is specifying a default value. Maybe it can be a special string that you can go back after the migration and search with a simple SQL query to find all the missing values so that you can replace with actual content.

Option 2 is to copy content that can be used from another field or column.

In my latest migration, the “body_value” column was NULL in a large number of records, but I did have a value I could use in the “body_summary” column in every single record.

The quick easy fix is to run this query in the D7 database. In my case, it fixed 400+ records not only making the import smooth, but also correcting the storage of the content.

UPDATE field_data_body SET body_value = body_summary WHERE body_value='' AND bundle='>>REPLACE WITH YOUR BUNDLE TYPE<<';

If you just want to set the value to some default value, you can.

UPDATE field_data_body SET body_value = '>>REPLACE WITH SOME DEFAULT VALUE<<' WHERE body_value='' AND bundle='>>REPLACE WITH YOUR BUNDLE TYPE<<';

Here is another useful one if the D7 site was in English only. It will set all the records to have en(English) as default language instead of und(undefined).

UPDATE field_data_body SET `language`='en' WHERE `language`='und'

2. Importing Redirects issues to the new site.

In my experience, Redirects import without much of problem and do not make adjustments to the YAML file. However, I did notice that the Redirects status came in wrong. Redirects status code cannot be “0” or NULL in Drupal 8 so you have to default it to 301 (moved permanently) or any other acceptable HTML redirect code you prefer. Again you can edit the YAML or, for easy quick clean up, just run this code:

Run this on the D7 database before import:

UPDATE redirect SET status_code=301 WHERE status_code=0;
UPDATE redirect SET status_code=301 WHERE status_code IS NULL;

Or, run this on the D8 database after import:

UPDATE redirect SET status_code=301 WHERE status_code IS NULL;

3. Importing URL Aliases from Drupal 7 to Drupal 8 is easy.

Ok, this requires a little more work than just running a SQL command, but I promise it will save you a lot of headaches as opposed to doing the Drupal migration because the aliases may create all kinds of problems.

I found that the easiest way is to simply export the “url_alias” table from the old site and import it replacing the new Drupal 8 database “url_alias” table. The replacement of the aliases in the new D8 site is to be done as a final stage of migration. Once you have completed the full migration of your content, nodes, entities, taxonomies, configurations, etc., you have tested that all the content has migrated successfully and you are ready to wrap it all up. Then follow these steps:

First, if you are using “Pathauto”, make sure you have the module installed and the URL alias patterns to match those from the D7. Pathauto configuration is at: /admin/config/search/path/patterns

Delete the D8 database “url_alias” table so that you can replace it with the new table and run this command in the D8 database: (You may want to back up this table before deleting all of the URL aliases)

DROP TABLE url_alias;

Export the table “url_alias” from the D7 database and import into the new D8 database using your preferred database management application.

Fix the URLs so that it works with D8 and run this SQL commands on the D8 database:

UPDATE url_alias SET url_alias.source = concat("/",url_alias.source);
UPDATE url_alias SET url_alias.alias = concat("/",url_alias.alias);

Now let’s change the name of the “language” column to “lancode” in the D8 database:

ALTER TABLE url_alias CHANGE language langcode varchar(12);

Now, if you are using Pathauto, let’s auto regenerate any missing aliases: Check all the types of aliases to regenerate all. And make sure that the “Generate a URL alias for un-aliased paths only” is checked so that it doesn’t overwrite all the aliases we just imported, and let it run. (You may notice that it may only create a few, if any. That’s okay because if we did the job right, all the alias should already be created) /admin/config/search/path/update_bulk

Check and test that all your aliases are working.

In conclusion, if you take the time to clean up your data before the migration, things will be a lot easier. Also, if later you need to pull an updated database from the old site, saving all your SQL commands and tracking your process, you will be able to clean up a fresh database in no time for re-import.

Mar 29 2018
Mar 29

Creating a frosted glass effect using CSS is a better method than the old javascript hacks. Using CSS to create the frosted effect uses fewer resources from the site visitors computer by using the native browser rendering engine.

To test this just drag the frosted glass example in the top right of this page. 

Ok, without wasting much of your time I’m going to jump straight into it.

The main components used for a classic frosted glass effect are:

  • > The original content
  •  - - > The frosted glass container ( Exp. <div> )
  •  - - - - > Original content copy inside the glass container (the element that mimics the content on the page with a blur effect).

For a basic idea of how this works. Here is a simple example:

HTML structure:

 <div id="frosted-glass-mask" >
  <div id="body-content-clone" ></div>

The CSS:

 width: 100vw;
 height: 900px;
 background-image: url( background-image.jpg);
 background-repeat: no-repeat;
 background-attachment: fixed;

 width: 500px;
 height: 500px;
 overflow: hidden;
 position: absolute;
 border: #ffffff63 solid 2px;
 left: 40px;
 top: 40px;
 box-shadow: 6px 7px 5px #00000075;

 left: -40px;
 top: -40px;
 width: 1000px;
 height: 1000px;
 background-image: url( background-image.jpg);
 background-repeat: no-repeat;   
 background-attachment: fixed;
 filter: blur(10px);

In this example, I’m setting the background-attachment as fixed, so the backgrounds for the body and the #body-content-clone element align to the top of the window. This way, we won’t have to worry about aligning the clone element with the original, and won’t have to use complicated CSS alignments or javascript to align the elements.

Test the sample code

In order to create the frosted effect, we are basically mimicking the original content with the #body-content-clone, aligning it, and sizing it on top of the original content.

Once we have the content lined up with the content clone, we can apply the blur filter effect on the #body-content-clone{ filter: blur(5px) } .

Lastly; “#frosted-glass-mask”, the parent div of the cloned content, acts as the glass element masking the content inside it.

For added detail you can use the psesudo “:after” and/or “:before” to add inside shadows, highlights and whatever else you want to style the content to your liking.

As always, it’s up to you to get creative.

Try it and let me know how you liked this quick tutorial blog, and if you end up using it in your project, please share a link in the comments to see your work.

Happy coding!

Apr 13 2016
Apr 13

Whether you are new to Drupal or a total Drupal superstar with 1,000,000 hours on the metaphorical “Drupal wheel”, making decisions about what modules to update to what version is not as straight-forward as it sounds. We’ve found many situations where the Drupal update page actually suggests that you “upgrade” a module to an older version. This has resulted in regressions and extra work more times than we’d care to admit. But it is clearly a problem begging for a good solution.

Our first solution to the problem was extensive training about the various situations you run across and what to do, but when updates are performed only once a month it’s hard for even the most experienced Drupal developer to remember every nuance of the “rules.” Enter… the Update Extended module. It brings into code all of those “rules” and provides more information and options to help you make good decisions about what modules to update to what version.

TL;DR The Update Extended module does super cool stuff and will make your update decisions easier! (Trust me, you will thank me later.) Let’s dive into its impressive benefits.

To give you an idea, here are a few scenarios where this module will prove extremely helpful to your website(s):

The Update Extended module will give you the option to update to the newer “-dev” version and will default to that newest version, “-dev” or full, if the currently installed module is “-dev”.NO MORE mistakenly regressing to an older version of a module — creating chaos in the universe!

Suppose you need a module on your site that has a bug somewhere that is only fixed in the “-dev” version so you install that release and now it all works perfectly. But a week later, it comes time to do updates and there is a new “-dev” release but not a new full recommended release.

Problem: The update page, out-of-the-box will show an update to the “recommended version” (Full Release), even though it is an older version. And you may end up reverting the module to the older version that still has the bug. You have to remember to compare the dates of the two versions.

Solution: The Update Extended module will not only give you the option to update to the newer “-dev” version, it will default to that newest version, “-dev” or full, if the currently installed module is “-dev”. This prevents the regression. Catastrophe averted!

NO MORE spending hours sweating and slaving away with updates on multiple websites!

Problem: When updating multiple sites the biggest problem is deciding if updating a module will regress it to an older version if you have one or many -dev versions installed. That means you have to diligently check sites one by one, again and again — Uff! I’m sweating just thinking about it!

Solution: You guessed it … Update Extended … you’re so smart! Since the module intelligently selects the correct version to update to, it’s easy just to do a  “select all” at the top and run the update. It will cut your time by a significant amount so that you can update your status on Facebook. Oh! I mean do some wicked development work.

NO MORE playing a guessing game — Oh Lawd, am I doing the right thing here???!

Besides adding extra modules and automatically selecting the latest one to download, I continued to further enhance the update by listening to feedback. I added visual elements that will make it easier to select the module option you want to make changes to. For now, it displays the date and time the module was created (if it is a major release), links to release notes, and tells you if the module is an older version than the one already installed.

Do you want more? Well, we think there is even more potential for this module, like Drush integration, so you are not dependent on configuration pages to get these benefits. If you have other ideas, please stop by the issue queue and leave a suggestion. Web development is constantly evolving and I just can’t wait to sink my teeth into the next challenge, or into a yummy breakfast taco. Either would make my day!

Once again, UPDATE EXTENDED — Download Here

Happy Coding!

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