Jump to content

Images field returning array, even when max files set to 1


renobird
 Share

Recommended Posts

Hello All,

I have an images field that has "maximum files allowed" set to 1.

My understanding is that calling that field should now return a single image and not an array.

However, when I use:

$user->images

it's still returning an array.

If I use:

$user->images->first()

I can access the image.

Either I'm doing something else wrong, or this is unintended behavior.

:)

Link to comment
Share on other sites

And what does it do if you do a foreach over the array? How many items are there in the array, just the one image? Make sure you really are using the right field etc. I can't reproduce this.

Link to comment
Share on other sites

Soma,

If you can't reproduce it, then it's likely I'm doing something wrong. ;)

I've double checked that I'm using the correct field.

Code:

$image = $user->images;
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";

produces:

<img src="/site/assets/files/41/" height="" width="" alt="" />

If I use this I get the desired results:

$image = $user->images->first();
Link to comment
Share on other sites

Soma,

If you can't reproduce it, then it's likely I'm doing something wrong. ;)

I've double checked that I'm using the correct field.

Code:

$image = $user->images;
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";

produces:

<img src="/site/assets/files/41/" height="" width="" alt="" />

It returns the file url (folder) when the field isn't populated.

try:

if($user->image){

echo $user->image->url;

}

If I use this I get the desired results:

$image = $user->images->first();

That would be? :) You get the image url? So the field is populated? Really weird can't reproduce. :/

Link to comment
Share on other sites

Where is the code being executed? It is in a template or somewhere else?

When in a template, PW puts pages in a state suitable for output with a setting called output formatting. When output formatting is ON, PW takes care of making things output ready so text formatters are applied, dates look like dates (rather unix timestamps), and image fields that set set to have a max of 1 image are resolved to just 1 image (rather than an array of them).

Based on the result you are getting, I would guess that $user has output formatting turned off. This would usually be the case in admin or command line API usage. You can check by doing this:

if($user->of()) {
   // output formatting ON for this page
} else {
   // output formatting OFF for this page
}

You can change the output formatting state by doing this:

$user->of(true); // turns on output formatting
$user->of(false); // turns off output formatting

That of() function was added recently, so if you are using an older PW, you may have to do this:

$user->setOutputFormatting(true or false);
  • Like 1
Link to comment
Share on other sites

Ok now if I populate the image field on the admin user I found it would work with both. I tested with normal pages and it isn't the same behaviour.

I think this has to do with the user pages. Thanks for posting.

Link to comment
Share on other sites

Ryan, now when testing with $user->of(true); I get this error:

Notice: Undefined property: User::$language in /Applications/XAMPP/xamppfiles/htdocs/pw-dev/wire/modules/LanguageSupport/LanguageSupportFields.module on line 125

Edit: and this

Notice: Trying to get property of non-object in /Applications/XAMPP/xamppfiles/htdocs/pw-dev/wire/modules/LanguageSupport/LanguageSupportFields.module on line 126

Edit: it's in front end template basic-page.

Link to comment
Share on other sites

Where are you calling $user->of(true);? Or is the call to $page->images; causing the notice?

I'm not sure what line 126 in LanguageSupportFields.module is referring to because line 126 is a function() statement, so not the one that's generating the error. Some updates were put in recently to the language modules, so you might not have these yet. Either way, the notice is not a concern, as these functions can get called before fields are loaded. Though once we find out where it actually is I can add in an extra check to avoid the notice getting thrown. I did try to duplicate the setup here, but am not getting the notice so it could be version related.

Btw, taking a closer look, output formatting is pretty much always off for users, unless you turn it on. So to get the $user->image behaving as a single image, you'd just have to turn the output formatting on for the $user. I think that's all there is to it.

Link to comment
Share on other sites

Ah ok, now when I solely put this into basic-page:

$user->of(true);

It throws again the two errors. it gets worse the more special echo code comes later.

Edit: sorry, yes they're notices not errors :)

Link to comment
Share on other sites

I'm a bit over my head here, but...

Even though I have the field "maximum allowable files" set to 1, it's still allowing me to add multiple images via the API.

I'm setting the image for that field via:

$user->images = $fileName;

Where $filename is "myFileName.jpg", after it's been sanitized.

If I turn user output formatting on, I get an image, but it's always the original image that was uploaded, not the latest image.

$user->of(true);
$image = $user->images;
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";
$user->of(false);

however, if I leave user output formatting off and use a foreach, I only get a single image returned, and it's always the latest image I uploaded.

foreach ($user->images as $image);
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";

Like I said, I'm a bit over my head—and super new to PW—so I'm not sure if any of the above was helpful.

:)

Link to comment
Share on other sites

@Soma are you running the latest? I'm not getting the notices here, doing the same thing. But if the notices are the same as the one you mentioned earlier, you don't need to worry as the condition is expected (though the notice isn't). I can add an extra check to prevent notices there, but want to make sure we're running the same version first.

@Renobird there actually isn't such thing as a single image field to ProcessWire beyond that output formatting setting. All image fields are multi-image fields behind the scenes. If you enter "1" for max files, and output formatting is ON, then PW takes the first image from it and makes that the value of your $page->image field. So this does a good job of hiding the fact that all image fields are multi-image fields, because anyone that uses them in their regular site development never knows the difference. Likewise, PW's image inputs are monitoring that max files setting and limiting the input to just 1 image. In your case, you are trying to modify the field value, so you have to do the same thing that PW's inputs are doing. My suggestion would be to just set your "max files" setting to 0 so that you are developing with a multi image field. The maxfiles=1 is primarily for output convenience and in your case it's less convenient, so just stick to a multi image field and maybe go back later and adjust it back if you'd like to. This is the same approach PW takes, as any code administratively dealing with images/files is not considering that max files setting until just before output or input.

  • Like 1
Link to comment
Share on other sites

@Soma are you running the latest? I'm not getting the notices here, doing the same thing. But if the notices are the same as the one you mentioned earlier, you don't need to worry as the condition is expected (though the notice isn't). I can add an extra check to prevent notices there, but want to make sure we're running the same version first.

I'm running plain latest version. With Translation installed.

I just pulled latest from today. Still I get the Notices. If I set the $user->of(TRUE), every following echo $page->something throws Notice.

Are you sure you can't reproduce this? Make sure you aren't in a god mode or something. :D

Link to comment
Share on other sites

Hi Ryan,

Thanks for the reply, that helps me understand the images field a lot better.

Turning $user->of() on/off helped solve my initial issue, but I'm still not sure how to solve what's happening now.

Maybe you can help me find away around what's happening when I try to set a new user image via the API?

In ProcessWire I have "max files" set to 1 on the user images field. So when a new image is uploaded to that field from within ProcessWire, the old image image gets overwritten in the file system and only the new image shows in ProcessWire. That's the behavior I would expect.

However, if I upload a new image via the API, it does not overwrite the old image, and the new image is "added" to the images field in ProcessWire.

I thought I could solve that by setting the image filename via the API (which would still leave multiple images in the filesystem, but just show the most recently uploaded in the admin)

$user->images = $fileName;

However, multiple images still show in ProcessWire, and when I try to reference the latest image for that field via the API, it always shows the oldest image.

$user->of(true);
$image = $user->images;
if ($image) {
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";
}
$user->of(false);

Ideally I'd like the admin and the API function the same when modifying the images field. (i.e. use the "max files=1" setting and either overwrite images in the filesystem, or at least not add them in the PW admin. I'm a little stumped on how to make that happen.

Link to comment
Share on other sites

renobird, I think what you would want to do is just simply delete the image first (if there's one) and add new one.

you should be able to do something like this, though you would have to try out.

if(count($user->image)) $user->image->delete();
...

Edit:

...ok maybe not exactly, but looking at api i'll try a moment...

Edit: Ok this works:

if(count($user->image)) { // if already 1 image
   $img = $user->image->first(); // get img
   $user->image->delete($img); // delete it
   $user->save(); // save user page
   $user->image = $config->paths->root . "P1000774.jpg"; // add new image
   $user->save(); // save again
} else { // if no image yet just add one
   $user->image = $config->paths->root . "P1000774.jpg";
   $user->save();
}
  • Like 2
Link to comment
Share on other sites

What Soma posted looks right to me. This is similar to what PW's Inputfield does. Though I'm not sure that the double save is necessary (though not hurting anything either).

Are you sure you can't reproduce this? Make sure you aren't in a god mode or something.

I was just able to duplicate it! Though only when echoing a user field like $user->email. I'm still not getting any notices as a result of just a $user->of(true); call. But I think getting the notices from the echo is enough here for me to fix.

Link to comment
Share on other sites

Soma, did some more testing here and found that the $user->language; reference in LanguageSupportFields could possibly be circular when $user->outputFormatting was ON, and it looks like that's what was causing the strange behavior and notices. This is fixed in the latest commit. Thanks for finding it.

Link to comment
Share on other sites

  • 4 months later...

Nice thread, thank you guys.

Just to confirm...has something changed in latest version since I did not experience this issue?

In other words, when I set the field max to 1, I don't get an array back and it is the latest image displayed (which is what I do want).

So a single field reference worked:

<?php
$image = $homepage->logo;
if ($image) {
echo "<img src='{$image->url}' height='{$image->height}' width='{$image->width}' alt='{$image->get('description|name')}' />";
}
?>

Thank you.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...