Estimated reading time: 5 minutes.
The website lairdubois.fr is a french-speaking portal about woodworking..
Contrary to forums or mainstream social network, the way this platform was designed makes it a reference website with an unparalleled quality.
At the time I'm writing, I can state without a doubt that this is the best woodworking-portal worldwide. UI, UX, Features and of course is community make it a one-and-only place on the Internet. I looked for similar websites in other countries: no chance.
English-Speaking websites about woodworking :
TBD
Asian websites about woodworking :
TBD
Other world areas woodworking websites/portals :
TBD
Attempt to contribute
The first way to contribute is to add content to the website, correct data shared by other users, make it a living platform.
Close to it, the second way of contributing is the monetary donation. This money does not pay the creator but is used to finance the hosting fees of the application (domain name + server hosting).
Finally, the third way is the more challenging one: act on bugs/remarks, feature requests = the code and the application architecture.
The current status shows that some files have not be touched in a while.
I recall from some discussions in the Issues that improvements are welcome but it's not easy to deploy a sandbox... therefore limiting the possibility to let people contribute to the project. And everyone knows that computer scientists are almost all in love with woodworking.
Modernize without hiding the application behind additional layers of complexity. (AI involved)
I haven't practiced this field enough to be able to jump in quick, hence the AI help required. My personal challenge here is to be able to get to a working solution, but also and specifically, to understand what is happening and not end in a situation where a human is not able to understand the project anymore. If totally deputizing an AI on it was the wished solution, I guess Boris Beaulant - the creator of the platform - would have done it already ?
This project is a self-assigned task to re-learn web development and related topics.
Here's the AI suggested roadmap for modernizing lairdubois.fr
P0 — Establish a safe and reproducible baseline
P0.1 — Create a reproducible development environment
A developer should be able to clone the repository, run a small number of documented commands, and get a working application.
P0.2 — Establish a functional baseline before upgrading
Run the current application unchanged in an isolated legacy environment and document its expected behavior.
P0.3 — Build a minimal functional test suite
Cover at least:
- login
- registration
- content viewing
- content creation/update
- search
P0.4 — Replace the obsolete Travis CI setup with GitHub Actions
Run Composer checks, PHP syntax checks, tests, and optionally MariaDB-based integration tests on every branch and pull request.
If achievable : Keep CI logic provider-independent; use GitHub Actions only as the orchestration layer.
P0.5 — Audit Composer dependencies
Identify:
- abandoned packages
- outdated packages
- PHP compatibility blockers
- dependencies no longer actually used
Add composer audit to CI.
P1 — Upgrade the application core
P1.1 — Upgrade Symfony progressively
Follow a controlled path:
Symfony 3.4 → 4.4 → 5.4 → 6.4 → 7.4 LTS
Each major step should have its own branch or pull request, with deprecations resolved before moving to the next version.
P1.2 — Upgrade PHP alongside Symfony
Do not jump directly from PHP 7.3 to a current PHP version on the existing codebase.
Progressively raise the PHP version as Symfony compatibility allows, with a final target around PHP 8.4/8.5.
P1.3 — Upgrade Doctrine progressively
Modernize:
- Doctrine ORM
- DoctrineBundle
- Doctrine Migrations
To early at this step to think about replacing MariaDB with Postgresql.
P1.4 — Replace Swiftmailer with Symfony Mailer
Remove the obsolete mailer stack and migrate existing mail functionality to Symfony Mailer.
P1.5 — Gradually retire FOSUserBundle
Preserve existing user data while progressively moving:
- authentication
- password hashing
- password reset
- security configuration
to native Symfony components.
P1.6 — Remove Assetic
Eliminate the dependency on the old Assetic pipeline.
P1.7 — Remove the legacy Node 10 / Java asset build requirements
Make frontend asset compilation independent from obsolete runtime requirements.
P2 — Simplify infrastructure and application structure
P2.1 — Rework the frontend build independently from the backend migration
Preserve the existing frontend first. Then choose the simplest practical way to build LESS/CSS/JS.
Avoid introducing a heavy frontend toolchain unless it is clearly justified.
P2.2 — Evaluate Elasticsearch before upgrading it
Determine which search features genuinely require Elasticsearch.
Only then decide whether to:
- upgrade it
- replace it
- reduce its scope
- remove it for some use cases
P2.3 — Evaluate RabbitMQ usage
Document exactly what the current consumers and producers do.
Determine whether some use cases can be simplified with Symfony Messenger or another lightweight approach.
P2.4 — Evaluate the WebSocket stack
Check whether real-time features still justify a dedicated WebSocket infrastructure and whether the current implementation should be modernized or simplified.
P2.5 — Review Memcached usage, Measure its actual value.
Consider simpler alternatives where appropriate:
- Symfony Cache
- filesystem cache
- APCu
- Redis only if there is a real need
P2.6 — Modernize Symfony configuration
Progressively move toward the modern Symfony layout:
config/ public/ src/ environment variables secrets outside the repository
P2.7 — Gradually reduce the monolithic LadbCoreBundle structure
Do not rewrite it wholesale.
When code is already being modified, progressively move functionality into clearer namespaces or domains.
P3 — Modernize secondary layers and improve maintainability
P3.1 — Modernize Bootstrap, UIkit and jQuery only after the backend migration
Frontend framework modernization should not block Symfony/PHP modernization.
P3.2 — Measure performance before optimizing
Profile:
- slow HTTP requests
- Doctrine queries
- database indexes
- caching
- image processing
- search
- background jobs
Do not replace a technology simply because it is old if it remains simple, stable and performant.
P3.3 — Simplify image processing and optimization where possible
Review the current ImageMagick, LiipImagine, pngquant, optipng and jpegoptim pipeline and keep only what provides measurable value.
P3.4 — Rewrite the installation documentation
Replace the current Debian 10 / PHP 7.3 / Node 10 / Java 8 / Elasticsearch 5 instructions with a concise modern setup guide.
The goal should be that a new contributor can understand and start the project without having to reconstruct the infrastructure.
P3.5 — Document the application architecture
Add a short technical overview covering:
- request flow
- database
- search
- queues
- WebSockets
- caching
- image handling
- scheduled/background tasks