Recently when I tried to create new image ads I had a problem where uploaded images were being turned into nodes which conflicted with where the ad module expected images to be.

At first I thought this was caused by the Ad module since this happened a day after updating to the latest version of the module.

I just discovered that the cause of this was a module called the upload image module.

http://drupal.org/project/upload_image Upload image

Description: Image nodes will be created from images uploaded as attachments. The module depends on both upload.module and image.module.

I think the ad module's description and read me file should point out this conflict.

Image assist may have similar issues.

Comments

Abilnet’s picture

Title: Image ads and upload image module » Image ad images in wrong directory - path problem

I'm having exactly the same problem in both versions, 5.x-1.5 and the latest dev.

AD -module is expecting (hard coded?) that the banner images are stored to the "files" -directory. Yes, in many cases uploaded images actually are heading to the "files" -folder, but in some cases no (as described above by underpressure) This depends on what modules are installed (in my case those banner images go to the files/images -directory.

Ok, it's easy to manually move the banners to the "files" -directory for ad-module to serve them, but what about having a setting to choose where the images are actually stored?

Sorry I can't help in coding, I'm far away from a coder... but my 2 centimos from Sunny Spain anyway.

PS. Thanks for the Great Module!

jeremy’s picture

Status: Active » Fixed

The ad module gets the path to the image file by reading the "files" table, using the "filepath" column. If you're moving files, you need to update this database table as well.

Abilnet’s picture

Ok, I see... however, I try to explain this some more (sorry my bad English) ...so, I had an "out of the box" installation with some commonly used image -related modules activated. This potentially means, that the uploaded images get saved to other locations than the files -folder got from the basic file system database settings by default.

I was just wondering, if there is any other solution to give the ad -module correct path to the images than manually editing database tables? (otherwise, for sure this issue pops up again and again, because people do have modules installed)

I think one possible solution (a non coder talking now) is to code the path to the banner images as a variable, and then in module settings everyone can set the path according to their configuration)

However, I can happily live with this and manually move the banners down to the "files" -folder... just wanted to give some feedback of this case.

Thanks for the Great Module!

jeremy’s picture

Category: bug » feature
Status: Fixed » Postponed (maintainer needs more info)

Are these image modules using their own custom tables to track files, rather than using the core "files" database? Do all of these image modules use the same custom table, or do they each have their own custom table? Do they each share an API for working with these images?

Again, the ad_image module reads from the "files" directory, and utilizes the standard Drupal file functions to build paths to the modules. It utilizes Drupal's configuration to determine where image files live, it does not assume or hard code anything. This works if you're using core modules, but won't work if modules are defining their own systems for tracking images. The best I can likely offer is to provide hooks in the ad_image module allowing you to easily over-ride its core assumptions. It would require someone to step up and show what changes need to be made for the ad_image module to work with the various contrib image modules.

Re-opening, and marking as a feature request.

summit’s picture

Subscribing, greetings, Martijn

jeremy’s picture

I will be closing this issue in one week if the additional details I requested above are not provided.

jeremy’s picture

Status: Postponed (maintainer needs more info) » Fixed

No further feedback, closing.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.