Page 1 of 1

Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 04:20
by Lupenzo
I am running XAMPP to try and set up a webcomic site. I am using Word Press and Comic Press. When I attempt to post blogs/comics I get the following error message.

"Warning: imagedestroy() expects parameter 1 to be resource, null given in C:\xampp\htdocs\wordpress\wp-content\plugins\comicpress-manager\comicpress_manager_admin.php on line 1302

Warning: imagedestroy() expects parameter 1 to be resource, null given in C:\xampp\htdocs\wordpress\wp-content\plugins\comicpress-manager\comicpress_manager_admin.php on line 1303

Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\wordpress\wp-content\plugins\comicpress-manager\comicpress_manager_admin.php:1302) in C:\xampp\htdocs\wordpress\wp-includes\pluggable.php on line 890"

I looked on the Comic Press Forums and their response to someone with the same problem was, "your PHP on xampp needs to handle GD" (entire response).

Unfortunately I do not really know what they are talking about. I checked localhost and it seems to indicate GD is enabled. As you may have guessed I am completely ignorant about all of this and the friend who is helping me is also stumped. When we asked how to fix this on the Comic Press forums they suggested we try the XAMPP forums.

Any help is appreciated and if you need more info I will do my best to provide it.

Thank you in advance.

(I tried searching the forums before asking but "GD" will not work as a search term and there were no hits for Comic Press.)

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 05:05
by Altrea
Which Version of XAMPP are you running?
Maybe the comic press version you use doesn't support PHP 5.3.

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 10:08
by JonB
Info - You must not have Googled much --

http://www.libgd.org/Main_Page

GD is a common graphics library.

I think your problem is not GD, but rather your your PHP error settings - note those are WARNINGS. not errors. Look in (search) your configuration files (could be php.ini or one for ComicPress) for a line containing: error_reporting. The last error (about headers already sent) is because the error reporting was output first. Thus the normal output headers cannot set up the page output.

try these values:

error_reporting( E_ALL ^ E_DEPRECATED ^ E_NOTICE);

READ this:
http://php.net/manual/en/errorfunc.configuration.php

GooD luck

:)

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 10:12
by Lupenzo
Actually I did google a bit, and even found that page but didn't understand the solution was there (ended up with the installation instructions for the library and PHP 5.1 already has the library so I thought that made it irrelevant.) I will revisit it and try to figure it out. Should have better luck now that I know what to read.

Thanks very much!

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 11:27
by Lupenzo
I fumbled around and got it set. I have a lot to learn. Hopefully my next question will not be so ignorant.

Thanks again!

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 11:39
by Altrea
To hide the warnings is not always a good idea.
There are reasons why these warnings appears.

If you just hide them, there is no guarantee that your script runs perfectly in all circumstances.

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 14:26
by JonB
Altrea:

Its a known problem with the WordPress core and plugins. If you don't suppress warnings and deprecated, you won't get output. That is a major catch-22/mess with WordPress development. How can you debug a web-app that doesn't output when you have warnings and errors? Answer: pipe them to a file. STDERR needs to go to a file. It requires programming (read 'a script'), and I have not fully researched/tested/debugged it yet. I know because I had to solve that problem before in WordPress and BBPress (their Forum/BBS startup), I use both on different sites.

Lupenzo, there was no way for you to have known this. This is/was an advanced application-specific problem. Just pass it on if you see someone else with the problem. CLEARLY, whomever responded on ComicPress didn't understand the issue. Plus, now you also know what GD is and why you need it.

Good Luck with your site.

:mrgreen:

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 16:35
by Altrea
JonB wrote:Altrea:

Its a known problem with the WordPress core and plugins. If you don't suppress warnings and deprecated, you won't get output. That is a major catch-22/mess with WordPress development. How can you debug a web-app that doesn't output when you have warnings and errors? Answer: pipe them to a file. STDERR needs to go to a file. It requires programming (read 'a script'), and I have not fully researched/tested/debugged it yet. I know because I had to solve that problem before in WordPress and BBPress (their Forum/BBS startup), I use both on different sites.


Yeah, i know :) Thats why i said "...is not always...". In some cases, thats the only way to get an application running. But not in every case is this the way to get a script running correct.
I just wanted to be sure, that nobody hides his warnings in general to get rid of them.

At last anyway it is recommend to hide parser errors in production mode and log them to a file.

Re: Problem with Comic Press on XAMPP

PostPosted: 21. June 2010 21:33
by JonB
and now why I really actually love WordPress -- the best codex anywhere: :shock:

Debug

The WP_DEBUG option, added in WordPress Version 2.3.1, controls the display of some errors and warnings. If this setting is absent from wp-config.php, then the value is assumed to be false.
NOTE: The true and false values in the example are not set in apostrophes (') because they are boolean values.

define('WP_DEBUG', true);
define('WP_DEBUG', false);

Additionally, if you are planning on modifying some of WordPress' built-in JavaScript, you should enable the following option:

define('SCRIPT_DEBUG', true);

This will allow you to edit the scriptname.dev.js files in the wp-includes/js and wp-admin/js directories.

In Wordpress versions since 2.3.2, database errors are printed only if WP_DEBUG is set to true. In earlier versions, database errors were always printed. (Database errors are handled by the wpdb class and are not affected by PHP's error settings.)

In WordPress version 2.5, setting WP_DEBUG to true also raises the error reporting level to E_ALL and activates warnings when deprecated functions or files are used; otherwise, WordPress sets the error reporting level to E_ALL ^ E_NOTICE ^ E_USER_NOTICE.


too cool -

8)