December just started, and with it its usual christmas spirit, Santa Claus, happy children and.... the symfony advent calendar!

This year the symfony advent calendar is a collection of articles written by different symfony experts:

http://www.symfony-project.org/blog/2009/12/01/one-more-thing

and is already available as a book on Amazon!

http://www.amazon.com/exec/obidos/ASIN/2918390178

I had the chance to contribute and write an article on developing for Facebook with symfony. This was the perfect occasion to finally sit down and write 15 pages on the experience I gathered on this specific subject. I had already collected it in the sfFacebookConnect plugin but it was lacking documentation. Well here it is finally! At least on Amazon and in a few days as part of the new symfony advent calendar.

Enjoy and do not hesitate to make a critical feedback, the article will be included with the plugin and can still evolve a lot!

It is for the moment VERY beta. It is used in two projects, http://www.allomatch.com which is a symfony 1.0/propel project and another project on symfony 1.2/doctrine. It is therefore compatible with both Doctrine and Propel. However some issues remain concerning 1.0 and 1.2 versions regarding some options, the tasks for example.

For the installation, the README is a good start but FAR from complete. I invite you to browse through the code to understand the logic and comment on this post if you have any question regarding installation. This will force me to improve the README.

I intend to improve the documentation in the very near future, so if you are not in a hurry, please wait. However I have already received dozens of mails concerning the current status, so I release it for those who need to start a project using Facebook Connect right now.

Here is the link to the plugin:

http://www.symfony-project.org/plugins/sfFacebookConnectPlugin

And here the presentation made at the sflive conference:

http://www.symfony-live.com/pdf/sflive09fr/theodo-symfony-facebook.pdf

It all started because I was amazed by the success of the Phoogle library on the Internet despite its limited number of functionalities. And since almost all my projects involved a Google Map I wanted to create a plugin containing all the core functionalities I always reuse. Now I am happy to see the popularity of the plugin and am looking forward further possible developments that will continue in the spirit of including as many core functionalities of Google Maps-based application in the plugin.

New functionalities for the moment include :

• More precise Mercator projections to convert GPS coordinates into Google Pixel coordinates and back GMapCoord::fromPixToLat, GMapCoord::fromLatToPix, etc.
• Added the GMapBounds::getBoundsContainingMarkers(...) function
• Added the GMap::centerAndZoomOnMarkers() function which enables to guess zoom and center of the map to fit the markers. Center is easy to guess. Zoom uses width and height of smallest bound, pixel width and height of the map and Mercator projection
• Added tomr's contribution: it is now possible to add multiple controls to the map
• Added the GMapCoord::distance($coord1, $coord2) function which gives an estimation of the distance between two coordinates
• Added the very useful function $gMap-> getBoundsFromCenterAndZoom(...) which enables one to calculate server-side the bounds corresponding to specific center coordinates, zoom, and map size. This is the equivalent of the client-side map.setCenter(...,...);map.setZoom(...);map.getBounds(); It uses the Mercator projection formulas as used by the Google Maps
• A new function $gMapMarker->isInsideBounds($bounds)
• A lot of unit tests
• And two new samples

Please, feel free to suggest what you consider typical core functionalities of your Google Maps-based applications.

A very simple version has been available for a few months but I have now finally released the 1.0 version,  with the following new features :

- it is now sf1.2 compatible straight out of the box
- it has some unit tests
- the GMap constructor now takes an array of parameters, which is much more flexible and also more in the symfony coding spirit (Warning : the modification of the GMap constructor should break your application if you used the prior version of sfEasyGMapPlugin)
- there are interesting functions concerning Bounds :
- smallest enclosing bound
- propel criteria "in bounds"
- homothety transformation
- zoomOut transformation
- there are interesting functions concerning conversion from/to lat/lng to/from Google's pixel coordinates system. These can be very useful if you want to guess the bounds knowing only the center lat/lng, the zoom level and the map's width/height in pixels. They involve a few mathematical formulas that were not so straightforward, (since you need to understand how Google's projection works) so trust me, these functions are valuable, even if they only concern power users.

I have also developed a few doctrine-specific functions which are unfortunately not available yet because not generic enough. I will try to release them in the next version.

The official symfony page is here : http://www.symfony-project.org/plugins/sfEasyGMapPlugin

Please feel free to comment on this work in progress !

I was looking for a nice blogging solution for symfony, and all I found was a very simple plugin and a lot of people encouraging me to build my own blog. Even though it is a nice exercise, my philosophy is to not reinvent the wheel. Wordpress is surely the best free blogging tool available, so I preferred to spend time integrating it into my symfony application than to create yet another sfVeryEasyBlogPlugin.

Integrating Wordpress into symfony can be done in three steps :

• integrating the blog into the application and its layout
• merging the authentification system
• integrating the blogging information into the symfony application

There is a wiki page handling the last two steps : http://trac.symfony-project.org/wiki/HowToIntegrateWordPressAndBbPressWithSymfony, written by Michael Nolan but I actually concentrated my efforts on the first step for the moment and that is what I will describe.

Integrating Wordpress into a symfony application and its layout

Install Wordpress

We need to store the wordpress files somewhere, I chose to create a new plugin sfWordpressPlugin and put the whole wordpress into the folder

plugins/sfWordpressPlugin/lib/vendor/wordpress

I then created a symbolic link in the web directory called blog pointing to the wordpress directory. That way I was able to run the Wordpress configuration and let it create its database

ln -s ../plugins/sfWordpressPlugin/lib/vendor/wordpress web/blog

Create a blog module

We then need a new module, which can be put in the new wordpress plugin and which I called sfWordpress. I enabled it in my frontend application and added the following routing :

blog:
  url:   /blog/*
  param: { module: sfWordpress, action: index }

Create an action that executes Wordpress

It now becomes a little tricky. I want to execute Wordpress from inside symfony. The goal is to use output_buffering to send the output to the template. I experienced three difficulties :

• some actions in Wordpress output specific headers, such as feed actions, so their output should be sent directly to the browser and not go through the symfony template
• including the wordpress files inside of a function and using buffering to store the output seemed like an easy solution, unless Wordpress used a lot of global constants... which is unfortunately the case ! Wordpress has some very bad coding habits, they use a dozen of global variable, and some of them have such stupid names as "$name" which means anyone can override them by error (Me for example...)
• the __() function of Wordpress and symfony are conflicting...

I was able to overcome these difficulties, and here is how my action looks like :

/**
 * intégration de Wordpress
 *
 * @param sfWebRequest $request
 * @author fabriceb
 * @since Mar 4, 2009 fabriceb
 */
 public function executeIndex(sfWebRequest $request)
 {
   // Don't load symfony's I18N
   $standard_helpers = sfConfig::get('sf_standard_helpers');
   $standard_helpers = array_diff($standard_helpers, array('I18N'));
   sfConfig::set('sf_standard_helpers', $standard_helpers);
 
   define('WP_USE_THEMES', true);
   chdir( dirname(__FILE__) . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . 'lib' . DIRECTORY_SEPARATOR . 'vendor' . DIRECTORY_SEPARATOR . 'wordpress' );
   global $wpdb;
   ob_start();
   require_once( 'wp-blog-header.php' );
   $this->blog = ob_get_contents();
   if (function_exists('is_feed') && is_feed())
   {
     ob_end_flush();
     throw new sfStopException();
   }
   else
   {
     ob_end_clean();
   }
 }

And I had to hack the wp-blog-header.php file to solve the problem of all the global variables :

equire_once( dirname(__FILE__) . '/wp-load.php' );
 
 // @HACK FABRICE
 // All variables defined here are considered global by Wordpress
 $local_global_vars = get_defined_vars();
 foreach($local_global_vars as $local_name => $local_value)
 {
   $GLOBALS[$local_name] = $local_value;
 }
 // Don't create new global variables ourselves, and do not overwrite other global variables, for example $name...
 unset($local_name, $local_value, $local_global_vars);
 // @HACK FABRICE
 
 wp();
 
 // @HACK Fabrice
 global $posts;
 // @HACK Fabrice
 
 require_once( ABSPATH . WPINC . '/template-loader.php' );

My only small disappointment for the moment is that I did not solve the I18N conflict, I just avoided it. I will try to come back on this later to fnd a real solution... using namespaces for example ?

Integrate Wordpress view in the symfony view

I created a new theme in my Wordpress, based on the default one, which goal was to output only the content of the blog without the layout. It is actually quite easy to do, you just go in each of the php files of the template and you remove all the references to the following functions :

• get_header()
• get_footer()
• get_sidebar()

That way, the output of Wordpress stored in the buffer is just the main content stripped out of the layout.

After that, the indexSuccess.php in the sfWordpress module is simple :

<?php echo $blog ?>

However you still want to include Wordpress's header or sidebar in your own layout. To do that I did the changes directly in my layout.php, as for example in the header :

<?php if (defined('WP_USE_THEMES') && WP_USE_THEMES): ?>
  <?php get_header(); ?>
<?php else: ?>
  <?php include_http_metas() ?>
  <?php include_metas() ?>
  <?php include_title() ?>
<?php endif; ?>

Or for the sidebar :

 
<div>
  <?php if (defined('WP_USE_THEMES') && WP_USE_THEMES): ?>
    <?php get_sidebar(); ?>
  <?php else : ?>
    <?php include_component('reference', 'quickList') ?>
  <?php endif; ?>
</div>
 

Secure the application

It was a big surprise to see that every dynamic Wordpress file is actually accessible from the web server. I do not feel at ease with this, and I plan on blocking direct access to any of the files. However for the moment I still see two files that are necessary and I have not yet wrapped inside a symfony action :

• wp-comments-post.php which is used to post the comments
• xmlrpc.php which is used for the pingbacks

So my philosophy for the moment is to trust Wordpress for the frontend files, and block access to all the other directories by including the following .htaccess in each of them :

        AuthUserFile /etc/apache2/.htpasswd

        AuthName "Admin only"

        AuthType Basic

        require valid-user

Url rewriting

If you enable the url rewriting in Wordpress there is actually nothing to do, since the symfony routing already routes any /blog/* url to the Wordpress action. However you must be very careful about the .htaccess that Wordpress automatically generates and which will break everything !

Therefore I created an empty

plugins/sfWordpressPlugin/lib/vendor/wordpress/.htaccess

owned by root and removed any write access for the user www-data

Conclusion (for the moment)

My plan is to publish very soon the work done in a sfWordpressPlugin and work on the next two steps of integration :

• Merging authentication systems

This should be quite easy to do without a hack, since the whole authentication system of Wordpress is overridable by a plugin. I think Eric Kittell actually already did it, let us hope it is opensource.

• Exchange contents between symfony and Wordpress

There are two solutions here, create a schema file for the wordpress database or use the rss file as a web service content provider. Both are interesting.

Please feel free to comment on this work in progress

Theodo est une jeune équipe de développement, spécialisée en symfony en particulier et plus généralement toutes les technologies de développement web opensource. Quoi de plus normal quand on a la philosophie opensource du partage des connaissances de partager à son tour ses découvertes. C'est le but de ce blog, où nous partagerons régulièrement les découvertes techniques ou les astuces des développeurs Theodo.