support configuring custom CDN for various default plugins

[Burial0268]

Add a CDN option to emoji plug-in to solve the problem that JSDELIVR is unavailable in some areas.I think it's a good way to solve it（Translate by google）

[frankli0324]

+1 on this, jsdelivr is currently unaccessible in China mainland (TCP connection gets reset during https handshake). due to political reasons, public CDNs often doesn't live well in China (especially when they serve GitHub contents, which jsdelivr do), so it's VERY nice to specify custom private/commercial CDNs.

ref to related code:

https://github.com/flarum/emoji/blob/4582249a632be02e84b70ed54e2d01bd88820e6f/js/src/forum/cdn.js#L5 https://github.com/flarum/pusher/blob/b76645df6c92f53bd96ae3178344a1d0340cba41/js/src/forum/index.ts#L23

I believe I should cc @askvortsov1

[frankli0324]

ref https://github.com/flarum/framework/issues/822 https://github.com/flarum/framework/issues/3353

[frankli0324]

@Burial0268 please change the title into something like support configuring custom CDN for various official plugins thanks

[Burial0268]

@Burial0268 please change the title into something like support configuring custom CDN for various official plugins

oh thanks for your noticed

[SychO9]

Also ref: https://github.com/flarum/emoji/pull/46

[frankli0324]

it seems that more individual components of flarum are integrated with jsdelivr than expected. it's there a true way out rather than dirty patches? patches destroys upgradability...

[ruibaby]

Hi, is there a plan how to support this setting option? I simply modified the Emoji Picker extension:

function loadEmojioneArea() {
    if (emojioneAreaLoaded) {
        return Promise.resolve();
    }

    emojioneAreaLoaded = true;

    return new Promise(resolve => {
        const style = document.createElement('link');
        style.rel = 'stylesheet';
        style.crossOrigin = 'anonymous';
        style.integrity = 'sha256-LKawN9UgfpZuYSE2HiCxxDxDgLOVDx2R4ogilBI52oc=';
        style.href = `${app.forum.attribute('emojioneAreaAssetsSource')}/emojionearea@3.4.2/dist/emojionearea.min.css`;
        document.head.appendChild(style);

        const script = document.createElement('script');
        script.crossOrigin = 'anonymous';
        script.integrity = 'sha256-ImIFrmJd7ymGlVw2MbtI96BNPW4NfcKqM3d1Go665Ig=';
        script.src = `${app.forum.attribute('emojioneAreaAssetsSource')}/emojionearea@3.4.2/dist/emojionearea.min.js`;
        script.onload = resolve;
        document.body.appendChild(script);
    });
}

[frankli0324]

is this discussed somewhere else? could anyone post a link here, maybe toward some discussion in the official forum?

[SychO9]

apart from https://github.com/flarum/emoji/pull/46 is is not discussed anywhere else as far as I know.

[frankli0324]

no one cares about accessibility or what? why?

[SychO9]

We will get to it eventually, there's a lot on our plate.

[aeris]

This issue is pretty serious. This is also GDPR infringment with US unlawfull data transfert and some other unlawfull processing (article 5 & 6 violations). Current code is crippled with hardcoded CDN pretty everywhere and no easy way to rebuild generated source code Currently Flarum is not legally usable in EU without massive fix and hack

[luceos]

As said, there's a lot on our plate. For as long as this issue has been open, someone could also have contributed the necessary changes to the respective extensions. That would be the best outcome. As said before in another issue; the extensions in question don't need to be used either; they're optional. Regardless of Flarum bundling them. You could also fork them and modify the remote source repositories for your own purposes, or republish them under another name. Just saying 🤷

Now, I am fully supporting the notion to remove these hard links and I had hoped to see them gone before. Yet we're a small team doing a lot of things. So this just hasn't been looked at nor taken care of yet. That's the nature of open source sometimes.