I am playing around with Dragonfly on a test site. It looks great, but the security code generates a blank blue box. I have an operational site running 8.2b where the security code works just fine. For my Dragonfly test site, however, all I see is a blank blue box (see links below).

8.2b:
example.com/index.php?name=gfx&random_num=97610

Dragonfly:
example.com/dragonfly/index.php?name=gfx&random_num=97610

I have looked at config.php and the others for extra returns at the end (as per the FAQ), but that didn't seem to fix anything. I an not very familiar with php, so "closing PHP tag" may be different from what I expect, but I've noticed that several of the files (eg. config.php, admin.php, index.php) don't terminate with "?>" in my 9.0 version as they do in 8.2b. I have experimented with this briefly with no success.

As this is a test site, re-installing is not a problem (I've done it a couple of times already), but I can't get the security code to work. Any suggestions would be appreciated.

make sure there is no space after ?>

If the security code image is empty then it could mean 2 things:

- session isn't stored properly on the server (could be related to PHP 4.2.x)
- Your server says it supports TTF but actualy it doesn't

Thank you for your suggestions.

xfsunoles:
I verified that there are no spaces (or returns) after the ?> (which I added) at the end of the .php files. This didn't solve the problem. I'm confused as to why the 9.0 files do not terminate with ?>, whereas the 8.2b files did. Does this not matter?

DJMaze:
I wonder why these server related possibilities would affect 9.0 but not 8.2b. Both sites are on the same server. Are there an intricacy involved in that regard that I'm not catching?

i had this problem with 8.2b before, ah, DJ asked me to verify if the bg.jpg file isnt corrupted and hola! it really was, please verify yours.

No this problem is related to the version of GD that is installed and if the TTF module in PHP is running.

And as i expected this is true after using the "test" function.
example.com/dragonfly/index.php?name=gfx&random_num=97610&test
example.com/dragonfly/index.php?name=gfx&test

The first image is blank and the second shows the text "test" terrible small while it should look like this cpgnuke.com/index.php?name=gfx&test (thisone is grey on black)

DJMaze:
Thank you as always for your quick response. I am admittedly very new with cpgNuke and php in general, but I still think it may not be as simple as a server side problem. I have installed 8.2b over top of my 9.0 test site. The security code works just fine:
example.com/dragonfly/index.php?name=gfx&random_num=97610

Also, my phpinfo indicates that GD and TTF are enabled:

GD Support enabled
GD Version bundled (2.0.17 compatible)
FreeType Support enabled
FreeType Linkage with TTF library
GIF Read Support enabled
JPG Support enabled
PNG Support enabled
WBMP Support enabled
XBM Support enabled

Is there a difference in how 9.0 and 8.2b handle the security code? Which php file handles the security code generation?

poldo:
Thanks for the suggestion. The bg.jpg file does not seem to be corrupted, however.

Quote::

Is there a difference in how 9.0 and 8.2b handle the security code? Which php file handles the security code generation?

Yes it's been changed.

Thanks GMINI03. I found that the security code appears to be handled within gfxchk.php. I don't know php syntax, but I'm trying to understand how the code generation works.

wish I could help further but I can't, I just know its been pretty much rewritten for dragonfly so saying it works in 8.2b doesn't help all that much.

Yeah, so I've noticed. There seems to be a lot of similarity between the two versions of gfxchk.php, though.

CPGNuke has been great--not least of all because of the community here. I'm excited to have Dragonfly up and running eventually with all the modules I use. I wish I could help more with the conversion process. For now I'll just have to wait for those more skilled than I to do the dirty work.

After playing around with gfxchk.php, I've noticed a couple of interesting things: It works if I set $useimage = false. Also, if $useimage = true, but I force it to use ImageString() instead of imagettftext(), it works as well.

There are 2 versions of imagettftext() and 1 works on font pixel and the other on size.

The $fontsize is multiplied by 2.4 which should result in 12 pixels.

Play with the values untill the text is displayed on the image.
Please reply with your results in here so we can integrate the solved issue with the final release.

I think I've found a work around. According to the comment by 'pete at monolight dot org' about half way down the page at:

terra.di.fct.unl.pt/do...xt.php.htm

You can (1) import the code_bg.png image into a base image. (2) Create an overlay image including the security code for which you make the background transparent. Then (3) merge the two images using imagecopymerge(). I have hacked an attempt on my site and it seems to work pretty well. Below are some extracts of my modification, although you will certainly want to clean them up. Keep in mind that this is the first time I've done anything in php. $image is the base image and $image_text is the overlay.

Removed the else in if ($useimage) to force the script to execute the $image = ImageCreate(..) portion. (This line is changed below)

Changed:

PHP:

$image = ImageCreate($chars*(4+$fontsize),20);

to

PHP:

$image_text = ImageCreate(ImageSX($image), ImageSY($image));

Changed:

PHP:

$background_color = ImageColorAllocate($image_text, $bred, $bgreen, $bblue);

to

PHP:

$white = ImageColorAllocate($image_text, 255, 255, 255);

Changed:

PHP:

ImageFill($image, 0, 0, $background_color);

to

PHP:

ImageFill($image_text, 0, 0, $white);

Replaced $image with $image_text in all further occurances

Scaled the font size in both occurances of imagettftext() by 1.4.

Added the following after if ($ttf) { imagettftext(...) ... }:

PHP:

imagecolortransparent($image_text,$white);

PHP:

imagecopymerge($image, $image_text , 0,0,0,0, ImageSX($image_text), ImageSY($image_text),100);

Added at end:

PHP:

ImageDestroy($image_text);

This definitely needs to be cleaned up, but I think the algorithm works. The method of handling the case where $useimage = false will have to be modified.

Just wanted to add my experience with this-- I just set up a test site running Dragonfly RC1 upgraded from a copy of my 8.2c database. I'm having the same problem with not being able to see the security code.