Jump to content


support topics not always created

when adding new download topics are not always created, and if they are not trying to do it from acp fails too.
it seems to happen mostly with zip/rar/7z files or with multiple files, if just a single pdf or something it works usually.
the upload/download itself is fine, just no topic.

Status: Fixed
Version: 2.5.1
Fixed In: 2.5.2


Please submit a ticket. This almost definitely means that the classPost API is throwing an error (perhaps your site doesn't allow dynamic URLs and you are including screenshots with the topics) but that is masked.
ok I will do this today.
fwiw dynamic urls has always been turned off,
it is related to screenshots, preparing ticket momentarily
ticket 809378 filed
if version control turned on, downloads with screenshots do NOT create topic.
if version control turned OFF it all works fine.
I have done the whole disabling/removing hooks thing, was not it.
only version control causes this.
I have version control enabled and my support topics are still created. I can't find any reason that would be the case. I presume your ticket is still open?
yes it is,
and the above was actually posted wrong spot.
had ticket and this open in tabs, thought I was replying to ticket.
with version off it helps but is not 100%
with no screenshots it always works though.
Ryan Ashbrook
Jul 17 2012 07:04 PM
Updating Status to: Unconfirmed

The problem is IDM isn't sending enough information to the Topics Library in IDM when adding an item. Specifically, when it's passed to topicsLibrary::sortTopics().

All of the data that is in the downloads_file_records table is not being sent in so when downloadsFunctions::returnScrenshotUrl() is called using the same data, it's sending back a dynamic URL, because this conditional does not come back true:

if( $this->settings['idm_screenshot_url'] AND $thumb AND $file['record_storagetype'] == 'disk' )

Specifically, $file['record_storagetype'] is never set when it's passed to the method. When the post content is passed to the Posts Class, it fails because the URL for the image is in this format:


Which fails the Valid Image Extension setting for posts.

That's the problem with this particular scenario, however there is an additional problem... if an admin does NOT have the URL to Screenshots setting set, then the system will always return a dynamic URL, and that will fail the valid image extensions check as well. So, topics would never get posted regardless of whether or not the correct data was being passed.

I sent the ticket up for you to take a look. His site let's you reproduce relatively easily.
yeah, what he said :)
leaving settings as they are for now in case you need to look more.
Updating Fixed In to: 0

Yes, when dynamic image urls are used, ".php" has to be added as a valid postable image extension. That has been the case always.

I can look into the data to build the direct URL not being passed though, as that nets us resource improvements.
I have dynamic turned off but would adding .php fix this for interim?
fwiw adding php DOES seem to fix this even with dynamic off
Ryan Ashbrook
Jul 18 2012 02:54 PM
Yes, it will.
Huh. Before if you didn't add PHP as an allowed image extension, the image links simply wouldn't work in the generated posts.

Any specific reason this was changed?
I have the same issue on a new upgrade (from 2.3.6).

My site relies entirely on uploads/downloads and support topics being created.

Adding PHP to the allowable image formats works, but isn't that a huge security risk?

Has this had any recent attention as far as it being confirmed/imagined/denied and/or on the 'to do' list?

No, it's not a security risk. I can set up a PHP file on my server, call it a .jpg and use a .htaccess file to simply execute the file as PHP (which it is in this case).

A remote PHP file can't really do any harm to YOUR server. It doesn't execute in the context of your site.
And if it's not remote?

We have image hosting on our server to compliment our board.
Updating Status to: Confirmed - General

well, same issue, I do not use option to post screenshots with topics.. however I use own mime type 'rar', no support topics are created at all. Also the re-making topics tool fails, says it created but did not.


Using latest IP.Downloads. Tried to submit paid as the free files, same issue. Any quick fix for this is possible?
Updating Fixed In to: 2.5.2
Updating Status to: Fixed


I've just run into the same problem.  I'm using 3.3.4 and Downloads 2.5.2.  When I submit a file as admin the topic is generated but  not for files submitted by members.  I ran the 'Check Topics' tool and it identified files with missing topics but after announcing success, actually failed to generate the topic.  I've added php to my allowed image types in the forum settings and now it works.....is that the solution, is it OK to have php in my 'allowed images'....I thought it was fixed in 2.5.2?  Any guidance appreciated, thanks.

If you do not set a URL to your screenshots in the IP.Downloads settings, the images will always be dynamic and contain a .php extension.  It is not an issue and it is fine to add it to your allowed settings.

Great, thank you for the feedback.