I recently blogged about the Google Analytics XML API being opened for report data and an object-oriented PHP API interface I was working on.
The second stage of development for the GAPI has been finished and now the interface is able to convert the XML into native PHP objects, with ‘get’ methods to retrieve the data.
Google Analytics recently (last week) opened full access to its powerful analytics data over an XML based API.
Official examples are provided in Java and Javascript, and the only PHP examples currently in existance are some pretty boring line-by-line non-object oriented examples. Here is an object oriented Google Analytics API PHP5 class ready for use in your awesome symfony, zend, cakePHP etc application.
Get the power of Google Analytics into your app – easily.
Since Symfony 1.1 – the forms have been handled by a more-MVC style form framework. Moving from Symfony 1.0 forms, where you made your forms in HTML and then used YML for the validation, this was a big step.
Here are my findings, and some tips to make using the new Symfony forms a bit less painful.
Running symfony on a web host that is running Plesk should be something that is easy, and it is, but with a bit of knowledge.
Most webhosts will run either Plesk or CPanel for managing resources on the server – and when putting a symfony website live on a shared host you are likely to run into this problem.
It is more important than ever to store hash values in your database instead of raw passwords.
The easiest method of storing passwords is to store plain-text passwords directly into the database. This has the advantage of allowing forgotten passwords to be sent out to the user, but it is a serious security flaw. If the application or database is compromised, hackers have access to a great deal of user passwords. This is a big problem when one third of users will use only a single password for all their accounts.
When most people think of getting a random row from a table, they will probably think of something like:
SELECT * FROM products ORDER BY rand() LIMIT 1
This is fine for a table with a small number of rows. This will cause a high server load when working with a more serious table – something >10,000 rows will start causing some real problems.
Read about ‘Getting random rows, or why order by rand() is bad for your health’ »
The ACMA took an extraordinary step today in issuing an “interim link-deletion notice” to Bulletproof Networks, the server hardware provider for Whirlpool, where a user had posted a link to an ‘objectionable website’. Failure to comply within 24hours was to be met with a $11k fine per day – payable by Bulletproof.
The day has come that I should join the ranks of the vocal minority who feel the need to spread their know-it-all egos onto the interweb.
Well no not really.