All the key elements of Seamless Donations 4.0 now work, and work together (mostly). Each of the core elements has been written and tested. These include the new forms engine, the new admin UI engine, the new custom post types, and the PayPal interface that takes data from the new form engine, processes payments, and records that data into the new custom post types.
This also includes the legacy system, which is an entire working legacy system so people who auto-update will have a working donations system after the updates go through. And, on top of that, it also includes the legacy update system, which moves all the legacy data into the new custom post type format, updates the UI, and brings things up to 4.0-ready — all by clicking one button.
Finally, it includes the new shortcode, used to embed the new form on a Web page. The old shortcode will work until the 4.0 upgrade button is clicked. Additionally, there is error-processing and warning code built in, so the shortcodes won’t just break if misused. Instead, a helpful guidance alert will be displayed explaining what needs to be done to change things and make them work with the upgrade.
The big remaining problem is that kicking off PayPal’s interface is inconsistent. Sometimes, when clicking “Submit” it will run. Other times it won’t. This seems to be the result of a vestige of the 3.3-vintage implementation, which actually built two forms on the page: one which contains the user donation interface and one which was hidden.
The user donation form displayed all the controls to the user, including the submit buttons. It had an onsubmit parameter to the form tag that would both process form validation in JavaScript and gather the data from the form for submission to PayPal, populating the fields of the hidden form. The second form consisted of all hidden fields, and had a form action that did the actual redirection into PayPal’s processing environment.
Sadly, I chose to emulate this approach in 4.0 for compatibility sake and now it’s biting me on the ass. One form has validation and the buttons while another form has the action and the data. This mix is just not working reliably. Quite often, clicking the buttons in the user-visible form changes state enough so the invisible form doesn’t redirect off to PayPal.
This can’t be allowed to remain this way. My next step will be to carefully manage the forms engine so PHP processing and JavaScript validation can co-exist, and so that only one form is necessary for user input and it doesn’t have to be so tightly integrated into the payment processing part of the system. Alternatively, if separating out the payment gateway looks like it will take far too long, I may look at just integrating in the PayPal form fields into the main form and seeing if that can meet processing needs, at least until a subsequent point-release upgrade.
So what does that mean for development progress? If it’s possible to clean up form submission without writing an entirely new gateway system, the plugin should be relatively close to a public beta. All the other elements seem to work reliably, both in legacy mode and new 4.0 mode. If, on the other hand, a whole new gateway interface needs to be written, add at least a few weeks to the process.
Stay tuned.
