Barcodes

Hey @petervandoorn ,

The primary reason we use a QR Code instead of a barcode is because you can include significantly more data in a QR than a regular barcode, an you use much less space. Typically one of our barcodes holds somewhere in the range of 150 to 200 characters of information (sometimes less, sometimes more, but this is an accurate average range). For a ‘regular barcode’ that data would be somewhere around 7-9 inches long in barcode form. With a QR, we can fit that into a square that is less than 2×2, which actually fits on the ticket.

Despite this, if your client ‘requires’ it, and understands the severe limitations it incurs and extra work it could require, we can make it so. I assume, based on your comment, that you already have a lib you want to use to generate the barcode. Assuming that you do, you can use the ‘qsot-compile-ticket-info’ filter to inject your code (after priority 3000) in the form of <img> tags, as you probably found out. If the ticket has a quantity of 1, you must make sure that the ->qr_code property is set, with an <img> tag of the barcode. If the quantity is more than 1, you need to make one barcode for each of the tickets in the quantity, and store them in a numeric array ->qr_codes (has an ‘s’).

Once you have that, the barcode should replace the QR code on the ticket. Now, assuming you did not change the information that goes into the barcode (when compared to the info in the QR), you should just be able to start scanning, because the data has not changed, and really that is all the software cares about; however, if you did change the data, then you have a little more work ahead of you.

First, if you need to change the data of the barcode (so that it is not so overbearingly large), you can do so by hooking into ‘qsot-create-checkin-packet’, which you can find on opentickets-community-edition/inc/ticket/checkin.class.php @ 285. This filter will need to accept an array of data we gathered for the individual ticket, and pass back a string representation of it. As long as your filter returns something other than null, your data will be used instead of our core data. Looking at this code should explain how it works, but if you need guidance here, let me know and I will do what I can to assist.

Next, when scanning the barcode, we need to make sure that if you changed the data, that we interpret the data the same way you created it. You can do this by hooking into ‘qsot-parse-checkin-packet’, found in opentickets-community-edition/inc/ticket/checkin.class.php @ 326. This filter will accept a string representation of the data you packed above, and we will need it to return an array of the needed data, detailed on like 329. As long as you return something other than null, you logic will be used, and ours will be skipped.

Finally, if it is vitally important to figure out where ‘order_item_id’ is generated, you can track that back to one of two locations.

*opentickets-community-edition/inc/ticket/checkin.class.php @ 64*
This is the location that is used during the actual checkin process. This is probably not the location you are mostly concerned with, but I will back track it for your just for piece of mind. The ‘order_item_id’ key comes into this function from the function params. Those params are generated on line 37, above, which in turn calls _parse_checkin_packet() on line 306. Basically, in this particular location, the ‘order_item_id’ is parsed out of the checkin url data (the data that is stored in the QR code).

*opentickets-community-edition/inc/ticket/ticket.class.php @ 280*
This is the location that is used to generate the ticket output. This is probably the one you are concerned with. In this case, ‘order_item_id’ is parsed out of the ‘ticket code’ (on line 269). That ‘ticket code’ is pulled from the actual ticket url (the url used to view the ticket). _That_ ‘ticket code’ is generated via the generate_ticket_code() method (line 223) and stored in the databased in the the wp_qsot_ticket_codes table via the add_ticket_code_for_order_item() method (line 188) during the order creation process (or ‘add order item’ process). The ‘ticket code’ is parsed from the ticket url on line 269, which calls the decode_ticket_code() mehtod (line 241). That takes the ticket url and turns it into an array containing the order_id, order_item_id, and event_id.

In short, I do not recommend changing the QR to a tranditional barcode. Even at the absolute minimum length you can produce for information for it to hold (order_item_id, qty index, security code, and separators, which is 40-50 characters long), you are still looking at line 3-4 inches of barcode. Furthermore, the order_item_id, while a relevant number, is really handled in the background, and should not be the focal point of your investigation. If you really want to change to the barcode, investigate the ‘qsot-create-checkin-packet’ and ‘qsot-parse-checkin-packet’ filters, and assume that order_item_id will be part of the information for those.

I really hope this helps, and if you come up with a solid solution that does not have an outrageous barcode length, by all means, please share your solution, and we will do what we can to add it to the code.

Loushou

Hey @petervandoorn,

Sorry for the late response (a hectic week for me). To clarify, order_item_id should hold the WooCommerce order_item_id, the id that identifies a unique order item. If you are going to encode one piece of data, this is by far the most important. This id links it all together.

From the order_item_id, you can derive almost all information you need, which I think is what you want. You can use the order_item_id to look up the order_id, via the wp_woocommercer_order_items table. You can use it to find all of the meta data for the item itself, like quantity, paid price, and event_id, via the wp_woocommerce_order_itemmeta table. Finally, you can actually use this to find the actual reservation information about that specific ticket, found in the wp_qsot_event_zone_to_order table.

Keep in mind, one of the big powers of having the ticket system on top of a flexible cart like WooCommerce, is that a given ticket can exist on the same order as another (even several other) tickets, as well as non-tickets, like merch. Because there could be 10 different tickets for 8 different shows on a single order (or really any combination), having only the order_id is insufficient.

Consider that a user has purchased 2 tickets for today’s show, and 4 tickets for tomorrow’s show, and paid for them on the same order. Knowing the order number would then be basically useless, because you have no idea which tickets to check in, since ticket exist for today’s show and tomorrow’s show. The only way I can see knowing only the order_id could work is if you were only checking in all tickets for the same event on a given order at once, and knew the event_id before hand.

Then consider this. What if that same customer above went to today’s show with her son, who will be 15 minutes late to the show. She gave him his ticket so he could get in, after she checked in. If you check in the entire order of tickets when she arrives then there could be a problem when he finally makes it. The reason is because you already check in his ticket, but here he is 15 minutes late trying to get in. Who is to say that this is not some random guy who photo copied his buddy’s ticket and is tryint to get free admission.

The information that goes into a ticket is mainly used as a security check. Sure someone could guess one short sequential number relatively easily. But it would be much harder to guess several sequential numbers, and a few strings, in their exact configuration, in order to build a valid fake ticket. That is why when the checkin process happens we validate most of the data coincides with what we have on record.

If you want to shorten that as much as possible then really the only thing you can use to guarantee you will have enough information to check them in, is the order_item_id. With it, you can derive all other data. Taking out all the other data however does open you up to anyone with some minor technical skill being able to “fake” or “commandeer” a ticket. If there is one thing I learn at Defcon every year, it is that if you leave it unsecured, it will be hacked. Just make sure client is aware of that aspect of their request too. 🙁

Anyways, hope this helps understand order_item_id and why it is important. If you have any other questions about it, let me know.

Loushou

Hey @petervandoorn,

Yeah it is best not to assume for sure. That being said, I try to give most variables and functions names that fit. It is rare to see something like ‘$ambiguous_var_1’ or ‘$value2’, unless it has contextual sense inside the scope it is used. Still, translating between WC and our plugin is not always one to one, so it is best to not assume, and ask. You were right on, as usual.

Loushou

Hey @petervandoorn,

Firstly, to this point, everything you have asked / pointed out, have been pretty general, and really have a place in a public forum, since you seem to have a knack for identifying questions and comments before others do. Do not feel like you are taking advantage, because trust me, if we get to a point where your requests start fading into specialize support, I will let you know immediately. Further though, almost everything you have brought up has added to the product, not detracted, so keep it up without fear.

In regards to the actual request: you are quite right that the order_item_id belongs in the $ticket information when rendering a ticket. I am pretty sure I had it there at one point, but removed it. Looking though my notes though, there is no indication of why I removed it, and I cannot see or think of any reason why it would be imperative to do so; thus, I have readded the order_item_id to the $ticket object. You will now be able to access it (in the next version, 1.11.2) by doing this inside the ticket template:

echo "Order Item ID: ", $ticket->order_item_id;

Hope this helps, and I will ping again once the release is out,
Loushou

Hey @petervandoorn,

This is in the new release, 1.11.2. Let me know if there is anything else, and thanks for the great idea.

Loushou