Forem: Graham Crocker

Send emails with php on mac quickly with mailhog and mhsendmail

Graham Crocker — Wed, 15 Mar 2023 17:04:04 +0000

Install Mailhog
brew update && brew install mailhog && brew services start mailhog

Check whether PHP can send mail

php -a

mail('test@test.com', 'subject', 'test');

Check http://0.0.0.0:8025/

If nothing appears the easiest way to fix this is to install MHSendmail

brew install go

go install github.com/mailhog/mhsendmail@latest

Get your php version and create a new file with respect to your version

php --ini
/usr/local/etc/php/X.X/conf.d/80-sendmail.ini

sendmail_path = /Users/xxxx/go/bin/mhsendmail

Restart PHP and try send mail again, it should work!

Investigating which events are being dispatched in Magento2

Graham Crocker — Thu, 17 Nov 2022 15:46:50 +0000

There are cases when certain events expected to be dispatched aren't, such as with product MassUpdate and individual product edit. Individual product edit dispatches catalog_product_save_after, but this does not apply to MassUpdate so we must investigate which events can be hooked in.

Go to vendor/magento/module-staging/Model/Event/Manager.php and in function dispatch below $eventName variable declaration add the following:

$eventName = mb_strtolower($eventName);

// devmod start
$filename = BP . '/var/log/events.log';

$writer = new \Zend\Log\Writer\Stream($filename);
$logger = new \Zend\Log\Logger();
#Fix for 2.4.x below
$logger->addWriter($writer);
$logger->info($eventName);
// devmod end

Magento 2.4.x Fix

$writer = new \Zend_Log_Writer_Stream($filename);
$logger = new \Zend_Log();

Before running your Magento process or journey

tail -f /tmp/events.log

Understanding Magento2 Versioning Specification

Graham Crocker — Mon, 22 Nov 2021 09:16:03 +0000

Introduction

The Magento version specification is quite complex. One need only read the release notes. Take the example of 2.3.0 and 2.3.1. A big release and another big release is my interpretation. You can spend a whole day reading them and trying to understand the difference. One may interpret that 2.3.0 brings about a lot of changes in terms of the way the system is run and in 2.3.1 a lot of improvements on it. There are further complications which I tackle later in this post.

2.3.0 release notes
2.3.1 release notes

Or maybe join me in my deep dive into understanding their versioning system by analysing the potential backwards compatibility breaks they introduce when upgrading your Magento instance.

Please note this is not a criticism or a bashing exercise, but simply a deep dive to help developers upgrade their systems by understanding the context of it. A lot of Magento is open-source and I encourage anyone to submit their pull requests if they think they handle backwards compatibility better.

Versioning Specification

Magento2 uses their own versioning specification, which may be interpreted as:
X - Different Application
Y - Major backward compatibility break extremely likely
Z - Major backward compatibility break possible
p - Patch Version where minor backward compatibility break is possible, but unlikely

For example 2.3.7-p2 may be interpreted as Magento2 version 3.7 with security patch version 2.

More info: https://devdocs.magento.com/guides/v2.3/release-notes/backward-incompatible-changes/reference.html

This differs from semver which is interpreted as:
X - Major version: Major backward compatibility break
Y - Minor version: No backward compatibility break
Z - Patch Version: No backward compatibility break.

More Info: https://semver.org/

Backward compatibility

Backward compatibility breaks means that something was changed to the effect that it can break functionality. A major one means major components stop working to the extent that the website fails to load (P0), because its no longer compatible with a service, or add to cart is not working (P1), because certain features now require enforcement like catalog permissions and so on. This may include some P2 issues. A minor one would break visual or functional website functionality (P3), but still allows the basic functions of the website to continue. This may also include P2 issues.

The relevance of Backward compatibility breaks are that you may have services installed that are no longer supported, code changes such as classes/methods or database changes using tables/columns that are depricated.

Case for or against backwards compatibility

There are several opinions about this.

Increasing backwards compatibility may make the application more convoluted and perhaps harder to improve the code base long term. Conversely companies will be more willing to upgrade to more secure and later version.

Decreasing backwards compatibility ensures that the application is trimmed off its extra code and enforces developers to use the more modern features and readapt their customizations such as writing more compatible code or using Interfaces rather than concrete classes in the DI. It also however makes upgrades more costly and time consuming especially for smaller businesses.

How Magento does it

Relative to semver, it might sound strange that a x.y.Z-p incompatibility could introduce a major break, but realistically if you're running a server using a php-fpm of version 7.2 and upgrade Magento from 2.3.5 to 2.3.6 may break your website (P0) due to incompatibility with 7.3 and from 2.3.5 to 2.3.7 is extremely likely as there are are significant backward incompatibilities in php 7.4 with commonly used methods.
If you spent 1 minute looking at each of the release notes of 2.3.0 to 2.3.1, one may read

We are pleased to present Magento Open Source 2.3.1. This release includes over 200 functional fixes to the core product, over 500 pull requests contributed by the community, and over 30 security enhancements.

This means that a x.y.Z-p release has nothing to do with size or backwards compatibility and rather to do with improving whatever x.Y.z-p release intended. Where matters are complicated is when Y versions are upgraded in tandem and one starts seeing features brought in by Y+1 in Y version.

What Magento do is generally release a x.Y.z-p version and run it in tandem with a x.(Y-1).z-p version, which is upgraded seperately. There are surely reasons for this, it is likely to introduce several significant changes in one area while allowing some vendors with heavy customisations to get the upgrades necessary in smaller iterations. This is how you end up with versions like Magento 2.4.0 being behind Magento 2.3.7 especially when you look at version compatibilty of services like composer or Redis that support the instance running. This makes sense when you look at release dates. Magento 2.4.0 was released 28 Jul 2020, but Magento 2.3.7 was released at 11 May 2021. See https://github.com/magento/magento2/releases

See systems requirements: https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements.html

Summary

A X.y.z-p version is wholly incompatible. It requires special purpose tools to migrate data and code or porting to a new instance.
A x.Y.z-p version upgrade is a very large release and usually a severe backward compatibility break, like a service incompatibility or removal/enforcement of services that support Magento, e.g. php version upgrade, or enforcement of elasticsearch for catalog indexing over mysql
A x.y.Z-p version, is a big release, but may still introduce severe backward compatibility break through incompatibility of services, code and database changes.
A x.y.z-P will include security fixes, which were orignally released on a patch list page on devdocs and installed via git patching. Explained in depth here. https://community.magento.com/t5/Magento-DevBlog/Introducing-the-New-Security-Patch-Release/ba-p/141287

Implement a strategy pattern in Magento2

Graham Crocker — Thu, 11 Nov 2021 19:31:25 +0000

The problem

Do you ever end up creating massive switch statements in functions in order to handle different behavior resulting in lots of logic in one place thats difficult to test or understand?

Take for example a type handler for an entity comprising of $X and $Y with these initial requirements:

If its of Type A then return [$X=>$Y], if its of Type B then return [ $X => [ $Y->getId(), $Y->getContent() ] ].

One could use a simple if statement:

if ($type instanceof A) {
    return [
        $X => $Y
    ]; 
} elseif ($type instanceof B) {
    return [
        $X => [
            $Y->getId(), $Y->getContent()
    ];
} else {
    throw new \InvalidArgumentException(__('Type: %1 is not supported', $type);
}

The above is perfectly acceptable, but what if the requirements change and you had to add several cases, handle errors with 3rd party modules for specific types or handle edge cases? You'd end up with something unmanagable and difficult to read and maintain. Potentially hundreds of lines of If statements, but then again you could improve and use a switch statement like so:

$typeClassName = get_class($type);
switch($typeClassName) {
    case A::class: 
        return [
            $X => $Y
        ]; 
    case B::class:
        return [
            $X => [
                $Y->getId(), $Y->getContent()
        ];
    case C::class:
        if ($X instanceof int) {
            // Do something
        } 
        if (is_array($Y)) {
             //Convert $Y into DataObject
        } 
        return [
            $X => [
                $Y->getId(), $Y->getContent()
        ];

    default:
        throw new \InvalidArgumentException(__('Type: %1 is not supported', $type);
}

Neater, but new requests keep coming in for further logic to add and eventually you'll spend time looking for the type to modify and worse still increase chances of making a mistake and adding a bug. A long convoluted switch statement will dramatically increase that chance, and as such this is a code smell and evidence of poor quality code.

The Solution

We know that data wise, its the same function (give us an entry based on the type of it), but the $type variable requires a different behavior. We can extend these behaviorial differences out into isolated classes limiting the scope of bugs on modification and increasing testability. This is a common design pattern known as the Strategy pattern, but how do we wire it up in something like Magento?

1. Create the Interface

These types all have something in common, a get() function, but we also need a way to discern from other types and one way to do it is test if it is applicable

<?php
namespace \Your\Vendor\Model\TypeMapper;

interface TypeInterface 
{
    public function get($X, $Y): array;

    public function is($type): bool
}

2. Create the Type Mapper

This class sets the context of the behavior, by looping over classes that implements TypeInterface until it gets the one which matches the type and implements the required behavior

namespace \Your\Vendor\Model;

use \Your\Vendor\Model\TypeMapper\TypeInterface;

class TypeMapper
{
    private $arrayOfTypeMappers;

    public function __construct(
        array $arrayOfTypeMappers
    )
    {
        $this->arrayOfTypeMappers = $arrayOfTypeMappers;
    }

    public function get($type, $X, $Y): array
    {
        $type = array_filter($this->arrayOfTypeMappers,
            function ($mapper) use ($fieldType) {
                if ($mapper instanceof TypeInterface) {
                    return $mapper->is($fieldType);
                }
         });
        if (count($type) !== 1) {
            throw new \InvalidArgumentException(__("Type %1 is not supported by %2", $type, self::class));
        }
        return current($type)->get($X, $Y);
    }
}

Wouldn't it be great if you could avoid this and get the classes implementing the Interface like you can do in .NET? get_declared_classes() unfortunetely won't work as PHP lazy loads classes. There is a way to preload specific folders in composer, but its rarely worth doing unless you're building something specific (like a microservice outside of Magento). We'll get to solving this in step 4.

3. Extend the Interface to create a concrete class/s

To keep this short, we're just going to implement one concrete class and add the declared classes in the di component

namespace \Your\Vendor\Model\TypeMapper;
use \Your\Vendor\Model\Types\A as TypeA;
class A implements TypeInterface
{
    public function get($X, $Y): array
    {
        return [
            $X => $Y
        ]; 
    }

    public function is(string $type): bool
    {
       return $type instanceof TypeA;
    }
}

4. Add the types to your etc/di.xml

See https://devdocs.magento.com/guides/v2.4/extension-dev-guide/build/di-xml-file.html#constructor-arguments for further info

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Your\Vendor\Model\TypeMapper">
        <arguments>
<argument name="arrayOfTypeMappers" xsi:type="array">
                <item name="a" xsi:type="object">
                    Your\Vendor\Model\TypeMapper\A
                </item>
                <item name="b" xsi:type="object">
                    Your\Vendor\Model\TypeMapper\B
                </item>
                <item name="c" xsi:type="object">
                    Your\Vendor\Model\TypeMapper\C
                </item>
                <item name="d" xsi:type="object">
                    Your\Vendor\Model\TypeMapper\D
                </item>
            </argument>
        </arguments>
    </type>
</config>

Step 5. Usage

Add \Your\Vendor\Model\TypeMapper as a property $typeMapper in the client class constructor and use $this->typeMapper>get($field, $X, $Y) to implement this functionality.

If you ever need to add a new type, simply create the class in the relavant directory, make it implement the interface and declare it in the di.xml as per Step 4. Modifying is simple and limited to the types you modify increasing quality of your code.

Give me a shout out if you found this interesting or helpful.

Create a Magento 2 Patch to override core

Graham Crocker — Tue, 02 Nov 2021 18:54:06 +0000

You may run into a situation where you need to modify core for some reason or another. In my career as a Magento2 developer there were many instances where we needed to do this and there are many ways to do it such as overriding/extending via preference or using a plugin, but I found that if you need to fix a Magento bug the best way of doing it is via a git patch, because if anything in the vendor/magento folder changes it will not apply the change and will be more visible to you, rather than spotting weird errors in logs a few years later when Magento2 fixes it.

You may also submit this fix as a PR to the magento2 github repository, but be advised that there is a lot of overhead that goes into proving a problem exists https://github.com/magento/magento2/pull/10102 and there are cases where this is not done such as this example case where we used a patch to fix an issue that was infrastructure related.
https://alanstorm.com/fixing-x-magento-tags-too-large-errors/

1. Commit the original state

Go into root directory

git init
git add vendor/magento
git commit -m 'init'

2. Commit your change

Make your code change
git add vendor/magento
git commit -m 'Description of your change'

3. Create the Patch

git format-patch -1 HEAD
cp x.patch patches/INITIALS-descriptionofchange.patch

Ensure the relative paths are a/vendor/x/y

4. Test the patch

Find the commit of init
git log
Reset vendor folder
git reset --hard <commit hash>

Execute the patch to check whether it applies or not
if git apply --check patches/INITIALS-descriptionofchange.patch; then git apply patches/INITIALS-descriptionofchange.patch; fi"

5. Add script to composer.json to apply the patch

Add to composer.json
"scripts": {
   "post-install-cmd": [
       "if git apply --check patches/INITIALS-descriptionofchange.patch; then git apply patches/INITIALS-descriptionofchange.patch; fi",
}

6. Conclusion

Ensure to run composer install to apply changes on CI/CD process or when pulling in other developers patches

Troubleshooting

If your machine can't handle git add to vendor/magento then go directly to the folder you need changing and do the process from there rather than from root directory. After you copy over the patch match the relative paths (where there is a/... and b/...) with the full path like a/vendor/magento.

If your patch is not applying, to find out why

git apply --reject x.patch

Create a custom virtual class logger in Magento2

Graham Crocker — Thu, 16 Sep 2021 20:38:38 +0000

There are a number of ways to create a custom log in Magento2 and one of the nicest ways to do is by creating a Virtual class by using the Dependancy Injection mechanism.

Create a typical skeleton module, in this case I named it YourVendor_Module and follow these steps

1. Create app/code/YourVendor/Module/Logger/Reporter.php

If you already have a class with a logger, adapt it to fit this basic structure.

At this stage this class writes info and error messages to the standard log filenames.

<?php
namespace YourVendor\Module\Logger;
use Psr\Log\LoggerInterface;

/**
 * Class Reporter
 * @package YourVendor\Module\Logger
 */
class Reporter
{
    /**
     * @var LoggerInterface
     */
    protected $logger;

    /**
     * Reporter constructor.
     * @param LoggerInterface $logger
     */
    public function __construct(
        LoggerInterface $logger
    )
    {
        $this->logger = $logger;
    }

    /**
     * @param string $message
     * @param bool $print prints messages from command line
     */
    public function log(string $message, bool $print = true)
    {
        if ($print) {
            echo __($message . PHP_EOL);
        }
        $this->logger->info($message);
     }

    /**
     * @param string $message
     * @param bool $print prints messages from command line
     */
    public function logError(string $message, bool $print = true)
    {
        if ($print) {
            echo __($message . PHP_EOL);
        }
        $this->logger->error($message);
     }
}

2. Create virtual logger in app/code/YourVendor/Module/etc/di.xml

This virtual class overrides Magento\Framework\Logger\Monolog and links to Logger Handlers which is where the filenames are specified.

As a matter of code readability namespace virtual classes under YourVendor\Module\Virtual.

<virtualType name="YourVendor\Module\Virtual\Logger"
                 type="Magento\Framework\Logger\Monolog"
    >
        <arguments>
            <argument name="handlers" xsi:type="array">
                <item name="debug" xsi:type="object">
                    YourVendor\Module\Virtual\LoggerHandler
                </item>
            </argument>
        </arguments>
    </virtualType>

3. Create and Link to the DebugLoggerHandler virtual class in di.xml

For simplicity, we log all messages to the yourvendor_module file by preferring the Base Logger, but if you require you can create as many virtual types as you want to route to what you like More Info

<virtualType name="YourVendor\Module\Virtual\LoggerHandler"
                 type="Magento\Framework\Logger\Handler\Base"
    >
        <arguments>
            <argument name="fileName" xsi:type="string">/var/log/yourvendor_module.log</argument>
        </arguments>
    </virtualType>

If you want to route Errors you can do something like:

<virtualType name="YourVendor\Module\Virtual\ErrorLoggerHandler"
                 type="Magento\Framework\Logger\Handler\Exception"
    >
        <arguments>
            <argument name="fileName" xsi:type="string">/var/log/yourvendor_module_errors.log</argument>
        </arguments>
    </virtualType>

Then go back to Step 2 in the xml and add the following argument to the arguments handler

<item name="error" xsi:type="object">
                    YourVendor\Module\Virtual\ErrorLoggerHandler
                </item>

4. Link the virtual classes with actual class in di.xml

To override any Psr\Log\LoggerInterface in any class, you need to replace the type name and fill the logger argument with your virtual class

<type name="YourVendor\Module\Logger\Reporter">
        <arguments>
            <argument name="logger" xsi:type="object">YourVendor\Module\Virtual\Logger</argument>
        </arguments>
</type>

5. Generate the files and upgrade

rm -rf generated/* or bin/magento setup:di:compile
bin/magento setup:upgrade
rm -rf var/cache/* or bin/magento c:f

If this helped you out send me some virtual love and subscribe!