NukeCommerce Future (Discussion)

Posted: Wed Feb 23, 2005 7:48 am

In light of recent the defacement of NukeCommerce and its subsequent temporary closing... I'd like to know how users feel about the project itself.

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

Six raises a VERY important question here, with serious implecations. No one is out to attack or discredit anyone. But, an e-commerce site/application is much more serious when exploited. Nuke has enough issues of its own but should/can nuke be used/trusted as an e-commerce solution? Consider this scenario. Nuke is often times hacked by an SQL Injection exploit. If they can gain access and alter the price database, then even when you are transferred to an SSL site, like PayPal, PayPal will send verification back to your local database, check the altered price, and guess what? I just got a $100.00 item for $1.00.

From first glance, it "appears" that nukecommerce is not up to date with Chatserv's fixes. I could be wrong and if so I aplogize. It just looks antiquated.

Posted: Wed Feb 23, 2005 9:48 am

Yes I in no way am attacking the project or its leaders. In fact I'd like to be comfortable using a Portal with an Osc based shopping cart. But there are as Raven points out serious issues to consider that are very much part of the basic architecture of the application.

Posted: Wed Feb 23, 2005 7:30 pm

You all know my opinion on this, as explained in a different topic.

(sorry i never pm'd you back sixtono)

Posted: Wed Feb 23, 2005 8:42 pm

DJMaze wrote:

You all know my opinion on this, as explained in a different topic.

(sorry i never pm'd you back sixtono)

Please provide a link-back Smile

Posted: Thu Feb 24, 2005 8:32 am

http://www.ravenphpscripts.com/postt4646.html <= here it is.
I didn't want to fully exploit it, but i think that topic did made some people think about the issue.
Then nukecommerce.com got hacked and we all know where it stands in the world today.

Someone has to do something, but where do you start ?
It took us a year to fix php-nuke, and where did we end ?
Actualy we ended with a new CMS which is totally different then php-nuke.
So to us it seems almost impossible to merge both systems properly without a complete rewrite of the core.

Posted: Thu Feb 24, 2005 9:17 am

In many ways I think that NSN-Cart/Emporium could be an easier point to begin with for PHPNuke users. Why? To get anywhere with the present osc based options you have to port any contributions yourself and it almost gets to the point where simply building an addon from scratch for a more native system such as NSN-Cart/Emporium becomes an easier task. As good and numerous as they are many of the osc contributions are but a starting point even when they are installed and require substantial modification to become production quality. (there are exceptions)

Security of course remains the underlying issue. Is PHPNuke strong enough to support a quality online shopping experience today? For Best Buy, Comp USA probably not but for a small to medium sized endeavor I believe it is closer today then its ever been. But this isn't horse shoes and people look to the community leaders for guidance and to the date general feeling I get (also my own opinion) is approach with extreme caution.

Now I've gotten slightly OffTopic

but I think the community wants a portal based ecom solution very badly and since support often comes down to dollars... it is better served to give our support to the strongest solution what ever it may be.

registered · Useless Joined: Aug 23, 2002 Posts: 213 Location: Chicago

Very nice thread. I agree with you all that even after having OSC and other shopping carts, we need a good system and as of right now, NSN-Cart seems to be the one who can do it.
Is it safe to use PHP-Nuke as an eCom portal? I think so, we are very close to securing is completely, script wise, with exception of sticking with one version for a while and don't upgrade your site every month.

There are 3 places (to my knowledge) where Emporium's (NSN-Cart) work is in progress:
TechGFX (mostly fixing small bugs)
NSN: Main coding team
E-DevStudio: Porting the module as a standalone.

There is a problem with porting other huge scripts to PHP-Nuke, every time that script upgrades, porting team has to start from all over which is why we need a native module that was made for PHP-Nuke only.

Posted: Thu Feb 24, 2005 7:08 pm

Totally agreed NSN and Emporium are the best, but since emporium isn't supported anymore all my points go NSN.

As they say in european song festival: 15 points

Regular Joined: May 31, 2004 Posts: 95 Location: NY

NSN-Cart is Emporium, and Emporium is NSN-Cart. NSN-Cart was the original name, until I decided to rename it. Bob owns rights to Emporium now, however, my credits will remain in said files.

If you decide to continue the script, I recommend that you follow GPL completely. All code changes should be commented, etc.

[Admin: Edited]

Posted: Thu Feb 24, 2005 9:53 pm

I did sort of assume Bob would find someone to carry the torch for NSN with a continuation at some point in time. burnwave I can understand your sensitivity towards a renewed interest in your brainchild. We've simply tried to hold an open discussion on the topic as it relates to NukeCommerce and the various other options that are out there. Of which Emporium is still a top contender. For which you are to be commended for and if you have evidence that your work has been molested let us know so we can avoid inadvertently promoting any such works.

Posted: Thu Feb 24, 2005 9:56 pm

I second that. If that is the case and you can prove it, it will be be swift HitsFan

Posted: Sat Feb 26, 2005 6:07 am

Emporium out of the picture ?
I can't find any info about it on Bob's website and burnwave.com redirects to a new cms.
The only place i can find it is at techgfx.

Does bob have any plans with it since he has some health problems ?

Posted: Sat Feb 26, 2005 10:28 am

DJ, read my post above. Those are 3 places where Emporium's work is in progress and from my understanding burnwave, Bob, E-Studio or TechGFX won't mind if someone else tries to carry on the development as long as it stays under GPL and permission has been asked.

Posted: Sat Feb 26, 2005 10:56 am

Interestingly enough and off topic. I see http://creloaded.com is running on CPG-Nuke as its support site. (Yes I'm still looking at alternatives). Why? Because I think that one should be able to setup a site like this or 100 sites like this and all but leave it to run itself. With the occasional bugfix ect...

Posted: Sat Feb 26, 2005 11:33 am

Right, just like I said, stick with one version for a while instead of upgrading it every month.

Posted: Sat Feb 26, 2005 12:25 pm

@six: they are using our Dragonfly CVS files and it seems they recently updated as well.

@mesum: sorry, probably i didn't fully understand your post cos you said

Quote:

NSN: Main coding team

So i thought NSN has info for us Confused

About CPG-Nuke/Dragonfly vs PHP-Nuke (since some people look for different systems):

Both have their good and bad points to integrate a shop.
The strongest point of Dragonfly is the security, but the weakest point is the support and limited add-ons.
Both systems can integrate a shop easily but since this website is mostly php-nuke based i think you should stick with php-nuke UNLESS most people want to switch to a different system to run a shop (Vaelio, Xoop, Mambo, Dragonfly, etc.)

I think a newsarticle/survey should be written where people can respond/answer questions for it like:

What kind of ecommerce solution would you like to have:

1) License: A. GPL no warranty + no instant support, B. Commercial license + warranty/support

2) Integrate into: A. PHP-Nuke, B. Mambo, C. Xoop, D. Dragonfly, E. Vaelio

etc.

I think if a lot of people are open minded and answer those you could result in a good CMS+eCommerce solution.
Atm only 5 people talk in here so maybe that will help.

Posted: Sat Feb 26, 2005 1:24 pm

DJMaze I think your partly right the discussion could/should be focused on phpnuke/and/or CMS based solutions. But then we might have to drop down to 4 people because I'm still not convinced it is a wise direction to go at least for me.
ROTFL

It took me a while to get the cre-loaded package running fixes applied and so on but once I did I was pleased with the results. Now if we could just stuff it into Dragonfly... J/K

Posted: Sun Feb 27, 2005 12:51 pm

Vaelio:
Vaelio's CMS hasn't even been available for beta testing, so the idea of doing an ecommerce extension for our CMS would be out for quite a while. However, I already have plans on developing an ecommerce extension for our system shortly after the public release, as that is the main reason why I wanted to start this new CMS. As it stands, the engine is more flexible than any other CMS I know of, and certainly would be able to handle ecommerce solutions.

Emporium:
TechGFX and Bob Marion have agreements with me regarding the availability of Emporium. As far as I know, their versions will not be released under GPL, as requested.

Ecommerce for phpNuke?
Considering that I am the only person here who has developed an ecommerce addon for any of these mentioned systems, I know what is and isn't good for ecom. I would not recommend phpNuke, in the condition it is currently in. CPGNuke is more capable of supporting an ecom addon than PHPNuke. However, CPGNuke isn't popular enough to attract all the hard hitting exploiters yet, so there is no telling whether or not it is secure enough for ecom apps. Xoops and Mambo are fairly well known for security as opposed to the others mentioned (although I'm fairly certain our CMS does the job quite nicely), and are more suitable for ecommerce than Nuke.

Just as you mentioned for CPGNuke, there is a lack of addons/support for xoops and mambo. Unless the cms was built to handle ecom from the very beginning of the system's development, I would be a tad concerned about the security of the system that I'd be developing ecom for. You wonder why there aren't any decent ecommerce addons for xoops, mambo, phpnuke, etc. My guess is:

a) People are too lazy to develop ecommerce applications from scratch. They'd rather port an existing, larger, incompatible system into another large system (ie. oscommerce + phpnuke is a great example of this, as is phpbb + phpnuke). This eventually creates problems, and actually drags out development time for upkeeps when the standalone application is updated. It takes less time to start something from scratch than to port something; I know this from experience.

My take on this:
1) If people can, they do.
2) If people can't, they port a script.
3) If people can't port a script, they wait for someone else to create/port the script, only to rebrand the application and consider it their own.

b) A majority of people aren't capable of developing a cumbersome application like a storefront system. Too many options, variables, this and that, and folks just abandon the idea due to code upkeep and such. Unless you have got a large team who knows what they are doing, you can expect the ecommerce solution will die out fairly quickly.

Emporium, Calloway's Cart, etc are a great example of this. I stopped developing Emporium just because of the fact that I written it poorly, as well as the code upkeep due to the constant changes in phpNuke security and module structures. Why should I waste my time constantly updating my storefront code just because phpNuke has horrible security problems? Also, had I started the system at a complete OO standpoint from the very beginning, would I still be continuing the development of Emporium. Now that I am in control of the CMS that my solution will be for, it is easier for me to adapt my system to it, make those necessary changes in case something major needs to be changed in the CMS engine, etc.

Off topic
Not to make a pitch or anything, but our CMS is COMPLETELY object oriented, and I can't tell you how much more secure it is compared to something structurally like cpgnuke, phpnuke, etc. Of course, it's not the OO aspect of things that make things secure, but a system completely OO is easier to secure than it is with structured coding... or at least, that's what I know from experience.

c) Most content management systems don't have the flexibility or toolset for easily creating / managing a system as broad as ecommerce. If it's going to be too hard to get the CMS to support business solutions without having to make hacks to the CMS itself, people will forget about the idea.

Posted: Sun Feb 27, 2005 1:34 pm

Another major fallacy is the nuke and many, if not most, are not true CMS's anyway. They are a hybrid, at best, of a Portal and a CMS.

[CMS - Definition]

Quote:

Software that enables one to add and/or manipulate content on a Web site. Typically, a CMS consists of two elements: the content management application (CMA) and the content delivery application (CDA). The CMA element allows the content manager or author, who may not know HTML, to manage the creation, modification, and removal of content from a Web site without needing the expertise of a Webmaster. The CDA element uses and compiles that information to update the Web site. The features of a CMS system vary, but most include Web-based publishing, format management, revision control, and indexing, search, and retrieval.

[Web Portal - Definition]

Quote:

A portal is a kind of Web site. Technically speaking, a portal site includes a start page with rich navigation, a collection of loosely integrated features (some of which may be provided by partners or other third parties), and a large, diverse, target audience.

E-Commerce - Definition

Quote:

(Electronic-COMMERCE) Doing business online, typically via the Web. It is also called "e-business," "e-tailing" and "I-commerce." Although in most cases e-commerce and e-business are synonymous, e-commerce implies that goods and services can be purchased online, whereas e-business might be used as more of an umbrella term for a total presence on the Web, which would naturally include the e-commerce (shopping) component.

E-commerce may also refer to electronic data interchange (EDI), in which one company's computer queries and transmits purchase orders to another company's computer.

ecommerce, e-commerce, or electronic commerce is defined as the conduct of a financial transactions by electronic means. With the growth of commerce on the Internet and the Web, ecommerce often refers to purchases from online stores on the Web, otherwise knows as e-commerce Web sites. They may also be referred to as "virtual-stores" or Cyber stores. Since the transaction goes through the Internet and the Web, some have suggested another term: I-commerce (Internet commerce), or icommerce. e-commerce can be business to business (B to B) or business to consumer (B to C).

Industry accepted definitions. So, nuke and most others are a Portal and not a CMS. Why does any of this matter? Using php-nuke in particular, it was never designed (prior to fb's inept handling) to be what it is today. Enter fb and the myriad of 3rd party applications - with the exception of some - it has become insecurity upon insecurity, inefficiency upon inneficiency, spaghetti upon spaghetti, and on-and-on upon on-and-on. It is insecure with every release. Chat and others scramble for fast fixes. But, in the end, it never ends. The main reason, to me, is that the present author/maintainer (and I use the terms VERY loosely) just doesn't care. He doesn't. If he did he would: learn how to program, apply efficiency techniques, secure the code, TEST before releasing, lose the arrogant attitude towards the community, cut the crap, etc. I and others have talked about other designs but I, as well as others, spend so much time in support of the garbage that we don't have time to shower much. Others are making attempts, some good and some bad, but most of their attempts still center around the nuke format or even core and just try more bandaids. Adding insult to injury.

All that to say that an E-Commerce/CMS/Portal system is beyond the foundation laid by nuke an most others. You cannot be all things to all people. IMO, at the very most, settle on a Portal and have it LINK to E-Commerce.

Many ask me (or tyraid upon me), if nuke is so bad why do I stay with it? Am I not making money off of it? ETC. Well, as long as there is sickness we will ned doctors. As long as there are cars we will need mechanics. As long as there are shoppers we need Walmart. As long as there is nuke, you need my types Wink

I would love to have the time and support to build my nirvana. But, if I can't garner the financial support that allows me the luxury of spending time on development instead of trying to juggle a full time job plus, then my nirvana will not happen. Maybe someone else's will. But, IMO, build a Portal, add the channels, then add EC as a branch to a secure EC Portal.

This is not a pitch for anything. It is fact. Give me 12 weeks of support that matches my 12 weeks of lost income and I will build a better one. I can't in a few hours after I come home and on weekends. Get someone to sponsor me for 12 weeks and you will have it. Well, maybe 16 weeks Wink

Posted: Sun Feb 27, 2005 1:39 pm

Burnwave i see your point and yes CPGNuke isn't OO.
However our Dragonfly is 50/50 OO based and doesn't allow register_globals so that makes our security pretty high.

We still have to see if your CMS is good security wise.
Also a 100% OO based system isn't good for several reasons but that will be noticed soon enough.

Either way it all concludes that a CMS almost shouldn't have a integrated store although it has some benefits.

I'm already working on a eCommerce solution for Dragonfly but it's not OSS for several reasons.
Also this shop has solved very strong issues which are necklegted in all eCommerce solutions that are available for php-nuke.
I don't want to say the issues but trust me, you will understand when it's ready.
(Already working on this system for more then a year, so go guess)

Posted: Sun Feb 27, 2005 1:49 pm

I've been building major applications for major clients since 1970. You don't design for Sprint, Bridgestone, US Steel, Bethlehem Steel, etc. with mostly secure applications! If you want to make a system secur, modularize it and demand that 100% of any addon and included code adheres to it. It's not piece-mealed and overriden. It role-based and by design, not by chance. If you are going to continue to use anything similar to nuke you will fail and it will be broken. You will use Oracle, DB2, or at the minimum, MySQL 4.1 or 5.0 - STORED PROCEDURES - STORED PROCEDURES - STORED PROCEDURES. Security is in the database, not the code [per se]. It's in the design, not the code. It's in the Proof, not the code. It's in the structure from the first cell that divides itself. You do all that and the code MUST comply. You don't write the code and then expect the others to comply. That's why, if before I die I can get to it, I will produce a ROLE Based system. It is virtually break proof.

Disclaimer: This is my site, my opinion, and my right to say what I think ROTFL

Posted: Sun Feb 27, 2005 2:05 pm

DJMaze wrote:

Burnwave i see your point and yes CPGNuke isn't OO.
However our Dragonfly is 50/50 OO based and doesn't allow register_globals so that makes our security pretty high.

Our CMS doesn't require magic quotes, register globals, or any specific php settings to be enabled/disabled. Your claim of having cpgnuke run without globals is nothing new or original. It's a typical PHP coding practice these days, and it brings nothing special out of the ordinary... well, non-nuke related that is. It's just as standard as coding a php application with E_ALL, which I am sure you do.

If you want to go into the whole 'my cms / your cms' episode, whose is more secure, etc, I can certainly start a nice thread elsewhere for us to discuss this.

Quote:

We still have to see if your CMS is good security wise.

You will soon enough. Still working on the alpha version of the engine, then beta will come around, then onto the public release. I'm already impressed with where it is at right now.

Quote:

Also a 100% OO based system isn't good for several reasons but that will be noticed soon enough.

Sure, let me know what those reasons are.

FYI: We haven't had ANY problems whatsoever so far... OO has only made things easier for us to manage.

Quote:

Either way it all concludes that a CMS almost shouldn't have a integrated store although it has some benefits.

If the developers of said CMS are confident that it is secure enough and feature rich to handle a store system, then I don't see why said CMS shouldn't have an integrated store system.

Quote:

I'm already working on a eCommerce solution for Dragonfly but it's not OSS for several reasons.
Also this shop has solved very strong issues which are necklegted in all eCommerce solutions that are available for php-nuke.
I don't want to say the issues but trust me, you will understand when it's ready.
(Already working on this system for more then a year, so go guess)

I'm fairly certain that I know what these 'issues' are. Most of which are common sense. I stopped Emporium dev due to these issues not being covered from the beginning, and readding them would have take a good bit of my time.

EDIT *** Not to mention there is what, 3 store systems for nuke, none of which are tailored for big businesses? I am sure anyone can address those 'issues' you claim to have thought of yourself for any mentioned commerce system for *Nuke. /EDIT

Since you've been working on your own store system, why are you considering making a port from another product into said CMS? I don't get it.

Posted: Sun Feb 27, 2005 2:11 pm

Raven wrote:

I've been building major applications for major clients since 1970. You don't design for Sprint, Bridgestone, US Steel, Bethlehem Steel, etc. with mostly secure applications! If you want to make a system secur, modularize it and demand that 100% of any addon and included code adheres to it. It's not piece-mealed and overriden. It role-based and by design, not by chance. If you are going to continue to use anything similar to nuke you will fail and it will be broken. You will use Oracle, DB2, or at the minimum, MySQL 4.1 or 5.0 - STORED PROCEDURES - STORED PROCEDURES - STORED PROCEDURES. Security is in the database, not the code [per se]. It's in the design, not the code. It's in the Proof, not the code. It's in the structure from the first cell that divides itself. You do all that and the code MUST comply. You don't write the code and then expect the others to comply. That's why, if before I die I can get to it, I will produce a ROLE Based system. It is virtually break proof.

Disclaimer: This is my site, my opinion, and my right to say what I think ROTFL

As you said, sticking with something like nuke where the main developers offer no support or fixes, will eventually do you in for the worst. Especially when those developers have no idea what they are doing Wink

Posted: Sun Feb 27, 2005 4:33 pm

burnwave wrote:

Since you've been working on your own store system, why are you considering making a port from another product into said CMS? I don't get it.

I don't understand why i should defend or answer such questions.
Every coder knows the difference between OSS and Shareware and what people decide to use.

I stop here, it's getting more a fight on which CMS then to see all options.
Secondly http://vaelio.com/index.php?run=Forums&op=viewthread&id=61#194 does tell someone his believes and is way out of order.
Hack that whole forum http://vaelio.com/index.php?run=Forums&op=viewforum&id=9 is out of order on that website, and all normal adults know why.
If someone has trouble with someone then talk with the guy in person and don't try to shout behind his back on other websites because the other website has nothing to do with it.
Investigate first before you go rant and rave about something/someone and do apologize if you're wrong.