The media_entity module is Drupal 8 (and its eventual inclusion in core) is great for managing these assets so that they can be reused, have fields, and included in nodes with the paragraphs module. For a new project, we’re importing faculty profile photos from a remote database into Drupal and want to be able to track the files locally so that we can take advantage of all these features, plus image styles and responsive images.

I found several examples that covered parts of this, but no single example that did everything I needed it to do, so this is a write-up of what I ended up using to solve this problem.

First, I wanted to create a separate directory inside the files folder to hold the images that this module would manage. I would like to be able to use file_prepare_directory() for this task, but in testing I wasn’t able to get it to create a directory with sufficient permissions. Calling file_prepare_directory() later in my procedural code would return false. So instead I’m using FileSystem::mkdir() which lets me pass the mode. This is based on the install process from the Libraries API module.

Next, I use system_retrieve_file() to import the file from the remote URL, create a File object for it and track it in Drupal’s managed files. There are a lot of examples out there that would have you use the httpClient class manually to fetch the file, or use standard PHP file functions and create the File object by hand, but I found using this function to be much simpler for what I was trying to do.

I then created the Media bundle based on the File I had just created. This code is based on this gist example. Lastly, I assign the Media object’s id to the Featured Image field of my node and then save it. I found this example of assigning media ids to fields to be helpful.

Our online Directory has been around in essentially the same form since the early 2000s, though I’ve rewritten it as a PHP application, then as part of Microsoft Content Management Server 2003 as a .NET 1.0 application, then as a PHP application again, and then as a .NET 1.1 application, and then upgraded it in .NET a few times. Along the way, it acquired a SOAP web service, which is accessible at https://directory.middlebury.edu/WebDirectory.asmx and is the primary interface for Directory information displayed in our Drupal sites, including profiles.

This fall, we needed to add a RESTful web service that returned some public Directory information as a JSON string for use in a mobile app. If I were doing the Directory all over from scratch it would probably be some MVC application with some nice endpoints that returned this data already, if it was in .NET, but that’s not the situation we’re in right now, so I had to find a way to hack a REST API on top of this thing.

Apparently, that’s possible using a Web Service ASMX file, which looks like a SOAP service, but with a few tweaks can act like a REST service. The gist below ends in .cs, but that’s just so the syntax highlighting looks nice. It’s really a .asmx file.

The first key is to uncomment the “[ScriptService]” notation above the class so that it can act as an AJAX response service, if needed. Next, above the method for the service response, add the notation “[ScriptMethod(UseHttpGet = true, ResponseFormat = ResponseFormat.Json)]”, which allows the service to accept GET requests and return a JSON response. Change the return type of the method to “void”, since we’ll just be printing our response directly, rather than returning a value that gets send via an XML wrapper.

The inner part of my search method is mostly program logic that creates an object and populates it with information from the Directory application based on the input query and business logic about what data to return. I decided to use the JSON.NET NuGet package after trying .NET’s native JavaScriptSerializer class, which kept pegging the CPU t 100% trying to serialize the object.

The JSON.NET object serializer offers a few more advantages. You can tell it to indent the response, if you want (I chose not to), and you can tell it not to include any property in the response where the value is null. For instance, if a person doesn’t have a telephone number, rather than returning “{phone: null}”, that portion of their record will just be blank.

Lastly, I write the JSON string directly to the HTTP response, which is why I earlier changed the method return type to void. With this in place, the service is now available at http://directory.middlebury.edu/RESTfulDirectory.asmx/Search?q=

Working on the conversion of our Museum of Art site, I ran into an issue with our “event” content type where we store the date and time of the event in a single datetime field, but want to display this information in two formats in different parts of the markup. In Drupal 7, we handled this using a preprocess function to access the data and set variables, but I wanted to find a more elegant solution in Drupal 8.

One option for this would be to have a, computed second field that stores the value again so it can be output twice in the node template and allow Drupal’s field API to format the output differently each time. I decided against this as it would require duplicating the data in the database.

Instead, I decided to format the date in the Twig template. Complicating this is that the date is stored as a string, rather than a timestamp in the database, so even if I tell the field API to format the output as a timestamp, there’s no way to directly access just that value without any of the markup.

To get around this, I set a variable in the Twig template to the value of the field piped to the date() function with the ‘U’ format, which will return an integer timestamp. This can then be passed into format_date() to have the date show up as desired.