osc integration ????

Anyway, here are a few questions that I have:
- I was wondering what would be the basic level of integration of oscommerce with modx?
- Would anybody be interested even when shopX arrives on the scene?
- Has anybody already done this?

Cheers!

1) The basic level of integration of osCommerce with modx would be just to install both on the same server and link to each other. Easiest way is to have ecommerce stored in /shop, and use weblinks.
From there, the next level up would be to a MODx/osC shopping cart snippet that maintained the session between the two areas.
2) Yes, people would still be interested in this when ShopX arrives, because there are many established osCommerce sites out there and the osCommerce data structure is more appropriate for certain sites, particularly sites with a large catalogue.
3) I don’t know.

I wonder if the SMF bridge code could be adapted to do this?

hehe, I’m still pouring over the latest osc 3.0 a4 release.
There’s some good stuff happening there but they still haven’t seen the magic that Modx can do

Very cool Carsten... looking forward to seeing what you come up with. I’d love to see the osC order total, tax, coupon/discount codes, and shipping modules working with shopX... that’d be a dream indeed!

Hmmn. My dream is to display the osC catalogue within MODx, but then hop over to actual osC code for the checkout.
osC is strong on checkout, but poor on catalogue display / website content management.

But first I need to bring osC and MODx together - I’m actually migrating some osC clients to a basic osC / MODx solution in the next few weeks. This will not be in a /shop subfolder - instead, I am renaming MODX’s index.php to modx.php and changing the .htaccess accordingly. With friendly URLs and .php as the extension, I’m able to migrate all the content pages (eg terms, delivery info) over to MODx. So I’ll probably be writing an osCcartview snippet soon.

ugh, similar situation, eh?
I am doing this more as a volunter project than anything ... but then again I love wasting my time doing silly development things like this

Ahhh, similar things to what I was thinking.

There should be no reason why you can’t write snippets to pull information out of osc.

Currently, I’m pushing along with the new alpha 3.0a3.
I figure that the future is there, however what I’m working on at the moment should work with the 2.x.x series.
One problem might be converting old shops to the newer 3 db layout ... but then again this could wait till osc gets to the beta stage or public release when they’ll be working on the db converter. hehe, you can always do this by hand

been there - done that

Basically I took Raymond’s SMF bridge module and have started converting it to work with osc.
I just ran across a problem though.

SMF and ModX use "member" and not a seperate "first name" and "last name" setup. hmmmm
I thought of using osc’s login name which is the email address but that would be a little silly since ModX would spew it out as the member name ....

Or do you just smash the firstname’space’lastname together to form both the member and real names?

Next steps will be to work out some of the more detailed settings that the SMF Bridge pulls in. This is a bit of a pain since SMF uses variables while osc uses defines and DB queries. Oh well, now I get to learn the db API for ModX

Does anybody have and hints, suggestions, or ideas that make this conversion a little more fun and simpler?

Indeed, the only reason not to pull osC data into MODx snippets is the whole "it’ll be easier with xPDO" thing.
osC 3 looks to be at least 6 months off release; any really serious fixes are being released for osC 2.2 anyway.
I’ve already deviated from 2.2, so an upgrade wouldn’t be a slam-dunk. I’m not completely convinced by some of the new features in any case.

Anyway. Integration. I guess I’d be tempted to use the email address as the default MODx member name, because there are several John Smiths but only one [email protected] - that is to say, the uniqueness of the member name is the most important characteristic. But "CustomerX", where x is the osC id, would be better.
I would then make the user devise a display username when they first needed to post something on the MODx side. Most users of a MODx / osC site will not publish anything, and I would imagine that they would be more likely to do so if they could have a name that was different from the name on their card.

Key to this would be a login script that allowed users to login to MODx with their email & password (on an autodetect) as well as username / password.

That said, I can’t see any immediate need for users to login to MODx, so that side isn’t a priority for me.

EDIT: I just need to know their osC login session, so that I know to display links to their cart, order status etc.

lolo, boy do we think along similar lines. I was just thinking that IF going this far I might as well try to cover all avenues at one shot ... hmmm ... then again, speed for me at the moment is more important than a "best solution" hack.

I like the idea of CustomerID.

That shouldn’t be that hard to code in.


:D

update:
I got the admin to pull into ModX
Now to go an check user synchronization problems.

note: login is not automatic but ... hey, it’s just a click away.

I’m looking at a beta release soon.

I’m running through the db inserts at the moment and then some trial login testing ...

Is anybody out there willing to beta test before I release?