ninsan

@fullworks I just realized I never got back to you on this. I just wanted to let you know that I tried the code you provided (placed it a mu-plugin file) and it works excellently. Thank you for your help! ??

Hi @tigroumeow , thanks for replying. ??

You are right, and I can see why my question is confusing. At the time of writing my original post, my rationale for wanting to include trashed media items in the results of the Media Cleaner scan was that I was looking for a way to easily detect all files that 1) are currently not in use and 2) take up physical space on the server. Since files in the WP media trash still take up physical space on the server (thus potentially weighing the server down), I thought it would be convenient if the Cleaner could detect those as well, which would allow me as an admin to delete all unused and trashed files in one simple, fell swoop. ?? I have since found an alternative solution to this issue, which basically involves setting up a simple Cron schedule that automatically empties the media trash every two weeks (instead of the default 30 days it usually takes for files to be permanently deleted).

/jenny

@davidanderson Thank you for clearing that up, I appreciate it. ??

I copied the ‘header.php’ file into my child theme and replaced the call to graphy_logo() with my own customized version of the function. Works perfectly, thanks! ??

If there is a built-in function, I haven’t had any luck in finding it. :/

I have some coding experience, so if there is a way to do it without using a plugin, I’d be happy to try it. ??

@fullworks Hello, thank you for replying. ?? You make a good point and, admittedly, I have not tested whether setting the ‘EMPTY_TRASH_DAYS’ constant has any effect on media library files. However, as I am interested in targeting trashed files in the media library exclusively, it wouldn’t be an option anyway as setting the constant would also alter the auto-delete interval of posts, pages and comments. The site I am building requires trashed media files to be saved for 14 days before permanent removal, while other post types should be saved for the default period of 30 days before permanent deletion.

/jenny

@wpusermanager Hi, thanks so much! I can’t believe I didn’t think to check in the ‘custom fields’ part of the plugin’s admin menu before asking here (sorry). Thank you for taking the time to reply. ??

/jenny

Just dropped you a line via the WPUM contact form. ??

Hi @polevaultweb , thanks for helping. ?? I enabled debugging in ‘wp-config.php’ according to your guidelines (I also had to deactivate another security plugin because it was preventing the ‘debug.log’ file from being created), however nothing is written to the ‘debug.log’ file when I try to delete the images from the test user’s account. There are a few lines of information in the file, but from what I can tell these warnings have nothing to do with what is happening (or not happening) on the WPUM user account page (there is no reference to the WPUM plugin in the warning messages). I can of course still send the file to you via email, if you want(?).

/jenny

2) Nevermind, I figured out how to do it myself. ?? For anyone reading this who is new to programming (like me) and wondering how I did it, here is the code:

 add_filter('wpum_upload_dir', 'jr_wpum_custom_uploads_directory');

 /**
  * Set the WPUM uploads directory to the default WordPress uploads directory.
  * @param string $wpum_dir_name The name of the WPUM uploads directory.
  * @return string The (modified) directory name.
  */
 function jr_wpum_custom_uploads_directory($wpum_dir_name) {
	 $wpum_dir_name = ''; // Empty string means the default WP uploads directory will be used.
	 return $wpum_dir_name;
 }

Hi @polevaultweb, thank you for replying. ??

1) On the Account settings page, when I click on the ‘remove’ link next to each image and then click the ‘Update Profile’ button, the page reloads and a message saying “Profile successfully updated” is displayed. However, when I scroll down on the Account page both images are still there, as if they had never been removed. They are also still showing on the user’s Profile page. Unless something else is amiss in my local development environment, this seems like a potential bug to me.

2) How would I go about writing the callback for the ‘wpum_upload_dir’ filter? I tried the following code but it threw me an internal server error:

 add_filter('wpum_upload_dir', 'jr_wpum_custom_uploads_directory');

 function jr_wpum_custom_uploads_directory($pathdata) {
	 $wp_upload_dir = wp_get_upload_dir();

	 $pathdata['path'] = $wp_upload_dir['path'];
	 $pathdata['url'] = $wp_upload_dir['url'];
	 $pathdata['subdir'] = $wp_upload_dir['subdir'];

	 return $pathdata;
 }

Thanks. ??

/jenny

@bcworkz to the rescue. ?? Your suggestion to use the filter ‘wp_handle_upload_pre_filter’ did the trick, I am now able to successfully block file uploads larger than 2 MB via the browser uploader. For anyone interested, this is what the code looks like:

add_filter('wp_handle_upload_prefilter', 'jr_max_upload_size_limit_browser');

/**
 * Set the maximum size limit for files uploaded with the Browser Uploader. Apply to all users except admins.
 *
 * @param array $file An array of data for a single file.
 * @return array The (modified) file array.
 */
function jr_max_upload_size_limit_browser($file) {

    if (!current_user_can('administrator') && $file['size'] > 2097152) { // 2 MB
        $filename = $file['name'];
        $file['error'] = "{$filename} exceeds the maximum upload file size allowed on this website.";
    }

    return $file;
}

Thank you @howdy_mcgee and @bcworkz for your help, I really appreciate it. ??

/jenny

Here’s what I’ve tried: I bulk-deactivated all my plugins, removed all mu-plugin files (except the one containing the ‘upload_size_limit’ callback) and set the theme to the default Twenty Twenty-One theme. The problem still persists: when a non-admin user with default ‘upload_files’ permission (an editor or author) clicks on Media > Add New in the admin menu and selects the Browser uploader, they are still able to upload files greater than 2 MB even though the page explicitly says “Maximum upload file size: 2 MB”. If they choose the Flash uploader, however, the callback works as expected, i.e. it prevents the user from uploading files > 2 MB. The code also successfully blocks 2+ MB uploads in the Block/Gutenberg Editor.

In other words, the issue appears to be unique to the Browser uploader on the ‘wp-admin/media-new.php’ page. For whatever reason, the ‘upload_size_limit’ callback has no effect in terms of actually blocking files greater than 2 MB from being uplodaded with the Browser uploader.

Hi @howdy_mcgee, thanks for responding. ?? My bad, I should have been more specific: by “non-admin” I mean authors and editors. Authors and editors are allowed to upload files by default in WordPress, unless I am mistaken. I am not using any plugins to expand the builtin upload functionality of WordPress, I am only using the core upload features.

/jenny

Hi @corrinarusso, thank you for helping. ?? Your link to the Stackexchange post set me on the right track! As it turns out, in order to show a list of only the author’s own posts in the “Find Posts” modal window in the Media Library List View, $pagenow must be equal to ‘admin-ajax.php’, since this is the file that is responsible for fetching the list of posts via a call to the wp_ajax_find_posts action in ‘ajax-actions.php’.

My final code looks as follows:

add_action('pre_get_posts', 'jr_show_only_users_posts_in_find_posts_modal');

/**
 * Show only user's own posts in the 'Find Posts' modal window, unless
 * user is admin or editor.
 *
 */
function jr_show_only_users_posts_in_find_posts_modal($wp_query) {
    global $pagenow;

    $find_posts = (isset($_POST['action']) && $_POST['action'] === 'find_posts');

    // target the post query for the Find Posts modal
    if (!is_admin() || $pagenow !== 'admin-ajax.php' || !$find_posts) {
        return;
    }

    // Authors
    if (!current_user_can('administrator') && !current_user_can('editor')) {
        $wp_query->set('author', get_current_user_id());
    }

    return $wp_query;
}

I have included the $find_posts condition in the hopes that this will help target the ‘get_posts’ query within wp_ajax_find_posts more precisely, though I am not sure if this actually has any effect (the code works without the condition, too). If anyone would like to weigh in on the possible pros or cons of doing it this way, feel free to do so!

/jenny