Updated today with a bunch of small fixes.
Anonymous posters in the forums wont be getting an ugly message any more and you'll see a couple more RSS enabled pages floating around. Namely The Word and The Central Committee.

There are also a bunch of subtle CSS changes and some backend stuff but yay it feels good to be tweaking. It has been a long haul to get here.

Man, the past couple days have been a blast. You guys have managed to show us all our flaws in our perfect system. Of course we knew it wasn't perfect and that's the any release goes. Problems pop up in magical places where they where they didn't exist 5 minutes earlier.

Anyways, like Greg said, we're nailing down the big issues and lining up the smaller ones we had planned on working on so things are getting back on schedule. I'm looking at the Forums and see lots of ideas for use too so I've got my work cut out for me. Thanks for the great responce and I'm looking forward to the good times ahead!

Ok, the image galleries are outputed really poorly. Text goes everywhere. I need to look at this.

Well the cart has been rewritten with some help upstream. It uses the seperate validation and submit hooks to employ the full potential of the forms api. Its also much cleaner, more flexible and more easily updated now so I hope this means good things.

One of the people that helped get some support for the changes, sime, needs updates to the shipping module and api so I'll probably put some work into this in my free time. Feel I kinda owe him some.

The cart is still in somewhat of a flux. Gordon really doesn't like a change I made to the urls durring the checkout process. I'll give a quick run down of the change and the reasoning behind it.

When I did the updates, it became very difficult to track the screen during the redirect. The form api does a 302 redirect after the form validation and submit handlers so a new page is shown with the new data. This is sort of a good thing in the checkoutapi because this allows the checkout api module to do pretty much anything durring its time running and the updates will appear in the new page. However our post is dropped when we redirect so we lost our storage of the screen.

The first solution I used was based on merlin's multipart form example that can be found on his blog and in the drupal handbook. It worked great except it broke this functionality previously available because it stored its screen tracking variable in the session. Once you went to the next screen its updated pretty much permanently and when you browse back you see only the latest screen.

So, I went ahead and added another argument to the path. This arguement just simply tells us what screen we're on so when I user loads the page I check into the session to see if we've validated this far. if not we'll push them back. and then we check to see if they're going back a screen and if so we'll rebuild the transaction to make sure there haven't been any mixups. This is the same structure imposed previously in the module so it made things very straight forward and I didn't have to worry about breaking outside modules.

Gordon however really doesn't like this added arguement and thinks its ugly. There's no argueing with taste though especially when they have control of the module and you dont :). He currently has some changes in cvs that he feels fix the screen# url problem by adding ?op=next to the url. I think this is bad for a couple reasons. A, op is used by drupal as the submit button so on post you're going to have 2 'op' values in $_REQUEST and this feels like it could cause problems. Also, it looks ugly to me. I never like ? urls when they aren't needed. And finally, it breaks the back steping completely the same as the session problem. In fact, I really don't see the point of having it at all as the normal URI should work the same as the system he's implemented.

I've posted the actual current breakages, namely not being able to go back, to the issue thread kept on these updates and until things simmer down and there is a fully working cart in cvs I'm going to maintain a seperate version with the screen in the URL for MG. I've been doing that anyways before the updates went through so I wont be a problem :) It works smashingly so we're good to go on that aspect for now.

The PayPalPro Payment module should be working. Everything should be converted to the new forms api.

During the process I noticed that the product module is polling the database 4 times for every item though so... We might want to look at the product module and see about fixing that.

Ecommerce has a default shopping cart block. Threw it in the left side bar even though that doesn't fit the wireframe so we could see/play with it.

Well I started playing with cleaning up the ecommerce module as we have it in svn. There are still some sections that haven't really been updated and some code lying around that seems to be leftovers from before the update that should be scrapped.

One fix is up now that keeps things from dieing when there are errors on your create product form(on non product nodes like our games in particular).

Another big place to work is paypalpro if we're going to use it. It seems to be fundamentally broken from not being updated. Easily seen problems.
During checkout:
Fatal error: Call to undefined function form_hidden() in /.../modules/ecommerce/contrib/paypalpro/paypalpro.module on line 364
and on payment adjusting
Fatal error: Call to undefined function form_textfield() in /.../modules/ecommerce/payment/payment.module on line 366

Its the finals weeks som things are heating up. Playing with how to store the rating information. Whether there will be a static list of rating questions or a dynamic. And if its dynamic, which makes more sense, how will the votes be stored to keep out orphans. Fun stuff to mull over durring study breaks.

Well I started going through and layout the needs for the rating system today. Not much to say yet.

Also thought it might be fun to use my blog space here to blog my development. Why the heck not right? So here it is!