You might find yourself wanting to install Bug Genie, or some other such newfangled toy onto Ubuntu 10.04 “Lucid”.

You might find yourself stonewalled at the suggestion that your PCRE version (7.8) doesn’t meet the minimum requirements of 8.x

You might then have found yourself here.

The solution is thankfully straightforward. Just add the precise pangolin repo temporarily to your apt sources and install via apt.

sudo nano /etc/apt/sources.list

Comment out all the lines by placing a # at the start of each one. Then add the following to the end:

deb precise main restricted universe multiverse

Ctrl+X then ‘y’ to save from nano, then do:

sudo apt-get update
sudo apt-get install libpcre3

Then go back and restore your apt sources.list to its former state, and run apt-get update again.

If you’re using TYPO3 along with the jolly-lovely FED/Flux templating system then you may well have tried to make an FCE preview in the backend that includes an image preview.

Here’s where I started:

{namespace fed=Tx_Fed_ViewHelpers}
{namespace flux=Tx_Flux_ViewHelpers}

<f:layout name="FCE/Photo" />
<f:section name="Configuration">
	<flux:flexform id="photoConfig" label="Photo Configuration" enabled="TRUE">
		<flux:flexform.sheet name="photoDetails" label="Photo Details">
			<flux:flexform.field.file name="photoFile" internalType="file" allowed="jpg" maxItems="1" showThumbs="1" label="Selected Photo" />
			<flux:flexform.field.input name="altText" label="Image Alt Text / Title" />

<f:section name="Preview">
	<f:image src="{photoFile}" height="80" alt="{altText}"/>

However, this doesn’t work out so well. A quick showed that the returned image resource path was relative, such as:


This ain’t gonna work as we’re in the BE context and I wasn’t able to fool it with any number of ../../ attempts as it always resulted in a Resource Not Found error.

The solution? FED includes an Image viewhelper (Docs) that’s crazy powerful, BUT, and here’s the important part, it renders the resulting image resource out with an absolute path, making it useful in both FE and BE contexts.

The result?

<fed:image src="{photoFile}" height="80" alt="{altText}"/>

Job done.


Code snippet from Floxx:

<f:section name="Preview">
	<img src="<v:format.replace substring=".." content="{f:uri.image(src: '{file}', height: '50')}" replacement="" />" />

While we’re on a roll here, how about removing the ridiculous inline styles from Blockquote tags, and allowing your custom CSS classes to hold their ground?

This one is buried right inside the bowels of the CSS Styled Content standard TypoScript, you can knock it on the head here:

lib.parseFunc_RTE.externalBlocks.blockquote.callRecursive.tagStdWrap.HTMLparser. \n
  tags.blockquote.overrideAttribs >

The above should appear on one line, without the \n, that was just to fit it in the code window without a scrollbar. I’m pretty confident this is a very very legacy bogeyman that no-one has bothered to clean up, due to the relatively small user-base that requires customisable Blockquotes in the RTE. Either way, now you know.

When configuring the TYPO3 RTE, it’s a common requirement to restrict the tags available to the editor. The RTE has dropdowns for block types which, by default, contains everything from p, through h1…h6, section, aside and so on… Not good news if you’ve got creative editors.

Removing these involved digging into the source here to discover a seemingly undocumented property in the RTE.

You can set this up as follows in your Page TS:

RTE { 
    default {
        buttons.formatblock.removeItems = h1,h5,h5,pre

If anyone finds this, and wants a more detailed guide on adding and controlling the custom classes in the RTE, just shout loudly in the comments! Best of luck keeping your editors under control 😀

UPDATE: Also, watch out to make sure you’re reading the most up to date version of the RTE manual… DOH. I was reading an outdated one, which did not document the above. The current RTE manual can be found here, and outlines this feature. Always watch out for that, the Typo3 documentation can be a bit of a maze!

Just recently I’ve been plagued by an issue with a Magento cart checkout performing slowly between stages 5 and 6 of the standard one page checkout process. Some bad code in Magento’s core helped reduce the delays (Loop limit counters that are initialised INSIDE the loop? Hello?), along with judicious increases to DB and PHP cache sizes. However the problem remained, leaving me with a 6-10 second delay (Down from 15-20 I must add) when hitting the final button in the checkout to head off to the payment gateway of choice.

The culprit?

An open_basedir directive in the http.conf file for the VHost it was running on.

A note to anyone unfortunate enough to find themselves butting up against this problem: When open_basedir is enabled, the PHP realcache gets turned off. This cache basically tracks the locations of included files, meaning that the OS doesn’t have to perform as many lstat() calls to determine what’s going on with the files you’re trying to include. Once it’s disabled, and Magento decides to trigger a host of AJAX related checkout processes like, say, saving your order, emailing the customer and contacting the payment gateway, those lstat() calls add up fast.

The solution? Security pundits might wince, but the way around this little beauty is to disable open_basedir and hope to all things holy that there aren’t any arbitrary file access holes in the Magento codebase, which, given its immense size (Which contributes to this problem in the first place…) might be a risky bet.

There’s plenty of detail over here:, but I thought I share for any other poor souls out there who’ve lost sleep thanks to this behemoth of a shopping cart. For anyone looking for an alternative, I’ve heard you can do a lot worse than Oxid or OpenCart