Thanks, Mr. MelvinG. You've given me a few more things to work on. I originally found the extension_dir=.\ line in php.ini which is what I modified to point to where things actually resided in the first place, and I still suspect that's my problem. Getting rid of the trailing slash didn't change anything, but for troubleshooting purposes I should be systematic and try both types of slashes (and restart the AbelCam web server, AND restart my operating system). I'm used to creating comprehensive Linux server boxes where all the paths normally are congruent. I'll continue to do some basic trouble shooting and give some feedback herein so others can benefit from the experience.

FYI, I didn't do a php install (in the Linux sense) but just unpacked the zipped directory to c:/php as noted in the extant AbelCam documentation. I think I saw something about "paths" in the xml config files for AbelCam to point to a different directory other than the expected c:/php one.

If you could (no malice if you can't), a check would be to install (copy) the actual php script linked to in my original message (it's configured to invoke gd2 by default) in some random test directory with a jpg or two and see if a mouse roll-over invokes gd2. If not, that would tell me that the issues are elsewhere. If it does work, I'll keep being stubborn and get it working. Again, if not, I'm not miffed (but it would probably take less than 5 minutes - it's that simple).

Yeah, I figured GD2 would work fine (heck, it's just an executable .dll being called up to be executed in the Windows php environment (with which I don't have a lot of experience) and shouldn't depend upon the AbelCam web server in any way). I'll be a bit more stubborn.

Off topic. You the Nixie Tube guy?

Just an ex-Angeleno (go Bruins!).

Okay... here's my take on what's going on...

Every time you mouse over a line in the directory listing, /dlf/i.php is called with ?f=filename, which creates the thumb on the fly.

1) In i.php the filename is gotten out of the URL by using $_REQUEST['f'] (perfectly legit method). But AbelCam is not loading up $_REQUEST with the parameter(s) like I'd expect it to. I remember having this problem ages ago and working around it by changing all $_REQUEST to $_GET, but that no longer works. The only place I could find the "?" parameters was in $_SERVER['argv']. They are there but it ain't pretty... the "?" and all that follows are lumped together in argv[1]. Meh.

2) I modified the scripts so that the thumb maker would get its filenames from argv[1]. That fixes it to a degree - at least it makes a thumbnail image, BUT AbelCam is stripping off the "Content-Type: image/jpeg" header that i.php provided and replacing it with "text/html". Huh? So the thumbnails still don't display because an image is expected and the header claims we got back text. Meh^2.

3) The issue in (1) with parameters also breaks the various param-driven features that index.php offers (sort order, etc.) that can optionally be specified in the URL. This can't be hacked up with 'argv' as readily as the passing of a single parameter to i.php was.

I'm SURE the AbelCam + PHP used to work better than this. In fact, I have some old code here from my old-old-old website (that was 100% served by older AbelCam + PHP) that I know used to work but will not work given the current state of affairs. What I don't have is a really old version of AbelCam to play with.

To move on from here we need Mr. SSE to look into what might have gotten broken in AbelCam. I know PHP support hasn't been looked at nor tested since many releases ago because when I switched over to Apache that took us from 1 to zero active users using Abel + PHP "seriously". I'll drop a post on the Issue Tracker to bring this to his attention, but I'm not sure how enthused he's gonna be about troubleshooting such an unpopular feature.

EDIT to ADD: Here's your script running under Apache...

http://eeber.no-ip.org:9334/test

When PHP was first added to AbelCam it worked pretty well, and after Mr. SSE and I went thru a few iterations of test / modify / re-release over on the Issue Tracker it worked really well. The "limited support" disclaimer was almost meaningless at that time. Something has been broken as AbelCam moved forward and you and I are just now discovering it.

The only reason I abandoned Abel + PHP was that at the time I had it stuck in my head that I wanted to use a frameset on my site (bad idea) and AbelCam server didn't want to cooperate. Wasn't even a PHP problem...

*** Pure speculation follows ***

I think it's safe to say that the reason PHP didn't catch on with AbelCam users is NOT because of limitations or bugs. I think your first idea is the right one: the majority of users want quick & easy, and if it takes more than 3 mouse clicks to set it up then it's too much trouble. Heck, most users use the web pages that come with AbelCam - unmodified - even though those pages were intended to be example / starting point stuff, not finished work.

Then there are a handful of users at the other end of the scale. You tend to see these people participating on the Issue Tracker and having their sites listed on the Camera List page. People like myself, who may not be expert developers but don't mind throwing together a bit of PHP or some C++ or Perl or whatever to create what they want. Thing is, these kinda users (I suspect) tend to already have a box or two set up for LAMP (or WAMP as the case may be) and go with what they know works rather than delving into Abel + PHP. Putting the site on the Apache box and plunking a few Java applets into the pages - to interact with an AbelCam "back end", maybe on a different box altogether - is pretty darn easy IMO and has certain advantages...

Melvin, I agree with your speculations.

Limitations are due to the PHP interface used (command line), please see Issue 344

I'm still scratching my head about the matter of $_GET. I understand and agree that $_REQUEST couldn't have ever worked - PHP docs are clear about this. The docs are less clear about $_GET when using command line style invocation. Logic would seem to dictate that something invoked from the command line wouldn't have any knowledge of something that's pretty specific to the webserver, but the docs don't come right out and say so for $_GET like they do for $_REQUEST.

And yet... I have this old code here that I wrote when I was trying to be a "100% served by AbelCam" site. This code worked - it ran my site for a few months and the only problems were frameset related. This code uses $_GET all over the place. If the $_GET wasn't working the site eould never have worked. I have no recollection of ever having to use ARGV and split the pairs as a workaround for $_GET and (more reliable than my memory) there is no trace of any commented-out ARGV-processing code in any of the PHP files.

Also... I checked, and my PHP is the recommended version. It's different only in that is was distributed as an MSI rather than as a ZIP.