Treasury

Posted: Tue Oct 21, 2008 1:40 am

I would like to see something like RN Treasury (aka Nuke Treasury) or Donations in the next release of RN as it continues to be a popular add-on for a lot of people.
I don't use it myself as the code base seems a little dated and it needs configurable multiple currency support (as against a hard coded currency).

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

Agreed. There are various tweaks here and there, but I don't think there is a combined version that handles currency, allows transaction maintenance, renamed admin files, etc.

One issue is the separation of the data / individual config file for NT. I'm not sure that's really needed, but it was done for security because PHPNuke had such poor security at the time. However, I'm not sure what data needs to be secured, really. Thoughts?

registered · Posted: Tue Oct 21, 2008 6:00 am

I agree too that a simple, integrated and updated package would be very useful as we continue to get questions on it, and as "G" said, the code is quite out-dated. It would be even better if it could be integrated somehow into subscriptions and/or group assignments, but I might be getting way too far away from my "simple" requirement. Laughing

Posted: Tue Oct 21, 2008 6:06 am

I don't see any reason why whatever is needed in a config file could not be moved to a DB table but it has been such a long time since I looked at NT I don't even remember if it requires an IPN enabled PayPal account or not. I used NT for only a short time before migrating to other things as at that time I needed subscription based access.

Posted: Tue Oct 21, 2008 6:30 am

It does require IPN-enabled account, but that's easy enough to address. But I was talking about the recommendation in the installation / configuration to use a separate database for NT transactions.

Posted: Tue Oct 21, 2008 7:23 am

I see. Yes, I think that was just a precaution due to nukes reputation at the time. I don't honestly see why it would be beneficial to use a seperate DB today. Unless of course you are getting thousands of processes and need to split them off because due to hosting limitations (sql query limit) but that would be extremely unlikely.

Posted: Tue Oct 21, 2008 8:47 am

I'm not sure I understand exactly what Nuke Treasury does. I know I looked at the description a while back and it looked like it was doing more accounting type stuff and less Paypal than I needed. I have a custom module that does Paypal but it's very specific to my needs on two sites and I just haven't had the time to go back and "abstract" it. For instance, you really need a table of "things" to be sold with prices, descriptions and some kind of ordering in terms of what screens and in what order they should go. And a shopping cart.

I have been messing with Zencart a bit on my test site, fkelly.org. Basically, you download it and read the installation instructions and upload it to a server and install. It works a lot the way RN does with configuration files for database access and an administrative piece that's separate from the user piece. Basically it has a screen or menu or form builder where you can build text, or checkboxes or radio button inputs (or readonly) based on input names and values you enter on a screen. It's a little confusing to work with (there is even a book teaching how to use it) since your options are spread out over a dozen or more admin. screens and it's not always obvious how to change them. However, there is a wiki and a great set of support forums that are very active.

If you want to see one form that I built in a couple days time while teaching myself the product you can go to:

Only registered users can see links on this board! Get registered or login!

That's as of October 21 2008, I won't be leaving it in that state or on that site for long.

I put the zencart tables in the same database as those for a test RN2.30 distribution. So, theoretically you could write a module to go against the Zen tables and pull out data for reporting (there are some reports built in). I'm not sure that trying to make zencart work as a RN module would be worth the effort. It has it's own database access routines and a separate templating engine that would be hard to make work with RN themes (I think). However, you could certainly build between Zencart and RN that would make the divisions relatively transparent.

Posted: Tue Oct 21, 2008 9:18 am

Guardian2003 wrote:

Unless of course you are getting thousands of processes and need to split them off because due to hosting limitations (sql query limit) but that would be extremely unlikely.

I would love to see a site that got that many donations!

fkelly, NT is a module that allows donations / payments through PayPal and has a block (and the module) to display those donations. It has monthly goals, and shows progress against those goals (goal - monthly donations). It's not really a shopping cart, though what you've described about your custom code might be useful to many.

As for integrating with ZenCart, like osCommerce and other applications, it might be useful to share user accounts, and there are several possible ways to go about that.

Posted: Tue Oct 21, 2008 10:11 am

Zencart has a customers table and a customers info table (linked). It would be really easy to build a bridge of some sort to put your site users into the Zen customers table. And with the customization that's possible with RNYA it would be easy to require fields that are needed or used in the Zen customers table (date of birth, gender, email format (text or html), and telephone. The level of integration would be the subject of further discussion: you could add to RNYA to update the zen customers table anytime the nuke_users table was updated or you could just build a bridge to periodically update the zen table from Nuke.

My custom code is a disgrace right now Smile

I started with a specific purpose and gradually expanded it to another site but I need to go back and modularize and refactor it. One thing you need to do with a Paypal application is have a way to move easily back and forth between the real Paypal and their sandbox including having some items that are being tested in sandbox while others are in a production mode and using the real system. My code doesn't do that yet. And you can't, as far as I know, test your Paypal applications on any kind of local system because you need a real domain to have Paypal respond to. It gets really tricky.

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

As I am the 'official' owner of the NT SourceForge project, it has been on my list for quite a while but I haven't been able to set aside time to do much with it. I have a version which has Guardian's changes from a while ago, as well as Kevin's and my own.

Now that RN v2.3 is out and about I will have more time to devote to other endeavors Smile

. I hope to be releasing an official NT v2.0 in the near future. I might even suggest a collaborative NT Team effort - SVN, Mantis, et all?

Posted: Tue Oct 21, 2008 10:47 am

I would be very willing to participate provided we can make it into a more general purpose "store" for selling tangible items, memberships, downloads, etc. as well as donations.

Worker Joined: Oct 05, 2003 Posts: 107 Location: Illinois

A payment module is a vital addition in my opinion. I just wish there was a better free payment version than paypal. I have checked around and have not found one worthy yet. I have modified the treasury module to draw from the nuke database, because it is not really any more of a security issue than a stand alone database now. It definitely needs updating to work with numerous currency types though.

Posted: Tue Oct 21, 2008 9:15 pm

I will just say that I hope you (Raven, Loki and Guardian among others) will take a good look at Zencart. A module that is integrated into RN is desirable of course but why reinvent the wheel. Zencart has features that would take years of programming to duplicate. And to Loki's point about payment options, there are several built into Zencart.

I'm not "sold" either way. After spending part of a week learning Zencart I started refactoring my Paypal code today and that's in my Purchase module for RN. But there are not enough hours in a day for me to write currency support in or to write the administrative interface to let admins define items to be sold.

Posted: Wed Oct 22, 2008 6:13 am

Raven,

I am definitely all for it. Just about every nuke site I have ever had needs some way to collect donations at its simplest. Why not just incorporate into the core of RavenNuke and so all the development tools (i.e., Mantis, SVN, etc.) are already ready-made to go. Wink

I am not sure I would ever need something as feature-rich as a formal shopping cart. Most folks just need a simple way to collect payments and possibly to sell subscriptions and/or assignments to specific NSN Groups for elevated privileges. But, if it could start simple, stay simple, but then have a more feature-rich piece as an add-on, that could be a nice road map.

Posted: Wed Oct 22, 2008 2:48 pm

montego wrote:

Raven,

I am definitely all for it. Just about every nuke site I have ever had needs some way to collect donations at its simplest. Why not just incorporate into the core of RavenNuke and so all the development tools (i.e., Mantis, SVN, etc.) are already ready-made to go. Wink

Sounds good to me!

Posted: Wed Oct 22, 2008 3:03 pm

Quote:

But, if it could start simple, stay simple, but then have a more feature-rich piece as an add-on, that could be a nice road map.

I agree in principle but my experience has been that it's difficult to do it that way. If you are only supporting one currency and you are only selling through Paypal and if you are only having a few items to sell it calls for one type of design. You might not even need an administrative component.

On the other hand if you plan to support multiple currencies and if you are going to be adding and changing items and their prices, descriptions etc. and if you want images for them then you need a more complicated design. The cool thing about Zencart is that it builds the forms AND their validation automatically based on an admin's input on screens in the administrative interface. There is no programming at all involved to build a form and to have it processed through Paypal and/or to add multiple items to sell, all on separate forms. In fact we could probably adopt similar technology throughout Nuke.

I already posted a link to see how zencart appears to a user. If anyone wants to take a look at the admin interface and even take a hack at listing items for sale to see how it works, just PM me and I'll send you a link. I just have it out on a test system right now and it's not hooked up to the real Paypal so no harm can be done.

Finally while it may seem like I am an unabashed zencart proponent that's not true. I just think it's something that should be looked at in the early stages of this project. I realize that enhancing Treasury may be the way to go and I am busy trying to generalize my own Paypal routines on a couple of my sites.

Posted: Wed Oct 22, 2008 6:16 pm

fkelly, the thing is, I see these are two separate needs. For example, I have no intention / need of ever really selling anything. I have no goods to sell, or events, etc. What I do have a real need for, and I believe many people do, is the simple ability to collect donations.

Since we have subscriptions and groups within *nuke, there needs to be a simple, integrated way to "sell" or collect "donations" for subscriptions and group access. Probably the only thing else that *nuke has to "sell", is Advertising.

So, I guess what I am really saying is that there are features / modules within *nuke already which just "scream" having a simple, integration way to collect payment towards the enablement of these features / modules.

Anything outside of these core functions, I consider as more traditional eCommerce. For that, I think something more like ZenCart is more appropriate as you have far more flexibility to create product categories, products to sell, manage the search / product presentment, sale, etc. These are not your typical *nuke site needs IMO.

But, that is what makes this team so much fun to work with. So many varied viewpoints, and in the end, we decide collectively, for the most part, the functional roadmap.

Posted: Wed Oct 22, 2008 6:54 pm

More succinctly put "The needs of the many outweigh the needs of the few - or the one" Wink

Posted: Fri Oct 24, 2008 12:49 am

I just wanted to add that I would prefer whatever system is eventually included into a core app that it should not use the IPN system.
Paypals IPN API can and does change
Some folks might already be using it for something else - last time I looked you could only configure IPN for one website.

Posted: Fri Oct 24, 2008 7:27 am

IPN is troublesome and difficult to configure, especially on the Paypal end of things where you need to set up Sandbox accounts (one for the business and one for the "tester") under a general developer account. The process of doing that is convoluted and arcane to say the least. Even with some experience using Paypal and IPN for a couple of years I am dealing with trying to figure out why it is sending back an INVALID code through IPN when a transaction seems to complete successfully.

I don't know what the alternative are however and we need to be careful of jumping from the arms of the devil we know into the one we don't.

Once concern that I've had in responding to Paypal related posts in these forums is that folks seem to expect the software (for instance the Nukescripts code or Treasury) to work without any effort on their part. I tell them that if you want to support this stuff you need to sign up for a Paypal developer account and figure out how to use the sandbox and be prepared to look into the extensive Paypal forums and documentation for solutions. And this goes to your point that the Paypal code does change.

I have seen days at a time when the sandbox simply wasn't working. So you'd be testing and tweaking your code and getting no results and banging on the keyboard and all of a sudden the Paypal Support people would say "oops, for some reason not to be explained the Sandbox has been down the last 3 days, or has been returning results erratically."

And I guess what I'm getting at is that if we want to provide a Treasury module we need to be prepared to support it and to have a patch mechanism in place in case Paypal changes something on their end. It is not like a core RN module that can more or less operate independently of the outside world.

Also, all the configuration parameters (return url, livefeed or not, the paypal email address it sends confirmations to, items you are selling, and several others) need to be easily visible (not buried deep in the code) and easily changeable. Probably we should also build in a debug or diagnostic mode too that can be easily turned on or off. And yeah, that $ppemail is one basic reason that you can only use one instance of the software for one web site. Paypal is going to send a summary of every transaction to that email address and there can only be one per site.

Posted: Fri Oct 24, 2008 8:31 am

Guardian2003 wrote:

I just wanted to add that I would prefer whatever system is eventually included into a core app that it should not use the IPN system.
Paypals IPN API can and does change
Some folks might already be using it for something else - last time I looked you could only configure IPN for one website.

I would disagree Smile

. IPN is an absolute must have. The very few API changes have never impacted me but for the better. I have used IPN for 5 years and never had any issues. The way to handle multiple sites or just about multiple anything with IPN is to just use one IPN url that is a Controller. Then, that script determines the actual routing. For instance, in your Paypal IPN setup, you point Instant Payment Notification (IPN) URL to an ipnController script. For obvious reasons I can't/won't reveal all my code Wink

but in the controller script you examine various variables sent from Paypal and determine what to do. For instance, you could

Code:

switch ("$item_name") {


   case ('subscr_signup'):


      include ('ipnScripts/subscrSignup.php');


      break;


   case ('subscr_payment'):


      include ('ipnScripts/subscrPayment.php');


      break;


   case ('subscr_eot'):


      include ('ipnScripts/subscrEot.php');


      break;


   case ('subscr_cancel'):


      include ('ipnScripts/subscrCancel.php');


      break;


   case ('subscr_failed'):


      include ('ipnScripts/subscrFailed.php');


      break;


   case ('donation'):


      include ('ipnScripts/donation.php');


      break;


   case ('refund'):


      include ('ipnScripts/refund.php');


      break;


   case ('send_money'):


      include ('ipnScripts/sendMoney.php');


      break;


   default:


      include ('ipnppd.php');


      break;


}

You can just as easily check for a domain. I have found IPN to be completely reliable and very extensible/configurable. Your mileage may vary due to mental stability/configuration killing me

Posted: Fri Oct 24, 2008 8:37 am

Frank wrote:

Paypal is going to send a summary of every transaction to that email address and there can only be one per site.

Again, not a problem Smile

. You have one Paypal controllEmailAddress. For instance, I might use ravenwebservices_pp@somewhere.tld.

Involved Joined: Apr 06, 2008 Posts: 484

fkelly wrote:

IPN is troublesome and difficult to configure, especially on the Paypal end of things where you need to set up Sandbox accounts (one for the business and one for the "tester") under a general developer account. The process of doing that is convoluted and arcane to say the least. Even with some experience using Paypal and IPN for a couple of years I am dealing with trying to figure out why it is sending back an INVALID code through IPN when a transaction seems to complete successfully.

you dont need all that.

You just need Instant Payment Notification (IPN) which requires a premium account.The premium account is free so you just upgrade.Once that is done it is as easy as,

1. activating IPN and inputting your notification url
2. Turn on auto reporting and set the url.
3. turn on payment data transfer
4. turn off block non-encrypted payment
5. turn on paypal account optional

and your done

Posted: Sat Oct 25, 2008 4:24 am

fkelly - it has been a really long time since I used IPN but I think you might get an invalid transaction if you are trying to pay yourself.

Posted: Sat Oct 25, 2008 4:58 am

The only way to pay yourself is to have 2 accounts. I have a personal and a Premium/Business account that I use when I want/need to test.