CUNY Academic Commons

Sorry, for the ambiguity.

Yes, this plugin did previously successfully install:
https://wordpress.org/plugins/dublin-core-metadata/
but it did not allow for the writing of meta-data to posts or pages.

I just tested against a different theme and it actually does allow for the writing of meta-data, however it does not allow for real DC.
Look at this post:
http://www.gclibrarytest.org/blog/2015/12/22/holiday-surprise-free-nytimes-pass-now-includes-tablet-app/
all that it inserts is:
<div class="entry-content">
Isaac Sanchez
Test Posting
JITP </div><!-- .entry-content -->

But, it should look something like:
<!--BEGIN Dublin Core Metadata-->
<meta name="DC.creator" content="Isaac Sanchez />
<meta name="DC.title" content="Test" />
<meta name=""DC.publisher" " content="JITP" />
<!--END Dublin Core Metadata-->

I suggest that the ScholarPress plugin is built out, allowing for the writing of DC meta-data in the dashboard similar to the Dublin Core one.

A quick update that I've spoken with the folks who developed and maintain the ScholarPress Coins plugin, and they're happy to hand the keys over to us for the proposed improvements.

Dan, the repo is here https://github.com/scholarpress/scholarpress-coins/. Let's call the next release 2.0. I've started a branch https://github.com/scholarpress/scholarpress-coins/tree/2.0.x where work should happen toward this release.

Let me know if you have questions getting started.

Here's my first crack at adding the ability to customize the data: https://github.com/scholarpress/scholarpress-coins/commit/9a7b1f20744cc0421ac190b61463a9cbeae73c88

I think one of the next things I'd want to do is add a "restore defaults" button/link. Right now there's no way to get back to the default values once you delete/change them, except manually.

Let me know what you think of it all.

Matt and Boone,

Can we have uploaded to the Commons, so I can test against:
http://jitpdev.commons.gc.cuny.edu/

Thank you.

Thanks.

Is the intention for folks to generate their own COinS metdata?

I see that the readme states:
'The plugin will automatically add an empty `<span>` to each post and page with COinS data.'
So is the assumption that the user needs to create COinS data for each page within the editing space of the page?

I was able to grab some COins via:
https://www.zotero.org/support/dev/exposing_metadata/coins
but if already in Zotero, then we do not really need this plugin.

I was thinking that there would be an editing interface on the that enables the adding of the metadata in the post/page editor and then the plugin converts to COins and exposes the COins.

As in my example below, COins is not the easiest type of metadata to create:
<span class='Z3988' title='url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fzotero.org%3A2&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Review%20of%20America's%20Half-Century%3A%20United%20States%20Foreign%20Policy%20in%20the%20Cold%20War&rft.jtitle=Presidential%20Studies%20Quarterly&rft.stitle=Presidential%20Studies%20Quarterly&rft.volume=23&rft.issue=3&rft.aufirst=Jonathan&rft.aulast=Nashel&rft.au=Jonathan%20Nashel&rft.au=Thomas%20J.%20McCormick&rft.date=1993&rft.pages=586-588&rft.spage=586&rft.epage=588&rft.issn=0360-4918'></span>

Sorry that was my mistake, not updating the Readme.

The old version of the plugin only does it automatically, this new one both generates some defaults and exposes the kind of interface you're talking about on posts and pages to override the defaults.

Have you tried it on a post as well? Sorry about that - for testing I enabled it just on posts, and forgot to change it back.

Yes, using the default 'Twenty Sixteen' theme.

Is it possible that you pulled in the "master" branch of the repository, instead of 2.0.x, which is our development branch where the changes have been made?

Mea culpa. I see the editor now. Sorry, I forgot that this project was forked.

Wondering if the editor needs multiple creator fields (at least 3), Publisher (journal name) and Issue.

Matt, do you have an opionion?

that sounds reasonable to me, Stephen

Thanks, Matt.

Daniel, can you add:
2 more creator fields.
Publisher field.
Issue field

Thank you.

Thanks, Dan! I will have a look this week.

Stephen, we'll be unable to add this to the Commons until it's had a thorough review; we can't introduce it before the data model is set, or users may enter data that won't work once the final version is in place. If you'd like to test on your own WordPress installation while we're in active development, you can download the plugin from Github.

Hi Dan - Finally getting a chance to look this over. In general, the changes look good. A couple of smallish things, which I'll raise on Github.

Biggest problem I see is that your rewrite doesn't maintain full compatibility with the existing plugin. You've written it in such a way that a post without any saved COinS data will put a bunch of empty fields in the Z3988 span. Any newly created post, or any existing post that is re-saved, will have this data generated. But this causes problems for existing posts that will not have been resaved after update.

I suggest introducing a new function, named something like scholarpress_coins_get_post_data(). Internally, it will do all of the fallback logic you're currently doing in scholarpress_coins_add_coins_meta_box() - the $default_coins_data stuff. Then, use that function both when generating the meta box, and when generating the span on the front end. In this way, the logic is centralized, and even posts that are not resaved will continue to have the fallback values shown after the upgrade to scholarpress-coins 2.0.

Thanks Boone! That's a good point about pre-existing posts. The reason I built it that way originally was in case, for some reason, a user wanted to not include some of the fields that we generate default data for. If we also generate it when we're making the span, that default data will always be included. I think it's worth it though, given what you've said here. We should find some way of letting the user know that'll happen though, so that it's expected behavior.

Maybe we can add a checkbox option to just hide all COinS data for a post/not generate the span instead. We could also include a message like "Fields with a * will be filled automatically from your post's information is left blank." or something.

The reason I built it that way originally was in case, for some reason, a user wanted to not include some of the fields that we generate default data for.

Ah, I guess this means the new fields that have been added? Because previously, all fields were generated, whether the user wanted them or not.

You could bake the distinction between "legacy" fields (which should be filled with default values) and non-legacy fields, into the scholarpress_coins_get_post_data() utility function I've suggested. In the case of "legacy" fields, you would only backfill with default data if you don't find anything in the postmeta table corresponding to the field; if you find the "empty" value (this is what you're using 'scholarpress_coins_empty' for), you wouldn't render the field. In this way, users would be able to disable a field by deleting the suggested value when saving the post, and leaving it blank. In the case of non-legacy fields, it may make sense not to show them at all until they've been saved, for complete equivalence with the previous plugin behavior. Does that seem right?

Boone's suggestion makes sense to me.

Thanks for this, Boone. Here's my attempt to ensure compatibility with version 1: https://github.com/scholarpress/scholarpress-coins/commit/2a8721ed7f1e5263511c1068669c4b9179847d67

I think I'm going to add the "Set to defaults" button next, and then work on the other requested fields.

This seems important to me because right now, if you change the post's title (including changing it from empty to adding something) or categories and update it, it doesn't update the COinS data at all. I think this is the right behavior, but I want to give users a one-click way to update the COinS info to reflect changes they've made to the post, or to just do a reset. This'll mean, however, that changes to the other fields, like author will also be overwritten and set the the defaults. I think it's worth it though to give users the option. Let me know what you think though.

Another option would be to add a checkbox or something next to each field that could say something like "always use default value," which would disable the field and always try to pull in the information from the post data.

Checkbox for each field would provide most flexibility.

Thanks for your continued work on this, Dan. Sorry for the delay in my review.

The new technique for backward compatibility fallback values is good. There was a typo in a variable name that was causing these fields not to be rendered properly, which I fixed in https://github.com/scholarpress/scholarpress-coins/commit/fa8410fe48c1209c0237b9589fb5bad56188f728.

I made some general improvements to the way the admin metabox form is built, which you can see in https://github.com/scholarpress/scholarpress-coins/commit/01d7723cfd63320f0f0e6080d976b16e43c29939. I also added XSS protection on the front end in https://github.com/scholarpress/scholarpress-coins/commit/c00d94c23a5b168a556cc817cc87dc8f5757f187.

if you change the post's title (including changing it from empty to adding something) or categories and update it, it doesn't update the COinS data at all. I think this is the right behavior, but I want to give users a one-click way to update the COinS info to reflect changes they've made to the post, or to just do a reset. This'll mean, however, that changes to the other fields, like author will also be overwritten and set the the defaults. I think it's worth it though to give users the option. Let me know what you think though.

Yeah, this is tricky. I agree that the current behavior is correct - it's good to default to the values that users have manually entered. A per-field "always use defaults" field seems like a decent compromise to me. Maybe the language/UI can use a "lock" metaphor: the field is "locked" to the post field. Then the input would be disabled.

In an ideal world, you'd also have some JS that detects changes to the post fields in question, and updates the disabled fields automatically - this will avoid confusion when a user changes the title, but hasn't yet saved the page, and the DC title field still reads something else. This definitely does not have to be done for v1, but might be a fun little project.

Let's get the lock/sync mechanism in, and we can roll the plugin as a work-in-progress onto the Commons.

Thanks, Dan! The lock feature looks pretty nice. One suggestion: When clicking the lock checkbox, can you dynamically set the field value to the "locked" value? I experimented with this by printing each of scholarpress_coins_get_locked_fields() to its own hidden input, and grabbing it on click. This way, the disabled field will hold the actual locked value, instead of the misleading custom value. (If you go from locked to unlocked, I think it's fine to leave the locked value there - the user may want to use it as a starting point to create the custom, unlocked value.)

I don't think it makes sense to have locks for Source and Date. Locks only make sense for fields that may change. The default Source (the site title) never changes, and the Date, assuming we go with the original post date, should never change. So I don't see any value in having a locking mechanism there.

Would you like me to start testing? If not, let me know when. Thanks.

Good call Boone. I've added that here: https://github.com/scholarpress/scholarpress-coins/commit/56eb7693d17c767805d2e8105f373a32d1d1aa74

Right now I have so that if the user "locks" a field, it pulls in the currently saved values, not the ones entered in the relevant post field before saving: for example, it doesn't pull the value from the post's "Title" field, or a new author if that's changed, or newly added/removed categories. Do you think that works for now or should I try and pull that information in, which would likely mean AJAX requests, at least for the author and subjects fields.

And Stephen - if you wanted to test now that would be great! Still need to add in the option to have additional authors though. We're still on the 2.0.x branch, not master.

I tested and this works great. This will be a great addition for scholarly communications. Thanks!

Thanks for testing, Stephen.

Dan - This is looking good. I just made a few security-related comments on the most recent changeset.

I don't think it's critical to change the locked values dynamically, especially since saving a post triggers a page refresh, which will result in updated "-hidden" values.

Once the escaping fixes are in, let's put this on the Commons and get a little testing with it before we talk about a release.

Sorry about that, Boone. Here's the most recent commit: https://github.com/scholarpress/scholarpress-coins/commit/643897249290af475940c95d65127d75d0a55657

Is there anything I need to do on my end to get in on the Commons for testing?

Hi Boone,

A little confused by your use of Target version. What does 1.9.28 mean?

What is the expected date?

Thanks,
Stephen

Stephen - The "Target version" field is for our internal use, so don't worry about it too much.

The new plugin is on the Commons and ready to be tested.

Thanks, Boone. I see:

ScholarPress Version 2.0 and it already activated in JITP.
Is this correct the correct plugin and version?

Yes, that's it.

I think I found a bug.

This:
http://jitp.commons.gc.cuny.edu/how-i-learned-how-to-stop-worrying-and-pickle-websites-the-art-of-fermenting-the-web-with-archive-it-and-webrecorder/
keeps on being inserted under Date field.

I have deleted it a few times.
It also seems to be the only field not to have the lock feature.

Dan, could you have a look please?

Yes this was a stupid typo on my part! Should be fixed in 2.0.x now.

So do we need to wait for it to be pushed to the Commons? Because I just tested and the bug is still there.

Dan - Thanks!

Stephen - Yes, it'll wait until the next version of the Commons. The deployment process is complex, and I can't do it for the back-and-forth of bug fixing. If you'd like to test the latest changes, you can pull them into a local development environment from the GitHub repo. Thank you for testing!

Boone - just leaving a note to see if there's anything I need to do on my end here, either getting the new version into the repository or anything else.

Dan - Can I ask you to do the following?

1. Update the changelog in readme.txt to explain the new features
2. Make sure the plugin will load translations. I think this just means adding a Text Domain header to the plugin, and calling load_plugin_textdomain() somewhere. Take a first pass using the instructions at https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/. If you can manage it, generate a fake language pack (using Poedit or another tool) to test that it's working. Or pass it along to me, and I'll do a quick test.
3. Bump version and "tested up to" numbers in scholarpress-coins.php and readme.txt headers
4. Give me your wordpress.org username so I can add you as a committer to the plugin (sorry, I forgot what it is)
5. Nice to have! Generate a screenshot of the new interface, and add a description of it to readme.txt. See https://wordpress.org/plugins/about/readme.txt

Once all this is in place, here's how I recommend handling release:

a. Check out the wordpress.org repo: svn co https://plugins.svn.wordpress.org/scholarpress-coins ./scholarpress-coins-svn
b. Replace trunk files: rm -rf scholarpress-coins-svn/trunk/* && cp -R /path/to/git/repo/* scholarpress-coins-svn/trunk/
c. Just for safety, revert the "Stable tag" header in readme.txt to 1.3 - this will allow us to test the wordpress.org-generated zip without forcing user uploads quite yet
d. svn ci -m "Updating files for 2.0 release"
e. Create a tag: svn cp scholarpress-coins-svn/trunk scholarpress-coins-svn/tags/2.0
f. In tags/2.0/readme.txt, bump stable tag to 2.0, and then svn ci tags/2.0 -m "Create tag 2.0"
g. Wait a few minutes for wordpress.org to generate a release zip. Look under "Other versions" at https://wordpress.org/plugins/scholarpress-coins/developers/. Once it's available, download and test a fresh installation to make sure nothing explodes.
h. If everything's good, bump the stable tag up to 2.0 in trunk/readme.txt, and svn ci -m "Bump stable tag to 2.0"
i. If you created a new screenshot (step 5 above), add it to the scholarpress-coins-svn/assets/ directory with the appropriate filename. See https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/

Will the update be available in the Commons before the WP repo?

Stephen - The 2.0 version of the plugin is already running on the Commons. The update that fixes the problem reported in https://redmine.gc.cuny.edu/issues/5490#note-39 will be part of the Commons 1.9.29 release, on October 1.

Hey Boone - I think I've got everything ready on my end, finally. My Wordpress username is dan-jones.

Great! Dan, I've added you as a committer to the plugin on wordpress.org. Let me know if you've got enough info to move forward.

Awesome! Version 2.0 is live in the repository!

Cross-posted from https://redmine.gc.cuny.edu/issues/3300:

Testing on http://jitpstaging.commons.gc.cuny.edu/city-of-lit-collaborative-research-in-literature-and-new-media/, I can confirm that the ScholarPress COinS translator kicks in as planned, and Zotero grabs whatever data is in the custom fields assigned by it. Thanks, Dan, for all your hard work on this plugin!

That said, unless I'm missing a way to trigger it, the plugin currently only allows for one author, with a single clear "last name" field. In the case of multiple authors, I tried a workaround of treating only the first author's last name as the requested "last name," and putting all other authors in the "first name" field, just to see what Zotero would do with it. Perhaps unsurprisingly, it treats this as a single author with a simple last name and a really complicated first name.

Don't get me wrong: it's still a vast improvement, and I'm grateful for it, and in many citation styles it'll probably even look right. But if there could be some way to make "author" a multi-valued array that Zotero could digest, that would be better still.

Thank you, Ben!

For the sake of separating out the issues, I've opened #6435 and added you as a watcher.

Oh wow I'm so sorry about that! I've pushed version 2.1, which should fix that problem. I've also updated it in the Commons codebase, on the 1.9.x branch.

Sorry, ignore my last update, was related to a different ticket, which I've now updated.