Blobfolio

Hi @countrypark,

The flip side — WordPress accidentally allowing files it shouldn’t — can be important too, particularly when a site has multiple users of varying technical proficiency.

But otherwise I would recommend deferring to the Golden Rule: don’t install plugins you don’t need to. ??

Unauthenticated file uploads (via a public contact form, etc.) always pose a security risk, but going back to your original question, LotF may not actually be able to help there if the code handling such uploads doesn’t do things the WordPress way.

Hi @countrypark,

WordPress uses the wp_check_filetype_and_ext function to check whether or not an uploaded file is of a type that is allowed to be uploaded to a given site, by a given user.

But the way it is written, it doesn’t work consistently from site-to-site, server-to-server, and tends to reject files that should be allowed, or allow files that should be rejected.

Lord of the Files helps translate the file types detected by PHP into the values WordPress expects, so WordPress can then take the correct action.

In other words, it makes the wp_check_filetype_and_ext function do what WordPress intends it to do. Haha.

Hi @countrypark,

If the plugin (correctly) uses the wp_check_filetype_and_ext method to verify whether or not an uploaded file should be permanently saved to disk, it will benefit from the changes introduced by LotF, but if it doesn’t, it won’t.

If you let me know which plugin you’re using, I’d be happy to take a look and let you know.

Thanks for reporting, @ducktales! The issue should be fixed in 21.7.4.

Hey @dsouzaj86,

Sorry about that. COVID and cancer have derailed that original timeline. Haha.

The main holdup is the plugin needs new build scripts. The current process is just a hacky stopgap, not contributor-friendly.

If you want to shoot me an email ([email protected]), I can zip up and send you the sources. It should give you a decent jumping-off point if you wanted to fork the project.

Hi @pixelcrash,

The default subject for a message is [Site Name] Template Title, but this can be overridden by specifying a subject manually.

For example:

wh_mail_template(
    'the-template-slug',
    array(...),
    array(
       'to'=>'[email protected]',
       'subject'=>'A Manual Subject',
       ...
    )
);

Perfect!

I’m gonna go ahead and close out this ticket, but please don’t hesitate to reach back out the next time file weirdness strikes.

Hi @ianerickson!

By default, WordPress only allows certain file types to be uploaded. Some Adobe formats work out of the box, but Illustrator documents do not. (Lord of the Files does not override these particular settings.)

But the defaults can be changed!

It looks like your site already has a “child theme” set up, which makes it pretty easy. Just drop the following code into the child theme’s functions.php file:

// Allow Adobe Illustrator Uploads.
function allow_ai_uploads($mimes) {
	$mimes['ai'] = 'application/postscript';
	return $mimes;
}
add_filter('upload_mimes', 'allow_ai_uploads');

If you’d rather not make code changes, there are some third-party plugins (not ours) that can help, like WP Add Mime Types. If you go this route, just remember to set the MIME type as application/postscript, same as the code sample.

Either approach should do the trick, but please let me know if you run into any issues.

Hi @tlgray,

There are a couple of different reasons DXF uploads might not be working with Gravity Forms, but it should be fixable.

Do me a favor:

1. Pull up Tools > Debug File Validation in the wp-admin area of your web site
2. Upload an example DXF file
3. Click the “Copy” button in the results (to copy them to your clipboard without formatting)
4. And finally, paste them in a reply to this ticket

I should be able to point you toward a solution with that information. ??

Hi @kyllaz,

LotF only assists with file type recognition (so e.g. WordPress doesn’t get confused and mistakenly block a file); it doesn’t add or subtract from the specific file types a given WordPress site allows to be uploaded.

To whitelist AVIF files for your site, you need to add them to the allowed list.

If you are able to write changes to your theme, you can add something like the following to functions.php:

/**
 * Enable AVIF Uploads
 *
 * @param array $mimes Allowed MIME types.
 * @returns array Allowed MIME types.
 */
function allow_avif_uploads($mimes) {
    $mimes['avif'] = 'image/avif';
    return $mimes;
}
add_filter('upload_mimes', 'allow_avif_uploads');

Never mind about the theme, @solex. The problem is with the WP Core.

The post-password form doesn’t contain any information about the post being visited; it’s just the password field. The generic wp-login.php endpoint handling those requests just blindly shoves a hash of the typed password into a cookie, then tries to work backwards to figure out where the user came from by checking the referral header. (This is the bit that None is breaking for you.)

It’s a very curious design.

Unfortunately this isn’t something Apocalypse Meow can really fix, but I did push a small update, adding information about the possible incompatibility to the referrer-policy info box.

If you have the option to mark your posts “private” rather than “password protected”, I would recommend doing that instead. WordPress’ password protection feature is sketchy. Form weirdness aside, post passwords are stored in plain text in the database and the posts themselves are marked “publish” just like public posts, making it really easy for a theme or plugin to accidentally leak their content.

• This reply was modified 3 years, 6 months ago by Blobfolio. Reason: Clarify sentence subject
• This reply was modified 3 years, 6 months ago by Blobfolio.

Thanks @solex! I’ll take a look and see what weirdness WP is doing. Haha.

Would you mind letting me know what theme your site is using?

Thanks for the kind words, @johanneseva!

Just thought I’d chime in since you mentioned the AVIF image format:

Upcoming changes to both Google Chrome and Firefox — improved standards compliance via libavif — are going to cause a lot of previously-working AVIF images to stop rendering in the browser. (AVIF files have a lot of redundant metadata that many encoders had previously ignored, but now decoding requires (some of) them.)

If you have AVIF images in use on any of your web sites, I’d recommend installing Google Chrome Beta (v.91) and visiting those pages in that browser to make sure the images still load correctly.

If you do end up needing to regenerate the assets, and if you’re on Linux (or are used to building Rust software from source on Mac), you can Google “Blobfolio refract” — I don’t want to get scolded for linking directly, haha — and it should return the Github repository for our guided image encoding software Refract, which tackles WebP, AVIF, and JPEG XL conversions.

AVIFs made with Refract are fully standards compliant and will load A-OK in the upcoming browser releases.

Thanks for reporting, @ducktales!

The PHP 8-related notices should be fixed in version 21.7.2. Please update the plugin once your site shows the new version is available and you should be good to go. ??

Hi @rvnadm,

The current release (21.7.1) should still work in PHP 7.2, however we are no longer testing/supporting environments < PHP 7.4 — WordPress’ current recommended minimum — so future releases will require 7.4. The WP.org PHP requirement has been bumped in anticipation of this change.