A build-to-order shared foundation layer for your Odoo website themes — one common library of QWeb snippets, SCSS design tokens, and reusable OWL/JS widgets that every child theme inherits. ECOSIRE scopes, builds, installs, and supports it for you. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
ऐप मैनिफ़ेस्ट
आपके वर्कफ़्लो के अनुरूप बनाया गया
A build-to-order shared foundation layer for your Odoo website themes — one common library of QWeb snippets, SCSS design tokens, and reusable OWL/JS widgets that every child theme inherits. ECOSIRE scopes, builds, installs, and supports it for you.
स्वयं सेटअप की ज़रूरत नहीं — ECOSIRE द्वारा निर्मित, इंस्टॉल और समर्थित एक कार्यशील ऐप।
एक बार के निर्माण मूल्य से शुरू करें। किकऑफ़ पर हम आपके साथ मिलकर दायरा तय करते हैं।
ECOSIRE इसे आपके Odoo पर बनाता, कॉन्फ़िगर और इंस्टॉल करता है।
आप लगभग 2–4 सप्ताह में लाइव हो जाते हैं, लॉन्च के बाद समर्थन अवधि के साथ।
Teams that run multiple Odoo website themes — or one theme that keeps growing — hit the same wall: every design duplicates the same building blocks. The same hero snippets, the same pricing tables, the same color and typography rules, the same JS carousel and mega-menu code get copy-pasted from one theme module into the next. When a brand color changes or a snippet has a bug, you edit it in five places and inevitably miss one. Odoo's native website builder gives you snippets and a theme structure, but it has no concept of a shared library that several themes can depend on; core website assets are global and hard to version, and a stock off-the-shelf apps.odoo.com theme ships its utilities locked inside its own package where your other themes can't reuse them. That is exactly the gap this build-to-order module closes.
We build theme_common as a dedicated foundation module that your other theme modules declare as a dependency in their __manifest__.py. It centralizes the parts that should only exist once: a versioned SCSS layer of design tokens (color palette, spacing scale, typography, breakpoints) exposed as CSS custom properties and Bootstrap/Odoo SCSS variable overrides; a curated set of reusable QWeb <template> snippets registered against website.snippets so they appear in the drag-and-drop builder of every child theme; and a library of OWL components and vanilla JS website widgets (publicWidget) for interactive elements like sliders, tabbed content, animated counters, and sticky headers. Assets are wired through the assets_frontend and web.assets_frontend bundles so each dependent theme loads the shared code once, in the right order, without duplication.
Technically, the module is structured so child themes override rather than fork. Design tokens live in SCSS partials that a child theme can re-declare to re-skin the entire component set without touching markup. Snippet options are defined in the standard snippet_options XML so your editors get the same inline controls (color pickers, layout toggles, spacing) across every design. Where content needs to be data-driven we add small models.Model helpers with computed fields (@api.depends) and expose them safely to the frontend, with access governed by ir.model.access.csv and record rules so public-website rendering never leaks backend data. Everything is built and tested against Odoo 17.0, 18.0, and 19.0, and we note the Community vs Enterprise differences that matter for website features so your deployment target is handled correctly from day one.
Because this is made-to-order, delivery works as a short, structured engagement rather than an instant download. We start with a scoping call to inventory your existing themes, the snippets and widgets you want consolidated, your token/design system, and your target Odoo version and edition. We then build on a staging branch, run UAT against your real content, and hand over installable source, documentation, and a git repository. Typical delivery is 2–4 weeks from confirmed scope, depending on how many themes and components are folded into the shared layer. Pricing starts from $249 (indicative, single-company base scope); the number of child themes consolidated, the depth of the design-token system, custom interactive widgets, and any migration of existing snippet content increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise.
Builds and maintains several Odoo website themes for clients and wants one shared utility layer so snippets, tokens, and widgets stop being copy-pasted across every project and can be fixed in one place.
Runs multiple branded microsites or a large multi-page site on Odoo and needs a consistent design system — shared colors, typography, and reusable blocks — that survives Odoo upgrades without re-work.
Owns the addons path and cares about clean module boundaries: wants shared theme code isolated in a dependency module with proper asset ordering, security rules, and no core monkey-patching.
Needs every website design to stay on-brand and lets the team re-skin the whole component set by changing design tokens, without touching QWeb markup or risking inconsistent pages.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Code reuse across multiple themes | One shared dependency module every theme inherits | Possible but you design and maintain it yourself | Utilities locked inside one theme package | |
| Design tokens / re-skinning | SCSS token layer + CSS variables; re-skin without touching markup | Whatever you build; often inconsistent | Fixed to the vendor's palette and options | |
| Fit to your themes | Scoped to your exact snippets, widgets and brand | Fully bespoke, but all effort is on you | Generic; you adapt to it, not the reverse | |
| Odoo version coverage | Built and tested for 17.0 / 18.0 / 19.0 to your target | Only what you build and retest yourself | Often lags new Odoo releases | |
| Upgrade safety | Clean inheritance, no core monkey-patching | Depends entirely on your discipline | Varies; can break on point releases | |
| Security of data-driven snippets | `ir.model.access.csv` + record rules enforced | Your responsibility to get right | Rarely applicable / not exposed | |
| Support & accountability | Post-go-live window + fixed-quote engagement | Internal team owns all fixes | Vendor forum/tickets, variable SLA | |
| Handover | Source, docs, training and git repo with history | Whatever you produce internally | Packaged module, limited docs |
This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope. The timeline depends mainly on how many of your existing themes and how many snippets/widgets we consolidate into the shared layer, plus your target Odoo version. We confirm the exact schedule after the scoping call.
Pricing starts from $249 as an indicative figure for a single-company base scope. The final number depends on the count of child themes consolidated, the depth of the design-token system, any custom interactive widgets, and migration of existing snippet content. After a short scoping call we send a fixed, written quote — you never commit to a variable or open-ended price.
Every engagement includes a post-go-live support window for bug fixes and questions. Because the module is built with upgrade-safe inheritance (no core monkey-patching), it is designed to survive Odoo point releases. We also offer ongoing maintenance and version-upgrade support (for example moving from 17.0 to 18.0 or 19.0) as a separate arrangement if you want it.
It's designed to work with your existing themes, not replace them. During scoping we inventory your current theme modules and decide which snippets, widgets, and tokens move into `theme_common`. Your themes then declare it as a dependency in their `__manifest__.py` and inherit the shared library — usually with light refactoring rather than a rebuild.
We build and test against Odoo 17.0, 18.0, and 19.0. The module targets the website framework that exists in both Community and Enterprise; during scoping we confirm your edition because a few website features differ, and we make sure the delivered module fits your exact deployment target.
Yes — that's a core design goal. We use clean QWeb inheritance and XML `xpath` overrides, register snippets through the standard `website.snippets` mechanism, and wire assets through the official `web.assets_frontend` bundle rather than patching core. This keeps the drag-and-drop builder intact and minimizes breakage across point releases.
Yes. The shared snippets appear in the standard drag-and-drop website builder with normal inline options (color pickers, layout toggles, spacing), so your editors work the way they already do. We include a user guide and a training session so the team is comfortable using the shared blocks across every design.
A build-to-order shared foundation layer for your Odoo website themes — one common library of QWeb snippets, SCSS design tokens, and reusable OWL/JS widgets that every child theme inherits. ECOSIRE scopes, builds, installs, and supports it for you.