Following up on my previous article about using Drupal migrations to modify content, this article looks at importing new content into a site. I give examples of migrations that create paragraphs, nodes, URL aliases, and URL redirects.
Drupal’s migration system was primarily designed for migrating data into a site from an older version of Drupal or from some other CMS. Here I present examples of using Migrate API for a different use case: moving and adding content within a site that’s being restructured.
On June 30, 1987, when Delta Flight 810 had risen to about 1700 feet after taking off from LAX, the pilot reached for a switch to give him manual control of the throttle. In a butterfingers or butterbrains move, he accidentally flipped two nearby switches that shut off fuel to both of the plane’s engines. The crew spent the next 60 seconds scrambling to restart the engines, as passengers felt the plane drop about a thousand feet and prepared for a crash. The crew managed to get the engines started in time, and the plane landed safely in Cincinnati.
I like filling out forms. No, really, I do. I like how a complicated task like “record your medical history” or “file your income taxes” is broken down into small, discrete steps. I like the clear expectations about what I should and shouldn’t say.
If you hate filling out forms, I invite you to consider that a form is a reflection of the organization that created it. A form can be humane or inhumane, competent or incompetent. It can make your task easier or harder.
Recently I was adding a photo gallery page to a Drupal 9 site. When a photo was clicked/tapped, the link was supposed to take you to a larger version of the image. Instead, to my surprise, it gave a “page not found” error.
Unix has all kinds of pessimizations that seemed really cool in the 1970s when they were introduced. One of them is ATime.
When we last left off, we were able to cook up a service name of our choosing, and resolve it from a client. If we hooked up launchd stuff, we could also make it demand-launch (maybe that’s for another day). But we didn’t actually do anything with that resolution. There are several reasons for that, first, because actually crafting a message and sending/receiving it was covered by a prior article. But even more than that, there are actually a substantial number of design decisions around this task, and plowing ahead requires a lot of text.
I’ll start with the previous server/client, and flesh it out in small steps. In between the steps, I’ll outline design decisions, maybe some history, and pitfalls/sharp edges to be aware of.
Recently a friend and fellow programmer asked me how I learn a new language or platform. I answered that I do it with specific task in mind. Basically, I bumble along googling every little step until I complete my task. But I forgot to tell her about the pitfall of this method…
(This is a sort of simplified retelling of http://fdiv.net/2011/01/14/machportt-inter-process-communication with some added lore. You should probably start there.)
Much of the magic behind macOS and iOS (and all the derived xOSs - watch, appleTV, the stripped down versions in cables and touch bars and wherever else these things invariably end up) is performed with the assistance of other processes (including the kernel). Communicating between them is accomplished by various ways, but for macOS, the underlying mechanism is a client/server IPC mechanism powered by Mach, and the underlying currency is the mach port (mach_port_t).
During my time at Apple, I dealt with a lot of rather low-level systems treachery. It’s poorly documented, even internally, and asking for help has roughly even odds on getting a passive aggressive non-answer.
The cool trick for today is creating a “memory object.” A memory object is one or more physical pages that are wrapped in a mach port. With this, you can pass the port to another process, who can map the pages, creating shared memory. Or you can map the pages again in your own address space, to create a mirror, or with different permissions so you can expose read-only pages at an interface boundary while still having the pages be writable at a different address.