The "Edit with Texture" link formulates with a stageId:

This is, presumably, the workflow stage, given that it generally sources from the fetch-grid call for a files grid, e.g. ojs/index.php/test/$$$call$$$/grid/files/production-ready/production-ready-files-grid/fetch-grid?submissionId=3&stageId=5&_=1570819236851

It fails to be assigned any value in a new submission as soon as the wizard moves beyond the initial upload.

Steps to reproduce:

1. As author, start a new submission
2. Upload a JATS XML and Dependent Files
3. Finalize the Submission.
4. Return to the Submission (ojs/index.php/test/$$$call$$$/grid/files/submission/author-submission-details-files-grid/fetch-grid?submissionId=1&_=1570820690723)
5. Try to Edit With Texture (fails)

or

3. Do not finalize the Submission
4. Return to the Submission (ojs/index.php/test/$$$call$$$/grid/files/submission/submission-wizard-files-grid/fetch-grid?submissionId=4&_=1570820830259)
5. Try to Edit With Texture (fails)

There is no need to rely on the URI for the workflow stage. We can get it from the submission.

Proposed workflow:
Upload of DAR file via the SubmissionsFilesUploadForm is hooked by this plugin and the contents are extracted (if valid).

Specifically:

• Hook submissionfilesuploadform::execute examines the upload
• If a 'dar' extension, and if it has at least a "manuscript.xml" and "manifest.xml"
• Extract the manuscript.xml to create a new submission file
• Use the manifest.xml to extract new dependent files
• Replace the submission file from the upload form with the extracted submission file (and dependent files).

Prerequisite: pkp/pkp-lib#5146

I have an OJS running with texture plugin installed. But this plugin doesn't shows up anywhere in the workflow. I have tested many times even on a fresh install of OJS on other hosting and local servers because error log reports depreciation warning.

[30-Oct-2018 10:59:58 UTC] PHP Strict Standards: Declaration of TexturePlugin::register() should be compatible with LazyLoadPlugin::register($category, $path, $mainContextId = NULL) in /home/roesolca/public_html/plugins/generic/texture/TexturePlugin.inc.php on line 141

Is there any way we can disable Lazyload plugin if this is the major error causing reason.

Please tell if there is a way to resolve this error along with multiple other depreciation warnings. If there is a problem with PHP version do tell me. I am running 5.6 Native PHP.

By default OJS doesn't runs many of the plugins like texture, JATS template etc due to these warnings. Please help me resolve these issues since I am fed up of this.

Deprecated: Non-static method PKPApplication::getRequest() should not be called statically in /path/ResponsiveThemePlugin.inc.php on line 181.

Please help me how to solve this issue.

When an XML file is the Main Manuscript file (this would need to be established somehow if there are more than one), then the metadata in the XML should be sync'ed with what's in the OJS back end (title, authors, etc.). This should probably be a two-way sync.

File names are handled as non-localized data, which was changed in OJS 3.3.
This leads to broken links to figures when reading the file as well as incorrect data of uploaded ones.
Associated error in the log when opening JATS XML with attached image:

PHP Warning:  Illegal offset type in /home/doc/OJS/development/versions/ojs-3.3.0-8/plugins/generic/texture/classes/DAR.inc.php on line 204

Uploading the image through the plugin leads to incorrect database entry in submission_file_settings table:

submission_file_id	locale	setting_name	setting_value	setting_type	

2466	0	name	fig4_2.jpg	string

Tested with OJS 3.3.0 and main branch of the Texture plugin

• Upload support

• Download support

• Content panel Style

Methods TextureHandler::_createDependentFile() and TextureHandler::_updateManuscriptFile() seem reusable enough that they could be methods of the Plugin, or even of SubmissionFileManager.

For example, for #32, we would want a plugin hook to potentially do both of these things. There would be no need to reach out to a Handler.

@withanage , @asmecher , opinions on whether to promote these methods to the plugin or to SubmissionFileManager? Are there assumptions or specifics I'm missing here which limit the reusability of this code?

• mixed citations are not supported.

• Do not break

• A script editor for unsupported tags

Hi. I use OJS 3.1.2.4 and I can´t install texture plugin, neither from the plugin panel nor uploading the plugin file (both updated and old version). Is there any solution? Thank you.
Pablo

OS platform: Linux
PHP version: 7.2.26
Apache version: LiteSpeed
Driver DB: mysqli
DB: 10.2.30-MariaDB

Current master branch.

Texture allows entering page count for book references but if the document is saved it can't be reopened with the editor because of validation error for page-count tag.

When OJS is "loading files" in the production phase (I suppose the same in other phases), the page never ends "loading files" and I get this error in apache logs:

[Sun Feb 07 20:46:50.849739 2021] [php7:error] [pid 13397] [client 127.0.0.1:46010] PHP Fatal error: Uncaught Error: Call to undefined method SubmissionFile::getExtension() in /home/isaac.marco/git/ojs33/plugins/generic/texture/TexturePlugin.inc.php:130\nStack trace:\n#0 /home/isaac.marco/git/ojs33/lib/pkp/classes/plugins/HookRegistry.inc.php(107): TexturePlugin->templateFetchCallback('TemplateManager...', Array)\n#1 /home/isaac.marco/git/ojs33/lib/pkp/classes/template/PKPTemplateManager.inc.php(1070): HookRegistry::call('TemplateManager...', Array)\n#2 /home/isaac.marco/git/ojs33/lib/pkp/classes/controllers/grid/GridHandler.inc.php(1020): PKPTemplateManager->fetch('controllers/gri...')\n#3 /home/isaac.marco/git/ojs33/lib/pkp/classes/controllers/grid/GridHandler.inc.php(986): GridHandler->renderRowInternally(Object(Request), Object(SubmissionFilesGridRow))\n#4 /home/isaac.marco/git/ojs33/lib/pkp/classes/controllers/grid/GridHandler.inc.php(1031): GridHandler->renderRowsInternally(Object(Request), Array)\n#5 /home/isaac.marco/git/ojs33/lib/pkp/classes/controllers/grid/GridHandler.inc.php(921): GridHandler->renderGri in /home/isaac.marco/git/ojs33/plugins/generic/texture/TexturePlugin.inc.php on line 130, referer: http://loc.ojs33/index.php/cero/workflow/index/3/5

Add teh follwing settings according to the license in the distribution settings.

e.g.

<permissions>
            <copyright-statement>© 202X The Author(s)</copyright-statement>
            <copyright-year>202X</copyright-year>
            <license license-type="open-access"
              xlink:href="https://creativecommons.org/licenses/by/3.0/de/deed.en" xml:lang="en">
              <license-p><inline-graphic
                xlink:href="http://mirrors.creativecommons.org/presskit/buttons/88x31/svg/by.svg"
              />This work is licensed under a Creative Commons Attribution 3.0 Germany License (CC BY 3.0 DE).</license-p>
            </license>
</permissions>

Dear Texture plugin team,
Is it possible to insert/change the existing format of citation and reference, e.g., from Vancouver to APA in the plugin?

Thanks

The text alignment feature is missing. I think this feature should be integrated with Texture and JastParser. .

In several places system default temp dir is used to store XML and attached files, e.g. : https://github.com/pkp/texture/blob/master/TextureHandler.inc.php#L433
I suggest deleting them after the Submission File is updated.

Texture currently supports stricly v1.0 , v1.1 and v1.2 of the JATS green.

-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.2 20190208//EN'

As long as schema is undefined correctly it throws an exception.

when we try to insert an image it seems that it is not being uploading to OJS_dir

The SubmissionFileAccessPolicy at https://github.com/pkp/texture/blob/master/TextureHandler.inc.php#L64 should use SUBMISSION_FILE_ACCESS_MODIFY instead of SUBMISSION_FILE_ACCESS_READ. This will prevent authors from making modifications which they are generally not allowed to do. If there is a need for author preview/editing, I guess we need to figure out what that looks like with the existing submission file access policies.

Wherever $request->getUserVar('submissionId') is used, use $submission = $this->getAuthorizedContextObject(ASSOC_TYPE_SUBMISSION); instead. For example here: https://github.com/pkp/texture/blob/master/TextureHandler.inc.php#L101. Generally the auth policies should prevent this code from being reached, but this ensures that if the code is fired we are using an authenticated object instead of the unauthorized data passed by the user. (It will also save some database hits.)

The main branch and 2_4_3-8 release are affected.

When importing the image through Texture, it's being saved in OJS database as a submission file with non-localized name property. This leads to an incorrect path to the file on the front-end when presenting with JATS Parser Plugin.

To reproduce:

1. Edit an XML file with Texture.
2. Click on Insert -> Figure or replace the existing one.
3. Save the change
4. Look for the correspondent submission file in submission_file_settings table. The entry looks like:

submission_file_id	locale	setting_name	setting_value	setting_type
2314	                0	name	        fig4.jpg	string	

When the texture editor loads, there's no title for the webpage so the browser just shows the URL in the tab. Can we add a title here:

https://github.com/pkp/texture/blob/master/templates/editor.tpl#L13

I think it could be just the article title or "Texture | {articletitle}".

Hi, how do you currently upgrade Texture?
(I am asking because as an npm dependency it seems to depend on node libraries - but there may be a better way)

Right now, Texture loads in its own window in a way that looks separate from OJS. Change to have Texture load "within" OJS, perhaps with a full-screen view that still keeps a top line banner (similar to full page article views).

Texture 1.0 has been released, so this plugin should be updated to the latest.

This conflicts with the name of the actual Texture app: https://github.com/substance/texture

I doubt that it's something that can be corrected on our side but anyway worth leaving a record.

When editing citations, which involves correcting in-text pointers to references, the JATS XML export doesn't include it's corrected citation ordering.
Assuming I have a reference with rid bib26. I want to put it as a first reference. While all is working as it should inside the editor, in JATS XML output the reference would look like:

<xref id="_xref-1" ref-type="bibr" rid="bib26">[1]</xref>

While id is correct, the text label pointers to the first reference in the sequence. There is no way to figure out from JATS XML what is the right order of references inside the list. The order of exported references is from lower to higher ids, thus citation label [1] points to the reference, which appears first, i.e. id bib1:

<ref-list>
	<ref id="bib1"></ref>
        <ref id="bib2"></ref>
        <ref id="bib3"></ref>
...
</ref-list>

To make any sense, the label here should repeat the numeric value of id:

<xref id="_xref-1" ref-type="bibr" rid="bib26">[26]</xref>

Or the order of refs inside the list should correspond to the text label:

<ref-list>
	<ref id="bib26"></ref>
...
</ref-list>

There's a warning that appears when using Texture in Firefox that says Texture only supports Chrome. Do we know what limitations are faced in other browsers?

Hello,
Is anybody experiencing this? The web version of Texture is no longer saving any modifications.

Hi all:

I have an issue when try to save an author with orcid. The orcid doesn't record.

Regards,
Diego.

Currently TextureHandler contains code to manually parse an HTTP multipart request. However, using file_get_contents('php://input') with multipart/form-data is out of spec. From http://php.net/manual/en/wrappers.php.php:

php://input is not available with enctype="multipart/form-data".

While it does appear to work on some systems, it's been reported not to work on all. Another mechanism needs to be used to communicate with the Texture editor. (Ideally, we should not be manually parsing HTTP requests at all!)

(Note that #6 may require a rewrite of the storage interface anyway -- this should be considered in conjunction with that issue.)