Having a field for academic degrees would be very handy. Our users have a tendency to put the academic degree in the last name field.
Hi @sherwood,
Is this metadata that you’d foresee getting presented somewhere in the interface? Or are users just dead set on putting it somewhere?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi Alex,
Yes to both questions.
We are weighing the benefits of using degrees in the articles (pdfs and htmls) themselves - we always have in the past but there’s some question of whether we should continue doing so. Along with that we’re debating whether they should be in the table of contents, and in the author index (as generated from the metadata).
No matter what we decide on usage of degrees, many (but not all) of our users ARE dead set on adding their degrees somewhere and it usually ends up in the last name field, which makes for inconsistencies in the author index.
Thanks,
S
Hi @sherwood,
Unfortunately I suspect it’ll be easier to add the field, even if the data’s not used anywhere, than to convince authors not to force it into the last name field. However, we don’t really have a use for the data in the general case, and I haven’t heard from users of this happening before – so it’s not a huge development priority. Do you have anyone on hand with PHP/MySQL experience? I could file a feature addition, but it would certainly happen faster if you’ve got a bit of dev time to put into it. I’d be happy to perform code review and merging etc.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks Alec,
Definitely agree about changing authors’ behavior.
The only one we have on hand with any (however limited and outdated) PHP/MySQL experience, unfortunately, is me. I would love to contribute to development but, alas, time limitations for the foreseeable future are a bit daunting. I will, however, try to take up the challenge. Besides this request, we have associate editors asking for other mods to the system - so far I’ve been deflecting their requests.
S
Hi @sherwood,
I understand. Let me know if I can provide any guidance!
Regards,
Alec Smecher
Public Knowledge Project Team
Alec,
Rest assured, I will be in touch when/if I take on the development task.
S
@asmecher, I’d like to hear your thoughts on this. I’m adding fields to the article metadata so that I can include something like subtitle, and maybe another public image.
The way that I was going - I have added my own template directory to the beginning to the template_dirs array so that I can override templates without touching core files. So I can override the metadataEdit.tpl file and add the fields. And I’ve hooked into “Action::saveMetadata” and “articledao::getLocaleFieldNames” in order add data to the article object and to make sure the new info is saved to the article_settings table, respectively. So I think that’s all good, but I was curious about:
- Did I get the field addition stuff right or was there a better way to go about it? Right now it was just a text field that was being added (‘subtitle’)?
- If I needed to display a custom field, is there a simpler way than overriding templates (other than the custom template manager plugin)?
I’ve actually figured out the following questions in the meantime so feel free to ignore.
Also, I wanted to ask about image processing. Maybe this should be a different thread, but since it’s related to being and added field, I was wondering if there’s an easy image processing method in ojs?
I need to display an image [originally the plan was this would be the cover image], but I need to display it in a couple dimensions that don’t really match up, one essentially being a thumbnail, so I’d love to avoid manipulating size in css if possible.
Also curious if, public files managed in the database in anyway or can I add files to that public directory and safely assume they won’t be removed?
Hi @_jd,
It sounds like you’ve gotten into the right spots. If you’re dealing with a multilingual input for subtitle, then yes, getLocaleFieldNames is the right place to hook in – but if you only want data to be entered, check out getAdditionalFieldNames.
Have you considered making your changes strictly via a plugin? If you work with a generic plugin, then you should be able to override templates without changing the template_dirs list. Check out the TemplateManager::display and TemplateManager::include hooks. There are examples of use for each of these in the existing set of plugins included with OJS 2.4.x.
As for how to alter the behavior of an existing template – unfortunately this is one area where Smarty is a little tricky. There are a few options:
- Replace the template entirely with your overridden version; that works but unfortunately may involve duplicating a lot of code in a longer template. And multiple plugins won’t be able to work with the same content.
- Register a Smarty output filter and use text munging tools (regular expressions etc.) to identify and work with the specific part of the template you need to alter. This is good for targeted changes, but is a little brittle to maintain.
- If you want to add content to an existing template and think the point of addition might be useful for other users, consider adding a hook to the template, then using that hook to add content. If this ends up being merged in upstream, it’s no maintenance cost to you; alternately, you could maintain the hook addition as a local modification.
Regards,
Alec Smecher
Public Knowledge Project Team
Hey @asmecher,
Thanks for the reply. I’m generally with you the options that you laid out. I think in regards to your points:
that works but unfortunately may involve duplicating a lot of code in a
longer template. And multiple plugins won’t be able to work with the
same content.
I’m not sure exactly what you mean by multiple plugins won’t be able to work with the same content. I’m trying to declare information within the proper place in the hook process. Is this just in reference to the fact that I’d have to override multiple templates?
If you want to add content to an existing template and think the point
of addition might be useful for other users, consider adding a hook to
the template, then using that hook to add content. If this ends up being
merged in upstream, it’s no maintenance cost to you; alternately, you
could maintain the hook addition as a local modification.
I’d say that “if” is a pretty big if. If I add a hook that doesn’t get merged in upstream, then I’m stuck with a template that is overridden and a broken upgrade path, right? Maybe I’m just not familiar enough with how that process is intended to be done within ojs, b/c I’ve been avoiding touching core files mostly for that reason. Especially when I don’t think I’ll be the one maintaining the site long term.
Hi @_jd,
If your plugin overrides an entire template and includes a modified copy of it within the plugin’s own directory, then any other plugin that also tries to override the same plugin will fight for control over it. that’s why I’d suggest an approach that acts like a filter on the existing template, rather than replacing it outright.
Agreed regarding adding a hook. If you feel like the hook has general use and want to go that route, propose the hook and I’ll see if we can agree first before you invest a lot of time coding for it.
Regards,
Alec Smecher
Public Knowledge Project Team