0

I had trouble accessing wp-login.php, so I changed the name of the theme I'm developing to force WP to switch to default. I then turned on debugging and received the errors below. I'm a little puzzled as to why these have come about because they were not showing when I was last working on the theme a few days ago, and I've used get_bloginfo in other themes without issue. Any and all help re: how to fix these errors is greatly appreciated.

Notice: get_bloginfo was called with an argument that is deprecated since version 2.2! The siteurl option is deprecated for the family of bloginfo() functions. Use the url option instead. in /home3/dyluxept/public_html/wp-includes/functions.php on line 3551

Warning: Cannot modify header information - headers already sent by (output started at /home3/dyluxept/public_html/wp-includes/functions.php:3551) in /home3/dyluxept/public_html/wp-content/themes/smallbiz/functions.php on line 141

Warning: Cannot modify header information - headers already sent by (output started at /home3/dyluxept/public_html/wp-includes/functions.php:3551) in /home3/dyluxept/public_html/wp-includes/pluggable.php on line 866

Improve this question

2 Answers 2

Reset to default
3

Replace get_bloginfo( 'siteurl' ) with home_url().

As the get_bloginfo() Codex entry explains, siteurl is deprecated:

'siteurl' / 'home (note this is deprecated! from version 2.2)' / 'url' - Returns the 'Site address (URL)' set in Settings > General. This data is retrieved from the 'home' record in the wp_options table. Consider using home_url() instead.

Improve this answer
0

You also seem to have a problem in the theme. From the second error:

/wp-content/themes/smallbiz/functions.php on line 141

You'll want to examine that line of the theme's functions.php file.

This is just a guess, but one common cause of an error like this is white space that comes after the closing PHP tag like this:

?>
_

(That underscore is a space.)

You don't even need the closing tag, so I'd just remove the whole thing.

Improve this answer
4
  • 1
    It seems more likely that this error is actually triggered by the existence of the first error. If you have error reporting turned on, and an error or notice is thrown before any action that tries to modify the headers, you'll get a "cannot modify headers" error because the reporting of the FIRST error counts as output.
    – MathSmath
    Commented May 21, 2012 at 18:57
  • That's a good point. But how would a deprecation notice trigger the second error?
    – mrwweb
    Commented May 21, 2012 at 20:21
  • Notices are echoed at exactly the point in execution where the code causes them, and the notices themselves become part of the output. The "headers already sent" error actually explicitly says where the output started --at exactly the same place that the first error occurred ("output started at ... functions.php:3551"). So the notice was spit out, and then some other action tried to modify the headers in some way. If the notice hadn't been echoed, no output would have been sent yet, and the second error wouldn't have been triggered. Make sense?
    – MathSmath
    Commented May 21, 2012 at 22:05
  • That does make sense. Thanks for taking the time to explain.
    – mrwweb
    Commented May 21, 2012 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.