Blog Sections Open
Speeding Up or Replacing `getImageList` for MIGX Workloads
If MIGX image output becomes too heavy, the fix is often architectural: reduce repeated parsing, or move to a leaner output pattern instead of patching one call at a time.
MIGX solved a lot of structured-content problems, but image-heavy setups could still become slow if the frontend relied on expensive repeated parsing. The old question here asked whether getImageList could be accelerated, or whether it should be replaced entirely.
When the Problem Appears
The pain usually shows up when a resource stores many images and every request rebuilds all of them through the same parsing path. That is especially noticeable in large listings, sliders, and gallery-heavy pages.
What to Review
- how many image rows are stored per resource
- whether the page renders all images or only the first few visible ones
- whether thumbnails are generated lazily on every request
- whether the data could be prepared once and reused more cheaply
Practical Rule
If getImageList is doing too much work, do not assume the answer is just a micro-optimization. Sometimes the better fix is to reduce the number of items rendered, prebuild thumbnails, or move the data into a simpler gallery workflow for that use case.
The legacy thread mattered because it highlighted a recurring Evolution theme: when output starts feeling slow, the right answer is often to simplify the content flow, not only to tweak the snippet.
A “Mythical” Vulnerability and Why Staying Updated Still Matters
A historical note on the old connector-related security discussion and a practical reminder that uncertain reports are still a reason to update carefully and promptly.
Troubleshooting TinyMCE After Updating an Evolution Build
What to check when TinyMCE stops working immediately after a build update even though the rest of the manager still loads.