We have an irritating problem in Moodle 2.0 dev at the moment.
Since a long time ago, the correct way to link to an icon in Moodle was to do something like $CFG->pixpath . '/iconname.gif'.
Now the correct value for $CFG->pixpath depends on the current theme. And the current theme depends on $COURSE, $USER, .... So, $CFG->pixpath cannot be set up from the start when we do require_once('config.php') - it has to be later.
On the other hand, there is no other core function that we can be sure will be called on every page, after we have all the necessary information, but before $CFG->pixpath is used. Therefore, there is no place where we can reliably initialise $CFG->pixpath.
It is tempting to think that we could initialise it in print_header (or $OUTPUT->header() as it is now). However, that is not the case. We seem to have a lot of code that references $CFG->pixpath before we get to print_header.
I think the best long-term solution is to replace the use of $CFG->pixpath everywhere with a new $OUTPUT->icon(...) function. That would solve the initialisation problem and also let us solve the problem of a theme wanting to override some, but not all of the core icons (or wanting to use .png rather than .gif), in a more elegant way that smartpix.php does. This issue is being discussed in this Themes forum thread. (And there are over 400 references to $CFG->pixpath in core Moodle, so I don't want to start making changes until we have agreed what the right solution is.)
In the mean-time, we have all these errors with $CFG->pixpath being used before it is initialised. If you encounter one of those the way to fix it in the short term is to do
global $OUTPUT;
$OUTPUT->initialise_deprecated_cfg_pixpath();
before the reference to $CFG->pixpath that is giving the error. That will make the problem go away. As you can probabl guess from the function name, this is inteneded to be a short-term solution.
$OUTPUT->icon(...) sounds OK to me! 
Martin ++
aarrrgh, the bloody initialise_deprecated_cfg_pixpath() is breaking everything, the problem is that originally you could safely use $CFG->pixpath after any require_login(), the changes you are making are breaking tons of places.
In 1.9 the theme was known after require_login($course), now you are proposing to set up the theme stuff much much later which is going to break very many places and create some really nasty chicken-egg problems. Is that really necessary?
For now I need to comment out all your initialise_deprecated_cfg_pixpath() and add this into my config.php if I want to continue with my coding
Please let's implement new clever $OUTPUT->icon('/pix/i/iconname') asap. I think it should require only "require_login()"==="theme is known" and should not "start" page output.
I might not understand it properly, but will there be a way to reset current theme in cron scripts? such as when sending mail notification to many users?
In 1.9 the theme was known after require_login($course), now you are proposing to set up the theme stuff much much later which is going to break very many places and create some really nasty chicken-egg problems. Is that really necessary?
For now I need to comment out all your initialise_deprecated_cfg_pixpath() and add this into my config.php if I want to continue with my coding
$CFG->pixpath = $CFG->wwwroot .'/pix';
$CFG->modpixpath = $CFG->wwwroot .'/mod';
Please let's implement new clever $OUTPUT->icon('/pix/i/iconname') asap. I think it should require only "require_login()"==="theme is known" and should not "start" page output.
I might not understand it properly, but will there be a way to reset current theme in cron scripts? such as when sending mail notification to many users?
In the past you could refer to $CFG->pixpath at just about any time, but that did not mean that the code was actually bug free.
I'm sure there are places where there was code that used $CFG->pixpath, and then later code did something that would change the theme, and hence $CFG->pixpath. That would mean that we might use the wrong icons in some places. That is hardly the world's most serious bug, but it is still a bug. And it would be very hard to detect this happening.
At the moment we have gone to the opposite extreme. I have intentionally made the code detect and complain if something goes wrong. That is, if you try to use something before we have enough information to initialise it, or if after the theme has been initialised, you try to change something like $COURSE or $PAGE->category, that the theme depends on. It now throws an exception, hopefully with enough useful information to nail the problem.
At this point in the Moodle 2.0 release cycle, this is probably the right thing to be doing. We should be making the bugs as visible as possible, and then fixing them. It is painful, but better for Moodle in the long run.
The theme is now set up the first time you use $OUTPUT. Therefore, a $OUTPUT->icon_url('i/edit'); will solve the problem. I'll implement that tomorrow morning if no one objects.
"require_login()"==="theme is known" is not possible. Think about course/category.php with the category themes option on.
In cron scripts, where we are preparing content to put into emails for a lot of different users/contexts, we should not be using the $PAGE and $OUTPUT globals, which are related to current HTTP request/CLI script execution. Instead, we should create a separate theme_config and moodle_core_renderer subclass for each required theme (the required theme depends on the forum/user combination) and use those non-global objects.
I'm sure there are places where there was code that used $CFG->pixpath, and then later code did something that would change the theme, and hence $CFG->pixpath. That would mean that we might use the wrong icons in some places. That is hardly the world's most serious bug, but it is still a bug. And it would be very hard to detect this happening.
At the moment we have gone to the opposite extreme. I have intentionally made the code detect and complain if something goes wrong. That is, if you try to use something before we have enough information to initialise it, or if after the theme has been initialised, you try to change something like $COURSE or $PAGE->category, that the theme depends on. It now throws an exception, hopefully with enough useful information to nail the problem.
At this point in the Moodle 2.0 release cycle, this is probably the right thing to be doing. We should be making the bugs as visible as possible, and then fixing them. It is painful, but better for Moodle in the long run.
The theme is now set up the first time you use $OUTPUT. Therefore, a $OUTPUT->icon_url('i/edit'); will solve the problem. I'll implement that tomorrow morning if no one objects.
"require_login()"==="theme is known" is not possible. Think about course/category.php with the category themes option on.
In cron scripts, where we are preparing content to put into emails for a lot of different users/contexts, we should not be using the $PAGE and $OUTPUT globals, which are related to current HTTP request/CLI script execution. Instead, we should create a separate theme_config and moodle_core_renderer subclass for each required theme (the required theme depends on the forum/user combination) and use those non-global objects.
Right, we now have new $OUTPUT methods $OUTPUT->old_icon_url and $OUTPUT->mod_icon_url and
Old code like "$CFG->pixpath/i/course.gif" should be changed to $OUTPUT->old_icon_url('i/course') and code like "$CFG->modpixpath/$mod/icon.gif" should be changed to $OUTPUT->mod_icon_url('icon', $mod).
Development:Migrating your code code to the 2.0 rendering API#.24CFG-.3Epixpath_and_.24CFG-.3Emodpixpath for more details.
The horrible hack that was $OUTPUT->initialise_deprecated_cfg_pixpath(); is gone. Please do not try to use it any more.
I am trying to replace all $CFG->pixpath and $CFG->modpixpathin HEAD. When I started earlier today there were 467. I am down to 162. (Yay! regular expressions.)
Old code like "$CFG->pixpath/i/course.gif" should be changed to $OUTPUT->old_icon_url('i/course') and code like "$CFG->modpixpath/$mod/icon.gif" should be changed to $OUTPUT->mod_icon_url('icon', $mod).
Development:Migrating your code code to the 2.0 rendering API#.24CFG-.3Epixpath_and_.24CFG-.3Emodpixpath for more details.
The horrible hack that was $OUTPUT->initialise_deprecated_cfg_pixpath(); is gone. Please do not try to use it any more.
I am trying to replace all $CFG->pixpath and $CFG->modpixpathin HEAD. When I started earlier today there were 467. I am down to 162. (Yay! regular expressions.)
Is the above method still the one to use? I can't find the API documentation for outputting stuff to the page and the moodle 2 changes pages, if I get my changes working would like to start a proper changes wiki section - as it's been interesting finding out everything I need.
The above post is ancient, and not very helpful any more.
If you want to know the right way to do things now, download the latest 2.0.x, and find an example of some code that looks well-written that does roughly what you want somewhere else in Moodle.