Skip to Content Skip to Menu

Programmatically generate purchase item

  • sstoks
  • sstoks
  • ONLINE
  • Posts: 1
  • Thanks: 0
  • Karma: 0
1 hour 35 minutes ago #343037 by sstoks
Hello,

For context: I "inherited" a web site for which I am now the webmaster.  This is a Joomla site which has been handled by various people for many years and by now it's frankly a bit of a mess.  I am not a Joomla expert and this is the first time I'm getting acquainted by it.  I volunteered because I'm an (embedded) software engineer and figured "how hard can it be".  I feel much more at home in a code editor than in a visual environment.
The site is for a society with <1000 (paying) members, and it uses CBSubs to manage that.  The society also (occasionally) sells items via a webshop (HikaShop) and organizes yearly events (with RSEvents) for which the site should handle the ticketing/registration process.
I figured out that it uses a "hybrid" approach in which the event tickets are actually "CBSub plans" behind the scenes.  The previous maintainers wrote a custom plugin which basically "intercepts" the ticketing form once it's submitted, replaces the items by CB plans, and forwards the user to the CBSub payment page.  They did this by not only doing string-based text replacements, but even edited the core CB files to get this to work.  I found this out because googling for a solution, I ended up on these very forums, with you guys (rightfully) saying "don't do that".
Of course, after I updated the ancient versions of the plugins, everything broke.

Since I am under time pressure (the event registration for the upcoming event must be enabled in the coming days), I think I need a solution to programmatically generate CBSub "shopping cart contents" and pass it on to the correct payment processing system.  The reason I want to do this, is that the other board members of the society are used to the (nice) payment overview system that CBSub offers, and they can quickly see who registered and who paid (including via various offline payment systems), and especially because then the "invoice" system would be taken care of.

TL;DR: In a "form submit event" elsewhere on my site, I can run arbitrary PHP code.  I can parse the form data myself, and would like to do something like

$cbsub = somehow_find_the_entry_point_to_cbsub_functionality();
$cart = cbsub.generate_purchase();
$cart.add_line("Ticket for the Workshop", $workshop_price);
$cart.add_line("Extra cookie with the coffee", $cookie_price);
$cbsub.pretend_the_user_just_clicked_checkout($cbuser, $cart);

(excuse my syntax, I'm not a native PHP speaker)

after which the user would be taken to a (preconfigured) payment page where they can select between PayPal and offline bank transfer, an invoice is generated (I'm also willing to provide the text for that programmatically myself by now), payment is taken care of, an email is sent out with "User John Doe just registered for the workshop and wants [1] extra cookie, offline payment is still pending" or something like that, and a line is added with this info to the CBSub "Payments Center" overview.

My initial gut feeling was that this is "misuse" of a system designed for paid subscriptions (in fact, the current implementation indeed handles this one-time ticket purchase as some special yearly subscription plan) and I should actually be asking this on a HikaShop forum, but the payment processors are better maintained on the CB part of the site, the generated overviews are much nicer, the invoices look better, support on these forums seems more active, and we can probably abuse a "merchandise" functionality for this use case. 

Kind regards,
Sander

Please Log in or Create an account to join the conversation.

Moderators: beatnantkrileon
Powered by Kunena Forum