What do you expect?

[cuwet]

I'm not a coder, but would love to be one. I love opensource stuff... It's absolutely great.

 

I have been using Postnuke and PostTep, an old Postnuke module of OSC that is not being developed anymore.

 

I love the features in both PostTep(OSC) and Postnuke. What makes me very sad :cry: is when I go look at all the contributions on the OSC site that will not work on PostTep(OSC).

 

As I'm not a coder... who am I to ask to make this right. I know that all devs involved in both projects work very hard and have to focus on their mission or things get messy and die.

 

The point I want to get to is this.. We all have things that we do for nothing in return. The hardest is being asked to do it more... and by someone who has done non of it(ie. ME). I know that feeling all to well, but I also believe in the line, "No pain, no gain" and I reckon the more the pain, the more the gain.

 

OK... so if mankind is ever going to unite who's going to do the pain stuff. Postnukers or OSCers? (I'll do beta testing for sure)

 

Could there not be a window of oppertunity, when OSC dev stops to give some postnukers time to pnAPI it. At the end of that deadline the OSC dev can either continue where they left off or make a seemless jump to the new OSC pnAPIed version.

 

Sorry if this doesn't make sence. Probably why I don't code.

--

cuwet

[Guest]

Could there not be a window of oppertunity, when OSC dev stops to give some postnukers time to pnAPI it. At the end of that deadline the OSC dev can either continue where they left off or make a seemless jump to the new OSC pnAPIed version.

It doesn't have to be an either/or thing. If someone wants to take the time to design a pnAPI wrapper for it, they are always welcome to do so. By their nature, milestones are good times to do that. However, it is unlikely that OSC is going to support the pnAPI to the extent of requiring people to use a pnAPI program to make changes in the same way that they require Cascading Style Sheets now.

 

A better idea is to start thinking about how MS3's Template Structure Implementation can be generalized to make it easy to add pnAPI (or other template managers) hooks to OSC. Properly done, this would make adding pnAPI support as simple as adding a new shipping method.

 

No general code freeze needed. Just development of an interface that will be stable over the long term. This is another reason to support the push for increased use of classes. Classes are designed as a tool for creating this kind of black box interaction.

 

--Matt

[Guest]

So you really want to reimplement theme, block rearranging (instead of the manual commenting stuff you have now), permissions and all that?

 

Actually yeah... I tried PostNuke before and not only did I find it cumbersome but it was poorly coded and comes with a bunch of junk that I don't want. Your opinions might vary.

 

Personally, I don't consider PostNuke a CMS. It has a CMS module but the overall script is more accurately a portal. I don't necessarily want a portal for my shop. I want a shop where people can find things and spend money. If the shop is buried in some block, that might not happen.

 

There are quite a few things that OSC is missing and I will be glad when they are implemented. The least of which is themes as most stores only have one theme anyway instead of it being selectable like in your average portal applications. However I would like the ability to have multiple stores off of one database with categories assigned to one or more stores and each store with their own theme. Now that would be a great feature to implement.

[webmedic]

lol well ostnuke .8 will be out soon enough. We have already added the themeing system and the code base has been thouroughly cleaned. We have another developer which just signed up to even make our security tighter as that is what he does for a living. Oh and for the poster above the core is the core only we dont include all htose modules anymore you will have to download what you want and install it as far as content goes.

 

Anyway I have already considered this for some time and well to tell the truth I expeced the kind of responce we see here nobody wants to work together on anything. They would all rather code everything from scratch. Me I don't. I would rather build on other projects if I can. If the other project wants to work together that is even better.

 

Having said that since I'm afraid we will see no support from this community (please prove me wrong but from the comments above it is pretty obvious) anybody that would like to work on a project to port osc to postnuke please email me. [email protected] . I'm willing to work with anybody interested in this. It will be fairly easy as most of the code will not even be needed. Mostly we will pull out blocks and then create the module from the pieces left that will meet our needs. It will be fully skinable whit html templates. Along with this I'm looking at an erp system to go with it. All those interested please email me.

[Guest]

nobody wants to work together on anything.

Mostly we will pull out blocks and then create the module from the pieces left

Irony thy name is forum. (Misquoted from a usenet saying.)

 

The true way to work with others is to be modular. OSC understands this. This is why they are working on creating classes and template support, to make it possible to integrate with other projects *without* gutting the code. What you are talking about is making a competing complete solution, which will work great until someone tries to install a contribution that uses the code you gutted out because you had something else that you preferred.

 

Which is, of course, why tepNuke is no longer developed.

 

--Matt

[webmedic]

well yes the truth of it is that this would end up being convergent. Because yes it would be done in classes and yes the template engine is already done and has been in use for a few years now. I dont really care about what mods are avaialble here for this and that. With the code in a more maintainable form like they are proposing sometime in the furure would be a great help but that is still a ways off. Why wait when what is needed is already avaialble. It's that simple.

 

Basicly yes what I'mtalking about is a wholesale shift in thinking and doing and instead of puting it sometime in the future making it available whithin a few months. solutions are needed now by many and well that is what I aim to provide solutions.

 

There are many in many communities that want solutions so give them what they want.

[wisanggeni]

I like to share some of my opinion ; while positioning myself as a common user.

 

First, I think it's very complicated to ask the OSC Dev.Team to port their wonderfull project to another project (PostNuke) just like that. OSC itself is allready a rocking stuff by their own. ...while on the other hand, I have spend over 2 months to figure out "...how the hell can I install this wonderfull OSC to it's perfect!?"

 

...as a common user, I found it very tricky to setup OSC in a fast and (very) efficient way ; considering of my tight schedule.

 

~~~~~~~~~~~~~~

 

Second, PostNuke on the other hand had a large variety that I like to offer along with all of my products. It has the key of a theory so call "Friendly Marketing".

 

...by now, my shop is based on PostNuke + PostKart. And I sell Computer stuff. ...I'm not just selling a computer or two, I sell hundreds of them! ...not including computer parts.

 

And the question is : "How am I gonna sell hundreds and hundreds more computer parts if I'm just standing there?"

 

Good shop is the one that makes customer back for more. How? ...by being kind, friendly to a customer, give them some or more knowledge about the product they're looking for. ...to be simple, Extreme Marketing.

 

*.You don't just stand there hoping for a (perfect) customer buying your item.

 

...and I think PostNuke (+ OSC?) does it!

 

~~~~~~~~~~~~~~

 

So, if there's anyone of you like to improve what is allready GREAT to become PERFECT!

...please do!

 

- a common user of both stuff.

Wisanggeni, Indonesia - South East Asia.

[Broadway]

Ok I feel like putting some .000000002 cents in.

 

 

I too am currently looking for CMS/ERP/CRM/Shop type of solutions. I have not liked what I have seen in the CMS world to date. Most of them look like portals/news more than anything of relevance for me and mine.

 

I believe in modular programming, and wish there was a way to "mix and match" php/mysql apps to facilitate ones needs more efficiently. Knowing that my biggest need currently is CMS/Shop there is nothing out there. I love OSC. This is the first time I have stepped out and tried to hack anything of its size, but was glad the community and developers are here.

 

Understanding that most of us that us OSC need CMS where do we really stand? Forking is for the birds. When one forks things are lost and support becomes relevant.

 

Does OSC plan on just staying a shop? If so, then what provisions can we do on our side to make integration with/to CMS's is more readily available.

 

On the flip side, I would ask that those CMS's develop or help develop a way to take current ms and incorporate it into their apps as well.

 

Just wanted to chime in.

[webmedic]

no problem the exact things you gus mention is why I'm headed in this direction. I would rather work with others on this also but wheather they want to work or no I will do this. The nice thing with postnuke for instance is that if you dont need certain parts simply shut it off.

 

The nice thing is that with it using hooks you could have an article link it to an item you sell at the item have comments and customer feedback on it. have ratings for items. I know that osc does alot of this but the point is it can be hooked altogether fairly easily.

 

I think the one thing I will definatly try ot keep in the interfaces for the pay systems and for the shiping to allow for easy droping in of htese parts. Any other part of osc that is more or less a plugin can be easily kept or at least that is my idea.

 

We also use adodb for database abstraction so if osc is not database abstracted then that would need to be done also.

[fixion]

You seem to have misunderstood a few things of what I wrote.

 

First of - my idea was to do it so it works like gallery does (ie. standalone AND as a module).

 

I think forks is a waste of good manpower, and I will definetely try my best to avoid this.

 

My hope was that the OSC devs would support (ie. NOT do it themselves, but help deciding how it would be done best, and accept it in the main codebase) working on making an API of some kind to OSC, so that one could easily plugin a pnAPI etc. so that any CMS could developer their own API layer to make OSC work with their CMS.

This would mean that the users have as much choice as possible (they can use OSC standalone, or any CMS with OSC as a module).

 

You do a great shop, is it such a bad idea to want to modularize it (using some sort of API), so anybody could write a API-module for their own CMS and make use of it's great features?

 

I've got some ideas on how this could be done, but I don't have much insight in the OSC code, which is why ideas and suggestions from the OSC devs would go along way to help this.

 

I'm sorry, but I can't see how wanting this, is stepping on somebodies toes.

[wisanggeni]

It's an opportunity to expand what was good enough by now, to become the NUMBER ONE by tomorrow.

 

It's not gonna hurt.

Creativity won't stop here.

It will extend FAR, FAR more than this...

[apprentice]

I agree that OSC is, so far, the best shop available out there. However, I would also like it to be a multi-shop, one database type of project. Peter McGrath was trying to set a mall-like interface but he stopped contributing the improvements to his code. He had the right idea, separate features per shop, etc. The main page would serve as a "lobby" featuring various shops with their own categories, products, payment and shipping capabilities. Why did he stop developing or contributing his code? Beats me! I think this is exactly what most of us are looking for. Linda McGrath also had a pretty good multi-shop set up but I have never found a contribution from her regarding that kind of set up.

 

Additionally, I agree with fixion. This awesome project needs to be more manageable for the whole community (not just those in the development team), and it needs a system to be able to quickly add the features we need without having to fiddle with the source code so much. Updates and contributions should be done almost automatically. I realize you don't like to hear about how other projects have dealt with these issues. However, learning about their solutions can bring greater light to developing your own! Others like E-Xoops and Xoops have a very manageable system to add the features (contributions) one may need with minimum chances for error. They have also made available tutorials regarding their coding for those of us who enjoy creating or modifying (customizing). I don't understand why OSC cannot do the same. It is very hard to get answers to error messages, etc. in the forums. I've seen many important questions go unanswered. Customizing the shop is extremely time consuming since it has to be done mostly on a file-to-file basis and by hand.

 

It is extremely frustrating and nerve wrecking to have the work you've done for hours get undone because you update to a new snapshot. Almost every time I add a new contribution that requires altering the source code in some way, something goes wrong. Some contributors do not give clear instructions. They might be excellent programmers but lack skills on giving directions. Furthermore, whenever I update to a latest snapshot, I lose everything I have managed to add successfully. It shouldn't be so! I tried saving the changes to the application_top.php files under the local/configure.php but it did not seem to work. Then again, there were no instructions on how to do this or how it works (using the local/configure.php). Now, I've noticed some changes (improvements) in the coding in the lastest snapshots. That's great but . . . the contributions' coding remains unchanged! So, where the instructions say to look for this line saying so and so, the syntax has changed in the new snapshots. More time consuming tasks hunting down the right lines to modify!

 

So, you don't want to be like the other guys! Fine, it's your prerrogative but sharing means making it easier for others to follow and also contribute to the initiative. There is no need to let ego and arrogance blind us! Making things hard, confusing and sooooo time consuming hardly helps advance anything and being inflexible discourages most people who could greatly contribute to this project. If there are methods and tools out there already set up to make changes easier and less error prone, why not use them? If you don't like what is out there, create your own and make it available to the community. It would make your work and ours much faster and easier!

 

I know that dissent is very unpopular nowadays. It seems that you are not very open to feedback and suggestions from members outside the developing team. I am sorry but that is a failing attitude to have. After all, not only developers are involved, using, and care about this project. I hope you will reconsider your position for the good of the project and the community. Thank you. :idea:

[judgej]

Summed up nicely. Thanyou.

[stevepurkiss]

I used to work for a company who spent years building a J2EE web app development platform with many of the features *nukes have, along with store functionality. They burnt through $5m of funding without selling much and went bust last year, and I've learned many lessons from this, so I'd like to put my point of view (free world et al.).

 

Take a couple of loosely relevant examples from Primesense's ten top Sales & Marketing steps to business oblivion:

 

* Try to ensure that nobody within the organisation ever actually talks to customers, particularly the management team or the marketing department. Encourage the belief that with the amount of knowledge and experience you've got on the team, asking real customers what they want is an unnecessary luxury. You may need to make an exception for the sales-force, or people will get suspicious, but this isn't a problem as sales people very rarely communicate anything useful back into the organisation anyway

 

* Don't segment your customer base. Treat all your customers exactly the same - never mind how large or small they are, what problems they have, or what their value is to your business. Make sure nobody tries to measure the profitability of different customer groups, or somebody might cotton on to the fact that most of your profit comes from a limited number of customers and suggest that you focus resources on retaining and developing them. This could have serious ramifications, prolonging the life of your company by several years.

 

* Move everybody out of marketing and into product development. Make sure nobody's responsible for finding out whether there's any demand for what you 're developing. If anybody questions this, just tell them that 'Great products make their own markets' and 'Nobody every developed breakthrough products by asking customers what they want'. If they really press the point, put a group of your product managers into a workshop for a day and ask them to produce a market demand forecast. That should prove conclusively that there is a sizable opportunity out there, just waiting to be seized.

 

Now with the above points in mind, take my position - I've been trying to decide which content management/portal/appdev platform to adopt for my clients existing and prospective as I don't want to write stuff from scratch, and I don't want to learn more than one CMS inside out, but when I read threads like these sometimes I wonder if I should bother at all with any of them.

 

For example, I have a client who is a reseller of digital content, mainly PDFs. They need supplier logins so suppliers can upload new products, alter pricing, etc. They also have a very complex pricing structure which depends on what subscription a user or company has bought, and in the latter case they want companies to be able to manage their own accounts - i.e. add users, see reports, etc.

 

I thought to myself 'OSCommerce, that looks great', but then it doesn't have the complex subscriber functionality I need, and as their site is also a community site I thought it would take too much customisation to be a viable proposition. Now I'm thinking more on the lines of integrating DreamAccount from DreamCost with PostNuke, XOOPS, or Xaraya (as it has mods for these) - it deals with subscriptions and I can write the pricing module myself.

 

But then I look at PostNuke and find out the main developers have left for Xaraya, so I download that and man is it complicated - maybe I'm just thick, but it's not easy to use (I know it's still in Beta, but can't find any user docs anywhere). I've written a module for PostNuke before, and it's not pretty, which is why I looked at the OO designed XOOPS. XOOPS looks good, but then I read about Xaraya lead developer saying all the *nukes are flawed as it's hard to make them look totally different. Then I read PostNuke's got a new Smarty based template engine coming. Then I read about security and find PHPNuke has one of those security login mods with the non-machine readable number people have to type in when they login, which is a great feature my client would love - they can't afford to be hacked. PHPNuke I threw out ages ago because I didn't like the fact it seemed to be run by one guy, but it has a lot of support and mods - that's what's important to me when developing a commercial solution - I don't want to come back in a year and find my CMS of choice is discontinued.

 

My point is this: Why don't all CMS/Commerce developers take a leap forward and develop a common API / Interface? Take the who's logged in blocks for example, or forums. They all have 99% exact same functionality, so why do people have to create a mod, then convert them to X amount of CMS and commerce systems? Why move in loads of different directions when we could all move forward?

 

I guess from the tone of this thread that OSCommerce will be developing their own CMS functionality for OSCommerce - if not then they will be losing out on a whole load of customer opportunities. Believe it or not, people /do/ want integrated CMS and Commerce - why should people have to spend many weeks integrating diverse systems? Integrated ones will always win, which is why *nukes are so popular. Open Source is becoming much more accepted in the business world, and with the possibility of selling a huge amount of support contracts it's worth listening to the market and taking stuff like this seriously.

 

I am sure my clients would gladly pay for such an integrated system - if you look at the commercial equivalent you're looking at tens of thousands of pounds - even if you sold business licences at $100 each you would make a hell of a lot.

 

Integrate, don't disintegrate.

 

Steve

[Guest]

My hope was that the OSC devs would support (ie. NOT do it themselves, but help deciding how it would be done best, and accept it in the main codebase) working on making an API of some kind to OSC, so that one could easily plugin a pnAPI etc. so that any CMS could developer their own API layer to make OSC work with their CMS.

They are moving in this direction. Codewise, this is what the moves to an increased use of classes and an integrated template engine accomplish.

 

For example, when the session code is implemented as a class, one could replace it by simply replacing the class with one that has the same name and methods but different internal logic (actually, you could do this now by replacing all the functions that says tep_session* with your own versions).

 

--Matt

[judgej]

...Believe it or not, people /do/ want integrated CMS and Commerce - why should people have to spend many weeks integrating diverse systems? Integrated ones will always win, which is why *nukes are so popular.

 

...

 

Integrate, don't disintegrate.

 

I would add: interoperate, don't isolate.

 

I think the crux is in how the integration is done. If the cart is too closely bound to the CMS, then it would reduce the choice for the end users, as the OSC cart would only be usable within one CMS. As you have found - there is no perfect CMS for all people, so that would not be a good move.

 

If APIs were built between the cart and the CMS functionality, then it would be possible to replace the CMS part with any CMS going. That, I believe, would increase the choice and versatility of the cart, and the hence userbase. It all depends on whether the OSC project wants to see fragmented ports to other systems: oscnuke, xarosc, oscxoops; or OSC running within all those CMSs as an application in its own right, but sharing the CMSs' security structures, sessions and data.

 

I'm not asking anyone on the project to actually do this, but it would be nice to know exactly what the objection is to the whole concept of interoperability with other applications. The whole idea just seems to be dismissed out of hand.

 

From an end user persective: I have already chosen my CMS, now I am choosing the cart that will operate within it.

 

-- Jason

[ocularmagic]

Well, I think that the dev team should concentrate on getting a nice stable, usable cart, which is what they're doing right now. There are people constantly asking, when is this going to be released, when is this going to be done. Then there are the people that are saying, you should add this, you should do it this way, why don't you do this? Why not just let them finish MS4 so there is an extremely nice base to start from, then start worrying about integrating with CMS'. If you think it should start now, take the code and start, or make your suggestion and wait. Don't get mad because they don't want to use your idea. With 10,000 members on this board, I'm sure they hear their fair share of suggestions. The fact that they even talk to people on this board is a plus. They're giving you the code for free, which makes them obligated to do absolutely nothing.

[judgej]

It's just a discussion - I don't think anyone is getting mad yet ;)

 

It is exactly this kind of discussion that helps lead the direction of the project. If we all just waited, then he dev team would never know what we wanted, and would just have to guess, with the potential of being way off target.

 

This kind of thread allows us all to see where the project is heading, to help decide whether we should join the project (if it is heading our way), to take the code and carry it another direction. Just waiting is not normally an option. As we are here, there is a good chance we need something along the lines of a cart pretty much now.

 

Without the dialogue, it all draws to an end rather quickly.

 

-- Jason

[ocularmagic]

I agree, I'm just hoping it doesn't turn into another thread about how people make suggestions to the dev team and nothing happens. I just think it should be suggested and if it get's turned down, that should be it. There was another thread asking if they were going to be working on integration with a CMS and the answer (if I remember right) was no. I have no problem with discussions, I was just putting in my two cents.

[judgej]

I think some ideas need to be put forward a number of times before the value in them is seen. So "will you integrate OSC into some other CMS of my choice" is likely to get turned down, with good reason. Further discussions on the thread tend to get tainted with the original idea - even when the discussions has moved on.

 

Another quesion "do you ever see OSC moving in a direction that will allow the cart function to be more easily integrated into a third-party CMS" - now that is a different matter altogether.

 

No to the first question means "do your own integrating", while no to the second means that the focus of the project has shifted somewhat from a cart function to a *much* broader application that may go way beyond some people's needs.

 

With a plan well understood, people can start making their own decisions on what to do next. They don't have to like it, but that is the plan to abide to. When the plan is not clear, the bickering starts. Suddenly a project is not going the direction that anybody wants, since it is all speculation.

 

I'm not saying that is necessarily happening here, but I do feel that many questions are being dismissed as whining, rather than trying to address the underlying needs of the people asking the questions or making the suggestions, and telling them straight how the present plan will affect their needs. That's just my impression.

 

-- Jason

[ocularmagic]

Like I said before - we're developing a full blown e-commerce solution, not a CMS or CMS plugin.

 

If I wanted osC integration with a CMS, I would think the above quote would mean to code it myself because there is no plan to do it at all. Of course, maybe if a lot more people keep requesting it, or making suggestions on how they could do it, that may change, but I wouldn't hold my breath. I apologize if I sound harsh, I'm not meaning to, I just thought the above quote answered the original question, that's all.

[judgej]

Yeah - I think I missed that one. It is pretty clear that there is no plan to enable the modules to be plugged into anything other than the OSC CMS. To be a full e-commerce package, I think a CMS underlaying the project is going to be necessary. In fact - I think we are all in agreement that a CMS of some sort underlies any goal the project aims for.

 

If that is the plan, then so be it. It looks like I am going to have to do that cart module port after all...;)

 

-- Jason

[Guest]

We don't want to talk you into things. And we don't want to promote Postnuke or anything but you could at least evaluate the features of the forthcoming Postnuke .8

 

The core will function without the many modules phpNuke needs and postnuke .7 still needs. You could use the core of postnuke with it's permission-, templating and user system to integrate into osc. That way you could concentrate on your shopping system and let other people do their job on the permission-, templating and user system. You could release osc with a romp-postnuke and nobody would notice, if he doesn't want to.

 

But this way osc could be expanded with all the modules, postnuke already offers.

 

A modern shopping site like Amazon consists of much more than you a kart system - you need user comments aso. Comments are eg already available as hook-module. This can be "hooked" into any supporting module.

 

But it's your choice to waste time on work that has already been done by other people. You are free to do that ;-)

[ocularmagic]

you need user comments aso. Comments are eg already available as hook-module. This can be "hooked" into any supporting module.

 

I believe osCommerce has the functionality to let users write reviews on products already.

 

Can someone tell me exactly what the specific benefits of integrating a cms would be? How would shoppers benefit from it? Would it generate more sales somehow? As a shop owner, I want people to spend money. How is a CMS going to increase their spending? I'm not being sarcastic, I really would like to know.

[judgej]

Can someone tell me exactly what the specific benefits of integrating a cms would be? How would shoppers benefit from it? Would it generate more sales somehow?  As a shop owner, I want people to spend money.  How is a CMS going to increase their spending?  I'm not being sarcastic, I really would like to know.

 

From my point of view, the CMS's that have been set up for my clients to distribute information, do not sell many things either. By adding a cart to the CMS, they can start to sell things.

 

If you start with a shop, it can be difficult to see how adding a CMS can help. If you start with a CMS, it is easy to see how a cart can be useful later.

 

-- JJ