[OJS] Adding a "Media Library"-PlugIn

[felixgruender]

As already mentioned in this bug report: http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=6058 (and in this older bug report: http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=4613), a Media Library (Files Browser)-PlugIn would be highly appreciated to enable journal managers to upload images, templates, information material etc. withouth needing SSH/SFTP or technical support.

Best regards, Felix

[asmecher]

Felix, that's part of OJS 3.0 (and OMP 1.1+), and we're unlikely to tackle it for OJS 2.4.x in the meantime. However, there's a fairly easy work-around -- make a symbolic link from the files directory into the public files directory. That'll permit JMs to use the Files Browser to upload content that'll then be available via the web server directly. Note that there are security risks -- if a bad actor gets hold of the JM credentials, they could potentially upload e.g. a PHP script which could then be executed server-side.

[felixgruender]

Hello Alec, thanks for your information! Maybe I missed to point out that adding a media library is already a fix part of our current project. It's a fact that many of our customers desire this feature - and it's unlikely that most our our customers will migrate to OJS 3.0 in the nearer future.

So we'd like to implement this feature for OJS 2.4.x ourselves (probably as a generic plugin?). We will take care that our solution will also be applicable for OJS 3.0, and of course we will consider the security risks you mentioned. (I just opened this issue to have a fix issue number to reference to).

Best regards, Felix

[ctgraham]

@felixgruender, we made a small change to the existing Files Browser to allow the journal manager access to both the public and private files at the journal level: https://github.com/ulsdevteam/ojs/commit/c38629c1a6d5b4c610f03772efc7b225589a28f1

We also found it helpful to point out to users that every TinyMCE enabled field has access to the jbimages upload. The vast majority of the "media" our journal managers wanted to manage was these inline images, so this fit most of the need.

[asmecher]

Gotcha, thanks, Felix. You might want to consider porting some of the OJS 3.0 code back to 2.4.x -- at least the database schema, DAO and DataObject classes, since those are fairly compatible across the codebases. That way you'll future-proof your work against the 3.0 upgrade, whenever that happens.

[bozana]

Alec, how do you mean it? :-\ The major requirement is the upload of document templates for authors -- so that they can download them and use them for the article layouting, s. e.g. http://www.qualitative-research.net/index.php/fqs/about/submissions#authorGuidelines. When we are working on that issue, we could/should make it as generic as possible i.e. consider all other similar requirements, right? Clinton, your solution will solve the requirements we know. Thus, would this maybe be a good way to do it i.e. for example to implement a plug-in similar to the "file browser" function for journal managers, but working with the public folder or a subfolder? What other requirements exist i.e. could/should be considered? Anything else? Thanks a lot!!!

[asmecher]

Bozana, just thinking that if your functional requirements match those for the submission library already in OJS 3.0 pre-release / OMP 1.x, it would make sense to use the same data structures. That way when journals using this work on OJS 2.x upgrade to OJS 3.x, the submission library files will not need special upgrade considerations.

[bozana]

Ah, OK :-) I/we will have to see how the submission library in OJS 3.0 / OMP 1.x is working... :-)

[bozana]

Is the submission library also the solution for the bugzilla entry 6058?

[asmecher]

Yes, thanks -- I've closed that entry.

[bozana]

Alec, do you maybe mean "Press Library" (Management > Workflow > Press Library) in OMP i.e. "Publisher Library" in OJS 3.0alpha? -- I cannot find "Submission Library" :-\ If so, those libraries are meant to function internally, within the workflow, for the persons involved in the workflow, and not to be public, right? The requirement here is to work with the 'public' folder...

[bozana]

Ah, sorry, just crossed my mind, not necessarily 'public' folder, but publicly available... :-)

[asmecher]

There's current the "press library" which is intended for things like contract templates, etc.; then there's the "submission library" which is an area to attach those files to for specific submissions once they're filled in.

The press library is closest to what you're talking about; OTOH I'm pretty sure those files are accessible outside of workflow users (see FileApiHandler::authorize).

They aren't kept in the public directory, but I'd like eventually to remove that directory entirely -- it's a security risk IMO and I'd favour managing all file accesses via PHP.

[bozana]

I am wondering if we could then extend a "press/publisher library" with a new category "public" and think about a mechanism how those files could be publicly accessed? For example an OJS/OMP-URL via which those files would be delivered by OJS/OMP? If so, I am wondering how to solve this in OJS 2.4.x in order not to migrate the whole library concept? What do you think?

[asmecher]

Another option might be to extend the TinyMCE image upload plugin, I suppose... Perhaps this needs to be solved differently in 2.x than in 3.x. For 3.x, I definitely want to use of the public files directory; it's an accident waiting to happen. For 2.x, though, it's OK to use. The problem will be the migration process, but I don't think requring a manual migration is the worst idea.

[bozana]

Alec, now the images uploaded within TinyMCE are stored, thus also available, in a public folder of the current user. This is a minor thing, however I wanted to ask, if this would be the preferred temporar solution for OJS 2.x? What about the Clinton's workaround? Whatever solution we take for OJS 2.x now, the public folder migration (manual or automatic) to the new, right solution will have to be considered... THANKS!!!

[asmecher]

I haven't worked out a migration strategy for content that's uploaded via TinyMCE. The tricky part with that content is that it's not tracked in the database anywhere, unlike every other kind of upload, so it'll be hard to migrate the content without breaking links. If you like, go ahead and use it for 2.4.x, but it's possible that upgrading to 3.x will require some manual work on that content.

[bozana]

And there is no strategy for this issue (how to implement it) for 3.x yet?

[asmecher]

The default will probably be to continue with the public files directory until changing it is a priority. I suspect you can count on it staying around for a while [unfortunately, since I don't like it].

[bozana]

Would we than migrate the TinyMCE solution to the 3.x as well, till the new strategy isn't there?

[asmecher]

Yes, I think that makes sense. Sorry for being hard to pin down on this one.

[bozana]

Sorry for asking so many questions! :-) OK, everything clear for now... :-)

[felixgruender]

Thinking about it I'm not entirely sure any more if extending the TinyMCE plugin is a viable solution for this issue. TinyMCE's upload functionality uses jbimages which in turn is based upon the CodeIgniter framework, so I assume it is difficult to implement changes/extensions here.

So I think the best way would be to develop a plugin similar to the existing files browser in OJS - including the following differences:

1) The uploaded files are stored in the public folder (of course security checks will be necessary) 2) Creating new folders / subfolders is not needed in my opinion. All uploaded files could be stored in one directory, e.g. public/journals/[journalid]/uploads 3) Additionally: maybe the file data should be stored in the database?

[jmacgreg]

I favour extending the publisher library option. It would expand the usefulness of the publisher library, and would suffice for all of the major use cases I can think of (eg. publishers wanting to upload public guidelines or templates in PDF or other format; wanting to upload and link to PDF posters and calls for papers; etc.). I think the following would be required:

• add a "public" checkbox for any item uploaded to the Publisher Library;
• for any public file, provide a URL that can be opened (or copied) so that publishers know the full URL they can paste eg. into other journal fields;
• for any public file, allow everyone, even non-registered visitors to the site, access.

[asmecher]

@jmacgreg, I think https://github.com/pkp/pkp-lib/issues/520 already covers at least some of this.

[jmacgreg]

Oh, excellent - agreed.

[asmecher]

520 got merged, and this is now quite old; closing.