hydrogriff

@collizo4sky, what you did is a sick and disgusting practice as a developer. The older plugin and the current one are not similar in any way. You should have created a new plugin instead of poaching and misleading users.

I hope you don’t do this sort of cheap things in the future. Your cheap activities have cost thousands of dollars for three schools who updated to your software and got infected.

You should be ashamed of yourself.

Hi @trumani,

The fix works now and have been deployed on all sites. Thank you for a prompt response. I reacted impulsively and I am sorry. I was initially worried that the plugin would eventually lock all free features and move pro only, but now I realize that I am wrong.

Have a good day.

Thank you. I will experiment with manual minification.

Thanks. This resolved the issue!

Thank you for the clarification.

Thanks.

As I mentioned in the previous response, I would like to know what the issue is. Does the fix disable gzip compression totally? What does the fix do?

And about the server, I am the one who maintains it. I see that mime_module is installed. Just not sure where should I start looking for the config. I am a junior developer and I have little experience with core server configs. If it’s not too much to ask, can you point me to the documentation that deals with MIME handling configs – so that I can reproduce the issue in a test server and check if I can find what’s causing the issue.

Hi. Kindly check my previous reply. As I edited it to add a code snippet, the spam filter caught it into moderation. I have added some info.

Thank you for the detailed response Marko. I would like to know what is the issue here. Should I add the fix in the wp-config (which I assume will stop W3TC from storing .gzip files)? Or should I configure my server to allow MIME type overrides?

If it’s the latter, could you show me a hint on how to do that?

Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 expires_module (shared)
 filter_module (shared)
 headers_module (shared)
 mime_module (shared)
 mpm_prefork_module (shared)
 negotiation_module (shared)
 php7_module (shared)
 reqtimeout_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 socache_shmcb_module (shared)
 ssl_module (shared)
 status_module (shared)

These are the active modules from one of the servers.

• This reply was modified 5 years, 4 months ago by hydrogriff.
• This reply was modified 5 years, 4 months ago by hydrogriff.

@eliasgdj, @hackernewbie is not wrong at all. I help some schools maintain their websites and student run WordPress sites. I have factual data that says Gutenberg is useless when it comes to end user.

Not one of the teachers, kids, or even the technically aligned people I have worked with found it useful. Classic editor is what they are using now.

Gutenberg should be a plugin.

It’s not about being good or bad. It’s about being in core. I see gutenberg as an extension to the default editor. So it should be a plugin. Even for the fairly computer literate ones, the default editor is easy to use while gutenberg is alienated with unnecessary complications. Especially, the children find it hard to use. You need to consider the majority of users here.

Keeping it as a plugin is the right and sane choice.