This is based on Raymond’s SMF connector so it looks, tastes, feels, sounds and smells the same too!
The read me is in the main folder.
This post is just for the files.
Version 1.0 Notes:
There are going to be issues but it does work with the latest osc BETA and would most likely with some minor changes work with osc 2.2.
Tangent-Warrior
Ok, a question arose about osc beta 3.0 and osc 2.2:
I chose 3.0b because that it does work and the majority of the layout is now CSS. A slew of classes and other nifty things are already in place and while I’ve been playing with it, it has been basically stable.
Stability is an issue too, I ask the age old question what is stability? In osc terms I’d venture to say that everything they’ve released has been basically pretty stable (outside of old cvs versions). Since this was officially announced, I’m betting that they just did the 2.0 routine except got smart and labeled it "beta" just to keep people quiet and stop the annoying, "when is it coming" questions.
Yes, the roadmap is layed out for 6 more months but ... you know how it goes, 6 months = 1 year.
The problem is for custom shops. The never ending dilema.
This is something that I was playing with over the last few months. osc is just not modular! end of story.
I was able to modularize the old cvs 3.0 beta (very old and most incomplete version of today’s beta) and it did made sense. Developers could work in one area without affecting many others. However, will osc ever go down that path?
I did make a comment at osc about ModX and it’s really good code design. I wonder if we ever got a few hits or members because of that?
Anyway, what are your ideas?
Tangent-Warrior
Ok, looks like this is bringing no attention.
I was wondering that maybe this should be moved out into the wild and let other people see it on the main forum area.
What do you think?
Tangent-Warrior
But osC haven’t labelled 3.0 "Beta". It is labelled "Alpha 3". Of 6. There’s a world of difference. Sure, it’s worth playing with, but the fact that it doesn’t fall over doesn’t mean it’s ready to use.
As far as I can tell, they’ve changed the checkout and payment parts - so I’ll probably need new merchant payment modules. They’re unlikely to become available until 3.0 hits Beta. Which is after Alpha 6.
Also, they’re not releasing the 2.2 conversion utilities until Alpha 6. Sure, I could figure it out now, but the reason the conversion isn’t there is that the db format has not settled down yet. It’s just not ready.
I’ve not yet had chance to find the equivalent part in 2.2 that needs changing in 3 as the structure is wildly different, nor have I yet had chance to install MODx alongside my test osC 3a3 install.
--
I have a highly customised osC 2.2 based setup that I use on about half a dozen shops. In fact, I’ve customised it further just this week. My osC is already more CSSey and less tablesey than the default templates. I need it to work alongside MODx. My plans are, roughly:
1) Both installed at root; MODx taking over control of all text pages (eg terms and conditions).
2) Shopping cart session maintained while visiting MODx pages.
3) Featured products boxes written as MODx snippets querying osC database.
4) Templates look the same; menus generated together.
5) Product edit box switched to TinyMCE
6) All osC admin functions available in MODx manager
7) Addition of suitable access privileges
8) Port product search pages to MODx
9) Port product more info pages to MODx, with friendly URLs (and redirect on old style)
10) osC/MODx user interoperability
So my end goal is for MODx to cover everything up until the checkout. The checkout will stay largely as osC code. I don’t actually have any things that an osC customer would need webuser privileges for in MODx, so it’s far far down the list. The number of admin users is small enough to give them a new password if it came down to it.
Now, as my osC is currently very different to a standard osC install, and as I wish to take the opportunity to improve osC during the process, I’m not sure how much is going to be generically useful to anyone else. The extra time needed to strip out references to custom fields is considerable! I will share what I can though.
--
Carsten, I did suggest that you post in Project Team about this because I believe that the attention you will get in the open forums is unlikely to be helpful at this stage. I’m very sorry that I didn’t respond sooner, but that’s just the nature of things. Hopefully I’ll be proved wrong about the reaction you’ll get from the public. As it is, if you want to go down the 3 a3 route, and I go down the established 2.2 route, we can see what can be shared along the way.
@ Paul
Paul could you send me a copy of your osc?
@ thoughts
I do agree with Paul on many points! And basically what Paul has written is also what I personally think. At the moment, I need to get a modx/osc out by October 1st ( a one-off for a friend ) this is basic reason for my rush and really don’t need to produce a final package but a running something ...
I did do a fork of an old cvs 3.0 and that was were I was headed but the newer 3.0a3 was just that much better of a base to go off of. Paul is right about the waiting process and the final release will be that much more tastier but ...
@ future
So, that leaves the age old question. Do we end up with a fork of osc just for ModX and if yes, which version would we go with?
Now, the problem here is that the masses need a solution now.
I think, that most of this would work just out of the package. The problems that I am expecting from this OSC Connector release will be basically the same for 2.2 or 3.0a3.
So, I am not set either way, I just am thinking ahead for the future and was thinking to work towards and save time by not focusing that much on 2.2.
@ hash it out!
Come on folks let’s hash this out some more! I love goods comment since you can normally gain something from lot’s of input!
Tangent-Warrior
Quote from: Carsten at Sep 23, 2006, 03:31 AM
@ Paul
Paul could you send me a copy of your osc?
No. My fork is heavily inter-related with some non-GPL parts, is split over two domains, is re-engineered to use the same codebase for multiple sites (which requires a particularly fiddly setup) and many of the customisations are for UK-oriented.
Quote from: Carsten at Sep 23, 2006, 03:31 AM
So, that leaves the age old question. Do we end up with a fork of osc just for ModX and if yes, which version would we go with? Now, the problem here is that the masses need a solution now.
I think it’s easier to think in terms of the data and the connection between osC and payment processors. People with existing shops will have existing 2.2 style data, and need to use 2.2 style payment wotsits. So 2.2 is the "now" solution.
But of course the other questoin is whether we wait for MODx 0.9.7, as that should make some of the other interconnection easier...
I’ll try that when I’m at the office tomorrow, but I suspect that the MODx hack needs to be moved above the line
if (sizeof($stack) != 2) return false;
Re admin users: indeed, my shop admin security is htaccess based. I think ordinarily there’s only one user; we’ve changed ours to have a superuser (us, can set config things etc), main user (client, just sees what he needs to see) and light user (person authorised to add products but not look at orders).
I can justify work time to get our osC 2.2 fork working alongside MODx, and we’re happy to share appropriate parts with the community where such integration can be easily made to work with other osC setups (including the default osC setup).. but full integration might just be easier with MODx 0.9.7. Indeed this would be a good test of 0.9.7.
By the time osC 3 is deployable for actual shops, MODx will be on 0.9.7 or even 1.0, and the other integration parts will be easier.
ooops, I thinnk you’re right!
3.0a3 uses a stack===3 check.
Sorry about that!
Ok, so let’s aim for 0.9.7!
:D
Tangent-Warrior
MODX Staff
