When changing the desired width/height settings for a flexinode image field, it seems not to take effect on existing nodes. I have to re-save each single node for the new display size to take effect. This is a daunting task on a site with loads of existing flexinode images.

Tips, anyone?
- is there a "workaround" one can use to re-save all flexinode with a command, until there is a flexinode fix for this?

Comments

Leeteq’s picture

Leeteq commented
Version: 4.6.x-1.x-dev » 4.7.x-1.x-dev

oops, correction: this is about the 4.7 version (as far as I know)

Leeteq’s picture

Leeteq commented

"Bump"... Is it possible to somehow (perhaps run a SQL command) resave (hence "update") all flexinodes in one operation? A concern is that it should not affect the "edited" date (should not make them appear as "updated" on top of the activity lists).

The only goal is to ensure that the settings change for the image field takes effect on each one...

Bèr Kessels’s picture

Bèr Kessels commented
Title: No effect on existing Flexinode nodes when image size settings change. » Optionally change existing images when thumbnail settings change
Version: 4.7.x-1.x-dev » master
Component: Code » Field type: image
Category: bug » feature
Priority: Critical » Normal

This is a feature request, and not a critical bug.

Leeteq’s picture

Leeteq commented
Version: master » 4.7.x-1.x-dev
Category: feature » bug

When changing a central setting, and the change is actually not applied to the content, not even as a selectable mass-update option, I would say that is such a serious limitation that it qualifies to be categorised as a bug. It should not even be necessary to do an update of the content, but simply have the new settings apply on subsequent rendering of the content. (that would be a change of how things work, I know).

Anyway, the report was about the 4.7 platform and still is.

Bèr Kessels’s picture

Bèr Kessels commented
Version: 4.7.x-1.x-dev » master
Category: bug » feature

Sorry to be stubborn. But no, this /is/ a feature. You think of but one case, the case where you want everything to change.

Another case can be 'from now I want all my thumbs to be bigger'. Applying that change, and expecting it to work backwards on all the existing thumbs may seem logical to you, it is just one way of looking at it. the way it is working now, was intentional. Yet your case is very usefull and valid too, it is certainly not the only one.
I am setting back the issue as feature request for HEAD.