How to get this plugin working?

Hey @yoursql719 ,

I have read through your questions and the description of the steps you followed to achieve the results you currently have. It seems to me that the basic problem is that the path you are following to purchase the ticket is the incorrect process. Below are the discreet answers to each question, and some final notes about the problems in general.

Question 1:
Tickets are designed to be hidden from the shop. In fact, if you closely examine the edit product page, you will find that the ‘category visibility’ is forced to ‘hidden’, no matter if you change it or not. This is by design, with good reason, and can only be overcome by manually updating the database to circumvent it.

In the system, if you out right purchase a ticket from the product page or shop apge, then the ticket is not assigned in the background to an event. With out an event, the ticket is just basically a dummy product, not linked to any other information, and basically useless. Because of this, direct purchase is not recommended. Instead you should be using the event page interfaces to purchase your tickets.

The event page has a form on it, which asks the user how many tickets for this event they would like to purchase. Once they fill out the form, and reserve their tickets, they can then proceed to their cart and checkout normally. When this process is followed, the ticket gets appropriately associated to an event. Once that happens, the the wp-admin information for the ticket will fall in place, as well as the email ticket information. The fact that these steps were not followed, based on your descriptions above, leads me to believe that they are the primary causes for the issues that sparked the other two questions.

Question 2:
Assuming the above steps are followed when purchasing your tickets, your order completion email will have some extra links on it. By each ticket product that is associated to an event (meaning purchased from an event page, not the shop page), there will be a link that says ‘View this ticket’. Clicking this link will bring the user to an html ticket page. On that ticket page will be the event information, their ticket information, the logos of the event and venue, and the qr code. There is also a link at the top that they can click to down load the PDF version of the ticket for their records.

Question 3:
Based on your description of the process you followed, and based on the information I have provided above, it seems most likely that the reason that you report is lacking the information on the purchaser is because the purchase process I describe above has not been followed. If those steps are followed when purchasing a ticket, then the report will be appropriately populated with the billing/shipping information that the end user supplied at checkout.

Closing notes:
Most of these problems can be rectified by following a different set of steps to purchase your tickets. The recommended flow for an end user coming to the site should be something like the following:

– direct the user to a list of upcoming events. by default this is the calendar page, which is installed upon activation, and lives at http://yoursite.com/calendar/.
– the user should then click a link to goto a specific event’s event page. from the calendar this is done by clicking the box that represents the event they want to attend
– on that event page is a section of the page labeled ‘Step 1: How Many?’ at this point the user should select how many tickets they want, and click ‘reserve’.
– once they have some tickets reserved, a ‘proceed to cart’ button appears. when clicked, they go through the normal checkout process.

For most end users, the entire process is relatively intuitive, once they get directed to the proper entry point, like the calendar page. I recommend trying to run through this process above, yourself, and see how it flows for you.

There is one final thing that I should note. If you land on the calendar page, and there are no events listed, or if you are reading this and asking yourself ‘what is an “event page”,’ then chances are you have not yet set one up, which is definitely a problem also. This could cause most of the confusion you are experiencing. Try following the steps we outline on our Create your first event help page, on our website.

Hopefully you found this comprehensive and very helpful. If not hit us back, and we will gather some more information and go from there.

Loushou

Hey there @yoursql719,

I went through the checkout process on your site using the steps I describe above. The test order did manage to get accepted, and I do see that the tickets I selected are in the order; however, I see one thing that does send up a red flag for me. Take a look at this screenshot.

In the screenshot, I see the item I purchased is being displayed. What I do not see here is a link to the ticket. This is because, this payment processor (things like BACS and COD) puts the order into ‘processing’ until payment is received, which you have to manually confirm happened in the wp-admin. The reason that the ticket link is not showing (and also the reporting is off), in this case, is because the order is not actually ‘completed’.

Once the order is ‘completed’ the link to the ticket will be provided to the end user. Until then, they do not have access to it. In fact, until the order is completed, the ticket link does not even exist :). The system is designed to not give the end user access to their ticket until a payment for the ticket has actually been accepted and confirmed as collected (aka “completed” order status). This provides a level of security that prevents users from prematurely gaining access to their tickets, before you actually receive the money for them.

For other payment processors, like authorize.net or paypal (any version), this process happens automatically on checkout. The user enters their payment information, that information is processed in real time, and we get an immediate response from the payment processor. Because of this, using one of those processors will cause the order to go immediately into completed or failed.

In your case, you are using a payment method that requires an admin user to verify that a payment has been received. Usually this is done after a check has been received in the mail or cash has been supplied on delivery (or something similar). The normal process to accomplish this in basic WooCommerce is to browse to your site’s admin area, edit the order in question, manually set the order status to ‘completed’, and save the order. This action triggers a second “completed order” email (which is different than the first “order received” email). In this completed order email, there will be ticket links.

Also once the order has been completed, the necessary reporting is updated to reflect a purchase that has been paid for. This principle applies to both OpenTickets reporting and WooCommerce reporting. In your WooCommerce reports, you should see that money has been collected, and that an order has been taken. The OpenTickets seating report will also be updated, now showing that a ticket has been purchased and ‘paid’ for.

Thus my recommendation is to do one of two things to solve this problem during testing:

1. manually update the orders to completed in the admin, as you would for normal WC orders using those payment types.
2. use a payment processor, in test mode, that provides an immediate response, such as PayPal IPN (comes with core WC) or one of the purchasable payment processors off of the WC website. using one of these will provide the best real world emulation, since one of them will likely be your real world payment processor solution.

Hopefully this helps further. Let me know if it does not,
Loushou

Hey @yoursql719,

I will take a look into the Gernamized plugin you mention. It is possible that there is some sort of unanticipated conflict with OpenTickets Community Edition when that plugin is being used. This will take a little bit longer to investigate though, so I will have to ping back to you on that.

The images not rendering on the PDF are possibly because of the way the server is setup. 664 should be more than enough permissions to allow access to the file. In the past there have been a few reports about images missing from the PDFs; however, those situations were remedied by a code change that makes the images JPEGs instead of PNGs (specifically PNGs with a transparent color in them). This does not sound like the issue you are having. Your issue seems like the image is being looked for in the wrong location on the server. I will need to look further into the PDF library we are using, but it is also possible that this could be related to tmp directory access as well, but that is just a guess until I do more research into it.

As for the last question, ‘can the ticket pdf be an attachment,’ currently the answer is no for this. The primary reason for this is because, technically speaking, there is not actually a PDF file to send. The PDF is created on the fly and then send directly to the browser when the PDF link is accessed. It never actually manifests as a file on the server. This is a problem because in order to send it as an attachment (without a hackish workaround), there must actually be a file to serve.

That being said, this idea may be included in a future version, if a sufficiently elegant solution can be created to handle it. Until such a solution exists, the compromise to this that we would be able to add would be a direct link to the PDF in the email, in addition to the existing webpage version link.

I will do some more research into th Germanized plugin, and the image thing, and get back to you on them after that research is complete. I will also open a ticket to add a PDF link to the email, next to the existing webpage link, which should help.

Loushou