Sean Reiser

Hi I'm Seán Reiser, this is my Personal Blog

#NewYorker #DrupalDeveloper #InfoSec #Photographer #GEEK #Whovian #MYSTie #LetsGoYankees #LongSufferingJetsFan #NAKnight #Quinquagenarian #CommitAwesome

Drupal Rainbow

So I have a personal Drupal  site which has is currently on Drupal 9.  It’s had a long history on Drupal dating back to Drupal 4. Like many Drupalists, my personal site is my background project as well as the place I experiment on things.  It’s also the first site I migrate to new versions of Drupal.

The site had a photo content type with a file entity field and a couple of taxonomy reference fields.  It contains photographs I've taken.  In a modern D9 site this content type would be a media bundle.  But, since I migrated the D7 site to D8 early in D8’s life,  the media module wasn’t ready for prime time, and I left them as nodes instead of migrating them to media entities.  Since I got my hands on a Round Tuit, I decided to finally address this.

My goal is to create a media bundle which I'll call "photography", with the images and taxonomy attached.  In olden times I was lazy about adding alt tags to my images, so I want to populate empty alt tags with the image title (not perfect but better than nothing).   For now I'll attach those media entities back to the original node, with the goal of deleting the nodes once I'm comfortable that everything converted a-ok. 

So, I see 3 possible options to accomplish this:

  1. Drupal Contrib Modules
  2. MigrateAPI
  3. Write a custom module

Going through contrib I found the Migrate File Entities to Media Entities Module.  This module looks good for the average use case.  It creates fields and  migration scripts to do the migration. One feature on the module is duplicate checking.  The module uploads your file to a 3rd party service to generate a hash,  I don't need that for my photography, I know there are no duplicates.  If I were to use this, I'd also need to modify the migration YAML to add Taxonomy.  All this together made it so this was not the best solution for me.

So my choices how were either the MigrateAPI or write a module.  When the data source and data target are the same database I prefer writing a module, but I could've used migrate as well. Here's what I did:

The site has a Content Type called "photo"  The 4 fields I want to migrate are:

  • Title - a standard Drupal node title
  • field_photo - an image field containing the photo
  • field_photo_category : a taxonomy reference field
  • field_photo_tag : a taxonomy reference field

I created a Media Bundle called "photography" (photography sounds more serious than "photo".with corresponding fields:

  • Title
  • field_media_image
  • field_photo_category
  • field_photo_tag

I also created a field "field_photo_media" on the photo content type to store the reference to the newly created media entity.

Every site I build has a sitename_db_maint module which I use to for these little utilities that come up.  It's generally disabled and I'll enable it to run the utility, and disable it when I'm done.  I could've executed this through an update hook but for something like this I like to execute it explicitly by hitting a URL. If I was planning on a run with a larger number of nodes or something that could be run by a lesstechnical person, I'd add drush support and probaby batches. So I used drush generate to generate scaffolding for a controller, build the route etc.

Method convertNode2Media()  is where the work gets done.  The code does an entity query pulling all of the nodes in that content type.  I loop through the nodes, creating the media entity, assigning the fields, saving the media entity and assign the reference  to the new media entity back to the node and save that.  

You'll notice that if I'm missing an alt tag or title tag from the source, i'm assigning the node's title to these fields.

I added some simple logging and exception catching.  and the thing worked.  After some auditing, I deleted the photo nodes and content type.

Standard Disclaimer:  Test your code, backup you're database, don't run on live data.

Laptop w/ Stickers

This site has a linkblog and I thought I'd do a quick writeup on how I capture the links and their metadata.  You'll notice the the links are displayed in cards, similar to what you see on social media sites such as Facebook and Twitter.

This writeup will cover:

  1. The conten type to store a link and its metadata,
  2. Creating a bookmarklet so you can easily add a story to your site as you surf the web.
  3. Scraping metadata on a webpage to get the image, site name, title and description.

This writeup assumes that you have some basic understanding of Drupal on a site builder level.  I'm assuming you understand basic administration tasks such as creating content types, and fields as well as how to create a module,.  

Although I wrote the code for Drupal 9, as I review it, I see no reason that it won't work for Drupal 8.   Since support is ending for Drupal 8, you should be upgrading to Drupal 9, but that's a different matter.

Creating The Content Type

You'll need a content type to house the links.  On this site I'm using my generic note type which I use for most of my blog posts (this allows me to add a link to any post).  But I assume you want to use a separate content type, let's create a content type named link.  In addition to the standard title and body fields you want to give it the following fields::


Field Name

Field Type




OG Link Description


Text (plain, long)

OG Link Image Url


Text (plain, long)

OG Link Site Name


Text (plain)

OG Link Title


Text (plain)



Text (plain, long

HTTP Status Code


Text (plain, long)


Of course you can just add these fields to an existing content type as I did, you'll just need to adjust the code as you go forward.

Building the Bookmarklet

Simply put, a bookmarklet is a browser bookmark that contains JavaScript.  We're going to create one that will open a node add form with the url of the current page already prepopulated into the link field.  This saves you the effort of copying the current URL, opening your site, navigating to the node add form and pasting in the url of the page you want to blog.  There are 2 things we need ti do to make this work:

First we'll  get Drupal to accept a parameter on the node add form's URL and prepopulate the link field.  We either need to create a new module or use a module that you already use for glue code and use hook_form_alter.

This code basically says, "when loading the node add page for the link content type, look to see if there is a 'link' query string, and if there is, put the contents of the query string into field_link."

Next we need to get the query string into the URL .... that's where the bookmarket comes into play.  Here's a little javascript

You need to replace "" with your site's URL.  Just add a bookmark in your browser, call it something like "Add Link To My Site" and paste the javascript in as the link.  Add the bookmark to the favorites bar and when you're on a page that you want to blog about, click on the button, add any commentary in the body field and rock and roll.

There is a contributed module, Prepopulate which accomplishes the sane thing (and more) but is a little more overhead than the couple of lines of code I wrote here.  Plus, if we use contrib for the easy things, we'll never learn anything.

Fetching Metadata

Next we need to fetch the image url, site name, title and description.   You can either scrape the content for metadata server side at save or client side at when rendering the page.  I prefer doing it at save since doing it  doing it at client side will slow down page loads.  Of course, since you're caching the information, if the site changes any of the metadata, your site will be out of date.

Instead of writing code to parse out the metadata, I took advantage of opengraph.php, a library that does the heavy lifting,  Very simply, I used hook_ENTITY_TYPE_presave to populate the appropriate fields.  You can put this in the same module from above:

This loads the open graph library, loads the page info a variable and pass the page to the library to find the  metadata and then add it to the node before it's saved.


Laptop w/ Stickers
Upgrade To 9

Support for Drupal 8 ends in 4 months! Migrating is simpler than it was with previous Drupal upgrade.   Time is running out to ensure that your site will continue to be up to date and secure.

Due to the pandemic, Drupal 7's end of life was extended to November 2022.  It's a more complex migration.  Now is the time to start your migration to ensure success.

If you don't have a plan to migrate your site to Drupal 9, I want o help you.  I am actively seeking clients to help them have the most secure, up to date Drupal Website possible.

My Drupal Migration Services 


Lately I've been on a number of interviews and a common question seems to be, "What are your favorite modules?"  I seem to be misunderstanding the question.  

You see, I'll answer that question with a few minute soliloquy on a module like the convert bundles module and how it saved me a bunch of time  on a project where I had to merge a number of redundant content types.  Or how useful twig tweak was when I was trying to insert a block into the middle of a views listing.  Maybe discuss how I use Twig Debugger and Config Split to have twig debugging turned on in a dev region but turned off in live yet still have a common services.yml checked Into git.   You see to me "favorite" is an ephemeral thing, often tied into the problem I'm trying to solve at that moment.  And I felt an answer like this shows not just that I know a list of modules, but how I use them and helps the interviewer know my thought process.

When I answer this way, I get what feels like a combination of confusion and disappointment off the interviewer.  So I worked up the nerve on a recent interview to say, "I don't think I gave you what you want there, did I?".  She replied:

Most People Mention Views or Webform.

I immediately knew where the problem was.  I am interpreting "favorite" as "modules you have a passion for" not "modules you use on almost every build".  It's funny I have been asked "What modules do you use a lot?" and my answer to that is, "Views, Webforms, Paragraphs, Metatag, Media, starting to use Layout Builder, etc.".  But to me these are very different questions.  Much like if someone asks what my favorite beverage is, I don't mention water, although it should be the beverage I should drink most.

I also have to admit, when it comes to modules. I've become spoiled.  I start 90% of my builds with a custom install profile, based on Varbase.  I've configured a number of popular modules and don't think about them.

Either way, I live and learn.  


Ladies and Gentlemen
We Are On Drupal 9.


Politics aside… I’ve done a lot of work in Drupal, many amazing things. To be honest the expression “if you have a hammer everything looks like a nail” can apply to me and Drupal. If I were building a twitter like social network, the last thing I’d do is think Drupal, especially with platforms like Mastodon out there.

I’m in the middle of a Drupal 8 -> Drupal 9 migration.  After the data migration  I decided to nose around the database and found a number of tables that I believe are vestigial and should’ve been dropped a while ago:

  • Migration Tables - (migrate_map_upgrade_d7_*). tables that were used when I migrated this Drupal 7 into D8 5 years ago.
  • Empty Field Tables (node__field_*)  and Node Field Revision Tables  (node_revision__field_*)  that were from fields that were deleted years ago, generally from deleted content types.  This also shows up for paragraph, taxonomy and media bundles.

The fact that this stuff lingers around surprised me.  In my database management days, cruft always bothered me.  Is there any danger in clearing this out by hand (dropping tables)?  Do any developers monitor these things?


Happy Drupal Security Update Day!

Everyone should take note : [after the update] "Additionally, it's recommended that you audit all previously uploaded files to check for malicious extensions. Look specifically for files that include more than one extension, like .php.txt or .html.gif"

"find . -name \*.html.\*" and "find . -name \*.php.\*” should do it.

Good Luck, be safe and
May the Force Be With You!


Day 29