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:
-
Make sure after extraction folder name in plugins is MauticAdvancedTemplatesBundle
-
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)
-
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:
- 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
- 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;
}
- 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.
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:
Make sure after extraction folder name in plugins is MauticAdvancedTemplatesBundle
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)
On server execute plugins installation command:
sudo /usr/bin/php /yourMauticPath/public_html/bin/console mautic:plugins:installIssue:
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:installand as a result I was getting this error:
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:
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:
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:
Code Changes in SmsSubscriber.php:
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:
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.