In trying to implement several advanced features and callbacks, sifting through hundreds of classes and files in their SDK, I decided that I needed to write my own class. Starting from scratch, I came up with a bare-bones class integrating with the Express checkout API. I completely dumped Paypal’s SOAP implementation in favor of the much simpler NVP (name-value-pair) integration. I don’t see any reason to stick with SOAP on such a simple API. I did include the more advanced features like adding products and shipping (this was probably in Paypal’s, but I couldn’t find it), and shipping and tax callbacks, through the express checkout API. After about 8 hours of coding and testing, I had a working integration that consisted of a handful of files, and about 400 overly spaced lines of code.

I went back and parsed out Paypal’s SDK to see just how large this monster was, and it is over 190,000 lines of code, and just under 1000 individual files.

I had looked at 2 symfony plugins the PaypalDirect and PrestsPaypal plugin, and the both use a lightly stripped version of Paypal’s SDK.

So the point of this is, don’t trust some plugin or package, or script from me, from Paypal, from Symfony, or any provider unless you know it is the best or at least a reasonable way to accomplish your task. Even if the code is cached, the overhead on running 190,000 lines of code every time a customer checks out of your website is simply ridiculous when you can accomplish the same thing with a few hundred. Additionally if you take into account the potential for errors, memory leaks, and security problems with 190,000 lines of code vs. 400, there’s really no comparison.

Now there are times when a huge SOAP integration would be appropriate, but I can’t see how this could possibly be one of those. I also think that if a good programmer started from scratch rather than using Paypal’s bloated code, they could significantly reduce the size of their integration. It’s absolutely baffling trying to debug or get information on a PHP class or method, when there’s 1000 files that you need to hop through to find the piece of code you’re looking for.

To start off with, the chart image must be delivered from a secure connection. Google doesn't allow this plain and simple, so we need to figure out how to host it from our own site. We accomplish this by fetching the image from google using the standard API, writing it to a file, and then calling it on our own script. We basically make a image handling proxy.

Let's take a simple google chart to experiment with.

Next we need to make a function to fetch and save the google chart locally. It will check the chart against the local copy and save it if the chart doesn't exist, or the image has changed. This way we aren't re-writing the same chart on every request, but if the chart changes, it will be updated appropriately.

Lastly we tie it all together so that it is usable in our application. Im using this within a class, but this could just be used as a function as well. Your image directory will need to be writable for this to work.

You'll need to implement your own error handling, and adjust this to meet the paths and specifics of your server, but the image can now be called from:
<img src="/images/charts/some_chart_image.png" alt="" />

If you need help creating your base chart image, this tool is a great place to start.

Having needed a way to force a SSL connection for certain pages, I modified a few scripts that I found online, and created a very simple filter to handle this. This was inspired by this script, and the unacceptably poor example in the Symfony 1.2 book.

To start off with, we need to modify our app.yml file to specify what modules and/or actions need to be secure. Leave the action completely blank if you want the entire module secure. Also change ignore_non_secure to true if you don't care if non specified pages are server over a ssl connection. Basically, from the app.yml below, setting this to false, will redirect any module/action to the non-secure version if it is not specifically defined under secure_actions. Setting it to true will allow a user to request any page over https, even if it is not listed in app.yml. Let me know if this is confusing in any way.

Next we add this filter. Save this under MyProject/apps/MyApp/lib/sfSslFilter.php

Finally, add to the MyProject/apps/MyApp/config/filters.yml file:

Clear the cache (symfony cc), and there you have it. Let me know if you have a better or different way of dealing with this on a per-module or per-action basis. Hopefully sfSslRequirementPlugin will get ported to work with Symfony 1.2, as the method above will not alter routes on your application.

Additionally, I specifically used 301 redirects to make this more search engine friendly, in case Google or another bot gets on a ssl page. This will help prevent getting duplicate pages indexed due to http and https versions of the same page.

Unfortunately Modalbox uses a more recent version of Prototype, and there is no track on when we can expect Symfony to upgrade it's included version of Prototype. However, this doesn't prevent us from using Modalbox in a Symfony development. We do have to trick symfony into using the correct Propel version for us. Once Symfony updates their Prototype version, using modalbox should become substantially easier.

To start out we need to download modalbox, and upload the newer prototype, scriptaculous, and modalbox.js scripts to our web/js directory.

We need to make sure that Symfony includes its own prototype version, or Symfony's Javascript helper will break. We do this by specifying it first with: %SF_PROTOTYPE_WEB_DIR%/js/prototype. We can now include the newer prototype version (example below). You can also add these specifically to actions with "$this->getResponse()->addJavascript" if you don't need modalbox for your entire site.

Next we need to make the script that the modalbox will call via an ajax request. For this example we will make a simple comment form.

Next we can add the modalbox popup script to a link on our site.

And that's it. You can of course make this as complicated as you want. This example wouldn't make a lot of sense, but should give a good idea of the capabilities of using modalbox and Symfony.

Here's a screen-shot of an app I'm developing.

As long as you continue to make ajax requests via form_remote, or remote_function tags, there's no limit to how complex your dialog box can be.

Symfony when using Propel does not have native support for using NOT IN queries in reference to another tables. You can use NOT IN and an array, but cannot use NOT IN with reference to another table.

Here's how to use NOT IN other_table with Propel and Symfony. Let's pretend we need to run this query.

Using Propel and Criteria, there is no native way of running this query. But, with the Criteria::CUSTOM modifier, we can force this query through propel.

It's actually very easy.

You can add whatever other Criteria to the query as well. So far this is the only reliable way to run these sort of queries that I've found.

If you want to keep this more true to the Propel ORM, you would use something like this: