testing and dev: count me in

[klausru]

Dear @ajnyga
I'd like to contribute to this plugin e.g. German translation and usability.
But first I'd like to understand the plugin and get it running on my test-/sandbox, first. As far as I understand, the plugin just adds a single descriptor to an issue (the checkbox) to add the issue to "themeIssues" which will then be collected and displayed under (journalpath/themeIssues).

• What about adding "categories" here: So, instead of a checkbox, add a text field for a category (the data stored in the database is practically the same)
• What about adding a description on top of each of these categories?
• The sort order seems to be implemented, already.
• Fancy eye candy: adding a category image

I'd be happy to get in touch

All the Best, Klaus

[ajnyga]

Hi, thanks!

Yes, it is very basic what it does now. I first planned to solve this for the journal just with a custom page, but then realized that they would be constantly contacting me when they would add a new theme issue :D So decided to do a simple plugin instead.

What you are describing is basically a custom taxonomy for issues. @NateWr any ideas how to approach this in OJS? I know you have been thinking about taxonomies and articles, but how about taxonomies and issues?

A more detailed question Nate: any plugin that handles custom image uploads at the moment?

edit: and another one: was there a way to pass on custom parameters to queries here: https://github.com/ajnyga/themeIssues/blob/master/pages/ThemeIssuesHandler.inc.php#L44-L50? I mean could I check the isThemeIssue param already there?

[NateWr]

any ideas how to approach this in OJS? I know you have been thinking about taxonomies and articles, but how about taxonomies and issues?

Nothing planned. I would suggest not a single text field. You'll want a new issue_categories table in the database. If each issue will only ever go into one category, you'll want a new column in issues for issue_category_id. If each issue may go into one or more categories, you'll want a new table issue_category_issues with two columns: issue_id and category_id.

any plugin that handles custom image uploads at the moment?

No, not that I'm aware of.

was there a way to pass on custom parameters to queries

A quick rundown:

1. Use Issue::getMany::queryObject to modify the selection criteria in the query. For example you might check if (!empty($this->categoryIds)) { .... }.
2. Use Issue::getMany::queryBuilder to receive the argument and set it in the query builder. For example you might say if (!empty($args['categoryIds']) { $issueListQB->categoryIds = (array) $args['categoryIds']; }.

Then you should be able to do something like:

$issues = Services::get('issue')->getMany(['categoryIds' => [1]]);

But to my knowledge this has never been done in a plugin. A good opportunity to test out our hook structure! 👍

[NateWr]

Sorry, I see now you just wanted the isThemeIssue param. The steps are the same just replace categoryIds with isThemeIssue.

[klausru]

Wouldn't it be possible to use the tables categories and category_settings to store that part of the data there and to link to issues in issue_settings -> setting_name (= e.g. "category_ID") -> setting_value (= ID of category)
That way no changes to the database needed

[NateWr]

It would be possible but there's a risk whenever you use a data structure intended for one thing for something else. We (PKP) expect the categories table to store article categories. If you use it for something else that's ok but just know that you're on your own for upgrades. If we change the underlying structure and migrate data over, your data may not match our expectations, an upgrade may fail, and we won't be able to help much.

This is usually fine for one-off cases. And categories are -- for the moment -- not used very much in OJS. But I discourage it for plugins that reach general distribution because the people using the plugin don't necessarily know what's happening under the hood.

[klausru]

Dear all
in order to have two different (kind of) "categories" of Theme Issues I simply duplicated the original plugin and renamed themeIssues and isThemeIssue accordingly. Including appropriate translations.
It works like a charm!

There are now two different checkboxes at the bottom of the issues settings form where I can choose. Of course, the data stored in the issue_settings could be more elegant (as far as I can see the setting_value is not used at all) and the overall plan is very un-elegant, but it shows that this is feasible.

[klausru]

I need your help:
https://github.com/ajnyga/themeIssues/blob/98d65edf6c791e034439fa32ef97cb8fb1bd9342/ThemeIssuesPlugin.inc.php#L61
Any value set for $page is used to replace the term "issue" in the URLs (links to single issues) that are generated in frontend/objects/issue_summary.tpl
So the display of one or more ThemeIssue-pages works fine, but the URLs within these pages are corrupted with the $page-value.
As a workaround I put issue_summary.tpl in my own theme and manually constructed the links to the single issues myself. But this is certainly far from useful.