Checkout module: forthcoming updates
|
alecmyers
Joined: 2006-08-01
Posts: 4342 |
Posted: Wed, 2008-02-13 13:04
|
|
With the blessing of Jayhen I am working on some updates for this module. On the agenda at the moment are two things: 1. To improve the custom (per-album/per-photo) pricing interface Improving the custom pricing interface means adding a new tab to the Edit Album/Edit Photo page, where prices and other data can be quickly and easily set for items and their descendants (and waving bye-bye to the use of the customfields module). Internally this means revamping the way custom prices (and also global products and prices) are stored, and this in turn raises the ugly spectre of backwards compatibility. There are some different options, on which I would like to invite comment from anyone interested: Firstly (and simplest) there can be no backward compatibility - upgrading to this new Checkout means re-entering all products and prices. Secondly there can be an automatic upgrade for the products, but not for the custom prices. This will save about 15 seconds per install, the average amount of time it takes to re-enter the products on the admin page (for a few people who have dozens of products it may take longer, but it won't be particularly difficult.) Thirdly there can be an automatic upgrade for products and also custom pricing information. For people who have a complex network of custom prices in different albums this will save re-entering a lot of information in different pages. For people who have no custom prices (the majority I suspect), it won't make any difference. If you *do* have a lot of custom prices no doubt you will still want to verify the upgrade has worked as expected, and therefore need to page through the relevant tabs for each album/photo in any case. I suppose what I'm really asking is whether the time invested by me to write (and test and debug) detailed upgrade code will be repaid in time saved (by you) not having to enter price/product information again. I am not *overly* keen, but if there is a general consensus that it is necessary then I will. I should add that the new data structure is somewhat more scalable than the existing one so future upgrades for more functionality should not see a repeat of this situation. One thing that will be simple to provide either way is a reporting tool that will list the existing products and custom prices for a gallery installation, so that you can print it and use it as a guide for any information that needs to be re-entered. |
|
Posts: 122
Firstly, well done! I look forward to what you are proposing.
My feeling is that the first option should be taken (no backwards compatability & re-enter all products & prices).
I would imagine that the number of people who have made use of the custom fields method of custom pricing is few and far between, and that the quicker a clean and polished solution is available would be welcomed by all!
I have a requirement for per-album pricing, but have been put off for a long time in trying to create a work-around using custom pricing.
I would be happy to assist in any way I can, suggestions, trialling if required.
Regards,
Paul
Posts: 4342
Hi Paul,
Thanks for the support. I shall be happy to call on you to try things out. When you say you have a requirement for per-album pricing, is it for something that can't be done currently? If so, now would be a good time to mention it.
Posts: 122
What I need is the ability to have a pricing structure that is album specific.
Depending on the target audience, for some types of photo I set different unit prices.
For me, the products would remain constant from album to album, but with the ability to set prices for a specific or a group of albums maybe? The difficulty doing this currently is that the album sizes may be 200+ images (too much hassle to do manually!)
Posts: 4342
That will certainly be achievable with the next release, but (you may not realise this) it's also easily doable with the existing release of the checkout module, since the syntax for custom prices when applied to an album effects those prices on all contained pictures and sub-albums. The new way of setting this up will I hope be a little more obvious though.
Posts: 122
I think you have hit the nail on the head! If it isn't obvious (and that certainly wasn't to me) then it will go over most people's heads! I have to say it is a couple of years probably since I dabbled with custom pricing - and gave up, too fiddly (and I'm not frightened to fiddle)
So a new admin driven method would be most welcome.
Posts: 13
Hi ye developers !
Sorry for barging in on this thread, i do have an intention to introduce some functionality into checkout and checkoutemail, in the intention to achive automated printing of the actual pictures in noritsu QSS minilab equipment, please let me explain myself,
Let me try to explain what i would like to achive, when a customer has uploaded his/her photos and decide to order prints, and has finished the order, the following should be produced in the backend (refering to backend as being where me in the lab reciving the order).
A folder structure looking as this: primary folder named "qss" and under this another folder named "order"(these two folders should be created once in siteadmin setup of module), now within this "order" folder the (checkoutemail maybe renamed to something fancy like checkoutprinter, i will refer to as checkoutemail for the time being) checkoutemail module will produce orderfolders named in an ascending fashion (o00000001 and soforth.., i am also considering getting this unique number from the album id generated in the database when the album is created), and within these orderfolders there will be yet two different folders per order namely "IMAGE" and "MISC", and in these folders will reside the ordered images (in the "IMAGE" folder, surprise), in the "MISC" folder there will be textfile named "AUTPRINT.MRK" and this textfile will contain a header for the order and print instructions as per image in the "IMAGE" folder.
I do belive i would have to create this text file (AUTPRINT.MRK) in order to make the minilab equipment understand what to do with the order, for the time being i am not at all certain on how to actually create this text file (is there an available GalleryCoreApi for this ?).
Other than these ideas of mine, i think it is a brilliant idea to have a possability to set prices in a fashion that the costumer get a discount/lower price per print when order a certain amount of prints (say minimum 200 print to get price X).
So to get back to why i am posting, do any of you guys know of a way to create and write to a text file using GalleryCoreApi or any predefined function within Gallery's library.
Sinc Palle Kuling
Posts: 4342
Palle,
Item price breaks based on quantity will be easier to implement when I've finished the work I'm currently doing. Your ideas for a specific output format (text files, folders etc) are easily achievable for a competent programmer who's familiar with the checkout module but they're very specific to a particular user/application and don't have a great deal of general application, so it's unlikely that I'll be able to implement them for you with this round of updates.
(you wouldn't need the Gallery API to write a text file, since that is something that can be done with php.)
Posts: 13
alecmyers,
Ok thanks a lot for your quick response, then i´ll reside to some php coding, do you know if there is any specific place in the gallery structure where i am supposed to place my php-script for this purpouse (for instance "local" folder within the module folder, hiding away from being overwritten by updates).
Sinc Pallekuling
Posts: 4342
I think you need to do some serious research into how the Gallery framework works, and how the Checkout module in particular is structured! You'll need a full understanding of that to know where and how to interface your new code. I don't think it's as simple as me being able to say that you should just put your script in a particular folder.
Posts: 51
alecmyers, what good news - what you are proposing sounds great!
I have no issue with there being no backward compatibility.
When it comes to re-entering products and prices I could live with that, even though I do have quite a few custom prices in my gallery.
The reporting tool that you mention (to list and print existing products and custom prices) would certainly be a great help to re-enter and check prices. With regard to this reporting tool, it would be great if it was available before and after the Checkout module upgrade.
Keep up the good work! I'm looking forward to the next release of the Checkout module!
Posts: 13
Hello again alecmyers !
Just came to think of it, when using the current version of checkout module one makes a choice in admin setup (size, amount and i belive paper type too), now when ordering prints this setup becomes quite rigid and unflexible.
For instance, if a costumer would like have his or her prints in an other fashion than the default type( as setup in admin), changing for every print, if the costumer has uploaded say 100 pictures for printing, this quickly becomes tedious.
I would like to see a possability to make a choice that affects all prints in one single sweep (that is change to a different paper surface or size for prints), in the view:
Checkout::Step 1 - Select the Product and Quantity, a dropdown choice would be really handy.
Just an idea...
Sinc Palle Kuling
Posts: 4342
Yes I see what you mean. There would be no great difficulty about arranging that - it would mean a rewritten template for displaying the cart, and a small amount of extra code to parse it. The hardest part (as always) is to layout the page so that it's simple to navigate for the user. If you want to design a page in photoshop or similar as to how you imagine it looking, then I will have a think about it. For my purposes most orders are only a few prints, not hundreds, so there's never been any great difficulty in setting product settings one-by-one.
By the way, I have had to redesign the order page slightly: the option for a choice of paper is now set on a per-product basis, so the display/choice of paper type has had to move to be set for each product ordered, rather than once per image.
Posts: 13
Hello !
Something like this ?!
Maybe yet another row of text, just so the intention of the button is clearer for the customer.
Sinc Palle
Posts: 4342
I now have an alpha version of checkout 0.2.0 (and I stress *alpha*) ready - drop me a PM with your email address if you can spare 30 minutes to install it on a *test* gallery installation and try to break it.
Posts: 122
First comments on alpha version checkout 0.2.0
After adding items to cart & saving, then clicking 'continue to checkout'
ends up with a blank page
this is the url
http://www.xxxxxxx.co.uk/gallery2/main.php?g2_view=checkout.ConfirmPhotos&g2_statusId=x6b61f5be&g2_navId=x2927562c
Paul
Posts: 4342
Hi Paul,
A blank page is usually indicative of a php error (the url contains no useful information) - can you enable debugging (as buffered) and generate the error again? The php error should be displayed at the top of the (now much longer) page.
In order to enable debugging, (if don't know) edit and save the config.php file in the gallery root directory. Towards the end is a line which has something like ...debugging(false) - change it to debugging('buffered') - there are more detailed instructions in the comment paragraph above.
Posts: 122
Alec,
Have enabled
On blank page now :
Fatal error: Call to undefined function: loadcheckoutitems() in /var/www/html/gallery2/modules/checkoutpaypal/classes/CheckoutPaypalHelper.class on line 68
Paul
Posts: 4342
OK, my bad - it looks like the CheckoutEmail and CheckoutPaypal modules are also going to need reengineering to match the changes in Checkout. That'll take me another day or two.
Posts: 122
Checkout Development 0.2.0 _alpha1
Problem with blank page when going to checkout page is fixed.
Some formatting issues when comparing between IE7 & Firefox, but I will detail whe I have looked further.
So far looks promising, no major probs found.
Regarding checkoutemail
email sent to customer 'customer@gallery' and to defined address.
No thumbnails within email.
Thumbnail option is checked against email adresses in checkoutemail.
In 'Photo' column text is 'No Thumbnail'
Posts: 122
Debug output
Notice: Undefined variable: price in /var/www/html/gallery2/modules/checkoutemail/Email.inc on line 132
Posts: 4342
Hi Paul,
Brilliant, thanks - both of those now fixed. What are the browser format issues? I can't see anything obvious at this end...
I have bitten the bullet and am writing some upgrade code for the (global) products and prices.
ps - it's only the php error message(s) at the top that are really useful (first off) from the debug page, so you can save time by not posting the whole thing!
Posts: 10
Hello alecmyers,
Glad you cared to updated this need module. Where can I download this?
Posts: 122
Alec,
On Checkout Step 1 page:
Using IE7
[img]http://www.paulcobb.co.uk/temp/2008-02-20_IE7.png[/img]
Using Firefox
[img]http://www.paulcobb.co.uk/temp/2008-02-20_Firefox.png[/img]
Paul
Posts: 4342
Moved from another thread, as it's more pertinent to this one:
It's been suggested that the term 'product' should change - as it's easy to confuse what's an image and what's a product when you're new to this module and trying to configure it. Any suggestions, post'em here...
Also in response to a query about what's changing in Checkout 0.2.0:
Checkout 0.2.0 (the one I'm working on) will not have many *new* features over 0.1.18, but it will make the features that are currently available and difficult to configure much more accessible. That is you can already, and will still be able to:
* Set prices for each product/image combination either individually or according to which album they're contained in (so different images can have *different* prices)
* Create products only for certain images and not for others (different pictures can have *different* product lists)
New features are:
* You enable/disable paper options on a per-product rather than per-image basis. There's no point offering a 'paper' option for a download product, for instance.
* You choose whether a product triggers a postage charge on the order, or not. A basket full of postage-free items will not add the postage charge.
In general there is a trade-off between making *absolutely* everything configurable for *every* product which confuses both the site admin and the customer to the extent that they're not actually sure how to use the site any more - and making it so simple that it no longer meets the needs of anyone. It must be easy to set custom prices for different product/image combinations if you want to *without* making it a PITA to set the *same* price for all combinations for those who need only that. The solution I am using is similar to how it was before with the custom fields, only it now has its own config page per album. That is:
You set the global list of all products in the admin page. You decide whether they are default visible or default invisible. Then in each album and sub-album you can change the visibility of any of those products. So you can exceptionally exclude an image that's generally displayed by setting it to visible in the Admin page and setting it to invisible in albums or photos where it shouldn't be shown. Or you display a product specific to a single image by setting as invisible in the Admin page and visible only on the single item. Or any combination in between. Visibility of a product is inherited from an image's ancestor albums with the setting closest to the image in question taking priority.
The same thing works with the prices - they are globally set in the admin page, and overriden anywhere in the album/photo structure. This isn't new, but the previous method of configuring it was somewhat opaque. This way should make it more accessible, while maintaining simplicity for those users who don't need complex pricing and product strutures: you can set the prices and products on the admin page and forget about the rest. (You can even disable the per-item/album tab completely.)
I'm happy to say that the code and templates are now in general shorter and less opaque than previously, which will benefit anyone who wants to twiddle things to suit their purposes.
On the cards for new features from me are:
* Banded Postage: customer selects from (for example) Inland First Class, Special Delivery, Overseas European Air, Rest of World - or whatever the admin configures.
* Purchase group access - if a registered user, customer can be added to a Gallery group on purchase of an item. Therefore you can sell access to different sizes by configuring group permissions
* Discount codes, as discussed
And I have some other ideas, depending on time.
Oh, and I'm also going to write a GB-en localisation to get rid of that wretched word "cart"!
Posts: 4342
At the moment it's not finished - if you want an alpha copy to test to help me iron out remaining bugs that would be fantastic - drop me a private message with your email address. So far I have been utterly un-fazed by the stampede to help out, since only paulcobb has volunteered.
Posts: 10
A general term "Item" can be used. Or admin can be given the option to modify the term from lang definition.
You should contact this site admin to submit your work to gallery codex so that you get more bug testers. The more testers the better.
Posts: 4342
The code for checkout 0.2.0 beta is posted in this thread - please move discussion and bug reports there!
http://gallery.menalto.com/node/74849
Thanks