Blobfolio

Thanks for clarifying, @saraolesen, but unfortunately I do not have any specific recommendations for you. Accepting files from unauthenticated users is an inherently unsafe operation. If at all possible, I would encourage you to try to collect only text-based information from your web site, and reserve file collection for follow-ups through other channels (like email), once you have established a degree of trust with the contact.

Hi @saraolesen,

Can you clarify what you’re looking to achieve?

This plugin should be compatible with any plugin which (correctly) uses WordPress’ upload API (namely the wp_check_filetype_and_ext() method), but will have no effect in cases where plugins try to implement their own file validation.

As a general rule, I would not recommend using any third-party solution; the safest way to add files to your web site is by using WordPress’ built-in Media Library.

Thanks for reaching out, @jeffkoke!

It looks like the WP Core recently changed the comment_type value for normal comments, which effectively prevented any of Sock’Em’s extra tests from running.

I just put out a new release (1.0.1) that should fix the issue. Please upgrade to that and let me know how it goes! I’ll leave this ticket open in the meantime.

(PS I submitted a test comment to your example post; that can be safely deleted now. Sorry for adding to your moderation woes! Haha.)

• This reply was modified 3 years, 10 months ago by Blobfolio. Reason: Change "issue" to "ticket" to read less ambiguously

Excellent! Thank you for confirming!

Oh, sorry @jofrysutanto:

WordPress doesn’t allow uploads of .sat files by default. (They might slip through because they’re just plain text, but they’ll be renamed to something like .txt.) Programmatically, additional file types are typically allowed by hooking into the upload_mimes filter, but there are also plugins that provide a backend page to manage types.

If you haven’t explicitly enabled .sat files and you have a custom or child theme going on, you can add the following to the functions.php file and it should do the trick:

function allow_sat_uploads($mimes) {
	$mimes['sat'] = 'text/plain';
	return $mimes;
}
add_filter('upload_mimes', 'allow_sat_uploads');

If you don’t have access to modify the theme (because it is e.g. made by a third-party), the easiest way would be to use a plugin like https://www.ads-software.com/plugins/wp-add-mime-types/ (not affiliated with LotF).

• This reply was modified 3 years, 11 months ago by Blobfolio. Reason: Add plugin link
• This reply was modified 3 years, 11 months ago by Blobfolio. Reason: "At" the user

Hi @jofrysutanto,

Thanks for reporting!

If you update to Lord of the Files 1.2.1, and change your client site’s upload whitelist entry to reflect 'sat'=>'text/plain' — a better fit than application/octet-stream — those files should upload A-OK now!

Please give it a whirl and let me know how it goes. I’ll leave the ticket open in the meantime.

Hi @vickief,

There haven’t been any functional changes in the past few LotF releases, only MIME definition updates. (And all the Google Press-related extensions are still there.)

The file validation page’s upload feature works independently of WordPress and the Media Library; if both are broken, I would be inclined to suspect a server/hosting problem rather than something lurking within the site code.

LotF will only produce an “unable to upload” error if the server can’t process the upload at all. There are only three (normal) reasons that would happen:

1. The file was larger than PHP, Apache/Nginx, and/or the OS allows;
2. WordPress does not have read/write privileges to a temporary directory to store the temporary upload;
3. The browser did not actually send any files (which could be because of all sorts of reasons, but they’ll be specific to a given computer);

There are plenty of uncommon reasons too, but I’d start with the above. ??

Are you able to upload JPG files or anything commonplace like that? If you temporarily disable LotF and/or Yoast, does that answer change?

Wow, that was a really productive Monday. ??

Thanks again @vickief for diving into so many support threads!

Thanks for sending those samples, @vickief.

I just pushed a new release of Lord of the Files (1.1.8) that includes fixes for DXF, STEP, and X_T files (which needed some extra love).

(I know you said this site didn’t need X_T support after all, but figured somebody somewhere might benefit, so fixed too that while I was at it. Haha.)

All of the sample files you sent along are being correctly detected on my test site now. When you have a moment, would you please update LotF on your site and retry the Media Library uploads and let me know how it goes? I’ll leave this ticket open in the meantime just in case.

None of the Solid Works formats have official type registrations filed with IANA, but Tika Apache servers have decided to classify them using the group alias type application/sldworks, which is why LotF suggests that as a good choice.

But you’re right, in deep dive Google searches, there are plenty of forum-type results that suggest alternatives like application/sldprt, application/slddrw, application/step, etc.

I went ahead and added these as extra aliases to be thorough.

For your site, it shouldn’t really matter whether you safelist them using the group or the extension-based types. Until they land in IANA, it’s more about what feels right. If application/sldprt looks better, go with that. ??

One last note: assuming these files are working in the Media Library now, they should also work with Gravity Forms (unless the file names trigger a rename hint because of e.g. an UPPER CASE EXTENSION, haha).

Hi @vickief,

Yes please, add the test results for the other file types. If you can send me samples of each (maybe just zip everything together?) I’ll take a look at those as well. They’ll probably need similar workarounds to the DXF type; PHP is really terrible at identifying non-binary file content. Haha.

And thank you for taking the time for all this back-and-forth! Every little report like this helps tick off another file fix. Only ten thousand to go… ??

Hi @vickief,

Thanks for running those tests!

Okay, so the issue with the IGS file is a bug in the Gravity Forms plugin that evidently hasn’t been fixed yet. (Someone else had a similar problem a while back.) You’ll have to point Gravity’s support team to the issue to get a proper fix landed in that plugin, but it lies in gravityforms/common.php, in the GFCommon::check_type_and_ext method.

The short of it is they are incorrectly treating all “renaming” suggestions from the file validation result as failures, rather than checking to see if the renamed file would still be valid for the given form. (In your case, for example, the file you originally tried was getting a rename hint in lower case, which definitely should not have triggered an error; GF should have just accepted the new name and moved on.)

The problematic line in that method reads:

if ( $proper_filename ) {
	return new WP_Error( 'invalid_file', esc_html__( 'There was an problem while verifying your file.' ) );
}

I should be able to add a workaround for your DXF issue to Lord of the Files to get those working for you. (I have a pretty good idea where WordPress is getting confused.) Can you send me a copy of that logo.dxf file? If it is still uploaded to your Media Library you can just drop that link here (it’s okay if the extension is wrong), otherwise you can email a copy to [email protected].

I normally release LotF updates at the beginning of the month, so you’ve got excellent timing. I’ll check to make sure the workaround works with your file and push out the update. ??

• This reply was modified 4 years, 2 months ago by Blobfolio. Reason: Fix typo

Hi @vickief,

I have two quick ideas that may help point to the root of the problem(s). (Keep the Lord of the Files plugin active for these two tests.)

You added an entry for dxf : application/dxf to the upload allowed list for your site, correct? Try changing that associated MIME type from application/dxf to image/vnd.dxf. After doing that, try to upload logo.dxf to the Media Library (not Gravity Forms). Does the file come through OK and un-renamed now? If the Media Library handles it A-OK, try submitting that same file through your Gravity Forms contact form. Does it work there too now?

The second test: try renaming “Google Press Positioner.IGS” to “google press positioner.igs” (lower case). If you try to submit that file through Gravity Forms, is it accepted now?

I should have some follow up questions/answers for you based on what those two tests turn up. ??

• This reply was modified 4 years, 2 months ago by Blobfolio.
• This reply was modified 4 years, 2 months ago by Blobfolio.

Thanks @dsouzaj86!

The plugin itself is open source, but it still has a few closed build dependencies that need to be replaced or recreated before the development repository can be made public. We’re working on it, but it probably won’t be ready until early next year.

I’ll let you know when it’s ready!

Excellent, thank you for confirming, @jjohnsonneon!

Hi @jjohnsonneon,

Thanks for reporting!

The “brf” file type has been added to the MIME database, available now in LotF v1.1.7.

When you have a moment, would you please update the plugin and retry your upload to make sure it works now? I’ll leave the ticket open in the meantime. ??