Repository: PrestaShop/prestashop.github.io
Pull request #1334: [ARTICLE] Reworking the update assistant v7
Author: login: ga-devfront
Created: 2025-03-04T13:21:57Z | Merged: 2025-03-11T09:26:51Z

| Questions     | Answers
| ------------- | -------------------------------------------------------
| Description?  | Added an article on feedback following the development of V7. The article aims to share a problem that we encountered during development and to invite users to test V7 beta of our module.
| Fixed ticket? | N/A

:warning: Do not merge in production before V7 beta is released

![image](https://github.com/user-attachments/assets/d3a46223-b968-46ca-9130-35225972034b)





Diff:
diff --git a/content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md b/content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
new file mode 100644
index 00000000000..23e724752d4
--- /dev/null
+++ b/content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
@@ -0,0 +1,82 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-11
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [autoupgrade, module, beta, releases, community, contribution, development, qa]
+---
+
+Let’s face it—our Update Assistant module was messy. The front-end was confusing, the user experience was challenging, and even minor adjustments were a little more complex than what we would have liked.
+
+As part of the Seamless Upgrade & Extensibility squad, one of our key missions is to improve the reliability of PrestaShop upgrades. And to do that, we knew the Update Assistant module needed more than just a few patches—it needed a complete reinvention.
+
+So, when we set out to build version 7, we didn’t just fix bugs—we redesigned the whole experience. Cleaner code, a smarter structure, and a user journey that actually makes sense.
+
+Here’s how we dismantled it and rebuilt it from the ground up. 🚀
+
+![Update Assistant V7](/assets/images/2025/03/banner_autoupgrade_v7.png)
+
+## Technical and UX Overhaul
+
+Before we started working on this complete rework, the module had accumulated a number of technical and usability issues that were becoming harder and harder to manage. On the technical side, all the front-end code was crammed into a single JavaScript and CSS file. There were no quality checks in place—no linting, front-end unit tests, or style validation. Every small change meant diving into a large, unstructured file, which made even minor updates risky and time-consuming. The interface was built as a single-page layout where everything was shown or hidden purely through CSS, with `display: none`, making it fragile and inefficient.
+
+On top of that, the user experience wasn’t great either. All the different features—update, backup, restore—were squeezed onto the same page, with a flood of messages, alerts, and options all fighting for attention. Knowing where to start, what was important, and what could wait was hard. This lack of hierarchy, combined with the fact that the page was slow to load, made for a frustrating experience. The main reason for this slowness came from a process running in the background that checked whether the shop met all the technical requirements to perform the update, a necessary step before displaying the page.
+
+To tackle these issues, we made several structural and technical improvements. We introduced a clear project structure with a `_dev` directory, switched to Vite to handle asset compilation and optimization, and added proper quality tools like ESLint, Stylelint, and Prettier. We also introduced Jest to cover our logic with unit tests. External libraries are now managed via NPM, which gives us better control over dependencies and makes future updates easier.
+
+![File restructuring scheme](/assets/images/2025/03/banner_autoupgrade_files.png)
+
+On the UX side, we completely rethought the page by splitting the key functionalities into distinct workflows—one for updating, one for backups, and one for restores. Each workflow has its own guided steps, with clearer messages and a more logical order. We also integrated partial page updates via AJAX, to avoid full page reloads and make the whole experience more fluid.
+
+![Screenshot of the new interface](/assets/images/2025/03/banner_screen_autoupgrade.png)
+
+All these changes combined make the module cleaner, more maintainable, and above all, easier to use for the merchant.
+
+## What obstacles did we encounter?
+
+Despite the technical and UX improvements, the interface did not feel as fluid and responsive as we would have expected while an update was running. One of the key pain points turned out to be the log display itself. During our tests, we noticed that navigating to the log page could sometimes cause the browser to freeze or even crash, occasionally blocking the update process entirely.
+
+A first analysis of the module revealed that an Ajax request could complete in under 100 milliseconds and return a response, yet the interface could take up to a full second to render the logs before triggering the next request. This clearly highlighted our first major bottleneck.
+
+## First axis of investigation – Display
+
+Our initial investigation focused on how each log entry was displayed. We had implemented icons—first as images and later as icon fonts—to indicate the status (success, warning, error). However, this approach also gave us valuable insights into areas where we could further optimize the system:
+
+- Using images slowed down the loading process.
+- Replacing images with font icons further degraded performance.
+- Even removing the icons altogether did not resolve the problem.
+
+In the end, we decided to leave the icons as they were and shifted our focus to identifying other factors impacting performance.
+
+## Second axis of investigation – Performance
+
+We then conducted a performance analysis to identify what was overloading the browser. Although having many `<div>` elements (each log entry in its own container) was a concern, our analysis revealed an even more significant issue. We discovered that forcing the scroll to the bottom of the list triggered a full re-render of the container. Each time the module returned a new log, the browser had to recalculate the maximum length of the logs and update the entire `<div>`, significantly impacting performance, especially when new entries were continuously added.
+
+![Log diagram without virtual scroll](/assets/images/2025/03/banner_no_virtual_scroll.png)
+
+## The adopted solution
+
+To address this challenge, we implemented a virtual scrolling mechanism—a solution inspired in part by <a href="https://blog.logrocket.com/virtual-scrolling-core-principles-and-basic-implementation-in-react/" target="_blank">this article about virtual scrolling</a>. The concept is simple: instead of rendering all log entries at once, we only render those visible in the viewport (with a small buffer above and below to ensure smooth scrolling). The viewport refers to the portion of the list that is currently visible to the user, while all other logs are kept in memory and not inserted into the DOM.
+
+This technique is commonly used for lists with fixed item heights—like what you’d find in a spreadsheet application—but our case introduced two additional complexities:
+
+- Each log entry can have a variable height, since some messages (especially errors) can span multiple lines.
+- The height of the log container itself can change depending on the progress and state of the update process.
+
+These factors made it more difficult to calculate both the overall scrollable height and the exact position of each entry. To overcome this, we dynamically measured the height of each log entry as it was created, updated the total container height in real time, and added a debounce mechanism to the scroll events to avoid overwhelming the browser with constant recalculations.
+
+![Log diagram with virtual scroll](/assets/images/2025/03/banner_virtual_scroll.png)
+
+Beyond improving interface performance, this optimization had a direct impact on the overall update process itself. Each time the front-end requests new logs, it also signals the back-end to continue the update. If displaying logs takes too long (due to rendering bottlenecks), it delays these requests, effectively slowing down the entire update process. By drastically reducing log rendering times, we were able to significantly improve the overall update duration.
+
+In practice, this optimization allowed us to reduce the update time—from over 10 minutes in real-world conditions—to just under 3 minutes.
+
+## Conclusion
+
+The overhaul of Update Assistant V7 required significant improvements in both technical architecture (code structure, quality controls, build process) and user experience (segmented workflows, clearer interface). Despite these advancements, managing the log display proved to be a considerable challenge—one we successfully addressed with a custom virtual scrolling solution that accommodates variable element heights.
+
+We invite you to test the V7-beta of the module by downloading it from the <a href="https://github.com/PrestaShop/autoupgrade/releases" target="_blank">Autoupgrade GitHub repository</a> and sharing your feedback. To do so, please create an issue on the <a href="https://github.com/PrestaShop/PrestaShop/issues" target="_blank">PrestaShop GitHub repository</a> and add the "Autoupgrade" label. Your input is invaluable in helping us refine this new version and make PrestaShop an even more powerful and user-friendly platform.
+
+Thank you for your time and happy updating!
diff --git a/data/authors.yml b/data/authors.yml
index 8d56d64be74..5d51149e00b 100644
--- a/data/authors.yml
+++ b/data/authors.yml
@@ -471,7 +471,7 @@ coffrep:
     display_name: Patrick Coffre
     role: OS Communication Specialist
     avatar: https://avatars.githubusercontent.com/u/103060695?v=4
-    email: patrick.coffre@prestashop.com 
+    email: patrick.coffre@prestashop.com
     github: coffrep
 
 NicolasLoeuillet:
@@ -495,6 +495,14 @@ ThibaultBlivet:
     email: thibault.blivet@prestashop.com
     github: tblivet
 
+AlexisGuyomar:
+    display_name: Alexis Guyomar
+    role: Fullsnack Developer
+    avatar: https://avatars.githubusercontent.com/u/52718717?v=4
+    email: alexis.guyomar@prestashop.com
+    github: ga-devfront
+    website: https://www.linkedin.com/in/alexis-guyomar/
+
 mattgoud:
     display_name: Matthias Goudjil
     role: Front-end Developer
diff --git a/static/assets/images/2025/03/banner_autoupgrade_files.png b/static/assets/images/2025/03/banner_autoupgrade_files.png
new file mode 100644
index 00000000000..e6d039ec6af
Binary files /dev/null and b/static/assets/images/2025/03/banner_autoupgrade_files.png differ
diff --git a/static/assets/images/2025/03/banner_autoupgrade_v7.png b/static/assets/images/2025/03/banner_autoupgrade_v7.png
new file mode 100644
index 00000000000..774bdd07d35
Binary files /dev/null and b/static/assets/images/2025/03/banner_autoupgrade_v7.png differ
diff --git a/static/assets/images/2025/03/banner_no_virtual_scroll.png b/static/assets/images/2025/03/banner_no_virtual_scroll.png
new file mode 100644
index 00000000000..eff00a08c66
Binary files /dev/null and b/static/assets/images/2025/03/banner_no_virtual_scroll.png differ
diff --git a/static/assets/images/2025/03/banner_screen_autoupgrade.png b/static/assets/images/2025/03/banner_screen_autoupgrade.png
new file mode 100644
index 00000000000..c145ef784d9
Binary files /dev/null and b/static/assets/images/2025/03/banner_screen_autoupgrade.png differ
diff --git a/static/assets/images/2025/03/banner_virtual_scroll.png b/static/assets/images/2025/03/banner_virtual_scroll.png
new file mode 100644
index 00000000000..0e7593a3a28
Binary files /dev/null and b/static/assets/images/2025/03/banner_virtual_scroll.png differ


Reviews:
user: login: M0rgan01
state: COMMENTED
author_association: NONE
submitted_at: 2025-03-04T13:46:03Z
user: login: kpodemski
body: I'm blocking not to merge it without our (mine and @coffrep validation).
state: DISMISSED
author_association: CONTRIBUTOR
submitted_at: 2025-03-04T15:37:47Z
user: login: kpodemski
body: I'm leaving a few minor suggestions and a proposal of the publication date.

Also, it could be interesting to emphasize what's worth testing by the community. Could they try and update from v8 to v9 beta? Is that possible? Have you tested it?

I also suggested how to introduce the article a bit better.

Overall a very interesting insights, thank you for the article @ga-devfront !
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-07T09:46:42Z
user: login: coffrep
body: Hi @ga-devfront great post, I'm approving on my end with a few edits. Thanks a lot!
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-10T17:34:28Z
user: login: ga-devfront
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-11T06:02:38Z
user: login: coffrep
body: Hi @ga-devfront I'm approving on my end! All good for publishing.
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-11T09:06:49Z
user: login: matthieu-rolland
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-11T09:26:42Z

Review comments:
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
+---
+
+Let’s be real—our **Update Assistant** module was a mess. The front-end was tangled, the user experience was frustrating, and every small tweak felt like defusing a bomb.
+So, when we set out to build **version 7**, we knew it wasn’t just about fixing bugs—it was about **reinventing the entire experience**. Cleaner code, a smarter structure, and a user journey that actually makes sense.
+Here’s how we tore it down and rebuilt it from the ground up. 🚀
+
+![Update Assistant V7](/assets/images/2025/03/banner_autoupgrade_v7.png)
+
+## Technical and UX Overhaul
+
+Before we started working on this complete rework, the module had accumulated a number of technical and usability issues that were becoming harder and harder to manage. On the technical side, all the front-end code was crammed into a single JavaScript file and a single CSS file. There were no quality checks in place—no linting, no frontend unit tests, no style validation. Every small change meant diving into a large, unstructured file, which made even minor updates risky and time-consuming. The interface itself was built as a single-page layout where everything was shown or hidden purely through CSS, with `display: none`, making it fragile and not particularly efficient.
+
+On top of that, the user experience wasn’t great either. All the different features—update, backup, restore—were squeezed onto the same page, with a flood of messages, alerts, and options all fighting for attention. It was hard to know where to start, what was important, and what could wait. This lack of hierarchy, combined with the fact that the page was slow to load, made for a frustrating experience. The main reason for this slowness came from a process running in the background that checked whether the shop met all the technical requirements to perform the update, a necessary step before displaying the page.
+
+To tackle these issues, we made several structural and technical improvements. We introduced a clear project structure with a `_dev` directory, switched to Vite to handle asset compilation and optimization, and added proper quality tools like ESLint, Stylelint, and Prettier. We also introduced Jest to cover our logic with unit tests. External libraries are now managed via NPM, which gives us better control over dependencies and makes future updates easier.
+
+![File restructuring scheme](/assets/images/2025/03/banner_autoupgrade_files.png)
+
+On the UX side, we completely rethought the page by splitting the key functionalities into distinct workflows—one for updating, one for backups, and one for restores. Each workflow has its own guided steps, with clearer messages and a more logical order. We also integrated partial page updates via AJAX, to avoid full page reloads and make the whole experience more fluid.
+
+![Screenshot of the new interface](/assets/images/2025/03/banner_screen_autoupgrade.png)
+
+All these changes combined make the module cleaner, more maintainable, and above all, easier to use for the merchant.
+
+## What obstacles did we encounter?
+
+Despite the technical and UX improvements, the interface did not feel as fluid and responsive as we would have expected while an update was running. One of the key pain points turned out to be the log display itself. During our tests, we noticed that navigating to the log page could sometimes cause the browser to freeze or even crash, occasionally blocking the update process entirely.
+
+A first analysis of the module revealed that an Ajax request could complete in under 100 milliseconds and return a response, yet the interface could take up to a full second to render the logs before triggering the next request. This clearly highlighted our first major bottleneck.
+
+## First axis of investigation – Display
+
+Our initial investigation focused on how each log entry was displayed. We had implemented icons—first as images and later as icon fonts—to indicate the status (success, warning, error). However, this approach also gave us valuable insights into areas where we could further optimize the system:
+
+- Using images slowed down the loading process.
+- Replacing images with font icons further degraded performance.
+- Even removing the icons altogether did not resolve the problem.
+
+In the end, we decided to leave the icons as they were and shifted our focus to identifying other factors impacting performance.
+
+## Second axis of investigation – Performance
+
+We then conducted a performance analysis to identify what was overloading the browser. Although having many `<div>` elements (each log entry in its own container) was a concern, our analysis revealed an even more significant issue. We discovered that forcing the scroll to the bottom of the list triggered a full re-render of the container. Each time a new log was added, the browser had to recalculate the maximum length of the logs and update the entire `<div>`, significantly impacting performance, especially when new entries were continuously added.
+
+![Log diagram without virtual scroll](/assets/images/2025/03/banner_no_virtual_scroll.png)
+
+## The adopted solution
+
+To address this challenge, we implemented a virtual scrolling mechanism—a solution inspired in part by [this article about virtual scrolling](https://blog.logrocket.com/virtual-scrolling-core-principles-and-basic-implementation-in-react/). The concept is simple: instead of rendering all log entries at once, we only render those that are visible in the viewport (with a small buffer above and below to ensure smooth scrolling). The viewport refers to the portion of the list that is currently visible to the user, while all other logs are kept in memory and not inserted into the DOM.
+
+This technique is commonly used for lists with fixed item heights—like what you’d find in a spreadsheet application—but our case introduced two additional complexities:
+
+- Each log entry can have a variable height, since some messages (especially errors) can span multiple lines.
+- The height of the log container itself can change depending on the progress and state of the update process.
+
+These factors made it more difficult to calculate both the overall scrollable height and the exact position of each entry. To overcome this, we dynamically measured the height of each log entry as it was created, updated the total container height in real time, and added a debounce mechanism to the scroll events to avoid overwhelming the browser with constant recalculations.
+
+![Log diagram with virtual scroll](/assets/images/2025/03/banner_virtual_scroll.png)
+
+Beyond improving interface performance, this optimization had a direct impact on the overall update process itself. Each time the front-end requests new logs, it also signals the back-end to continue the update. If displaying logs takes too long (due to rendering bottlenecks), it delays these requests, effectively slowing down the entire update process. By drastically reducing log rendering times, we were able to significantly improve the overall update duration.
+
+In practice, this optimization allowed us to reduce the update time—from over 10 minutes in real-world conditions—to just under 3 minutes.
+
+## Conclusion
+
+The overhaul of Update Assistant V7 required significant improvements in both technical architecture (code structure, quality controls, build process) and user experience (segmented workflows, clearer interface). Despite these advancements, managing the log display proved to be a considerable challenge—one we successfully addressed with a custom virtual scrolling solution that accommodates variable element heights.
+
+We invite you to test the V7-beta of the module by downloading it from the [Autoupgrade GitHub repository](https://github.com/PrestaShop/autoupgrade/releases) and sharing your feedback. To do so, please create an issue on the [PrestaShop GitHub repository](https://github.com/PrestaShop/PrestaShop/issues) and add the "Autoupgrade" label. Your input is invaluable in helping us refine this new version and make PrestaShop an even more powerful and user-friendly platform.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: M0rgan01
body: links to other sites make us leave the page. We could perhaps use HTML <a> tags and add a target="_blank" to prevent the user from losing context.
created_at: 2025-03-04T13:45:44Z
author_association: NONE
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
+---
+
+Let’s be real—our **Update Assistant** module was a mess. The front-end was tangled, the user experience was frustrating, and every small tweak felt like defusing a bomb.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: ```suggestion
Let’s face it—our **Update Assistant** module was chaotic. The front-end was confusing, the user experience was challenging, and even minor adjustments felt like defusing a bomb.
```
created_at: 2025-03-07T09:32:55Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: ```suggestion
date:   2025-03-11
```

proposal

**important** it has to be merged on this date, otherwise it won't be automatically published on a given date 
created_at: 2025-03-07T09:33:19Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
+---
+
+Let’s be real—our **Update Assistant** module was a mess. The front-end was tangled, the user experience was frustrating, and every small tweak felt like defusing a bomb.
+So, when we set out to build **version 7**, we knew it wasn’t just about fixing bugs—it was about **reinventing the entire experience**. Cleaner code, a smarter structure, and a user journey that actually makes sense.
+Here’s how we tore it down and rebuilt it from the ground up. 🚀
+
+![Update Assistant V7](/assets/images/2025/03/banner_autoupgrade_v7.png)
+
+## Technical and UX Overhaul
+
+Before we started working on this complete rework, the module had accumulated a number of technical and usability issues that were becoming harder and harder to manage. On the technical side, all the front-end code was crammed into a single JavaScript file and a single CSS file. There were no quality checks in place—no linting, no frontend unit tests, no style validation. Every small change meant diving into a large, unstructured file, which made even minor updates risky and time-consuming. The interface itself was built as a single-page layout where everything was shown or hidden purely through CSS, with `display: none`, making it fragile and not particularly efficient.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: ```suggestion
Before we started working on this complete rework, the module had accumulated a number of technical and usability issues that were becoming harder and harder to manage. On the technical side, all the front-end code was crammed into a single JavaScript and CSS file. There were no quality checks in place—no linting, front-end unit tests, or style validation. Every small change meant diving into a large, unstructured file, which made even minor updates risky and time-consuming. The interface was built as a single-page layout where everything was shown or hidden purely through CSS, with `display: none`, making it fragile and inefficient.
```
created_at: 2025-03-07T09:34:56Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
+---
+
+Let’s be real—our **Update Assistant** module was a mess. The front-end was tangled, the user experience was frustrating, and every small tweak felt like defusing a bomb.
+So, when we set out to build **version 7**, we knew it wasn’t just about fixing bugs—it was about **reinventing the entire experience**. Cleaner code, a smarter structure, and a user journey that actually makes sense.
+Here’s how we tore it down and rebuilt it from the ground up. 🚀
+
+![Update Assistant V7](/assets/images/2025/03/banner_autoupgrade_v7.png)
+
+## Technical and UX Overhaul
+
+Before we started working on this complete rework, the module had accumulated a number of technical and usability issues that were becoming harder and harder to manage. On the technical side, all the front-end code was crammed into a single JavaScript file and a single CSS file. There were no quality checks in place—no linting, no frontend unit tests, no style validation. Every small change meant diving into a large, unstructured file, which made even minor updates risky and time-consuming. The interface itself was built as a single-page layout where everything was shown or hidden purely through CSS, with `display: none`, making it fragile and not particularly efficient.
+
+On top of that, the user experience wasn’t great either. All the different features—update, backup, restore—were squeezed onto the same page, with a flood of messages, alerts, and options all fighting for attention. It was hard to know where to start, what was important, and what could wait. This lack of hierarchy, combined with the fact that the page was slow to load, made for a frustrating experience. The main reason for this slowness came from a process running in the background that checked whether the shop met all the technical requirements to perform the update, a necessary step before displaying the page.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: ```suggestion
On top of that, the user experience wasn’t great either. All the different features—update, backup, restore—were squeezed onto the same page, with a flood of messages, alerts, and options all fighting for attention. Knowing where to start, what was important, and what could wait was hard. This lack of hierarchy, combined with the fact that the page was slow to load, made for a frustrating experience. The main reason for this slowness came from a process running in the background that checked whether the shop met all the technical requirements to perform the update, a necessary step before displaying the page.
```
created_at: 2025-03-07T09:35:34Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
+---
+
+Let’s be real—our **Update Assistant** module was a mess. The front-end was tangled, the user experience was frustrating, and every small tweak felt like defusing a bomb.
+So, when we set out to build **version 7**, we knew it wasn’t just about fixing bugs—it was about **reinventing the entire experience**. Cleaner code, a smarter structure, and a user journey that actually makes sense.
+Here’s how we tore it down and rebuilt it from the ground up. 🚀
+
+![Update Assistant V7](/assets/images/2025/03/banner_autoupgrade_v7.png)
+
+## Technical and UX Overhaul
+
+Before we started working on this complete rework, the module had accumulated a number of technical and usability issues that were becoming harder and harder to manage. On the technical side, all the front-end code was crammed into a single JavaScript file and a single CSS file. There were no quality checks in place—no linting, no frontend unit tests, no style validation. Every small change meant diving into a large, unstructured file, which made even minor updates risky and time-consuming. The interface itself was built as a single-page layout where everything was shown or hidden purely through CSS, with `display: none`, making it fragile and not particularly efficient.
+
+On top of that, the user experience wasn’t great either. All the different features—update, backup, restore—were squeezed onto the same page, with a flood of messages, alerts, and options all fighting for attention. It was hard to know where to start, what was important, and what could wait. This lack of hierarchy, combined with the fact that the page was slow to load, made for a frustrating experience. The main reason for this slowness came from a process running in the background that checked whether the shop met all the technical requirements to perform the update, a necessary step before displaying the page.
+
+To tackle these issues, we made several structural and technical improvements. We introduced a clear project structure with a `_dev` directory, switched to Vite to handle asset compilation and optimization, and added proper quality tools like ESLint, Stylelint, and Prettier. We also introduced Jest to cover our logic with unit tests. External libraries are now managed via NPM, which gives us better control over dependencies and makes future updates easier.
+
+![File restructuring scheme](/assets/images/2025/03/banner_autoupgrade_files.png)
+
+On the UX side, we completely rethought the page by splitting the key functionalities into distinct workflows—one for updating, one for backups, and one for restores. Each workflow has its own guided steps, with clearer messages and a more logical order. We also integrated partial page updates via AJAX, to avoid full page reloads and make the whole experience more fluid.
+
+![Screenshot of the new interface](/assets/images/2025/03/banner_screen_autoupgrade.png)
+
+All these changes combined make the module cleaner, more maintainable, and above all, easier to use for the merchant.
+
+## What obstacles did we encounter?
+
+Despite the technical and UX improvements, the interface did not feel as fluid and responsive as we would have expected while an update was running. One of the key pain points turned out to be the log display itself. During our tests, we noticed that navigating to the log page could sometimes cause the browser to freeze or even crash, occasionally blocking the update process entirely.
+
+A first analysis of the module revealed that an Ajax request could complete in under 100 milliseconds and return a response, yet the interface could take up to a full second to render the logs before triggering the next request. This clearly highlighted our first major bottleneck.
+
+## First axis of investigation – Display
+
+Our initial investigation focused on how each log entry was displayed. We had implemented icons—first as images and later as icon fonts—to indicate the status (success, warning, error). However, this approach also gave us valuable insights into areas where we could further optimize the system:
+
+- Using images slowed down the loading process.
+- Replacing images with font icons further degraded performance.
+- Even removing the icons altogether did not resolve the problem.
+
+In the end, we decided to leave the icons as they were and shifted our focus to identifying other factors impacting performance.
+
+## Second axis of investigation – Performance
+
+We then conducted a performance analysis to identify what was overloading the browser. Although having many `<div>` elements (each log entry in its own container) was a concern, our analysis revealed an even more significant issue. We discovered that forcing the scroll to the bottom of the list triggered a full re-render of the container. Each time a new log was added, the browser had to recalculate the maximum length of the logs and update the entire `<div>`, significantly impacting performance, especially when new entries were continuously added.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: ```suggestion
We then conducted a performance analysis to identify what was overloading the browser. Although having many `<div>` elements (each log entry in its own container) was a concern, our analysis revealed an even more significant issue. We discovered that forcing the scroll to the bottom of the list triggered a full re-render of the container. Each time the module returned a new log, the browser had to recalculate the maximum length of the logs and update the entire `<div>`, significantly impacting performance, especially when new entries were continuously added.
```
created_at: 2025-03-07T09:38:16Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
+---
+
+Let’s be real—our **Update Assistant** module was a mess. The front-end was tangled, the user experience was frustrating, and every small tweak felt like defusing a bomb.
+So, when we set out to build **version 7**, we knew it wasn’t just about fixing bugs—it was about **reinventing the entire experience**. Cleaner code, a smarter structure, and a user journey that actually makes sense.
+Here’s how we tore it down and rebuilt it from the ground up. 🚀
+
+![Update Assistant V7](/assets/images/2025/03/banner_autoupgrade_v7.png)
+
+## Technical and UX Overhaul
+
+Before we started working on this complete rework, the module had accumulated a number of technical and usability issues that were becoming harder and harder to manage. On the technical side, all the front-end code was crammed into a single JavaScript file and a single CSS file. There were no quality checks in place—no linting, no frontend unit tests, no style validation. Every small change meant diving into a large, unstructured file, which made even minor updates risky and time-consuming. The interface itself was built as a single-page layout where everything was shown or hidden purely through CSS, with `display: none`, making it fragile and not particularly efficient.
+
+On top of that, the user experience wasn’t great either. All the different features—update, backup, restore—were squeezed onto the same page, with a flood of messages, alerts, and options all fighting for attention. It was hard to know where to start, what was important, and what could wait. This lack of hierarchy, combined with the fact that the page was slow to load, made for a frustrating experience. The main reason for this slowness came from a process running in the background that checked whether the shop met all the technical requirements to perform the update, a necessary step before displaying the page.
+
+To tackle these issues, we made several structural and technical improvements. We introduced a clear project structure with a `_dev` directory, switched to Vite to handle asset compilation and optimization, and added proper quality tools like ESLint, Stylelint, and Prettier. We also introduced Jest to cover our logic with unit tests. External libraries are now managed via NPM, which gives us better control over dependencies and makes future updates easier.
+
+![File restructuring scheme](/assets/images/2025/03/banner_autoupgrade_files.png)
+
+On the UX side, we completely rethought the page by splitting the key functionalities into distinct workflows—one for updating, one for backups, and one for restores. Each workflow has its own guided steps, with clearer messages and a more logical order. We also integrated partial page updates via AJAX, to avoid full page reloads and make the whole experience more fluid.
+
+![Screenshot of the new interface](/assets/images/2025/03/banner_screen_autoupgrade.png)
+
+All these changes combined make the module cleaner, more maintainable, and above all, easier to use for the merchant.
+
+## What obstacles did we encounter?
+
+Despite the technical and UX improvements, the interface did not feel as fluid and responsive as we would have expected while an update was running. One of the key pain points turned out to be the log display itself. During our tests, we noticed that navigating to the log page could sometimes cause the browser to freeze or even crash, occasionally blocking the update process entirely.
+
+A first analysis of the module revealed that an Ajax request could complete in under 100 milliseconds and return a response, yet the interface could take up to a full second to render the logs before triggering the next request. This clearly highlighted our first major bottleneck.
+
+## First axis of investigation – Display
+
+Our initial investigation focused on how each log entry was displayed. We had implemented icons—first as images and later as icon fonts—to indicate the status (success, warning, error). However, this approach also gave us valuable insights into areas where we could further optimize the system:
+
+- Using images slowed down the loading process.
+- Replacing images with font icons further degraded performance.
+- Even removing the icons altogether did not resolve the problem.
+
+In the end, we decided to leave the icons as they were and shifted our focus to identifying other factors impacting performance.
+
+## Second axis of investigation – Performance
+
+We then conducted a performance analysis to identify what was overloading the browser. Although having many `<div>` elements (each log entry in its own container) was a concern, our analysis revealed an even more significant issue. We discovered that forcing the scroll to the bottom of the list triggered a full re-render of the container. Each time a new log was added, the browser had to recalculate the maximum length of the logs and update the entire `<div>`, significantly impacting performance, especially when new entries were continuously added.
+
+![Log diagram without virtual scroll](/assets/images/2025/03/banner_no_virtual_scroll.png)
+
+## The adopted solution
+
+To address this challenge, we implemented a virtual scrolling mechanism—a solution inspired in part by <a href="https://blog.logrocket.com/virtual-scrolling-core-principles-and-basic-implementation-in-react/" target="_blank">this article about virtual scrolling</a>. The concept is simple: instead of rendering all log entries at once, we only render those that are visible in the viewport (with a small buffer above and below to ensure smooth scrolling). The viewport refers to the portion of the list that is currently visible to the user, while all other logs are kept in memory and not inserted into the DOM.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: ```suggestion
To address this challenge, we implemented a virtual scrolling mechanism—a solution inspired in part by <a href="https://blog.logrocket.com/virtual-scrolling-core-principles-and-basic-implementation-in-react/" target="_blank">this article about virtual scrolling</a>. The concept is simple: instead of rendering all log entries at once, we only render those visible in the viewport (with a small buffer above and below to ensure smooth scrolling). The viewport refers to the portion of the list that is currently visible to the user, while all other logs are kept in memory and not inserted into the DOM.
```
created_at: 2025-03-07T09:38:39Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: If I recall correctly, you have to use the tags available in tags.yml, could you confirm?
created_at: 2025-03-07T09:39:23Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,78 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-04
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [module revamp, update assistant, virtual scrolling, UX improvements, performance optimization, frontend, code quality, user experience]
+---
+
+Let’s be real—our **Update Assistant** module was a mess. The front-end was tangled, the user experience was frustrating, and every small tweak felt like defusing a bomb.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: kpodemski
body: Perhaps in the first paragraph, it is worth explaining who you are referring to by writing "us", and what you mean by writing "our", i.e., mention that you are part of the Seamless upgrade and extensibility squad whose one of the missions is to improve the reliability of upgrades 
created_at: 2025-03-07T09:45:43Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,82 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-11
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [autoupgrade, module, beta, releases, community, contribution, development, qa]
+---
+
+Let’s face it—our Update Assistant module was chaotic. The front-end was confusing, the user experience was challenging, and even minor adjustments felt like defusing a bomb.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: coffrep
body: ```suggestion
Let’s face it - our Update Assistant module was messy. The front-end was confusing, the user experience was challenging, and even minor adjustments were a little more complex than what we would have liked.
```
created_at: 2025-03-10T16:50:21Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,82 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-11
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [autoupgrade, module, beta, releases, community, contribution, development, qa]
+---
+
+Let’s face it—our Update Assistant module was chaotic. The front-end was confusing, the user experience was challenging, and even minor adjustments felt like defusing a bomb.
+
+As part of the Seamless Upgrade & Extensibility squad, one of our key missions is to improve the reliability of PrestaShop upgrades. And to do that, we knew the Update Assistant module needed more than just a few patches—it needed a complete reinvention.
+
+So, when we set out to build version 7, we didn’t just fix bugs—we redesigned the whole experience. Cleaner code, a smarter structure, and a user journey that actually makes sense.
+
+Here’s how we tore it down and rebuilt it from the ground up. 🚀
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: coffrep
body: ```suggestion
Here’s how we dismantled it and rebuilt it from the ground up. 🚀
```
created_at: 2025-03-10T16:51:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,82 @@
+---
+layout: post
+title:  "Reworking the \"Update Assistant\" Module V7: Our Experience"
+subtitle: "Transforming Complexity into Efficiency: The Story Behind Update Assistant V7"
+date:   2025-03-11
+authors: [ AlexisGuyomar ]
+icon: icon-rocket
+tags: [autoupgrade, module, beta, releases, community, contribution, development, qa]
+---
+
+Let’s face it—our Update Assistant module was chaotic. The front-end was confusing, the user experience was challenging, and even minor adjustments felt like defusing a bomb.
path: content/news/posts/2025/reworking-the-update-assistant-module-v7-our-experience.md
user: login: ga-devfront
body: I have made the requested changes. Except for the case of hyphens rather than dashes because this is not the correct syntax in English. Here is an article (FR) that talks about it in more detail: https://www.ef.fr/ressources-anglais/grammaire-anglaise/traits-union-tirets/
created_at: 2025-03-11T06:02:38Z
author_association: CONTRIBUTOR

PR comments:
user: login: ps-jarvis
created_at: 2025-03-04T13:22:01Z
body: <!-- PR_WELCOME -->
Hello @ga-devfront!

This is your first pull request on [prestashop.github.io](https://github.com/PrestaShop/prestashop.github.io/) repository of the PrestaShop project.

Thank you, and welcome to this Open Source community!

author_association: NONE
user: login: ga-devfront
created_at: 2025-03-07T08:16:54Z
body: @kpodemski @coffrep we would like to release the BETA next week to be able to release on the 19th, is it possible to review soon? Thanks in advance
author_association: CONTRIBUTOR
user: login: kpodemski
created_at: 2025-03-07T09:31:09Z
body: @ga-devfront, if we schedule the article for the 11th, would that work for you? :)
author_association: CONTRIBUTOR
user: login: ga-devfront
created_at: 2025-03-10T07:21:26Z
body: > I'm leaving a few minor suggestions and a proposal of the publication date.
> 
> Also, it could be interesting to emphasize what's worth testing by the community. Could they try and update from v8 to v9 beta? Is that possible? Have you tested it?
> 
> I also suggested how to introduce the article a bit better.
> 
> Overall a very interesting insights, thank you for the article @ga-devfront !

Thank you for this very constructive feedback. I have made the requested changes. All that is missing is a review of @coffrep and we will be able to merge tomorrow if we manage to release the beta.
author_association: CONTRIBUTOR