Thread

Since upgrading to v2.4.0 - Build: date 20120123 all the category images that I had assigned to each category have disappeared without a trace. I haven’t accessed any of them and saved, they’re just gone.

I can go through and edit them and utilize the new File upload to get them back, but it means I have to sort through all the other uploaded files or find them on my hard drive again, either one would be tedious as there are many categories.

I guess this might be a bug, but I’m hoping there might be a way to get them back easily?

I have this problem too.

Hello Tony,

I am sorry to hear you are running into this issue.

I am curious as to what version you are upgrading from?

Have you tried to run a Synchronize Files since the upgrade?

I am looking forward to your response.

Cheers!

Synchronize files didn’t help. I think I upgraded from a 2.2 version, can’t say for sure.

Tony,

I am sorry to hear you are still having this problem.

Are you using an add-on like Category Images Manager to associate images with the categories?

Did you double check the permissions on the folder that the images are in?

Regards,

I have the same problem.  When I go to edit the category, I see this:

Category Image URL
Add File
update_category_image

Does that mean I have to update them all manually?

Hello Jules van Schaijik,

It’s unfortunate, but I do believe you need to update them manually.

Tony - how are things going with you?

Cheers,

Didn’t have much of a choice, I had to update them all manually. A bit disapointed that a bug like this got through.

I have the same issue. Was using the category image manage extension, and have over 200 categories. Client not happy! Is there some easy mysql script we could run to update this??

For the record, I wasn’t using any kind of addon, just straight up assigning a URL to the field for the category.

Hi all,

This definitely sounds like a bug with several people experiencing the same problem and as such I have filed a bug report for you on this issue. I encourage you to comment on that thread in order to keep informed of the status of the fix.

Sean

I get this warning when I try and update the category image.

Please update your category image to use the file field provided, or the old style image URL may be deleted upon saving.

I also notice that the categories image urls are now using the

https://ellislab.com/asset/images/team-photo/

prefix instead of the full url as before.
Could it be that this is not parsed??

See my list of categories names with image url beside.

http://deepbluemusic.com.au/products/all-cats
Note: Student Progress Recordings - https://ellislab.com/asset/images/team-photo/progressrecording1.jpg

Hi all,

Sorry you’re having trouble with this. With 2.4, we made the decision to change category images to a file field for consistency, instead of a URL text field. Unfortunately, there was no smooth way to make this transition because the two fields are ultimately two different data types. It’s not reliable to look at the URL entered and then try to guess if that same file exists in an upload directory. So, we have you replace the file when you edit a category.

That said, category image data is not lost upon upgrading to 2.4. It is still in the database and should still render on the front end using the {category_image} tag. It is only when you choose to edit a category that the image could be lost if you don’t enter a new one into the file field.

It’s not perfect, but we felt it was better to make this hard switch to a file field rather than try to accommodate these two different data types for an indefinite period of time.

So, this is currently intended behavior and I believe it’s what you all may be experiencing. The data isn’t really lost, as seen on the front-end, but it may appear lost in the control panel because the text field is missing. If anything I’ve said doesn’t match the behavior you’re seeing and these images are in fact not rendering properly on the front end, let us know and we’ll look into it.

Thanks,
Kevin

Nope, category_image is blank. I might have missed it, but was any of this made note of in the documentation?

Thanks, Tony. I see the issue now. Looks like the old values are still in the database, but they actually do NOT render on the front end as I thought, I think it’s something to do with our file field parse function we’re running that tag through. Very strange, something must have changed after we tested it. I’ll look into it come up with a solution for those still having this issue.

I think the only note of it in the documentation was that the image URL field was changed to a file field.