The problems I ran into mostly had to do with working around the built-in Joomla JavaScript and admin form submission handling. Perhaps there’s a better way, but here is how I got things to work:

1. Manually call Joomla’s core scripts in the view’s layout file.
2. Override the Joomla functions “Joomla.submitbutton” and “submitbutton”.
3. Intercept form submissions from inside the Joomla.submitbutton function.
4. Update the necessary hidden fields manually and push through the form via Ajax.

1. Manually call Joomla’s core scripts in the view’s layout file.

This step was necessary when overriding the Joomla functions with my own. Without doing this, Joomla’s functions will be imported last, and will override your, erm, overrides. It’s easy enough to to – include this bit of PHP at the top of your view’s layout file:

<?php
$document =& JFactory::getDocument();
JHTML::_('behavior.mootools');
$document->addScript('/path/to/my_javascript.js');
?>

So, first you use JHTML to bring in the core Joomla JS files, then you attach your own JS file afterwards to handle the overrides.

Override the Joomla functions “Joomla.submitbutton” and “submitbutton”.

The primary override will be to the new Joomla.submitbutton method. Mine looked something like this:

Joomla.submitbutton = function(task){
	if (task == 'publish' || task == 'unpublish'){
		jQuery('input[name=format]', jQuery('#adminForm')).val('json');
		jQuery('input[name=task]', jQuery('#adminForm')).val(task);
		jQuery('#adminForm').ajaxSubmit();
	} else Joomla.submitform(task);
	return false;
};

This example intercepts form submissions for the publish or unpublish tasks. My form has a hidden field named “format” with the default value of “html” for a normal form submission. The script above first changes that to a format of “json”, and then my Controller can check for the format field and send the correct response and view.

I’m also having to manually set the “task” hidden field, since we’re stealing that functionality from Joomla’s core scripts. Finally, we do the ajaxSubmit call (this assumes you’ve already added jQuery and the jQuery Form Plugin to your document). In my real world script, I also passed some parameters to the ajaxSubmit() function, such as the callback functions for successful submissions and errors.

For me, this all worked when using the list checkboxes and the toolbar buttons at the top, but not when clicking the publish or unpublish column graphics in the list. The problem there seemed to be that the publish/unpublish graphics were going through the Joomla listItemTask() function, which, for whatever reason, was still using the older submitbutton() function (not attached to the Joomla object). This override was pretty simple – I just routed it through to the other:

function submitbutton(task) {
	return Joomla.submitbutton(task);
}

That got things working for me. My ajaxSubmit() callbacks handled the refresh of the list, and there are obviously some app-specific details I’ve left out, but hopefully this helps point someone (or me, later) in the right direction.

/administrator/modules/mod_quickicon

…you’ll see that the whole list is being generated and wrapped in a div with class=”cpanel”. What we want to do is add our own custom icon to the list before this happens. In the helper.php file, see the modQuickIconHelper::getButtons() method for details.

Instead of creating a new admin module, we need to build a custom plug-in that adds additional icons to that list before it is output. Joomla is already doing this in recent versions, and you can find examples here:

/plugins/quickicon

Chances are, these examples are more complicated than you need since they’re using Ajax to check the version/update status of Joomla or your installed extensions. Here is a simplified example plugin:

Download mycustomicon.zip Example Plugin »

Inside the zip archive, see the main plugin file “mycustomicon.php”:

<?php defined('_JEXEC') or die;

class plgQuickiconMycustomicon extends JPlugin
{
    public function onGetIcons($context)
    {
        if (
            $context == $this->params->get('context', 'mod_quickicon')
            && JFactory::getUser()->authorise('core.manage', 'com_content')
        ){
            return array(array(
                'link' => 'index.php?option=com_content',
                'image' => 'header/icon-48-component.png',
                'text' => 'Quickicon Example',
                'id' => 'plg_quickicon_mycustomicon'
            ));
        } else return;
    }
}

We’re hooking to the onGetIcons event, and:

• Check the context and permissions (lines 7 – 9)
• Add our own icon to the list (lines 11 – 16)
• Return null

The “id” value will need to be unique for each icon. For the “image” value, use the relative path from:

/administrator/templates/bluestork/images

(or whichever admin template you’re using). If you’d like to use a custom icon image, enter the absolute path to that image, including “http://” …my first guess was that I could just start the path with a / and Joomla would know that the image path was absolute, but that did not appear to work without the fully qualified http:// address.

See Joomla’s update icons for better examples that make use of language files and what-not.

The solution was simple enough. In my custom JTable file, I added some code to the store method override to check for an empty string (or ’0000-00-00′) in the date field(s), and if found, force back to null. Something like:

public function check()
{
	// force empty date values to null
	if ($this->date_start == '' || $this->date_start == '0000-00-00')
		$this->date_start = null;
	return true;
}

1. Upgraded the Mac machine to newest version (10.7.1 at the time)
2. Make sure printer sharing is enabled on the Mac under System Preferences / Sharing / Printer Sharing
3. Installed the needed print drivers on the Windows machine (in my case, an Epson Stylus NX125)
4. Installed Bonjour Print Services for Windows on the Windows 7 machine
5. Used the Bonjour Printer Wizard in Windows 7 to find the shared Mac printer and set it up (selecting the appropriate driver, installed previously)
6. Made sure the printer status was “ready” (filled an ink cartridge that was complaining about being low)
7. Restarted both machine

After all that, it seems to be working fine.

I did run into an odd bug where, after creating the Bonjour printer in Windows, it could not be deleted from the control panel. This was apparently caused by the @ sign in the printer name. The solution was to go into any application’s print dialog (I used Notepad), select the printer in the list and delete from there. I found that information here:
You cannot remove a printer that has the at sign (@) in its name from a computer that is running Windows 7

/Applications/MAMP/conf/apache/httpd.conf

I noticed that things got moved around, so now there’s an “extra” folder in the same directory as httpd.conf, which has the file “httpd-vhosts.conf”. Presumably, that’s where the virtual hosts now belong, so I grabbed a backup configuration file and pasted my virtual host configurations into httpd-vhosts.conf.

Then, I had to tell the main httpd.conf file to import the included httpd-vhosts.conf file by finding this block around line 525:

#Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf

… and removing the # sign at the beginning to un-comment. After doing that, then re-starting the MAMP servers, everything was back to normal.

Also worth mentioning: I tried to use Time Machine to restore an old version of httpd.conf onto the desktop so I could copy the virtual host configurations for pasting, but for whatever reason, Time Machine kept restoring it as the newest version without the data I needed. I had to manually open my Time Machine backup drive, find the file in the backup archives and drag it to the desktop manually.

Basically, I was using a config.xml file with this:

JToolBarHelper::preferences('com_mycompname');

…and when I loaded the page to test, no button was there. Turns out it was just because I wasn’t logged in as an administrator (I believe it was with a Manager account). After logging out and then back in as admin, all was right with the world.

Override the System Default Layout

The basics of building a custom 404 error page in Joomla are fairly straightforward and can be found here: Custom Error Pages (Joomla!)

Long story short, copy this file:

/templates/system/error.php

…to your active template’s folder:

/templates/(your template)/error.php

To customize your error page(s), you can now make whatever edits you want to the error.php file in your active template folder, since this file will override the system default.

Response Headers (Important!)

It’s important to send the correct response headers so browsers (and search engine crawlers) know that what they are seeing is a 404 error page and not your normal site content. This is easy enough to do by adding a snippet of PHP code:

error->code == '404')
header("HTTP/1.0 404 Not Found");

This code must be placed before HTML output (including white space), so it may be a good idea to insert this snippet minus the tags directly into the PHP block at the top of the error.php after the line:

defined( '_JEXEC' ) or die( 'Restricted access' );

Using Modules and Menus in Custom Error Pages

My first inclination was to just import my main template layout file like:

include dirname(__FILE__) . "/index.php";

…and then use a conditional in the tempalte index.php file to either display an error message or load the normal Component, like:

<?php if (isset($this->error) && $this->error->code == '404'): ?>
<h1>Error 404: Page Not Found</h1>
<?php else: ?>
<jdoc:include type="component" />
<?php endif; ?>

…but unfortunately, not all of the features available in the template’s index.php file are available to the error.php file in Joomla – most notably, the jdoc tags and functions for working with Modules. You could opt to re-work the index.php file to not use any features that error.php does not support, but in my experience, it has been best to duplicate the index.php file and make an alternate version for use with error.php. Otherwise, there are just too many conditional tests and the template file becomes difficult to work with, particularly for someone less familiar with PHP.

I usually end up copying my index.php code into the error.php file, then give it a test run in the browser (by typing in a page address that does not exist in the site) and then fixing whatever PHP error messages come up from trying to use functions and features that are not available. Since this will vary depending on how your template’s index.php file is built, there will be a certain amount of trial-and-error involved. A few likely examples are listed below.

Testing For and Outputting Modules

Code like this will not work in error.php:

<?php if($this->countModules('left')) : ?>
<jdoc:include type="modules" name="left" style="rounded" />
<?php endif; ?>

…since the countModules method is not available and the jdoc tag doesn’t parse. You can still bring Modules into the error page using PHP. Try the following (changing the position and output type as needed):

<?php
foreach (JModuleHelper::getModules('left') as $module)
print(JModuleHelper::renderModule($module, array('style'=>'rounded')));
?>

Head Section Content

The head content import tag will also not work in error.php:

<jdoc:include type="head" />

…so keep in mind that the title tag and an necessary system-imported CSS and JavaScript files will need to be added manually.

Using an Article as 404 Error Message

It is also possible to use an Article for the 404 error message content – this may be useful if you would like to give the end user control over the error page text without them having to edit the error.php file directly. For details, see this page: Creating a Custom 404 Error Page.

Personally, I don’t like that method because it does a redirect for the error page and doesn’t send the expected error page headers. Instead, you might consider using a Custom HTML Module to manage the error page content, then create a position that’s only used in the error.php file (for instance “errormsg”). You can use the PHP method above (under “Testing For and Outputting Modules”) to output the module position into your error page template.

Conclusion

I hope this is useful to others – I will likely be updating this document as I run into other issues. Please post any corrections or questions in the Comments section below.

To get a Layers-based layout to center, we first need to add a wrapper DIV around the whole design. There’s no super-easy way to do this in GoLive’s layout editor, so switch to source view (this will be quick and painless, but it wouldn’t hurt to make a back-up first).

In source view, find the opening <body tag (should be right after the closing </head> tag). We need to add another line after the opening body tag – see arrow in image:

Now we need to add the start tag for a “wrapper” div (to tell the browser what to center with).

Add <div id=”wrapper”> in the new line after the <body> tag to look something like this:

(The indenting isn’t important – GoLive will take care of that). Next, scroll down to the bottom of the page and add a new line just above the closing </body> tag – see arrow in image…

We need to add a closing </div> tag just above the closing </body> tag. There may (or may not) already be a </div> tag just above the </body> tag, but we need to add yet another one. So, we should end up with something like this:

Now we’re finished with source view! Switch back to layout view mode in GoLive and click the stair-step-looking icon at the top left to open the CSS editor:

In the CSS editor, see if you already have a <> element (on the left) named <body>. If so, select that element to edit. If not, add a new CSS <> element (bottom left of css editor window) and name it body:

Select your new body style, select the alignment tag on the right and set the text alignment to “Center” as follows:

Now we’re almost done! We need to add a new ID (#) style and name it “wrapper” as follows:

For the style settings, set the text alignment however you want (usually left)…

Set the left and right margins for your wrapper to “auto”…

…and set the positioning to “relative”. Generally, set the height to “auto” and the width to a little larger than the total of the layout area you’ve already designed (in my example, it’s about 520 pixels). If you aren’t sure, you can either measure in GoLive or do a screen capture of your page in a browser and measure in another program:

If all went well, your wrapper div should now center in the browser window. Keep in mind that the layout will still appear left aligned in GoLive CS’s layout view, so test/preview in your web browser.