DOI resolver updated


(Jay Pfaffman) #9

Fixed! Per this commit.

You’ll need to rebake (or just rebuild html if there aren’t many of them) to have it fix posts that are already entered.

If someone could have a look at

and tell me how to make my plugin honor the site setting I created for it, I’d appreciate it.


(Christoph) #10

Jay, I’m sorry if this is a false alarm, but is it possible that your plugin is causing this error:

TypeError: Cannot read property 'addPreProcessor' of undefined

If it is, something like this may be the fix:


Deactivated plugin causes Error 500 on post
(Jay Pfaffman) #11

I’ve been thinking that it’d get broken with the new markdown engine.

Thanks for the link. I’ll have a look in a couple of days.


(Jay Pfaffman) #12

Hey, @zogstrip or @eviltrout. Does discourse-pirate-speak still work? Could you take a look at it (or discourse-doi-resolver) so that I have a super-simple model so I can figure out how to make my trivial plugin work with the new engine?


(Robin Ward) #13

I suspect that one is broken with @sam’s new markdown work. Maybe he can circle back and fix at some point?


(Jay Pfaffman) #14

You mean that in your mind there are higher priorities than the Pirate Speak plugin!?

FWIW, Talk Like a Pirate Day is Sept 19.

:wink:


(Sam Saffron) #15

The regex approach is deeply flawed on quite a few levels, it is edge case central, what happens when the text is already inside a hyperlink?

I will get around to fixing it, already cloned the repo.


(Jay Pfaffman) #16

Agreed! And imagine my surprise to find that someone’s using it!


(Jay Pfaffman) #17

Since some of the plugin howtos refer to discourse-pirate-speak, you might just fix it. This was a trivial modification of that.

If memory serves, I fixed the case where it’s inside of a URL & the only problem is that it fails to replace it if the DOI is at the start of a line.


(Robert) #18

If DOIs are now URLs, should a separate plugin not depreciated in favour of a Discourse onebox based on meta data fetched from Crossref?

As an academic, I generally appreciate the idea to make DOIs work nicely in Discourse. :man_student:


(Christoph) #19

Many (most?) dois when resolved on doi.org are merely pointers to another website which means that they already being oneboxed if the target website supports it:

I used https://doi.org/10.1017/9781316941591 for the box above.

Those that are not forwarded are not oneboxed because doi.org doesn’t seem to support OpenGraph:

https://doi.org/10.1109/5.771073

For these urls it would indeed be great to have onebox support. So the question is whether the team would consider considering doi.org as worthy of it’s own oneboxing engine…

I wouldn’t say that the oneboxing feature would/should replace the doi-resolver plugin because you’d still want that in situations where a doi is mentioned inline, e.g. in a reference.


(Robert) #20

Papers (here from Springer) format DOIs usually like this:

So I would write in the text: doi:10.1109/PTP.2004.1334951 to make clear it is a doi. Now, crossref suggest to move over to https://doi.org/10.1109/PTP.2004.1334951 and one can imagine to drop the scheme, thus one gets doi.org/10.1109/PTP.2004.1334951. This would work also inline in Discourse: doi.org/10.1109/PTP.2004.1334951

The plugin would allow us to have a working link for those, who are too lazy to write .org/ instead of a colon. I am not sure if it is worth is considering that the url format is much better known and supported by various pieces of software.


(Sam Saffron) #21

Be sure to read the last section here: Developer's guide to Markdown extensions


(Jay Pfaffman) #22

Aha! Perhaps I can RTFM my way to a solution! :wink:

@tophee , would requiring DOI: before a DOI be ok with you? That’d make sam’s regex concerns largely moot, & I think compatible with APA’s nonsensical rules. I thought I was being clever (and the only one affected) when I decided to try not to require DOI: in front of one.


(Christoph) #23

It’s your plugin (which I’m happy to use), so I’m not really in a position to demand anything, but since you’re asking, here’s what I think would be good to have in order for this to work for “the average user”:

  1. DOI can be both upper case and lower case
  2. It also works with a space between the colon and the actual doi (if it’s not a big hassle, even two spaces would be nice, knowing that stuff happens…)

(Sam Saffron) #24

The regex even with capture groups will work fine with the post processor, it takes care of only running on text fragments


(Jay Pfaffman) #25

You’re the only one using it, to my knowledge, other than a couple of friends who might again teach a course on an instance I host. You have no right to demand that I fix it immediately, but you represent a large portion of the set base, so you definitely get a vote!

I will do as you suggest when I get around to it (hopefully the end of next week), as I think it works for almost all normal use cases.


(Christoph) #26

Not sure how much time you want to invest in this plugin, but here is a suggestion for how it could be extended: use doi2bib to render a doi as a fully fledged reference.

Or, since turning the bibtex file into an reference (even of one particular style) could be quite laborious, another idea would be to add second link to the bibtex file. Like doi:10.1109/5.771073 (bibtex)


(Jay Pfaffman) #27

Well, the good news for ms is that I have enough paying work that this is pretty far down the list. :slight_smile: (Well, and I’ve been on vacation for most of the past month.) I’ve got a handful of not-really-paying tasks that are a bit higher on my list, but it’s still on the list. . .

Seems like that could be a cool way to one-box a DOI, maybe.

Oh. That’s freaking awesome. If I were still an academic, I’d definitely do that. IN a heartbeat.


(Christoph) #28

Yes, of course! Didn’t even think of that!