matt glaman

DDEV is a local development stack built on top of Docker. It gives you all of your environment needs without messy configured on your host machine, without needing to know Docker or configure your own containers. Which is great, and makes life easier. Instead of just using DDEV to develop your site or application locally, why not also run your tests within it?

Working in object-oriented programming is great. You can define interfaces which specify a contract that implementers need to fulfill. You can then extend these to define your end requirement and provide the implementation. This also means you can guarantee an object that implements that interface will have a guaranteed set of known methods.

When I work, I try to follow the principles of Test-Driven Development. I have found it to aid me in writing cleaner code, identifying odd coupling of components or crazy accidental dependencies between components. It also lets me write my API first by using mocks against interfaces I have defined. PhpStorm's auto-test functionality speeds up my test-driven development process.

When it comes to Drupal and external data, I use Migrate. A lot. Like a lot, lot, lot. Many times this data is being imported over CSV files that are pushed to a server at some defined interval. Usually, the data can be derived directly from the CSV file itself, other times a custom process plugin derives data from other information.

I moved over to DDEV for my local development stack back in February. One of my favorite things is the ease of using Xdebug.

If you want to have multiple Solr indexes using Search API, you need to have a core for each index instance. For my local development stack, I use DDEV.

For a long time, I have had Google AdSense on my website. It generated enough revenue that I could hit the minimum payout of $100 about once a year, covering my hosting costs. Then, a few months ago, I found CodeFund by Gitcoin.

At Drupal Europe, Dries announced the release cycle and end of life for Drupal's current and next version. Spoiler alert: I am beyond excited, but I wish the timeline could be expedited. More on that to follow.

Here is a quick breakdown:

Today I was working on a custom Drupal 8 form where I needed an option to purge existing entities and their references on a parent entity before running an import. It seemed pretty straightforward until I saw "ghost" values persisting on the parent entity's inline entity form. Here's my journey down the rabbit hole to fix broken entity reference values.