Blog | guides and magazine in your shop linked to products
Description
Highlights
- One system instead of two: blog and shop share login, theme and domain
- 13 blog elements in Shopping Experiences, you build the pages yourself
- Guides show up on the product page, no template work required
- Read in your WordPress export and keep posts, comments and authors
- Switchable per sales channel: visible in B2C, silent in your trade shop
Features
- Posts with cover image, gallery, short description, teaser, author, category and tags
- Publication window: posts appear and disappear on the date you set, on their own
- 13 Shopping Experiences elements, from the post list and slider to the comment column
- Two ready-made layouts after installation: one for posts, one for overview pages
- Posts for this product as a list, a slider or a single teaser in the product layout
- Author profiles with photo, short bio, social links and their own profile page
- Comments with approval, replies up to the depth you set, captcha and a spam brake
- SEO URLs from your own template, sitemap entries, JSON-LD and OpenGraph tags
- Blog posts appear in the shop search and in the suggestions under the search box
- RSS feed at /blog/feed.xml, switched off with one setting
- WordPress import from the WXR export file, including authors and comments
- Blog address is yours to choose, for example /magazine instead of /blog
- Store API for posts, post detail, categories, tags and comments
- Posts can be limited to single sales channels and to customer groups
- German, English and Dutch in the administration and in the storefront
About the Extension
Your shop runs on Shopware. Your blog runs on WordPress. Two logins, two themes, two update cycles. And when you want to recommend a product inside a guide, you copy the address across by hand.
The problem
A second system eats time that sells nothing. Patching it, watching for security holes, rebuilding the theme so the blog at least resembles the shop. Your articles sit on a subdomain or in a folder that has nothing to do with your shop. And the best guide in the world earns little if the reader has to go hunting for the matching product afterwards.
The solution
This plugin puts the blog where your shop already is. You write posts, categories, tags, authors and comments in the Shopware administration under Content, Blog. You build the pages in Shopping Experiences, with the same tools you use for every other page. Products get attached to the post, and the same post can appear on the product page.
What's in it for you
One system fewer to look after. One login, one theme, one database, one backup. The blog gets its updates together with the shop, and your posts look like the rest of your shop without anyone styling them.
You build the blog pages yourself. Thirteen elements wait in Shopping Experiences: post list, post slider, single post, categories, navigation, post header, post content, post gallery, author box, comments, related posts, linked products and posts for this product. Two finished layouts are there right after installation, one for posts and one for overview pages. Start writing today, rearrange later.
Your guide lands on the product page. Link posts to products, drop the "Blog: Posts for this product" element into your product layout, done. As a list, as a slider or as one large teaser. Someone reading the care instructions sees the care kit. Someone looking at the care kit finds the instructions.
Your content works for your own domain. Readable addresses from your own template, sitemap entries, JSON-LD for the post and the page path, OpenGraph tags for social networks, meta title and meta description per post and per language. Posts also turn up in the shop search and in the suggestions under the search box.
Comments without the data protection headache. A commenter's email address is stored as a hash only, never in plain text. Consent is recorded with a timestamp. Approve by hand or automatically, allow replies up to the depth you choose, use the captcha from your shop settings and set a minimum gap between comments to blunt spam waves. Comments are switched off after installation, so the decision stays yours.
Separate per sales channel. Every setting hangs off the channel, including the master switch. The magazine runs in your consumer shop and stays quiet in your trade channel. Individual posts can also be limited to certain channels and to customer groups.
How the plugin works
Posts live in their own tables and behave like any other Shopware content: multilingual, with their own permissions, in the context of the sales channel. Slug, reading time and view counter are filled in by the plugin, per language. The blog sits under /blog by default, and you can move it, for example to /magazine. If another page claims the same address, the blog overview in the administration tells you. Overview, category, tag, author and detail pages come with it, plus an RSS feed and the Store API for your own front ends. The page cache uses its own cache tags per sales channel: change a post, an image, an assignment or a category and exactly that goes stale, not half the shop.
Typical use cases
Moving over from WordPress. You upload the WXR export file in the administration. Posts, categories, tags, authors and comments come along. A second import updates the posts already taken over instead of duplicating them.
A retailer whose products need explaining. A garden tool dealer writes maintenance guides and attaches chain oil, a sharpening kit and spare blades to the post. Every one of those product pages then carries the matching guide, and nobody has to touch a template.
A magazine for consumers only. Your B2C channel gets recipes and how-to articles, your trade channel stays plain. One switch per channel, one installation, different visibility.
Posts with an end date. An advent calendar post starts on 1 December and disappears on 25 December. You set two dates and forget about it.
Technical facts for your IT team
Shopware 6.7, PHP 8.2 and above. The plugin creates 19 tables of its own prefixed swp_blog_six and changes no Shopware table. It sends no data to external servers, everything stays in your database. Personal data: comment addresses as an HMAC SHA-256 hash only, consent with a timestamp, views counted per day, post and channel with no visitor identifier. The minimum gap between comments works on a hashed IP address in the cache; the address itself is never stored. Permissions come as the Blog group under Permissions, Content, with viewer, editor, creator and deleter roles. The HTTP cache gets its own tags per sales channel, the lifetime is yours to set and 0 turns it off. Uninstalling without "keep user data" removes all blog tables, the plugin configuration and the layouts that shipped with it.
To be honest
The plugin sends no email at all. A new comment produces no notification; you look at the comment list, or you switch on automatic approval. There are no editorial workflows with several approval stages, no draft revisions and no scheduling board for a team: a post is active or it is not, and it has a publication window. If you run a newsroom with review loops, a dedicated editorial system serves you better. For everyone else, the blog inside the shop is the shorter route. Give it a try.
Legal notice
We accept no liability for legal requirements. Please check the use of this plugin with a qualified legal advisor.
Your shop runs on Shopware. Your blog runs on WordPress. Two logins, two themes, two update cycles. And when you want to recommend a product inside a guide, you copy the address across by hand.
The problem
A second system eats time that sells nothing. Patching it, watching for security holes, rebuilding the theme so the blog at least resembles the shop. Your articles sit on a subdomain or in a folder that has nothing to do with your shop. And the best guide in the world earns little if the reader has to go hunting for the matching product afterwards.
The solution
This plugin puts the blog where your shop already is. You write posts, categories, tags, authors and comments in the Shopware administration under Content, Blog. You build the pages in Shopping Experiences, with the same tools you use for every other page. Products get attached to the post, and the same post can appear on the product page.
What's in it for you
One system fewer to look after. One login, one theme, one database, one backup. The blog gets its updates together with the shop, and your posts look like the rest of your shop without anyone styling them.
You build the blog pages yourself. Thirteen elements wait in Shopping Experiences: post list, post slider, single post, categories, navigation, post header, post content, post gallery, author box, comments, related posts, linked products and posts for this product. Two finished layouts are there right after installation, one for posts and one for overview pages. Start writing today, rearrange later.
Your guide lands on the product page. Link posts to products, drop the "Blog: Posts for this product" element into your product layout, done. As a list, as a slider or as one large teaser. Someone reading the care instructions sees the care kit. Someone looking at the care kit finds the instructions.
Your content works for your own domain. Readable addresses from your own template, sitemap entries, JSON-LD for the post and the page path, OpenGraph tags for social networks, meta title and meta description per post and per language. Posts also turn up in the shop search and in the suggestions under the search box.
Comments without the data protection headache. A commenter's email address is stored as a hash only, never in plain text. Consent is recorded with a timestamp. Approve by hand or automatically, allow replies up to the depth you choose, use the captcha from your shop settings and set a minimum gap between comments to blunt spam waves. Comments are switched off after installation, so the decision stays yours.
Separate per sales channel. Every setting hangs off the channel, including the master switch. The magazine runs in your consumer shop and stays quiet in your trade channel. Individual posts can also be limited to certain channels and to customer groups.
How the plugin works
Posts live in their own tables and behave like any other Shopware content: multilingual, with their own permissions, in the context of the sales channel. Slug, reading time and view counter are filled in by the plugin, per language. The blog sits under /blog by default, and you can move it, for example to /magazine. If another page claims the same address, the blog overview in the administration tells you. Overview, category, tag, author and detail pages come with it, plus an RSS feed and the Store API for your own front ends. The page cache uses its own cache tags per sales channel: change a post, an image, an assignment or a category and exactly that goes stale, not half the shop.
Typical use cases
Moving over from WordPress. You upload the WXR export file in the administration. Posts, categories, tags, authors and comments come along. A second import updates the posts already taken over instead of duplicating them.
A retailer whose products need explaining. A garden tool dealer writes maintenance guides and attaches chain oil, a sharpening kit and spare blades to the post. Every one of those product pages then carries the matching guide, and nobody has to touch a template.
A magazine for consumers only. Your B2C channel gets recipes and how-to articles, your trade channel stays plain. One switch per channel, one installation, different visibility.
Posts with an end date. An advent calendar post starts on 1 December and disappears on 25 December. You set two dates and forget about it.
Technical facts for your IT team
Shopware 6.7, PHP 8.2 and above. The plugin creates 19 tables of its own prefixed swp_blog_six and changes no Shopware table. It sends no data to external servers, everything stays in your database. Personal data: comment addresses as an HMAC SHA-256 hash only, consent with a timestamp, views counted per day, post and channel with no visitor identifier. The minimum gap between comments works on a hashed IP address in the cache; the address itself is never stored. Permissions come as the Blog group under Permissions, Content, with viewer, editor, creator and deleter roles. The HTTP cache gets its own tags per sales channel, the lifetime is yours to set and 0 turns it off. Uninstalling without "keep user data" removes all blog tables, the plugin configuration and the layouts that shipped with it.
To be honest
The plugin sends no email at all. A new comment produces no notification; you look at the comment list, or you switch on automatic approval. There are no editorial workflows with several approval stages, no draft revisions and no scheduling board for a team: a post is active or it is not, and it has a publication window. If you run a newsroom with review loops, a dedicated editorial system serves you better. For everyone else, the blog inside the shop is the shorter route. Give it a try.
Legal notice
We accept no liability for legal requirements. Please check the use of this plugin with a qualified legal advisor.
Details
- Available: English, German
- Latest update: 1 October 2026
- Publication date: 5 October 2026
- Version: 6.7.1
- Category: Blog
Resources
Reviews (0)
About the Extension Partner
BuI Hinsche GmbH
Partner Status
-
Shopware
Bronze Partner -
Shopware
Premium Extension Partner
Details
-
Ø-Rating:
4.3
Average rating of 4.3 out of 5 stars
- Partner since: 2014
- Extensions: 97
- Certifications: 2
Support
- Based in: Germany
- Speaks: German, English
- Response time: Very quickly
6.7.1 6.7.11.0 - 6.7.15.0
- Switching the content language on a post, category, tag or author no longer discards unsaved changes: the shop asks whether to save them first, and the page loads the new language exactly once
- Opening a post, category, tag or author keeps the selected content language; only new entries start in the default language
- After saving, the detail page shows the saved state straight away
- Empty lists for posts, categories, tags, authors and comments show their hint centred, as in Shopware's own lists
- The WordPress import page shows "Counting posts …" while the export is being counted instead of "0 / 0"
- Error messages of the plugin now reach the shop log; search terms entered by visitors are not logged
- The settings "SEO URL template for posts" and "SEO URL template for categories" now take effect per sales channel; after saving, the addresses are rebuilt in the background via the message queue. An unusable template is discarded and logged as an error. Templates maintained under Settings › SEO with a sales channel selected survive updates and are only replaced by a changed plugin template or blog address
- Changing the blog address no longer rebuilds all SEO URLs inside the admin request, so saving stays fast with thousands of posts
- Sitemap entries of posts and categories use the readable address and are valid URLs
- Shared posts show their own image, type and title on social networks: the plugin replaces the shop's OpenGraph and Twitter tags instead of adding a second set
- The blog overview, category, tag and author pages output the canonical link and "og:url" with the address of the current sales channel and language, including the page number from page 2 onwards
- Canonical and feed links use the domain the page was called on, also in sales channels with several language domains
- Posts restricted to customer groups are only filtered while the restriction is switched on in the settings, and the page cache is then separated per customer group — restricted content is no longer served to other customer groups from the cache
- Changed or deleted comments, authors and sales channel assignments of categories and tags refresh the affected pages, including blog elements on start and product pages
- WordPress import: posts already imported are recognised by their WordPress origin instead of their address — posts created by hand with the same address are no longer overwritten, the imported post gets a unique address; running the same import again duplicates neither posts nor comments; a database error ends the job as failed and deletes the uploaded export; a cancelled job stays cancelled; large exports are read in bands from the last position; counting runs in the queue instead of the upload request
- View counting no longer writes to the visitor's browser storage; repeated views are recognised on the server within 30 minutes by a pseudonymised hash of the IP address
- The comment form always shows a privacy notice, with a link to the privacy page if the shop has one configured
- Roles without edit permission see the detail pages of posts, categories, tags and authors read-only; switching the content language no longer offers to save
- Roles with read permission open posts, categories, tags, authors and comments from their list via "View" instead of finding a greyed-out "Edit" entry
- Under Settings › SEO, the blog rows show readable labels (Blog post, Blog category, Blog author) instead of technical keys
- The row menu of the comment list offers "Edit" and "Delete" alongside "Approve" and "Reject"
- The completion message of the WordPress import states the number of posts actually taken over, and the Shopping Experiences element "Blog: Single post" shows the title of the selected post in the designer
- Sales channels that are created, activated later or given a new domain receive the blog's SEO URL templates automatically in the background; their blog addresses follow the configured blog address instead of "/blog"
- Re-importing a WordPress export no longer changes the visibility of posts already taken over and no longer recreates posts and comments deleted in the shop; this does not cover content from an import made with 6.7.0 that was deleted before the first repeated import with 6.7.1
- Deleting a customer account anonymises the name on its blog comments even if the deleting admin role has no permissions on comments
- Scheduled publications also refresh the blog pages of a newly created sales channel without restarting the background processes
- When many posts, categories or tags with the same title are imported in parallel via the sync API, every record receives a unique address; the API no longer reports an error, and entries already saved without an address receive one automatically the next time a text field is saved
- Authors saved without a URL slug receive one derived from their name, as described in the administration
- Posts with view statistics can be deleted and the statistics can be read through the Admin API; the statistics table gets its own key, existing counts are kept
- Copying an image through the Admin API no longer copies its blog gallery entries
- Uninstalling without keeping user data no longer re-creates the blog's SEO URL templates or leaves messages in the queue that made the queue worker fail once the plugin had been removed
- Uninstalling without keeping user data also removes the SEO URLs of blog posts, categories, authors and the blog overview, in batches for large blogs
- During an update from 6.7.0, blog pages, saving posts, categories, tags and authors, and the sitemap keep working; a running WordPress import pauses until the background processes run the new version and does not restore deleted content
- The hourly roll-up of view counts and the check of publication windows are scheduled again after a failed run instead of stopping for good
- Error messages in the administration name the failed action and, where input is rejected, the affected fields instead of the server's technical text; the WordPress import names the reason for a rejected upload or a failed job in the administration language
- Errors are no longer swallowed silently but logged with context in the plugin log; database errors in the blog search, when deleting customers and when deleting imported blog entries now surface and roll the change back instead of leaving a half-finished state
- Uninstalling without keeping user data first removes the uploaded WordPress exports and stops with a message if that is not possible, instead of reporting success and leaving the files behind
- Background jobs (WordPress import, rebuilding SEO URLs) carry the context of the admin request that started them
- Saving a sales channel no longer fails on Shopware 6.7.11 to 6.7.13
- Compatibility: Shopware Store analysis notices about deprecated interfaces resolved
6.7.0 6.7.11.0 - 6.7.15.0
- Initial release: full-featured blog system for Shopware 6.7
- Entities for posts, categories, tags, authors and comments including translations (DE / EN / NL)
- Admin module Content → Blog with dashboard and list/detail pages for posts, categories, tags and comments
- ACL role set swp_blog_six (viewer / editor / creator / deleter) under Permissions → Content, listed as "Blog" in the role editor
- Posts with cover media, author, category, tags, teaser, short description, meta data, featured flag, publication window and sales channel assignment
- Translatable short description per post, shown in listing cards, in the single-post element and as meta-description fallback
- Image galleries for posts and categories: any number of images per entry, maintained on the detail page as a thumbnail grid — upload straight into it or pick from the media manager, reorder by dragging, remove from the tile
- Author picture with upload and preview on the author page
- Publication window with start and end date; expired posts disappear on their own
- Assignment to several sales channels or to all of them
- Automatic, per-language unique slugs derived from title or name; the field explains itself and keeps a slug entered by hand unchanged
- A new post is prefilled with the current time as its publication date and is assigned to all sales channels, so it appears at the top of the blog right after saving
- Every field the plugin fills in on its own — slug, reading time, meta title, meta description, publication date — says so in its help text
- Automatic reading time per language and view counter
- Storefront pages: listing /blog, category /blog/category/{slug}, tag /blog/tag/{slug}, author and detail /blog/{slug}, plus sidebar; every overview lists only its own posts and can be paged through
- Author page with a profile head: picture, name, job title, short profile and social links
- Category and author pages carry their own page title and meta description from the entity instead of the shop default
- The setting "Posts per page" applies to every overview; a page number beyond the last page answers with 404, and unusable values (?p=abc, ?p=0, ?p=-1) show the first page
- Storefront behaviour as Twig components (Shopware 6.7.11 component system) for comment form, reply link, reading progress, sharing and view counting — automatic initialisation, and extension through the event system instead of overrides
- 13 CMS blocks and elements for Shopping Experiences — Blog listing, Post slider, Single post, Posts for this product, Post gallery, Post header, Post content, Author box, Linked products, Related posts, Comments, Navigation and Categories — each with configuration and preview in the administration
- "Blog: Single post" with five post sources: fixed post, latest, random, most-read of the last 30 days or latest featured post; category scope selectable (all categories, the current category of the page or a fixed one), an empty result falls back to the newest post
- "Blog: Posts for this product" in three display modes: list, slider or single post, selectable per layout
- Blog listing, post slider and "Blog: Single post" can be limited to the posts assigned to the current product on product page layouts, with an optional fallback to all posts when nothing is assigned
- Blog listing with configurable column count (2, 3 or 4 from tablet width up); post slider with configurable autoplay and dot navigation
- The layout designer shows on the element which post or selection rule will be rendered
- SEO URLs for posts and categories with configurable templates, plus sitemap entries
- Renaming a post keeps its old address alive: the previous URL answers with a permanent redirect (301) to the new one instead of a 404, so existing links, bookmarks and search results keep working
- RSS feed at /blog/feed.xml, can be switched off in the configuration
- Blog hits in the shop search and in the suggest box, switchable per sales channel; ranked over a fulltext index and searched along the language chain, so a post written only in the shop's default language is found in every language it is displayed in
- Comment system with moderation: master switch, auto-approve, honeypot field, minimum distance per sender and GDPR consent
- Comment e-mail addresses are stored as a hash only; consent and its timestamp are recorded
- WordPress import for posts, categories, tags and authors from a WXR export file; files that are not a WordPress export are rejected instead of reported as an import of zero posts
- Admin API for approving and rejecting comments and for blog statistics
- Store API for posts, post detail, categories, tags, galleries, comment list and comment submission
- Events for submitted, approved and rejected comments and for viewed posts
- HTTP cache with per sales channel cache tags and a channel specific lifetime, invalidated precisely when posts, galleries, tag, sales channel or product assignments and customer group visibility change
- A failure in the blog part takes down neither the shop's product search nor cacheable storefront pages such as the home, category and product pages
- Administration built on the Shopware design tokens (dark-mode safe), with explanatory empty states in the lists; a help text opens where its icon is and leaves the page where it is
- Uninstalling drops all blog tables and the plugin configuration only when "keep user data" is not selected