gdcc / dataverse-previewers

A collection of Datafile Previewers that can be configured to work with Dataverse
MIT License
5 stars 15 forks source link

All external URL removed and js and css data saved locally. #52

Closed BenediktMeierUIT closed 1 month ago

BenediktMeierUIT commented 5 months ago

All links to external servers such as Cloudflare or Google are deleted and the link is changed in the footnote.

BenediktMeierUIT commented 5 months ago

I have also changed the footer. Old: Screenshot 2024-03-13 144316

New: (link repository) Screenshot 2024-03-13 144247

BenediktMeierUIT commented 5 months ago

In some places, reference was made to the following servers: https://ajax.googleapis.com/ajax/libs/jquery/3.5.1 https://stackpath.bootstrapcdn.com/bootstrap/3.4.1 https://cdnjs.cloudflare.com/ajax/libs/jquery-zoom/1.7.21 https://cdn.jsdelivr.net/handsontable/0.28.4 https://unpkg.com/georaster@1.6.0

It is debatable whether it is good or bad. But I thought these points when I saw it.

This line was called twice in succession. Which is not necessary. (Probably because it was at the end of the other line and it was overlooked.)

The footnote has also been adjusted slightly. This makes it clear where to find the current repo.

BenediktMeierUIT commented 5 months ago

We also have an image of the version running. If you want to test it. https://dataverseno.github.io/dataverse-previewers/previewers/v1.4/...

qqmyers commented 3 months ago

I'm not sure what to do with this PR. For sites running previewers the way we have them in the examples, this just switches it so people's browsers will go to github.io for all the js libraries instead of the normal remote sources (or just copies of those their browsers have already cached). That said, a fully local version is useful for other people. And it is probably a pain to keep both up to date. Are there any tools that might help in converting, i.e. we use remote links but point to /provide a script that can make local copies and adjust the links that people could use for local downloads?

BenediktMeierUIT commented 3 months ago

now i have improved a script and beta version.

I don't quite understand what you mean by local and github.

External URLs version: (Here you need a complete Internet connection without filters.) Screenshot from 2024-05-06 18-06-29

Local files: (Can be called up locally or wherever and you only need to establish a connection. ) Screenshot from 2024-05-06 18-07-13

BenediktMeierUIT commented 3 months ago

What we are currently using. https://dataverseno.github.io/dataverse-previewers/previewers/betatest/PDFPreview.html

BenediktMeierUIT commented 3 months ago

If I assume what you mean by local, that you save the website, that doesn't work either. Because css data is always loaded from a second file. Unless you do something stupid and don't delete the old data in the cache.

It is best to download the repo if you work locally. Then everything always works!

philippconzett commented 3 months ago

Allow me to jump into this thread. Is there any more information needed to move this PR forward? @qqmyers

qqmyers commented 3 months ago

I don't think we want to be responsible for maintaining copies of these libraries. The script approach started by @BenediktMeierUIT is easy to extend to automate making changes to any version of the previewers you want to run - see #63. I'd suggest that we adopt that and the other non-local improvements in this PR instead of adding the libraries directly. If there's some compelling argument to make the version served through github.io use libraries in this repo, this PR should change to only address the betatest version (which could lead to a v1.5 release) and I'd also suggest that we keep the "integrity" attributes in the links (perhaps even require them) - easier to assure those are the same as for the official versions than having to review the large js libraries themselves.

BenediktMeierUIT commented 1 month ago

Is it not good practice to not be able to perform subsequent updates, especially when loading external code. This could also become a problem with this project: https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-your-supply-chain-risk https://cside.dev/blog/more-than-100k-websites-targeted-in-web-supply-chain-attack

I'm just sharing my perspective, you make the decisions and will have to justify them to others. (I always say, no one is perfect and neither is any program.)

qqmyers commented 1 month ago

I am certainly glad we were not serving a bad polyfill from this repo because no one had looked at the script during a review. Regarding decisions, if there's interest in changing the policies for this repo, e.g. regarding whether we serve versions via github.io, or whether/when those past versions change, etc., please feel free to engage the community or the GDCC steering committee. I see my job as trying to keep the technical work aligned with what GDCC and the volunteers here have told the community to expect, and, if that changes, then we can change how this repo operates. Alternately, feel free to set up a repository that is managed differently and we can add a pointer to it's existence in the readme here.