Przerzuciłem się na PHP 5.6.0 i teraz wszędzie dostaję następujące ostrzeżenie:
Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will
be removed in a future version. To avoid this warning set
'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream
instead. in Unknown on line 0
Warning: Cannot modify header information - headers already sent in Unknown on line 0
Dobrze, polegam na jakiejś przestarzałej funkcji. Tylko że ja nie!
- Nigdy nie użyłem tej zmiennej w żadnym z moich skryptów. Szczerze mówiąc, nie miałem pojęcia, że w ogóle istnieje.
phpinfo()
pokazuje, że mamalways_populate_raw_post_data
ustawione na 0 (wyłączone). Więc, co się dzieje?
Nie chcę „unikać ostrzeżenia”, ustawiając tę wartość na -1. Spowoduje to ukrycie ostrzeżenia i nadal będę mieć przestarzałą konfigurację. Chcę rozwiązać problem u jego źródła i wiedzieć, dlaczego PHP uważa, że HTTP_RAW_POST_DATA
wypełnianie jest włączone.
Odpowiedzi:
Okazuje się, że źle zrozumiałem komunikat o błędzie. Powiedziałbym, że zawiera bardzo słaby dobór słów. Googlowanie po okolicy pokazało mi, że ktoś inny źle zrozumiał wiadomość dokładnie tak, jak ja - zobacz błąd PHP # 66763 .
Po całkowicie niepomocnym „Tak właśnie chcieli RMs”. W odpowiedzi na ten błąd Mike'a, Tyrael wyjaśnia, że ustawienie go na „-1” nie oznacza jedynie ostrzeżenia o zniknięciu. Robi właściwą rzecz , tzn. Całkowicie wyłącza zapełnianie zmiennej winowajcy. Okazuje się, że ustawienie wartości 0 NADAL zapełnia dane w pewnych okolicznościach. Porozmawiaj o złym projekcie! Aby zacytować PHP RFC :
Więc tak, ustawienie go na -1 nie tylko pozwala uniknąć ostrzeżenia, jak powiedział komunikat, ale także ostatecznie wyłącza zapełnianie tej zmiennej, o co mi chodziło.
źródło
always_populate_raw_post_data = -1
. wciąż nadchodzi ostrzeżenie iphp.ini
pliku i ustawienie (lub odkomentowanie)always_populate_raw_post_data = -1
.To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead.
Minęło trochę czasu, zanim natknąłem się na ten błąd. Przedstaw moją odpowiedź każdemu, kto może natknąć się na tę kwestię.
Ten błąd oznacza tylko, że wysyłasz puste żądanie POST. Ten błąd często występuje w żądaniach HTTPRequests bez przekazanych parametrów. Aby uniknąć tego błędu, zawsze możesz dodać parametr do POST bez zmiany pliku php.ini.
Lubić:
źródło
Doświadczyłem tego samego problemu na serwerze nginx (DigitalOcean) - wszystko, co musiałem zrobić, to zalogować się jako
root
i zmodyfikować plik/etc/php5/fpm/php.ini
.Aby znaleźć linię z
always_populate_raw_post_data
pierwszym uruchomieniemgrep
:To zwróciło linię
704
Następnie po prostu otwórz
php.ini
ten wiersz wvi
edytorze:Usuń średnik, aby odkomentować go i zapisz plik
:wq
Na koniec zrestartuj serwer i błąd zniknął.
źródło
php.ini
, prawdopodobnie używasz rozwojowej konfiguracji php.ini.należy dodać lub odkomentować właściwość
always_populate_raw_post_data
wphp.ini
i ustawić jej wartość na-1
. W moim przypadkuphp.ini
znajduje się w:C:\wamp64\bin\php\php5.6.25\php.ini
Na koniec uruchom ponownie WAMP (lub kliknij Uruchom ponownie wszystkie usługi)
źródło
Jeśli
.htaccess
plik nie jest dostępny, utwórz go w folderze głównym i wklej ten wiersz kodu.Umieść to w
.htaccess
pliku (testowane działa dobrze dla API)źródło
Odkomentowanie pliku
w php.ini (linia nr 703) i ponowne uruchomienie usług APACHE i tak pomoże mi pozbyć się wiadomości
źródło
Dla każdego, kto nadal boryka się z tym problemem po zmianie php.init, jak sugeruje zaakceptowana odpowiedź. Ponieważ błąd występuje, gdy petycja Ajax jest wykonywana
POST
bez żadnego parametru, wszystko co musisz zrobić, to zmienić metodę wysyłania naGET
.Jeszcze inną opcją, jeśli chcesz zachować metodę
POST
z jakiegokolwiek powodu, jest dodanie pustego obiektu JSON do petititon ajax.źródło
Otrzymałem ten komunikat o błędzie podczas wysyłania danych z formularza html (metoda Post). Wszystko, co musiałem zrobić, to zmienić kodowanie w formie z „text / plain” na „application / x-www-form-urlencoded” lub „multipart / form-data”. Komunikat o błędzie był bardzo mylący.
źródło
Niestety ta odpowiedź @EatOng nie jest poprawna . Po przeczytaniu jego odpowiedzi dodałem zmienną fikcyjną do każdego odpalanego żądania AJAX (nawet jeśli niektóre z nich miały już jakieś pola), aby mieć pewność, że błąd nigdy się nie pojawi.
Ale właśnie teraz natrafiłem na ten sam cholerny błąd z PHP. Podwójnie potwierdziłem, że wysłałem trochę danych POST (kilka innych pól wraz ze zmienną fikcyjną). Wersja PHP
5.6.25
,always_populate_raw_post_data
wartość jest ustawiona na0
.Ponadto, gdy wysyłam
application/json
żądanie, PHP nie wypełnia go$_POST
, a raczej mam dojson_decode()
surowej treści żądania POST, dostępnej przezphp://input
.Jako odpowiedź @ rr- cites,
Ponieważ metoda żądania jest na pewno POST, myślę, że PHP nie rozpoznało / nie polubiło mojego
Content-Type: application/json
żądania (znowu, dlaczego ??).OPCJA 1:
Edytuj
php.ini
plik ręcznie i ustaw zmienną winowajcy na-1
, zgodnie z sugestiami wielu odpowiedzi.OPCJA 2:
To jest błąd PHP 5.6. Zaktualizuj PHP.
OPCJA 3:
Jak odpowiedział @ user9541305, zmiana
Content-Type
żądania AJAX naapplication/x-www-form-urlencoded
lubmultipart/form-data
spowoduje, że PHP$_POST
wypełni treść z postu POST (ponieważ PHP lubi / rozpoznaje tecontent-type
nagłówki !?).OPCJA 4: OSTATNI RESORT
Cóż, nie chciałem zmieniać
Content-Type
AJAX, spowodowałoby to wiele problemów przy debugowaniu. (Chrome DevTools ładnie wyświetla przesłane zmienne żądań JSON).Tworzę to dla klienta i nie mogę poprosić go o użycie najnowszego PHP ani o edycję pliku php.ini. W ostateczności sprawdzę tylko, czy jest ustawiony na,
0
a jeśli tak, edytujęphp.ini
plik w samym skrypcie PHP. Oczywiście będę musiał poprosić użytkownika o ponowne uruchomienie Apache. Jaka szkoda!Oto przykładowy kod:
źródło
Cóż, jeśli jest ktoś na współdzielonym hostingu i nie ma dostępu do
php.ini
pliku, możesz ustawić tę linię kodu na samej górze plików PHP:Działa bardziej tak samo. Mam nadzieję, że zaoszczędzi to komuś czasu na debugowanie :)
źródło
NB: JEŚLI UŻYWASZ PHPSTORM
Spędziłem godzinę próbując rozwiązać ten problem, myśląc, że to mój problem z serwerem php, więc ustawiłem „always_populate_raw_post_data” na „-1” w php.ini i nic nie działało.
Dopóki nie dowiedziałem się, że używanie wbudowanego serwera phpStorm jest przyczyną problemu, jak opisano szczegółowo w odpowiedzi tutaj: Odpowiedź od LazyOne Tutaj , więc pomyślałem o udostępnieniu go.
źródło
; always_populate_raw_post_data = -1 w php.init usuń komentarz z tej linii .. always_populate_raw_post_data = -1
źródło
Właśnie dostałem rozwiązanie tego problemu od znajomego. powiedział: Dodaj ob_start (); pod Twoim kodem sesji. Możesz dodać exit (); pod nagłówkiem. Spróbowałem i zadziałało. Mam nadzieję że to pomoże
To jest dla tych na wynajętym serwerze hostingowym, którzy nie mają dostępu do pliku php.init.
źródło