Just a quick, but important note about local and remote domains on Unix-type systems when you have a domain that has some functions on one machine and other functions on another machine… don’t forget to set localdomains and remotedomains appropriately.

For example, say you have www.domain.com on Machine A, and dev.domain.com on Machine B. Machine A is configured as the main web site and mail server. Some environments (and I’m talking specifically about WHM/cPanel here) will automatically add domain.com as local on Machine B. This means that when your scripts (or WordPress blog) running on Machine B try to send email to domain.com, it will get stuck on Machine B and never arrive on Machine A.

To avoid this, simply edit your localdomains and remotedomains files on Machine B:

/etc/localdomains
Here you’ll have to remove the domain.com entry. Just remove the whole line it’s on.

/etc/remotedomains
Here you’ll need to add domain.com as an entry. Just add the domain on a line by itself.

And that’s it. =)

Ok, so say you want everyone who goes to domain.com to be magically redirected (in a search engine-friendly manner) to www.domain.com. Lots of reasons you might want to do this, but most relate to analytics. Google has a handy guide just for you.

In short, though, you’re setting your web server to 301 (permanent redirect) all requests to certain domains over to the preferred domain. Doing it as the server level means you don’t have to do it at the script level (no PHP or ASP scripts doing redirects here). Check out the article for specifics.

The next time someone tells you that you can’t track downloads in Google Analytics (like links to PDFs, movies, or other assets that don’t reside on an actual page) tell them they’re full of crap. =) Provided you’re using the newer ga.js method you are golden. Check it out here.

The one gotcha is that the ga.js code can’t be at the bottom of the page, which is non-typical, and could increase page rendering times. The reason Google’s ga.js code goes at the very bottom is to prevent the latency of connecting to Google from adding to the page’s render time. Since the code is now at the top of the page, there’s no way to avoid the (admittedly only potential) latency problem.

But hey, you can track your document downloads! =)

Update: Also works for offsite links.

After installing FCK Editor 2.639b for Joomla 1.5, I was getting this error when attempting to edit an article:

“[path]/plugins/editors/fckstyles_template.xml was not found on this server.”

Naturally, it was a permissions issue related to the hosting environment. Full description of the known issue is here:

http://www.joomlafckeditor.com/forum?func=view&id=1544&catid=8#1544
(registration required)

Crunchy bits follow…

Re:server didn’t send back a proper XML response?
Apache web servers configured to use PHP suEXEC or suPHP will deny the execute permission on all files and folders that are world writable – 0777 and 0666. Which means your PHP scripts won’t run for any user in which the files are Chmod to 0666 or 0777. That is why it is recommended to use the values, 755 and 0644 for folders and files respectively. In most cases this will work; as the user, Apache will be running under will be the owner of the files and folders for your Joomla installation.
If you are not using suPHP or neither running PHP as CGI then Apache will be running under the ‘Nobody’ account or some other equivalent. That means your files will have to be set to 0666(‘rw-rw- rw-‘), and in the case of using PHP to create new files in a directory, the folder will have to be set to 0777(‘rwxrwxrwx’).

I set the following directories to 777:

• /plugins/editors
• /plugins/editors/fckeditor

and the following files to 666:

• /plugins/editors/fckeditor.class.php
• /plugins/editors/fckeditor.legacy.php
• /plugins/editors/fckeditor.php
• /plugins/editors/fckeditor.xml

Voila! =)

After installing Joomla, remember to:

1. Set the RSS feed cache directory (/cache) to writable (I used 777, not sure if that’s required, but 666/664 didn’t seem to work), or the RSS feed module will throw up an error in its output.
2. If adjusting template configuration, make sure and make the template’s params.ini file to writable (666 worked).

Another DOCman issue, this time with a plugin I hadn’t tried before called AutoThumb 1.41. Installing through the normal ZIP upload method returned the following error:

JFTP::mkdir: Bad response
JFTP::chmod: Bad response
JInstaller::install: Failed to create directory. “/[path]/plugins/docman/autothumb/libraries/phpthumb/cache/source”
Install mambot Error

So, the solution was to change the ownership of the /plugins/docman directory, and then give 666 permissions to the files inside it. Once this was done, the normal install process worked fine. =)

Ok, there are a couple of gotchas when installing DOCman 1.4x with Joomla 1.5x. The readme.txt file is less than helpful, but the short version is this:

1. Temporarily allow 777 permissions on the following three directories (this can be found in the DOCman support forum):
   /
   /administrator/modules/
   /plugins/
2. Install plugin as normal (I uploaded the ZIP using the standard Joomla installer).
3. After the install you’ll get an error message like “Warning: fopen([path]/administrator/components/com_docman/docman.config.php) [function.fopen]: failed to open stream: Permission denied in [path]/administrator/components/com_docman/classes/DOCMAN_config.class.php on line 121
   To alleviate this, change /administrator/components/com_docman/docman.config.php to be 666 writable (probably forever, but that assumes you’ll be changing your DOCman options as you toy with it).
4. Set permissions back to 755 on the three directories from step 1.

Voila!

Note: After this is done, no permissions changes need to be made to install the various official Joomla add-ons (which are indispensable) through the normal ZIP upload method:

• DOCLink
• DOCman Search
• mod_docman_catdown
• mod_docman_latestdown
• mod_docman_lister
• mod_docman_mostdown

Add-ons available at the DOCman downloads page.

To resolve ASP.NET CS0433 compile errors resulting from a changed code-behind, simply do the following:

1. rename the Bin directory (may need to wait for the processes inside to finish talking to it)
2. visit page in question (will result in an error, just ignore)
3. rename Bin directory back to Bin
4. visit page in question again

Ta da!. =)

Thanks go out to David Woods for this solution.

I’ve recently gone through the painful task of using Adobe’s GL2DW extension to convert a very large heavily component-ized, heavily templated GL CS2 site to Dreamweaver CS3. This would have been a much more grizzly experience without the help of Rob Keniger of MenuMachine fame and his revisions to the GL2DW tool found here:

http://www.menumachine.com/kb/162

Also Thuy Copeland’s efforts to catalog the issues and solutions with the extension found at her site here:

http://www.mindgraffiti.net/gl2dw-faq-for-common-problems/

I’ll summarize her findings. Prior to running the export make sure to:

1. Rename /Extras/Library to /Extras/Library/Snippets.
2. Remove all non-component GoLive object tags from components/templates (the GoLive datetime object, older smart rollover objects etc.).

A couple things Thuy doesn’t mention:

1. gl2dw will not handle editable header items correctly. Beware that after conversion you templates may not have editable headers, and thus any change to the templates would overwrite the head elements of your pages. Make sure and check this and add the editable regions back in if necessary.
2. Make sure all components and templates are loose in their respective folders, and not nested in subfolders. If you have nested folders, move the components/templates out of their subfolders (renaming if necessary). Example: /Components/interior/header.html could become/Components/interior_header.html

GoLive’s templates, components, and other Extras can be stored in hierarchal folders. Components are in the Components folder, and they can be in subfolder after subfolder after subfolder within. Example:

/Components/header/
/Components/interior/callouts/
/Components/interior/menus/

There doesn’t appear to be a way in Dreamweaver to organize templates and components like this. All components (called library items in DW) apparently live in one big bin (/Library for library items, /Templates for templates) with only alphabetization available to help organize them. Groan.

Behavior appears to be identical in the new DW CS4.

Ok, I guess I’m coming to the Firebug party a litte late (thanks David for passing this along ages ago… I never really followed-up on it ’til now). For those web developers not familiar with this great Firefox extension, run (don’t walk) over to getfirebug.com and get this thing installed. Among it’s other varied uses is a style inspector. This isn’t just your ordinary tag selector. The thing is incredible! It let’s you browse through a collapsable HTML tree, highlighting the divs, spans, and other elements you are hovering over in the tree. But not just that, it also shows you the CSS rules that are applying to (or being superceded by) the element. It even indicates the filename of the stylesheets in question and points out the line numbers for the reference. As if that wasn’t enough, it also lets you edit the page’s cached version of the source and style code for what-if-ing. It’s amazing!