Step 1: Server and client communication

The dev server is our standard set-up: Debian stable (currently Etch) running with stable apt packages of PHP 5 (5.2.0) and Apache 2. I have Samba set-up to share each developers home directory with Apache having multiple VirtualHosts per developer serving from within those home directories.

My ‘client’ is Windows XP or Vista (FWIW these instructions tested on both) running PhpED 5.2. We’ve mapped a drive to the home folder on the dev server and we can write to files within it.

The Nusphere website has detailed instructions here & here and here for getting the communication between client and server set-up. You probably want to read through all of that first but here’s my summary:

Install the server module

Situated somewhere like C:\Program Files\nusphere\phped\debugger\server you should find a number of operating system specific folders, these contain the relevant dbg module, in my case I needed \Linux\dbg-3.2.10-Linux-glibc-2.2.tar.gz. Unzip this and place the version specific to your PHP version into PHP’s extension_dir which can be easily figured out by either running phpinfo(); or by looking at php.ini; in my case it’s /usr/lib/php5/20060613+lfs. For neatness I symlink dbg.so-5.2.x to dbg.so I then create /etc/php5/apache2/conf.d/dbg.ini and within it I write:

extension=dbg.so

[debugger]
debugger.enabled=on
debugger.profiler_enabled=on
debugger.hosts_allow=ALL
debugger.hosts_deny=ALL
debugger.ports=7869, 10000/16

Saving and then restarting Apache I check phpinfo(); and see near the top:

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
with DBG v3.2.10, (C) 2000,2007, by Dmitri Dmitrienko

…with further down the page more detailed information relating to the dbg module.

A few notes on my set-up:

• the /etc/php5/apache2/conf.d/*.ini is a Debian thing. If you’ve compiled from source or use another distribution then it’s likely that you want to put the dbg configuration settings into php.ini, you can find out where that lives on your system by looking in phpinfo()
• note the configuration line debugger.hosts_allow=ALL. It’s possible (and likely desirable) to only allow debugging sessions between specific machines. On my internal network I don’t care so to save configuration changes when new developers start or machines change I’m leaving it open to all

Ensure Server can talk to client

With the server successfully set-up we now want to ensure that the server can talk to the client. To do this fire up PhpED and ensure that the the listener is running, this is the little satellite dish in your task bar. If you right-click and select set-up you should see this:

Good, now on the server telnet to the client, thus:

telnet <client IP address> 7869

If it’s working you should see a black dot appear within the listener icon in the system tray, if so you’re done. Just Ctrl and ] to exit the telnet session and move onto step 2.

Note: If you don’t know your ip address you can fire up a dos window and type ipconfig.

Step 2: Project set-up and mappings

Step 1 is all relatively straightforward assuming you’re already comfortable with the inner workings of your set-up. What is less obvious is how to properly set-up the project to actually get down and start debugging. I have had partial success in the past with simple projects but the issue has always been with mappings. If all you want is a PhpED project where it’s root is also the document root of the website then there’s not a lot to it. Where the problem lies, for me at least, is when there are library files outside of the document root that you still want to be able to see and edit from within your project.

To illustrate a slightly more complex project set-up I’ll go through the mappings for one of my Symfony projects.

My directory structure is as follows:

/home/<developer>/www/projectname (checked out from subversion, this is the trunk)
/home/<developer>/www/projectname/codebase
/home/<developer>/www/projectname/codebase/web (default name for a Symfony project’s document root)

where /home/<developer>/ is mapped to Z:\ (or whatever) on the client.

Elsewhere Symfony has been installed using PEAR so lives in /usr/share/php/symfony. To make it easier for a developer to look at (read only) versions of core Symfony (and PEAR) classes I ensure that within the developers’ sandbox the library files are symlinked. So for example with symfony the developer would have:

/home/<developer>/www/lib/symfony -> /usr/share/php/symfony

We want to be able to edit all of the files within the project so when setting up the new project we set the root directory to be the projectname folder so in this case it’ll be Z:\www\projectname and for now, just to get the project set-up and the code imported set the ‘Run mode’ to be Local CGI.

Doing so gives us this view within the workspace:

That done we need to get the mappings sorted, so entering project properties again we set things up so they look like this:

Namely:

• Root directory is unchanged and Z:\www\projectname
• Run mode is 3rd party web server
• Root URL is blank
• Remote root directory is blank

If we were to press the OK button now PhpED would complain as it needs to know which URL you’re using to access the third party web server (our dev server) so instead we select the Mapping tab and add the following mappings

1. The apache document root
   • Local directory is Z:\www\projectname\codebase\web
   • Remote directory is /home/user/www/projectname/codebase/web
   • URL is http://projectname
2. The Symfony libraries
   • Local directory is Z:\www\lib\symfony
   • remote directory is /usr/share/php/symfony

Ensuring that the original project root (in bold) is at the bottom of the list we can now press OK.

That’s it. If we open one of our pages, in Symfony’s case one of the files under web, and then press the debug button (green arrow with a D in) or press F5 the debugging session with launch and by default it’ll stop on the first line of the first file. You’re now in debug mode, alright!.

How to use the debugger is left as an exercise for the reader. As you’d expect there’s more information on PhpED’s debugging features on their website.

This does however cause problems with older legacy sites that generate reams of warning errors because the developers were slack and - say - didn’t declare all their variables. So, the obvious solution is to set the error reporting at the VirtualHost or.htaccess level.

Or is it? At the recent PHPWM meeting I brought up my issue that whenever I set it to be:

php_value error_reporting E_ALL & ~E_NOTICES

which in php.ini will give you errors but not the notices, it was _definitely_ not working for me in the vhost. A possible solution offered was to use the integer value of the constant instead but we all couldn’t remember what that was.

A quick Google later and it seems that using the text constants doesn’t work in the vhost or .htaccess but the integer version DOES. So the definitive answer to “How do I turn on PHP errors but get it to ignore warnings in a vhost” is

php_value error_reporting 6135

Well, this works for me on php 5.2.3 anyway

That list is:

1. sfSimpleCMSPlugin
2. sfGuardPlugin
3. sfPropelActAsNestedSetBehaviorPlugin
4. sfMediaLibraryPlugin
5. sfSimpleBlogPlugin
6. sfSimpleForumPlugin
7. sfFeed2Plugin
8. sfgWidgetsPlugin
9. sfThumbnailPlugin
10. sfUJSPlugin
11. sfControlPanelPlugin
12. sfFormValidationPlugin
13. sfMogileFSPlugin
14. sfLightboxPlugin
15. sfCaptchaPlugin
16. sfNiftyPlugin
17. sfPrototypeWindowPlugin
18. sfPropelLoadbalancerPlugin
19. sfSavvyPlugin
20. sfYzClientSideValidationPlugin

I find it very interesting that the ’simple’ ones are all in the top 6 with the CMS one - which is very new - already taking up top spot.

It proves that the interest is there for off-the-shelf solutions built upon this great framework and I feel that there’s going to be lots of exciting activity in this space over the coming months. For example  I’m sure I’m not the only one who is eagerly awaiting the impending release of Magento which is based upon the Zend Framework.

Being reminded of it and having an hour to kill before I head off to the pub I thought I’d give it a stab, here we go…

My environment is PHP 5.2.3 on Debian Woody.

Upgrade to latest stable version (as root):
pear upgrade symfony/symfony

Stop being root and create test sandbox:
cd ~/www/TEST/
mkdir sfSimpleCMS && cd sfSimpleCMS

…obviously your paths can be different.

Create project and app
symfony init-project cms
symfony init-app frontend

Set-up the Apache Virtual Host:
<VirtualHost>
ServerName sfSimpleCMS.bealers
DocumentRoot "/home/bealers/www/TEST/sfSimpleCMS/web"
DirectoryIndex index.php
php_flag magic_quotes_gpc off
php_flag register_globals off
Alias /sf /usr/share/php/data/symfony/web/sf
<Directory /home/bealers/www/TEST/sfSimpleCMS/web>
AllowOverride All
Allow from All
</Directory>
LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog /var/log/apache/sfSimpleCMS.log
ErrorLog /var/log/apache/sfSimpleCMS.log
</VirtualHost>

…your paths should match the location of your sandbox

Restart apache (as root, or use sudo)
apachectl reload

Make sure that your hostname resolves to the IP of the server and then try it in your browser in my case http://sfSimpleCMS.bealers

Do some simple config
mysql> create database cms;
mysql> grant all on cms.* to cms@localhost identified by 'cms';

Edit config/propel.ini so that:
propel.database.createUrl = mysql://cms:cms@localhost/
propel.database.url = mysql://cms:cms@localhost/cms

Edit config/databases.yml so that:
all:
propel:
class: sfPropelDatabase
param:
dsn: mysql://cms:cms@localhost/cms

Install the re-prequisites
symfony plugin-install http://plugins.symfony-project.com/sfGuardPlugin
symfony cc

symfony plugin-install http://plugins.symfony-project.com/sfPropelActAsNestedSetBehaviorPlugin

Edit config/propel.ini so that:
propel.builder.addBehaviors = true

Install tiny MCE
cd /tmp
wget http://prdownloads.sourceforge.net/tinymce/tinymce_2_1_1_1.tgz?download
tar -zxvf tinymce_2_1_1_1.tgz

Move the actual useful bit to our Symfony project (obviously change this to contain the right path for you)
mv tinymce/jscripts/tiny_mce/ ~/www/TEST/sfSimpleCMS/web/js

Tidy up
rm -Rf tinymce*

Get back to our project
cd ~/www/TEST/sfSimpleCMS

Install sfSimpleCMS
symfony plugin-install http://plugins.symfony-project.com/sfSimpleCMSPlugin

Build everything
symfony propel-build-all

Our database now looks like this:

Edit apps/frontend/config/settings.yml so that:

all:
.settings:
enabled_modules: [default, sfSimpleCMS, sfSimpleCMSAdmin]
sfSimpleCMS:
default_text: '[add text here]' # Default text for page editable parts
routes_register: on # Use the plugin's routes
rich_editing: on # Use TinyMCE for rich text editing
default_page: home # Slug (=path) of the default root page
home_link: My swell site # what is displayed on the top right corner of the pages (can be HTML code)
use_l10n: false # Enable multiple versions for a single page
localizations: [en, fr, es] # If l10n is enabled, list of cultures in which pages are available
default_culture: en # If l10n is not enabled, default culture for pages
editor_credential: # Name of the credential required for page editing (leave blank for free editing)
publisher_credential: # Name of the credential required for page publishing (leave blank for free publishing)
templates: # Available templates
simplePage: Simple Page # the key is the name of a template which must be present in modules/sfSimpleCMS/templates/
home: Home # the value is the name under which the template is presented in lists
slot_types: # Available slot types
Text: Simple text
RichText: Rich text
Php: PHP code
Image: Image
Modular: List of components

Import some data. I was unable to get the fixtures to load by running:
symfony propel-load-data frontend plugins\sfSimpleCMSPlugin\data\fixtures (actually I’ve never had much luck with loading data from fixtures, but that’s another story) so with a bit of trial and error I came up with this simple query which’ll give us our first page (if we don’t do this things go a bit weird and the top element has no template assigned so the view barfs).

mysql> insert into sf_simple_cms_page set id=1, slug="home", template="home", tree_left=1, tree_right=2, is_published=1, created_at=NOW();

Visiting http://sfsimplecms.bealers/frontend_dev.php/sfSimpleCMSAdmin/ should give you the site!

Double clicking on the content areas opens an editing window. I’ve been unable to get rich text editing working with tinyMCE but I guess it’s in the wrong place in the directory tree. I notice that theres a sfSimpleCMSPlugin folder under web that has its own js folder. Maybe it needs to go in there but I’ll leave that as an excersise for the reader whilst I head off to the pub.

Here’s the official plugin page for further reference.

Note: It see that Wordpress has munged the tabs which are important for the yml files. I suggest you look at the official plugin page above should you be unsure of the tab order. I’ll attempt to tidy it up some time soon.

This plugin allows you to add a simple Content Management System (CMS) to your symfony application with the following features:

* Uses Javascript and Ajax to provide a neat user experience
* Edit zones in pages
* Edit page URL (you can use / in page path)
* Edit content in the real context (’edit in place’)
* Preview result
* Create and manage a tree structure for pages
* i18n ready (the interface is translated)
* l10n ready (a page can have different versions)
* support multiple templates
* Basic publication workflow
* Breadcrumb navigation
* User management is controlled through sfGuardPlugin

It is not aimed at replacing full-featured CMS packages, but offers a lightweight alternative for when you build a website that has to contain pages often updated by special users. It is voluntarily simple, and very easy to configure; so it should fulfill most basic CMS requirements.

Sounds exactly what we’ve been looking for (or at least intending to build)

More here

Sounds like a bargain to me.

Symfony is great, not just because it allows developers like me to get on and build complex, easily maintainable apps but also because the documentation is superb.

When I picked it up 5 months ago it was on version 0.6 and already had:

• The obligatory webcast (I watched this once and then moved along)
• A beginners intro
• A full hour-by-hour ‘project in a day’ called Askeet with very detailed code examples leading the reader to finish up with a full working project
• Forums, mailing lists, wiki etc.

To build on this already great work, today the printed book was released - which I’ve ordered. They’ve also gone one better and released the whole thing available to read online under the GFDL licence. I happen to think that this is a pretty shrewd move and hope that it will cement Symfony’s place as one of the top PHP frameworks out there along with Cake and the ZF.

If you’re a web developer and have not yet jumped into bed with a particular framework - whether self-rolled  or community led - then I would strongly urge you to try out the Symfony offering. It’s the dog’s danglies.

Related

• Website news release
• Symfony project homepage
• Buy the book (with Symfony’s affiliate ID tagged)

Whether you currently live in the US or in Poland, if you know symfony well enough, we’re interested. The positions are in Paris, France, and we are willing to do the necessary paperwork and look for accommodation for you. The job description is a mix between web development and project management. Prerequisites for working at Sensio’s are simple:

* You must be an experienced PHP developer (you should know what OOP, MVC, ORM, and unit testing mean and how to apply them)
* You must be able to manage a small web project (you should know a bit about XP programming, trac, svn, and scheduling)
* You must be able to handle the relationship with a client (not necessarily with a tie, but at least with a smile)
* You must have already developed an application with symfony (askeet doesn’t count - you must have made the askeet tutorial anyway)
* You must be willing to move to Paris, France (who wouldn’t?)
* You must be available full time and soon enough (this is a real job)

French is not compulsory, since our teams speak English and the projects we work on come from all over the world. Salary is attractive, working conditions are nice, the team is fantastic, projects are fun. Plus, this is a unique opportunity to work in Paris.

If you’re interested, send a email to Fabien at fabien.potencier [at] symfony-project [dot] com. Interesting profiles will be contacted by phone during the week.

Post on Symfony site
Symfony, the PHP web framework

Today I put together a detailed/summary view switcher for a list of items coming from a database with a (script.aculo.us) fade in/out effect and I didn’t need to write one line of JavaScript. Now that’s what I’m talking about.

Here’s a summary of what I did, with example code:

Everything applies to the ‘list’ action belonging to the ‘bar’ module. The view displays either detailed or summary view for a paginated list of records coming from the database.

In my view file (app/module/templates/listSuccess.php) I add:

[php][/php]

A quick reload and I can see that the libraries have been loaded:

[html]

[/html]

My complete template looks like:

[php]

[/php]

and the module’s controller looks like:

[php]

class barActions extends autobarActions
{

public function preExecute ()
{
// set a view mode for the bar/list page if one isn’t already set
if (!$this->getUser()->hasAttribute(’viewMode’))
{
$this->getUser()->setAttribute(’viewMode’, ‘detail’);
}
}

/**
* @desc Called by AJAX when clicking on the [Detail|Summary] view link.
* This allows us to ‘remember’ the view that the user they have chosen
*/
public function executeSetmode()
{
$this->getUser()->setAttribute(’viewMode’, $this->getRequestParameter(”mode”));
// if javascript is disabled we need to re-direct back to the listing
$this->redirect(”bar”);
}

}
?>[/php]

So when we click on the detail/summary link we want to set a session variable so that the application remembers the view mode. To do this this the template specifies an AJAX call using the link_to_remote() JavaScript helper it then, by using the ‘complete’ parameter, executes the javascript methods. The visual_effect() calls are Symfony’s javascript helpers and they do the script.aculo.us fades between the two content windows, note the chaining. The latter part of the ‘complete’ parameter are additional direct javascript calls to Prototype methods so we can swap the navigation links to remove the link for the active view mode.

Like any self-respecting developer I wanted to ensure that the code would work with scripting turned off. Now this was the only part of the excersise where I had to do a bit of digging. In the excellent Symfony documentation under JavaScript helpers there is mention of the if_javascript() method, e.g.:

[php]

You have JavaScript enabled.

[/php]

This seemed a bit cumbersome to me so after some further digging into the API I noticed the $options_html() array for link_to_remote() . Using this I pass the URL so the href gets populated (normally it’s just a #) and as the last item within ‘complete’ I add a return false; so with JavaScript enabled the link is not followed. Finally in my controller for setmode action I add the redirect. Now, even with javascript disabled, it all works albeit with a page reload.

I’ve still plenty to learn with Symfony but I can see that now I’m over the worst of the learning curve I’m going to start really enjoying it from here on in.

I’ve been a long suffering PHPEdit user from since it was open source and into having to pay (twice) for a licence. Unfortunately I started getting very irritated by some annoying and performance degrading bugs in the newest version. So after a number of bug reports and spending too much time trying to get to the bottom of the problem I just gave up and bought Nusphere’s PHP IDE.

It wasn’t cheap but I really quickly became to like it and a month in there is no way I’d switch back.

Anyway, I’d toyed with PHPEdit’s debugger (which I’m sure does work) but the documentation is sparse to say the least and I never got it working perfectly. But today I decided to try with PHPEd (the Nuspehre one) and got nearly there on my own but had some path issues at the last hurdle.

A post on their support forum and 10 mins later I’m presented with this FAQ entry.

Obviously mine is the the most complicated one at the bottom but adding the mappings as they suggest means that I can still see documents not in the project root and merrily debug!

Kick ass.