I whipped up this little plugin because I kept getting pinned into a corner when using Categories. For example, if an entry is part of more than 1 category, Blue and Red as subgroups of a Colors parent group for instance, and you’d like to list all entries in the Red subcategory… well good luck.

{categories limit="1"}{category_name}{/categories}

This will give you “Colors”. Not what we’re going for.

{categories limit="2" backspace='2'}{category_name} -{/categories}

Will give you “Colors – Red“, which will work, unless one of your entries is also in Blue. Since the categories are listed alphabetically, you end up with “Colors – Blue” even though your url is http://site.com/section/category/red”.

Well, why not just take the URI segment and case modify it to say “Red”? Easy enough, as long as your URI segments match the name. So I wrote a plugin to take any string, such as {segment_3}, and strip out the “_” or “-” delimiters and set words to title case. Parameters exist to uncapitalize words such as “and”, “for” and “the”. Give it a try, it just might come in handy in a pinch. Full documentation is in the plugin’s “Usage” area, which you can see in the Plugin Manager of your ExpressionEngine Control Panel, but here’s a quick example usage:

<title>{site_name} | {exp:uri_prettify uncap_keywords="yes" keywords="and|to|the|milk"}{segment_1}{if segment_2} | {segment_2}{/if} {/exp:uri_prettify}</title>

Download URI Prettify v1.0.

I’ve heard this, or something similar, many times. I’ve both thought it myself and said it aloud. It shouldn’t be hard, right? While designing and developing ExpressionEngine websites, i try to avoid implementing them at all costs. However, I’ve eventually had to spend enough time taming them that maybe we can be friends. Or at least not enemies. Oh and newsflash. WordPress uses TinyMCE. They also have over 650 lines of javascript customizing it, but hey, nothing is keeping you from making your own tweaks.

There are two big players on the WYSIWYG scene. FCKeditor and TinyMCE. I’ll be focusing in on the later in this article. If anyone else has insights on FCKeditor, please post them in the comments. There are plenty other small ones, including jWYSIWYG (which i ported to ExpressionEngine, but i digress… it has it’s own issues). Also worth noting, there are two main ways of implementing TinyMCE in ExpressionEngine. Leevi Graham’s Extension, and the 1st party extension.

The Problem

There are 2 main problems with the default install of TinyMCE. The first: it’s ugly, bloated and unintuitive. The second: the code that might come out of it when clients take control. Let’s get to work:

The first step is customizing which buttons and features (including plugins) are on loaded. How this is done can depend on where the javascript is loaded (the tinyMCE.init() function), but the method is the same regardless. Parameters can be added inside the function which control what’s being loaded. I’ll show you what i use myself and then I can walk through what’s going on:

Where We’re Going:

Clean TinyMCE

mode : "textareas",
theme : "advanced",
skin  : "thebigreason",
plugins : "fullscreen",
theme_advanced_toolbar_location : "top",
theme_advanced_toolbar_align : "left",
theme_advanced_buttons1 : "formatselect,fontselect,fontsizeselect,separator,bold,italic,underline,separator,justifyleft,justifycenter,justifyright,bullist,numlist,separator,link,unlink,image,separator,code,separator,undo,redo,fullscreen",
theme_advanced_buttons2 : "",
theme_advanced_buttons3 : ""

Customizing Appearance and Theme: Parameters

• mode: This tells TinyMCE where to apply itself. If set to “textareas”… i think you get the idea. If you set it to “exact” you can target specific ids with the additional parameter -> elements: “first_id, second_id”
• theme: If you want to get custom, set this to “advanced”. It’s as easy as that. There’s a “simple”, but you lose a lot of functionality.
• skin: Skins can be be created or downloaded by others that have done the same. They usually consist of a few css files, some images, and a bit of javascript. They’ll go in the /tiny_mce/themes/advanced/skins/ directory. I really like TheBigReason’s skin — it’s clean and easy, utlizing the famfamfam silk icon set. Check it out
• plugins: There are number of cool functions to throw in here, from spellcheck and emoticons, to print and preview. Take a look at the whole list of plugins.
• theme_advanced_toolbar_location: Position the toolbar at the top of the textarea. Self explanitory.
• theme_advanced_toolbar_align: Left or right. Pick left. It’s better.
• theme_advanced_buttons1/2/3: The advanced theme, by default, has three rows of buttons. I myself prefer only one row, so I put all the buttons i want in the buttons1 parameter and leave 2 & 3 empty to prevent the defaults from sneaking back in. See the full list of TinyMCE buttons. can be found here. Just separate them by commas and use “separator” if you want to break the icons up. Feel free to drop in my list and see if that works for you.

Cleaning Up The Rendered Code

There are a few parameters here that can help you get more for less:

• fix_list_elements : true – This option enables you to specify that list elements UL/OL is to be converted to valid XHTML. This option is disabled by default.
• forced_root_block : false — This keeps block level elements, such as <strong> from being wrapped with <p> tags, if you need to prevent that.
• invalid_elements : “b,i,span” — Set any html elements you want to prevent being written. Not a bad idea at all. Conversely, there is a “valid_elements” parameter. Look at the defaults to see if you need to squash anything
• convert_fonts_to_spans : false — if you allow the user to set fonts, i would recommend this one, which prevents the depreciated font tag: <font size=”3″ face=”Comic Sans MS”>. USE THIS.

There are plenty–too many in fact–other parameters, but hopefully this will get you going in the right direction. Check out the full list if need be.

You can also customize the visual appearance of the redered in-editor code via the content.css file. You can find it here: tiny_mce/themes/advanced/skins/<your skin name>/content.css. Not a bad way to have your clients see a rough guess of what they’ll see on the site.

I plan on playing with creating my own theme(s) in the near future. We’ll see how that goes. If you’re ambitious, check out the documentation on that whole bag of apples.

Let me know if there is anything you’re trying to do in TinyMCE and maybe I can help you, and others, out. Hope this helps!

Load Optimization is a lot of little things added together for the greater good. When combined, page weight can be cut in half, or even more, with no change in functionality. Start with the lowest hanging fruit and move up to the more complex and more gritty as needed. I’ve found that 2 or 3 “out-of-the-norm” techniques will get you 80% of the way to a superfast loading site. Standard 80/20 rule.

I’ll break the modifications down into 3 categories:

1. Requests
2. Sizes
3. Queries

Before I get into the gritty details, I’d first recommend a tool to benchmark and compare performance as you work through these tips. My favorite tool is YSlow, a Firebug Addon for Firefox. It breaks your site down into a number of elements and grades you on a set of (mildly) arbitrary benchmarks. Great place to start. Compare your progress as you move forward. Find what gives you the best boost and try to replicate those changes on every site.

1. Requests

The more files you request (HTTP Requests), the slower your site load. In addition, the ORDER in which you request them and WHEN you request them can play a factor as well

• Combine as many javascript functions/libraries/plugins as you can in a single include. I’m a huge offender in this category, sometimes with 8 to 15 javascript includes. Sites have to load these 1 at a time, in sequence. Try and keep it to 5 or 6 at max. Less is more.
• If you can’t combine javascript, try loading them right before your closing </body> tag. If they’re not needed for onLoad effects, at least your visitors won’t have to wait for the visuals
• CSS Sprites. Background images are a load-speed culprit . If possible, sprite (a technique where you combine a number of elements into one image and position them as needed) as many elements as you can. It takes a little while but it’s worth it. Check out YouTube’s master sprite. THAT’S optmization. There are many tutorials online for this technique, just Google “CSS Sprite” or “How to CSS Sprite.” You’ll survive.
• I know a lot of people like to separate their CSS (style.css, layout.css, text.css, reset.css, ie6.css, ie7.css, etc….) for organization’s purpose, but every request adds just a little bit to your load time. It’s best to simply roll it into 1 to 2 main files (i like keeping a reset.css and 960.css combined for those applicable when using the grid, plus my main css sheet).
• Try using Google hosted jQuery/MooTools/Prototype includes. Chances are people will have these cached from visiting another site and will save a request. At least it will save you bandwidth
• Caching. There are a number of different levels you can approach here. First and most straightforward is ExpressionEngine template caching. Once your site is out of development, turn caching on for all major templates that don’t change at a moment’s notice. My general rule of thumb is 5 minutes for major templates (home page, first level landing pages, nav includes, etc) and 60 minutes for less used templates (contact form, sitemap, etc). Secondly, if you have templates that just change too often, maybe you have {exp:weblog:entries} tags that don’t change often, such as an intro paragraph to a news section or something similar. You can actually cache your tags. Example:

  cache="yes" refresh="30"

2. Sizes

I’m going to assume you’ve already optimized all your images. You wouldn’t be here if you were looking for that tip. (Save-for-web @ 100%

• Minimify your javascript. This gets rid of any extra markup, whitespace, etc… to save precious kb. Check out the YUI Compressor (http://developer.yahoo.com/yui/compressor/) to get those bad boys down in size.
• Gzip your javascript files. This gives me awesome results everytime. Once i tried this i never went back. It can change depending on your server, but as long as you’re on a LAMP stack, this should get you close. You’ll need to have mod_deflate loaded in PHP for starters. Behond that, it’s really a simple .htaccess update. I prefer to set it up to gzip everything and exclude the files i don’t want compressed (images, zip and rar files, gz, etc…). This usually cuts my js file sizes in HALF. The following .htaccess info should be able to be dropped right in your site.

# Gzip Our Scripts
######################################################
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ \
no-gzip dont-vary
SetEnvIfNoCase Request_URI \
\.(?:exe|t?gz|zip|bz2|sit|rar)$ \
no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
# Just in case some noob is using an old browser...
######################################################
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

3. Queries

Hopefully you’re doing this already, but disabling any parameter you don’t need in a {exp:weblog:entries} tag will help to speed up the query process and thus your site.

• My standard disable string is disable=”member_data|categories|trackbacks|pagination”.
  I usually leave category_fields and (of course) custom_fields out of there.

I try to do all these tweaks on all my sites. So far, i’ve cut average load times from 4 seconds to under 1.3 seconds across the board. Simply by using these techniques. Give it a shot.

That’s it for part one! If anyting doesn’t work or you’d like to add your tips, feel free to comment and i’ll add your tips in (and give you credit of course). I hope it helps you.