Single-site setups, multiple machines. I cannot get this module to work on them.

First off, when I set the "Default image path:" to images, it creates the directory underneath the drupal root, rather than in the file_system_path where it implys with helptext "Subdirectory in the directory "files" where pictures will be stored. Do not include trailing slash." Odd? Bug?

Second, Image is passing the relative path as configured by "Default image path:" to the convert application. As if it's counting on PHP to have set the default working path somewhere else? How can I get around this? It's obviously not working for me. I get the errors such as:

The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
&
Unable to create preview image

The images upload fine into images/temp, but the original sized image never moves up a directory out of temp. If I put the absolute path into the "Default image path:" the convert commands run fine, every single warning or error message goes away and the submit seems to run fine. However, when drupal img ref's in the images to view the page or edit, etc, I see the absolute path appended to the drupal url. That won't work.. heh

So.. what am I missing? What am I doing wrong? Am I the only one with this problem? Is it maybe a php configuration setting that's causing the relative path to be incorrect?

Comments

drewish’s picture

drewish commented

you set a file system path on admin/settings/file-system right? is it beneath the drupal root? are you using public or private file transfers?

Image is passing the relative path as configured by "Default image path:" to the convert application

well the path is relative to drupal's root right? what toolkit are you using?

GypsyMage’s picture

GypsyMage commented

Correct.

Site Configuration
-File System
--File system path: files
-Image
--File paths
---Default image path: images

I'm using the ImageMagick toolkit, all is well on the configuration page to select it.

Drupal is installed to ~user/public_html/drupal

GypsyMage’s picture

GypsyMage commented

Forgot to answer; Public transfers.

Tresler’s picture

Tresler commented

Perhpas more info, possibly a seperate issue.

Upgrade from a 4.7 install. Al galleries, images, and there derivitives show up fine. On editing the node and re-submitting I get the following message: 

    * Operating in off-line mode.
    * The Image has been updated.

    * The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
    * The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
    * The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.

As you may have guessed I have the two defaults and a third derivative setup - hence the message x3. For testing purposes I did a chmod -R 777 files/ and the same result.

Whats weird, is obviously image.module knows where these files are and that they do exist - it shows them right before I edit the node. But on submit its saying it can't find them. Hence destroys records of them in the db.

Tresler’s picture

Tresler commented

So a little digging discovered that for some reason all my images are stored in the database as

images/filename.jpg

and when I save a new image it saves as

sites/sitename/files/images/filename.jpg

So somewhere along the line the files table started saving the files_directory_path() part of the path... which causes image module to look for a different file when editing...

At least that's my current thoughts... ideas?

Tresler’s picture

Tresler commented

So I executed this bit of code in devel.module's execute php bloack and it appears to have resolved the problem.

NOTE: THIS WILL NOT WORK FOR ANYONE WITH MORE THAN IMAGE FILES IN THEIR FILES DIRECTORY.

But you could use it to build off of. 

$filepaths = db_query('SELECT fid, filepath FROM files');
while ($paths = db_fetch_array($filepaths)) {
  $m++;
  $path[$m]['path'] = 'sites/charlesgeorge3d.com/files/'.$paths['filepath'];
  $path[$m]['fid'] = $paths['fid'];
  }

 
foreach($path as $i) {
 db_query('UPDATE files SET filepath = "%s" where fid = %d', $i['path'], $i['fid']); }
drewish’s picture

drewish commented

tresler, you're issue is upgrade related while GypsyMage's problem is with a clean installation. You should take a look at http://drupal.org/node/142178 it sounds like your problem. You're code would probably be well served in an .install update for that issue.

meignorant’s picture

meignorant commented

Tresler, every time I run your code it just adds the path set in line 4 to the existing path in the database. I am not familiar with php and shouldn't have tried this solution. Too late now. Please tell me how to get back to the condition like it was before the code was run for the first time?

GypsyMage’s picture

GypsyMage commented
Status: Active » Fixed

Here's the problem and fix!

Problem:

I stack traced the apache code to a failed GETCWD command. EACCESS was the error.. checking the php man page for GETCWD showed the problem right away. It requires all parent directories of the current working directory to have +read/search mode set. One of the parent directories in my tree was not set readable. Even though webpages functioned correctly, the getcwd command failed.

Fix:
cd to incorrect directory and chmod o+rx .

Tresler’s picture

Tresler commented

sorry meignorant - should have menitioned that you would need to alter that line to match your file directory... but asDrewish says - mine was probably a different issue altogether.

drewish’s picture

drewish commented

if any of you are using PHP4 take a look at: http://drupal.org/node/141994

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)