How to disable twemoji.classicpress.net prefetch?

Support Version 1.x
#1

After moving a WP 4.9.22 site to ClassicPress 1.5.0, I find a dns-prefetch link to twemoji.classicpress.net in header. That can be a GDPR problem in some countries. How to disable this prefetch?

Expected behavior

No dns-prefetch link

Current behavior

dns-prefetch link

#2

Welcome to the forum. Happy to help.

Add the following code to your theme’s functions.php file. That will remove DNS prefetching:

add_action( 'init', 'classicpress_remove_dns_prefetch' ); 
function  classicpress_remove_dns_prefetch () {      
   remove_action( 'wp_head', 'wp_resource_hints', 2, 99 ); 
}
#3

Thanks but this appears to remove all wp_resource_hints.

How to disable http://twemoji.classicpress.net prefetch?

#4

To disable Twemoji DNS prefetch only, add the following to your theme’s functions.php:

add_filter( 'emoji_svg_url', '__return_false');
#5

Thanks, that seems to work.

Would suggest to disable twemoji integration alltogether or at least make it compatible to “Disable Emojis” functionality in plugins for WordPress, like via "Autoptimize / Extras, which is used on this website.

It is unexpected user experience to suddenly find a dns-prefetch which was disabled in WordPress before migration to ClassicPress.

1 Like
#6

Thanks, great feedback. If WordPress changed how they handle dns-prefetch, we will most likely pick that up as we re-fork.

#7

Autoptimize plugin (and other plugins) compare to an s.w.org URL and remove the prefetch if it matches:

    public function filter_remove_emoji_dns_prefetch( $urls, $relation_type )
    {
        $emoji_svg_url = apply_filters( 'emoji_svg_url', 'https://s.w.org/images/core/emoji/' );

        return $this->filter_remove_dns_prefetch( $urls, $relation_type, $emoji_svg_url );
    }

ClassicPress does not use this URL but its own twemoji URL.

There is nothing changed in WordPress, the URL is changed in ClassicPress.

That’s why plugins in ClassicPress fail to remove emoji prefetch but are able to remove them in WordPress.

Have no real suggestion how to handle this in a better way but adding extra functions.php lines for this to work in Classic Press is extra pita work.

#8

You can try requesting Autoptimize developer to add a check for ClassicPress:

And use the correct URL:

#9

Sorry, I won’t request changes to third party plugins.

Third party plugins should work like in “WordPress without the block editor” as ClassicPress is described.

If ClassicPress changes more than that, it’s a ClassicPress problem.

Gave the ClassicPress project a try today to get an older WordPress 4.9.22 site to be PHP8 compatible but as it seems it’s actually too much of a hassle and actually causes legal risks for client because of mentioned prefetch and maybe similar other yet unknown effects. Also ran immediately in another problem described here which was almost an immediate showstopper already. So I guess, we will not dig into this any further.

Thanks for your quick support though.

#10

Thanks for giving ClassicPress a try. ClassicPress is more privacy-oriented than WordPress.

  • API requests to ClassicPress endpoints send anonymized and fewer data points, unlike WordPress.
  • w.org is most likely owned by Matt Mullenweg. We don’t want user data going to a third, for-profit party. So we have our own domains and resources.
  • Gravatar, another data-collecting third party, is disabled by default.

Plugins or individual features may or may not work with ClassicPress. It’s not perfect, but we’re continually working on improving it based on community feedback such as yours.

The second issue is getting fixed in 1.5.1 and already has a temporary solution as mentioned in the discussion. Every open-source project has bugs, including WordPress (some over 10 years old) :grinning:

#11

Functionality like “disable emojis” in various plugins removes the external integration of s.w.org in browser of end user visitor. That external integration is not allowed to be there without explicit user consent due to GDPR in various countries.

ClassicPress with its own URL reinstates the problem by using another external integration to another external service in browser of end user visitor, which is also not allowed to be there without explicit user consent.

If admins switch to ClassicPress they do not expect to add a new legal problem because ClassicPress silently integrates another external emoji services in a way which bypasses existing “disable emojis” functionality.

Possible solution: Include all emoji files in ClassicPress distribution so no remote server is used in end user visitor browser or drop emoji functionality completely.

#12

We’ve planned on removing emojis for a while, it’s just never happened due to other priorities.

GDPR is an EU law, but our users are all over the world. So we also have to think of them too and by default, emojis are enabled. That’s why it was moved to our own domain/servers.

I do agree that this needs to be fixed, one way or another.

#13

One update on this issue. I submitted a PR to change how Autoptimize removes emoji dns-prefetch. It was accepted and merged with beta. So it will be available in the future version.

As a side note, WordPress removed emoji dns-prefetch a few months ago. So it’s not going to be a problem in the future. As we will begin re-fork, this change will be included in CP v2.

1 Like
#14

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.