Adding a required field during Checkout that Shows on the Invoice

Hello,

Let me start off by saying I do not know if I'm posting in the right category. I was unable to find an answer via a search. Forgive me for errors.

ISSUE
We are using an attribute on all of the products. This attribute is "Mail with Discretion" mwd. If a customer chooses to mwd they select "yes" to this attribute for every single product. This is a pain for them.

HOPE
Is there a way that we can create a required field in the checkout process that will ask this question (mwd) one time? Additionally, this information needs to be sent to us some how, via the invoice or an email alert that states this customer wants mwd.

HOW TO
If this is possible, how do we do it?

I look forward to your reply.

Thank you.

**bump**

You can easily modify the Optional Shipping Insurance mod to say Mail With Discretion instead. (even charge a bit extra for it if you wish.)

Thanks Kiddo... You are right... I did not think about that. We already have that installed and we can just modify the code. :) Thank you so much!

:hug:

I think you would only have to do a little creative editing with the text so instead of saying the Insurance blah blah... the wording offers the special shipping instead.

Cheers!

Back to the original question, I would like to add a text field on the checkout confirmation for users to type in "Where they found us" - so obviously a simple yes/no field isn't going to work here.

I have modified the template file [ tpl_checkout_confirmation_default.php] to a. give me a new textarea b. run some javascript

I was *hoping* that I could just append this string to the "comments" hidden input field which is output earlier on the page. I *can* but it doesn't write it all to the database. bugger!

I am quite happy simply to append this data to the [ comments ] value, this keeps it pretty simple and doesn't require new database fields or the like.

But obviously this looks like it needs to be done some other way. If it cant be done dynamically with scripts then I gather I would need to modify the php code on the next executing page - so I was wondering if any ZC experts could point me to the next file.

Any recommendations (ie modify the array, or just append the inserted database value, or.....etc!) welcome.

Ta, Adrian

OK, I see I am probably going to have to sort this myself, and feel reasonably confident to do so "in this area". I know the database field is named [comments] in the [orders_status_history] table AND at this point are planning to edit the: includes/classes/order.php file to try and append data to the array value from an additional form input written onto the order confirmation page

Hopefully this will then simply use the existing ZC processing to write the data to the database.

I would appreciate any Zen Cart experts giving me their quick thought, especially with regards to any other implications of altering the executing php file - and where else it may be called *apart* from the order confirmation page.

No response yet of course. This is my main gripe with Zen Cart, even though it is a great OS product.

The problem is when you actually want to do something a little different. As detailed above I am more than prepared to delve into the code and suffer all of the debugging effort that core code modifications require, however it would *really* help if a Zen Cart expert/team member could give me just a little insight into where to start. But I can't get any response, and that means:

- there are no experts who know this information
- there are no experts who can be bothered responding

Unfortunately for me these problems with quasi-support is Zen Cart's limiting factor.

As a reasonably intelligent developer :blink: I am using Zen Cart because (apart from the obvious cost factor) I can customise the cart to suit rather than write the darn things from scratch (which I have done in the past).

I accept the code "quirks" because of this, but I do want to be able to customise beyond the standard parameters - and to do this effectively I need to know how the code processes.

At the end of the day this "simple" mod is something the client wants and it is quite frustrating that it seems I would need to do all of the code reverse-engineering in this area to implement it. Obviously someone must have written this code....

OK, I could pay someone else to do it, (but who?) and then this simply raises other development issues that tip the scales towards me simply handing it all of the work (and the hassles) to a commercial software provider.

It has been a great product and it has given my client a great start into online trading, but for me the signs are now pointing towards the site just maturing beyond the point where Zen Cart is the right option.

My two cents anyway. :smile:

Anyone got any recommendations (actual users please) on commercial software that is reasonably easy to get data from Zen Cart?

I wish I had an answer for you and for myself. I'm posting because I did not want your post to go ignored as many (in my opinion) do.

This might be close and has been in the downloads for a time if one looked
http://www.zen-cart.com/index.php?ma...roducts_id=186

Quote:

---

Originally Posted by lotii10396

Anyone got any recommendations (actual users please) on commercial software that is reasonably easy to get data from Zen Cart?

---

What type of data?

Kobra,

The one you suggested doesn't populate on the packing slip or invoice.

The data I would like to input is text.

Quote:

---

The one you suggested doesn't populate on the packing slip or invoice.

---

It stores it with some variable to the DB
One would have to add the variable to the invoice etc

Kobra,

That sounds great. It sounds like it is just a matter of (for text) duplicating that add on, modifying the options then adding it to the invoice.

Thank you again for the start. It is appreciated.

To Rabbcon and kobra, appreciate your thoughts. And I especially agree with Rabbcon regarding un-answered posts. The dilemma here is that 80% of posted questions are usually simply install errors or RTFM (read the $@#% manual) problems so many are duplicated and thus ignored. As a developer myself I certainly do not have time to be answering the simple questions.

As a reasonably experienced user of ZC I try and avoid any third-party modules that involve database modification wherever possible (so kobra I wasn't looking for a module!) because I wish to keep the code as tight as possible.

All I want to do is append field data to an existing database variable which is already used in the invoice display. I would have thought this is far simpler than using third-party modules and modifying the database.

But I just can't see how the final page variables (as mentioned assume they are in some sort of an array) get written to the database. As you would know from the code most pages are includes+includes+includes which makes reverse engineering very tedious and difficult, so all I was looking for was insight as to where (ie which files) this is happening.

So my point remains the same - as a developer the biggest problem with ZC is that serious help/support is just too hit-and-miss.

----------------------------------------------------------------

Why "not" to use modules.

Of course I use the modules, but the more I use them the less I like the implementation.

My biggest problem is that, I (like many others I suspect) have been caught with these modules not working/no longer supported. The scary part here was that one module (which calculated postage rates) did not stop working - it just stopped "calculating" properly. So I did not notice this until several months later. It was only "after" finding out this information and having a rant (another...!) with the developer that the module was removed from the downloads list, where it was still appearing as a totally valid and updated module!

And with the current "optional" implementation of the module manager (where some require it and some don't) the module management side is only getting messier rather than simpler. EG what happens if the developer coding the Module Manager decides to abandon ship?

Modules are a great idea, but for me they need to start getting a little bit more refined as to how they are managed.

------------------------------------------------------------

At the end of the day for me it is about money. I'm at the point where I would *like* to:

1. pay to be on a developer forum where:
a. you wouldn't get silly posts
b. you would be assured of a response

I expect that being on this forum would sort out many of the recent data-mining issues with ZC and rampant indexing spiders without me having to do hours of research.......

2. pay a registration fee with module programmers who would then "push" me updated information/patches.


So whilst I do think it is great OS software (which was why I used it in the first place) I'm a developer who doesn't *want* to be continually checking that the code/modules are working so I am recommending to my client that she should now begin looking at commercial software.

---------------------------------------------

When I was asking for recommendations obviously others have taken this path before, so I was hoping other users could give some insight as to which packages import the raw ZC data (ie from the database) the best.

I would have thought the attributes would be the biggest head-ache?

Anyway, thanks again for responding :smile: Adrian