Resized images are missing file name (on PHP 5.1 and lower)

Hmm, is the image logo1.jpg actually on the live server? I've never seen what happens if the file just doesn't exist.

What's the file path on your local installation? Maybe the code for finding the extension is off somehow and we're matching on ".org" instead of the file extension.

I had this happen when I installed and activated the image resize filter but then moved my Drupal installation to a different directory. Uninstalling and reinstalling did not solve this problem. Any clues?

You can't move the location of your files directory. If you do, you need to manually update the files table to reflect the changes.

The files that are getting their names mangled are not even listed in the 'files' table. Is that the issue? I even truncated this table in an installation that had image_resize correctly working, and it did not affect the module's correct behavior.

Thanks,
Jim

Oh shoot, sorry I'm giving out totally wrong advice. Sorry this issue comes up all the time in the FileField queue. :-/

Right, so the problem might be that since you moved the installation, the paths are now wrong and need to be updated. Truncate the cache_filter and and cache_content (if you have CCK), which will make Image Resize Filter reparse the HTML code and regenerate the images. You can also clear the caches at admin/settings/performance, which should do the same thing.

No problem - but I'm afraid that's not helping. I don't have caching on in the first place. However, just to cover things, I tried doing the cache truncation anyway, and reenabled the module, but I still had the problem after saving the content again - file names dropped right out of the cache file names.

Are there any other places I should look? Would it help if I attached some data and examples?

Thanks,
Jim

Well I'm at a total loss here. I setup an entirely new Drupal installation at localhost/drupal6, set the file directory location to "sites/default/files", then I moved the entire installation to a virtual host setup at example.org, then changed the files directory to "sites/example.org/files". The images used in nodes are successfully resized and the file name is kept, for both files that are in the files table and ones that are not.

Just a side-note, Drupal always manages the input filter cache in the cache_filter table, even if you've turned off every form of caching. There's no way to turn it off (nor would you want to), so it can still have an effect on any filter-based module like Image Resize Filter.

Thanks for going to the trouble of testing. As it happens, I was able to move installations locally too, and had no problem. It is only on my client's site with her web server that this happens, and it happens consistently there. Clearly, it is likely to do with the configuration there. I noticed that when I upload files, they are under a certain assigned user, but when the image resize filter creates files, they are (naturally) owned by the apache user. I actually had to write a php script to clean the previously created resize directory off the system.

Even though the files without the base names happen to work, I'm leaving the filter off for caution, since another resize might end up with the same dimensions, which would result in a clash of file names.

I did all the cache purging I could. Is there anything else we can try? I took a brief look at how you generate file names, but didn't get deeply into tracing.

Thanks,
Jim

Hmm, perhaps you have safe_mode turned on the client server? This could cause certain php functions to not work properly, though I can't identify any of the affected functions as being a problem for Image Resize Filter: http://us.php.net/manual/en/features.safe-mode.functions.php

I'd suggest doing a comparison of your php.ini settings and try to match them as closely as possible to your development box (or reverse the process to cause the problem on your dev box).

No, the website isn't running in 'safe' mode, but it's a good suggestion. I just think that something in the file name generation is returning an empty string for one reason or another. I'll see if I can log the actions of this module.

By the way, one marked difference between her installation and mine was that the 'mysqli://' protocol wasn't supported, so I switched it to 'mysql' in order for that to work. Also, it's a PHP 4 installation, as opposed to mine, which is PHP 5. Could there be some relevance there? I've attached phpinfo output for your reference.

Thanks,
Jim

PHP Core
Directive Local Value Master Value
allow_call_time_pass_reference Off Off
allow_url_fopen On On
always_populate_raw_post_data Off Off
arg_separator.input & &
arg_separator.output & &
asp_tags Off Off
auto_append_file no value no value
auto_prepend_file no value no value
browscap no value no value
default_charset no value no value
default_mimetype text/html text/html
define_syslog_variables Off Off
disable_classes no value no value
disable_functions no value no value
display_errors Off Off
display_startup_errors Off Off
doc_root no value no value
docref_ext no value no value
docref_root no value no value
enable_dl On On
error_append_string no value no value
error_log no value no value
error_prepend_string no value no value
error_reporting 2047 2047
expose_php On On
extension_dir /usr/lib/php4 /usr/lib/php4
file_uploads On On
gpc_order GPC GPC
highlight.bg #FFFFFF #FFFFFF
highlight.comment #FF8000 #FF8000
highlight.default #0000BB #0000BB
highlight.html #000000 #000000
highlight.keyword #007700 #007700
highlight.string #DD0000 #DD0000
html_errors On On
ignore_repeated_errors Off Off
ignore_repeated_source Off Off
ignore_user_abort Off Off
implicit_flush Off Off
include_path .:/usr/share/pear .:/usr/share/pear
log_errors On On
log_errors_max_len 1024 1024
magic_quotes_gpc Off Off
magic_quotes_runtime Off Off
magic_quotes_sybase Off Off
max_execution_time 30 30
max_input_nesting_level 64 64
max_input_time 60 60
memory_limit 16M 16M
open_basedir /var/www/vhosts/XXXXX/httpdocs:/tmp no value
output_buffering no value no value
output_handler no value no value
post_max_size 8M 8M
precision 14 14
register_argc_argv On On
register_globals Off Off
report_memleaks On On
safe_mode Off Off
safe_mode_exec_dir no value no value
safe_mode_gid Off Off
safe_mode_include_dir no value no value
sendmail_from no value no value
sendmail_path /usr/sbin/sendmail -t -i /usr/sbin/sendmail -t -i
serialize_precision 100 100
short_open_tag On On
SMTP localhost localhost
smtp_port 25 25
sql.safe_mode Off Off
track_errors Off Off
unserialize_callback_func no value no value
upload_max_filesize 2M 2M
upload_tmp_dir no value no value
user_dir no value no value
variables_order EGPCS EGPCS
xmlrpc_error_number 0 0
xmlrpc_errors Off Off
y2k_compliance On On

PHP 4... ugh! I should put on the project page PHP 4 is not supported. Enough modules require PHP 5 these days (since PHP 4 is officially dead, completely unsupported) that my sandbox site doesn't even work when running PHP 4. I'm not going to spend any time trying to figure out something that's wrong with PHP 4, so you're on your own there.

Regarding the configuration, check the open_basedir against your local install and turn it off if possible on the server. Also if you're using a symlink to your files directory, try using a normal directory instead.

Well, I, too, dislike PHP 4, but I thought that since Drupal 6 itself is still supported under PHP 4, you might have it so for this module, too. If you aren't going to support it, though, I would suggest that you update your project page accordingly and make the module error out in a PHP 4 environment, so that no one else is stuck with this issue.

I am not using a symlink for files, and cannot change the web host provider's PHP configuration or version.

At least we might now know the root cause of this issue.

Thanks again,
Jim

The purpose of the GoPHP project was to make all new releases of any software released after February 5, 2008 PHP 5 only. Since this module was released after that date, I think it's fair that it's PHP 5 only. Not to mention I'd like to do anything possible to stop people from using PHP 4, which is the server equivalent of running IE6. I've updated the module .install to require PHP 5 so it will no longer install on PHP 4 and updated the project page.

Well, it's up to you what you want to do with your module, and I appreciate all you've done.

Just my opinion: since Drupal 6 supports PHP4, a module that is meant for Drupal 6 ought to run on any platform that the base module is supported, meaning PHP 4 ought to be supported for any module that is meant to be compatible with Drupal 6. Granted - I'm no fan of PHP 4, but not all the web servers out there have upgraded. As a web developer, I don't want to support PHP 4 or IE6, but I'm stuck doing it anyway.

Drupal 7 will require PHP 5.2 or higher, which is in accord with the GoPHP campaign you mention, which seems like a better time to be locking out PHP4 from Drupal 6 modules.

Yeah I know, it's mostly my impatience. I'm sick and tired of both IE 6 and (to a lesser extent) PHP 4. But considering that it's in the power of most developers to upgrade their client's hosting platform or move to a different host entirely (whereas moving off of IE6 is not the choice of developers), I've given up trying to test for differences in PHP 4. It's pretty easy to convince a client, "I'm going to save you $10,000 worth of development if you just move to a different host, which will cost you $200/yr". Considering even this small module at least 50 hours of development in it, and time is worth $100-250/hr, that's $5,000 - $12,500 for this module alone. So if you want to use this module for free (and have it work correctly), it should be easy to foot the $200/yr for a decent host.

Anyway... off the PHP topic. We still never really found what the problem was. If you can figure out what in the module could possibly be causing it, I'd still really like to fix it. But considering it's been impossible to reproduce in any situation except for your client server, I'm not sure what else to do.

Absolutely. We're still only speculating it has to do with PHP 4, so our
discussion on this subject may not be 100% relevant anyway. I'll be happy to
take a closer look on my client's website and see if I can determine the root cause.
If I have a code fix to propose, I'll send that to you privately.

Thanks again,
Jim

Nate,

I have E-mailed you my findings. Please let me know if you did not receive.

Thanks,
Jim

BlackCatWeb, after checking the code you sent me, I've revised slightly to create the attached patch.

Everyone else: It turns out the PHP pathinfo() function did not support the 'filename' property until PHP 5.2. So in fact this wasn't working even on PHP 5.1 (which is what RedHat is still running, unfortunately). I've committed the attached patch which rolls back the PHP 5 requirement since as far as I know it should work in PHP 4 as well as 5.1 with this patch.

I've committed this already, prepping for a 1.2 version.

I've also committed this update function to flush out existing images and regenerate them as necessary.

QuickSketch - Thanks for fixing this. I didn't know about the 5.1 limitation. My Red Hat distribution, FC8, is using 5.2, and FC8 is more than a year out of date now. Not surprising there are some legacy RH distros out there still in use.

Thanks again - I'll await your new package.

Yeah oddly it's RedHat Enterprise Linux (and CentOS) that's not yet updated, unless you pay extra for a newer update stream or something crazy like that. We just went through the same whole fiasco in the FileField queue (which had been requiring 5.2).

Version 6.x.1.4 works with Drupal 6.10 under PHP 4.3.9.