Jump to content
Latest News: (loading..)

Recommended Posts

@@wHiTeHaT I don't know if you manage an online store or just are an oscommerce programmer, but if you can do it run this SQL query to see what I'm trying to explain:

SELECT `customers_id` , `customers_name` , `customers_street_address` , `delivery_street_address` , `billing_street_address`
FROM `orders`
WHERE `delivery_street_address` <> `customers_street_address`
AND `billing_street_address` <> `customers_street_address`

It would be really useful if other store managers could do the saame and post results here. I've found so far 12 results from this query, and in all cases it was caused from costomers who put incomplete data on the orders and I had to edit the addresses, and for customers who has relocated and kept their old address as primary addres instead of deleting it. So those fields can, in best case, be redundant and in worse led to errors.

Edited by piernas

Share this post


Link to post
Share on other sites

no no my friend, like that it not work (for me):

https://www.pcisecur...s.org/index.php  Say's nothing to me... i (and other readers) want a explanation for what you say, i not go try to FIND what you try to say.

 

you read it on that site.... but WHERE? (be precise).

 

That "sample" query means nothing to me.... it does not say anything.

Concern in that case more for HOW data is inserted.

Consider to prevent mismatch results a auto-complete/address lookup API.

 

But i leave you now to your orders class....Goodluck!

 

Explanation of PCI DSS rules is not easy, but basically every merchand and programmer that works with CC data has to follow the rules of PCI DDS (Payment Card Industry Data Security Standard). Perhaps wikipedia has a more simple view of the rules so you can take a look at: http://en.wikipedia.org/wiki/PA-DSS

 

There are several points oscommerce 'as is' doesn't comply with, but there's one that's crucial (see it on wikipedia link above):

 

9- Cardholder data must never be stored on a server connected to the internet

 

Do you understand it now? Don't you think it's enough to remove those fields?

If you don't understand it just go to your bank or tell you CC provider you're currently using oscommerce for permanently storing CC data on its database and see what they have to tell...

Share this post


Link to post
Share on other sites

We just don't share the same concept of storing, for sure. For me a customer fills the data and your software stores it instead of . It's a clear concept for me.

 

There's a lot of other requirements also when using the credit card module supplied with it. Just to mention some of them, Oscommerce does not encrypt those stored data fields nor does have an admin access control system that allows those stored data to be hidden from certain employees or grant access to others, admin side allows you to see CC data under a non secure connection and so on.

 

There's a lot of threads in this forum discussing this matter, and if you look at them you will find many opinions like mine.

 

And take it easy, man. It's not a competition and nobody has to have the absolute truth, you don't have to shout continuously. we're just discussing about an interesting matter.

Share this post


Link to post
Share on other sites

@@wHiTeHaT I'm sorry, you're right about the cc module. I was remembering about cc.php module on oscommerce 2 RC2 as is the version I¡ve been using for years.

 

About storing the data I'm completely lost with your affirmations:

 

 

There is nothing wrong with storing the CC data as IS in osCommerce.

 

 


Now....once again..... osCommerce DOES NOT STORE CC DATA.

 

So what's the correct one? Does oscommerce use the order table data about cc or not?

 

I'm currently trying to comprehend how this data is used (if it is at all) in oscommerce.

 

You're misunderstanding me. I don't use my experience as a grade, in fact I couldn't find where I said that???? Experience for me is not a grade, but a way to learn and understand things. I don't consider at all myself an expert if that's what you think. I have no studies about programming and all of my little knowledge about php comes from experimenting with oscommerce and reading this and other online sites so the only knowledge I can mention is experience.

 

About shouting constantly for me it's not a matter of education in school but a matter of aquired respect. I try to treat everyone with respect including you. It's you who are saying about me talking crap and suggesting I'm not qualified to do anything related to this software.

 

For the rest of those who doesn't consider offensive to oscommerce asking questions: I'll be posting a topic later to see if someone else can help me with how cc database fields are used in oscommerce because these doesn't fit well in this topic; I'm currently reading the code but still didn't find an answer. For now I presume those fields are legacy code that was left there over the years from the time the credit card module was in oscommerce, but I'm still not 100% sure. We'll see what we can find :)

Share this post


Link to post
Share on other sites

Ok steep forward pls. cc is not as important than you are taking attentions in it. :)

How could be it closer? What would be the solution?


:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Share this post


Link to post
Share on other sites

Thanks @@Gergely I got distracted with the discussion. I'm just attempting to add the values to the class and all other relevant files.

 

I'm not good at github but will try to use a new branch to upload the changes proposed.

Share this post


Link to post
Share on other sites

@@wHiTeHaT it's difficult for me to follow your comments. Latest reply clarifies a lot because I didn't understand what you were saying. Now it's much clearer.

 

If the data is not stored/collected by oscommerce but by a module then personally I don't see the point of having those fields, independently of legal or contractual implications. If I understood you well the fields are not used by any piece of code of oscommerce and does not store any user input, right? So for me these are empty fields, useless, superfluous stuff left there forgotten when the cc module was removed. It's my opinion, and as a personal opinion I shared it in this post.

 

I don't store any CC data on my site, not just because rules, but because I believe it's not a good practice. It's a risk with no benefits. As I told before I've suffered a fraud because one online shop where I usually buy was hacked and my credit card data, along with the data from other customers was stolen. As a resul one day I received a credit card statement where I had supposedly purchased four cinema tickets in Sheffield, UK while I was in Valencia, Spain. So I've learned the lesson: I will never enter CC information on a cart system that stores or asks for CC data without a PSP.

 

About the language you use weird assumptions when arguing. To be clear: I speak decently two languages, spanish (my native one) and english, and understand a bit a couple of them more. May I have your permission to have a multilingual shop that offers both languages and manages them on a reasonably useful way or will you oppose because I could add a third language that I don't speak?

 

About the so-called customer address in orders table: I suggest you to re-read my previous explanation calmly and without prejudices (just in case you want to, I will not force you in any way), because you didn't understand it at all. In no way I speak about using a 'current address' or putting on the order some address the customer hasn't put there. I'm talking about the completely opposite thing; not using a field that oscommece does not take from the current user input. Just use the two addresses the useer inputs (billing and shipping) and completely remove the third one, that only shows AFAIK on the admin order details file orders.php and nowhere else.

 

Thank you for your excuses and please accept my apologies if I've said something that looks arrogant as I didn't have the intention to. I'm sorry for your headache; all I can tell you about it, again, is 'take it easy'.

 

 

Share this post


Link to post
Share on other sites

Again into the topic, I spent two hours today trying to get apache 2.4 and php 5.5 working thogether as the latest version of oscommerce refuses to install over PHP 5.3 on my local system. I'll publish a modified class as soon as I get it working.

Share this post


Link to post
Share on other sites

 

currency_value  Is it really useful?

 

 

For multi currency shops...yes

Share this post


Link to post
Share on other sites

@@piernas

 

https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf

 

This shows what is allowed (and what is not allowed) to be stored.  


This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest current code (community-supported responsive 2.3.4.1BS Edge) here

 

Share this post


Link to post
Share on other sites

A bit of a me too on this topic. Not so much with multiple languages, but with the text changing.

 

When sending orders over interfaces to other systems, the paid shipping method has to be derived from the language-specific text on an order total record - which is the same text presented to the user when choosing shipping method. This text seems to change more often than you would imagine (at least once a year!) so I implemented a lookup table to save rework.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

For multi currency shops...yes

 

I meant having the currency value inside the order. It could be taken from the currencies table, but I'm thinking it has to be the currency stated in the order, because it could change when between ordering and payment. Is it right?

 

 

A bit of a me too on this topic. Not so much with multiple languages, but with the text changing.

 

When sending orders over interfaces to other systems, the paid shipping method has to be derived from the language-specific text on an order total record - which is the same text presented to the user when choosing shipping method. This text seems to change more often than you would imagine (at least once a year!) so I implemented a lookup table to save rework.

 

Yes that's another issue I think has to be fixed. References to `payment and shipping methods should refer to some kind of service_id that doesn't change instead a name, even if the language is the same.

 

Finally managed to install php 5.5 on my test server and started the changes to the orders class and table and to the related files , starting with fields additiions; I will show here the results as I check everything related to those changes work.

Edited by piernas

Share this post


Link to post
Share on other sites

If you use store only an ID;

1. what happens to orders if the name (that corresponds to the ID) changes.  You have just (accidentally) edited an order.  Not good.

2. what happens to orders if the module (that corresponds to the ID) is removed.  Then you have the possibility of broken orders.  Not good.

 

It is important that the name gets recorded.  

 

As a more simple example, look at the orders_products table.  

What would happen in there if we did not store the name of the purchased product.  

If you deleted or renamed a product, the order would be trashed.


This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest current code (community-supported responsive 2.3.4.1BS Edge) here

 

Share this post


Link to post
Share on other sites

Use class name instead of ID as I suggested before. IDs could be change sometimes but class names always static and unique.

 

Moreover php class name used as filenames.

Edited by Gergely
morover

:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Share this post


Link to post
Share on other sites

If you use store only an ID;

1. what happens to orders if the name (that corresponds to the ID) changes.  You have just (accidentally) edited an order.  Not good.

2. what happens to orders if the module (that corresponds to the ID) is removed.  Then you have the possibility of broken orders.  Not good.

 

It is important that the name gets recorded.  

 

As a more simple example, look at the orders_products table.  

What would happen in there if we did not store the name of the purchased product.  

If you deleted or renamed a product, the order would be trashed.

 

I agree. With all of that. But for shipping we should still have all this in the order total record.

 

Keep the order total (we need to know how much it costs too!) - with the name at the time of ordering. The field on order is an extra to simplify when we need to code something based on its value. 

 

 

Use class name instead of ID as I suggested before. IDs could be change sometimes but class names always static and unique.

 

Moreover php class name used as filenames.

 

Yep. No need for a new id, the one we already have is best... just need to store it.

Edited by BrockleyJohn

For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

 

 

If not have a define..... it is no big deal.

But if you miss a class....you have more problems.

 

PLUS: it require lesser code/core changes, as you only need to manipulate the methode for when insert into order/orders_total table

 

Class loading overtake all language files and not easy to recover the class from a language constant. Language constant has similar problems as language text. Its bring us closer but not as close that we would like.

We would like to handle the order at admin site. (edit/modify/create/recalc)


:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Share this post


Link to post
Share on other sites

If you use store only an ID;

1. what happens to orders if the name (that corresponds to the ID) changes.  You have just (accidentally) edited an order.  Not good.

2. what happens to orders if the module (that corresponds to the ID) is removed.  Then you have the possibility of broken orders.  Not good.

 

It is important that the name gets recorded.  

 

As a more simple example, look at the orders_products table.  

What would happen in there if we did not store the name of the purchased product.  

If you deleted or renamed a product, the order would be trashed.

 

Yes you're right, the names must still be there to keep the order history. I didn't take in mind what you say until I started with the class.

 

@@BrockleyJohn don't worry about removing any fields, I won't do it at first unless they really look absolutely useless.

 

 

Use class name instead of ID as I suggested before. IDs could be change sometimes but class names always static and unique.

 

Moreover php class name used as filenames.

 

Yes that also came in mind when I started digging in the code. With the current way the shipping and payment method works it seems the best and easier option.

 

// is defined in payment module language file (if it somehow go missing... just put it in another language file)
define('MODULE_PAYMENT_PAYPAL_EXPRESS_TEXT_TITLE', 'PayPal Express Checkout');			

// retrieve $payment_method from table orders
$payment_method = 'MODULE_PAYMENT_PAYPAL_EXPRESS_TEXT_TITLE';    

// we show where we need it and in whatever language we chosen  
echo constant($payment_method);

So.... the goal should be.... to ONLY insert in db the constant, instead of the defined.

That is the onkly thing what needs to be done for the payments into orders table.

 

You can do the exact same for shipping, what is send to orders_total table.

 

This way is much safer as Gergely's way, as you still count for having a class.

 

If not have a define..... it is no big deal.

But if you miss a class....you have more problems.

 

PLUS: it require lesser code/core changes, as you only need to manipulate the methode for when insert into order/orders_total table

 

 

I'm not sure on what you mean. What fields you suggest to be stored in the database?

 

If we don't have something like a class or a unique id for each payment method we cannot identify the method used in a simple way. As @@bruyndoncx stated with his example you have to hardcode it or search for every payment method in every language file (or just in the language of the order if we introduce the language_id) one by one.

Share this post


Link to post
Share on other sites

@@piernas

 

Best is to take that piece of code and paste it on a test.php, just so you can see what happen.

 

Now.... imagine you insert : MODULE_PAYMENT_PAYPAL_EXPRESS_TEXT_TITLE  inside the db, instead of : PayPal Express Checkout

 

Then if you are on admin or on account_history , you simply : do the orders query but instead of how you normally call the payment method you now do : echo constant($payment_method);

 

@@Gergely, i not see any problem in this approach when want to manipulate an order.

If i would want to edit an order, i would make a copy of the original orderorder_id 1, parent_id 0 = original order and order_id 3 is new order with parent_id 1

 

Then the only thing i need to do is simulate in admin that i am the customer who "owns" the order.But just skip the processing that you would need to follow when are a real customer.

 

I think I had a vague idea at the back of my mind that the selected payment class name is already available in the create order process, while this approach would mean changing each module to return the constant name - or am I wrong?


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

@@wHiTeHaT I can see there are advantages with your approach. My experience with 2.3.x is still limited - are orders always created within payment modules now?


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

@@BrockleyJohn

The title itself is also available inside each payment module.

But now imagine you remove that payment module from your server completely,there will be no fall back to anything and when then lookup an old order, either from admin or client account, you will be having errors.

 

As for my approach you only need to have a define('blabla', 'paypal');

As for the other method you need to have a full class file + you need to tweak the orders table, with a chance that it not go work, and not will work for earlier versions of osC.

 

 

Actually, I think that whatever solution is adopted, it would be wise to code the evaluation of the field in such a way that it fails gracefully and displays the content if it can't be evaluated.

 

ie if the constant isn't defined, display the constant name (ok that's what it does natively, you don't need to code it - but what happens if the value has spaces in) and similarly for the class.

 

In either case, you'd still be able to tell what method was used. Probably.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

Ignore all that rubbish I just said - now I've thought about it properly.

 

If we're already storing the method as displayed to the customer (payment and shipping) we carry on using that where it needs to be seen.

 

In addition, we store a codified representation of the shipping & payment classes used, so that if we need it for processing logic or reporting, it's consistent across all (new) order instances.

 

Where that comes from and what's in it makes no difference to me as long as it's consistent. I'm never going to evaluate it, just use it as a value.

 

For interfaces and new order processing, existing order data doesn't matter. If they want to be able to report consistently across new and old data from the online database, then a shop-owner is going to have to figure out a way of populating new fields in historic data (shouldn't be that complicated).


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

Today I've installed Osc 3.0.2 to see what was planned for its database and I found the idea was already there and the orders table has both payment_method and payment_module fields. That looks fine, as you can still display the name even when the method is removed and you can programatically identify the method class easily. It seems to be the best option in my opinion.

 

I'm not familiar with Osc3 structure, but I'll try to find what other changes related to this class may be already there.

Share this post


Link to post
Share on other sites

@@piernas :thumbsup:


:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×