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.

PHP Snippets:

MySQL Snippets:

This is a simple example using sleep() to demonstrate the output.

The script outputs:

Time 1: 1.001833 seconds.
Time 2: 2.001427 seconds.
Time 3: 3.001124 seconds.
Time 4: 1.001720 seconds.
Total time: 7.006104 seconds.

It's a good idea to comment each time you record a microtime so that you know which section of script took that amount of time.

This can be used to generate random passwords or keys or just about anything else that needs a random string. You can also throw this directly into a class and use it as a static method.

Examples:

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:

Here's a quick script I created using linux's wget to run another process in the background. You could use this to automatically upload something to another server, or just about anything that needs to happen after a user action.

Note: you must have exec enabled for this to work. This is a security risk, so make sure you know the potential damage that can be done by enabling exec, and by the script that you are running. Make absolutely sure to sanitize any input being transferred to the executed script.

In my case, I needed to initiate a file upload to a remote server after a certain action was taken. Because of the nature of the upload, it would have taken about 30 seconds before displaying any response to my user, which is an unacceptable delay.

First, make the script that needs to run in the background.

Next, make the script that executes the background script.

There you have it. This will run a script in the background (any web page that you specify). I do not use a local path to the file, because it will often break and can pose additional security risks. Using the above code, the server can only execute wget, and the actual page is parsed just like any other page on your website.

Again, make sure you understand the potential problems enabling exec can cause. There are also other ways of doing this such as running php from the exec command (path/to/php my_script). These can pose much greater security risks if they are not properly coded.

Lastly, this should be run on user or administrator initiated event, and not on events such as page views. This could spawn a huge number of processes if it is ever allowed to run based on every page view or something similar.