Updating the Data Viz WordPress Blocks
This guide explains how to update the data-viz-wordpress blocks and use different Docker images (test, build, or production) from the WordPress repository when releasing.
Overview​
The data-viz-wordpress blocks are provided through Docker images from the data-viz-wordpress repository. When releasing updates, you can use different image tags depending on your needs:
- Snapshot images: For testing release candidates (format:
v<version>-snapshot-<YYYYMMDD>.<build-number>) - Production images: For stable releases (version tags or
latest)
Prerequisites​
- Access to the Docker registry (
registry.developmentgateway.org) - Understanding of Docker image tags and versions
- Access to the
data-viz-wordpressrepository
Understanding WordPress Image Tags​
The WordPress Docker images are published with different tags based on the release type:
Production Images​
registry.developmentgateway.org/data-viz/wordpress:latest- Latest stable releaseregistry.developmentgateway.org/data-viz/wordpress:v1.0.1- Specific version tag
Pre-release/Test Images (Snapshots)​
registry.developmentgateway.org/data-viz/wordpress:v0.0.11-snapshot-20251010.0- Snapshot tags for release candidates- Format:
v<version>-snapshot-<YYYYMMDD>.<build-number>v0.0.11- Version numbersnapshot- Indicates this is a snapshot/RC build20251010- Date in YYYYMMDD format0- Build number for that day (increments for multiple builds on the same day)
- Example:
v0.0.11-snapshot-20251010.0,v0.0.11-snapshot-20251010.1,v0.0.11-snapshot-20251011.0
Updating WordPress Blocks​
Method 1: Using Production Images (Recommended for Stable Releases)​
When a new stable version of the WordPress blocks is released:
- Check available versions:
# List available tags (requires Docker registry access)
docker pull registry.developmentgateway.org/data-viz/wordpress:latest
# Or check the data-viz-wordpress repository releases
- Update docker-compose.yml:
wordpress:
image: registry.developmentgateway.org/data-viz/wordpress:latest
# Or use a specific version:
# image: registry.developmentgateway.org/data-viz/wordpress:v1.0.1
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: mysql
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
- wordpress:/var/www/html
- ./custom/wp-customizer:/var/www/html/wp-content/plugins/wp-customizer-blocks
networks:
- backend
- frontend
- Pull and restart the service:
docker-compose pull wordpress
docker-compose up -d wordpress
Method 2: Using Test/Build Images (For Testing Releases)​
When testing release candidates or pre-release builds:
-
Identify the snapshot image tag:
- Check the
data-viz-wordpressrepository for snapshot tags - Snapshot tags follow the format:
v<version>-snapshot-<YYYYMMDD>.<build-number> - Example:
v0.0.11-snapshot-20251010.0(version 0.0.11, snapshot from October 10, 2025, build 0)
- Check the
-
Update docker-compose.yml with snapshot image:
wordpress:
# Use snapshot tag for testing
image: registry.developmentgateway.org/data-viz/wordpress:v0.0.11-snapshot-20251010.0
# Format: v<version>-snapshot-<YYYYMMDD>.<build-number>
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: mysql
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
- wordpress:/var/www/html
- ./custom/wp-customizer:/var/www/html/wp-content/plugins/wp-customizer-blocks
networks:
- backend
- frontend
- Pull and test the image:
docker-compose pull wordpress
docker-compose up -d wordpress
-
Verify the blocks are updated:
- Access WordPress admin at
http://localhost:8080/wp - Check that the blocks appear correctly in the block editor
- Test block functionality
- Access WordPress admin at
-
Switch back to production image when ready:
wordpress:
image: registry.developmentgateway.org/data-viz/wordpress:latest
Release Workflow​
Testing with Snapshot Tags​
When a new snapshot (release candidate) is available:
- Create or update a feature branch:
git checkout -b feature/update-wordpress-blocks
- Update docker-compose.yml with the snapshot image tag:
wordpress:
image: registry.developmentgateway.org/data-viz/wordpress:v0.0.11-snapshot-20251010.0
The snapshot tag format is: v<version>-snapshot-<YYYYMMDD>.<build-number>
v0.0.11- The version numbersnapshot- Indicates this is a snapshot/RC build20251010- Date in YYYYMMDD format (October 10, 2025)0- Build number for that day
- Test the snapshot version:
docker-compose pull wordpress
docker-compose up -d wordpress
# Test WordPress blocks functionality
- Create an RC tag on your feature branch:
git add docker-compose.yml
git commit -m "chore: update WordPress blocks to v0.0.11-snapshot-20251010.0"
git tag -a 1.0.1-rc1 -m "Test WordPress blocks snapshot 20251010.0"
git push origin feature/update-wordpress-blocks
git push origin 1.0.1-rc1
-
Deploy and verify:
- The Jenkins pipeline will deploy using the snapshot image
- Verify blocks work correctly in the testing environment
- If issues are found, you can test a newer snapshot (e.g.,
v0.0.11-snapshot-20251010.1orv0.0.11-snapshot-20251011.0)
Production Release​
When the snapshot is approved and a stable release is available:
- Update docker-compose.yml with the production version:
wordpress:
image: registry.developmentgateway.org/data-viz/wordpress:v1.0.1
# Or use latest for the most recent stable release
# image: registry.developmentgateway.org/data-viz/wordpress:latest
- Merge to main:
git checkout main
git pull origin main
git merge feature/update-wordpress-blocks
git push origin main
- Create a production tag (optional):
git tag -a 1.0.1 -m "Release WordPress blocks v1.0.1"
git push origin 1.0.1
Using Environment Variables for Image Selection​
You can use environment variables to make image selection more flexible:
- Set environment variables:
# For testing with snapshot
export WORDPRESS_IMAGE_TAG=v0.0.11-snapshot-20251010.0
# For production
export WORDPRESS_IMAGE_TAG=latest
- Update docker-compose.yml:
wordpress:
image: registry.developmentgateway.org/data-viz/wordpress:${WORDPRESS_IMAGE_TAG:-latest}
# The :-latest provides a default value if the variable is not set
ports:
- "8080:80"
environment:
WORDPRESS_DB_HOST: mysql
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
- wordpress:/var/www/html
- ./custom/wp-customizer:/var/www/html/wp-content/plugins/wp-customizer-blocks
networks:
- backend
- frontend
- Use in deployment:
# For testing with snapshot
WORDPRESS_IMAGE_TAG=v0.0.11-snapshot-20251010.0 docker-compose up -d wordpress
# For production
WORDPRESS_IMAGE_TAG=latest docker-compose up -d wordpress
Updating Custom Blocks​
If you have custom blocks in custom/wp-customizer/blocks, they will continue to work alongside the updated WordPress blocks:
- Custom blocks are mounted as volumes:
volumes:
- ./custom/wp-customizer:/var/www/html/wp-content/plugins/wp-customizer-blocks
- Rebuild custom blocks if needed:
cd custom/wp-customizer/blocks
pnpm install
pnpm run build
- Restart WordPress:
docker-compose restart wordpress
Verifying Updates​
After updating the WordPress image, verify the update:
- Check WordPress version:
docker exec <wordpress-container> wp core version
- Check installed plugins:
docker exec <wordpress-container> wp plugin list
-
Verify blocks in editor:
- Access WordPress admin
- Create or edit a post/page
- Check that data-viz blocks are available in the block inserter
- Test block functionality
-
Check browser console:
- Open browser developer tools
- Check for any JavaScript errors related to blocks
- Verify block assets are loading correctly
Troubleshooting​
Image Not Found​
If you get an error that the image cannot be found:
# Verify you're logged into the registry
docker login registry.developmentgateway.org
# Check if the tag exists
docker pull registry.developmentgateway.org/data-viz/wordpress:<tag>
Blocks Not Appearing​
If blocks don't appear after updating:
- Clear WordPress cache:
docker exec <wordpress-container> wp cache flush
-
Regenerate block registry:
- Go to WordPress admin → Plugins
- Deactivate and reactivate plugins if needed
- Clear browser cache
-
Check block registration:
docker exec <wordpress-container> wp block list
Version Conflicts​
If you encounter version conflicts:
- Check current image version:
docker inspect registry.developmentgateway.org/data-viz/wordpress:latest | grep -i version
-
Verify compatibility:
- Check the
data-viz-wordpressrepository for compatibility notes - Review release notes for breaking changes
- Check the
-
Rollback if needed:
wordpress:
image: registry.developmentgateway.org/data-viz/wordpress:v1.0.0
# Use previous stable version
Best Practices​
- Always test snapshot images before using production images
- Use snapshot tags for testing release candidates (format:
v<version>-snapshot-<YYYYMMDD>.<build-number>) - Check for newer snapshots if testing reveals issues - multiple builds may be created on the same day (incrementing build number) or on different days
- Use specific version tags in production instead of
latestfor better reproducibility - Document version changes in commit messages and release notes
- Test custom blocks after WordPress block updates
- Monitor WordPress logs after updates for any errors:
docker-compose logs wordpress
- Keep custom blocks updated to ensure compatibility with new WordPress block versions
- Review release notes from the
data-viz-wordpressrepository before updating
Related Documentation​
- Creating Custom Blocks - Learn how to create custom WordPress blocks
- Deploying the Customizer - Learn how to deploy WordPress customizer
- Configuring WordPress - WordPress configuration guide
- @devgateway/dvz-wp-commons - Common utilities for Data Visualization in WordPress that can also be used in other projects.
- @devgateway/dvz-wp-commons API - Type definitions for the @devgateway/dvz-wp-commons package.