omeka / plugin-scripto Goto Github PK

On the "Scripto | Transcribe Page" page, consider renaming the "Export document" and "Export page" buttons to "Import document" and "Import page" respectively. "Import" makes more sense in this context. Remember to change the related IDs and page_actions in the transcribe.php view and Scripto_IndexController::pageActionAction().

Hello,
would be nice (even if non-blocking) to be able to set the path to API as relative. I have installed mediawiki as a /mw subdidrectory of my Omeka, I would like to configure Scripto in this way so that if my domain name changes my configuration is still OK.

It would be great if in the mediawiki content, you could insert a link to the omeka item, thus enabling navigation between the two sites.

Navigation elements between "next page" and "previous page" would be greatly appreciated too.

This issue was reported back in 2.3 and butler had fixed this in 2.3.2 (found in this repo: https://github.com/ui-libraries/plugin-Scripto) in March 2019.

We recently had to upgrade from 2.3.2 to 2.4 due to the login issue (which 2.4 did fix...thank you!).

However, that broke the individual transcription item pages. It was the same exact issue we ran into here: https://forum.omeka.org/t/scribe-theme-install/6978

We see the same exact error message with 2.4:

Omeka has encountered an error
Scripto_Adapter_Exception
The provided adapter method “getPageTranscriptionStatus” does not exist.

Scripto_Adapter_Exception: The provided adapter method “getPageTranscriptionStatus” does not exist. in /home/xxx/public_html/omeka/plugins/Scripto/libraries/Scripto.php:106

I compared 2.3.2 and 2.4 and the fix in 2.3.2 is not present in 2.4. Perhaps having 2 separate repos led to neglecting changes in the other? Should these repos be combined so there's one authority.

In a similar vein, the link to the Scripto github bug report found here https://scripto.org/, does not point to any Scripto github repo. Instead it points to https://github.com/omeka/Omeka/issues.

The cookie_prefix branch fixes a bug that prevents users from logging in to Scripto when using MediaWiki 1.27.0+. The fix should be backwards compatible, so if you have an existing Scripto installation that works, it should still work without any changes.

Confirm that you can log in to Scripto when using a MediaWiki version that is <1.27.0 and when using a MediaWiki version that is >=1.27.0. For the latter you must add a MediaWiki cookie prefix in plugin configuration.

Would there be a way - regardless of the theme used - to have the transcribe page in full screen. Or does this have to be configured for each theme ?

It would be useful to provide users a dashboard with items in three categories :

• done (transcribed and imported)
• transcribed (and not imported)
• no started transcribed

Additional thought : would having a flag such as "finished transcribing" help ? This way we can have a partially transcribed category...

Once the following tickets are resolved:

• https://omeka.org/trac/ticket/1101
• https://omeka.org/trac/ticket/972

remove the admin_append_to_files_form hook and it's callback; and use insert_element_set() instead of creating the Scripto element set from scratch in ScriptoPlugin::install().

It would be nice to be able to configure the number of zoom levels so that the zoom could be finer on some omeka installs. Right now, I have page transcribing where one zoom level is too small and the next one is too big (have to scroll horizontally).

I am using openlayers (maybe I have to submit a request over there?)

I took a quick look in the javascription of openlayers but haven't found a way of doing this yet.

Some contributors to the transcribe functionnality on my omeka site use the wiki markup to make links to wiki pages (for example when transcribing a year they add [[year]] so we can have a common page to which all the mentions of this term or date link to). Scripto seems to strip the href from the a, so we can't navigate to & from the sites.

Making this an option would be fine, I can understand that you wouldn't want this as default behaviour.

The Scripto interface should be flexible enough to style independent of the native Omeka styles. This may require applying namespaced ids to every Scripto-specific element. Consult with a web designer on this one.

@leeannghajar @jhalabuk

There are no new features to test, so just follow these instructions to install Scripto (except pull from git master; you'll need MediaWiki), click on every link, making sure they go to working pages and behave exactly as expected. Follow the editor's role and transcriber's role to make sure you test all functionality.

These instructions suggest that some Omeka administrators want to give their users the ability to import transcriptions from MediaWiki to Omeka. Currently, import is limited to sysop and bureaucrat, but this is configurable via Scripto. Maybe assume that if someone can log into Omeka admin, they should be able to import transcriptions.

There is a chance that the above organization doesn't know to log into Scripto to access the import feature.

I have 25.000 pages of newspaper clippings and 25.000 txt-files with an OCR of those clippings. It would be nice to be able to upload those transcriptions to the Scripto-field before crowd-sourcing. But I don't see how to address the relation uris between OMEKA and Scripto. Any idea?

When trying to put a page to watchlist, Scripto fails with Internal server error. This happens with Scripto 1.3 and also with current development version from Github.

My setup:

Omeka 1.5.1
MediaWiki 1.19.1
PHP 5.3.13
MySQL 5.5.21

Request headers:

Accept:/
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Content-Length:64
Content-Type:application/x-www-form-urlencoded
Cookie:6bfe8801ec9f4933ac9a9f3ff364f855=fc8e84639da51d8755e71b78feea7881; scripto_cookieprefix=bitnami_mediawiki; scripto_bitnami_mediawiki_session=b91cc43ec4468d799c0b6897668cd277; scripto_bitnami_mediawikiUserID=1; scripto_bitnami_mediawikiUserName=xxxx; scripto_bitnami_mediawikiToken=ab067af9560257d91f43fd8562b329c9
Host:xxxx
Origin:xxxx
Pragma:no-cache
Referer:xxxx/admin/scripto/transcribe/15937/11961
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.2 (KHTML, like Gecko) Chrome/19.0.1061.0 Safari/536.2
X-Requested-With:XMLHttpRequest
Form Dataview URL encoded
page_action:watch
page:transcription
item_id:15937
file_id:11961

Once https://omeka.org/trac/ticket/1097 is resolved, make sure to feed file extensions (in addition to MIME types) to add_mime_display_type() in Scripto_IndexController::init(). Probably add file extensions as static properties to ScriptoPlugin.

In IndexController.php, page actions are wrapped in a try block, with the catch block throwing a generic 500 error. Specifically, the error we had was:

exception 'Scripto_Service_Exception' with message 'You must confirm your email address before you can edit in /home/judygies/public_html/omeka/plugins/Scripto/libraries/Scripto/Service/MediaWiki.php:667

This is a common error which should have user feedback saying as much, barring this, have a more descriptive error message rather than just 500.

If not the above, and we wish to continue using 500 errors as a catch-all (for security reasons as an example), the error_log should at least be updated with a detailed line so that troubleshooters can quickly assess the nature of the problem.

Preferably, a combination of above should be implemented. Thanks!

Got this error message with 2.4 upgrade.

I searched for any CSS file in the scripto directory and found one here:
/public_html/plugins/Scripto/views/shared/javascripts/theme/default/style.css

However, it was looking for css/scripto-transcribe.css. So I moved the theme directory up to shared and rename it css, and renamed the file scripto-transcribe.css, so that it lives here:
/public_html/plugins/Scripto/views/shared/css/scripto-transcribe.css

And that fixed the issue.

InvalidArgumentException: Could not find file css/scripto-transcribe.css! in /home/xxx/public_html/application/libraries/globals.php:1288
Stack trace:
#0 /home/xxx/public_html/application/libraries/globals.php(1247): web_path_to('css/scripto-tra...')
#1 /home/xxx/public_html/application/libraries/globals.php(1193): src('css/scripto-tra...', 'css', 'css', '2.7.1')
#2 /home/xxx/public_html/application/libraries/globals.php(1093): css_src('scripto-transcr...', 'css', '2.7.1')
#3 /home/xxx/public_html/themes/Scribe/scripto/index/transcribe.php(3): queue_css_file('scripto-transcr...')
#4 /home/xxx/public_html/application/libraries/Omeka/View.php(114): include('/home/xxx/...')
#5 /home/xxx/public_html/application/libraries/Zend/View/Abstract.php(888): Omeka_View->_run('/home/xxx/...')
#6 /home/xxx/public_html/application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(912): Zend_View_Abstract->render(NULL)
#7 /home/xxx/public_html/application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(933): Zend_Controller_Action_Helper_ViewRenderer->renderScript('index/transcrib...', NULL)
#8 /home/xxx/public_html/application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(972): Zend_Controller_Action_Helper_ViewRenderer->render()
#9 /home/xxx/public_html/application/libraries/Zend/Controller/Action/HelperBroker.php(277): Zend_Controller_Action_Helper_ViewRenderer->postDispatch()
#10 /home/xxx/public_html/application/libraries/Zend/Controller/Action.php(527): Zend_Controller_Action_HelperBroker->notifyPostDispatch()
#11 /home/xxx/public_html/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('transcribeActio...')
#12 /home/xxx/public_html/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#13 /home/xxx/public_html/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(105): Zend_Controller_Front->dispatch()
#14 /home/xxx/public_html/application/libraries/Zend/Application.php(384): Zend_Application_Bootstrap_Bootstrap->run()
#15 /home/xxx/public_html/application/libraries/Omeka/Application.php(73): Zend_Application->run()
#16 /home/xxx/public_html/index.php(23): Omeka_Application->run()
#17 {main}

We have recently come across a bug in OpenLayers relating to this issue in our application after an upgrade with Omeka classic. Since the OpenLayers library has seemingly been compiled and minified, we are unable to add in any hot fix from our position. There are two suggested solutions here and here with the latter coming from an OpenLayers team member.

Omeka 1.5 will soon be released, and with it comes some changes that this plugin can implement:

1. Omeka_Plugin_Abstract: extend ScriptoPlugin off of this class
2. Map file display strategy to filename extension when MIME type is not found: and with it, fix #3

One downside to this is that existing Omeka instances would have to upgrade to 1.5 for the plugin to work. I'm on the fence whether this is acceptable. On one hand we should encourage everyone to upgrade; on the other, some users may not want to. This plugin is still unreleased, save for some testing installations, so upgrading should not be a problem for existing users.

Once this ticket is fixed, make sure to order the files in the Scripto interface according to the native file order.

It would be nice to be able to localize the displayed scripto html.

Some strings are both used in display and javascript so this needs further attention.

Scripto gives '400 Bad request' when trying to import document to Mediawiki in item transcribe page. This happens with with Scripto 1.3 and also with current development version from Github.

My setup:

Omeka 1.5.1
MediaWiki 1.19.1
PHP 5.3.13
MySQL 5.5.21

It would be useful to have an automatic import submission when editing is done. Right now my users systematically click the import button after finishing an edit.