rocketweb / module-cms-import-export
rocketweb/module-cms-import-export
CMS import and export CLI command extension that allows syncing CMS blocks & pages between environments
CMS Import/Export Tool
A tool to manage CMS content (both blocks & pages) being imported/exported between environments using the repository. This tool comes handy for build and maintenance projects.
Ideas for using this:
- allowing FED team to create a CMS block/page in admin but then modify the HTML content using proper IDEs that allow auto-complete & code-styling
- allowing simpler deployments since there is no manual copy/paste of CMS data needed
- allowing the client to modify staging content and having it ready for deployment
- having an easy way to sync up production env to staging/dev/local by exporting on production and importing on
staging/dev/local
Installation
Using composer:
composer require rocketweb/module-cms-import-export
Then enable module:
bin/magento module:enable RocketWeb_CmsImportExport
Once the tool is installed, we have two workflows, depending on what we are trying to do.
Export
Usage:
php bin/magento cms:dump:data [options]
Description:
Dumps cms pages/blocks to var/sync_cms_data for further import
Options:
-t, --type=TYPE Which type are we dumping - block/page/all
-i, --identifier[=IDENTIFIER] identifier to process (one or CSV list)
-a, --importAll Flag to import all files
-r, --removeAll Flag to remove all existing data
As you can see from the options, we need to define:
- type - which can be CMS block, CMS page or both - required
- identifier - either a CMS block or CMS page identifier - optional
With the combination of these two, we can export:
- all CMS content (using --type=all)
- all CMS pages (using --type=page)
- all CMS blocks (using --type=block)
- specific CMS page or pages (using --type=page --identifier=about-us.html,no-route)
- specific CMS block or blocks (using --type=block --identifier=who-are-we,homepage-carousel)
CMS Page identifier is Url Key! Because of that, it can have .html suffix - it depends on what is set in the
Magento Admin CMS Edit Page. Use the actual value from CMS Edit Page - Url Key!If the CMS Page Url Key has .html suffix, then the file %%IDENTIFIER%% will be: url_key_html.html (but for export or import, you still use the value from Url Key)
Once you execute the command, you will get the following folder structure:
var/sync_cms_data/cms/
- blocks
- %%IDENTIFIER%%.html => contains the block HTML
- %%IDENTIFIER%%.json => contains title, is_active, stores information
- pages
- %%IDENTIFIER%%.html => contains the page HTML
- %%IDENTIFIER%%.json => contains title, is_ative, page_layou, content_heading
You can modify the HTML directly in your editor which should give you more flexibility.
When you are done, commit the files (html & json) to the repository.
Import
Usage:
php bin/magento cms:import:data [options]
Description:
Import cms pages/blocks from var/sync_cms_data
Options:
-t, --type=TYPE Which type are we importing - block/page/all
-i, --identifier[=IDENTIFIER] identifier to process (one or CSV list)
-a, --importAll Flag to import all files
-s, --store[STORE_CODE] Store code to process only pages/blocks specific to this store
This command works by using files in var/sync_cms_data/cms/ path. As you can see from the options, we need to define:
- type - which can be CMS block or CMS page - required
- identifier - either a CMS block or CMS page identifier - optional
There are optional parameters: - importAll - when identifiers not specified we'll import all blocks or pages
- store - store code (like default) to import block(s)/pages(s) only for specific store
With the combination of these two, we can import: - all CMS pages (using --type=page and importAll)
- all CMS blocks (using --type=block and importAll)
- specific CMS page or pages (using --type=page --identifier=about-us,homepage-new)
- specific CMS block or blocks (using --type=block --identifier=who-are-we,homepage-carousel)
- specific CMS page by store (using --type=page --identifier=about-us-default --store=default)
Once you execute the command, the content will be created/updated in Magento Admin.
By executingphp bin/magento cache:flushyou should be able to see the updated CMS content on frontend also!
No changelog yet
The vendor hasn't published a changelog. Tagged releases appear in the Versions tab.
Requires 2
| Package | Constraint |
|---|---|
| php | ^7.4|^8.0 |
| magento/module-cms | 104.0.* |
Requires-dev 2
| Package | Constraint |
|---|---|
| phpunit/phpunit | ^10.5 |
| reach-digital/magento2-test-framework | ^1.7 |
Compatibility
Each Magento release line is installed on its supported PHP versions, then the module is built (DI compilation + static-content deploy) and its unit and integration suites are run. The matrix shows the lines and PHP versions the module is confirmed to install and run on. Code-quality results further down (phpstan, phpcs, …) are reported separately and never affect compatibility.
Code Quality
Advisory checks against the module's source. Static analysis runs once across the whole module; PHPStan re-runs per Magento + PHP version because resolvable symbols differ between releases. These NEVER affect the Compatibility badge — a phpcs finding can't make a module incompatible.
Static analysis
Coding standards (phpcs), mess detection (phpmd), copy-pasted code (cpd), PHP cross-version compatibility, composer.json validity. Each runs once for the whole module.
PHPStan
Type-checks the module's PHP against a real Magento install at the configured gate level. Re-runs per Magento and PHP version because resolvable symbols differ between releases. Cell → details modal.
Tests
Unit and integration suites, run for each applicable Magento and PHP version. A test failure speaks to the module's behaviour, not its compatibility with a Magento line, so it is reported here separately and never reddens the compatibility matrix.
Unit tests
| Magento | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|
| 2.4.7 | N/A | N/A | ||
| 2.4.8 | N/A | N/A | ||
| 2.4.9 | N/A | N/A |
Security
Security checks run directly against the module: an audit of its declared dependencies for known vulnerabilities (composer audit) and a scan of its source for malware and web-shell signatures. Each runs once. A malware detection fails the version outright.
Turn an existing module into recurring revenue.
If you already maintain a Magento 2 module on GitHub or GitLab, listing it on Packagento takes about five minutes. We mirror your tags, handle distribution signing, and route paid licenses through Stripe Connect, so you can keep shipping the way you already do.