I had created one wordpress site.
It was working nicely but now it showing the error as follows :
Warning: Cannot modify header information - headers already sent by (output started at /home/**/public_html/wp-content/themes/**/includes/classy-options-init.php:1) in /home/*/public_html/wp-includes/pluggable.php on line 866
What is exact problem please help me.
Read up on how to go about troubleshooting this extremely generic error message:
https://wordpress.org/support/article/faq-troubleshooting/#how-do-i-solve-the-headers-already-sent-warning-problem
Again, this message gives us virtually nothing to work with. Aside from the line # in pluggable.php, the question might as well read "this doesn't work". Try googling for "pluggable.php on line 866" to see some likely causes, since that's all you have to go on at the moment.
Additionally, take a look at your web server (apache?) error logs, and see if you get any more info out of them.
Finally, take a look at other questions involving pluggable.php on SO. They may or may not be a dupe of this issue. For example:
Cannot modify header information - headers already sent by... WordPress Issue
Related
On a script which has been working fine for some time and unchanged, today I get
'Execution failed: Data storage error'
on a line which consists simply of:
PropertiesService.getScriptProperties().setProperty('runMode', 'LIVE');
What can I do to fix this?
Is this some kind of server error?
It's an error from Google. An issue as already been submitted, you can upvote it (click the star in the title) : https://code.google.com/p/google-apps-script-issues/issues/detail?id=6856
[EDIT] Seems to be up and running now.
Yes, the google-apps-scripts-issues 6856 describes the problem exactly, as experienced today by dozens of users. Appears to have been fixed at approx 14:00 GMT 24-Mar-17.
Would like to know whether we need to code around the possibility of a repeat of this error.
According to the OpenShift docs, the following should return a result:
curl -X GET https://openshift.redhat.com/broker/rest/api
However, any call to the API actually just returns a single whitespace - including those called with username & password.
I've confirmed the issue from several different machines accross the globe.
What might be the reason?
Inspired by a similar question regarding Twitter, I added .json at the end of the URL and it worked:
curl -X GET https://openshift.redhat.com/broker/rest/api.json
It's kind of disappointing that RedHat never replied to any inquiry regarding this issue.
The issue is logged here: https://bugzilla.redhat.com/show_bug.cgi?id=1324208
You can add yourself to the "cc" if you would like to be notified as the fix gets rolled out to production.
FYI, asking for help on a public forum and giving it only 4 hours for a response from the company seems a bit much. In the future it may be worth it for you to either check for open bugs, or to ask the company directly instead.
I am facing some issue with product url. Url seems to look fine but some times it's get redirected to 404 and the url-key value in address bar is getting replaced with 'null'.
I am not able to find any clue why its happening.
Can you any body suggest proper method to debug such issue?
Thank You.
This is basically URL rewrite issue. Check if the url rewrites are enabled: System> Configuration > Web > Search Engine Optimization > Use Web Server Rewrites.
And if the problem still persists do check your exception.log file
I'm aware this is a 2 year old post, but I had this issue today...
all previously valid product urls got a 404 error
after a lot of failed attempts of figuring out what was going on I asked someone to take a look, to which they replied: Err, What's wrong? ...
apparently everything was fine, but my own user's session/cookie had bad data, or something.
Removing the bad cookie fixed this.
I have no idea specifically what it was because I did not think of keeping a backup of the bad cookie/session data to investigate.
But I'm guessing it had something to do with my session's customer id or user id
Next exception 'Zend_Db_Statement_Exception' with message 'SQLSTATE[HY000]:
General error: 1032 Can't find record in 'report_viewed_product_index',
query was: INSERT INTO `report_viewed_product_index`
Has anyone tried accessing bungie.net reach stats api (statistics from Halo Matchmaking)?
As described here http://www.bungie.net/fanclub/statsapi/Group/Resources/Article.aspx?cid=545064
I can't seem to get any data returned, for example if i use this (with correct API key and gamertag values of course) ignore the first 2 asterisks ...
**http://www.bungie.net/api/reach/reachapijson.svc/player/details/byplaylist/MyIdentifierAPIkey/Gamertag
I don't receive a response - but no errors either, am i doing something wrong?
looking to use this for a Titanium (appcelerator) app eventually.
Any help or advice welcome, thanks in advance.
Unfortunately the API is not yet live to the public. I asked in a Private Message. They didn't say when it would be live.
In the Docs that Achronos posted, he put spaces in the URL's, I'm not sure if those are supposed to be there or not, so I tried it with the spaces and I got a 403 Forbidden error page. When I remove all the spaces, I get an error page that says:
Request Error
The server encountered an error processing the request. See server logs for more details.
I kinda can't check the server logs though... Bungie did say they were having some issues with the site though, so this might be a biproduct of that. I want them to get it working soon though, I wanna see just what it can do!
My site was valid until today, wondering wether it is my site's or the validator's fault.
I am getting this message:
The error encountered was: 500 Can't connect to localhost:8888 (connect: Connection refused)
HTTP Error 500 is an Internal Server Error, so that will be their fault. Try validator.nu whilst you are waiting.
W3C validator maintainer here. Tip: Next time you see that message, try validating your document directly at http://validator.w3.org/nu/ instead.
Because if you see that 500 error it means the validator is trying to reach the HTML5 backend, which runs as a separate service/process responding at localhost:8888 on the validator host.
But we actually run several validator hosts, round-robin, so if you see that 500 error it could mean that only one of the HTML5 backends on one of the hosts is temporarily down. And if you go to http://validator.w3.org/nu/ you might get lucky and hit a different host and it'll work.
On the other hand if you get a 404 from http://validator.w3.org/nu/
it most likely means you caught me in the middle of restarting/redeploying the W3C HTML5 validator backends to pull in changes I've made to the sources from https://github.com/validator/validator
But that never takes me more than a few minutes, so on your end you should never be seeing that 500 error for more than, say, 10 minutes at most. So if/when you do see it for any longer than that, please report it either by tweeting to #w3c or #sideshowbarker on twitter, or pinging me on IRC (MikeSmith on #whatwg or #w3c on irc.freenode.net).
I think it's pretty clear from the error that it's a problem at their end:
Checking the Document Type of this document requires the help of an external tool which was either not enabled in this validator, or is currently unavailable. Check in the validator's system configuration that HTML5 Validator is enabled and functional.
The error encountered was: 500 Can't connect to localhost:8888 (connect: Connection refused)
(My emphasis.) I expect they'll get it fixed Right Quick Like.
We were getting the following error while checking the domain in W3C validator and we managed to fix it by installing CA Bundle and Intermediate Root certificates for the same domain. Now, the domain is able to pass through the W3C validation check and reporting appropriate result.
===================================
Sorry! This document cannot be checked.
Error
I got the following unexpected response when trying to retrieve <https://our-xx-domain.in/>:
500 Can't connect to our-xx-domain.in:443
If you made recent changes to your domain name (DNS) configuration, you may also want to check that your domain records are correct, or ask your hosting company to do so.
===================================