Skip to main content
The order history shows the logged-in buyer their previous orders. Unlike in the basket, the data for this is not available as individual tags but as a stored order data record. This data record has no fixed tag list, but a structure of sections and parameters that expands with the shop’s functions. That’s why there are no tags with fixed names for the order history, but two construction forms. OH-S- navigates through the sections, and OH-P- retrieves a parameter from the section currently reached. In both, you insert the technical ID from the order data record. Guide: Integrating the order history · Materials: Order data overview

How the order data record is structured

An order data record is a nested structure. Sections contain parameters and further sections, and parameters contain values. The items of an order, for example, are stored as several sections of the same name Item within the OrderList section.
In the template, you work your way down from the top level. Each area tag {OH-S-…} goes one level deeper, and the corresponding end tag goes back up. Which sections and parameters exist is listed in the order data overview.
The three Country lines in the example show the basic pattern of the parameters. For the technical parameter Country with the value DEU, there can be a parameter Country_DName with the field label and a parameter Country_DValue with the readable value. The three tag forms below access exactly these three lines.
OH-S- comes in three forms, and they do three different things.
The double area tag around the loop looks cumbersome but is necessary. The loop counts the subsections of the parent section. Only the positive area tag above it sets the position to the Item level, from which the loop can work.
OH-S- is not valid as a single tag. ~OH-S-Item~ is an invalid tag. The two exceptions are OH-S-LoopCounter and OH-S-RawData, which are described below.
The CreditCard section is blocked in the template. {OH-S-CreditCard} is treated as an invalid tag in every form, so that credit card data does not accidentally end up on a page. You can get the payment method via the parameters of the Order section.

Outputting values

Within a section, OH-P- retrieves a parameter. The suffix determines which of the three lines from the basic pattern you get.
In the sample data record above, this outputs Land: Deutschland, while ~OH-P-Country_rawdata~ returns the value DEU.
OH-P-Country_noencode is not described in the previous documentation. It outputs the same value as OH-P-Country but omits the HTML encoding. You need this if the order data record already contains finished markup. All other forms encode, and you should leave it that way, because the data record can contain buyer input.
All OH-P- forms also work as area tags and take effect if the parameter exists and has a value. This lets you hide entire lines that are not filled for this order, without knowing the content.

Checking for a specific value

You can pass a comparison value to the area tag as an argument. It then only takes effect if the parameter has exactly this value.
The outer area tag checks whether the parameter exists at all. The inner, negative area tag hides the line if the discount is zero. Always compare against _rawdata, because that contains the unformatted value, which can be compared reliably.
The argument only has an effect with OH-P-… and OH-P-…_rawdata. With OH-P-…_text, the shop system does not evaluate it. {OH-P-Country_text(Land)} therefore always takes effect if a field label exists, regardless of the argument. The previous documentation describes the comparison for this form as well, which is not correct.
The comparison does not distinguish between uppercase and lowercase. This also applies to the technical IDs in the tag names themselves.
With the single tag, an argument has no effect. ~OH-P-Country(DEU)~ outputs the same value as ~OH-P-Country~.

The position in a loop

OH-S-LoopCounter outputs which pass the loop is currently on. It is exclusively a single tag.
The first argument is a modulo value and is suitable for alternating row colors. The calculation is modified so that the result is never zero, but always a number between one and the argument. Materials: Modulo calculation The second argument is the number of levels to go up from the current point. This lets you access the position of the outer loop in a nested loop.
If you only want to use the second argument, put a zero in the first position. The modulo value zero switches off the modulo calculation.
If the tag is in a place where no loop is currently running, it outputs nothing. This is not an error; you simply see a gap at this point.

Sections that only contain text

Some sections of the order data record do not contain parameters but a continuous text. The buyer’s comment is the most common case. OH-S-RawData retrieves this text.
OH-S-RawData always refers to the section currently reached and is therefore not supplemented with a technical ID. The area tag only takes effect if the section is actually a text section and contains text. In a section with parameters, the tag is treated as invalid.

Where the tags apply

The OH- tags work on the order history template, stored in the shop configuration shop.config in the <Templates> section under OrderHistory, usually ws_order_history.htm. They also work within the loop over the order list itself. There, they each refer to the order of the current pass, so that you can output several orders one below the other without changing the page. The tags that provide the order list and the entry point to an individual order are described under WS- (General tags).

The tags at a glance

  • Guide: Integrating the order history
  • Materials: Order data overview
  • Materials: Modulo calculation
  • Reference: WS- (General tags)