Allow_url_fopen Fresh Phoenix Install

[greasemonkey 190]

Hey all, I’m starting fresh with Phoenix 1.0.5.0 and I’m stuck on the first page of install. 
 

I’ve confirmed with cPanel mutliPHP INI editor that it is turned on for this add on domain (URL). And also uploaded a phpinfo file and confirmed. 
 

 

[burt 5,435]

https://stackoverflow.com/questions/13433660/how-to-check-if-allow-url-fopen-is-enabled-or-not

Upload a new .php file containing;

<?php
echo (ini_get('allow_url_fopen')) ? 'Fopen ON' : 'Fopen OFF';

And see what it says...

[azpro 144]

Scott .. did you restart apache?

[greasemonkey 190]

@azpro no didn’t restart - however would (not an expert) presume because it’s recognized by phpinfo and cPannel that it wouldn’t necessary?

 

@burt I’ll give it a try tmr. 

[greasemonkey 190]

17 hours ago, burt said:

https://stackoverflow.com/questions/13433660/how-to-check-if-allow-url-fopen-is-enabled-or-not

Upload a new .php file containing;

<?php
echo (ini_get('allow_url_fopen')) ? 'Fopen ON' : 'Fopen OFF';

And see what it says...

@burt the output is

Fopen ON

Could it be a cache issue (I don't think so, I've tried in in a couple different browsers)? Or maybe its looking at the wrong dir php.ini file? Example: html_public in place of html_public/myaddondomain.com

[burt 5,435]

https://github.com/gburton/CE-Phoenix/blob/master/install/templates/pages/index.php#L56

comment it out, by adding a double slash in front.  That will allow your install to continue.

I may need to change that line of code - thanks for the heads up. 

Edited February 26, 2020 by burt

[burt 5,435]

Even better, instead of commening out that line, would you instead change this line

https://github.com/gburton/CE-Phoenix/blob/master/install/templates/pages/index.php#L55

to

if(!ini_get('allow_url_fopen')) {

 

and that should allow you to continue.  And is a better fix.

[greasemonkey 190]

@burt it will only allow me past if I comment it out.

/*	if(!ini_get('allow_url_fopen')) { 
      $warning_array['allow_url_fopen'] = 'Fopen Wrappers must be turned on.  This is a <em>hosting</em> setting which you or your host may be able to change by setting allow_url_fopen to "1" or "On" in php.ini';
    }*/

I'm in no huge rush if you wanted to test something else....

Of course it still gives the thumbs down - which I presume is only a display...

Edited February 26, 2020 by greasemonkey
added text

[greasemonkey 190]

@burt as a follow up. After install i do see the error in dashboard

allow_url_fopen must be enabled in php.ini
This is a hosting setting and may be able to be performed via your hosting control panel - if not, ask your host.

and the export fort server info shows

allow_url_fopen = 0
allow_url_include = 0

Despite the earlier test (and just recheck) shows

Fopen ON

 

[Robbogeordie 10]

I'm also having this issue.

If you put @burt code in a new file in your admin folder and check the output my guess is that it will still be: Fopen  Off

If your custom php.ini is not recursive then the PHP Values In Your custom php.ini are not inherited by any Subdirectories, so Fopen will be on in the root folder, but nowhere else.

I've not fixed mine yet because it's throwing another error due to a missing dll, but to make your custom php.ini recursive add this code to .htaccess :

suPHP_ConfigPath /home/USERNAME/public_html

Some information here:

https://www.inmotionhosting.com/support/website/recursive-php-ini/

 

[Robbogeordie 10]

Some more info here:

https://www.pickaweb.co.uk/kb/inherit-php-values-in-your-local-php-ini-to-all-subdirectories/

[Robbogeordie 10]

Here's how I fixed it.
I removed the recursive code that I'd put in my .htaccess and simply copied the php.ini file to my admin directory instead. Fopen On in admin
Voila, simple as that.

[greasemonkey 190]

Yes, moving the php.ini file to admin removes the error.

[Fast4u 0]

I have the same issue on a fresh installation of Phoenix v1.0.7.9. I have a big warning in the Admin section "allow_url_fopen must be enabled in php.ini".

I can't enable this setting in php.ini with my hosting provider.

Need to have a virtual private server to enable it.

The website seem to work well, before going further, what will be the impact if i can't turn on this setting?

Do i really need upgrade to VPN?

Thank's

 

 

 

[burt 5,435]

56 minutes ago, Fast4u said:

The website seem to work well, before going further, what will be the impact if i can't turn on this setting?

Minor

• You will not be able to view certain things (eg the certified_addons page in admin).

Major

• You will not be able to update currencies

I will look at doing something to combat that in 1.0.7.10 as currencies is obviously an important part of core and the certified_addons page is important in helping to keep the whole project alive

Edited October 10, 2020 by burt

[Omar_one 149]

ago, burt said:

 

I will look at doing something to combat that in 1.0.7.10 as currencies is obviously an important part of core and the certified_addons page is important in helping to keep the whole project alive

 

Maybe using cURL instead will fix the issue. 

Edited October 10, 2020 by Omar_one

[♥ecartz 693]

23 minutes ago, Omar_one said:

Maybe using cURL instead will fix the issue. 

Although then you have the problem of when curl isn't available. 

It might be overengineering, but a generic remote file access class that could use whatever was available might be worth it.  

A beginning:  https://stackoverflow.com/questions/3979802/alternative-to-file-get-contents/21177510#21177510

Note that that still hard codes some of the curl options, which should probably be configured or parameterized instead.  I'd be willing to write something, but testing it would be a pain.  Because we would have to find people with all the alternatives or recreate all the different setups to verify that the failovers worked correctly. 

[♥ecartz 693]

Never mind.  Burt already did:  https://github.com/gburton/CE-Phoenix/commit/84812c63fc854d405b023b48064a96df47c85b1c

[burt 5,435]

13 hours ago, ecartz said:

Never mind.  Burt already did:  https://github.com/gburton/CE-Phoenix/commit/84812c63fc854d405b023b48064a96df47c85b1c

This is tested on a live shop with fopen_wrappers off - the URL is gotten via Curl then and everything appears to work as it should, both the "reading" things (dashboard, certified addon page) and the functionality (currency update).

With both fopen_wrappers off and Curl off, the advice would have to be one of: 

• enable fopen_wrappers
• enable curl
• new host"