You know for the html pages thing someone could just easily intergrate http://tinymce.moxiecode.com/example_fu … ample=true

The rest of the work to be done is pretty simple, 'cept maybe the wizard.

I would do it but I've no will to (money isn't an incentive) and besides that I'm busy with my own software. Maybe in the future tho....

2

(19 replies, posted in Feature requests)

Oh, I see.

However, the 90 secs was an example, and ideally it would be an option. Also, it's trivial to make image.php send a cache header to the browser

But so ok, I see no one's probably going to be willing to make this core functionality but would be it be possible to insert a few text fields into the user pref's page without touching any exisintg files?

oh and oops, soory but see above edit

Rickard wrote:

Thanks for bringing this up again. I am aware that it isn't properly fixed and I was going to have a look at it. However, just putting CRLF line breaks everywhere won't work. The problem is that, most of the time, mail() isn't talking to an SMTP server, it's talking to a command line program running on the server. That command line program expects linebreaks that are native to the operating system on which it is running. Have a look at PHP Bug #15841.

Yes I've seen the bug but forgive me if I'm wrong but don't you use your own socket code to transmit emails if an smtp server is given? mail() should only be being used if that's blank, and yes, in that case it would be neccesary to alter the line breaks

edit: a ha, I see what's going on. you use a generic wrapper that then either calls mail() or smtp_mail(). prehaps the following...?

        // Detect what linebreak we should use for the headers
        if (strtoupper(substr(PHP_OS, 0, 3) == 'WIN'))
                $eol = "\r\n";
        else if (strtoupper(substr(PHP_OS, 0, 3) == 'MAC'))
                $eol = "\r";
        else
                $eol = "\n";

        $headers = 'From: '.$from.$eol.'Date: '.date('r').$eol.'MIME-Version: 1.0'.$eol.'Content-transfer-encoding: 8bit'.$eol.'Content-type: text/plain; c

        // Make sure all linebreaks are CRLF in message
        $message = str_replace("\n", "\r\n", pun_linebreaks($message));

        if ($pun_config['o_smtp_host'] != '')
                smtp_mail($to, $subject, $message, $headers);
        else
                mail($to, $subject, $message, $headers);

to

        $eol = "\r\n";
        $headers = 'From: '.$from.$eol.'Date: '.date('r').$eol.'MIME-Version: 1.0'.$eol.'Content-transfer-encoding: 8bit'.$eol.'Content-type: text/plain; c

        // Make sure all linebreaks are CRLF in message
        $message = str_replace("\n", "\r\n", pun_linebreaks($message));

        if ($pun_config['o_smtp_host'] != '')
                smtp_mail($to, $subject, $message, $headers);
        else {
                // Detect what linebreak we should use for the headers.
                if (strtoupper(substr(PHP_OS, 0, 3) == 'MAC'))
                        $eol = "\r";
                else if (strtoupper(substr(PHP_OS, 0, 3) != 'WIN'))
                        $eol = "\n";

                $headers = str_replace("\r\n", $eol, pun_linebreaks($headers));

                mail($to, $subject, $message, $headers);
        }

5

(19 replies, posted in Feature requests)

I wouldn't really call it leeching. All you're doing is instead of letting the client make their own request for the image, you do it for them. In fact you could save the other host bandwidth by at least cache'ing for 90 secs or something (depending on board activity).

As for people with dynamic sigs, I didn't really think of that but I presonally don't see the point of those so at least in my implentation, I wouldn't care. A short cache time would stop them even noticing probly, much less caring.

And so what does this function do that you speak of? I didn't catch what you was refering to when you said it does "exactly that".

6

(19 replies, posted in Feature requests)

Bit late to join this topic I know, but I too would like to see this feature implemented.

Anyway, there's an easy solution. You make a wrapper, say image.php, that accepts a userid as a variable (image.php?uid=123) and then you simply query the databse for the user, fetch the url specified for their avatar then within image.php you download the image, check it's size etc and if all is well, you display it.
Only thing is this adds the extra bandwidth usage of the server having to retrieve the image, then send it to the client whereas a direct url would have it downloaded from the remote server. Would make a nice option in the CP though

But if no one on the core team is willing to do this then....
Would this be possible with a mod? I've not played with punbb's mod system but is it possible to manipulate the user "Personality" pages? so I could insert a text field or 2. also is it possible for a mod to add extra options to the control panel? (note, by mod I mean using an API, not by patching files)
If there's a decent mod API I'd be happy modding this.

PS, you could make it so the first time a url is is specified it's downloaded and cache'd locally.

Ok, firstly I'm aware this has been brought up before and supposidly "fixed" but the issue is still present in 1.2.7.

I've looked at the source and fixed it for myself but I'm wondering why it is you attempt to use different line breaks for different OS'? (lines 79-84 of include/email.php)

Firstly, the server PHP is running on in most cases will not be the same as the SMTP server, so they way it is determined could produce bad results. For example, if indeed it did matter that for instance mac MTA's only accepted "\r", and you were using a win php server for punbb but set it to use the mac as smtp server. You'd end up with "\r\n" being sent to the mac.

Secondly, any standards compliant MTA will allow "\r\n" breaks in headers over SMTP sessions (different story to it being piped through a CLI program, as with mail() on *nix), so I don't see why not just make all headers end with "\r\n" as done with the main message body.

-- Tx

P.S. The reason qmail rejects this is becasue it's fully standards compliant (painfully so according to some) and doesn't even bother to fix invalid input (it easily could) out of principal. Standards are here to be used, not ignored.... just an answer since you seem genuinly baffled as to why in previous posts

P.P.S. See section 3.1.2 of RFC822 if you need confirmation of header syntax.