Enabling Unfiltered Uploads
Enabling Unfiltered Uploads
If you’ve ever tried to upload a custom font, an SVG logo, or another non-standard file to your WordPress site and gotten a “Sorry, this file type is not permitted” error, this guide is for you. WordPress blocks many file types by default to protect your site — but with FlyWP’s WP Config editor, you can unlock those restrictions when you have a legitimate need.
Why WordPress Restricts Uploads
WordPress ships with a predefined list of allowed MIME types (file format identifiers that tell the browser what kind of file it’s receiving). Files like .svg, .woff2, and other non-standard types are blocked by default because they can contain embedded code that bad actors might exploit. It’s a sensible default for most sites, but it can get in the way of legitimate design work.
How to Enable Unfiltered Uploads
You can lift these restrictions by adding the ALLOW_UNFILTERED_UPLOADS constant (a PHP setting that controls WordPress behavior) through FlyWP’s WP Config editor:
- Navigate to your site in the FlyWP dashboard.
- Click the WP Config tab.
- Add the following constant:
define('ALLOW_UNFILTERED_UPLOADS', true);- Click Save.
Enabling unfiltered uploads is a security risk. It allows any authenticated user with upload capabilities to upload any file type — including potentially dangerous files like .php scripts. Only enable this if you trust every user on your site who has upload permissions.
Safer Alternative: Allow Specific MIME Types
Rather than opening up all file types at once, consider using a WordPress plugin that adds only the specific types you need. FlyWP recommends this approach for most sites.
Popular options include:
- Safe SVG — allows SVG uploads with built-in sanitization (cleaning) to strip out potentially harmful code
- WP Extra File Types — lets you add specific MIME types to the allowed list without touching any PHP
Who Is Affected
The ALLOW_UNFILTERED_UPLOADS constant affects all users on your site who hold the upload_files capability (permission). This typically includes Administrators, Editors, and Authors. There is no built-in way to restrict it to specific user roles without custom code, which is another reason to prefer the plugin approach when only one role needs the extra access.