Default image not being resized

I've confirmed this bug. Steps to reproduce:

1. Place a large image image.png in sites/default/files.
2. Go to admin/config/people/accounts and enter sites/default/files/image.png in the Default picture field. Leave the default values for other fields and submit the form.
3. Visit user/1. The large image will be unscaled.
4. Click the Edit tab and upload a different large picture. Save.
5. The image will now be properly scaled to thumbnail dimensions.

Tagging.

The problem lies in line 1413 of user.module

if (module_exists('image') && file_valid_uri($filepath) && $style = variable_get('user_picture_style', '')) {

Suppose that my default picture is 'sites/default/files/defaultuser.jpg' then file_valid_uri() will return FALSE, as file_valid_uri() expects a file_stream_wrapper.
This is needed as theme_image_style() only works with files inside the public files directory.

I think it would be best to add a validation function on the user_admin_settings() form to check if users entered a public file path.

Let's see if my logics makes sense ;)

Can we:

1. Confirm whether this issue still exists in D8 and D7 HEAD.
2. Check for duplicates of this issue (it sounds familiar).
3. Add an automated test that follows my STR in #3.
4. Update the patch to apply to D8 HEAD.
5. Manually test the patch to confirm the functionality; watch particularly for any bugs that reflect test failures from the existing patch. Provide before-and-after screenshots.

1. I can confirm this issue still exists in D8
2. I searched but couldn't find any duplicates
3. I never wrote a test script, maybe someone else can do this so I can watch and learn?
4. Done, attached.
5. Works, but please re-test ;)

user picture is going to be a field in D8, I'm not sure it's usefull to fix this now while this is going to be removed anyway (in D8). Not saying this isn't needed in D7.

Well, in that case: back to D7 then? I'm happy to try and change the test script?
The main difference in my solution here is that I change the field from being used as path, to a filename.

Old situation

Path: pictures
Default picture: sites/default/files/myfile.jpg

New situation

Path: pictures
Default picture: myfile.jpg (will be searched and fetched from the pictures directory)

We should fix this regardless of the user-image-as-field conversion.

Giving this a try at code sprint

mallezie: patch in #10 works, but it only needs test scripts.

I can confirm this works. And that the bug still existed.
Only problem seems to be the two failing tests.

This is (i think) caused because the test compares the picture path with the path of the resized path.

http://drupal8.localhost/sites/default/files/simpletest/244924/image-test.png
This is the path of the original file, and compares it to the path on the user-page which is the resized picture

http://drupal8.localhost/sites/default/files/simpletest/244924/styles/thumbnail/public/http%3A//drupal8.localhost/sites/default/files/simpletest/244924/image-test.png
this is the value in (string) $elements[0]['src']

It contains both the string of the original file, which is correct, but also adds the resized image path.
Further i'm stuck on this. Hope this helped.

Hi guys,

I'm taking over the test writing for this issue, but I've been digging into the code a bit and found (or think so) the source of the problem.

It's not only the fact that the paths didn't match (the patch has solved that for me), but also that there's no resize being done at when saving the user_admin_settings. So, when choosing an image style, it's all fine, because with the patch in #10 the paths match. The system doesn't find the image on the first time it fetches it, so it creates and stores it. That's done on the template_preprocess_user_picture() hook:

if (module_exists('image') && file_valid_uri($filepath) && $style = variable_get('user_picture_style', '')) {
        $variables['user_picture'] = theme('image_style', array('style_name' => $style, 'uri' => $filepath, 'alt' => $alt, 'title' => $alt));
      }
      else {
        $variables['user_picture'] = theme('image', array('uri' => $filepath, 'alt' => $alt, 'title' => $alt));
      }

However, if no style is chosen, the if clause above will not pass, and the else clause will be executed, calling the filepath without any style at all, hence displaying the original file that was *not* resized when saving the user_admin_settings form.

So, in addition to the patch rolled, there should be a submit handler for user_admin_settings that resizes the picture and saves it (in a similar why to what is done when a user uploads the picture). Other option would be style it with the sizes defined on the settings form every time it's loaded. I'd go with the first one though. Happy to work on the patch to add those changes and re-roll it after I'm done with the test.

Allright, let me have a look at it again.

This should pass the tests.

I've removed the testExternalPicture test, as it does make sense to test for external images right?
The admin can only select default pictures within the public file path, so no external ones. The user can only upload pictures, and they will be stored within the public file path. So I don't see what the use of this test is.

Or am I missing something?

Now with patch.

+++ b/core/modules/user/user.admin.inc
@@ -383,7 +383,7 @@ function user_admin_settings() {
-    '#description' => t('URL of picture to display for users with no custom picture selected. Leave blank for none.'),
+    '#description' => t('Filename of the picture to display for users with no custom picture selected. It should be placed in the picture directory. Leave blank for none.'),

This makes theme provided user pictures useless? At least an absolute path is not possible anymore according to this description which is what I currently use.

I meant to say this probably breaks current Drupal 7 sites.

+++ b/core/modules/user/user.module
@@ -958,7 +958,7 @@ function template_preprocess_user_picture(&$variables) {
+      $filepath = file_build_uri(variable_get('user_picture_path', '') . '/' . variable_get('user_picture_default', ''));

This is Drupal 7 right using variable_get :)

Clemens, you are right about full urls not working anymore. So the most pragmatic solution is the above patch. If you want to support theme-given default avatars then theme_imagestyle should be changed as well, 'cause at the moment, it is just not possible to resize images outside of the files directory.

#21: default-image-not-being-resized-1371742-21.patch queued for re-testing.

Hmmm ... I expected the test run for D7 ...

I assume @BarisW in #13 was right in that we only need a D7 version.

In #21 tests were removed. Do we need a new test? I guess not as that would be 'just another image_style test'.

The patch in #21 is for D8.
As Tim said in #14, we want this for D8 too and them we can backport to D7.

Still an issue, unassigning myself.

The patch in #21 needs a reroll before we can look at the tests again.

This bug seems to be fixed in D8 as a result of converting the user picture to an image field, http://drupal.org/node/1292470. I followed these steps,

1. Place a large image in sites/default/files.
2. Go to admin/config/people/accounts/fields and set the default image as the oversized image. Leave the default values for other fields and submit the form.
3. Visit user/1.

and the image was resized. There is no longer a form field for a default picture on admin/config/people/accounts in Drupal 8.

updating tags since according to #32 a re-roll for 8. x is not needed.

I guess it would be more accurate to say that this needs a backport, since the patch in #21 is for D8.

Instructions for backporting are here, but the test file will have moved. If you're using patch -p2 < path/you/saved/patch/in.patch you'll be asked something like "File to patch:" when it comes to the test patch. You can skip the test hunk of the patch by pressing return, then patch the test file manually.

Rerolled the patch in #21 for D7.x

added "needs issue summary update" tag

This works, but since the location of the image now has changed it will break sites that use a default image. After upgrading the site admin need to manually move the default file to the 'sites/default/files/pictures/' directory (or whatever was configured). So I'm not sure this is suitable for Drupal 7 as is.

Added an issue summary

Patch in comment #35 works great! Only the description below the field was bit wrong. So here is a new patch with better description. Now tests are required as mentioned in tags.

So, as of January 2014, what is the recommended solution for D7?

Is the patch needed? Is that the only way to get the default image to display properly as a thumbnail?

Thanks.

38: default-image-resized-1371742-38.patch queued for re-testing.

This problem can be reproduced in D7 using the steps from the issue summary. So this is still an issue here (not in D9, because the user picture is a field here). Here are some examples what a user can enter in the Default picture textfield:

1. public://image.jpg or any other Drupal supported scheme (URI)
If you enter an URI, then the image is resized on output.

2. sites/default/files/image.jpg (relative path)
If you enter a relative path, then the image is not resized on output.

3. https:// example.com/image.jpg (internal or external URL)
If you enter an URL, then the image is not resized on output.

I think we cannot use the approach in #38 anymore, as this would change the behavior for all existing sites and disable the possibility to use URLs in this field (definitely there are sites using this). Actually I don't see how could we resize this type of images.

We can try to detect relative paths from the point no. 2, but as this does not fix the issue as a whole, I am not convinced this is a best approach. Another option is to close this as Won't fix in this D7 stage.