[Request to become a PrestaShop committer] Nico Hery (@nicohery)

This is a committer application, not a code change. Read the application and its linked pull requests and reviews to assess the candidate's contributions, experience, and availability; the outcome is a decision on the committer request.

Prerequisites

• I understand and accept the project's Code of Conduct.
• I have a record of accepted Pull Requests in the PrestaShop project.
• I have reviewed Pull Requests from other contributors.
• I am aware that this role comes with responsibilities around code review, quality standards, and active participation.

Which part of the project are you applying for?

Core (PrestaShop/PrestaShop), Modules, Theme

Links to your accepted Pull Requests

https://github.com/search?q=org%3APrestaShop+is%3Apr+is%3Amerged+author%3Anicohery&type=pullrequests

• PrestaShop/PrestaShop#41225 Fix attribute and attribute group position ordering in core methods
• PrestaShop/PrestaShop#39576 Add console command prestashop:htaccess:generate
• PrestaShop/PrestaShop#37590 Patch TinyMCE fullscreen
• PrestaShop/hummingbird#871 Fix jsonld error when no manufacturer / brand is set
• PrestaShop/ps_onepagecheckout#185 Align the payment section and footer with the checkout form on desktop
• PrestaShop/ps_onepagecheckout#190 Show a notice on the configuration page when guest checkout is disabled

Open: PrestaShop/PrestaShop#43201, PrestaShop/PrestaShop#43050

Links to Pull Request reviews you performed

https://github.com/search?q=org%3APrestaShop+is%3Apr+reviewed-by%3Anicohery+-author%3Anicohery&type=pullrequests

Why do you want to become a committer?

Hello everyone,

I'd like to apply for the committer role on the Core, Hummingbird and the native modules.

About me

I'm Nico, a web developer since 2006 and a freelancer since 2012, based in Auray, Brittany, France. Most of my work is PrestaShop shops for small and medium merchants, alongside Symfony applications and Kirby websites.

I follow my clients over many years and take their shops through the big migrations: 1.6 to 1.7, 1.6 to 8, 1.7 to 9, then a Hummingbird redesign.

What I work on

My days are spent on live shops: moving them from Classic to Hummingbird or redesigning them on Hummingbird, writing modules, preparing upgrades and chasing bugs that only show up in production. When the bug is in PrestaShop itself, I reproduce it on a clean install and fix it upstream rather than patching the client shop, where the fix would be lost at the next update. That is how most of my pull requests started, from attribute ordering in the core to the one-page checkout layout.

Several Hummingbird redesigns led me to publish hummingbird-child, a minimal child theme starter that builds its own assets from the parent sources, with no extra custom.css or custom.js.

Upgrades are the other half of my work, so I give the agency side on the Update Assistant: module uninstalls (PrestaShop/autoupgrade#1773) and the theme version left stale after an update (PrestaShop/autoupgrade#1759).

Discussions and events

When a change needs agreement before code, I open a discussion first: which attributes product lists show (PrestaShop/PrestaShop#43064), re-applying a theme's theme.yml (PrestaShop/PrestaShop#43235), a "Modules" step in the Update Assistant (PrestaShop/autoupgrade#1775).

I have met the PrestaShop teams at the PrestaShop Dev Conference and the PrestaShop Summit. On 4 November 2026 I joined the Workshop & Hackathon Day at the Summit in Lyon: the Sylius workshop for PrestaShop developers in the morning, then the hackathon, building a Sylius plugin with AI, working as the architect rather than writing every line. I went to learn, to move forward and to challenge myself on a framework I don't use every day.

How I review

I have reviewed 43 pull requests in 11 repositories. I try to only post what I have checked: run the PR's tests without the fix to see them fail, then with it; reproduce the bug before / after on a local install; count queries when the PR is about performance. My local shops run in Docker behind Traefik (traefik-docker-local), so switching one from the base branch to a PR and back takes a few minutes. A few examples:

• PrestaShop/PrestaShop#43027: queries counted before / after on a category page, matching the description.
• PrestaShop/PrestaShop#43040: the new tests fail without the fix and pass with it.
• PrestaShop/hummingbird#1125: tested in the browser before / after, found a side effect the fix also solves and suggested a test for it.
• PrestaShop/ps_onepagecheckout#95: tested before / after in the browser, measured that only one of the reported duplicate ids was still present on main, and why.
• PrestaShop/blockwishlist#464: requested changes twice, approved once fixed.
• PrestaShop/ps_facetedsearch#1348: checked what happens to the rows left before the upgrade, and tested the cleanup query on a real database.

Why committer

Front office, theme and module pull requests often wait for someone who can test them on a running shop. I already do that; as a committer, those reviews would count and help unblock them.

Working as part of the team

I expect my proposals to be challenged, reworked or rejected, and I'm fine with that. I'll respect the backward-compatibility policy and the QA and product workflow, including when my own pull requests have to wait.

Availability & transparency

I'm a freelancer and no company sponsors my time on the project. My merchant clients know I contribute. I commit to about two hours per week, with priority on reviews in my areas: front office, combinations and listings, Hummingbird, native modules and the upgrade path.

I also write custom modules for my clients, without overrides, so I use the hooks and extension points that module pull requests change. When a change matters to one of my clients, I'll say so in the pull request and leave the merge to another committer.

Thanks for considering my application.