PostNuke

The only thing that needs work is the Content-type which depends on version of excel. Anyway here it is:
function exportsub($uname)
{
global $uname, $dbconn, $pntable, $admin;
Header("Content-type: Excel.sheet");
Header("Content-Disposition: filename=$uname.csv");

$column = &$pntable['whatever_column'];
$result = $dbconn->Execute("SELECT $column[whatever], $column[whatever2] FROM $pntable[whatever]");
while(list($whatever,$whatever2) = $result->fields) {
print"$whatever,$whatever2n";

$result->MoveNext();
}
exit;
}

Let me know if yall use it. I'm using it for the export of subcontractor and cost control information. Works good.
builder@biltright.com

All the selected form tag that has textarea for editing, replace it with a function call, say

OpenEditorForm( $browser, $os, $form_name, $action, $method, $input_names_separated_by_comma, $misc_para);

Then for those input textarea tag for actual editing, replace it with another function call, say

PutEditor( $browser, $os, $col, $row, $input_name, $input_value );

Then for the end of form tag, just to be consistent, replace it with yet another function call, say

CloseEditorForm();

These functions are defined by module namely, for example, "WYSIWYG".

In OpenEditorForm, one will create "different" textarea for different browser, e.g. different Javascript, IFrame for IE, etc.., so there is room for creativity. But the key is the input_names which is basically used for associating individual input text area with javascript functions, or better yet dynamically generate javascript functions (but bear in mind it may impose performance issues.)

In PutEditor, those names previously defined in OpenEditorForm() will invoke whatever Javascript you have defined plus all the dimension needed for the textarea or IFrame (if you prefer IE only solution).

You may want to use DOM to manipulate the control of textarea along with mouse click on different areas on the "graphic menu bar".

This approach allow a whole new set of cool development for WYSIWYG editor plug-in and the rest of the open source community can have more choices and of course the freedom to choose which editor they want to use without a lot of hassle.

Just my two cents.

it would be nice if we could all write code that assumes postnuke sites could get very large. one obvious place this matters is to make sure anything that displays a "list" has a "forward" button to go ahead to further results, rather than just assuming there will only be a limited number of results, or forcing there to be a limited number of results with LIMIT in the sql query.

any other places where scalability is an issue?

anyone agree/ disagree with me?

Having no knowledge of other PHP projects out there I have installed and currently still running PHP Nuke on my server. PHP Nuke was the only PHP Modular web system I have ever been exposed first hand to, so there was no thought of looking for others.
I'm having as of yet no problems either. But mainly because I haven't found that "thing" I want to change in it yet either. But already I can tell it would be a nightmare to make alterations to PHP Nuke due to its static hard coded nature. I have read modules describing how if you want thier module to work in version x.x you have to do a search and replace in multiple files.
As a professional developer though I will say one thing. W3C is cute and maybe prestigous but who cares. If IE and Netscape are happy than its compliant. The only added benefit even though it doesn't always hold true is that W3C HTML should remain true and consistant in browsers for a longer time period. For a script system like PHP Nuke and Post Nuke this extra grace period should give you the ample amount of time to get scripts up to par with current popular browser standards. For static html page writers the only thing they need to worry about is does their html work for 90%+ of the web users.
I see in the near future PHP Nuke will be falling behind alot in this department with the way it is designed.

Although I'm not going to remove PHP Nuke just yet (I just finished installing and configuring and i'm too lazy to start over.) I can see in the near future I probably will be removing it and installing Post Nuke when Post Nuke hits that 1.0 version or I get completly burned by PHP Nuke which ever happens sooner.
Your concepts and layout of code seems to be right on target.
I just hope you guys don't get into that popularity contest syndrome that usually spells disaster for projects.

Anyways i'm going to be watching Post Nuke site and keeping track of whats going on. So far everything sounds like a real positive step in the right direction.
Keep up the good work guys!

In the DL section of Postnuke.com: PN hacks the first dl is called UCD_download.tar.gz.
It's a hack allright but WHAT FOR ?
Is it for 0.64, for .701 .702 or for windows 3425 ?
Noone knows and noone could know !!
Would it be to much to ask from all people releasing downloadable archives to name the files much more clearer? For example:
packname.packversion.pnversion.extension
in the above example would be:
UCD_downloads.0.064.tar.gz

I am sure others will agree with me
Please take this into consideration, make it a requirement and make a public announcement .
I am sure that the procedure will be adopted by everyone in a short while and it will save everyone a lot of time and troubles.

This improvment will make the PN along with developer products more accesible and easy to be installed.

Thank you and congrats from Romania on a very well done job.