Images in posts.

[CrYpTiC_MauleR]

Actually, realizing how much of a pain in the neck it will be for Mentors to have to optimize every image, I would offer the following (admittedly pedantic) amendment:

Users upload, are asked to optimize themselves to save Mentors the trouble, then mentors see the uploaded image, which they can optimize if need be.

I agree, the less work we create for the mentors the less this site will turn chaotic with so much dumped on mentors.

[Huntress]

Should there not also be some way to notify Mentors that an image has been uploaded for approval?

[Zyloch]

There could be an image control section of the site where mentors of a particular area of expertise could view the images submitted and whether they have been optimized or not by another mentor. If we want, we can have an email sent to the mentor as well (that they could sign up for). I personally have Gmail so it's pretty easy for me to just sort all possible image emails into a label.

Furthermore, expanding on Nick's idea with the self-uploading with mentors having a choice of optimizaton, we could limit images to a certain filesize. If it is above that filesize, we can either deny the image or temporarily upload for mentor optimization.

[nicholassolutions]

>>>Should there not also be some way to notify Mentors that an image has been uploaded for approval?<<<<
Of course -- it will be just like posting a comment as text (and of course only the mentor(s) will get the initial post for approval).

>>>mage control section of the site where mentors of a particular area of expertise could view the images....<<<<
Good idea, although Mentors may prefer not to have others monkeying in their threads...that's just something we'll have to feel out though.

>>>could limit images to a certain filesize.<<<<
you should do this whenever you write a form, it's just part of good input validation =) But we'll obviously make the limit pretty large since you can optimize quite a bit.

But these are just technical details =)

[COBOLdinosaur]

But these are just technical details

Exactly.

The proposal is about managing the images.  It limits them and with the ammendment put control of it in the hands of the mentors.  How it is implement, or what the options are being loaded int the discussion just muddies things.

The proposal is a about the What... what to do about images.  Trying to resolve the how is just going to result in an inability to determine the what.  Once that is nailed down then we can debate experiment and eventually determine how to implement the policy.

[Lobzuki]

By the way, this is probably better off in PHP, but since I have your attention:
if we ever need to use imagemagick, we may be able to do it without turning off safemode using this: http://pecl.php.net/package/imagick

How about a little script like what Photobucket uses, where all uploaded images are reduced in size automatically (if required) to a max of so-and-so pixels?  That would ensure that files are not too big and it's also prevent the posting of images that force the viewer to scroll horizontally (like some of the stuff I post).

[pinaldave]

I have not complete thread but went over few things.

I have opinion about using Quotes.

There are two ways to use Quotes.

1) Click on quotes and white box is with quotes. I like it but it is not good when it is matter of programming. Because sometime user have asked three question and I want to answer them individually; in that case, it is difficult to use those quotes.

2) use >>> when the quotes is selected and fill up the textarea with that.
Like quotes comes with >>>
Now I can easily modify it without any html skills or understanding of TAG.
Well, there would not be race for points so nobody is in hurry.
I think I like using >> which will make gives whole page uniform look.

[Anonymous]

I think any image uploaded MUST be validated by the appropriate mentor group.

There should be a mechanism of response so an image can be rejected, ask to be amended, accepted.

Once accepted, only a thumbnail, with a link to a fuller image, should be embedded within the consultation (which opens a new window). The URL will NOT be the image but a script which presents the appropriate image from a post. I would recommend only 1 image per post. If multiple images are required, then multiple posts. Maybe.

A post with an unauthorised image will display a message saying that the image is awaiting authorisation (or something nicer than that maybe) OR a very low res monochrome thumbnail version - maybe - I prefer the message though.

Images will be scaled to a fixed size. I would suggest that an image will be shrunk to 800x600 if larger. Aspect ratio should be maintained.

Images wider or taller will be shrunk to fit within the 800x600.

As part of the authorising process, the image MAY be allowed through without  scaling, though I can see only very few instances where this may be appropriate. JPEG/GIF/PNGs would be supported, but any animated GIFs would be rejected (not sure on how to detect these - yet).

Thumbnails and images would be stored in the filesystem. Thumbnails should be scaled to within 80x60 (maintaining aspect ratio again).


I think initially, we are only looking for inappropriate content. By this I mean, I don't think we want to see pictures of tits and arse on the site. (I put that bit in so I could type tits and arse twice - he he  :D )

Processing of the images (shrinking and thumbnailing) can take place as part of the image upload.

Authorisation could be handled en-mass. Say 10 images and their thumbnails at a time with a simple option list for each image (Accept, Please replace with a smaller image, Please replace with appropriate content, Rejected - innappropriate content) sort of thing.

[Anonymous]

... The proposal is a about the What... what to do about images.  Trying to resolve the how is just going to result in an inability to determine the what.  Once that is nailed down then we can debate experiment and eventually determine how to implement the policy.

So.

Images (or their thumbnails) in posts SHOULD be allowed.

Links to images should NOT be allowed OR have an obvious alert saying that ERT can in no way be responsible for the content. Maybe this alert is only shown for seekers posting images. As you improve your standing within ERT, this alert becomes less important. Obviously, this external_link_appropriateness flag can be enabled by a moderator (not a mentor) at a later stage.

[COBOLdinosaur]

RQ,

I think the limited use is going to win the vote.  That being the case you like the ideal one to right the definitive proposal for handling the limited ones.  Probably a lot of you prvious post could be used as the basis for a FAQ specific to image posting policy on te site.  

Whatever we end up doing is going to need documentation to avoid misunderstanding.

[Anonymous]

Sure.

[Anonymous]

I am a programmer, so a lot of this is probably for the programmers here too.

The following proposal is to describe how images from seekers will be handled, the mechanism of approval and rejection of the image as well as some security issues on retrieving the images.

BASIC

• Images will be uploaded from a user and logged within the system.
• Large images will be scaled to a maximum of 800x600.
• The image's aspect ratio will be maintained.
• Smaller images will not be scaled.
• Images whose aspect ratio is adverse MAY be rejected.
• Thumbnails will be produced.
• lowsrc variants could also be produced - to what benefit though?
• The appropriate mentor group will periodically examine the uploaded images and approve them for adding to the consultation.
• Rejected images are simply deleted.
• When an image is rejected the post will be deleted and a private message generated.
• When an image is approved, the thumbnail will be embedded in the post with a link to the larger scaled image.
• Session logging will be used to restrict what images are allowed to be seen.

DETAILED

• Initially, uploading an image is the complete post. No additional message. Multiple images could also be allowed and multiple posts created automatically.
• Images will be validated to make sure they are in fact images and not MP3 files, PHP code, movies, etc.
• Image's filesize may be limited ONCE the image has been scaled. An image being uploaded at 1280x1024 MAY be 100K, once scaled it may be 80K. A limit of 90K should not reject this image automatically.
• Images will be logged in a database table and moved to a holding area outside of the webroot with a unique name. The unique name will be provided as part of the logging. This will stop images being uploaded with the same name.
  Images will be logged in a database table and moved to a holding area outside of the webroot with a unique name. A unique name will be provided as part of the logging. This will stop images being uploaded with the same name.
  
• A thumbnail will be produced of the image. This will be at maximum 80x60. This maintains the aspect ratio of 800x600. The lowsrc/monochrome version can also be produced at the same time if required.
  A thumbnail will be produced of the image. This will be at maximum 80x60. This maintains the aspect ratio of 800x600. The lowsrc/monochrome version can also be produced at the same time if required. If the file has been uploaded previously (as identified by the SHA1 and the presence of the image/thumbnails), then the previous saved thumbnails will be used and no further generation will be necessary.
  
• The image's unique name will be generated from the SHA1 hash of the image. This will trap the same image being loaded twice but with a different names (thank you CM). The hash will be saved in the log. The hash should never be visible to the end user.
• For internal housekeeping and stats generation purposes, the image uploader will be responsible for determining the number of images uploaded/approved/rejected for each of the mentoring arenas and saving this information into a file. Ideally this would be in a simple PHP array in an include file. Access to the include file will use by via a mkdir() semaphore lock which will exist for the duration of the file manipulation/access.
• Mentors will be able to see how many images are awaiting approval, currently being approved, have been rejected and have been approved. Further statistics on diskspace and aged analysis could be provided. This information could be part of the header for each mentoring arena.
• A mentor will be able to choose to view any of the 3 states of images (uploaded, approved, rejected).
• When a mentor chooses to view images, they will be given a page of images and these will be locked for 10 minutes. The lock_expiry information will be part of the table logging the images. A mentor will only be able to approve images which are part of their mentoring arenas. When viewing the uploaded images, they will be given the oldest first. When viewing the approved or rejected images, they will be given the newest first.
• The approving process will show the scaled image and the thumbnail. At this stage it could be possible to expand the approval process to be able to add specific image manipulation to assist in improving the image.
• The mentor will either approve or reject the image. A list of suitable rejection reasons will be available along with the option of entering a short "other" message. As much as possible, the supplied reasons should be used.
• A rejected image will cause a private message to be sent to the seeker saying that the image was rejected and for what reason. The original post will also be removed. The database will be updated with the mentor's id, the datetime and the result of the approval process. The original image will remain for 30 days, allowing for other mentors to approve the image.
  A rejected image will cause a private message to be sent to the seeker saying that the image was rejected and for what reason. The original post will also be removed. The database will be updated with the mentor's id, the datetime and the result of the approval process. The original image will remain for 30 days, allowing for other mentors to approve the image. If the image's SHA1 exists in multiple posts, then only when there is a single SHA1 usage will the original image and the thumbnails be deleted.
  
• When altering a previous mentor's decision, it may be necessary to create a new thread in the mentor's private place and have the mentor changing the decision to document why.
• A mechanism may be required to allow a seeker to have the decision to reject an image re-examined. As this site is a democratic site, this process may be necessary.
• An approved image will be logged in the same way as a rejected one. The original post will be removed and a new one inserted into the thread. This new post will be logged against the image and the post will contain a link to a image viewer URL.
• To stop people from surfing the images, when a database is investigated and image URLS are seen as part of the data (the image table will contain the post id, so a simple left outer join of the post to the image is required here), the image ids will be logged in the session. When the image viewer page responds it will examine the image ids within the session to confirm their validity. Any image request which is invalid will result in a standard image apology - "Sorry, but the requested image could not be found at this time. Please try again later". This list of image ids should be destroyed at the start of every page request.

PROGRAMMING
This is just some ideas and notes.

• Image uploading will be provided by using the normal HTML file upload method and as such the PHP developers will be expecting $_FILES to be populated correctly.
• The uploaded file (or files) will be validated to make sure they are actually images. Normally getimagesize would be enough as this does not require any additional libraries. NOTE: getimagesize will return a warning if the file is NOT an image, so @getimagesize() is preferred and test for False.
• Images will be moved from the file upload directory to an appropriate, private (i.e. outside of webroot) image directory. PHP: move_uploaded_file(). As part of this process, a unique name will be allocated. This name will best come from the DB as the key to the file when the image is logged.
• The image uploader will automatically remove all rejected images and posts that are 30 days old.

NOTE/OFF-TOPIC: I have found that with some servers, if the file upload limit of PHP is greater than that of the web server, no page is returned when an uploaded file's size reaches the lower server limit. It is worth checking what the file upload limit for the server is before setting the limit in PHP.

[COBOLdinosaur]

I have asked the host tech support about the limit.  I will post the response when they get back to me.

[CrYpTiC_MauleR]

Images will be validated to make sure they are in fact images and not MP3 files, PHP code, movies, etc.

Images will be logged in a database table and moved to a holding area outside of the webroot with a unique name. The unique name will be provided as part of the logging. This will stop images being uploaded with the same name.

You can verify an image is in fact an image by using getimagesize(), but all images must be run through an anti-virus though, because there are vulns in PHP modules, and images can contain viruses due to problems in image software on operating systems. Most notable one is the gd+ buffer vuln for MS. This is to ensure that a user wont upload an image that will cause buffer overflow in a vuln visitor comp and give them a virus.

As for second quote, getting the SHA1 of the image file should suffice in giving them a unique name.

[Anonymous]

As for second quote, getting the SHA1 of the image file should suffice in giving them a unique name.

As the files are being logged in a DB, the row's uniqueid/identity column will be enough. No need for any additional file processing.

getimagesize will return a warning if the file is NOT an image. So use @getimagesize() and check for False to known if the image is valid.

e.g.

Code:

<?php
/*
isValidImage - Determines if a string is a valid image file.

The type of images accepted is automatically limited to GIF, JPG and PNG - See PHP Manual - getimagesize().

An array of strings can be supplied instead of a single string.

The results will depend upon the type of the first parameter.

If a string is supplied, the result will be False if the string is not a valid image otherwse the array returned by getimagesize is the result.

If an array is supplied, the result will be an array whose key is the supplied string and the value the result of isValidImage().
*/
function isValidImage($mFilename = '', $aLimitImageTypes = array(IMAGETYPE_GIF, IMAGETYPE_JPEG, IMAGETYPE_PNG))
{
// Start with the image NOT being valid.
$mResult = False;

// Has a string been supplied.
if (is_string($mFilename) === True)
{
// Does the string actually contain something?
if (strlen($mFilename) > 0)
{
// Does the string contain a valid filename?
if (file_exists($mFilename) === True)
{
// See if the file is a valid image.
$mResult = @getimagesize($mFilename);

// Are we limiting the type of images of valid images?
if ((count($aLimitImageTypes) > 0) && ($mResult !== False))
{
// Reject unwanted image types. Use the
if (in_array($mResult[2], $aLimitImageTypes) === False)
{
// Filename is NOT a valid image.
$mResult = False;
}
}
}
}
}

// Has an array of images been supplied?
if (is_array($mFilename) === True)
{
// Start with an empty result set.
$mResult = array();

// Iterator the array of supplied filenames.
foreach($mFilename as $sFilename)
{
// Validate the filename as an image and store the results.
$mResult[$sFilename] = isValidImage($sFilename, $aLimitImageTypes);
}
}

// Return the result.
return $mResult;
}

?>