molafish

I'm trying to figure out why I have an order without a shipping charge, when this module is the only shipping module enabled. I have free shipping under the Order Total module disabled. So the only thing I can think of is checkout was able to continue when the soap service was down? Is that possible? I tried changing the url to something else to test what happens when the url is down, and that just threw php errors. So, I've come here to see what the expected behavior should be. I've seen mention of a "please enter zip code" message when people have auth problems. But does checkout still proceed after that message is displayed?

I would like to help make this work. I have not spent a whole lot of time understanding the attributeManager code, nor do I have lots of free time, but I would be willing to follow through on whatever todo lists you have to resolve the issues reported in the Linked Products support thread. The first thing that stands out to me is missing column 'type_show_product_as' reported there. How is that intended to be used in the product_types table? Please contact me via email at: my first name at first initial last name .net My name is Ian Freeman. ie [email protected] Thanks.

Anything is possible. Not everything is desirable. This was suggested, by the way.

Coupon Admin rollup 3 posted today. This release only adds one new feature to the coupon admin page (without having to click on report): - number of redemptions - date of last redemption - redeemed coupons view filter This rollup is comprehensive, in that it includes all the changes from the coupon admin bug rollup packages 1 and 2 that I posted earlier. I've included a screenshot in the package for your viewing pleasure.

insomniac2, The code I changed in coupon_admin.php for number_format() and decimal precision seems the way it outght to be. If a dollar amount or percent has no post decimal data ($10.00 or 10.00%), then only display $10 or 10%. What you did was override the logic of the ternary operators I inserted. Basically, each ternary IF statement is now asking "Is the amount an integer? If so, then display to 2 decimals. If not, then display to 2 decimals." The code I wrote was intended to do this: "Is the amount an integer? If so, then display with 0 decimals. If not, then display to 2 decimals." If you want to always display decimals, why not replace all the ternary instances with just the number_format() call? It would clean up your code...

I have finished a second round of bug fixes for the coupon admin page. It's available at the CCGV contrib page. Thanks to primadude for helping me find bugs here. You guys let me know if there are other bugs you find.

Strange. Try applying the coupon admin rollup 2 package from the contrib section and see if it still does it.

There are different sections of code that display based on which action mode was passed to the page. What is the action GET variable when you are having the problem? And what section of the $action switch is this code in? It looks like the 'new' case...

If anyone has made this change and incorporates taxes in the coupon value, let me know if your order total math is coming out correct. Fred's code doesn't work because $cart is not set when he called product_price(). But I fail to see why we need Fred's change, because I am unfamiliar with the VAT shop setup. Somebody let me know how this works out with your tax settings (I don't let coupons deduct the tax amount).

Try Textpad. It has file diff capability. It has other useful text editing features too like syntax highlighting, customizable modules, and line number matching for command line tools (configurable). I don't know if the demo is time limited or feature limited... Many have already done it. Open the install instructions for the contribs on the ccgv contrib page. There are line by line instructions in some. However, I don't know if 5.15a1 or a2 have those instructions. I have built comprehensive instructions for modded stores in the release I'm working on. I have now replied. I am currently testing the code myself (in a sort of alpha phase). After that has been finished, I will ask for greater widespread beta testing from others here. But before doing that, I will post the contrib so that you can all download it, in keeping with the forum rules. Sorry if it seems I'm not around. I do have full time school, 3 part time jobs, and on the side programming work to load balance...

I've done a lot of fix work to admin/coupon_admin.php tonight. I'm going to put it up on the contrib page. Here's the highlights: Fixed coupon_admin from overwriting dates and customer uses fields to defaults when editing or displaying an error. (default uses per customer is 1 and default date range is now() to now() + 1 year). removed non-working length check of coupon_name field in coupon_admin, fixed other possibly non-working checks. (instead of fixing the check, I made the name optional. It was desirable for me to have the option to display just the coupon code to the customer). fixed problem where free shipping coupons deduct an additional amount (if the amount was specified on the coupon_admin page) above the shipping cost. During coupon creation now, the amount will be zeroed out if free shipping is checked. (You will need to edit all of your previous coupons which have both an amount and free shipping checked for this to take effect). fixed missing or hard coded language text used on coupon_admin page for errors and buttons. changed Coupon Name help text to reflect the unrequired nature of that field. (Your contrib probably still displays nothing if the name field is blank for a language - I have changed all instances of that to display the coupon code instead in my unpublished contrib. Until I put up the full contrib, just continue to enter the coupon name field to avoid this). All these changes are made only to one file: admin/coupon_admin.php. Except for the missing language text item, which will require you to add these 6 lines to your admin/includes/languages/[language]/coupon_admin.php file: define('ERROR_NO_COUPON_AMOUNT', 'Error: No coupon amount has been entered. Either enter an amount or select free shipping.'); define('ERROR_COUPON_EXISTS', 'Error: A coupon with the same coupon code already exists.'); define('COUPON_BUTTON_EMAIL_VOUCHER', 'Email Voucher'); define('COUPON_BUTTON_EDIT_VOUCHER', 'Edit Voucher'); define('COUPON_BUTTON_DELETE_VOUCHER', 'Delete Voucher'); define('COUPON_BUTTON_VOUCHER_REPORT', 'Voucher Report');

In my last post, where I said "free checking" I meant "free shipping." Does the ability to edit your own post expire after a set amount of time?

Right now the documentation (next to the free checking checkbox on the admin page) says: "The coupon gives free shipping on an order. Note. This overrides the coupon_amount figure but respects the minimum order value." The "overrides" part is by design. Really, the amount should not be recorded if free checking is checked. If that checks conceptually with everyone, I'll change that in the admin tool. It seems that the free shipping coupon is not working as expected anyway. If you do enter a dollar amount or percentage with free shipping checked, the percentage is changed to a dollar amount and that dollar amount is ADDED to whatever the shipping cost is to derive the order discount. Example: shipping costs 5 dollars. If a coupon is applied which has free checking checked and has 2.5 in the amount field, the discount showing on checkout_confirmation.php is $7.50. I have to rethink how checkout_confirmation should show the free shipping. The fixed sort order complicates things a little. Obviously, this should not happen. It should deduct 5.00. I'll post the fix here.

He felt it was easier to code the communication to the user about the coupons and gift vouchers during the checkout process by using the error reporting process. I don't like this, and it should be changed. It also causes problems with special characters (such as umlauts in german) being displayed because all html chars are stripped out as a security precaution as they are parsed from the html query. With that being said, it can be put on the backburner. Primadude in the meantime has modified the stack so that the customer is not scared by a red warning which says Congratulations!

If anyone knows, it's molafish. Ask him. You are right. The contrib as it stands currently is an abysmal mess. All the more reason to stop by and help test! This happened because we didn't have anyone take charge of the contribution and guide development and bug fixing. This will get better, I promise. Update on my progress: I have a working copy installed on a server. I am going through now and fixing known bugs. Every time I do I find three more. After I've done my testing I will post it. Stay tuned.

Once you do that, post it to the ccgv contrib site and I'll try to incorporate it into the release i'm working on

Geez. Things really went to hell in a handbasket with this. We need to take a step back and add relevant changes to a working version. I'm one of the guys that was working hard on a good repack for this, and now I'm back in the game (finally). This is what I suggest for us to fix this incredibly jumbled mess of a contribution: I will finish up my extensive documentation of all the changes between version to version lately, and upload a *working* install based on 5.13 with hand picked fixes since 5.13. Anybody willing to test it can help me decide what's still broken, and then we'll come up with the right fixes for the problems we still have. I noticed several "solutions" lately that might cause some serious harm to the checkout process. I was already aware of several bugs that were present in 5.14. And many have not been addressed by 5.15. In addition, as many have commented, 5.15 introduces more bugs. Be patient, and we'll turn this mess into a rock stable release with cool new features. Please, nobody get offended. I am not discrediting any of your hard work. In fact, I would appreciate personal messages from any of you who wish to help code and test (Shanejackson,etc). This is the way I see things progressing: 1. Fix order process - including annoying reentry of credit info after applying coupon 2. Add extra admin interface functionality 3. Distribute language packs with images alongside CCGV 4. Look at other payment modules compatability(PayPal has known problems that seem to have been fixed in a couple of forgotten releases) 5. ? We will all benefit by working together on this. Even those of you who are posting that you are waiting for a fix because you don't know how to code can still help. For instance, you can play with photoshop to make images... If you have ftp access and extra room for another database, then you can help by letting us install a test osC + CCGV install on it. That would be greatly appreciated, as currently I do not have room to do such on my servers. More news to come in several hours. In the meantime I will be working on what I said I would.

Because 5.15a must contain code which adds the first check box, when it doesn't need to (in your case). I can't tell you much more than that at the moment, I'm working on a new release of CCGV, plus I didn't write 5.15a. But I do know that people were having trouble getting the check box to appear, which is why I think someone added another checkbox (the first one you see on the page).

A checkbox to the admin interface to create multiple description columns when description text exceeds 256 characters. Obviously not an EP limitation (Excel and some other editors) but a simple workaround for those using Excel (Excel inserts 256 #'s when a cell is over 256 characters).

Sorry I can't be of help with Paypal right now, but make sure to post your solutions to the forum here so we can include them in the next big release.

I have PWA, and this doesn't happen to me. Ensure that you've made all required changes to checkout_payment.php and then tell us what version of PWA you installed. I know there's code that needed to be changed for PWA which normally would redirect to the login (That is, needed to be changed for PWA, not for CCGV).

I hope to work on it heavily over this weekend. A nice four days should bring it very close to completion. Yeah, me too. I wanted to have this done in October. I also spend a lot of time with JavaRoaster's stuff too. I'll set up an ftp and we can play with it. PM coming.

Good news. I think I am about 80% done with what I'll call ccgv 5.15. It's taking so stinking long becuase I'm compiling an exhaustive changelog since rigaden's 5.13 full package release for every subsequent release. Dozens of fixes, and detailed instructions for installation and a log of which releases I incorporated along the way to 5.15. There's a lot of stuff that was 'forgotten' about along the way, because people would post changes without incorporating previous fixes. This release hopes to fix all that, and add some nifty admin panel controls as well.

Yes, I was working with him as well. But alas he, as well as I, have been busy with real life. Hopefully soon we'll get a new install up (one of us).

Yes, it's the full package. Meaning all the files are there to do a full install. But what does that mean? Not many people have kept continuity logs when they posted files to the contribution page. Look at all the packages released between 5.13 Full Package by Rigaden and 5.14! Look at all the different contributors. There are a lot of changes, not all of them necessary. Some of the changes have detrimental effects. And many of the authors didn't bother to release different language files, so you might make changes to a file to find that something is in french or spanish all the time, when you want it to be english. I am almost complete repackaging what will be 5.15, by starting at 5.13 and selecting updates and adding others to a configurable admin interface. Until me or someone else does this, you have to do your best to sort through the updates and only apply what you need or deem is appropriate. A good start is to follow the instructions in the 6 Oct contrib. I hope to release something within a week or two.