New features - haven't got the hang of them yet...

[EdP]

Hi
1. The new feature of "CiviCRM Extensions" directory - I can find the link but every time i click I get error 001 and a note "Sorry. A non-recoverable error has occurred.
Public directory down or too slow - please contact CiviCRM team on forums."  Am I missing something obvious - like the the site not existing yet?

2. Logging: I've activated this, and I'm on PHP 5.2 with triggers permissions, so that should be fine. However, I can't work out (probably stupid) where I would see the logs. They aren't in the change log tab. Where should I be looking?

Thanks.

Ed

PS. J1.5 and Civi3.4

[Michał Mach]

Ed,

Regarding your extensions error:

Does the machine that your CiviCRM install is on have access to Internet when you try getting on CiviCRM Extensions screen? Is it behind firewall that doesn't allow it to reach out to the directory? Can you please try to access http://extdir.civicrm.org/ from this machine, if possible?

I should probably make the error message more descriptive, but let's solve your problem first.

When it comes to logging, once you've enabled it, you should see it in "Change Log" tab in contact view and in Reports in CiviReport menu.

Thx,
m

[EdP]

Thanks for your reply.

1. On the extensions, I'm not sure how I'd test that. The instance is running on a live webserver so I'm not sure how I'd call that URL from that machine. I have had problems calling a URL on the same machine before (which the hosting company doesn't like for some reason) but the website more generally can get RSS feeds and content from the internet generally (the CAPTCHAs work fine, for example).

2. Logging: I had a look on the demo site and mine isn't doing what the demo site does. I turned it off and on again and got a yellow fatal error screen for "DB Error: unknown error" and I couldn't open the details option. That's obviously rather unhelpful so I'll have to try to find a more useful error message or log than that somewhere. A real pity as the logging I saw on the demo site is really good and something I really need to use.

Thanks for your help.
E

[Michał Mach]

1. On the extensions, I'm not sure how I'd test that. The instance is running on a live webserver so I'm not sure how I'd call that URL from that machine. I have had problems calling a URL on the same machine before (which the hosting company doesn't like for some reason) but the website more generally can get RSS feeds and content from the internet generally (the CAPTCHAs work fine, for example).

Hm ,that's really strange.

Could you try putting a php file on your server and executing it (via browser or via shell), it should contain something like:

$extdir = file_get_contents('http://extdir.civicrm.org/');
echo $extdir;

It should display more or less the same as accessing above url directly. If it doesn't let me know what error message is there.

2. Logging: I had a look on the demo site and mine isn't doing what the demo site does. I turned it off and on again and got a yellow fatal error screen for "DB Error: unknown error" and I couldn't open the details option. That's obviously rather unhelpful so I'll have to try to find a more useful error message or log than that somewhere. A real pity as the logging I saw on the demo site is really good and something I really need to use.

I'll ask Piotr, who knows logging much better than me to help you debug.

Thx,
m

[Piotr Szotkowski]

Logging: I had a look on the demo site and mine isn't doing what the demo site does. I turned it off and on again and got a yellow fatal error screen for "DB Error: unknown error" and I couldn't open the details option.

Where did you get this yellow screen? On the log tab or somewhere else?

Do you see the logging reports?

Can you try disabling the logging logging and re-enabling it once again?

[EdP]

Piotr
Thanks. It was a yellow screen of death job, i.e. full screen error message with a yellow box - option to click to go back to the Home page but otherwise a full failure. Usually they give me the option of seeing some useful fault information but this one didn't. I've been away but will investigate further - appreciate that this does not help much by itself!

In a (probably) separate issue, now that I have updated to 3.4.1, the admin screen has started warning me that: "Your database is configured to use the MyISAM database engine. CiviCRM requires InnoDB. You will need to convert any MyISAM tables in your database to InnoDB. Using MyISAM tables will result in data integrity issues. This will be a fatal error in CiviCRM v2.1. "  Which is a little odd, given that I have been happily using Civi on this db without warnings for over a year and umpteen versions.

Ed

[Michał Mach]

In a (probably) separate issue, now that I have updated to 3.4.1, the admin screen has started warning me that: "Your database is configured to use the MyISAM database engine. CiviCRM requires InnoDB. You will need to convert any MyISAM tables in your database to InnoDB. Using MyISAM tables will result in data integrity issues. This will be a fatal error in CiviCRM v2.1. "  Which is a little odd, given that I have been happily using Civi on this db without warnings for over a year and umpteen versions.

Can you check what's the actual Mysql engine?

Thx,
m

[EdP]

1. Extensions: thanks for that script. Tried it and the log duly reported "[Fri May 13 16:41:54 2011] [error] [client IP....171] PHP Warning:  file_get_contents() [<a href='function.file-get-contents'>function.file-get-contents</a>]: URL file-access is disabled in the server configuration in /home/sites/DOMAIN/public_html/new/test.php on line 2
[Fri May 13 16:41:54 2011] [error] [client IP.....171] PHP Warning:  file_get_contents(http://extdir.civicrm.org) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: no suitable wrapper could be found in /home/sites/DOMAIN/public_html/new/test.php on line 2"

... so it looks as if the external call is banned.

2. Database - Yes, looking at the SQL files, the ENGINE= was set to MyISAM, although how come I don't know because this warning has only just come up having used CiviCRM for well over a year. Anyway, forcing it back to InnoDB seems to have solved both the warning and the logging problems.

Thanks for all the help.

[Michał Mach]

1. Extensions: thanks for that script. Tried it and the log duly reported "[Fri May 13 16:41:54 2011] [error] [client IP....171] PHP Warning:  file_get_contents() [<a href='function.file-get-contents'>function.file-get-contents</a>]: URL file-access is disabled in the server configuration in /home/sites/DOMAIN/public_html/new/test.php on line 2
[Fri May 13 16:41:54 2011] [error] [client IP.....171] PHP Warning:  file_get_contents(http://extdir.civicrm.org) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: no suitable wrapper could be found in /home/sites/DOMAIN/public_html/new/test.php on line 2"

... so it looks as if the external call is banned.

Ok, I'll ask you for your help in exchange. :-)

Can you add one line at the beginning of test.php script:

ini_set( 'allow_url_fopen', 1 );

and see if it changes anything?

Some hosting companies might be banning opening external URLs, so we'll need to think of a workaround.

Thx,
m

[EdP]

Hi, yes, I later tracked down that I could make it work with "allow_url_fopen=1" set in php.ini, but on balance I thought I was better off with it set to "0". It does mean, though, that I could temporarily allow it and use the extensions directory (very neat, once I got there!)

But some people may not have that option.

Thanks.
Ed

[Michał Mach]

Ok, cool - glad to hear that enabling it temporarily helped. I'll just add the code that enables it for the time of call to directory.

Thx,
m

[Chris Burgess]

I've just run into this error as well, with CiviCRM 3.4.5 on a somewhat locked down webserver (HTTP access via Squid only). Thing is, I'm trying to enable a custom module which is already sitting in the extensions directory, and having the extensions page throw a fatal error because it can't access a remote site is a bit of a grue.

I did this in CRM/Core/Extensions.php ...

Code: [Select]

        if( $extdir === FALSE ) {
            // CRM_Core_Error::fatal('Public directory down or too slow - please contact CiviCRM team on forums.');
        }

        $lines = explode( "\n", $extdir );

        foreach( $lines as $ln ) {
            if (preg_match ("@\<li\>(.*)\</li\>@i", $ln, $out)) {
                $extsRaw[] = $out;// success
                $key = strip_tags($out[1]);
                if( substr( $key, -4 ) == '.xml' ) {
                    $exts[] = array( 'key' => trim( $key, '.xml' ) );
                }
            }
        }

        if( empty( $exts ) ) {
            // CRM_Core_Error::fatal('Malformed extensions list on public directory - please contact CiviCRM team on forums.');
            $exts = array();
        }

That let me move on and enable my custom ext without remote access to extdir.civicrm.org. I did see a warning message after enabling the extension, but otherwise it seems to work fine.

warning: Invalid argument supplied for foreach() in /path/to/civicrm/CRM/Core/Extensions.php on line 266.

Unless there's a specific reason that we should throw a fatal error in that case, I suggest that we instead only, allowing manual uploads. This would retain full CiviCRM extensions functionality while eliminating the dependency on HTTP access.

I've opened this as http://issues.civicrm.org/jira/browse/CRM-8886