leftcolumn.net » zend framework

Zend Framework: How to add FCKeditor to a Zend_Form

Joe — Tue, 10 Mar 2009 00:39:18 +0000

There are around 1,083,367 JavaScript-based Rich-Text Editors out there, and I’m sure most are pretty good. But I’ve had good results with FCKeditor so I use it on all my projects. Here’s a step-by-step guide to adding the FCKeditor to your Zend Form Elements.

1 – The basics

Download FCKeditor and Upload it to your Web Server. It needs to be somewhere accessible to the world, for example: /js/fckeditor/, which on your server may be a path like /var/www/html/your_site/js/fckeditor/.

2 – .htaccess

The .htaccess that sets up your index.php as the bootstrap needs to exclude the files that FCKeditor uses. If your bootstrap code in .htaccess looks like this:

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

you’ll need to change it. I typically only rewrite to /index.php if the requested file really doesn’t exist. So .htaccess should be something like this:

RewriteEngine on
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1

3 – Zend_Form Elements

In the Form code, you need to make sure that you know the id of the Element (In this case the id is ‘body’), and that you are filtering out all tags and attributes that you don’t want to explicitly allow. Create an allowed_tags list like the one below and ensure that the FormElement has a StripTags filter applied to it:

$allowed_tags = array(
	'a' =>	array('href', 'title'),
	'strong',
	'img'	=>	array('src', 'alt'),
	'ul',
	'ol',
	'li',
	'em',
	'u',
	'strike');

$body = new Zend_Form_Element_Textarea('body');
$body->setLabel('Body')
	->setAttrib('rows', 12)
	->setAttrib('cols', 40)
	->setRequired(true)
	->addFilter('StringTrim')
	->addFilter('StripTags', $allowed_tags);

4 – View Script

Let’s Assume that you use Layouts, and that you only want to use the FCKeditor on a couple of pages on your site. You don’t want to include the FCKeditor code on every page because it just adds to the page size, so we do something like this in the View Script (Note: WordPress is messing with the quote marks in this block, ensure you have single quotes after src= and before the last semicolon. The other quotes should be double quotes.):

$this->custom_head = '';
$this->custom_head .= "";
$this->custom_body = ' onload="setupFCK()"';

5 – Layout Script

The Layout Script needs to know about this new variable, so the Layout Script needs to know to refer to $this->custom_head if it is set. Drop the code below inside the section of your layout script:

custom_head) {
	echo $this->custom_head;
}
?>

…and change the html body element to look like this:

custom_body) {
	echo $this->custom_body;
}?>>

6 – Loading the FCKEditor when the page loads

Create /js/custom.js and put this in it:

function setUpFCK() { if(document.getElementById('body')) { var oFCKeditor = new FCKeditor('body') ; oFCKeditor.BasePath = "/js/fckeditor/" ; oFCKeditor.Height = 400; oFCKeditor.ReplaceTextarea() ; } }

7 – FCKeditor changes

I like to implement FCKeditor as a single row of buttons for basic editing, just to keep it from looking too big and clunky. I use a set of icons like this:

FCKConfig.ToolbarSets["Default"] = [
	['Bold','Italic','Underline','StrikeThrough','OrderedList','UnorderedList','Blockquote','Link','Unlink','Image', 'SpecialChar','SpellCheck']
] ;

And I don’t want to enable any kind of file uploads, so I make sure these configs are all set to false (edited to show the relevant bits):

FCKConfig.LinkBrowser = false ;
...
FCKConfig.ImageBrowser = false ;
...
FCKConfig.FlashBrowser = false ;
...
FCKConfig.LinkUpload = false ;
...
FCKConfig.ImageUpload = false ;
...
FCKConfig.FlashUpload = false ;

8 – Anything else?

Not really! There are no Controller changes, which is good because this stuff all belongs in Views anyway. The Models know about the allowed tags, which is good because that’s the kind of work that Models should do. So to me this solution fits the MVC pattern and is not too hack-like. Feedback welcome…

Update: 25/3/09

Fixed various problems with the instructions and it should now all work properly.

Update: 20/3/09

I’ve been doing a bit of reading about Ruby on Rails with the intention of moving to it as my primary development platform. I haven’t quite got my head around the integration of front-end stuff like FCKeditor yet but Rails really does look like it simplifies the creation and maintenance of forms, which is, after all, about 70% of the work in websites. Need an example? Well Rails has a sensible defaults approach to forms where they can be created automatically based on the model. So compare that to Zend Framework, where I create a separate class for the Form that must match the structure of the model (and be updated when the model changes)! For a big site, that is significant: only one class per table/model!

Update: 29/11/2011

Fixed a typo. Also: check out Frost’s comment below for a tidier way to do this.

Zend Framework one-line platform config: Configure, Don’t Integrate

Joe — Wed, 18 Feb 2009 04:06:22 +0000

Separating config from code in Zend Framework is not as simple as it is in say, Ruby on Rails. And when your source code is version-controlled you want to minimise the manual configuration required. So here’s a nice way to keep it simple. The idea is to keep configuration data for your test and production environments in a single config file that does not change, then switch environments in a dedicated separate one-line config file.

Here’s a sample platforms.ini:

[test]
developer_mode = true
db.adapter = PDO_MYSQL
db.params.host = localhost
db.params.dbname = testdb
db.params.username = lkdf034k3k3b
db.params.password = SJGS43we3sdd

[production]
developer_mode = false
db.adapter = PDO_MYSQL
db.params.host = localhost
db.params.dbname = productiondb
db.params.username = ksjdhfkjjdhf
db.params.password = jfdhkjsdhdjk

.. .And here’s active_platform.ini. This is where we define which of test or production is currently active:

[platform]
setting = test

…And here’s how index.php refers to active_platform.ini to first determine which platform it’s on, and second load the appropriate config from platforms.ini:

// which platform mode are we on? i.e.: test or production
$active_platform = new Zend_Config_Ini('application/configs/active_platform.ini','active_platform');

// get the platform config
$config = new Zend_Config_Ini('application/configs/platforms.ini', $active_platform->setting);
Zend_Registry::set('config', $config);

// set up the db
$db = Zend_Db::factory($platform_config->db);
Zend_Db_Table::setDefaultAdapter($db);

When you want to deploy to production, you change the setting in active_platform.ini to ‘production.’ Simple as that.. this may be obvious but I’ve found it to speed up deployment and make it less error-prone.

Calling a View Helper from inside another View Helper in Zend Framework

Joe — Thu, 15 Jan 2009 10:02:23 +0000

Update 8th April 2009: Apparently as of 1.7.6 $this->view->[helperName()] now works with no extra work required so the info in this post is only necessary if you’re using <= 1.7.5. Thanks to Mike van Lammeren for the heads up, Â see Mike’s comment below.

If you’re relatively new to Zend Framework, some of the little details can stump you. To call a view helper from within another view helper, you need to give the helper some, er, help. Helpers will try to call a function called setView to set up $_view, so just add it:

Add these lines to the view helper:

private $_view; public function setView($view) { $this->_view = $view; }
then to call the View Helper you need, use $this->_view->anyHelperYouLike();

Edit: I found this information somewhere on the web, but can’t remember the source. Any information appreciated!