Scripto Problem: error thrown

Omeka Classic Plugins
1

I’m running Scripto in Omeka Classic through Reclaim Hosting. It’s worked great until recently, when an error message is thrown whenever I attempt to load a page for transcription - this link provides an example. The image to be transcribed sometimes sometimes loads, sometimes not. When it fails, it generates the following error:

Warning: getimagesize(http://dhl.bac.edu/files/original/65c57840432bb2d18df27e5d5e4863f2.png): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/dhlbacne/public_html/plugins/Scripto/ScriptoPlugin.php on line 407

However, the error below is consistently thrown into the space for the transcription box:

Warning: in_array() expects parameter 2 to be array, null given in /home/dhlbacne/public_html/plugins/Scripto/libraries/Scripto/Document.php on line 683
You don’t have permission to transcribe this page.

I’m accessing the page from an admin account, and permission shouldn’t be an issue. The change happened recently, and there haven’t been any new plugins have recently installed or upgrades occuring.

Here’s the info on the current versions used for this Omeka Classic instance:

Scripto 2.5
Mediawiki 1.38.2
Omeka Classic 3.0.2

Any suggestions on how to proceed? All help greatly appreciated.

2

I tested with identical versions and am unable to reproduce the errors. I notice that the page you linked loads quite slowly. If a page loads too slowly, functions like getimagesize() may fail, as you see. As for the in_array() error: it suggests that Scripto is having trouble requesting data from your MediaWiki installation, which may also be running slowly. These issues may be related to performance of your Reclaim Hosting account.

3

I’m getting the same error as @danielhutchinson

[03-Jan-2023 20:56:07 UTC] PHP Warning:  in_array() expects parameter 2 to be array, null given in /public_html/dev/plugins/Scripto/libraries/Scripto/Document.php on line 683

Omeka Classic 3.0.3
Scripto 2.5
Mediawiki 1.39.1
Thanks Roy theme

It’s a fresh install. No other plugins are installed. I’m testing with the sysop user, that has a confirmed email address. I’ve tested various cookie options, the one that I’m currently using is “mw_” and this matches the value in LocalSettings.php.

These are the rights in LocalSettings:

 $wgGroupPermissions['*']['edit'] = true; 
 $wgGroupPermissions['*']['createpage'] = true;

When I dump the userinfo for the logged in user, this is what I get:
array(4) { [“id”]=> int(1) [“name”]=> string(6) “Qzxwrf” [“groups”]=> array(6) { [0]=> string(10) “bureaucrat” [1]=> string(15) “interface-admin” [2]=> string(5) “sysop” [3]=> string(1) “*” [4]=> string(4) “user” [5]=> string(13) “autoconfirmed” } [“rights”]=> array(64) { [0]=> string(10) “userrights” [1]=> string(11) “noratelimit” [2]=> string(13) “editinterface” [3]=> string(11) “editsitecss” [4]=> string(12) “editsitejson” [5]=> string(10) “editsitejs” [6]=> string(11) “editusercss” [7]=> string(12) “edituserjson” [8]=> string(10) “edituserjs” [9]=> string(5) “block” [10]=> string(13) “createaccount” [11]=> string(6) “delete” [12]=> string(9) “bigdelete” [13]=> string(14) “deletedhistory” [14]=> string(11) “deletedtext” [15]=> string(8) “undelete” [16]=> string(6) “import” [17]=> string(12) “importupload” [18]=> string(4) “move” [19]=> string(13) “move-subpages” [20]=> string(18) “move-rootuserpages” [21]=> string(18) “move-categorypages” [22]=> string(6) “patrol” [23]=> string(10) “autopatrol” [24]=> string(7) “protect” [25]=> string(13) “editprotected” [26]=> string(8) “rollback” [27]=> string(6) “upload” [28]=> string(8) “reupload” [29]=> string(15) “reupload-shared” [30]=> string(14) “unwatchedpages” [31]=> string(13) “autoconfirmed” [32]=> string(17) “editsemiprotected” [33]=> string(14) “ipblock-exempt” [34]=> string(10) “blockemail” [35]=> string(12) “markbotedits” [36]=> string(13) “apihighlimits” [37]=> string(13) “browsearchive” [38]=> string(8) “movefile” [39]=> string(11) “unblockself” [40]=> string(16) “suppressredirect” [41]=> string(12) “mergehistory” [42]=> string(16) “managechangetags” [43]=> string(16) “deletechangetags” [44]=> string(4) “read” [45]=> string(4) “edit” [46]=> string(10) “createpage” [47]=> string(10) “createtalk” [48]=> string(8) “writeapi” [49]=> string(15) “viewmywatchlist” [50]=> string(15) “editmywatchlist” [51]=> string(17) “viewmyprivateinfo” [52]=> string(17) “editmyprivateinfo” [53]=> string(13) “editmyoptions” [54]=> string(9) “minoredit” [55]=> string(13) “editmyusercss” [56]=> string(14) “editmyuserjson” [57]=> string(12) “editmyuserjs” [58]=> string(20) “editmyuserjsredirect” [59]=> string(5) “purge” [60]=> string(9) “sendemail” [61]=> string(15) “applychangetags” [62]=> string(10) “changetags” [63]=> string(16) “editcontentmodel” } }

I’m not sure what’s going wrong here. I look forward to @jimsafley 's thoughts!

Edit because I forgot to mention that I can’t transcribe at all. Instead I’m getting the message: “You don’t have permission to transcribe this page”

4

Where exactly are you dumping the userinfo? In Scripto_Document::_canEdit()? If so, your output looks different than mine, which wraps the user information in:

array(2) {
  ["batchcomplete"]=>
  string(0) ""
  ["query"]=>
  array(1) {
    ["userinfo"]=> <USER INFO HERE>
  }
}

As with the original poster, suspect that Scripto is having trouble requesting data from your MediaWiki installation. The call to getUserInfo('rights') may somehow be returning NULL and not throwing an exception, which can happen if MediaWiki returns nothing rather than an error response. You can check by going to Scripto_Service_MediaWiki::_request() and dumping $body.

5

Thank you.
You are correct, the call to getUserInfo('rights') is returning NULL and not throwing an exception. When I dump $body within Scripto_Service_MediaWiki::_request(), I get this:

 string(315) "
Not Found

The requested URL was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
"

I can check on a different server and with a different version of MediaWiki to eliminate these possibilities. Do you think these would be useful tests?

To answer your question, I think was dumping the wrong user rights. I was using $this->_userInfo['query']['userinfo']; instead of $this->_mediawiki->getUserInfo('rights');

6

Interesting. Can you successfully configure the Scripto plugin? Go to Plugins > Scripto > Configure and press “Save Changes.” Do you see a “The Scripto plugin was successfully configured!” message? If not, Scripto does not recognize the MediaWiki API URL as being valid. I suspect it’ll work, or you’d see even more errors when transcribing an item.

With that said, I’m not sure how Scripto can make a successful request for siteinfo, and receive a 404 Not Found for a userinfo request. I don’t see any harm in checking on different servers with different versions of MediaWiki

7

Can you navigate directly to your MediaWiki API? Enter this in your browser:

<MediaWiki URL>/api.php?action=query&meta=userinfo&uiprop=rights

8

Thank you again.
I tested on a different server, and all works as expected. So I think (as you said in an earlier post) that this is a Reclaim server issue.

But to follow up, the api url works. Here’s the output for userinfo rights. Interesting that the name is an ip instead of a username and that the ip fails when opened in a browser (though maybe this is expected behavior?)

{
    "batchcomplete": "",
    "query": {
        "userinfo": {
            "id": 0,
            "name": "192.241.132.143",
            "anon": "",
            "rights": [
                "createaccount",
                "read",
                "edit",
                "createpage",
                "createtalk",
                "writeapi",
                "viewmywatchlist",
                "editmywatchlist",
                "viewmyprivateinfo",
                "editmyprivateinfo",
                "editmyoptions"
            ]
        }
    }
}

I was curious about the mediawiki api url too. When the correct url is entered, I’m able to save the config form and I get the success message. If I enter the incorrect api url, I get the error: Omeka_Plugin_Installer_Exception Invalid MediaWiki API URL

Upon further digging, the 404 refers to the image file. getimagesize() is failing, just like the OP experienced.

9

Updating in case this is useful to anyone in the future. For us, this was a server issue. Our Omeka install was migrated to a new shared server and we needed to update DNS records from our institutional domain.

1 Like
10

This topic was automatically closed after 250 days. New replies are no longer allowed.