A really big bug in SMF 2.x

[markem]

Hello everyone!  :-)

I downloaded and installed SMF and have been enjoying it quite a bit but I have found a major bug in the program and wanted to post about it.  Here is bug plain and simple:

If you attach a large image to a post and you attempt to upload the post, SMF will - if the image is too large for it - simply toss out everything and put you back at the "start a new topic" entry.  This is a major bug for two reasons:

   1. I was not "Starting a New Topic" - I was "Replying to a comment".  So that is a bug in and of itself.
   2. Even though the image file may be too big - the message was not.  SMF should store the message no matter what AND THEN decide if the image is too large.
       (SMF was not saying anything about the image being too big BTW.  It just dies.  Which is also a bug.)

It is, IMHO, an extremely big NO-NO to throw away the work someone has put in to creating a message.  In my case, I had just spent two hours answering a move in an RPG game I am running.  Which just made me go ARGH!  Mainly because this wasn't the first, second, or third time this has happened - but the fourth time on the same message.  Lucky for me - I had made a copy of the message I was posting.  Unlucky for me, SMF looked like it was going to actually post the message the fourth time so I deleted my temporary file with the message in it.  THEN SMF came back and said "Hey buddy - did you want to start a new topic?"  I just wanted to cry.  At an hour for each of the first three tries and two hours for the fourth (I had received additional requests on this message). I've spent five hours just trying to get a message posted.  I'm going to just forget about uploading the image and concentrate of doing the message.  THEN I will try to get the image posted.

Anyway - those are the bugs.  :-)

[LiroyvH]

If it just dies, i'm pretty sure the issue is with you hitting limits your host imposed; rather than a problem with SMF.

[markem]

Yes.  That is probably true.  Since I set the board up and said I could have up to a 10MB file (and I did set the PHP limits also.  They actually are at 100MB files.) and since the image file is only 4MB - I was not expecting SMF to not honor those settings.

This doesn't remove the two points listed which were 1)Why did SMF dump me into "Let's make a new topic" instead of "Let's reply to the topic again", and 2)Let's save the message even though we can't save the image.

Those are two really big bugs.  SMF should at least save the message first.

Also - my website is set to handle up to 100MB image files too.  (In case you meant Apache.)  I have several websites and I've uploaded a lot of things to all of them.  A few of these images were 50MB-60MB files.  Apache has never barfed on doing them.  Neither has PHP.  So I'm a bit confused why SMF is doing this.  :-/

[markem]

Since I have brought this up, let me make a suggestion on how this should work.

If, instead of using the SUBMIT button a regular button-button was used (I haven't looked to see how SMF is set up) then when the POST, PREVIEW or whatever buttons were clicked on SMF would retain control of what was going on.  So...

<input type="button" value="Post" class="<SMF  Post Button Class>" onclick="javascript:doPost()">

Then you just need

function doPost()
{
   var mypost = $('#thePost').val();
    .
    .
    .
    $.ajax(....);
}

So you set the button to call a javascript function that gets the post and sends it via AJAX back to the server so the server posts it.  Then you do a second AJAX call after the SUCCESS option has triggered to get the image.  In this way you never lose a post and you still get the image afterwards.  Kind of like this:

Code Select Expand

////////////////////////////////////////////////////////////////////////////////
// Function: makeOpts().  Get the parameters and make an option line.
////////////////////////////////////////////////////////////////////////////////
f.makeOpts = function(id){
var p = f.getParams();
var s = "";

s = "file=" + id;
for( var k in p ){
if( p.hasOwnProperty(k) ){
s = s + "&" + k + "=" + p[k];
}
}

return s;
}
////////////////////////////////////////////////////////////////////////////////
// Function: loadPage(id). If a page hasn't been loaded - then load it.
////////////////////////////////////////////////////////////////////////////////
f.loadPage = function(id){
if( f.pages.indexOf(id+'|') < 0 ){
f.pages = f.pages + id + "|";
f.send( f.makeOpts(id) );
}
else {
id = f.checkID( id );
f.clearPages();
f.showPage( id );
}
}


Where I get the parameters and then change them into options and send them back to the server for processing.  Same thing with a post. Hopefully that is somewhat clear.  I'm looking for my latest stuff.  Nothing like losing it when you need it.  :-P

[markem]

By the way, got it to post.  Changed it from PNG at 4MB to JPG at 702KB and it posted.  Rechecked my settings - still at 10MB.

[Arantor]

The symptoms described do not match what the code does, I'm afraid.

If SMF's limits are hit, you get an error message of such for which you then press back and the editor content at least should be retained (and this has been the case for years in all major browsers)

Since no mention of receiving an SMF error, I would be more inclined to assume it is not SMF's limits being hit but something related to your host's mod_security configuration which would assess the request prior to SMF receiving it. Perhaps dumping the POST body for being oversized (which would explain the symptoms you DO mention)

AJAX is not a viable solution without reworking major parts of SMF, nor do I have any confidence it would truly solve your problem anyway. It certainly couldn't be a core feature of SMF because there is a non-trivial section of the userbase that would have difficulty using such a thing (be that for technical or usability reasons) and in fact sending the entire file via AJAX subjects you to all the same limits you'd actually have anyway. The only *real* solution to sending huge files is to chunk them prior to sending, requiring either the File API or a Flash based solution (but you run into problems *there* because Flash requires the entire file be memory-mapped prior to sending, which for multi-GB files can be problematic) but even that requires extremely specialised handling on the server end, and is arguably unsuited to SMF core in any case.

This also doesn't deal with the small problem of *sending* the file. SMF will struggle to send a 100MB file on most configurations - even a multi-MB file can be troublesome - because the entire process of sending is still dependant on having PHP's own limits not expire (including the time limit). If you've got mod_xsendfile installed (or using lighttpd) there are ways to mitigate that and divest all actual sending off to Apache rather than tying up the PHP instance to do it.

You mention upload limits, I have no doubt you have adjusted the maximum upload size but I'm somewhat more wary of you having correctly updated the maximum post size as in the one sent as part of the POST message. There is a reason that the max upload size is set to 2M by default but the max post size is 8M by default. I recommend at least 3x the max upload size for max post size, 4x if you can manage it, if nothing else because some conditions will mandate base64 encoding of the content before sending. This may also be the cause of your problem.