solved Failed test for: json support

[LeslieC]

Hey guys,

Have a question, I am installing PW on my server now and looks like I don't have json support on it. When I contacted my server provider I was told that my server doesn't support json extension  I don't understand why, because after reading about it looks like json its regular php extension. Well the question is; How important is json to PW, will PW work without any problem without json and will I loose some functionality? 

Thanks

Leslie

[Soma]

Hi lesliec

I'm not sure about other parts, but especially the hierachical page tree list in the admin uses json since it's ajax driven.

I don't think there's an easy workaround for this.

[drilonb]

Here is how to do that if you have your own VPS or if you don't have just ask your web hosting for this

First Step: run this command: pecl install json

When it’s done you should have a json.so file in your PHP modules directory.

This directory should be /usr/lib/php/modules/

Second Step: Add the json.ini file to /etc/php.d/ – to enable the extension add extension=json.so to this file

Third Step: Restart Apache

if you are using any sharing hosting maybe your PHP is older or something is wrong.

or follow this link

http://www.php.net/manual/en/json.installation.php

[Adam Kiss]

Were you informing about json support or requesting json support? Obviously, JSON support in PHP can be also turned off (well, obviously, the suprise is that somebody turns it off). I think you should request that they turn it on (it seems you're on shared hosting or having VPS managed by administrators), and if they don't, I would find another hosting, or contact somebody higher.

As for real need for JSON (above was rather about business with non-responsive company ) I will leave this up to Ryan, as he knows most about core (obviously), but I'm 90% positive it won't work without JSON support without major rewrite on your side.

[LeslieC]

I just switched to new provider (I use VPS) because of the service. Anyway, I asked them to turn on json and I was told that my server doesn't support it ( It runs fine on my local server, go figure). So I did some reading up on it and looks like that is not the case. I opened new support ticket wit them and awaiting answer.  :-\

---

Well that's done  ;D json is installed and PW is running  ;D

Thanks guys 

[Edit by Adam] Please do not double post

[Adam Kiss]

Congratulations!

---

It always makes me feel better (and think better about the company) if some hosting just adds some services, or gives me better solution, then when they go on their 'fucking noob doesn't know what he's talking about' rampage. Also it's good sign that they wish to have you as a customer, which is always good in bussiness.

[ryan]

Glad you got it working. It's pretty unusual for a webhost running PHP5 to not have JSON support, as it's part of PHP's default installation–they would have to specifically disable it. But I know there are some that install PHP and basically exclude everything possible... that usually means bigger problems than just missing JSON support.

There are workarounds for missing JSON functions. You can always define your own json_encode/json_decode functions and solve the problem that way. A good JSON library is the one included with the Zend framework. Years ago I dealt with a client's server that didn't have JSON support, so used Zend's framework and created the functions that way. It works, but much better to have them native in PHP (faster running).

[bitmatix]

Hey guys,

I've installed PHP 5.4.6 on my Mac and the phpinfo() says that I have json support:

json support enabled

json version 1.2.1

But when I try to install PW the check screens says: "Failed test for: json support".

Any ideas?

Thanks a lot!

[Soma]

Quick look at intall.php it turns out it parses the phpinfo() table and search for json support. It may fail because the phpinfo returned is different in php5.4. Are you still able to install it anyway?

[bitmatix]

Quick look at intall.php it turns out it parses the phpinfo() table and search for json support. It may fail because the phpinfo returned is different in php5.4. Are you still able to install it anyway?

Thank you for your fast replay Soma.

Yes, I was abled to install PW anyway and everything seems to work fine. I was just wondering about the "check" message.

[SiNNuT]

I haven't got a PHP 5.4 install to work with but i think Soma is right. A quick comparison of the phpinfo output on PHP<5.4 and 5.4 should explain why https://github.com/ryancramerdesign/ProcessWire/blob/master/install.php#L66 isn't finding json support correctly.

[SiNNuT]

I wonder if there aren't better ways to check for compatibility and such. For example php version checking in install.php. There are existing functions for that:

<?php if (version_compare(PHP_VERSION, '5.2.3', '>=')): ?>
<?php echo PHP_VERSION ?>
<?php else: ?>
PW requires PHP 5.2.3 or newer, this version is <?php echo PHP_VERSION ?>
<?php endif ?>

<?php !extension_loaded('iconv') ?>
<?php !function_exists('ctype_digit') ?>
<?php !function_exists('json_decode') ?>

etc

[ryan]

I wonder if there aren't better ways to check for compatibility and such. For example php version checking in install.php. There are existing functions for that:

Great ideas. Anyone want to do a pull request for this? Either way, I'll plan to get these updates in 2.3.

[SiNNuT]

Great ideas. Anyone want to do a pull request for this? Either way, I'll plan to get these updates in 2.3.

Ryan, i'll take a stab at it over the weekend.

[SiNNuT]

@ryan

I'd send you a pull request but for some reason my git client doesn't play nice when syncing to GitHub and totally screws up the diff, so no real help there. Instead i'll just attach it here. Basically 'protected function compatibilityCheckPHPInfo()' is gone and i've added that stuff to 'protected function compatibilityCheck()'. This way it doesn't rely on phpinfo() parsing. I've also changed the way the PHP version is checked. I've only done some trial and error testing and all seems well but you and/or other pro's should give it a good look before using it. I hope it can be of some use.

- edit - One of those days :S Forum software fucking with indentation. I'll just attach install.php.

/me grabs a beer, cheers

install.php

[ryan]

Thanks for this SiNNuT! Posting here is just as good as GitHub, doesn't matter to me. I will pull this into the dev branch and look at the changes and test, etc. Thanks again for these updates.

[ryan]

One minor question on the install update. I like that you've added the PCRE UTF-8 support check (nice!), but wondering if there's some way we can accomplish it without changing the encoding of the whole install.php file to UTF-8? The reason I ask is that once I pull the file into VIM, it's converting this line:

if(! @preg_match('/^.$/u', 'ñ')) {

to this:

if(! @preg_match('/^.$/u', 'ñ')) {

which would break it, once I hit save.

[SiNNuT]

One minor question on the install update. I like that you've added the PCRE UTF-8 support check (nice!), but wondering if there's some way we can accomplish it without changing the encoding of the whole install.php file to UTF-8? The reason I ask is that once I pull the file into VIM, it's converting this line:

if(! @preg_match('/^.$/u', 'ñ')) {

to this:

if(! @preg_match('/^.$/u', 'ñ')) {

which would break it, once I hit save.

I'm not sure about this. I got the code for this check from kohana framework because i'm not an expert on this.

Another one is:

00797		 protected function envCheckPCRE() {
00798				 if ( !function_exists( 'preg_match' ) ) {
00799						 $this->showError( 'config-pcre' );
00800						 return false;
00801				 }
00802				 wfSuppressWarnings();
00803				 $regexd = preg_replace( '/[\x{0430}-\x{04FF}]/iu', '', '-АБВГД-' );
00804				 // Need to check for \p support too, as PCRE can be compiled
00805				 // with utf8 support, but not unicode property support.
00806				 // check that \p{Zs} (space separators) matches
00807				 // U+3000 (Ideographic space)
00808				 $regexprop = preg_replace( '/\p{Zs}/u', '', "-\xE3\x80\x80-" );
00809				 wfRestoreWarnings();
00810				 if ( $regexd != '--' || $regexprop != '--' ) {
00811						 $this->showError( 'config-pcre-no-utf8' );
00812						 return false;
00813				 }
00814				 return true;
00815		 }

but i'm guessing this will have the same problem.

[slkwrm]

-АБВГД-

Why are they here?

Wanted to mention that all templates in PW use ANSI encoding by default, so cyrillic symbols don't display correctly if you put them right into template. It's not a problem for me to convert them to UTF-8 but it can cause a bit of trouble for newbies. Would be really nice to have them multilanguage-ready. I've never used VIM, but heard many legends how configurable it is

[SiNNuT]

Why are they here?

Well, i hardly understand any of this regex stuff but i seems like this is their way of testing for utf-8 support.

Wanted to mention that all templates in PW use ANSI encoding by default, so cyrillic symbols don't display correctly if you put them right into template. It's not a problem for me to convert them to UTF-8 but it can cause a bit of trouble for newbies. Would be really nice to have them multilanguage-ready. I've never used VIM, but heard many legends how configurable it is

Now that you mention it. Wouldn't it be a good thing that PW files are always encoded as UTF-8 without BOM. Maybe as part of some Coding Standards. Every decent editor allows you to easily set the file encoding (and conversion if needed).

[ryan]

Now that you mention it. Wouldn't it be a good thing that PW files are always encoded as UTF-8 without BOM. Maybe as part of some Coding Standards. Every decent editor allows you to easily set the file encoding (and conversion if needed).

Well if you are working in a text editor from the 1960s, then it's a little more tricky. But I found out how to get VIM in UTF-8 mode... just wish it knew how to auto detect it. I don't want to change the encoding on all the core files, but should be okay in specific instances like this install.php. Also sounds like I should change the default profile template files to UTF-8 encoding. Didn't realize they were showing up as ANSI for others--can't say as though I've ever seen that encoding in PW's files. For me they show up as either ASCII or Mac OS Roman with unix linefeeds, though I've always kept the character usage to pure ASCII except in specific instances (like InputfieldPageName.module).

[Soma]

Why are they here?

Wanted to mention that all templates in PW use ANSI encoding by default, so cyrillic symbols don't display correctly if you put them right into template. It's not a problem for me to convert them to UTF-8 but it can cause a bit of trouble for newbies. Would be really nice to have them multilanguage-ready. I've never used VIM, but heard many legends how configurable it is

ANSI isn't an encoding but rather extending the ASCII plain text to 8bit. Not sure though as ANSI was used for different things. So far I recognized no problems with the PW files as all, when opening they are in utf-8 in every editor I have. All website I've done use cyrillic chars and never got any issues with PW and never had to convert anything.

[ryan]

When I hear ANSI I immediately think of the codes we used to make graphics for our BBSs back in the day.

[slkwrm]

ANSI isn't an encoding but rather extending the ASCII plain text to 8bit. Not sure though as ANSI was used for different things. So far I recognized no problems with the PW files as all, when opening they are in utf-8 in every editor I have. All website I've done use cyrillic chars and never got any issues with PW and never had to convert anything.

Thanks for clarification, Soma. I use Notepad++ and it detects templates encoding (or expanding? ) as being ANCI. And if I put any cyrillic text to a template it looks broken in browser, so I convert it to UTF-8.without BOM. Maybe I should mention I use XAMPP running on Windows.

When I hear ANSI I immediately think of the codes we used to make graphics for our BBSs back in the day.

Reminds me some kind of 8-bit graffiti