MODx – Belafonte Code

Image Manipulation with phpThumbOf in MODx Revolution

.abelafonte — Thu, 23 Jun 2011 20:59:56 +0000

PhpThumbOf is a MODx Revolution add-on that is based on the popular php script called phpThumb. It allows you to use the graphics libraries on an Apache server to make modifications to images on-the-fly.

This is an entry that is based on the presentation of phpThumbOf that I gave at the June MODx Houston Meetup, which demonstrates some of the awesome things we can do to manipulate images using phpThumbOf in MODx Revolution.

I’m not going to go through the process of how to download and install phpThumbOf from the MODx repository. I’ll assume that you’ve already downloaded and installed the add-on. There are no other add-ons that need to be installed to get this working.

These examples are created using MODx 2.1.0 and phpThumbOf 1.2.1-pl.

Note: there is also a MODx Evolution version of this add-on called phpThumb.

As of this writing, the official MODx documentation for phpThumbOf is pretty scarce. Initially, I thought you could only use the &zc= (zoom-crop) option when inserting an image because that’s all that’s mentioned in the add-on’s documentation. Then, I just randomly tried some of the other phpThumb options and they worked!

The Anatomy of a phpThumbOf Call— As an Output Filter

A MODx Output Filter allows you to pass the value of an element through any of a set of filters to modify it before it’s loaded into the page. The syntax looks like this

[[element:modifier=`value`]]

The first, and most common, way that you can use phpThumbOf is by using it as an Output Filter, attaching it to an image-based Template Variable in MODx.

Just to be thorough, I’m going to walk through the creation of an image-based template variable.

First, you’ll create a new template variable and name it whatever you want. Take the following, for example:

Fields for creating a new Template Variable

Then choose ‘Image’ as the input type under Input Options.

Select 'Image' as the input option

We’ll select the following image as the source of our Template Variable:

All we have to do is set this TV output as the src of our image. The code to call this Template Variable looks like this:

As we mentioned at the outset, an output filter modifies the element before it’s printed to the page. So we attach the phpThumbOf Output Filter to our previous TV call, like so.

[[*tvImage:phpthumbof=`w=120&h=120`]]

Note: If this is being called inside a TPL file or Chunk, then the asterisk becomes a plus: [[+tvImage:phpthumbof=`w=120&h=120`]]

The result is a newly-generated image, based on the image you choose for the ‘tvImage’ template variable that is resized to 120px by 120px. But if you notice, it has added a white background to keep our image’s size ratio stays intact.

Image resized to 120px by 120px

If you don’t want it to force a background, simply leave off either the width or height. Here’s what happens if we only specify a width:

[[+tvImage:phpthumbof=`w=120`]]

It resizes to the specified width, and just lets the height fall to whatever proportionally matches this width.

120 Pixels, Width Only. Height automatically calculated.

Just so you can see that the resizing possibilities are extremely flexible, here is another example with a width of 270px defined. You can even output an image that’s larger than its source image. (Not that it would be a good idea).

[[*tvImage:phpthumbof=`w=270`]]

Cropping the Image to Exact Dimensions

If we want to crop it and make it exactly 120px by 120px version of our image, we’d add the zoom-crop option &zc=1.

[[*tvImage:phpthumbof=`w=120&h=120&zc=1`]]

Now, we have a cropped version of the same image with the exact dimensions we specified.

Note: As of this version (phpThumbOf 1.2.1-pl) crop gravity does not work. So, Changing the &zc= value to ‘C’, ‘T’, ‘B’, ‘L’, ‘R’, ‘TL’, ‘TR’, ‘BL’, ‘BR’ will not change the (top, bottom, left, right, etc.) area of the picture that the crop will be anchored to. It will always be center-weighted.

PhpThumb’s Filters— Where the Fun Really Begins

Now that you know how to manipulate the size of the image, we’ll get into what I consider to be the real power of phpThumb: filters. I’m just going to throw out several demos of the filters available in phpThumb. Notice that we’re simply adding new filters to the end of previous phpThumb options. Order DOES matter. Filters are applied from left to right.

Blur

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=blur|10`]]

120px by 120px with a blur value of 10

Grayscale

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=gray`]]

120px by 120px in grayscale

Rounded Corners

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=ric|20|20`]]

120px by 120px with rounded corners

Notice how the filter is adding the white background into the non-image areas where the rounded corners are? We can get rid of that by switching the image type from JPG, to PNG.

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&f=png&fltr[]=ric|20|20`]]

120px by 120px, rounded as transparent PNG

Borders

We all want to add borders to images. You can do it with CSS, of course. But there are times when you might want to do it within the graphic itself. I don’t like going into Photoshop for simple stuff like this. It’s overkill. So, take a look at once such instance where I’d use phpThumb instead of CSS:

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&f=png&fltr[]=bord|5|0|0|FFFFFF&fltr[]=rot|-15|E4F6FE`]]

PNG output, border 5px with no curves, set to white. Rotated -15° with a matte color of #E4F6FE that matches the background

Rotate Graphic

Rotation requires a little explanation. You must specify a background color for the non-graphic area in the corners. In this example, we use #006699. The rotation is -45°

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=rot|-45|006699`]]

120px by 120px, rotated -45 degrees

If you want to reduce the JPG ugliness, you can increase the JPG quality (1-100):

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=rot|-45|006699&q=100`]]

120px by 120px, rotated -45° with JPEG quality 100

If you want to have a transparent background, just change the output to PNG like we did before:

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=rot|-45|&f=png`]]

120px by 120px, rotated -45° with transparent png

Color Overlay

The colorize filter allows you to overlay any hex color over an image. The first value is the percentage, the second is the hex value.

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=clr|35|990033`]]

120px by 120px with 35% color overlay of #990033

If you want a duotone effect, just precede the overlay filter with a grayscale filter to remove the image’s color first.

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=gray&fltr[]=clr|35|990033`]]

120px by 120px with 35% color overlay of #990033 atop a grayscale image, which gives us our duotone effect

Basic Text Watermark

You can do text and image watermarks as well, using phpThumb. With text watermarks, you can define the size, placement, opacity and even the TTF font you want it to be rendered with.

There are a lot of variables to set. Check original documentation to see all options.

Here’s a simple text watermark using a default server font:

[[*tvImage:phpthumbof=`w=120&h=120&zc=1&fltr[]=gray&fltr[]=wmt|Belafonte Code|3|T|FFFFFF||100|20|0||0|`]]

120px by 120px with basic text watermark, aligned-top, offset with 20% margin

Direct Image Manipulation

Output Filters are excellent, but what if you just want to modify a single image without creating a Template Variable for it? To do that, we call phpThumbOf as a snippet and then pass the image url and options into it:

You can chain the filters at the end of the options query string all the same.

Note: If you want to see all the rest of the MANY options available, check the phpThumb demos page.

Note: I have not gotten drop shadows with fades to work.

You’re probably thinking of all the amazing things you can do with this so you don’t have to go into Photoshop for simple graphic tweaks. It also gives you the power to let users and content editors add graphics to pages and always know that they will be formatted according to your design specification.

Feel free to leave some of your awesome and clever uses of phpThumb in the comments.

Evo version of this demo coming soon.

Hosting Multiple Top-level Domains Using MODx Revolution

.abelafonte — Fri, 11 Feb 2011 02:55:00 +0000

As a follow-up to the previous entry for setting up multiple subdomains in Revo, this entry explains how to use multiple top-level domains in a single installation MODx Revolution without worrying about access to your Apache config file.

Hosting multiple domains in MODx Revolution has been covered at H-Quadrat. But, just as with subdomains, I prefer to give each domain its own folder on the server to keep js, css and images tidy. So we will go into detail about how to route each domain to separate resource folders.

Preparation:

The top-level domains that you wish to use should already be pointed to/parked on the server where Revo is installed. Do this the same as you would with setting up hosting or parking for any domain.
You will need FTP access to the web directory where you plan to have MODx installed. We will be using it to upload files and create the assets folders.
This tutorial assumes that you have MODx installed already. We will be using a fresh install of 2.0.7-pl. (Download)
Please note that in the scripts you see in this tutorial, the bolded items are things you need to change for your setup.

Note: Although I’ve already covered the beginning parts of the setup process in the previous article, they will all be repeated here for completeness.

Creating Contexts

Setting up multiple sites will be done in what’s called “Contexts”, essentially “states” that your site can switch to. Basically, we’ll set the conditions that tell MODx which state to be in based on how the visitor got to the site.

When you first log into the MODx Manager, you’ll notice that there’s a little house icon in the tree. This is your default context.

The default ‘web’ context with basic pages added.

To create a new context, we need to go to System > Contexts in the top menu.

Location of the Contexts menu

Once there, you’ll notice that our default ‘web’ and ‘mgr’ contexts are there. The ‘mgr’ context is the manager interface. Neither of these can be edited or removed.

Click ‘Create New‘ and we’ll create our first alternate domain. The ‘Content Key‘ refers to how you want your context to appear in the sidebar and how you will refer to it when you tell MODx to go there. This should be simple, and include no spaces.

I’m calling my first alternate domain ‘Domain2’ for this example, since it’s assumed that my first domain will be attached to the ‘web’ context.

Refresh the resource tree on the left (using the green “recycle” arrows), and you should see your new context appear below the original ‘web’ context. This will be the home of our first alternate domain. I always create the minimal pages needed inside any new contexts just to give it some life and for testing.

Go ahead and add an index and an error page. You can use the new ‘Quick Create’ feature by right-clicking the new context and choosing ‘Quick Create > Document‘.

I added content that will immediately let me know that I’m looking at the correct context during testing.

My resource tree now looks like this:

Note: As of 2.0.5, you can edit your system settings and choose which field you want to display for each resource in your resource tree. In my example, I’ve chosen ‘menutitle‘ in stead of the default ‘pagetitle‘. This setting is found on page 4 of your system settings as ‘Resource Tree Node Field‘

Adding Context Settings

Now, we need to make our new context actually DO something by adding in the system settings specific to this child site.

Go back to your list of contexts under System > Contexts
Right-click the new context you created.
From the pop-up menu, choose ‘Update Context‘
Click on the green tab for ‘Context Settings‘

Location of Context Settings

We’ll be using this area to override global settings for things like ‘default home page’, ‘default template’ and pretty much any other global setting.

Click ‘Create New‘.

In the panel that pops up, there are several fields. We only want to edit the Key, Name and Value.

Context setting value fields

Do this once for each of the following settings:

site_start – the ID of your new context’s homepage.
base_url – Set this value to “/” (no quotes) since we’re making the root of the URL our base.
http_host – Set this value to “yourseconddomain.com” (your add-on domain url)
site_url – Set this value to “http://www.yourseconddomain.com/” (FULL domain url). Must have trailing slash.

Here’s what my finished context settings panel looks like:

Note: You’ll notice that I’ve added the value for the error page. You’ll want to do this, but it is NOT required to get your context up and running.

Option 1: Mapping Domains to their Contexts by Using Single Index

Note: Jump to Option 2 if you plan to give each domain its own folder.

When the official documentation refers to a ‘Gateway Plugin’ it’s essentially referring to the ‘index.php’ file. ONLY do this if you’re not planning on giving your sites separate resource folders. We will add conditionals to the main index.php that will handle the traffic for us.

This is extremely easy to do. Open your ‘index.php’ file and scroll down to the bottom. You’ll see a block of code that looks like this:

/* Initialize the default 'web' context */
$modx->initialize('web');

You can replace those two lines with the following:

/* Setup context mapping */
switch ($modx->getOption('http_host')) {
	case 'modxdomain2.com:80':
	case 'modxdomain2.com':
		// if the http_host is of a specific domain, switch the context
		$modx->switchContext('Domain2');
	break;

	default:
		// fallback, go to main context
		$modx->initialize('web');
	break;
}

Notice what’s happening here: “If the http_host setting matches the domain that was used to access this site, switch to the context associated with that http_host“.

For each extra domain, you would repeat the first section, from the switch all the way to the first break. Change the items that I’ve bolded to match the domains you’re working with, of course.

At this point, if your domains are parked, you should be able to visit your alternate domain and see pages from the second context!

You can stop here if you’re going to have all resource files in the main directory. Continue reading to see how I set up unique folders for each domain.

Option 2: Giving each Domain a Unique Folder

Now we create a folder on our server that will house the resources for our new domain. It can go anywhere, but for now, we’ll place them all in the same directory where MODx is installed and give it the same name as our domain. I’m calling it ‘modxdomain2’ for this example so there’s no guessing once I have several domains in place. Inside this newly-created folder, you’ll want to copy three files from the root directory:
.htaccess
index.php
config.core.php

This keeps our sites’ files organized neatly and prevents things from getting messy once all the domains are set up. Now that you have that in order, you can add all the css, javascript, files and folders that would normally live in the root of your web projects. Mine looks like this:

Routing Domain to Specific Folder on the Server

Similar to our earlier approach, we’ll be using .htaccess directives to tell the server what the root folder should be for each domain. Last time, we set it so that it would automatically map to a folder based on the subdomain that was used to access the site. This time around, we won’t use that approach because we can’t guarantee that some things won’t get confusing on the server once all domain names are in place. That said, we’ll want to type the directives manually so that we have ultimate control over what folder names go with each domain.

Open your ROOT FOLDER’S .htaccess file and paste the following:

#MAP TLD TO CUSTOM SUBDIRECTORY
RewriteCond $1 !^foldername/
RewriteCond %{HTTP_HOST} ^www\.modxdomain2\.com
RewriteRule (.*) /foldername/$1 [L]

Telling the Browser Which Context to Load

If you read Option 1 above, you noticed that we used the single index to insert all the rules that direct the user’s browser to the proper context based on which domain they used to access the site. We still have to do this, only the index will simply have a single rule, since our .htaccess is handling the re-routing for us already.

So, in the index.php that you copied into your second domain’s folder, find the following lines:

/* Initialize the default 'web' context */
$modx->initialize('web');

As you’d suspect, we do NOT want to point this traffic to the ‘web’ context. That would show the main site. We want it to go to our ‘Domain2’ context. So simply change it to this:

/* Initialize the default 'web' context */
$modx->initialize('Domain2');

Of course, you’ll want to replace ‘Domain2’ with the name you gave to your second context in MODx. You can also change the comment to read whatever you want.

Fixing Friendly URLs

Since we’re using some pretty advanced directives in the .htaccess file, we’re going to have to make changes to the frienly URL script that comes with MODx. Basically, we’ll have to tell it to only work on the primary domain. Open the ROOT .htaccess file and paste the bolded line into the default friendly URL script and be sure to change it to your domain name.

# The Friendly URLs part - MUST BE SPECIFIC TO TOP-LEVEL HOST SO AS NOT TO CONFLICT WITH SUBFOLDER REDIRECTS
RewriteCond %{HTTP_HOST} ^www\.yourprimarymodxdomain\.com
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) /index.php?q=$1 [L,QSA]

Notice how we added the first line that tells the server that ONLY our primary domain (whatever yours happens to be) will use the friendly URL script in this file. The other domains will have their own .htaccess file.

So, next, in the child .htaccess file that you copied into your subdirectory, delete everything else and place the following code to enable friendly URLs on child domain. (You will have to do this for each site that has its own folder.)

RewriteEngine On
RewriteBase /

# The Friendly URLs part
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php?q=$1 [L,QSA]

Point Child Site to the MODx Core (503 Errors)

If you’ve tried to access your child site already, you should be getting a pesky 503 Error. This means that your gateway cannot locate the MODx core. Open your second site’s config.core.php and do the following.

Find

define('MODX_CORE_PATH', dirname(__FILE__) . '/core/');

Change to

define('MODX_CORE_PATH', '/home/example/public_html/core/');

Use the full web path to your site’s core folder. If you don’t know your site’s full path, check your control panel or hosting welcome letter. You can use various PHP functions to find this information as well.

You’re All Done!

Now, with this in place, development can continue on addon domains without having to refer to relative directories. You can use absolute paths in your CSS and JS such as background-image: url('/images/background.gif'). This eliminates the need to make extra changes when, for instance, moving from staging to live servers.

Now you should be able to add as many domains to your MODx Revolution installation as you want. Of course, you want to be reasonable. If your site deals with incredible amounts of traffic, you may want to consider separate installations for each domain. But for the majority of site owners and developers, this will be the perfect solution for keeping a family of sites in one place.

Bonus Information and Optional Tweaks

Automatically Route to WWW Site

As you might know, for SEO reasons, it’s good to globally redirect all traffic to a single version of your domains. I typically choose the WWW version. You can use the default MODx script in the .htaccess file and set this up for each of your domains. But with the following script, you can set it once for all domains that you point to this server. No customization needed in this script.

# FORCE WWW ON ALL URLs
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

Hosting Multiple Subdomains on MODx Revolution

.abelafonte — Sun, 18 Apr 2010 14:00:28 +0000

This write up gives you a step-by-step of how to set up and run multiple subdomains on a single instance of MODx Revolution. This process was created using the official documentation, along with some other helpful tricks that I added to make possible for anyone to do without root server access.

Update: Feb 11, 2011 — If you’re interested in hosting multiple top-level domains, the new write-up is here.

Before We Begin

In order for this to go smoothly, you should have a few things already taken care of.

Make sure that you have a wildcard (*) A Record created in your DNS Zone. If you don’t want to fool with wildcards, use your control panel to create the subdomains in your hosting control panel (although you won’t be using the real subdomains).
You must have FTP or File Manager access to the location where your MODx install lives.
Download and install MODx Revolution, already. I’m going to start with a fresh install of Revo. This tutorial uses RC-1, so the instructions you see here will likely apply to the final release.

Let’s Get It Started

When you first visit your Manager, you’ll see the ‘web’ container in the nav area. This is the context that houses the default main site of your MODx installation.

The default ‘web’ context with basic pages added.

Our goal will be to create several of these “home folders” one for each subdomain that we will create. So, let’s go!

First we need to visit the ‘Contexts‘ menu, located at System > Contexts.

Click to Enlarge

The Context area lists the default contexts: the ‘web’ context, which is the main site, and the ‘mgr’ context, which is the backend manager that we’re using to do this.

Click on ‘Create New‘ and we’ll create our first subdomain. The ‘Content Key‘ refers to how you want your context to appear in the sidebar and how you will refer to it when you tell MODx to go there. This should be simple and include no spaces (and preferably no caps). I typically name it the same as the submdomain I’m planning to use just because it makes things easier to remember (although these two names have no impact on one another). For this example, I entered the following:

If we refresh the resource list (using the green “recycle” arrows), we see our new context appear along with the original ‘web’ context. This will be the home of our first subdomain. Go ahead and create the minimal pages needed. I generally start with an index and an error page to get started. You can use the new ‘Quick Create’ feature by right-clicking the new context and choosing ‘Quick Create > Document‘. I typed the following:

As you can see, I typed something in the content area that will let me know that it’s successful when I go to test the subdomains later.

My resource list now looks like this:

The Setup

To get this new context to actually behave like a website, we need to edit it and add a few necessary variables. So go back to your list of contexts (System > Contexts) and right-click the new context you created. From the pop-up menu, choose ‘Update Context‘. Once there, you should click on the green tab for ‘Context Settings‘.

Location of Context Settings Tab

Click on ‘Create New‘ and we’ll begin adding the variables that we will need, one at a time. When the ‘Create New‘ dialog pops up, the only settings you need to worry about are the Key, Name and Value. Everything else goes untouched. I add a description just for kicks, but the main site’s description will usually override this description anyway.

Do this once for each of the following settings:

site_start – the ID of your new context’s homepage.
base_url – Set this value to “/” (no quotes) since we’re making the root of the URL our base.
http_host – Set this value to “subdomain.yourdomain.com” (your subdomain url)
site_url – Set this value to “http://subdomain.yourdomain.com/” (FULL subdomain url). Must have trailing slash.

Note: You might recognize some of these variables, as they are simply overrides of options currently defined in the settings for the main site in your MODx installation. You can add any settings that you wish to customize for each site such as Default Template and Error Page.

Here are my finished settings.

Click to Enlarge

Now We Make It Tick

So, let’s create a folder in our server to create a place where the subdomain’s files will live. We’ll place it in the same directory where modx is installed and give it the same name as our subdomain. My folder is called ‘subdomain1’ for this example.

Inside this newly-created folder, you will need to copy a few files from the MODx root directory:

.htaccess
index.php
config.core.php

Now, we edit these files so that they handle things properly when they’re accessed. Basically, we need to make them behave as if they were root folders.

Edit .htaccess

Make sure that RewriteBase is set to “/” with no other folder names behind it. (In most cases, it will probably already be set correctly.)

Edit index.php

Find

$modx->initialize('web');

Change to

$modx->initialize('subdomain1');

Change the context name to match whatever you named your context in the manager section.

Edit in config.core.php

Find

define('MODX_CORE_PATH', dirname(__FILE__) . '/core/');

Change to

define('MODX_CORE_PATH', '/home/example/public_html/core/');

Use the full web path to your site’s core folder. If you don’t know your site’s full path, check your control panel or hosting welcome letter. This information should be readily available with your account.

At this point, everything should be working smoothly and you can test the success of your setup by accessing http://www.yourdomain.com/subdomainfolder/ and you will see the contents of your main page.

In my case, I got the “This is Subdomain1” text that I typed as a success message. So, I’m in good shape!

Routing Subdomain Traffic to the Proper Folder

Now that we have all of our settings in place and our folder created, we just need to tell the server where to redirect this traffic to so that we can be sure our visitors don’t see the main site when they access this url. In the official documentation, they describe how to do this in your Apache Config File. I got mine working that way, but it was a huge pain. I wanted to find a way that would work without needing to hack around in Apache. Not to mention, most users do not have root access to their config files.

After several days of searching, I came across a regex hack from jdmorgan at WebMasterWorld that could be placed in the htaccess file. The script will take any traffic that comes in through a subomain and redirect it to a subfolder that matches that subdomain. This turned out to be exactly what I needed since I wouldnt want my subdomains to have to share folders and files with the main site anyway. That would be a disaster waiting to happen.

Place the following script in the .htaccess file that resides in the MAIN folder of your MODx installation. This does NOT belong in the .htaccess files of your subsequent folders. Add this to your .htaccess AFTER the Friendly URLs code or it will break Friendly URLs

#REDIRECT SUBDOMAIN TO SUBDIRECTORY OF SAME NAME
RewriteCond %{ENV:REDIRECT_SUBDOMAIN} =""
RewriteCond %{HTTP_HOST} ([a-z0-9][-a-z0-9]+)\.yourdomain\.com\.?(:80)?$ [NC]
RewriteCond %{DOCUMENT_ROOT}/%1 -d
RewriteRule ^(.*) %1/$1 [E=SUBDOMAIN:%1,L]
RewriteRule ^ - [E=SUBDOMAIN:%{ENV:REDIRECT_SUBDOMAIN},L]

If you had success above when accessing your subfolder directly, you will be equally rewarded when you visit http://subdomain.yourdomain.com, where you should see the contents of your subdomain’s home page.

Now that you have this working, you can repeat this process as many times as you wish to launch any number of subdomains within your MODx installation.

Our next task is that of hosting completely different domains inside a single MODx installation.

Troubleshooting

Error 503

If you’re getting an Error 503 when you access either the subfolder or the subdomain, then you need to check your config.core.php file. If the path there is not specified correctly, you will get this error.

You might also check that the Context settings you created are correct.

Subdomain Not Displaying Sub-folder Contents

To be sure our redirect script is working, try adding a simple HTML file into your subfolder and accessing it via the subdomain (without folder name in URL). If you get a 404 error, then your site does not have a subdomain or wildcard set up.

How to Fix MODx CSRF Error when Using Firefox 3.5

.abelafonte — Mon, 28 Dec 2009 07:12:26 +0000

This article describes how to fix the error “A possible CSRF attempt was detected. No referer was provided by the server.” that recently appeared when I upgraded to MODx 1.0.2.

I use WordPress for all of my blogs, but my CMS of choice is MODx, hands down. As I recently mentioned on the forums and on Twitter, the update to version 1.0.2 started causing a very frustrating problem when accessing the manager in my copy of Firefox 3.5. The good news was that the problem did not seem to appear in Safari, so I was able to get into the manager from there.

The error shows up like this: A possible CSRF attempt was detected. No referer was provided by the server.

If you go to the MODx forums, you’ll see that they suggest any of the following: 1.) reinstall, 2.) go into your database or site cache file and change the value of Validate HTTP_REFERER headers to “0”, or 3.) turning the Validate HTTP_REFERER headers option off in the configuration settings using a browser that can access the manager successfully.

I tried all of these and they do work. However, none of these is an actual solution. For one, this security feature was added for a reason, and when it’s disabled, your Manager displays a constant warning about it. Also, if you change this manually in your site cache file, it somehow changes from “0” to “00” and the problem returns. Another reason is that I launch new sites with MODx at least once a month and I didn’t want to have to do that every single time I install.

I thought about it for a while and it hit me: the key word here is “referer”. The lack of a referrer made me think of the Firefox about:config panel because I had run into something similar not too long ago.

You see, a while back, I came across a blog posting on the Net somewhere that was entitled something like “How to Optimize Your Firefox Installation”. In it, there was a list of suggested “tweaks” that one would apply in the about:config panel that would theoretically speed up Firefox and make an overall “more optimized” application. One of these supposedly helpful suggestions was to instruct Firefox to NOT send referrer information. Well, I didn’t nit-pick the changes… I just applied them *Facepalm*. It took me over a year to notice that blocking referrer information was actually breaking some functionality on a few sites that I visit.

The Solution

Once I realized that mine was set to block, I made the necessary change, and now the problem is fixed. To get rid of the CSRF error, I went to the about:config of Firefox and found the integer for network.http.sendRefererHeader, which was set to 0, and reset it 2 in order to send the proper referrer information to the website.

Modifying the setting in about:config

Why This Works

Here’s some information about the different sendRefererHeader settings in the Firefox about:config from The Cafes that helps explain what’s going on here.

Setting it to 1 sends a referer header when following a link to another page, but not when loading images on the page. This will block most cross-site cookie tracking, but still allow WordPress and most other sites that depend on referers to function. Setting sendRefererHeader to 2 (the default) sends it when following links and when loading images on the page.

In the case of MODx, setting the integer to “1” does not work. It must be set to the default of “2”. So if you may have been poking around in your Firefox settings at one time or another, make sure to check this setting if you’re experiencing problems with your MODx installation.

Note: I upgraded from 0.9.6 to 1.0.2, so this problem may exist in other versions of MODx, such as 1.0.1 and likely affects all versions of Firefox.

Note: If you are having this problem and Firefox is not the culprit, you might have some other software on your computer that is blocking the sending of referrer information in an effort to protect your privacy. Some forum postings suggest that Norton Anti-Virus may also cause this error.