View Issue Details

IDProjectCategoryView StatusLast Update
0006957OXID eShop (all versions)2.6. Administer orderspublic2019-02-28 15:35
Status acknowledgedResolutionreopened 
Product Version6.1.2 
Target VersionFixed in Version 
Summary0006957: Problem with shipping method presentation in order view in admin panel
DescriptionSoo... problem is with view in admin panel:
Administer Orders > Orders > {CHOOSE ORDER} > Main > Shipping Information

See our attachments.

We made order on OXID fron page like simple customer. We had choosen german language in front page of shop.
Order was made without any problems.
When admin want to send mail about shiping information from admin panel, then something is wrong there.
On start OXID admin panel shows "Standard - DE", when we send mail, then after refresh iframe oxid will change language to "Standard - EN" in dropdown field ("Shipping with:").

Probably it is not what you wanted to do and now we have a question... Which language should be loaded in case from our screen shoot? orderlanguage? editlanguage? baselanguage?
Steps To Reproduce1. Prepare lang prefix in shipping method for each country, like ENG, DE to see results
2. Make a order
3. Go to admin panel: "Administer Orders > Orders > {CHOOSE ORDER} > Main > Shipping Information"
4. Check language in DROPDOWN field
5. ... now send mail with "Shipping info"
6. Check language in DROPDOWN field again
TagsAdmin, Languages, Pull Request, Solution Provided
BrowserGoogle Chrome
PHP Version7.1
MySQL VersionNot defined



2019-02-25 08:53


OXID-bug-deliveryset.png (99,438 bytes)
OXID-bug-deliveryset.png (99,438 bytes)


2019-02-25 08:58

reporter   ~0012793

This is first part of problem... because we think that this is small part of bigger problem but please first watch on this.


2019-02-25 14:59

administrator   ~0012798

I think here is a misconception of two mechanics.

1. active language in administration area.
2. active language while making the order of the customer.

While browsing the administration area the admin can choose the language to display the texts with. If you select the English language, but the shop was installed with the German language then all objects are displayed in English which were translated; the rest will stay German. The rest will shown with German translations.

-> When you saved the delivery set "Standard" in German to "Standard DE" (oxid: oxidstandard) and in English "Standard EN" (oxid stays: oxidstandard) then it's just a display behaviour you have triggered.

The mail is sent with the selected language of the customer. When the language English was active while making the order, the shop will send the mail also in English. Independent of the active language in the administration area.

When you have a look into the table oxdeliveryset for the delivery "oxidstandard" you will a record like:

oxid: oxidstandard
oxtitle: Standard DE
oxtitle_1: Standard EN

The order object has the information of the used language while doing the order:


$orderLang = (int) (isset($order->oxorder__oxlang->value) ? $order->oxorder__oxlang->value : 0);

it then calls the method: \OxidEsales\EshopCommunity\Core\Email::_getShop($orderLang)
which sets the language for the mail:

protected function _getShop($langId = null, $shopId = null)

All in all: The selected item of the dropdown box is chosen by the active language of the administration but it does not have an effect of the language used for the e-mail text.


2019-02-26 12:29

reporter   ~0012800

Last edited: 2019-02-26 12:37

View 3 revisions

Thanks for you reply! Really!

I have last question :)

Could you watch on video?

1. You want to say that this "automatic language switching proccess" in dropdown field after send mail with shipping info is correct? Yes/No

2. When i talked about deeper problem i meant view error.
I know that code under maybe have wrong architecture problem (model into model) but i made it only for an experimental approach:

class Order extends Order_parent {

    public function replaceOriginalTrackingUrl($oDelSet) {

        if ($oDelSet->oxdeliveryset__kiratrackingurl->value === '') {
            throw new WrongCarrierTrackingUrlException('Carrier tracking url is an empty string');

        if (strpos($oDelSet->oxdeliveryset__kiratrackingurl->value, "###ID###") === false) {
            throw new WrongCarrierTrackingUrlException('Missing ###ID### element in your carrier tracking url');

        $sReplace = str_replace("###ID###", $this->getTrackCode(), $oDelSet->oxdeliveryset__kiratrackingurl->value);

        return $sReplace;

    public function getShipmentTrackingUrl()
        $this->_sShipTrackUrl = parent::getShipmentTrackingUrl();

        try {
            $this->_sShipTrackUrl = $this->replaceOriginalTrackingUrl($this->getDelSet());
        } catch(WrongCarrierTrackingUrlException $oException) {
            $oLogger = Registry::getLogger();
            $oLogger->alert($oException->getMessage(), [$oException]);

        return $this->_sShipTrackUrl;


When i tried to access to "$this->getDelSet()" or even create new instance of DeliverySet and load it by "oxdeliveryset.oxid" in "Order" model - OXID throws me an error like on the screen.

If you will analyze it, you can see that OXID made a mistake. It took "oxv_oxdeliveryset_1_en" and "oxv_oxdeliveryset_1_de" in one sql query.
When i will switch admin language to Deutsch, everything is ok.


2019-02-26 12:30


error-sql.png (72,381 bytes)
error-sql.png (72,381 bytes)


2019-02-28 15:26

developer   ~0012802

Last edited: 2019-02-28 15:34

View 3 revisions

Hi there,

1. There is no really process behind that. It is just a loop and compares the given order shipment id and all shipment ids:

[{foreach from=$oShipSet key=sShipSetId item=oShipSet}]
    <option value="[{$sShipSetId}]" [{if $edit->oxorder__oxdeltype->value == $sShipSetId}]SELECTED[{/if}]>[{$oShipSet->oxdeliveryset__oxtitle->value}]</option>

2. After some debugging I found the cause for the language abbreviation mix in the query generating:


$oldTplLang = $lang->getTplLanguage();
$oldBaseLang = $lang->getTplLanguage();

replace with:
$oldTplLang = $lang->getTplLanguage();
$oldBaseLang = $lang->getBaseLanguage();

The reason is quite simple:
Assumed the base language of the shop is German (Id 0) and the used language for the administration area is English (Id 1), then we will get a mix of ids when the TplLanguage is used for the BaseLanguage afterwards.

Before executing the method (in the administration area context):
TplLanguage = 1
BaseLanguage = 0.

After building the mail:
TplLanguage = 1
BaseLanguage = 1

If you have the constellation that the order is made with the German language and you mark the order as shipped while the English language is active in the administration area but you do not send the mail, then nothing bad happens. If you check the selectbox to send the mail also, then the SQL error appears in the log.