V158 Japanese language pack

gernot:

Hello @pilou2
I'm finally at the point where I can install your very nice encapsulated shipping modules.
I'm however not having any luck with the Tarif module. I already realized that the plugin manager gives no error, modules simply do not show up if there is some issue.
I noticed that the admin/includes/languages/english/extra_definitions is missing the lang.tarifs.php file, so I added that file, but still nothing.
Can you advise please where this page should appear, and whether there is anything missing?
I did check your latest Github as well and the Tarifs module there looks the same as the 2.1.2j.

First, the lang.tarifs.php was not missing. It is only used for languages other than English to add constants for language strings that are saved in English in database. There is a new override system in ZC v2.1for theses database strings using this file for non English languages.

As you said for Tarifs plugin, it just disappeared without error or log file. The problem comes from a file name which has two _ like this __ instead of one:
**```
zc_plugins\Tarifs\v1.0.0\admin\includes\extra_datafiles\shipping_prices__definitions.php

**```
zc_plugins\Tarifs\v1.0.0\admin\includes\extra_datafiles\shipping_prices_definitions.php
```**

After the correction, you need to install Tarifs plugin again and you should find a new link in Modules, just under Plugins Manager.

Thanks for the feedback! It might have taken some time before I find this problem as when installed and set, you don't use it very often.

Many thanks for the prompt response, and explanations, as you can see the new ZC 2.1.0 functionality is still confusing me.
I removed the unnecessary language file, and renamed the offending file you pointed out.
Unfortunately, after re-installing (and uninstalling and re-installing again) still nothing appears in the modules dropdown.
Not sure how to obtain some kind of error message from the plugin manager unfortunately.

GitHub updated with the above correction.
It seems that this wrong file name was there since realse v2.2.1j. I am pretty sure it was working then and even when I released v2.1.2j... Perhaps something change in ZC files that does not accept this kind of error anymore.

Everybody who downloaded this pack before today's last GitHub update needs to apply this correction. It is not critical as it is only an optional functionality but that can be usefull and time saving.

gernot:

Many thanks for the prompt response, and explanations, as you can see the new ZC 2.1.0 functionality is still confusing me.
I removed the unnecessary language file, and renamed the offending file you pointed out.
Unfortunately, after re-installing (and uninstalling and re-installing again) still nothing appears in the modules dropdown.
Not sure how to obtain some kind of error message from the plugin manager unfortunately.

You need to have at least one shipping module installed. The shipping modules are creating the table Tarifs at install time, then Tarifs module will use it.
I tried to unsinstall and re-install again to be sure and everything is OK, I got the 'Shipping Pricing' link at the bottom of Modules menu.

Thank you once again. I do have all the shipping modules installed and enabled, and none of them showed any errors when configuring, but on checking the DB, there is no table named "tarifs". So I presume something did not go as planned with the plugin installation of the shipping modules. I will have a look again in detail tomorrow.

Hi @pilou2,
I have had a look at the 3 encapsulated shipping modules. It turns out that none of them touches the database: no configuration keys add (or removed if I add them manually), and no tarifs table created.
So I am trying to debug why this is so.

Hello @pilou2
So far the only oddity I have found is that the installer subdirectory is in lowercase, while the stanard says it should be written as "Installer". This applies to the 3 shipping modules as well as to the Tarifs module.
Still trying to find debugging possibilities to discover why the installers do not act on the DB.

@gernot
Hello,
I did more testimg, removing all files and deleting table, then re-installing from scratch and there was no problem at all. Table tarifs is created when installing one of the 3 plugins Yamato, Yubin or Sagawa. When installing plugin Tarifs, a new link (and page) is created in Admin Modules menu under Plugin Manager giving access to the 3 companies shipping rates.
When going to shipping modules page and installing one of the shipping modules, keys are added to configuration table.

Encapsulated plugins use some ZC 'helper' functions to do all this. Are you sure your ZC is properly updated to v2.1.0? It won't work with older files versions.

Can you install another plugin without any problem like POSM or Display logs?

Hello @pilou2
Thank you for your efforts. I'm sorry this has not been a good use of your time, please do not worry, I will report back on my own debugging.
But yes, the issue seems to be limited to these particular modules, I have installed several other encapsulated modules (Edit Orders, Stripe, Structured Data, etc.) without issues.
Maybe there is some functionality missing that I have not correctly ported from the Japanese language pack, but so far I have not found it (I am using a spreadsheet to document all the differences and their integration).

Quick update:
Summary: The Plugin installer is a tricky little beast. The issues are related to my customizations.
Long version:
I decided to go ahead and start working on various changes to the plugins while thinking on how to debug, starting with the Sagawa module.
For the _Sagawa.php class I use ISO codes for prefectures rather than the names. After I made that change, I reran the installer, and while no configuration entries were made, I noticed that the tarifs table had been created.
While keeping the (not really installed except in name) module installed, I installed the Tarifs module and could access the table fine.
Thus, it is clear that my customizations are the issue here.
I haven't yet been able to get the module installer to run even though I believe I have made all necessary changes to the sagawa.php shipping modules file, but it does appear that the Plugin installer is doing a lot more than I expected - I thought I could install the module, then debug it afterwards as needed.
Unfortunately, it seems that it is a hard job to debug an encapsulated module, compared to a non-encapsulated one, as the Plugin installer does not seem to generate any logs. But it is what it is.

Final update:
All solved - I am officially a dummy.
First, I installed the Sagawa module in unencapsulated form (slight mods to _Sagawa.php class and sagawa.php shipping module files), and this installed perfectly. After which I discovered I was missing a couple of custom functions needed only in the shipping modules.
After adding these in functions_addresses.php, I uninstalled the unencapsulated version and retried the now proven encapsulated version. Running uninstall correctly removed all configuration keys.
This is when I finally realized that installing the plugin does not create configuration keys - only the tarif table (which part I had already solved previously).
Installing the actual payment and shipping modules provided by the plugin then correctly inserted the configuration keys.

I hope this helps someone else when trouble-shooting in future.

Hello @pilou2
All issues with the modules resolved.
I did find that the _Yubin.php class had

   function GetSizeClass() {
        $a_classes = [
            [0,  60,  30],  // 区分,３辺計,重量
            [1,  80,  30],
            [2, 100, 30],
            [3, 120, 30],
            [4, 140, 30],
            [5, 160, 30],
            [5, 170, 30],
        ];
```where the last line should change 5 -> 6.
I've written my own boxing logic for my specific store requirements (boxing of wines), and noticed that in the original modules the $bgirth variable might benfit from being modulated to display as the available box size for the corresponding module. So instead of displaying "90 cm", it could possibly be more beneficial to state "100 size" as that would be the corresponding box size.

@gernot
Thank you very much for this correction. It has been updated on GitHub.
For the box girth, effectively, if you send products of regular size and use standard boxes, it might be a good idea to display the box category size. In my shop I had to send very variable size products, especially some long and thin ones which need custom cut boxes. In this case seing the real box girth estimation helps to avoid making boxes larger than charged on invoice. For example if estimated girth is 98, I really take care to make a box that is not over 100. In the contrary, if girth is 85 then I know I can use a box that fit approximatively without risk of oversize.

Hello @pilou2
Thank you for the explanation, that makes sense. I had been using Yupack Chilled (cloned from the Yupack module) and added it to the encapsulated plugin you provided. I attach the created and modified files here. The module uses the same tarif table as Yupack, but adds a surcharge. There are differences in the permitted sizes and delivery times. The icon is roughly created. In case you wish to add it to your plugin (maybe some cleanup to adjust to the plugin standards).
Attachment #20981
Note: Oops, I forgot to revert to using the original prefecture codes, but original code is in both the class and module file, merely commented out.

Hello @pilou2
A further minor issue with the shipping modules is that in the GetQuote() function in the _Yamato.php, _Sagawa.php and _Yupack.php classes, $this->quote['cost'] is undefined in the case of an error, such as when the parcel is oversize. This causes warnings in the logs.
I tested a simple workaround, by defining this->quote['cost'] = 'Error' (i.e., not a number, which might be accidentally used), and this appears to avoid warnings being generated.
Example for the _Yamato.php class:

if ($n_sizeclass < 0) {
    $this->quote['error'] = ($n_sizeclass == -1) ? MODULE_SHIPPING_YAMATO_TEXT_OVERSIZE : MODULE_SHIPPING_YAMATO_TEXT_DIMENSION_MISSING;
    // debugging - cost not available if error
    $this->quote['cost'] = 'Error';
} else {
    $this->quote['cost'] = $a_pricerank[$s_rank][$n_sizeclass];
}
```Probably it will be better to simply initialize cost and let it be overwritten with correct value later, since there may be several conditions being tested in different places for error.

gernot:

Hello @pilou2
Thank you for the explanation, that makes sense. I had been using Yupack Chilled (cloned from the Yupack module) and added it to the encapsulated plugin you provided. I attach the created and modified files here. The module uses the same tarif table as Yupack, but adds a surcharge. There are differences in the permitted sizes and delivery times. The icon is roughly created. In case you wish to add it to your plugin (maybe some cleanup to adjust to the plugin standards).
Attachment #20981
Note: Oops, I forgot to revert to using the original prefecture codes, but original code is in both the class and module file, merely commented out.

Thanks for the file. I had a look at it and I will add it as a new shipping module when I have time.
By the way, for the standard Yupack shipping module, I saw that the charge for 'weighted Yupack' is now 560 JPY for all destination instead of 510 and 520 before...

gernot:

Hello @pilou2
A further minor issue with the shipping modules is that in the GetQuote() function in the _Yamato.php, _Sagawa.php and _Yupack.php classes, $this->quote['cost'] is undefined in the case of an error, such as when the parcel is oversize. This causes warnings in the logs.
I tested a simple workaround, by defining this->quote['cost'] = 'Error' (i.e., not a number, which might be accidentally used), and this appears to avoid warnings being generated.
Example for the _Yamato.php class:

if ($n_sizeclass < 0) {
$this->quote['error'] = ($n_sizeclass == -1) ? MODULE_SHIPPING_YAMATO_TEXT_OVERSIZE : MODULE_SHIPPING_YAMATO_TEXT_DIMENSION_MISSING;
// debugging - cost not available if error
$this->quote['cost'] = 'Error';
} else {
$this->quote['cost'] = $a_pricerank[$s_rank][$n_sizeclass];
}

I actually corrected this last week (on GitHub) by intializing $this->quote['cost'] to Null, The oversized was already taken care of elswhere.
Thanks for your detailed screening and reports! It will hepl improve code.

Many thanks @pilou2,
I wil update the modules accordingly.

New Shipping module 'Refrigerated Yu-Pack' added to GitHub in development version 1.02.

@Gernot, I removed your specificities, the option over 25 Kg that does not exists for Chilled Yu-Pack and did some cleaning. The name 'Refrigerated Yu-Pack' was used rather than 'Yupack Chilled' because this is the name on Japan Post site. I resized the icon too.
There was a file missing in what you sent, catalog/includes/classes/observers/auto.yupackchilled.php. It is an observer used to activate/de-activate the module for some categories or products. Please check you have it in your custom version or these functions will not work.

Thank you @pilou2 for the corrections. I do have the catalog/includes/classes/observers/auto.yupackchilled.php file, but it seems I forgot to include it in the bundle I attached.