Thanks. Fixed.Johnathan wrote:Here is (I think) a new one: since the price column was added recently, the colspan is off in /admin/view/template/catalog/product_list.tpl when there are no products. Replace:
with:Code: Select all
colspan="7"
Code: Select all
colspan="8"
If it's been resolved I've yet to see a clear breakdown or solution. Mostly I see this exact same post from you. There are only dozens of possible solutions that may or may not work in all cases. If you have something solid then I can take a look at it and test it and see about adding it to the core.OSWorX wrote:Guess you are using the original OpenCart?
Then it is clear, the included mail class has bugs.
This is already discussed long time ago (lot of threads here - use the search), but the developers ignore that fact.
I've gone through and fixed all the confirmed bugs listed in this thread. I plan to have 1.4.9.4 released this week. Before you ask.. no.. this has no effect on 1.5.0. Daniel is working on 1.5.0, I am working on 1.4.9.x. Mostly bug fixes and minor improvements. At some point we will combine the fixes from 1.4.9.x in to a stable 1.5.x, but for now this is business as usual. Here is the list I have:
Anything else?
I am still looking into the USPS double currency and coupon applies if cart changes issues. But I'm happy to say that the new invoice generator system seems to be working perfectly.== OpenCart v1.4.9.4 ==
FIXES:
- Colspan fixed for admin product list when no products found
- Search not working on all pages fixed
- Removed Foreach in Cache::get function since it returns after the first file anyway
- Added touch() to cache file before unlink to avoid the file race condition
- Add IP back to order edit page (accidentally removed in 1.4.9)
- Removed language status check for download edit
- Fixed language autodetect to check if language is enabled
- Fixed php error when loading information controller with no information_id
- Possible additional fixes for mail to use base64 encoding in subject
- Fixed column width issue fpr product totals in admin order edit
- Updated Paypal Standard to latest patch
- Fixed text_error in category page
- Email validation simplified to check for *@*.*
- Fixed security issue with Moneybookers payment gateway
ADDED:
- Specials listed in the admin product list also show when start or end is 0000-00-00
- Allow resetting invoice id to 1 by changing invoice prefix
- Added invoice_date field to order to store the date the invoice was generated
- Added invoice date to actual invoice print
- Added additional help text for some features to explain their function better
- New Account Create alert mail option
- Added email to db insert for admin on new install
- Converted setting.php controller to use the new proposed optimization standard methods (cut filesize in half)
- Added additional security params in htaccess
- Additional minor code optimizations
Anything else?
have a look at this: Cache unlink() Errors - v1.4.9.3 - Possible Patch.
And what about the e-mail validating issues? See: Email Validation.
And what about the e-mail validating issues? See: Email Validation.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
yea.. that is pretty much the gist. An alternative is to restore the original error handler for the unlink step, so that the @ still works, and then return back to the custom error handler.JAY6390 wrote:How will the touch stop the race condition? because it makes the file if it's deleted between?
I tried to add a try/catch but it seems unlink doesn't throw an exception, just a notice
Can we have warning for options in Cart or checkout page? I think this should be a bug since day 1.
Some clients added items in basket before we have options for some items, but when they checkout or view the cart, it doesn't have warning or advise the client to update these items after.
Thanks!
Allen
Some clients added items in basket before we have options for some items, but when they checkout or view the cart, it doesn't have warning or advise the client to update these items after.
Thanks!
Allen
I know nothing about PHP and SQL, but I still try my best to understand it.
The cart has always had a quantity check on products and options since day 1. Perhaps you dont have it enabled. "Allow Checkout" in the settingallenshea wrote:Can we have warning for options in Cart or checkout page? I think this should be a bug since day 1.
Some clients added items in basket before we have options for some items, but when they checkout or view the cart, it doesn't have warning or advise the client to update these items after.
Thanks!
Allen
You haven't understand what I mean, here I attach 2 pictures to explain.Qphoria wrote: The cart has always had a quantity check on products and options since day 1. Perhaps you dont have it enabled. "Allow Checkout" in the setting
This is the right in cart and order details. Clients added items in the cart after we had options.
Order with Options - options.jpg (79.39 KiB) Viewed 4503 times
This is not right, if the clients already had these items in their cart before we added options. When they view the cart or click check out, should be some warning to let clients make choose for options. or we will got the order like
Order W/o Options - wooptions.jpg (24.85 KiB) Viewed 4503 times
Should be a bug for OC?
I know nothing about PHP and SQL, but I still try my best to understand it.
Just curious, I listed a couple of issues with multi-cart on page 7 that appear to be bugs, but they seem to have been passed over... is that because its multi-cart? or not bugs? or previously solved and I missed it? (btw Q we just picked up your authnetsim module and it works straight of in 9.3 tx!)
1.4.9.4
LOL, this is the other way around!allenshea wrote:You haven't understand what I mean, here I attach 2 pictures to explain.Qphoria wrote: The cart has always had a quantity check on products and options since day 1. Perhaps you dont have it enabled. "Allow Checkout" in the setting
This is the right in cart and order details. Clients added items in the cart after we had options.
This is not right, if the clients already had these items in their cart before we added options. When they view the cart or click check out, should be some warning to let clients make choose for options. or we will got the order like above pictures from 2 orders, options.jpg from Order ID: #742, wooptions.jpg from Order ID: #755
Should be a bug for OC?
You should make sure that BEFORE you show your product in your store you have your Options etc. set.
You want us to build a fix for a "mistake" you make, or are you just being lazy?
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
This is not a mistake I made, If you had a product in your shop, after few days you got some new options for that item, say some accessories, it is very normal for a product.
But if without fix for this bug, you will always got the problem in Orders. Am I right?
But if without fix for this bug, you will always got the problem in Orders. Am I right?
I know nothing about PHP and SQL, but I still try my best to understand it.
Allen is right. This happens when you change options for a product and someone has that product in their basket with options already. Even if the same options have been set/saved, OC wipes the options and puts them into the database again. This is a very poor way of getting the options to work, and IMO an unnecessary step. That said Allen, this has been known for a while, and isn't considered a bug, although I have to agree it shouldn't happen
Yea.. allen is right.. just not explaining it right. I would consider it a bug personally.
The issue is the way options are saved. When updating a product, it is easier to ensure you've covered all bases by simply deleting and re-adding options instead of running the update command. So a new insert gives a new option id and when the saved cart reloads it realizes that original option doesn't exist so it drops it. But even if we changed it to update, you'd still have a problem if you actually did delete the option and add a new one.
So actually the fix is quite simple. Compare the date_modified date with the date_added on the saved cart. If the date_modified is newer than date_added, just delete it from the saved cart. That should do it.
The issue is the way options are saved. When updating a product, it is easier to ensure you've covered all bases by simply deleting and re-adding options instead of running the update command. So a new insert gives a new option id and when the saved cart reloads it realizes that original option doesn't exist so it drops it. But even if we changed it to update, you'd still have a problem if you actually did delete the option and add a new one.
So actually the fix is quite simple. Compare the date_modified date with the date_added on the saved cart. If the date_modified is newer than date_added, just delete it from the saved cart. That should do it.
That's not really a fix though to be honest. a better way in my opinion would be to add an extra hidden field to each product option and product option value that has the current respective id's in. then get a list of each id that gets passed back to the model for the update, delete any options not in that array of ids, and then update those ids with the new info, and add any new ones
Obviously if you delete an option and re-add it, you're going to lose that option, but it means not every option is deleted. I wouldn't say this is easy but it's not going to be impossible to do
Obviously if you delete an option and re-add it, you're going to lose that option, but it means not every option is deleted. I wouldn't say this is easy but it's not going to be impossible to do
But then wont that be more confusing? If a customer addsJAY6390 wrote:but it means not every option is deleted.
Computer
- Mouse: Logitech vx
- Keyboard: Microsoft 4000
- Ram: 4G
Then you delete the Ram option, their cart updates with just:
Computer
- Mouse: Logitech vx
- Keyboard: Microsoft 4000
But that isn't what they want. I'd think they'd rather rebuild it again to choose the new available options. By blowing it away, they just intuitively assume they need to re-add it. I suppose a message could be on the login page stating "an item in your cart has changed and has been removed" or something if you want to get fancy
I'm not saying they don't need to update the product options again, what I mean is that when people generally edit a product, they don't mess with the options (such as change a title, price, or add a link to a new category) but even in these instances the options get destroyed. This is unnecessary, and can be worked around
Oh.. I see what you mean.. in the admin when changing the product, if the options don't change, don't update them. Well that would be good too. I'll look.. tho I'm not likely gonna spend a lot of time on it since this issue should actually remedy itself in 1o.5.0 since the product_id will map to an option_id of the new options so the need to properly use "UPDATE" instead of delete/insert will be required anyway.
Who is online
Users browsing this forum: No registered users and 10 guests
