EasyStore 2.1.0 – Custom Shipping Plugin Event Not Firing On Hosted DEV Site - Question | JoomShaper
Back to the questions

EasyStore 2.1.0 – Custom Shipping Plugin Event Not Firing On Hosted DEV Site

BP

Bruce Paine

EasyStore 1 week ago

Hello JoomShaper Support,

I would appreciate your advice on an unusual EasyStore shipping-plugin issue I am currently investigating.

I have developed a very small custom shipping plugin for which uses EasyStore's CommonShippingPlugin and subscribes to:

onEasyStoreGetShippingMethods

The plugin is working correctly on my local MAMP development installation, but the same plugin is not working on my hosted DEV installation.

Both installations are now running:

  • Joomla 5.4.8
  • EasyStore 2.1.0

I have also confirmed that the plugin source files are identical in both environments, including:

  • GoSweetSpot.php
  • CommonShippingPlugin.php
  • services/provider.php
  • the plugin XML manifest

The Joomla #__extensions records are also effectively identical apart from the extension ID and the saved API credentials.

I have traced the execution on the hosted DEV site and established the following:

  1. CheckoutController::getShippingCarriers() is definitely being called.

  2. It successfully finds the configured carrier:

    GoSweetSpot

  3. PluginHelper::isEnabled('easystoreshipping', 'GoSweetSpot') returns true.

  4. PluginHelper::importPlugin('easystoreshipping', 'GoSweetSpot') completes successfully.

  5. The GoSweetSpot plugin's own getShippingCarriers() method is definitely entered.

  6. The shipping address is correctly passed into the event, including country, state, city, postcode, address line 1 and address line 2.

  7. The event being dispatched is:

    onEasyStoreGetShippingMethods

    and the event object is a Joomla\CMS\Event\GenericEvent.

  8. However, on the hosted DEV installation, the plugin's:

    onEasyStoreGetShippingMethods(Event $event)

    method does not appear to be invoked, so no shipping methods are added to the event and EasyStore ultimately receives NULL for shippingMethods.

On the local MAMP installation, the same code and event mechanism works and live shipping rates are returned correctly from the plugin.

There is also a secondary symptom on the hosted DEV installation: the GoSweetSpot plugin configuration fields appear without their language labels, displaying the language keys instead (for example ??PLG_EASYSTORESHIPPING_GOSWEETSPOT_ACCESS_KEY_LABEL??). Language debugging confirms that Joomla is attempting to resolve those keys but is not finding the translations. The same plugin displays all labels correctly on MAMP.

I have checked the plugin XML language declarations, language files, namespace, service provider and extension database record, and cannot find a difference between the two installations.

The relevant part of CommonShippingPlugin is:

public static function getSubscribedEvents(): array
{
    return [
        'onEasyStoreGetShippingMethods' => 'onEasyStoreGetShippingMethods',
    ];
}

and the plugin class extends CommonShippingPlugin and implements the corresponding method.

At this point I am wondering whether there is anything in EasyStore 2.1.0's plugin loading/event registration mechanism, or in the way Joomla 5.4.8 loads EasyStore shipping plugins, that could cause the subscriber not to be registered correctly on one installation even though the plugin itself is identical.

The fact that the plugin works correctly on the local installation makes me suspect an installation, extension registration, caching/autoloading, or environment issue rather than the GoSweetSpot code itself.

Before I start reinstalling Joomla or EasyStore on the hosted DEV site, I would really appreciate your opinion as to what might cause this behaviour, or whether there is anything specific within EasyStore's shipping-plugin architecture that you think I should check.

I have deliberately kept the custom plugin very simple, so I am hoping this may be something familiar from EasyStore's side.

Many thanks for any guidance you can provide.

Regards,

Bruce Paine

0
8 Answers
Order by
Oldest Newest Votes
BP
Bruce Paine
Accepted Answer
1 week ago #232255

Note: GoSweetSpot is the name of my plugin.

0
Toufiq
Toufiq
Accepted Answer
Senior Staff 1 week ago #232280

Hi there,

Thank you for reaching out. Did you read documentation? If not, Please read the documentation.

https://www.joomshaper.com/documentation/easystore/how-to-create-a-custom-shipping-carrier-for-easystore

Best regards,

Toufiqur Rahman (Team Lead, Support)

0
BP
Bruce Paine
Accepted Answer
1 week ago #232305

Hi Toufiqur

Thank you for responding.

The documentation has helped me develop a shipping plugin which works perfectly in my local test environment.

However, I may have missed something related to different environments. Moving the plugin to a hosted environment from a local MAMP install appears to be the problem.

This led me to refer to the JoomShaper support team in case someone might be able to easily and precisely pinpoint the solution.

I will check the documentation again and let you know what I discover. I am sure the solution, once realised, will be helpful to others developing a shipping plugin for the first time.

Regards,

Bruce

0
BP
Bruce Paine
Accepted Answer
1 week ago #232309

I have reread the documentation and noticed the specific warning about DI registration and compatibility with the EasyStore plugin loading mechanism. This seems potentially relevant because EasyStore successfully finds and imports my plugin on both environments, but the onEasyStoreGetShippingMethods subscriber is only invoked on my local MAMP environment. Could you clarify what DI registration or plugin-loading conditions EasyStore 2.1.0 expects for a custom shipping plugin on Joomla 5.4.8?

Please note for clarity: When I refer to the DEV environment, I mean the hosted Joomla installation, not the carrier's API test/live environment.

0
BP
Bruce Paine
Accepted Answer
3 days ago #232552

Hello JoomShaper Support,

I wanted to follow up on my earlier discussion about the custom EasyStore shipping-plugin documentation.

In an earlier support request, I had already reported that the online documentation appeared to be out of date. Another team member kindly confirmed this and told me that the development team was working on a new version. He subsequently provided the manual.pdf from your developer, with the comment:

“Our documentation will be updated soon etc.”

I have now worked through the process far enough to get my custom GoSweetSpot shipping plugin successfully working with EasyStore and returning live NZ Couriers shipping rates.

Having gone through the exercise in detail, I wanted to pass back one particularly important finding that I think would be worth including in the revised documentation.

Case sensitivity can be masked by MAMP/macOS

I developed and tested the plugin locally using MAMP on a Mac. This initially made the plugin appear to be correctly named and structured even when there were inconsistencies in the capitalisation of the plugin name.

The reason is that the normal macOS filesystem is case-insensitive. In practical terms, a development environment such as MAMP can therefore mask errors involving names such as:

GoSweetSpot

versus:

gosweetspot

When the plugin was deployed to the Linux-based hosted environment, those differences became significant because the filesystem is case-sensitive.

This was particularly confusing for a relatively inexperienced Joomla plugin developer, because the plugin could appear to be working locally while failing after deployment.

I therefore think the revised documentation should explicitly warn MAMP/macOS developers about this distinction. Something as simple as:

“If developing on macOS/MAMP, be aware that the local case-insensitive filesystem may hide filename and directory case errors which will cause problems when the plugin is deployed to a case-sensitive Linux server.”

would potentially save a lot of debugging time.

Specific casing issues encountered

During troubleshooting I found that the plugin directory, XML filename and relevant plugin element references needed consistent lowercase naming. For example:

plugins/easystoreshipping/gosweetspot/gosweetspot.xml

and:

PluginHelper::getPlugin('easystoreshipping', 'gosweetspot')

At the same time, the PHP namespace/class names retain their normal PHP namespace capitalisation, for example:

Comfoot\Plugin\EasyStoreShipping\GoSweetSpot

Making this distinction explicit would be very helpful.

The provider.php example

The provider.php supplied in the PDF was particularly useful. It differs from the version currently shown in the online documentation, and it also differs in some respects from the downloadable sampleshipping.zip.

The significant point for my implementation was that the plugin configuration is obtained using the lowercase plugin element name and the resulting plugin class is then instantiated separately.

In my case, the working pattern includes:

PluginHelper::getPlugin('easystoreshipping', 'gosweetspot')

followed by instantiation of my GoSweetSpot class.

I initially had a mixture of GoSweetSpot and gosweetspot in different places, which contributed to a considerable amount of confusion while tracing Joomla's plugin-loading process.

The end result

After working through the Joomla plugin-loading process — including PluginHelper::importPlugin(), bootPlugin(), the provider and the event subscriber — I was eventually able to confirm that:

  • the plugin is loaded correctly;
  • the provider creates the correct plugin class;
  • onEasyStoreGetShippingMethods() is being called;
  • the plugin can make the GoSweetSpot rates request; and
  • live NZ Couriers rates are successfully returned to EasyStore.

So the integration is now working.

I wanted to send this follow-up because the case-sensitivity issue is something I would never have anticipated as a developer working in MAMP/macOS. I suspect other developers following the documentation could easily encounter exactly the same problem without realising that their local environment is concealing it.

Thanks again for providing the developer PDF and for passing my earlier findings on to your development team. I hope this additional information is useful when the documentation and sample plugin are revised.

Regards,

Bruce

0
Toufiq
Toufiq
Accepted Answer
Senior Staff 3 days ago #232598

Can you provide me your custom shipping plugin?

0
BP
Bruce Paine
Accepted Answer
2 days ago #232666

Hi Toufiq,

I would like to clarify that the plugin is now 100% working and there is nothing further for you to do.

In my last message, I simply wanted to share my experience in case the details were helpful to other developers.

The plugin is still under development and contains credentials for the client's live GoSweetSpot account, so I'd prefer not to send a copy.

I can, however, provide the relevant code or a sanitised version if you are interested in seeing my method.

Regards, Bruce

0
Toufiq
Toufiq
Accepted Answer
Senior Staff 2 days ago #232681

Hi Bruce,

Thank you for the clarification. I completely understand, and there is no need to share the full plugin, especially while it is still under development and contains the client’s live credentials. I appreciate you sharing your experience. It is helpful to know that the plugin is now working 100%.

Best regards,

Toufiqur Rahman (Team Lead, Support)

0