DEV Community: Jon McLaughlin 🍄

Replacing the included PHP Xdebug module in MAMP Pro

Jon McLaughlin 🍄 — Tue, 16 Jun 2020 18:10:52 +0000

Introduction

I'm a fan of MAMP Pro (https://www.mamp.info/mamp-pro/). I do all my web development work on a Mac and I like the simplicity of having one MySQL server, one Apache (or Nginx) server, a centralized GUI tool for modifying /etc/hosts, and I can switch between any of the supported PHP versions by linking a virtual host to a different PHP-FPM service.

Where MAMP Pro fails me is that I am reliant on the PHP versions they have made a decision to build into the the app. Each PHP-FPM service is actually installed with the app's package. MAMP doesn't use the OS' PHP, and I'm mostly okay with this.

Unfortunately, the most recent version of PHP 7.3 that has been included in MAMP Pro 5.7 is PHP 7.3.9. There are probably a lot of reasons why I should be using a more current version of PHP (7.3.19), but this old PHP version also means that MAMP has bundled a bugged version of Xdebug (2.9.0). This particular version of Xdebug has a bug that will cause the PHPStorm debugger to trigger at the declaration of a function that contains a breakpoint rather than at the actual breakpoint. More information on this Xdebug 2.9.0 bug is at https://bugs.xdebug.org/view.php?id=1727.

Luckily, Xdebug is a module and not part of the actual PHP build. Modules can be compiled independently of the PHP code and I was able to easily upgrade the Xdebug that is included as part of MAMP. The Xdebug module does need to have knowledge of the PHP that you are going to install it into, so for that reason you can't simply link the PHP-FPM service to another Xdebug installed somewhere else for another PHP.

Xdebug has a great tool to assist: http://xdebug.org/wizard.

I use a Homebrew installation of PHP CLI instead of MAMP and simply following the standard Xdebug install or compile instructions would lead the an Xdebug module that was configured the the CLI PHP and not MAMP's PHP.

So some slightly modified instructions for when you get to the phpize part of the compile instructions found on http://xdebug.org/docs/install. My paths are based on a standard MAMP Pro installation on a Mac and are specific to PHP version 7.3.9 that comes with MAMP Pro 5.7.

Instructions

In a new Terminal window, enter /Applications/MAMP/bin/php/php7.3.9/bin/php -i.
Copy-and-paste the output of this command into the textarea that appears on http://xdebug.org/wizard.Click the form button to analyze your MAMP's phpinfo() output.
Follow the presented instructions, including downloading the most recent version of Xdebug to your ~/Downloads folder (xdebug-2.9.6.tgz at the time of this post)
If you used Mac OS's tar extractor instead of the tar command, you may have to go one level deeper for step 4 of the Xdebug instructions (cd ~/Downloads/xdebug-2.9.6/xdebug-2.9.6).
For step 5 on that page, you are instructed to run phpize from within the source code directory. Substitute this command: /Applications/MAMP/bin/php/php7.3.9/bin/phpize.
For step 6 on the Xdebug instructions, substitute this command: ./configure --with-php-config=/Applications/MAMP/bin/php/php7.3.9/bin/php-config.
Run make as normal from within the source code directory.
Follow the cp instructions on step 8. It should be something like: cp modules/xdebug.so /Applications/MAMP/bin/php/php7.3.9/lib/php/extensions/no-debug-non-zts-20180731 (make sure you are still inside the Xdebug source code directory)
You will not have to edit the MAMP php.ini file as instructed in step 9 of the Xdebug compile installation instructions. This is because we are replacing the older version of Xdebug with our newly compiled one. The MAMP php.ini will include the Xdebug module (xdebug.so) when you enable Xdebug in the MAMP Pro GUI.

Hopefully this helps you. It still might be better to build a whole new PHP, with a more up-to-date Xdebug, to replace the outdated PHP 7.3.9 that is currently included with MAMP Pro 5.7. However, this was quicker and simpler for me to accomplish, probably because of the great instructions wizard included on xdebug.org, and this solution got me back in business with PHP 7.3.

Consider supporting continued Xdebug development financially: https://xdebug.org/support

The Power Of Twig's Merge Filter With Drupal 8 Templates

Jon McLaughlin 🍄 — Thu, 05 Mar 2020 19:12:52 +0000

Rendering web content in Drupal is a little bit like building a web page that is an onion. You have to peel back the layers to find the right place to make changes. Luckily, most everything ends up at a suggested Twig template. The Twig template engine is one of the best things about Drupal 8. It is powerful and easy to use for all levels of developer proficiencies.

I often find myself creating Twig templates for different node content types and view modes. So, for example, I might have a Twig template in my theme that is named "node--project--full.html.twig". This template will get utilized for the "project" content types and when the "full" view mode is used.

This method allows me to put one field of the project content type in a specific place on the page. Maybe below it will be more fields that are in a 9 column space on the left, and a few more fields are in a 3 column space on the right.

Twig lets you use regular HTML to create the layout for this content type & view mode. You can then use simple Twig syntax to place various fields in various places of the layout.

<h1{{ title_attributes }}>{{ label }}</h1>
<div class="row">
    <div class="columns medium-9">
        {{ content.body }}
    </div>
    <div class="columns medium-3">
        {{ content.field_project_date }}
        {{ content.field_project_link }}
        {{ content.field_tags }}
    </div>
</div>

Very simple and works well, but what if you want to customize the rendered output that comes from each of those content.field elements? Drupal and Twig definitely allow you to peel back the onion and use a usage specific templates for each of those field elements. For example, you can put a Twig template named "field--node--field-project-date--project--full.html.twig" in your theme, rebuild the Drupal cache, and then you can get as specific as you want for the rendered HTML of that particular field when it is used in that particular content type ("project") and for that particular view mode ("full").

I use this pattern for simple changes to the fields. Maybe I want to add a "button" class to a link field when it is used in a specific view mode. Or maybe I want to use a specific field label. Drupal's pattern of template suggestions works well, but in the end you do end up with potentially dozens of field templates in your theme.

For simple customization of individually fields, particularly when the customization only applies to a node & view template, I realized there is a way to use Twig's merge filter.

Twig filters are simple utility functions that you can call on any variable that is in the Twig template's context.

Let's say I need to use a different label for a field in one particular view mode. Instead of creating a specific field template, I can just alter the node's template like so:

<h1{{ title_attributes }}>{{ label }}</h1>
<div class="row">
    <div class="columns medium-9">
      {{ content.body }}
    </div>
    <div class="columns medium-3">
      {{ content.field_project_date|merge({
        '#label_display': 'above',
        '#title': 'Year',
      }) }}
      {{ content.field_project_link }}
      {{ content.field_tags }}
    </div>
</div>

At this level of Drupal's render onion, content is an array of fields and each field is another array.

In this case, I'm changing the field label from "Project Launch Date" to simply "Year". I will still have to customize the output of the field formatter to just display a year, but most Drupal field formatters don't allow for label customization beyond showing or hiding it.

Most standard Drupal field formatters also don't allow for customization of the class attributes that get used when the field is rendered. You could create separate field templates or you could use various preprocess hooks in your front-end theme. A possibly simpler way is to just use the merge filter in your node Twig template:

    {{ content.field_project_link|merge({
      '#attributes': { 'class': ['my-custom-class', 'another-custom-class'] },
    }) }}

It is worth noting that these additional class attributes are being applied to the field wrapper. If you want to apply changes to the individual items of the field this would likely not be possible to do at this level of the onion. You might still need to create a "field--field-project-link.html.twig" template, but you could maybe avoid having to write a preprocess function for it if you just wanted to add some additional attributes to the link items:

  <div{{ attributes.addClass(classes) }}>
    {% for item in items %}
      {{ item.content|merge({
        '#attributes': {'class': ['button', 'primary']}
      }) }}
    {% endfor %}
  </div>

To do any of this you will have to have a good understanding of all the various Drupal render arrays that your fields might be using. One of the best ways to learn what is going on inside of a Twig template is to configure your IDE to allow you to place debug breakpoints within the template itself. Then you can just inspect the $context variable and see which theme function is being called when something like item.content is rendered.

I'd love to hear if you think this method makes things simpler or more complicated.