Hello.

I transferred a v.6.16 installation to another web host.

When I logged in as admin then clicked on modules et al, the following message (abbreviated) displayed and made it where the admin pages were no longer accessible unless I used the back button until I reached an earlier page:

(Note: I'm typing this from paper copy versus copy/paste since it is no longer on screen)
~~~~~~~~~~~~~~~
Fatal error: Uncaught SoapFault exception: [WSDL] SOAT-ERROR: Parsing WSDL. Couldn't load from 'https://api.verticalresponse.com/wsdl/1.0/VRAP.wsdl' : Start tag expected, '<' not found in /usr/home/account/public_html/.../all/modules/vr/vr.module:138 Stack trace: #0 /usr/.../vr/vr.module(138):

SoapClient->SoapClient('https://api.ver...') #1 ........
~~~~~~~~~~~~~~~

The only solution to prevent the module from being detected was to change the module name but the name couldn't be e.g. 'vr--', it had to be something like '.vr'. Then I could access all of the administer pages.

Thanks.

CommentFileSizeAuthor
#3 vr-wsdl-754702.patch1.35 KBaaronbauman

Comments

jbomb’s picture

jbomb commented

Thanks for the report. I've encountered this error before. I think it has something to do with the server configuration for SSL or CURL. I don't remember the specifics. Anyway, I believe the work-around is to download the .wsdl file and host it locally. The SOAP instantiation should be wrapped in a try catch directive to avoid that WSOD.

I'll roll a patch.

[edit]

Here a relevant PHP bug report. A specific explanation of the problem exists at the end of the thread.

We investigated the problem very close and discovered that the reason is with libxml libraries statically compiled into PHP.
Details: PHP is compiled with the following XML related options:
--with-xml=/hsphere/shared
--with-libxml-dir=/hsphere/shared
--with-xmlrpc=shared

If libxml2 static library is available in the {prefix} directory (libxml2.a), PHP includes libxml2 library into itself at buildtime.
In that case, soap FAILS to work with https.

If libxml2 shared library is available in the {prefix} directory (libxml2.so), PHP doesn't includes libxml2 library into itself at buildtime, but seach the library at runtime.
In that case, soap works with https fine.

There is another thread here.

Hope this helps.

jbomb’s picture

jbomb commented

Have you tried hosting the .wsdl file (https://api.verticalresponse.com/wsdl/1.0/VRAPI.wsdl) locally and changing the following in vr.module

<?php
  // Replace
  // $wsdl = 'https://api.verticalresponse.com/wsdl/1.0/VRAPI.wsdl';
  // With something like
  $wsdl = drupal_get_path('module', 'vr') . '/VRAPI.wsdl';
  $vr = new soapClient($wsdl);
?>

Or have you had any luck resolving this issue otherwise? I'm not sure how to patch the module as this seems to be a server configuration issue.

aaronbauman’s picture

aaronbauman
he/him
commented
Status: Active » Needs review
StatusFileSize
new vr-wsdl-754702.patch1.35 KB

Attached patch does 2 things:
1. Tries to load a local wsdl in root vr directory (as in comment #2). If no local wsdl exists, tries to load the remote wsdl.
2. Wraps SoapClient instantiation in try-catch block.

drupert55’s picture

drupert55 commented

Hello folks and thanks for providing the info.

I'm trying to get back to this as soon as I can. I have to finish the initial stage of a project first. I did check and WSDL is stored on the server.

Thanks.

jbomb’s picture

jbomb commented
Title: 'Fatal error: Uncaught SoapFault exception...' after transferred web host » Provide option to host .WSDL locally.
Version: 6.x-1.0-alpha3 » 6.x-1.x-dev
Category: bug » feature
brewern’s picture

brewern commented

I can confirm this patch works. However after applying the patch I discovered the reason I was getting the fatal error to begin with. The error was a result of not having SSL support in the build of PHP. Essentially I had to enable SSL support. Then it worked!

aaronbauman’s picture

aaronbauman
he/him
commented
Status: Needs review » Fixed

This is (finally) into dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.