Thanks for insisting on this issue, @Coining . Over the Search entry in the top menu I could indeed find and retrieve documents on relatives of mine.

It seems my report was not clear enough. I am sorry about that. In fact, I used the grandparents search, and one of my grandfathers indeed was shown as a search result, but then there were no more data. When I clicked on my grandfather's entry, the said error message was shown. And this did not change when simply reloading pages. I then tried to reload all pages in Ancestry I came across, to no avail. I cannot say whether this is a problem in Ancestry or in Wikipedia LIbrary. This is why I reported my problem and why I asked for further investigation. I hope this makes it more clear so that you can have a further look into the issue that still is indicated on the Wikipedia Library overview of databases. Thanks, again.

I'm afraid I cannot confirm that refreshing the results page solves the problem. When proceeding from one of my grandparents I get the message: "We were unable to find your grandparent in our records. Try a different grandparent."

I also would like to ask whether you please could look into the trouble with Ancestry again. Perhaps we could get some help from Ancestry themselves to sort this out? I've just tried to search for my relatives in Ancestry, but search yielded no result, forwarding me to a login page in the end. It looks like our access has just expired. This should be checked first, before we look into any other technical issues.

I'm afraid, access has not been restored yet … thanks to everyone looking into this!

Works perfectly for me. Please test further, since ProQuest is huge, and I only need a rather small part of it. Thanks to ProQuest for supporting Wikipedians and to everyone involved in restoring access.

Works perfectly for me. Please test further, since ProQuest is huge, and I only need a rather small part of it. Thanks to ProQuest for supporting Wikipedians and to everyone involved in restoring access.

I'm afraid we have lost access to most ProQuest databases without prior notice. This is why I think this is a mistake, probably due to a misconfiguration? Last night, at the resource exchange on German Wikipedia we realised that we can only search ERIC and the Supplemental Educational Index. We cannot access any other databases, that means, we also cannot access newspaper archives as we used to, neither over the web interface nor through my local bookmarks which worked quite well for a long time. I would very much appreciate if you please could look into this. Thanks in advance.

AKL is back, and I've also had a quick look into some legal journals and books that also are available. Many thanks to everyone who helped restore access to this valuable resource!

I just would like to note that @Sandro_Halank_WMDE is right. We now definitely have no access to de Gruyter Brill.

Please note that access to de Gruyter Brill seems to have been restored. So, please check before contacting our partner.

I have a suggestion: Could we please implement a management watching for expiring subscriptions before they expire?

Same here, also 404. But if I use the Library dashboard there is https://wikipedialibrary.idm.oclc.org/login?auth=production&url=http://www.openedition.org for accessing the partner website which redirects me to https://www-openedition-org.wikipedialibrary.idm.oclc.org/ , but our access still has not been renewed, I'm afraid.

@sjvipin Thank you for looking into this issue.

Open Edition offers e-books to read online and to download as PDF or EPUB. But there are some books you cannot access in either way, so if you want to read those you will have to buy them. It makes no difference whether you access those books via our proxy or directly over the website. E.g., https://books.openedition.org/septentrion/12250 cannot be accessed either via https://books-openedition-org.wikipedialibrary.idm.oclc.org/septentrion/12250 I think our access has actually ended. So I would be grateful if you please could ask for a renewal, @Samwalton9-WMF . Thank you very much in advance.

I'm afraid the problem persists. :(

I'm afraid I do not understand what you mean. The TWL landing page links to https://wikipedialibrary.idm.oclc.org/login?auth=production&url=https://www.degruyterbrill.com/ which looks perfectly allright, doesn't it? As the old website for Brill remains online, there is no need to change anything here. I think, the only thing that would need an update is the header for the DeGruyter partner there because this now links to degruyterbrill.com with a new name an a new logo.

@Carolynparrishfan , could you please indicate which e-books you cannot access?

Thanks, again. I've told German editors at https://de.wikipedia.org/wiki/Wikipedia_Diskussion:F%C3%B6rderung/The_Wikipedia_Library#Umstellung_der_De-Gruyter-Website that you are already working on the task.

Thanks for your early response.

This is due to the merger between DeGruyter and Brill. The two websites were migrated to a new domain https://www.degruyterbrill.com/ and the new site does not realise a request comes from the TWL proxy.

From a librarian's POV, a search should yield no result rather than a set or rather a cloud of vague results. That's what I mean. But YMMV, of course.

I see. But we should try to be as specific as possible.

But … if you remove the part with the brackets from the search string the search will not match because the part with the brackets serves as a disambiguator between encyclopeadic lemmata. So, please do not do this.

I'm afraid, the issue persists. :(

I'm afraid the relaunch of Mohr Siebeck's website has lead to a major problem. Clicking on the button to read a resource as PDF, you are now redirected to viewer.content-select.com. That is to say, you are forced to access Mohr Siebeck's own viewer over a domain that we cannot access over our proxy. This seems to be hard coded on the publisher's side. Hence, the user's own IP address gets checked which, of course, is not eligible for access to the site.

Reports are coming in on our feedback page on German Wikipedia that access to the library has been restored, and I can confirm that it also works for me in Firefox, again. Your help is much appreciated.

Right. I deleted all cookies and cache data in Firefox, logged in again in Wikipedia, Wikipedia Library. And the above error persists in Firefox.

Seems to be a cookie issue, indeed. I've logged in to the library pane with Safari now, and it goes right through to both DeGruyter and Nomos. It's working all right.

I've deleted oclc cookies, and the error message in Firefox is still the same: SEC_ERROR_REUSED_ISSUER_AND_SERIAL

I can confirm that the error has recurred, but now it is: SEC_ERROR_REUSED_ISSUER_AND_SERIAL

Works for me, too. Thanks for looking into this so quickly.

Hmm ... deleted cookies again, and now it works for me, too. No idea what caused this because I followed the advice for testing.

You might like to ask community members dealing with the graphics in their project for advice.

Again, thanks for creating this ticket and for looking into this. I have checked again, and I can confirm that access now works again as expected for me. I'd like to watch it for a while, but maybe we could close the task for the time being?

First of all, this is excellent news indeed! Thanks, again, for your hard work.

We have been discussing these and related problems with watchlist layout on German Wikipedia, cf. https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Kein_b%C3%BCndige_Darstellung_der_Beobachtungsliste

I just would like to ask whether you still consider the partnership? Thanks in advance.

Their response was positive. I think we can close this task. Thanks, again, @Samwalton9 and @Sandro_Halank_WMDE !

That's right, thanks. Works again for me, too. I've asked the other users who also had the same problem on dewiki. Maybe we could wait for their feedback.

Indeed. Their website is back up now, and I can confirm that I can also access and download non-free content from SpringerLink. Thanks a lot for looking into this!

But … I wonder whether this is related to our issue or whether springerlink.com is down completely at this time … maybe we should wait a moment …

I'm afraid not. All cookies deleted, I also get an error message from SpringerLink.

Well, we also lost the medical section in Oxford Handbooks Online.

As to T&F, it never was complete. E.g., we have access to this article at T&F, but not to this one.

Thanks. But please note that we do not have access to everything in Academic, cf., e.g., https://doi-org.wikipedialibrary.idm.oclc.org/10.1093/med/9780190050726.003.0033 So, you might like to tell users that some content still may be missing.

Well, not exactly. A meta catalogue is always inferior to the original source because information gets lost. Citoid never worked fine as long as we had only WorldCat there. No objections to additional sources, but please leave K1plus, as is now.

FWIW, K10plus ISBN appears to be superior to the service provided by the German National Library, as observed in Zotero so far. So, no need for a change.

After some testing in my fields of interest I just would like to thank you for this major improvement in Citoid! In fact, it's amazing, much better that what we've had before. :)

I've been using Zotero for managing my personal library extensively over the years. It always used to be superior to the solution we had in Citoid. So I would second using Zotero's ISBN endpoint in Citoid. The Internet Archive cannot be better than that because the national libraries' catalogues are the reference for metadata of any book in print. I'm looking forward to the improvements you are about to implement!

I've just encountered the said problem: My first attempt to log in to the Library failed. Access token generation failed, please try logging in again. When I tried again, it worked.

Gladly, I can confirm that it works again for me, too. DeGruyter is back again on the Library platform. Remains to be seen why the issue appeared only in some accounts. But this may remain unsolved, as everything seems to be back ti normal. Many thanks for your assistance!

I deleted the Library and the DeGruyter cookie before testing, and I cannot access any proprietary content on degruyter.com, either. It seems our subscription has expired and needs to be renwed. I think, it's as simple as that.

@Samwalton9 , thanks for pinging. :) I think, it's alright now. I also posted a notice on German Wikipedia where the issue came up: https://de.wikipedia.org/wiki/Wikipedia_Diskussion:F%C3%B6rderung/The_Wikipedia_Library#Favoriten-Funktion_defekt? So, if you would like to close the task, please go ahead!

Favouriting works immediately for me (the number increments and the authorization is visible in the Favorites tab). Per @jsn.sherman, however, new favorites are placed at the end of the list and are only alphabetised on a page reload.

@jsn.sherman Thanks for the fix! I've tried it out in Firefox on macOS, and it works.

@jsn.sherman I think we can close the issue. I have not had any problems accessing Springer Link lately. Thanks, again, for your kind assistance!

I sedond your suggestion. I just would like to add that if you should opt for a popup solution in the end could you please make it opt-in only? All such major changes to the user interface should be active opt-in, i.e. they should be switched off by default.

Moving something to popups could be a solution. But please note that power users are prone to use Navigation Popups already, so the two should not interfere.

@Jdlrobson we are discussing re-opening this task on dewiki. Could you please have a look into this? Thanks!

@Jdrewniak , your proposed fix to WikidataInfo has been accepted, and the sciript now works as expected:

@Jdrewniak , thank you for looking into this and for contacting @Yair_rand both on this platform and on Wikidata. I would be grateful if you please could fix the issue before the new version of Vector 2022 goes live. Also, I had not realised yet that #contentSub is back again. That's even better.

@Jdlrobson I admit, I had to take a look into my Browser console :) Here it is:

So, I have closed Firefox, renamed my profile, and restarted Firefox again. Logged into Wikipedia and the TWL. Result: SpringerLink worked fine, and so did DeGruyter.

BTW, there is another strange issue with FF 107.0 in MacOS 12 that could be connected to this one:

I'm sorry I did not try another browser before. When I answered your last post about an hour ago I was so much focused on enumerating and re-enabling my add-ons I just forgot about that.

Thanks for your suggestions.

Thanks for checking. No change here, i'm afraid. Same error message as yesterday. The problem only persists with Springer Link.

@jsn.sherman Would you please let me know if there is anything I can do to help find the issue.

I'm afraid I have to correct my former post, as I've just realised that WikidataInfo now appears right below pagetitle. So it seems to work for me. Thx.

Pls cf. also these discussions on German Wikipedia https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Vector_2022_kaputt and on Wikidata for another broken script: https://www.wikidata.org/wiki/User_talk:Yair_rand/WikidataInfo.js#Vector_2022:_Info_not_shown – help would be much appreciated. Thx.

I think this bug report could do with a bit of attention, couldn't it? Thanks.

Thanks. But you might remember the Hitchhiker's Guide to the Galaxy and the part about the planning charts that had been on display somewhere around Alpha Centauri for some fifty earth years without anyone ever realising it? ;)

I strongly agree with my fellow users from German Wikipedia. We are very much used to this feature which is rather useful for reading and writing long articles. Also I have no issues as to website performance etc. Please keep this feature.

Same here. Seems to be working again. Thanks a lot for the quick fix!

I can confirm that the broken main page on dewiki is due to an error in discussion tools. :(

+1. It would make it so much easier to edit Wikipedia, and it would also give back power to the editors who are not content with what the machines do automatically.

Yes, the second scrollbar remains visible when I open the main page of German Wikipedia in Firefox 81.0.1 on macOS 10.13.6.

For the record: I could use drag and drop with a footnote tonight for the first time again. :)

It is the same after updating to Firefox 67.0.

I am sorry to say that the issue has come up again on Geman Wikipedia, so I have reopened the task for re-evaluation. @Cirdan has made a good point in describing the issue and the solution for dewiki above. In the meanwhile @Crazy1880 pointed out to an entry in OCLC that of course does contain the OCLC number, but not an ISBN. In German-speaking countries we rarely refer to OCLC ids. Also, we rarely use WorldCat, we prefer the catalogues maintained by our national libraries that issue ISBN and ISSN for German-language publications. So, I subscribe to Cirdan's description and I would be grateful if you please could change configuration accordingly.

Just to make sure: This worked before, and it only happens in JSTOR, no other resource is affected. I did not change anything about the local configuration.