After some trial and error I discovered a way to properly change the encoding before saving it in the DB.

A simplified version of what I did:

 $url = 'http://www.smooka.com/blog/';
 $html = file_get_contents($url);

 //Change encoding to UTF-8 from ISO-8859-1
 $html = iconv('UTF-8', 'ISO-8859-1//TRANSLIT', $html);

This partially solved my problem. But for some reason single quotes where displayed with a question mark symbol. After reading documentation, forums, etc.. I discovered that I needed to translate ASCII characters.

 $dom = new Zend_Dom_Query($html);
 $results = $dom->query('div p');

 foreach ($results as $result)
 {
    $line = $result->nodeValue;
    $line = iconv('UTF-8', 'ASCII//TRANSLIT', $line);
 }

Hope this saves you some time, as I was not able to find a complete solution on the web so I had to piece everything together.

//make sure your time is set
date_default_timezone_set('America/New_York');

$datetime = '2004-02-12T15:19:21+00:00';

//convert the given datetime string to time
$newDatetime = strtotime($datetime);

//re-contruct to format
$newDatetime = date('Y-m-d H:i:s', newDatetime);

It’s so obvious, but I only wished, I knew this before trying all sort of crazy stuff.

If you want to unit test an action in a controller that checks the request to see if is an XML HTTP Request using the isXmlHttpRequest() method provided by the Zend Framework, then you will definitely run into a problem.

isXmlHttpRequest() pretty much checks to see if the $_SERVER['HTTP_X_REQUESTED_WITH'] is set with ‘XMLHttpRequest’, if not, then returns FALSE. I thought that by setting the server variable with XMLHttpRequest directly will allow me to bypass the check.

function myAjaxTestAction()
{
      $_SERVER['HTTP_X_REQUESTED_WITH'] = 'XMLHttpRequest';

      //then do your ajax tests here
}

This solution seemed like it was going to work, but it turns out that isXmlHttpRequest() makes a call to getHeader() like this:

public function isXmlHttpRequest()
{
        return ($this->getHeader('X_REQUESTED_WITH') == 'XMLHttpRequest');
}

What I didn’t know is that when you are doing unit tests the framework extends the HTTP class and changes the getHeader() to only use headers set using the setHeader or setHeaders methods.
After a couple of minutes tracing over the calls being made. I discovered that the fix was pretty simple, set our headers doing the following in your test case:

function myAjaxTestAction()
{
      $this->request->setHeader('X_REQUESTED_WITH');

      //then do your ajax tests here
}

This will fake an AJAX request and return the expected result.

I hope this article helps many of you since I spent many hours trying to decipher why setting ‘XMLHttpRequest’ to the $_SERVER did not work as I expected.

After reading the reference guide on Zend_Translate I decided that we were going to use “gettext” as our translation adapter. PHP has support for gettext right our of the box, and with the Zend_Translate it’s easy to change adapters, if you decide that you want to use a different adapter.

Assuming that you already have the latest version of Zend Framework (1.10.*) installed in your server, I’m going to explain and guide you guys on how I got it all working.

First you need to get a tool that we will use to parse your project files to create the translation dictionaries. I’m using PoEdit which is free and supports multiple platforms.

Now let’s put some code down in your index.phtml file of you application. This one should be located in /yourapp/application/views/scripts/index/
If it’s not there, then just create one, but make sure you have to corresponding controller and action.
Inside of this file we are going to put the following:

<?php
$t = new Zend_Translate(
	'gettext',  //the adapter
	APPLICATION_PATH.'/translation', //where the lang files will be stored
	'auto',  //set to auto include .mo files
	array('scan' => Zend_Translate::LOCALE_FILENAME) //set to scan lang files
);

echo $t->_("This is my first translation")."<br/>";
?>

Before this piece of code works, we need to generate our translation files, else it will throw an error stating that the application can’t find the corresponding language files.

We need to create a new folder in your application folder. I’m calling it lang, but you can call it anything you want. This folder will be used to store your language files. So you should have something like “/yourapp/application/lang”.

After this, you need to open up PoEdit:

1. Go to File->Catalog Manager

2. Click on the “Create new translations project” icon

3. Give your project a name

4. Select the directory to store your translation files (“/yourapp/application/lang”) and hit OK

With a newly crated project, we can now generate our language file.
To do this,  close the Catalog Manager window

1. Go to File->New Catalog

2. Give it a project Name and/or version and be sure to feel in the appropriate information. Be sure to select Charset  ”utf-8″

3. Now, click on the paths tab. Here you will have to add all the dir paths that point to the files that you want to parse for translation. (/yourapp/application/views/scripts/index/index.phtml)

4. Finally, click on the Keywords tab, and make sure you include the keyword the parser will use to identify the text that needs translation. In our example we will put an underscore “_”  since in our code we have echo $t->_(“This is my first translation”);

5. Hit OK and make sure that you save the file with a name such as mylang_en.po. The _en is crucial, since Zend_Translate will scan the appropriate language file and use this naming convention to load the appropriate file

Since by default the PoEdit PHP parser handles files with .php extension. We need to modify the preferences so that it allows other types, such as .phtml files.
To do this, go to Edit->Preferences->Parsers  When you get to parsers select PHP and then click on the EDIT button. In the parser setup window we need to add *.phtml extension to the “List of extensions” field in the Language section, separated by semicolons. The field should be something like this: *.php;*.phtml
Then, in the Invocation section, you need to add  -L php to the parser command. This should look like this  xgettext --force-po -o %o %C %K %F -L php

Once you have completed this, a pop up screen will show the progress of the catalog update and then list you all the parsed strings. Hit OK and then you will be in the translation view. Just select the string you would like to translate save and you are good to go.

Once you’ve completed the following steps just copy the .po file and create additional one’s for the languages you want to do translation. Remember the naming convention discussed on the steps above.

In your code to switch languages, you need to put the following line $t->setLocale('es'); This for example will switch the locale to Spanish and will try to load a file with “_es”

<?php
$t = new Zend_Translate('gettext', APPLICATION_PATH.'/translation', 'auto', array('scan' => Zend_Translate::LOCALE_FILENAME));

echo $t->_("This is my first translation")."<br/>";

//change locale to spanish
$t->setLocale('es');

echo $t->_("This is my Second translation")."<br/>";
?>

When developing an application there are some important factors that you have to pay close attention to avoid problems in the future. I think one of the most important is logging information on how your application is working and when it fails.

Must of us like to log only big exceptions and fatal errors, but the truth is, that when you are in the development process it’s very important to keep track of not just errors, but important information of when something gets executed. As a web developer one of the most important tools to have is FireBug. If you didn’t know, FireBug has an API that you can use to send console messages for logging purposes, when debugging JavaScript. But, did you know you can use FireBug to debug your php applications?

Through Wildfire, a project that was created to help developers have a standard way for sending messages between different programming languages and scripts. The Zend Framework is now able to communicate to the Firebug console in order to display logging messages injected by PHP.

Using this component is pretty straight forward if you are using Zend_Controller_Front (MVC) with zend Framework.

Place this in your bootstrap file before dispatching your front controller

$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);

Then whenever you want to log something to Firebug just use it in your model, view, or controller like this.

$logger->log('This is an INFORMATIONAL log message!', Zend_Log::INFO);
$logger->log('This is a WARNING log message!', Zend_Log::WARN);
$logger->log('This is an ERROR log message!', Zend_Log::ERROR);

If you notice in the example above, you can specify the type of message you want to log (INFO, WARN, etc..). This is helpful when you want to clearly identify what type of message you are viewing since it will apply a special formatting and in some instances provide more information.

If you want to use the Zend_Log_Writer_Firebug as a stand alone here is the sample code you can use:

//Instantiate the Firebug Writer
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);

//start the wildfire component
$request = new Zend_Controller_Request_Http();
$response = new Zend_Controller_Response_Http();
$channel = Zend_Wildfire_Channel_HttpHeaders::getInstance();
$channel->setRequest($request);
$channel->setResponse($response);

// Start output buffering
ob_start();

// Now you can make calls to the logger

$logger->log('This is a log message!', Zend_Log::INFO);

// Flush log data to browser
$channel->flush();
$response->sendHeaders();

If you don’t use ZendFramework there is another alternative to php developers. FirePhp, will also enable you to send log messages to Firebug by using php method calls. Be sure to check FirePhp website to get more information.

So remember that this is just one easy and great way to debug your projects, there are many other tools and methods you can incorporate into your projects. If you want to share other ways or simply just want to ask a question regarding this post, feel free to leave a comment.

According to Joe Hewitt, developer of the facebook app. Version 3.0 of the facebook application has already been submitted to apple, and it’s waiting for approval.

Here is what’s new on the version of the app will contain:

• New and improved Home screen that allows you to create shortcuts to your favorite friends and Pages
• Events: the new events screen will allow you to see your upcoming Events and RSVP
• Pages: support for pages was added so you can easily see and become fan of Pages and if you are a Page admin you can now post updates and photos to your pages.
• Birthdays: see your friends’ b-days.
• Notes: now you can write Notes and read your friends’ Notes
• Complete photo management (create albums, delete albums, delete photos, delete photo tags, Upload photos to any album)
• Upload videos from an iPhone 3GS
• Change your Profile Picture
• Zoom into photos
• Like functionality was added so you can like posts and photos
• See the same News Feed as the Facebook website
• Visit links in a built-in web browser
• See all of your friends’ friends and Pages
• See mutual friends
• Easily search for people and Pages
• Make friend requests
• Quickly call or text your friends
• Friends sorted by first or last name according to your settings
• Chat friends sorted alphabeticaly

There are a few missing functionality that we have been waiting for. But Joe Hewitt already mentioned in his twitter account that he already started development of version 3.1 of the facebook app and it will include “Push Notifications” and “Landscape Mode” and I guess he will throw in a few more small features.

Now with version 3.0 of the facebook application Will we ever need to go into the full facebook.com website? I guess that depends on how you use facebook, but, in my opinion I will be visiting the site less.

Update: According to the developer of the application the update it’s live on the iPhone App Store. So go grab it and let us know what you think.

Working now on some iGoogle like dashboard for the system I’m developing.

I was trying some stuff out with CURL and was having a hard time to maintain my current session when making a curl request to another page. I needed to stay authenticated in order to retrieve my widget.

Here is my initial code:

$strCookie = 'PHPSESSID=' . $_COOKIE['PHPSESSID'] . '; path=/';
$ch = curl_init($rssFeedLink);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt( $ch, CURLOPT_COOKIE, $strCookie );
$response = curl_exec($ch);
curl_close($ch);

The problem with that piece of code is that it was generating a new session id instead of sending my current session.

The solution? Put session_write_close() before you make the CURL request.

$strCookie = 'PHPSESSID=' . $_COOKIE['PHPSESSID'] . '; path=/';

session_write_close();

$ch = curl_init($rssFeedLink);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt( $ch, CURLOPT_COOKIE, $strCookie );
$response = curl_exec($ch);
curl_close($ch);

What does session_write_close() do? It, ends the current session and store session data. Apparently, PHP does not like when multiple scripts play around with the session, so, it locks it. Putting session_write_close makes sure that your current session is stored so you can retrieve it and use it.

This little issue had my head spinning for a few hours, so, I hope this article helps you.

$rssFeedLink = 'http://www.smooka.com/blog/';
$cacheId = 'rss_feed';

$frontendOptions = array(
		   	'lifetime' => 1800, // cache lifetime of 30 mins
		   	'automatic_serialization' => true);

$backendOptions = array(
		    	// Directory where to put the cache files
		    	'cache_dir' => '/cache/'
			);

// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core','File', $frontendOptions, $backendOptions);

if (!$rss = $cache->load($cacheId)) {
	try {
		$rss = Zend_Feed::import($rssFeedLink);
	} catch (Exception $e) {
		$feedError = true;
	}

	//check to see if it did not fail
	if (!$feedError && is_object($rss))
	{
		$cache->save($rss, $cacheId);
	}
}

//assuming that everything went right while fetching the feed
foreach ($rss as $item) {
	$channel['items'][] = array(
		'title'       => $item->title(),
		'link'        => $item->link(),
		'description' => $item->description()
	);
}

While iterating through the feed, the script would output the following message “Warning: Invalid argument supplied for foreach()”, under, “Zend/Feed/Element.php on line 322″ on an empty cache.

It appears that Zend_Feed and Zend_Cache do not get along, I’m pretty sure it’s a bug since it looks like Zend_Feed_Rss is sent to sleep by the $cache->save() call and it’s not waking up automatically. The solution that I found it’s pretty straight forward. Just modify the following piece of code.

if (!$feedError && is_object($rss))
{
	$cache->save($rss, $cacheId);
	//ADD a wakeup call to the RSS object
	$rss->__wakeup();
}

That should do the trick!

After I fixed the issue, I went back to the drawing board and decided that it was more efficient to cache the actual HTML output, instead of the returned object by Zend_Feed. That seems to work just fine, since the call to $cache->save() is done after the iteration of the feed items. That fixes the issue and at the same time you are eliminating the need to iterate and re-build the HTML every time the page is loaded.

Hope this information helps you, and if you have any questions or comments be sure to post them here.