Hello Elementor: the empty WordPress theme that hands the work to a builder

The theme's job is to subtract, not to style

Hello Elementor is described as a lightweight and minimalist WordPress theme built specifically to work with the Elementor site builder plugin, and the project description calls it a plain-vanilla theme that resets the environment and prepares it for smooth operation of Elementor. That word resets is doing the real work. A normal theme ships typography, colours, spacing and a layout that fights whatever you put on top of it, and every one of those defaults has to be overridden before a visual builder produces the page you designed. A theme that starts from nothing removes that work. The stated benefits follow from that: it is optimized for speed and performance, and it is positioned as easy to use for both beginners and experienced designers. The README also mentions common WordPress features are supported and can be extended using a child theme, so the theme is a starting point rather than a finished design.

Customisation has three routes and you should pick one early

The project names three ways to add custom styles, and the choice matters because they behave differently under an update. You can do it from inside Elementor itself, which keeps the change in the page content and travels with the export. You can use a child theme, which is the conventional WordPress answer and keeps PHP and CSS overrides separate from the parent. Or you can use an external plugin, which keeps the parent theme untouched and the override outside the theme entirely. The project points to the Elementor developers documentation for going further. The practical advice is to decide which of the three you use before you write anything, because a CSS override written in a child theme and a widget or template written in Elementor can disagree, and once both are in play you get debugging rather than designing. Elementor settings also live in the database rather than in the theme, so a deployment pipeline that only tracks theme files will not carry those changes with it.

Classic templates and a block theme config sit side by side

The repository layout shows a theme that supports both eras of WordPress. There is a theme.json at the top level, which is the mechanism for block theme settings and global styles, along with a modules directory and a template-parts directory, which are the conventions a block theme uses to split its templates into pieces. Alongside that sit the classic PHP template files, index.php, header.php, footer.php, sidebar.php, comments.php and functions.php, so a site that still renders with classic templates has what it needs. The includes directory at the top level carries the rest of the theme's PHP. The presence of both means the theme is not betting on one rendering model, which is a pragmatic choice for something intended to be inherited. The README does not document a minimum WordPress version in what is shown here, so check the readme.txt and the theme header before assuming a version.

The build is a wp-scripts workflow with Composer alongside npm

The package.json file describes the toolchain, and it is a Node and PHP project together. The package name is hello-elementor, the slug is elementor-hello-theme and the version tracked there is 3.5.1, which matches the most recent release tag of v3.5.1. The scripts section shows how the theme is built and checked.

    "name": "hello-elementor",
    "slug": "elementor-hello-theme",
    "homepage": "https://elementor.com/",
    "description": "A sample theme for Elementor.",
    "version": "3.5.1",

The build commands run wp-scripts, the WordPress JavaScript tooling, and the development build calls composer update and composer install before wp-scripts build, while the production build runs composer install with the no-dev flag. The lint script chains CSS, JavaScript and PHP linting, with the PHP side delegated to Composer. There is also a package target that builds for production and copies the result into a directory named after the package, using a .buildignore file to decide what to leave out, and a package:zip target that produces a zip archive of that directory. The top level also carries webpack.config.js, tsconfig.json, .browserslistrc, .prettierrc, .stylelintrc and .eslintrc.js, so the frontend assets are compiled and linted with a modern toolchain rather than hand edited.

Tests run through PHPUnit in Docker and Playwright in the browser

The theme has two test paths, and the split tells you what the project considers worth automating. The PHP tests run phpunit inside a Docker Compose service defined in bin/docker-compose.yml, so the WordPress test environment is containerised rather than depending on a local PHP and MySQL setup. The browser tests use Playwright with a config file under tests/playwright, and there are variants for headless runs in CI and for debugging. The setup step for that environment runs wp-env, the WordPress local environment tool, which is also referenced by a .wp-env.json file in the repository root. A unit test suite is unusual for a theme this minimal, and it is the clearest evidence that Hello Elementor is treated as a maintained codebase rather than a stub. The repository also carries phpunit.xml, phpcs.xml and a composer.json with a composer.lock, so the PHP dependency set is pinned, and the ESLint, Prettier and Stylelint configurations plus a package-lock.json pin the JavaScript side.

Where a deliberately empty theme becomes a problem

The limitation is the same thing as the feature, seen from the other side. If a site has any part of it built outside Elementor, the theme offers no design to fall back on, because that is exactly what it does not provide. Sections, headers and footers built with classic templates have to be styled by hand or by a child theme, and the theme gives you no baseline to inherit. The same reset applies to typography: with no theme defaults, the base font size and line height that a page inherits are whatever the plugin or your own CSS sets, which is a decision someone has to make rather than a default you inherit. A second limit is the dependency on the plugin the theme is built around. The theme is free and open source, but the layout capability lives in Elementor, so a site that stops wanting that plugin ends up with a bare theme and the work of rebuilding every page. The documentation also does not describe an upgrade path for a site that has customised the parent theme directly, which is the standard reason the child theme route exists in the first place.

Licence terms are not stated here, and the release rhythm is regular

One fact a buyer should look up rather than assume: the licence for this repository is not stated in the project listing, so check the LICENSE file and the readme.txt in the theme itself before you build a client site on it. The project describes the theme as free and open source, but the specific grant is the thing that matters for a theme you redistribute or modify. On maintenance, the last push to the repository was on 2026-09-16 and the recent releases are v3.5.1 from 2026-08-26, v3.4.9 from 2026-05-20 and v3.4.8 from 2026-05-20, so this is a project with steady patch releases and a maintained build pipeline rather than a set of files left in place. Note the version gap between the repository and the theme directory, since the screenshot in the README points at version 2.7.1 in the WordPress.org media path while the package.json is on 3.5.1, which tells you the directory release and the repository tag are versioned independently. Support is routed through the Elementor Facebook group, the YouTube channel and the Elementor developers documentation.

Editorial conclusion

Hello Elementor fits a team that builds every page in Elementor and wants a theme that adds no styling of its own, since the whole value of the theme is that it resets the environment rather than adding to it. It does not fit a site whose pages are partly hand written PHP templates, because the theme provides a base and a child theme, not a design system, and it does not fit a team that wants to avoid the plugin dependency it is built around. Before you adopt it, read the theme's readme.txt for the version currently in the WordPress.org directory against the version in package.json, check that the Elementor developers documentation covers the customisation you need, and decide early whether your customisations will live in a child theme or in an external plugin, since the project supports both and mixing them is where the conflicts start.

Frequently asked questions

Official sources

1. elementor/hello-theme on GitHub
2. Issues
3. Project website
4. README
5. Releases