Why has json_decode started returning NULL?

PHP
21

Ok, the only thing I can think of, and what I initially thought was causing this is the data inside some of the key/value pairs. In particular the description.

Example,
This is what is inside some of the items descriptions:

"DESCRIPTION": "▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬\\n Playing bass 'Barry'. \\n\\nThe Band\\n EXAMPLE\\n\\n\"an underground party and so on"

I then pasted this inside the $json = “” on the page which returned NULL.

I then removed some of the " and ’ which was causing the code to open and close, in particular ‘Barry’ which broke the flow of the json.

It then displayed the json

So I think it might have something to do with the quotation marks and apostrophes causing the conflict and resulting in a NULL value…

Is there a way to check this or force and replace/decode function so the quotation marks and apostrophes don’t break the copy? Likewise for any other special characters?

Barry

22

I’ve just ran the below again:

$indata = 'http.....events.json';
var_dump($indata);

$json = json_decode($indata, true);
var_dump($json);

$data = file_get_contents('http.....events.json');
var_dump($data);

This time:

string(59) “http…events.json”
NULL
string(0) “”

If anybody gets a eureka moment would be great to hear back, thanks.

Barry

23

1450×810 35.1 KB
1600×226 103 KB

This is only locally so I am not sure if it is because of the file or if it’s because file_get_contents or if it’s because of your host. But you can try adding in the URL and see if it helps. Other than that, I still believe it’s because of file_get_contents and that maybe your host disabled this featured in a new update. If it doesn’t work with cURL as well, then it’s because of your file. You might want to escape the double quotes as I have said above. This could also cause the problem.

24

This:

$indata = 'http.....events.json';
var_dump($indata);

is missing the file_get_contents(), so it’s just assigning a string and therefore the rest doesn’t do anything incorrectly.

I just did a quick test with some very basic data and didn’t manage to duplicate the problem with quotations or apostrophes inside a string. Have you only just started putting these symbols inside the data strings, to coincide with when this stopped working? If not, then I wouldn’t imagine it’s the issue. Do you use standard json_encode() and json_decode() to create and extract the data?

So, after this

$indata = file_get_contents('events.json');
var_dump($indata);

do you get anything at all? If you just get false, then file_get_contents() isn’t reading the data from the file.

1 Like
25

Yes the json file is well-formed and has no issues even with symbols in, already checked this. It’s only when I wrapped the $json variable around instead of calling the file I seen the problems within PHP.

The events.json updates with new data/events every week. The description sometimes has special characters and sometimes not. It depends what other people feed into them - the symbols are changing every time I update the file.

I decode it, stripslashes_deep and feed the DB with a INSERT statement. Then simple php query when I return the results from DB.

It returns - string(0) ""

And I just came across:

Check file_get_contents PHP Manual return value. If the value is FALSE then it could not read the file. If the value is NULL then the function itself is disabled.

??

Barry

And thanks spaceshiptrooper, as mentioned, I already tried this returning the same error. I’ve just emailed my host to see if anything has changed - just to make sure.

26

I’ve just ran a test using the below inside the events.json

[
        {
          "LANG": "PHP",
          "NAME": "Barry"
        },
        {
          "LANG": "SQL",
          "NAME": "Barry1"
        },
        {
          "LANG": "C",
          "NAME": "Barry2"
        },
        {
          "LANG": "JS",
          "NAME": "Barry3"
        }
]

Result without descriptions and special characters:

string(0) “” NULL string(0) “”

:expressionless:

??

Barry

27

OK, so now at least you know that it’s not to do with json_decode() or the way you’re encoding it in the first place, it’s to do with file_get_contents() not being able to do what it needs to. I can’t offer any ideas why not, unfortunately, I presume you’ve checked for locations, permission codes and so on.

28

That’s the thing - I haven’t changed anything besides upload a couple of basic files.

I’ve submitted a support ticket to my host provider, hopefully they get back soon or tomorrow, until then I’ll see what they say and report back and hopefully, ha wishful thinking, find a solution of what’s causing this :slight_smile:

Anyhow, until then, thanks for your time guys!

Chat soon, Barry

29

Only 2 things that are causing this; your host or file_get_contents. I’ve tried this on my live host running PHP 7 and it is running perfectly fine.

If it’s possible, I would like to connect to that specific Json file because it may also be causing the problem. I know you don’t want the content taken and I pretty much don’t really care for content. I’d rather be helping. But it would be great if I can get a hands on work with what you actually have. —Try to debug it from my end and then compare the difference and maybe try to figure out a solution.

30

Thanks spaceshiptrooper

I can’t give access to client files, though appreciate the help!

One thing I have just tried while waiting for response from host.

I ran the below inside a blank php file from inside my local host:

$json = json_decode(file_get_contents('http://www.example.com/events.json'), true);
var_dump($json);

It printed the full file and data from the server

What does that mean?
I can get access to the file and print the data on my localhost which has PHP Version: 5.6.2

Thanks, Barry

31

Don’t believe it!

@droopsnoot @spaceshiptrooper @Mittineague

Host got back, ran a test:

echo 'file_get_contents: ', file_get_contents(__FILE__) ? 'Enabled' : 'Disabled';

file_get_contents: Enabled

Also tells me I can update my PHP version via htaccess:
AddHandler application/x-httpd-php55 .php

Is this a good idea?

Anyhow, I ran the php5 version and accidently got an error from my include_once snippet:

Warning: include_once(): http:// wrapper is disabled in the server configuration by allow_url_include=0…

…which then directed me to (after quick google search) something about…

"The warning is generated because you are using a full URL…

So I changed:

$json = json_decode(file_get_contents('http://www.example.com/events.json'), true);
to
$json = json_decode(file_get_contents('events.json'), true);

And it worked! :grinning:
Tested both php versions works on both.

The error was the absolute URL
I must of changed it one night and not realised.

Three nights… turns out to be absolute URL :sunglasses:

So what does that mean, I can’t use an absolute url in this instance?
And how does allow_url_include=0 fit into all this, something I need to worry about/change?

Remembering the absolute url worked from my localhost but does not run while on the server.

Cheers, Barry

32

I am glad you found a solution.

That’s not entirely correct. I just did a quick test using my live Json file that gets generated using database calls and tried to connect to it using my localhost and the full path and it didn’t complain about anything and it also displayed the data. I am using PHP 5.6 on my BunsenLabs OS. I think it’s probably because your host has a weird configuration. I would recommend switching to a host that allows you to use php.ini instead of using .htaccess. php.ini allows you to do much more stuff like modify how long a cookie lasts or even where your server is located. You can modify all these properties and even modify file_get_contents to your will. You can enable or disable it as well. That’s the great use of php.ini. .htaccess has very limited use in my eyes. I’d rather have a host that allows me to modify my php.ini. That’s just me.

1 Like
33

Having “allow” enabled introduces some security risk which is why a shared host may want it disabled.
It was my first guess as to what the problem was, but the OP shows the use of a relative URL not an absolute URL so I ruled that out.

1 Like
34

It’s not really to do with absolute vs relative URLs. The difference is that if you specify a filename, like events.json, it’s going to try to load that directly from the file system rather than via HTTP.

As Mittineague pointed out, some hosts disable the fetching of files from a URL (i.e potentially from a 3rd party server) due to the security risks.

2 Likes
35

Ah, to me this does show the down side of over-sanitising live code for forum posts. For example, way back in post one, you showed us this code, which had stopped working:

$json = json_decode(file_get_contents('events.json'), true);

but it turns out your original code was more like

$json = json_decode(file_get_contents('http://www.example.com/events.json'), true);

and you changed it to

$json = json_decode(file_get_contents('events.json'), true);

to get it working again.

As @fretburner said above, the leading ‘http’ changes the way that file_get_contents() operates, and requires a specific configuration that might be disabled. It isn’t so much that you’ve changed it from an “absolute URL”, it’s that you’ve changed it from a URL to a filename. The main thing here is that fgc() has to be specifically configured to allow you to use URLs rather than local files, and it might have been an early thing to tick off the list. It worked on your localhost because it’s the configuration of the server that’s running the PHP code that decides whether or not to allow it, and by default a lot of development machines are configured to allow everything. Mine certainly is, because I’ve haven’t got to a level where I need to deal with real hosts and I just need to have things work.

Anyway, I’m also glad you’ve got it working even if it doesn’t sound like it.

1 Like
36

Thanks all!

Been a bit of a whirlwind the past few nights, though final got there :sunny:

And yes, as a few of you mentioned, I originally posted the relative file and only introduced the absolute url in #15, apologies had no idea this was the problem. Albeit, I think we all learned a little - a good exercise and no doubt something that could come in handy further down the line :slight_smile:

Well, can now bring this to a close :sunglasses:

And thanks for the deep explanations of what has happened here, really helps moving forward.

Cheers, Barry

1 Like
37

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.