IP.Downloads 2.5 Dev Update: File Submissions

IP.Downloads features a robust and powerful file submission process, allowing your users to quickly and easily upload files to your site and configure them to the specifications your site has set. Users can upload multiple files and multiple screenshots, using either the traditional uploader or the flash uploader; you can configure custom fields for users to populate, and even require them to fill in the fields; versioning is handled automatically, if enabled, and changelogs are fully supported. IP.Downloads provides much of the functionality you would ever need in a download manager out of the box, and allows you to extend this functionality as needed on a per-site basis.

For IP.Downloads 2.5, we have improved some aspects of the file submission process, added some new features, and extended how the submissions are presented in some areas. Read on for further information on changes you can expect to see in the next release of IP.Downloads.


Tagging

I suppose I could end this section with "'nuff said", but for those of you looking for the details, we have implemented full tagging support in IP.Downloads 2.5. You can disable tagging on a per-category basis, and the system supports the pre-defined tagging system (with the ability to configure pre-defined tags on a per-category basis if you wish). You can utilize prefixes and disable prefixes on a per-category basis as well. When submitting a new file (or editing an existing one), you will be presented with the standard tagging interface as you would when submitting a topic, and the interface adapts based on how you have configured your tagging system as a whole (i.e. if you use pre-defined tags, the user will be presented with a dynamic select box to choose from the list of available tags).

As mentioned, prefixes are supported, and will be highlighted before the file name (just like a prefix in the forums will show before the topic title). Tags are searchable through the global search system, and tags are shown where relevant (search results, category listings, and the file view page). Basically, all aspects of the tagging system available through the core framework have been incorporated into IP.Downloads, allowing you to configure the system to suit the needs of your site.




Enhanced uploader support

IP.Downloads supports the use of both the traditional uploader and the advanced flash uploader. The traditional uploader requires you to select a file, hit the 'Attach file' button, and then proceed to select more files or continue with the form submission. The flash uploader will allow you to select multiple files at once, and will upload them automatically once you have confirmed your selection. In IP.Board 3.2, we removed the ability to configure your uploader preference from the user control panel, deferring to the more intuitive inline option available on posting forms throughout IP.Board. When you are replying to or starting a new topic, you can change your uploader type right on the submission form (if you have the ability to upload attachments). This is a more logical way for users to set their preference, but a problem presented itself with the setting removal in the User Control Panel - IP.Downloads did not provide this same inline switching capability, so if a user decided he needed to use a different uploader type, he would be required to visit the forums, click to start a new topic, change his preference from here, and then return to his file submission form to continue.

We have added the ability to change your uploader preference right from the IP.Downloads 2.5 submission form, allowing your users to more intuitively utilize and configure the uploading feature without having to leave the page.



When you are using the traditional uploader, as mentioned above, you must click the 'Attach file' button to perform the actual file upload. Many users not familiar with the interface would often select a file and forget to click this button, proceeding to click the submit button at the end of the form before actually uploading a file. The end result is that the user sees an error message on the screen advising them that they did not upload a file, and they have to reselect the file and click upload again after the page has finished loading.

With IP.Downloads 2.5, we have added a check to the form submission process to verify at least one file was uploaded before allowing the submission to continue. If no files have been uploaded, the user will be taken to the top of the page and a message will be shown to alert them that no files have been uploaded. We believe this simple enhancement will help users better understand the interface, save time for users who forgot to upload a file, and make the overall submission process clearer, particularly for newer users not familiar with the software.


Version numbers

IP.Downloads supports version numbering in the submission and editing processes, allowing your users to upload new versions of their file and specify the version number when doing so. The version number is then shown on the file display page along with the file name, so users can see right away what version of the file they are looking at.

We have decided to expand version number support to other areas of the software for consistency. Version numbers will now be shown everywhere the file name is shown - search results, the download manager index page, category listings, and so on. By providing this information to users before clicking through to the file, users can be better informed before visiting a file if it is of interest to them, or if it has been updated since the last time they visited. You can see the version "1.0" in the tagging screenshot above, for example.


Screenshot efficiency

IP.Downloads presently processes all screenshot requests through a PHP backend handler, allowing it to handle many of the various configurations possible with the software. If you store screenshots on a remote FTP server, or in the database, or outside of the web root, or if you allow linked screenshots, IP.Downloads needs to take all of these various possibilities into account and present the user with the same result regardless of how the image is stored. This works well, but routing all image requests through a PHP handler increases the overhead needed to show the user a simple image, and is not necessary for the most common configurations - screenshots stored on disk in a web accessible folder.

We have added a new setting to IP.Downloads 2.5 to allow you to configure your screenshot URL in the ACP. When you configure your screenshot URL, and the image is a locally stored file and exists in the configured upload folder, the screenshot will be loaded directly from the server, instead of served through a PHP script. This might sound like a very minor change on the surface, but it has tremendous resource ramifications, and will benefit the vast majority of IP.Download installations that use a common setup as described above. Further to this - you can configure your screenshot URL as a CDN URL, allowing your screenshots to be stored in a CDN and served to users from the CDN.

To make use of this feature, again, you need to store your files on disk, and screenshots (only) need to be stored in a web-accessible folder. You can move your screenshots folder to your web root and update your ACP configuration if you are storing them outside of the web root directory presently, allowing you to make use of this useful change when it becomes available.

Additionally, linked images will no longer be run through the PHP handler. While this means that linked images will not display a watermark or copyright stamp, if configured, and the remote images will not be proportionately resized, it resolves many miscellaneous resource considerations that apply to the current implementation: bandwidth is saved for you both by eliminating the image being downloaded to your server and by not serving it from your server to the user, linked images are no longer handled through a PHP handler, and linked images are no longer dynamically resized upon request (image processing is one of the most resource-intensive processes with PHP). This results in a much more efficient handling of linked screenshots.

Note that the following will still be served through a PHP handler:

• Screenshots stored on a remote FTP server
• Screenshots stored in the database
• Screenshots stored in a folder that is not web-accessible
• Full-sized screenshots, as we need to apply the copyright stamp or watermark if configured (and cannot apply this to the actual image file, in case you wish to rebuild thumbnails later, or change your watermark image, etc.)