Customize webhook alert on enable to use UF relative path

updated stripe to v2, make compatiable with webform_civicrm, code cleanu...

updated stripe to v2, make compatiable with webform_civicrm, code cleanup / generalization to work with civicrm + webform, prevent sensitive data transfer across the server to ensure PCI compliance, also notice and indentation fixes

Cache instantiated jQuery Form object when using multiple times

Patch - Add support for offline events/memberships

Add hook path for Wordpress to Readme

The buildform hook only supported offline contributions but should also work on offline event registrations and offline memberships

Add patch for CiviCRM 4.5 forms

Direct child selector was failing because of the way forms are written in 4.5. Removing the direct child selector fixed the issue. Also added condition to check for jQuery dialog forms as well.

Fix for pay later bug: https://github.com/drastik/civicrm_stripe/issues/5

fix bad-query: payment_processor_type is not a char-field. add join to g...

Clarify readme.

Strict warning: Declaration of CRM_Core_Payment_Stripe::singleton() should be
compatible with & CRM_Core_Payment::singleton().

And:
Strict warning: Accessing static property CRM_Core_Payment_Stripe::$_mode as
non static in CRM_Core_Payment_Stripe->__construct().

Don't use livemode parameter.

Log all stripe errors.

Usually when we setup staging and test sites, we set the Stripe payment
processor keys to use the test keys for both test payments and "live"
payments. This lets us test things more realisticly. Unfortunately, because
we are doing a "live" test, but using the Stripe test keys, the Stripe API
fails with "Received unknown parameter: livemode".

I think the CiviCRM Stripe payment processor should behave like all the other
payment processors and work as expected if you use the test API keys as the
"live" keys.

Usually when we setup staging and test sites, we set the Stripe payment
processor keys to use the test keys for both test payments and "live"
payments. This lets us test things more realisticly. This caused a problem
with the Stripe extension where it was it was sending 'livemode' => true
along with the 'create_plan' API call. This was causing the API call to fail
with "Received unknown parameter: livemode", but because stripeCatchErrors
ignores most errors the code was actually failing later on.

To make problems with the Stripe API calls easier to debug in the future,
we added some code to log all the exceptions when making Stripe calls and
make sure that Civi crashes when these calls fail. That way the user knows
that something went wrong with his transaction and he can inform the website
owner.

Sometimes, though we do expect an error from Stripe (like in the case where a
subscription plan already exists, but it isn't in the local
civicrm_stripe_subscriptions table). For that I've added an ignores parameter
to the stripCatchErrors method that can be used to tell it to ignore very
specific error messages, but still crash if we get an unexpected error.

BillingBlock.tpl is gone!
JS For Stripe is now injected on appropriate pages.

Known fixes
-----------
GitHub Issue: https://github.com/drastik/civicrm_stripe/issues/28
Ability to submit backend/offline contributions for a contact w/ Stripe.

Previous fixes
--------------
The last commit also fixed GitHub Issue:
https://github.com/drastik/civicrm_stripe/issues/9
USD forced on recurring plans.

Fixed issue where you might see 'no such customer'.
---DO NOT UPDATE LIVE SITES YET---
Changes to plan names to utilize Stripe's new ability to do plan frequency intervals.

No $charge->fee field returned by Stripe

Stripe was not returning the fee with recurring payments, so this was causing 500 error.

-Fix amount issue from github: https://github.com/drastik/civicrm_stripe/issues/18
-Fix BillingBlock.tpl issues (cvv image, credit cards image)
-New error message report if there was a silent error (can be found in stripe.com account logs)