Preview Email

Scott — thanks for the concrete example; that pins it down.

I checked every Zen Cart from 1.5.7 through 3.0.0, and stock core builds the confirmation-email line as qty x name (model) = price in all of them (in order::create_add_products(), the products_ordered / products_ordered_html build). None put the model first. So 1 x WHS0059 Baby's Breath - Excellence, 250gm Bunch $15.00 — model first, no parentheses, no = — isn't what stock Zen Cart sends; something on your store is reformatting that line. The preview is showing the stock format, which is what a preview rebuilt from order.php can show.

I also checked the common mods that touch orders, in case one of them was rewriting it, and came up empty: One Page Checkout uses the stock order class as-is (it just calls new order() from core, ships no order.php, and never touches the email), and Edit Orders doesn't rebuild the confirmation line at all — its only model formatting is [model] in the change log, not model name. So it isn't one of those; it looks specific to your store. My hunch is a customization on the Portland florist's site changed how its order-confirmation email builds the product line, rather than anything in core — does that match what you've got there?

And here's where your original point lands, fairly: a preview that reproduces core's markup reflects stock Zen Cart, not whatever a given store has changed. That's true of ours, and it was equally true of the 1.x/2.x line — build_checkout_email() hardcoded name (model) as well, so it would show the same stock format on your store, not your model name. Neither approach can mirror a store-side change to the email by copying core.

So the useful question is where your store changes it, because that decides what's possible:

- If it's an edit to includes/classes/order.php (its products_ordered line), we can make the preview read the store's own order.php and render from that, so a customized line shows through. That's the "don't just copy core" direction you've been pointing at.

- If it's a plugin or a notifier reformatting the email as it's sent, then order.php is stock and the change lives only at send time — nothing that inspects a stored order can reproduce it; only an actual send would.

Quickest way to tell which: v3.0.2 ships tests/Unit/CheckoutParityTest.php, which checks the preview against your store's own order.php. If it passes on your store, the change is at send time; if it fails, it's in order.php and we've got a clear target. Or just tell me what's reformatting that line.

Either way, I want to make this right for your case — I just need to know which it is.

- If it's an edit to includes/classes/order.php (its products_ordered line), we can make the preview read the store's own order.php and render from that, so a customized line shows through. That's the "don't just copy core" direction you've been pointing at.

This is what I want you to do.

Quickest way to tell which: v3.0.2 ships tests/Unit/CheckoutParityTest.php ...

No, it doesn't.

Correct on the test. 3.0.2 strips the tests/ out of the release zip.

Now that we know we are dealing with a modified cart, we have the next problem.

Monitoring a cart's modified order.php uses eval, which fails the security_scan based on info from ZC.

It doesn't mean I can't do it. After all, we would be evaluating the store's own order.php, but will I be able to get it past ZC's security check?

PM sent.

i think the whole direction of this plugin is wrong.

if a store modifies how a order confirmation email looks, the whole point of the preview is to preview how that store's email looks. even a modified one.

the code contained in this script does nothing of the sort.

IMO, i would do something like:

$preview = new order($orderNum);
$preview->send_order_email();

and then use the notifier/observer system to actually NOT send the email. and then, again using the notifier/observer system to grab the constructed emails from this notifier: NOTIFY_ORDER_AFTER_SEND_ORDER_EMAIL.

that is how i would approach it, which i think is in-line with the goals of @swguy.

@carlwhat

As always, you have an excellent point about what the plugin should do. I'm not sure I agree that its current state is "wrong."

Perhaps it's better to say it could have been better if the update considered modified core files.

The goal was to find mods that were dormant, popular, and not working on current ZC versions. Some were mods my clients needed; some I just felt the community needed.

Secondary to getting them current was the possibility of encapsulating and "modernizing" them. In this case, like many others, the original mod was the basis for the rejuvenation.

This mod did what the previous version did, and other than pointing out the code involved, it only added the ability to email yourself a copy of the email to see how your email client handled the code.

Sadly, I did not consider modified core files when building the plugin. I don't have a single customer who has wanted the sequence changed in this situation, nor did I ever consider it being overridden during plugin development.

I have a working model that handles this situation, but the method required could be a security risk. Minimal, at most, but it will fail the scan when submitted simply for using that code.

I'm awaiting a ruling on that. We'll see what's next once I receive an answer.

The forum changeover, cross-referenced plugin IDs, and folks bombarding the new site are really straining the devs right now, so I understand if a decision takes a while.