Hello,
We’re trying to get our installation of Omeka-s + Scripto up and running and we’re getting this error when creating a new Scripto user:
Zend\Http\Client\Adapter\Exception\TimeoutException: Read timed out after 10 seconds in /var/www/html/omeka-s/vendor/zendframework/zend-http/src/Client/Adapter/Socket.php:639
Stack trace:
#0 /var/www/html/omeka-s/vendor/zendframework/zend-http/src/Client/Adapter/Socket.php(443): Zend\Http\Client\Adapter\Socket->_checkSocketReadTimeout()
#1 /var/www/html/omeka-s/vendor/zendframework/zend-http/src/Client.php(1459): Zend\Http\Client\Adapter\Socket->read()
#2 /var/www/html/omeka-s/vendor/zendframework/zend-http/src/Client.php(940): Zend\Http\Client->doRequest(Object(Zend\Uri\Http), ‘POST’, true, Array, ‘action=createac…’)
#3 /var/www/html/omeka-s/modules/Scripto/src/Mediawiki/ApiClient.php(1012): Zend\Http\Client->send(Object(Zend\Http\Request))
#4 /var/www/html/omeka-s/modules/Scripto/src/Mediawiki/ApiClient.php(931): Scripto\Mediawiki\ApiClient->request(Array)
#5 /var/www/html/omeka-s/modules/Scripto/src/Controller/PublicApp/IndexController.php(49): Scripto\Mediawiki\ApiClient->createAccount(‘newtest1203’, ‘NewTest13’, ‘NewTest13’, ‘jhayton@histori…’, ‘’)
#6 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/Controller/AbstractActionController.php(78): Scripto\Controller\PublicApp\IndexController->createAccountAction()
#7 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Zend\Mvc\Controller\AbstractActionController->onDispatch(Object(Zend\Mvc\MvcEvent))
#8 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\EventManager\EventManager->triggerListeners(Object(Zend\Mvc\MvcEvent), Object(Closure))
#9 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/Controller/AbstractController.php(106): Zend\EventManager\EventManager->triggerEventUntil(Object(Closure), Object(Zend\Mvc\MvcEvent))
#10 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/DispatchListener.php(138): Zend\Mvc\Controller\AbstractController->dispatch(Object(Zend\Http\PhpEnvironment\Request), Object(Zend\Http\PhpEnvironment\Response))
#11 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Zend\Mvc\DispatchListener->onDispatch(Object(Zend\Mvc\MvcEvent))
#12 /var/www/html/omeka-s/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\EventManager\EventManager->triggerListeners(Object(Zend\Mvc\MvcEvent), Object(Closure))
#13 /var/www/html/omeka-s/vendor/zendframework/zend-mvc/src/Application.php(332): Zend\EventManager\EventManager->triggerEventUntil(Object(Closure), Object(Zend\Mvc\MvcEvent))
#14 /var/www/html/omeka-s/index.php(21): Zend\Mvc\Application->run()
#15 {main}
Weirdly, the account actually is created and the email notification to the user goes through fine–clicking the confirmation link lets me sign in with the test username and password I just created with no other problems. Has anyone run into this error or something like it before? Any advice would be appreciated.
Thanks,
J.
I appears that your MediaWiki API successfully processed the account creation but didn’t respond fast enough for the Scripto client. I’ve opened an issue that should be resolved in the coming weeks.
Thank you for your suggestion and the quick issue fix - unfortunately, even after implementing the increased timeout limit we’re getting the same error. We’ll look into possible firewall issues and see if that could be the root problem.
I’ve been working on this with Julia, and am utterly stumped.
As she notes, we are getting the timeout page error after whatever period is set in the code. But the user is created anyway and can then log in.
I was initially convinced this must be some sort of error in our AWS security group setup that was preventing the server from talking to itself. But I’ve been through everything I can think of there and nothing has changed.
I tried upgrading to the current mediawiki (we were on the LTS version and one minor revision back) but this did not change anything. (I did notice that when I forgot to run the upgrade script, the MW database error was properly passed through to Omeka.)
Now I’ve also noticed that if I try to recreate the same user, the system immediately responds with an error.
This and the previous observation about the post-upgrade database error would seem to confirm that Scripto is having no trouble communicating with the MW API. But when I actually create an account, it still fails spectacularly.
We’re a bit up against a wall on this since we’re trying to hit a grant deadline and this is a blocking issue. Would welcome additional ideas…
Another update: I was able to successfully use the PHP sample code at https://www.mediawiki.org/wiki/API:Account_creation#Sample_code (running on the server itself) to create a new account on the wiki that was recognized by Scripto - output shown below.
root@hws-omeka1:~# php test.php
{"createaccount":{"status":"PASS","username":"Testcode"}}
I was then able to log into scripto as Testcode
So this seems to prove that it’s not a connectivity problem from the server, a speed issue with MediaWiki, or an internal MediaWiki problem. It seems like there must be something going wrong on the scripto side that is preventing this from working.
Omeka’s HTTP client (zend-http) threw a TimeoutException, which means that the the socket has timed out. Whatever is happening, the client thinks that it’s taking too long.
Maybe Omeka’s default HTTP client configuration is causing the problem. In Omeka’s /config/local.config.php file, try replacing the Socket connection adapter with another one, like Proxy or Curl. You may find a configuration that will work better with your server environment. For example:
'http_client' => [
'adapter' => 'Zend\Http\Client\Adapter\Curl',
[custom configuration options here]
],
You can see all configuration options on zend-http’s adapter documentation.
Tried it. No luck so far. Similar error.
I’ve played with a few different config options, particularly relating to SSL handshaking, but doesn’t seem to make a difference. I’m still unclear on how this can be an issue only for account creation, but all other functions that go through the API seem fine. I’m not an expert on reading the zend stack trace, but is it possible the API just isn’t returning what the plugin is looking for to confirm account creation?
UPDATE:
(Apparently I’m not allowed to reply to this topic anymore, so posting update here.)
I think I’m finally on the right track on this. I realized that the same thing was happening when creating a new user natively in MediaWiki (which somehow I had not thought to check previously) but that it would eventually create a user if I let it sit for a couple of minutes.
So that did point away from anything on the Omeka side. I then got the Mediawiki profiler enabled, and discovered that the account creation process was stalling out for a long period of time while calling the mail function to try to send the confirmation e-mail.
I’m going to need to explore this a bit, but that explains why only account creation was impacted. I’m assuming its something to do with the native environment not supporting outbound e-mail. (This may be a security default set up by AWS.) I temporarily disabled e-mail via a LocalSettings flag, and suddenly things started working.
I’m assuming we do want the system to be able to send e-mails, so will need to explore this further. But at least we finally have some idea what’s going on…
Thanks for all your help on this.
FINAL UPDATE: IT’S WORKING!
Added Mediawiki extension to bypass internal PHP mail function and send via Amazon SES. Account creation process now works smoothly. (Now to figure out what to do with the 60 or so test users we created during troubleshooting. 
)
A timeout error is pretty clear, but it could be possible that Scripto’s accountcreation request itself needs additional configuring for your specific setup. Maybe your MediaWiki is configured to redirect during account creation. Does your wiki use CAPTCHA, OpenID, or a two-factor authentication? Scripto assumes a simple PASS or FAIL response, not a REDIRECT, which those methods of authentication may require.
What version of MediaWiki are you using?
