[checkout module] make another field required

I guess if anyone's familiar with Checkout, it's me.

Are you using the latest version? 0.3.2 - get it from this thread: http://gallery.menalto.com/node/74849

To add fields to the tables you'll need to write some code. There aren't any fields that are unused (except some of the binary flags - they will likely be used in future updates, so if you use one for something other than its titular role you're probably screwing your update path. You certainly shouldn't rename any of the fields as they are referenced by name throughout the code.

A better way to do it that won't break anything is to write a new module and create a new Map table for your extra data. Depending on what you want to put in it, you should use the various interfaces in Checkout to reference your code which will add the data; that way you preserve your upgrade path and don't have to alter any code in checkout itself. If you explain what the 'required' field is for, I can be more specific.

To charge extra for certain paper types: the easy way is to include them as separate products, and give them different prices. The neater way involves creating a new module which will implement the CheckoutTransactionDetailsInterface_1_0.class to modify the cart contents (obviously adjusting the prices according to the paper selections); if you do that you can (probably should) give it a per-album/item admin page by implementing the CheckoutCustomPageInterface_1_0.class. Then you can post your code and everyone else can use it too. If you want to go that route let me know and I can give more details.

0.1.18 is the latest 'released' version, but it hasn't been updated for about a year. I took on some updates a couple of months ago and moved quickly through version 2 to where it is today, 0.3.2. That seems pretty stable and I've been using it on a production site for the last couple of weeks, as have a few others. On my to do list is to get it moved back into the SF server. There are dozens of new features and the architecture is much more extensible, so at this stage I'd recommend giving it a go especially if you're considering modifying or adding to it. Version 0.1.18 is functional but basically dead, and you'll find it hard to move any changes forward from there as the architecture has changed quite a lot.

You'll need to use the new versions of checkoutemail (and checkoutpaypal if you require it) that are included; there shouldn't be any problem upgrading them.

I think a phone number field is a good idea, should be quite straightforward to implement. It will be difficult to make it required, because, for instance, paypal doesn't (I don't think) return that information so checkoutpaypal orders couldn't have it. (Might be wrong, will have to investigate.) There should be no problem with you implementing a custom mod to require it in your own checkoutemail module though.

You could also by the way have a module that 1) asked for the custom text 2) charged appropriately and 3) on download or whatever added the text automatically - if you wanted.

I'm open to offers on custom development - pm me if you like. Otherwise, best move discussion of new features for 0.3.2 to the thread http://gallery.menalto.com/node/74849 rather than here.

Good luck!

Yep... I'm convinced that my checkout by email config is FUBAR. I uninstalled (as much as I could) the new version...still getting the "failed to completely delete checkout by email" error. Then I deleted the directories and put the old version back... got the old version working again. Just so I could put salt in my own wound, now that I fixed it.. I figured "oh what the hell maybe it will work the second time around." So I copied the new version of the modules in, did the upgrade, did the configure and activate...and same thing. The checkout part looks complete (and options look to be the same as the old version...is that right?) The checkout by email config though is the one that is all messed up. Most of the options are missing... I've attached a screen shot.

Any ideas? I still think the original issues I was having with 1.18 somehow screwed stuff up in the DB and so those issues are carrying over into this upgrade. How difficult is it to remove the tables and rows in the DB that checkout and checkout by email reference? Maybe I can start completely clean from scratch...

Let me know what you think. I think I'll put the old version back..again..

Hi Alec. I read what you wrote above regarding the CheckoutCustomPageInterface_1_0.class.
I think i need to do what you said: "The neater way involves creating a new module which will implement the CheckoutTransactionDetailsInterface_1_0.class".

Let me explain myself. I want to sell prints and also license images. I´m not interested in using the printing modules right now, because i want the customers to stay on the site. So i thought of doing just one checkout, they would pay through paypal and if it is a print, i´ll do all the printing and shipping.
The thing is that if i add all the options for printing (sizes, paper, etc) plus all the options for licensing (size, uses, etc), it gets pretty messy. And that is just for 1 picture. Plus clients buying prints shouldnt see options for licensing and viceversa.

My rudimentary solution was to duplicate the module, renaming all the corresponding parts. The original checkout would be for licensing and the copy named "buyprints" for printing. It worked great, until i had to use the paypal module. There can´t be 2 paypal modules apparently, as gallery don´t get the notifications back from paypal and the photos remain unpaid.
Is it my solution then using the interface you proposed there?
Can you give me a hand?
Thanks!

http://www.lucasmarin.com

So you're going to have two different "Add to cart" links for each picture? And two different sets of cart contents? And two different "view cart" commands?

You can have as many paypal modules as you want, if you change enough of one of them so it's distinguishable from the other. That will include changing all the interface names *everywhere*, and making sure that the second paypal module implements only the changed payment interface, and since it will have to have a different module name it will have a different callback url automatically.

I'm not sure - what would you be trying to do with it?

There are references that you missed; but they're indirect. This is how it works:

The checkout module defines a class CheckoutPaymentInterface_1_3 (see the eponymous .class file) and all of the payment modules including checkoutpaypal implement a different implementation of this class (see checkoutpaypal/classes/CheckoutPaypalPaymentPlugin.class for the code) and register that implementation in the FactoryMap table when the payment module is installed - for checkoutpaypal this is in checkoutpaypal/module.inc line 53.

Then when checkout builds the confirm page (the one with the payment methods at the bottom) it calls CheckoutInterfaceHelper::getPaymentPlugins() which checks through the FactoryMap table for implementations of the payment interface to know which sub-templates to include at the bottom of that page. See CheckoutInterfaceHelper.class line 52ff.

In order to have two paypal modules and for each of two checkout modules to recognise one and only one paypal module, you will have to change this interface name ("CheckoutPaymentInterface_1_3") everywhere it apears (filenames and contents), before installing those modules.

This de-duplication effort will have to be applied to *everything* *else* either of the two modules registers in the FactoryMap, too: look in the respective module.inc files for function performFactoryRegistrations() to see what that refers to. Then you have to mirror those changed names *everywhere* in the code files and code file titles they appear making sure that the changes are consistent across the two modules.

For instance, the CheckoutEmailInterface_1_0 is used for having payment modules (or other modules) add contents to the emails that checkout builds; that needs to be disambiguated.

Also the names of the different GalleryEntities that the two checkoutpaypal and checkout modules use have to be distinguished; you can only have one module declaring (and using) a GalleryCheckoutPaypalIPN Entity, a GalleryCheckoutTransaction Entity, a GalleryCheckoutItem Entity and so on. The second pair of modules will have to have different entity names so the tables in the db are distinct. In order to change an Entity name you'll need not only to change the php code files (and names) but also to go right back to the .xml files and mirror the changed name, including in all revision files (there are 12 revisions for the CheckoutTransaction Entity/class table.) When you've changed all the xml files you'll have to recompile with the developer tools to automatically generate the schema.tpl file which is the code Gallery uses to build the tables (with the correct names, now) when the modules are installed.

I hope you've nothing else planned for the next couple of weeks!

ROFL. I'm so glad I spent the hour and half it took me to research and write it, then.

No, not really.

You could have a little module that adds an extra attribute to each product, "licence" or "print" then test that attribute in your modified template and change the css. Then you can write your own javascript that hides/reveals each class appropriately. To do the first part of this you'd need to understand a lot of G2 structure: modules, interfaces etc as well as be comfortable with php and Smarty (the templating system G2 uses).

Alternatively you could just prefix the product names with "licence" or "print" in the text, then test for that (and strip it out) in the Smarty template.

I can't help you with the CSS or javascript required as I know very little about those two things.

I can't comment on that; only you know how badly you want this.

Oh yes, trivial for someone who's familiar with all the things you'd need to be familiar with.

Good luck!