Post by wsapplegate » Mon Oct 27, 2008 3:42 am

Hi everybody,

My enterprise is about to deploy its third OpenCart-based Web Site, and I would like to (1) thank everyone who contributes to the project (finding it was a real boon, I was extremely happy to relegate the mass of festering spaghetti code that is OSCommerce to the bit bucket), and (2) try to contribute back our changes. Here is a list of patches and their description, take whatever you want, all patches are in unified diff format : That's it. If you've got any comments or questions, feel free to ask in this thread. Like OpenCart, these patches are licensed under the GNU Lesser General Public License, version 2.1 or later.

Newbie

Posts

Joined
Wed Sep 26, 2007 8:55 am

Post by Qphoria » Mon Oct 27, 2008 4:06 am

Looks like you did a lot of work there. I hate to say it, but you would have probably been better off using the latest SVN version as your base, or at least 0.7.9RC3

0.7.8 is pretty much dead as we are nearing the release of 0.7.9 Final

But at least you got a chance to get intimate with OpenCart, and we can take a look at some of the patches to see if they are still needed to be fixed in 0.7.9 ;D

Thanks!
Last edited by Qphoria on Mon Oct 27, 2008 4:08 am, edited 1 time in total.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by wsapplegate » Mon Oct 27, 2008 7:01 am

Looks like you did a lot of work there. I hate to say it, but you would have probably been better off using the latest SVN version as your base, or at least 0.7.9RC3
Yes, I was expecting this remark ;-) Actually, my patchset is always based on the last released version, as I use it primarily for customer deployment and I'm (obviously) reluctant to deploy beta software in production. I will port it to 0.7.9 as soon as it gets released, though.

As an aside, I missed 0.7.8 availability by several months because the opencart.com home page still says
Latest Version
0.7.7 released 9th October, 2007
May I respectfully suggest an update (yeah, I could have looked in the forums before, but still...)?
0.7.8 is pretty much dead as we are nearing the release of 0.7.9 Final
Good to know. I was about to upgrade our installations, but if the release is coming soon, I'll delay the upgrades a bit to avoid duplicating work. Thanks for the head-up.

Newbie

Posts

Joined
Wed Sep 26, 2007 8:55 am

Post by Qphoria » Mon Oct 27, 2008 8:08 am

Yea there are a lot spots where the new version is posted and then we have the maintenance of remembering to change them all. I believe Daniel and HM2k are looking at switching the main site to Drupal, and then integrating the forums after we get 0.7.9 final out.

We half-expected to have released 0.7.9 Final two weeks ago but when we opened up the forum area for bugs, it seems a lot more people found it easier to chime in with some bugs that have been overlooked for a long time. In the long run this is a very good thing, as it just means it will be even more stable.  :)

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by jty » Mon Oct 27, 2008 10:34 am

are looking at switching the main site to Drupal,
For a moment, I thought you meant Ubercart  :o

From reading words only and not downloading and testing, I like these ones
Preselect the first choice on every checkout page, allowing the customer to just click away to the next page like a dazed monkey (customers hate being asked to actually *think*; we've listened to them :-)

Do not display reviews when they've been disabled in the admin

Adds a print stylesheet to the admin CSS, enabling the shopkeeper to print uncluttered invoices

Sends mail to the shop owner on a successful transaction, so he doesn't have to click the refresh button all day long
Coupons need to be hidden too, if not used.

I also like the "French" flavour patches.

jty
Active Member

Posts

Joined
Sat Aug 30, 2008 8:19 am

Post by Qphoria » Tue Oct 28, 2008 12:15 am

We are looking at some of these for 0.7.9 final and the next "feature" version....

Some of my personal thoughts... not to be regarded as the team's thoughts.....
wsapplegate wrote:
This is one we are trying to handle a bit differently. My initial fix was the same, to put all the stuff loading at the top. But then all css loads for pages that don't required it (like the product.css will load on the home page unnecessarily). We are looking to either use some sort of post-processing like the xhtml contrib or another pre-loading method that creates a css array stack after all the tpl files load, but before the layout.tpl loads. But it is certainly on the radar for the next "feature" version.
wsapplegate wrote:
It appears that when you insert a product, and set the name to "Baskets & Balls", it is saved to the database as "Baskets & Balls". When it is read on the front end, in html, it shows "Baskets & Balls". Same for images. So I think this is inherently fixed in 0.7.9
wsapplegate wrote:
This one I think needs to be fixed.
wsapplegate wrote:
This is only a fix for the "French language" contrib, not OpenCart?
wsapplegate wrote:
This might be worth having as well, Always good to have a fallback.
wsapplegate wrote:
This is planned for the next feature release.
wsapplegate wrote:
Another good fallback idea.
wsapplegate wrote:
Isn't this already happening? I see it in my 0.7.8, unless I don't understand the fix.
wsapplegate wrote:
This would be a good future-proofing step
wsapplegate wrote:
  • http://intarweb.goretsoft.net/~wsappleg ... ment.patch This patch adds the SIPS payment system. SIPS is quite popular in France, having been adopted by various banks (under different names: Société Générale markets it as Sogenactif, BNP Paribas as Merc@net, etc., but it's the very same system). The checkout gateway page is not W3C-compliant due to the SIPS `request' binary outputting b0rked HTML...
This would be best as its own contrib that others could simply drop in for plug n play.
wsapplegate wrote:
Not sure I understand this one. A customer can't see his account if he switches languages?
wsapplegate wrote:
This would be a cool mod if it allowed configuration of the tracking url and could be used for any/most shipping services instead of just Colissimo. Still would probably be best as a contrib.
wsapplegate wrote:
Another one for a contrib, is it not possible to keep that self-contained within the shipping module itself?
wsapplegate wrote:
Also should be Colissimo contrib.
wsapplegate wrote:
This really isn't the correct way to do this. the "review_status" setting is meant to disable the Reviews sidebox module. But that doesn't necessarily imply that you completely want to disable reviews for your products.

Really the best way would be to add an option to the products themselves to allow reviews at a per-product level. This way you can choose which products are allowed to be reviewed, while still allowing reviews to exist, with or without the sidebox. I'll add that to the todo list.
wsapplegate wrote:
Good idea for future version.
wsapplegate wrote:
We will look to include them in the english if they haven't been fixed yet.
wsapplegate wrote:
Very good idea, also already planned for the next feature release.
Last edited by Qphoria on Tue Oct 28, 2008 12:23 am, edited 1 time in total.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by planetgroove » Tue Oct 28, 2008 1:01 am

wsapplegate wrote:
Not sure I understand this one. A customer can't see his account if he switches languages?
Yes, that's right. I have seen the same behaviour. When you switch to German on the frontend the history is not available. Switching back to English, the history is shown again. Maybe has something to do with this bug http://code.google.com/p/open-cart/issues/detail?id=92
May be a general problem caused by the way OpenCart handles the languages ...?

http://www.planetgroove.com


New member

Posts

Joined
Sun Oct 26, 2008 12:18 am


Post by hm2k » Tue Oct 28, 2008 1:17 am

wsapplegate wrote:
Most of this is already fixed in 0.7.9, apart from the CSS loading.
wsapplegate wrote:
Already fixed in 0.7.9
wsapplegate wrote:
I thought I had fixed this, there's a couple of issues with this, but luckily I'm an expert on this.
wsapplegate wrote:
Issue is with the "French language" contrib, please contact the author of the contrib.
wsapplegate wrote:
I had considered this before, I had done this in other projects. This seems to be a similar topic.
wsapplegate wrote:
Feature. We plan on making slimming down the default checkout procedure to make it easier for users to complete orders.
wsapplegate wrote:
I was actually looking at this function today. There is no bug here, if you look further down if there's no $encoding, $data is returned anyway, however I may use this to slightly improve the function. r171.
wsapplegate wrote:
The templates already send UTF-8, which should be fine.
wsapplegate wrote:
http://code.google.com/p/open-cart/issues/detail?id=94
wsapplegate wrote:
  • http://intarweb.goretsoft.net/~wsappleg ... ment.patch This patch adds the SIPS payment system. SIPS is quite popular in France, having been adopted by various banks (under different names: Société Générale markets it as Sogenactif, BNP Paribas as Merc@net, etc., but it's the very same system). The checkout gateway page is not W3C-compliant due to the SIPS `request' binary outputting b0rked HTML...
Contact the payment sips contrib author.
wsapplegate wrote:
http://code.google.com/p/open-cart/issues/detail?id=95
wsapplegate wrote:
Contrib, not bug.
wsapplegate wrote:
Contrib, not bug.
wsapplegate wrote:
Contrib, not bug.
wsapplegate wrote:
http://code.google.com/p/open-cart/issues/detail?id=96
wsapplegate wrote:
This is a feature, and a view feature at that. The default should really show an example, but it's not required.
wsapplegate wrote:
Surprisingly these typos still exist. http://code.google.com/p/open-cart/issues/detail?id=97
wsapplegate wrote:
On TODO list as BCC admin.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by planetgroove » Tue Oct 28, 2008 1:18 am

Addendum to the above posting regarding language switching and problems for the customer viewing his past orders:

When you change the language setting on the admin-pages, the order-status and the download-status settings are changed automatically somehow. Don't know why. But that leads to the problem, that the formerly set status "complete" for the order and the downloads are reset to "canceled". Therefore the customer cannot access his downloads anymore. This can only be corrected by again accessing the settings page in admin and setting the download-status manually back to "completed". But: when the language is switched again, the setting is again reset.

http://www.planetgroove.com


New member

Posts

Joined
Sun Oct 26, 2008 12:18 am


Post by Qphoria » Tue Oct 28, 2008 2:08 am

planetgroove wrote: Addendum to the above posting regarding language switching and problems for the customer viewing his past orders:

When you change the language setting on the admin-pages, the order-status and the download-status settings are changed automatically somehow. Don't know why. But that leads to the problem, that the formerly set status "complete" for the order and the downloads are reset to "canceled". Therefore the customer cannot access his downloads anymore. This can only be corrected by again accessing the settings page in admin and setting the download-status manually back to "completed". But: when the language is switched again, the setting is again reset.
The order statuses were bugged and fixed in the latest svn based on JNeuhoff's earlier bug report:
http://code.google.com/p/open-cart/issu ... d=90&can=1

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by planetgroove » Tue Oct 28, 2008 3:25 am

I'm not that familiar with SVN. If I would like to "upgrade" my test-installation with the fix, how to do this? Is it sufficient to only replace the relevant files with the files on this page: http://code.google.com/p/open-cart/sour ... r=170  ?

What about the database? Is it then automatically changed/clenaed up of the surplus entries too?

http://www.planetgroove.com


New member

Posts

Joined
Sun Oct 26, 2008 12:18 am


Post by Qphoria » Tue Oct 28, 2008 3:35 am

To get the latest SVN you can see the tips here: http://forum.opencart.com/index.php/topic,1994.0.html


SVN isn't really too hard. its just like opening a file explorer in windows more or less.

But for the order_status fix, if you just want that, you can run the following in phpmyadmin for your database:

Code: Select all

DROP TABLE IF EXISTS `order_status`;
CREATE TABLE `order_status` (
  `order_status_id` int(11) NOT NULL auto_increment,
  `language_id` int(11) NOT NULL default '1',
  `name` varchar(32) collate utf8_unicode_ci NOT NULL default '',
  PRIMARY KEY  (`order_status_id`,`language_id`),
  KEY `name` (`name`)
) ENGINE=MyISAM AUTO_INCREMENT=17 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

INSERT INTO `order_status` (`order_status_id`, `language_id`, `name`) VALUES ('2', '1', 'Processing');
INSERT INTO `order_status` (`order_status_id`, `language_id`, `name`) VALUES ('12', '1', 'Canceled');
INSERT INTO `order_status` (`order_status_id`, `language_id`, `name`) VALUES ('3', '1', 'Shipped');
INSERT INTO `order_status` (`order_status_id`, `language_id`, `name`) VALUES ('1', '1', 'Pending');
INSERT INTO `order_status` (`order_status_id`, `language_id`, `name`) VALUES ('16', '1', 'Complete');

Still not sure why the numbers are so high for canceled and complete
Last edited by Qphoria on Tue Oct 28, 2008 3:41 am, edited 1 time in total.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by hm2k » Tue Oct 28, 2008 5:18 am

Look at the "AUTO_INCREMENT=17", it means that daniel had added/removed 16 items before he had settled.

For the purpose of the initial install, I don't suppose it really matters if we reduce the id, so long as all references are also updated.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by wsapplegate » Tue Oct 28, 2008 9:25 am

Well, first, glad to hear some of the issues are already fixed in 0.7.9 :-) As for the rest:
We are looking to either use some sort of post-processing like the xhtml contrib or another pre-loading method that creates a css array stack after all the tpl files load, but before the layout.tpl loads. But it is certainly on the radar for the next "feature" version.
Yes, the latter would be the preferred way as far as I'm concerned (speaking as a template author).

This would be a cool mod if it allowed configuration of the tracking url and could be used for any/most shipping services instead of just Colissimo. Still would probably be best as a contrib.
Well, it stores URL patterns with each order and all shipping services could use it, theoretically (it's just a matter of filling the right fields in the order table).
This really isn't the correct way to do this. the "review_status" setting is meant to disable the Reviews sidebox module. But that doesn't necessarily imply that you completely want to disable reviews for your products.
Sorry. I was unable to find an adequate control in the admin, and I just took the easy route. If I can help with a better solution, I'm all for it.
Issue is with the "French language" contrib, please contact the author of the contrib.
Actually, I'm hoping French will be integrated in core in the next versions; it's just a few kilobytes anyway, and I don't think a language pack could cause bugs...
I was actually looking at this function today. There is no bug here, if you look further down if there's no $encoding, $data is returned anyway, however I may use this to slightly improve the function. r171.
Huh... That's embarrassing. I'm quite certain this fixed something, but I wrote it in April, and I completely forgot what exactly was the problem. Please ignore, if I happen to remember, I'll post again.
The templates already send UTF-8, which should be fine.
Allow me to be unbelievably pedantic, and quote RFC 2616, § 3.7.1:
When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value.
Please include the character set in the HTTP headers. You never know what user agent will be reading your content (think braille readers, indexing crawlers, etc.). Better safe than sorry.
Contact the payment sips contrib author.
Well, I *am* the payment_sips contrib author, and the patch you're quoting *is* the payment_sips contrib. Anyway, maybe I should repost this in the other forum...
Contrib, not bug.
Contrib, not bug.
Contrib, not bug.
Well, the three are indeed features but the first two touch core files, hence they're not really additional contrib extensions. As for the last, yes, contrib (but since it depends on the previous patches, it's not practical as an independent extension, either. The best I could do is a tarball with the files plus the patches and instructions to apply them before installing the extension. Cumbersome, to say the least. I'll post it to the contrib forum anyway).

Newbie

Posts

Joined
Wed Sep 26, 2007 8:55 am

Post by Qphoria » Tue Oct 28, 2008 9:51 am

wsapplegate wrote: Well, it stores URL patterns with each order and all shipping services could use it, theoretically (it's just a matter of filling the right fields in the order table).
Technically most shipping services are a tracking url, and the tracking number is plugged into it the url:
USPS: http://trkcnfrm1.smi.usps.com/PTSIntern ... gTrackNum=123456789
HongKong: http://app3.hongkongpost.com/CGI/mt/gen ... ?tracknbr=123456789HK
UPS: http://wwwapps.ups.com/WebTracking/proc ... &tracknum=123456789

So a mod could be made to set the service id and tracking number on the order and that would map to the correct url to use.
Sorry. I was unable to find an adequate control in the admin, and I just took the easy route. If I can help with a better solution, I'm all for it.
We are looking to either add it as a global option in admin->configuration->setting OR per-product in catalog->product
Actually, I'm hoping French will be integrated in core in the next versions; it's just a few kilobytes anyway, and I don't think a language pack could cause bugs...
Heh, we just spent the last hour ripping all the german language out of the core because none of us speak it well enough to support it. We would like to pull all languages out to separate language packs to keep them all the same.
Huh... That's embarrassing. I'm quite certain this fixed something, but I wrote it in April, and I completely forgot what exactly was the problem. Please ignore, if I happen to remember, I'll post again.
Well, this is what I see in my html source from 0.7.8 and 0.7.9:

Code: Select all

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html dir="ltr" lang="en">
<head> 
<title>Your Store (Powered By OpenCart)</title>
[color=red]<meta http-equiv="Content-Type" content="text/html; charset=utf-8">[/color]
And that value is set in the language file like catalog/language/english/english.php:
$_['charset']               = 'utf-8';

So it seems to already be explicitly passed.
Well, the three are indeed features but the first two touch core files, hence they're not really additional contrib extensions. As for the last, yes, contrib (but since it depends on the previous patches, it's not practical as an independent extension, either. The best I could do is a tarball with the files plus the patches and instructions to apply them before installing the extension. Cumbersome, to say the least. I'll post it to the contrib forum anyway).
Have you tried all possibilities to keep the changes self-contained in the contrib files? ( I assume yes.) There was one or two contribs that I made that also required a change to the core... namely the authorize.net module doesn't use form enctype of "multipart/form-data". There could be other payment methods that don't use that enctype as well so it made sense to change it in the core to allow an override. I will look to see if there is any damage from the change you would like.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am
Who is online

Users browsing this forum: No registered users and 9 guests