Re: Super Orders 2.0, <br /> tags not scrubbed from status comments
Quote:
Originally Posted by
wickedklown
This problem didnt have to do with batch status. it was just when doing order status via super orders. I rarly use batch status update, or any of those batch's.
should i still preform this fix, and will it fix my current problem?
See wickedklown's post of 14th October 2006, 05:24 PM for background.
This was regarding non-scrubbing of [FONT=Courier New]<br />[/FONT] s from status comments added with super orders. I was experiencing the same problem. When adding one status comment to a single order with super orders, my newlines were being stored as [FONT=Courier New]<br />[/FONT] in the database, and the tags would then also appear when the customer viewed the status comment from within the order page in their zencart account. The html email sent to the customer looked as expected: line breaks where there were line breaks in the original text... it was just subsequent re-display of the stored comment on the customer's order page that had the [FONT=Courier New]<br />[/FONT] tags shown.
SO... I discovered a workaround. I "un-supered" the line that super_orders.php uses to scrub the comments and changed it back to the version in plain-old orders.php. In catalog/admin/super_orders.php , in the vicinity of line 100, I made the following change:
Code:
// 070722: Changed this line to use same function orders.php uses, to fix improper
// scrubbing of <br /> from comments.
$comments = zen_db_prepare_input($_POST['comments']);
// 070722: Original Line
// $comments = zen_db_scrub_in($_POST['comments']);
I believe zen_db_prepare_input() is the function that is builtin to zencart to scrub input prior to database storage, and zen_db_scrub_in() is a function from super orders that performs the same task.
Anyhow, a big disclaimer: This fixed the problem I described, but there obviously is some reason a new function was created to scrub input for super orders, so... user beware. This may have some undesirable effect that I simply haven't noticed yet, although the fact that orders.php uses this line makes me suspect that this will work OK in most situations. Time will tell.
Background info: I did this on an installation with: Zen 1.3.7, Database Patch Level 1.3.7, MySQL 5.0.33, PHP 4.4.5, Apache 2.2.4.
Re: Super Orders 2.0, <br /> tags not scrubbed from status comments
OK, regarding my post of 22nd July 2007, 04:29 AM:
There are, in fact, secondary effects from making the mod I outlined. They can be fixed up, I believe, with two edits to super_edit.php and one change to super_orders_functions.php . The end result is that newlines are stored in the database and not <br /> (which is what I wanted), and newlines are converted to <br /> when needed for html output to email, etc. It also fixes the behavior I kept seeing where, after editing status comments with super orders (for one order at a time, not batch mode), <br /> , \n , \r , (or some combination thereof) appearing in status comments would be re-saved to the database as "nr" at the beginning of each line.
So it appears to function the way I want now, with newlines appearing visually as line breaks in all contexts.
However, I can't really recommend it.
One reason is that I am not certain that protection from injection hazards is as good after this mod. It might be, but I'm not an expert in such matters. It isn't a consideration for our situation, as this all runs in the admin side and our admins are limited, non-malicious, and just use it to paste in simple, but multi-line, text. For general use it might be more of a concern.
One other reason I can't recommend it is that I suspect that the intent in altering the scrubbing strategy/code/functions in super orders was to preserve <br /> and other html tags in the database and display them properly in HTML contexts. For some reason there were a few cases in the unaltered code for super orders where status comments would appear with <br /> and also where, after editing status comments, line breaks such as \r\n would be converted, saved and subsequently displayed as "rn" (perhaps the reverse order, "nr", I forget which). These are probably just minor bugs, or it could also be that I, wickedklown, and the other person (somewhere in this thread) who observed "rn"s or "nr"s are doing something when entering or editing status comments that should be done differently to prevent these problems.
My point is that when/if a new rev of super orders is released, I would be willing to bet that the <br /> , \r\n , rn , nr strangeness in status comments will probably be eliminated.
Finally, I haven't tested other HTML tags in the comments, such as hrefs, etc. and can't vouch for how they are handled after modifying superorders as I did. We just need regular text with linebreaks, so it does what we want.
If someone else is having problems with newlines, <br /> , etc. in status comments, I can post the additional mods. PM me if you want the other mods and I'll post them with a big warning.
Re: Super Orders 2.0 "No Email problem"
The source of the error page displayed after I click on "confirm order" button in checkout says the following:
Code:
<br />
<b>Warning</b>: str_repeat() [<a href='function.str-repeat'>function.str-repeat</a>]: Second argument has to be greater than or equal to 0. in <b>C:\xampp\htdocs\PAC\shop\includes\modules\payment\cc.php</b> on line <b>259</b><br />
<br /><br />Email Error: SMTP Error: Data not accepted.<br /><br />
The section in the cc.php file which includes the offending line says:
Code:
line256 $len = strlen($_POST['cc_number']);
line257 $this->cc_middle = substr($_POST['cc_number'], 4, ($len-8));
line258 if ( (defined('MODULE_PAYMENT_CC_EMAIL')) && (zen_validate_email(MODULE_PAYMENT_CC_EMAIL)) ) {
line259 $order->info['cc_number'] = substr($_POST['cc_number'], 0, 4) . str_repeat('X', (strlen($_POST['cc_number']) - 8)) . substr($_POST['cc_number'], -4);
line260 }
line261 }
I'm too php-ignorant to know what's causing the problem here, or how to fix it. But since this section refers to 'MODULE_PAYMENT_CC_EMAIL', I thought maybe this could be the reason emails aren't being sent.
Hope this helps!
Keep getting this 1062 Duplicate entry error..
i keep getting this error when im trying to apply the sql patch:
1062 Duplicate entry 'CA' for key 2
in:
[INSERT INTO so_payment_types VALUES (NULL, 1, 'CA', 'Cash');]
If you were entering information, press the BACK button in your browser and re-check the information you had entered to be sure you left no blank fields.
i tried both with the file and with copy and past the query
anyine knows what to do....?