Plugin not installing on Mautic 4.4.10 - I included solution

[iuriJorbenadze]

Mautic Version: 4.4.10
PHP Version: 7.4

If your Mautic 4.4.10 instance like mine did not work with default plugin achieve from github, you can use my ".zip" achieve of this plugin which I am attaching alongside this issue, In this .zip I have applied all fixes and which worked for me.
MauticAdvancedTemplatesBundle.zip

Installation instructions:

1. Make sure after extraction folder name in plugins is MauticAdvancedTemplatesBundle

2. Delete cache folder manually (With other plugins cache:clear was not always working for me so deleting cache fodler on server inside mautic root folder is recommended)

3. On server execute plugins installation command:
   sudo /usr/bin/php /yourMauticPath/public_html/bin/console mautic:plugins:install

Issue:

After Extracting plugin .zip and renaming it Mautic would not be assessable from browser because of Internal error 500 so I would have to install plugin using command on server: sudo /usr/bin/php /yourMauticPath/public_html/bin/console mautic:plugins:install

and as a result I was getting this error:

In FileLoader.php line 208:

  Expected to find class "MauticPlugin\MauticAdvancedTemplatesBundle\Config\config" in file "/yourMauticPath/public_html/plugins/MauticAdvancedTemplatesBund
  le/Config/config.php" while importing services from resource "../", but it was not found! Check the namespace prefix used with the resource.

Root Cause
This error occurred because config.php in the Config directory was being interpreted as a class file due to the wildcard loading pattern in services.php. Symfony’s dependency injection expected config.php to define a class MauticPlugin\MauticAdvancedTemplatesBundle\Config\config, but config.php was actually a configuration file, not a class.

Solution Summary
To resolve this, we adjusted the wildcard loading in services.php to load only directories that contained actual class files, and we explicitly excluded Config/config.php from being loaded as a class file.

This change was crucial in preventing Symfony from attempting to autowire config.php as a class, allowing the plugin to load its configuration correctly.

The installation of the MauticAdvancedTemplatesBundle plugin encountered several errors related to Symfony’s dependency injection and autowiring mechanism. These issues primarily stemmed from:

Misinterpretation of Configuration Files as Classes: Files like config.php and services.php were incorrectly being loaded as classes due to wildcard loading patterns.
Incompatibilities with Symfony Autowiring: Some classes used in the plugin required constructor arguments that Symfony could not autowire automatically, particularly for:
Logger dependencies expecting a Monolog\Logger instance rather than the more compatible Psr\Log\LoggerInterface.
String-typed constructor parameters that needed explicit configuration.

Step-by-Step Changes

Each issue and the corresponding change is documented below:

1. Configuration Files Loaded as Classes
   Problem: Mautic’s plugin loading mechanism attempted to interpret config.php and services.php as classes due to the wildcard loader used in services.php.

Solution:

In services.php, we avoided loading the entire plugin directory with a wildcard. Instead, we specified individual directories and explicitly excluded configuration files.
Code Changes in services.php:

$services->load('MauticPlugin\\MauticAdvancedTemplatesBundle\\EventListener\\', '../EventListener')
    ->exclude('../EventListener/Feed');  // Exclude subdirectories as needed

$services->load('MauticPlugin\\MauticAdvancedTemplatesBundle\\Helper\\', '../Helper');

// Avoid loading configuration files by excluding 'Config' or targeting only needed directories

2. Logger Dependency Issue in Event Subscribers
   Problem: EmailSubscriber and SmsSubscriber classes used Monolog\Logger as a type hint for their $logger constructor parameter. Symfony was unable to autowire Monolog\Logger directly, as it only provides Psr\Log\LoggerInterface for dependency injection.

Solution:

Changed the type hint from Monolog\Logger to Psr\Log\LoggerInterface, allowing Symfony to inject its default logger implementation, which is compatible with Psr\Log\LoggerInterface.
Code Changes in EmailSubscriber.php:

use Psr\Log\LoggerInterface;

public function __construct(TemplateProcessor $templateProcessor, LeadModel $leadModel, LoggerInterface $logger)
{
    $this->templateProcessor = $templateProcessor;
    $this->leadModel = $leadModel;
    $this->logger = $logger;
}

Code Changes in SmsSubscriber.php:

use Psr\Log\LoggerInterface;

public function __construct(TemplateProcessor $templateProcessor, LeadModel $leadModel, LoggerInterface $logger)
{
    $this->templateProcessor = $templateProcessor;
    $this->leadModel = $leadModel;
    $this->logger = $logger;
}

3. String Parameter Autowiring in the Feed Class
   Problem: The Feed class required a string-typed $feed parameter in its constructor. Symfony’s autowiring cannot resolve primitive types (like string) automatically, so an explicit configuration was needed.

Solution:

Defined the Feed service explicitly in services.php, setting a specific string value for the $feed parameter. Additionally, we excluded Feed.php from being autowired with a wildcard loader to prevent conflicts.
Code Changes in services.php:

use MauticPlugin\MauticAdvancedTemplatesBundle\Feed\Feed;

$services->set(Feed::class)
    ->arg('$feed', 'your_feed_value');  // Replace 'your_feed_value' with the required string

$services->load('MauticPlugin\\MauticAdvancedTemplatesBundle\\Feed\\', '../Feed')
    ->exclude('../Feed/Feed.php');  // Exclude Feed.php now that it’s explicitly defined
    

Final Notes
These adjustments ensure compatibility with Symfony’s autowiring standards and Mautic’s plugin structure. After applying these changes:

Clear Mautic’s Cache using cache:clear.
Reinstall the Plugin with mautic:plugins:install.
This should resolve the dependency injection issues and allow successful installation of the MauticAdvancedTemplatesBundle plugin.