We had OJS 3.1.1.4 on Windows in XAMPP and the Plugin Gallery was displaying plugins. Later on, we upgraded to 3.1.2.1 and then to 3.1.2.4. When I go to the Plugins tab, I don’t see a Plugin Gallery (see screenshot). Am I missing something that I need to enable somewhere?
Before creating this topic, I read half a dozen threads about the empty Plugin Gallery on the forum, made sure that we have “allow_url_fopen=On” in php.ini, and no proxy is setup in config.inc.php. When I try to see an error in php_error_log, there is none, although it shows other events, because I set “error_reporting=E_ALL” in php.ini. I am on Chrome 79 and cleared cache/reloaded, but at no avail. The only message in Debugging Tools > Console is:
jquery.min.js?v=3.1.2.4:2 [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help, check https://xhr.spec.whatwg.org/.
send @ jquery.min.js?v=3.1.2.4:2
If someone could help me sort this out, I would be very grateful!
Naive approach: You could use the XAMPP shell and try whether you can ping, telnet or ssh pkp.sfu.ca (I do not have XAMPP on windows). Also, is curl library on PHP enabled?
Pinging pkp.sfu.ca [204.187.13.80] with 32 bytes of data:
Reply from 204.187.13.80: bytes=32 time=75ms TTL=57
Reply from 204.187.13.80: bytes=32 time=76ms TTL=57
Reply from 204.187.13.80: bytes=32 time=75ms TTL=57
Reply from 204.187.13.80: bytes=32 time=75ms TTL=57
In php.ini, I have “extension=curl”, as well as:
curl.cainfo=“C:\xampp\apache\bin\curl-ca-bundle.crt”
openssl.cafile=“C:\xampp\apache\bin\curl-ca-bundle.crt”
I wonder whether anyone else, (perhaps, people who designed and maintain this wonderful software), can suggest something else to try? It would be great to finally have a Plugin Gallery, especially since we have the latest version of OJS installed.
I can’t think of anything relevant that changed in the OJS codebase between OJS 3.1.1-4 and 3.1.2-4, so I suspect something changed in the underlying tools. To debug this, I’d suggest working with error_log in the relevant code, particularly in lib/pkp/classes/plugins/PluginGalleryDAO.inc.php:
private function _getDocument() {
$doc = new DOMDocument('1.0');
$gallery = FileWrapper::wrapper(PLUGIN_GALLERY_XML_URL);
$doc->loadXML($gallery->contents());
return $doc;
}
This is the function that fetches the plugin list from the PKP server (https://pkp.sfu.ca/ojs/xml/plugins.xml, defined at the head of that file). I suspect you’ll find that $gallery->contents() is failing to return the contents of that XML file.
As you’ll probably need to dig further, see lib/pkp/classes/file/wrappers/HTTPSFileWrapper.inc.php, and lib/pkp/classes/file/wrappers/HTTPFileWrapper.inc.php; some error_log calls before the error condition returns would probably narrow down the issue.
If I had to guess, I suspect it’s something to do with your SSL toolset that’s failing to negotiate with the PKP server’s implementation of the same.
Regards,
Alec Smecher
Public Knowledge Project Team
I am not sure how to do the debugging. I just changed “Enable database debug output (very verbose)” to “On” in config.inc.php, tried to reload the Plugin Gallery page and saw thousands of lines in php_error_log, but none has the word “Gallery” in it.
Should I go to Debug Settings in config.inc.php and set all/some of the following to on?
show_stacktrace = Off
display_errors = Off
deprecation_warnings = Off
log_web_service_info = Off
If yes, what would I need to do then? Reload the Plugin Gallery page and go to php_error_log again? Or do something else?
I still assume that it is the firewall. Since ping uses ICMP and does not use ports, you may reach pkp.sfu.ca . You should check that ports 80 and 443 are open.
The approach I’m suggesting above will require a small amount of PHP expertise – it’s to add calls to PHP’s error_log function at various points in the source code to determine what is happening when the system tries to load the plugin gallery. But @mpbraendle’s suggestion is a good one to pursue too, and doesn’t require modifying the PHP code.
Regards,
Alec Smecher
Public Knowledge Project Team
Thank you, @asmecher. I tried @mpbraendle’s suggestions, setting temporarily all inbound connections to “Allow”, while outbound connections have already been set to “Allow”. I can start telnet and ssh sessions to pkp.sfu.ca on port 22:
login as: test
Keyboard-interactive authentication prompts from server:
Password:
However, clearing cache in Chrome or IE and re-opening the Plugin Gallery still gives me the same page with no items.
After I set firewall back to blocking incoming connections no matching a rule, SSH and Telnet sessions to pkp.sfu.ca still work, so I am not sure what else to try firewall wise. If nothing else comes to mind, then perhaps I should try looking into adding calls to error_log. If you could point me toward a resource covering that, I would read-up and try it here.
Hi @asmecher, I changed error_reporting in php.ini to E_ALL and now, when I try to load the Plugin Gallery page, I see in php_error_log the following warnings:
Declaration of UploadPluginForm::execute() should be compatible with Form::execute(…$functionArgs) in C:\xampp\htdocs\journal\lib\pkp\controllers\grid\plugins\form\UploadPluginForm.inc.php on line 22
fsockopen(): SSL: Handshake timed out in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): Failed to enable crypto in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): unable to connect to ssl://pkp.sfu.ca:443 (Unknown error) in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): SSL: Handshake timed out in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): Failed to enable crypto in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): unable to connect to ssl://pkp.sfu.ca:443 (Unknown error) in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
DOMDocument::loadXML(): Empty string supplied as input in C:\xampp\htdocs\journal\lib\pkp\classes\plugins\PluginGalleryDAO.inc.php on line 61
These lines refer (respectively) to:
===============================
UploadPluginForm.inc.php line 22 :
class UploadPluginForm extends Form {
===============================
HTTPFileWrapper.inc.php line 77 & 78:
if (!($this->fp = fsockopen($host, $port)))
return false;
===============================
PluginGalleryDAO.inc.php line 61:
$doc->loadXML($gallery->contents());
I see that you replied to another user, who had similar PHP warnings, a year ago, that it was known issue in 3.1.1-4, but I am at 3.1.2-4, so it probably doesn’t apply.
I made sure that OpenSSL is installed and my site is properly redirecting 80 to 443. I wonder what else could try.
fsockopen(): SSL: Handshake timed out in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): Failed to enable crypto in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): unable to connect to ssl://pkp.sfu.ca:443 (Unknown error) in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): SSL: Handshake timed out in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): Failed to enable crypto in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
fsockopen(): unable to connect to ssl://pkp.sfu.ca:443 (Unknown error) in C:\xampp\htdocs\journal\lib\pkp\classes\file\wrappers\HTTPFileWrapper.inc.php on line 77
These relate to your installation being unable to fetch the list of plugins from the PKP server due to an underlying problem in the PHP/SSL setup on your server. When you say OpenSSL is installed, do you mean the PHP module?
Regards,
Alec Smecher
Public Knowledge Project Team
Apache Environment-> OPENSSL_Conf: C:/xampp/apache/bin/openssl.cnf
(this section also has 27 lines for our SSL cert, such as SSL_TLS_SNI, SSL_SERVER_S_DN_O, etc.)
curl → SSL: Yes; SSL Version: OpenSSL/1.1.0i
mysqlnd → core SSL: supported; extended SSL: not supported
PHP Variables:
$_SERVER[‘OPENSSL_CONF’] C:/xampp/apache/bin/openssl.cnf
+31 lines, most of which are the same as the ones in Apache Environment
<…>
$_SERVER[‘SERVER_SIGNATURE’]: Apache/2.4.35 (Win32) OpenSSL/1.1.0i PHP/7.2.11 Server at domainname.ca Port 443
$_SERVER[‘SERVER_SOFTWARE’]: Apache/2.4.35 (Win32) OpenSSL/1.1.0i PHP/7.2.11
Thank you, @asmecher. I checked the firewall rules. Incoming HTTP is enabled for 80 and 443. In Outbound rules, I see only BranchCache Content Retrieval (HTTP-Out) on port 80 and BranchCache Hosted Cache Client (HTTP-Out) on 80, 443, both disabled.
But it I ran netstat for 443, it looks like there are connections established.
C:\Windows\system32>netstat -ano | findstr :443
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 6332
TCP myipaddress:7834 externalipaddress1:443 ESTABLISHED 4672
TCP myipaddress:8489 externalipaddress2:443 ESTABLISHED 4672
TCP myipaddress:8500 externalipaddress2:443 ESTABLISHED 4672
TCP myipaddress:8508 externalipaddress3:443 ESTABLISHED 4672
TCP [::]:443 [::]:0 LISTENING 6332
Finally, to try outgoing 443 connections, I used a site that is answering to outside request, so I got this.
$ telnet portquiz.net 443
Trying …
Connected to portquiz.net.
Escape character is ‘^]’.
$ nc -v portquiz.net 443
Connection to portquiz.net 443 port [tcp/daytime] succeeded!
$ curl portquiz.net:443
Port 443 test successful!
Your IP: myIPaddress
$ wget -qO- portquiz.net:443
Port 443 test successful!
Your IP: myIPaddress
It looks like the firewall is not blocking port 443. As to whether outgoing connections need to be proxied, I have never heard about that before, so I am not sure how to check. I manage an EZproxy server, but it is sitting on its own machine, but that’s the only time I deal with proxy connections.
So I think you’ll need to debug this in PHP. The easiest way to do that is to pull the relevant operations out into a short test script and work with that. This short script should capture the necessary operations:
When you run this (through the command line or through the browser) it should dump the contents of https://pkp.sfu.ca/ojs/xml/plugins.xml. However, in your case, I suspect it’ll generate the same errors you’ve seen before. Can you verify?
Regards,
Alec Smecher
Public Knowledge Project Team