PHP Compatibility problems in PHP Photo Album

1) Script Title: PHP Photo Album

2) Script URL (on DD): http://www.dynamicdrive.com/dynamici...photoalbum.htm

3) Describe problem:
There are a few problems with the PHP to get the images for cross-server compatibility:
1. It uses short tags: <?....?>. On some (many) servers this won't work. It's a simple fix: The first open tag must be <?php.
2. On newer releases of PHP if it isn't setup by default, PHP will refuse to use date(). http://www.php.net/manual/en/functio...mezone-set.php As explained on that page, that function (at the start of the script) will fix this. Since the real time is irrelevant and only relative time matters, that's good.
3. The order of images is hard to control because it's using file date. Perhaps there could be a parameter to do alphabetical. For example, on my old server they were in a different order because that is how I uploaded them, but now they are in alphabetical order because that is how I restored the site from a backup (automatically).


I could rewrite any of the PHP as needed, if I can find some time (on vacation now, so not on the computer much, but it won't take too long to find a few minutes for this).


There may be more minor issues with various types of servers, and cross-server compatibility isn't something I've worked much with yet in PHP, just a bit now that I've switched servers and found a few things to be different.
Most importantly, short tags should never be used to distribute code: long tags always work and short tags don't always.
Then maybe a note about the date thing. I'm not sure if that's usually configured, but it isn't on my server so it may be a problem for others. I'm not sure if this is common though.
Reworking the image gathering system would be another issue.


Finally, the ereg functions are deprecated and throw warnings generating (I believe) invalid JS. I've replaced them with the preg functions and can post that here as needed.

The javascript already allows for sorting by name.

See also:

http://www.dynamicdrive.com/forums/s...ad.php?t=54416

Which takes care of everything you mention and more, except sorting (the script already does this), and the date issue you mention.

I think that could be resolved with this code (now added to my linked post above) any time before the date functions are accessed:

PHP Code:

---

if (phpversion() >= 5.1){
    @date_default_timezone_set(date_default_timezone_get());
} 


---

1. Sort:
Yes, I hadn't realized the options were there. That's fine, though the inconsistencies in moving servers are a little confusing. Specifying that, however, will probably control it so that doesn't occur when the system does.

2. PHP date:
That's the correct way to fix it, and that should work on all servers assuming they're new enough to have those functions, which is likely. I suppose there could be an added conditional using function_exists().

By the way, my photo gallery is working fine now since I fixed a few things in the script. This may help others though.
Also, though this may be a tradeoff if there is a major error, disabling errors (perhaps just "E_NOTICE" level) will make the javascript generated at least be valid. The warning about deprecated ereg, for example, will be irrelevant, since the function still works.

About the date, I'm ignoring PHP 3 which will choke on preg_match() anyway. So simply testing for the version number (available from PHP 4 on) should suffice without the need for function_exists(). Besides, function_exists() is only PHP 4+ as well.

One other thing about this script. I've seen where some systems just don't get:

PHP Code:

---

$dirname="." 


---

For some reason they seem to need:

PHP Code:

---

$dirname="./" 


---

I'm not sure what that is, probably some kind of a configuration thing. I'm also not sure if all systems that do fine with . would also be OK with ./

If they would, this change should be added.

Making this PHP3 compatible is not worth it. PHP4, 5 and 6 are important though. And for that, the biggest problem is the warnings that pop up for various non-essential components.

I have never seen the problem with "." instead of "./" (I believe you, though), but I have had similar issues with trying to find paths, etc. This means that if this is ever combined with something (eg subdirectory or file), it'll need to be known that it already contains the slash. From what I've seen, the standard method is NOT to do this, but rather to add the slash like this:

PHP Code:

---

$mypath = dirname(__FILE__); //or $mypath = '.';
$myfile = 'file.ext';
echo $mypath.'/'.$myfile; 


---

The way the function is set up is:

PHP Code:

---

function returnimages($dirname=".") { 


---

called later as:

PHP Code:

---

returnimages(); 


---

It's my understanding that if you wanted to use a GET for the folder, you could call it like so:

PHP Code:

---

if(isset($_GET['dirname']))
returnimages($_GET['dirname']);
else
returnimages(); 


---

At that point it would be up to the person modifying the script to either call it with the correct query or to add in the required slash(es), dots, etc. right there.

The folder used for the filenames is derived from $_SERVER values, so whatever is set as dirname for the function would only be used in retrieving the files, not for writing out their full paths later.