Hi Paul,

That is very encouraging news thank you.

I will look forward to it.

My aim is to attempt integration with GoSweetSpot and NZ Couriers. I have great hopes!

This may be useful for you, I got it from our developer. Our documenation will be updated soon etc.

manual.pdf

OK great. I will study it. Thank you!

Dear JoomShaper Support Team,

I have successfully developed a shipping plugin for EasyStore that retrieves live NZ Couriers shipping rates via the GoSweetSpot API during checkout.

During development I discovered that the current EasyStore checkout workflow does not pass the first and second street address lines through to shipping plugins. To support the GoSweetSpot API, I needed to modify the following EasyStore core files to include two additional parameters (address_1 and address_2) throughout the checkout shipping process:

• /components/com_easystore/src/Controller/CheckoutController.php
• /components/com_easystore/src/Checkout/CartManager.php
• /media/com_easystore/js/checkout.site.js

The GoSweetSpot API (and, I suspect, other shipping providers) requires the street address in addition to country, state, city and postcode in order to return accurate shipping rates. Without these additional address fields, live rate calculations are not possible.

Although my plugin is now working successfully, modifying EasyStore core files creates an ongoing maintenance issue because those changes must be re-applied whenever EasyStore is updated.

Would the development team consider passing address_1 and address_2 through the checkout shipping workflow as part of the EasyStore core? Existing shipping plugins would continue to function unchanged by simply ignoring the additional parameters, while plugins that require more detailed address information could make use of them.

I believe this would make the shipping plugin interface more flexible and would benefit developers integrating EasyStore with a wider range of courier services.

I would be interested to hear your thoughts.

If it would be helpful, I'm happy to provide the modified PHP/JS files or a diff showing the required changes.

Kind regards,

Bruce Paine

Hi Bruce, thanks, I shared your info with our developer.

good news, we will add this in next update.

Wonderful! It will be a most helpful addition. Looking forward to it! Thanks again to you and your developer!

Hello JoomShaper Support,

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

As you know, I had already reported that the online documentation appeared to be out of date. You kindly confirmed this and told me that the development team was working on a new version. You 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