The historical workflow
- Create an asides category. Short updates remained ordinary WordPress posts.
- Select the category. Plugin settings identified which content belonged in the sideblog.
- Choose a display count. The output showed a limited stream of recent items.
- Place the output. Publishers used a sidebar widget or a PHP function in the theme.
- Publish short posts. Adding a post to the category placed it in the compact stream.
Why the model was effective
It reused WordPress posts, dates, categories and publishing permissions instead of creating a separate data store. The weak point was presentation coupling: a plugin and theme integration became responsible for output that modern block themes can often assemble with core tools.
Modern translation
| Approach | Content model | Best for | Main tradeoff |
|---|---|---|---|
| Posts + dedicated category | Standard WordPress posts | Short updates that should remain in feeds and archives | Requires theme rules to keep short posts visually distinct |
| Category + Query Loop block | Core blocks and taxonomy | Block themes with no custom PHP requirement | Layout control varies by theme and site-editor experience |
| Custom post type | Separate structured content type | Updates needing their own fields, archive and permissions | Requires durable registration and a migration plan |
| Curated notes page | One maintained page or collection | Low-volume notes where simplicity matters most | Individual notes may lack stable URLs and feed entries |
Frequently asked questions
Did Sideblog store content outside WordPress posts?
The historical instructions describe creating normal posts in a selected asides category. That made the content conceptually portable even if the display plugin was retired.