Building AIOSEO’s release publishing system
Marty Helmick · Changelog developer · AIOSEO
I built the WordPress tools AIOSEO’s team used to write release notes and the archive customers used to read them. The same entry could be copied as HTML or Markdown, and I migrated the old releases into the new system.
Start with one release
A customer looking for a fix to an add-on shouldn’t have to read through every update to the main plugin. The editor already knew which product a release belonged to. I wanted that choice to carry through to the page the customer saw.
I created a release post type in PHP and made the product a required choice. A new release opened with three sections already in place: New, Updated, and Fixed. I built a Changes List block for each section. The author picked the kind of change and wrote the items in a list. The block handled the heading and markup.
Put the structure to work
The product choice determined where the entry appeared. I kept the main plugin at the existing changelog address and gave add-ons their own archive URLs. Individual release posts redirected to the relevant product archive. I built the navigation and responsive styles, then manually moved the legacy entries into the new format.
The release team also needed the text outside WordPress. I added Copy HTML and Copy Markdown to the editor. Someone preparing a release could write a note once, choose the format, and paste it into the next destination.
See it from the customer’s side
On the public changelog, switch from the main plugin to an add-on such as Redirects. The entries follow the same structure, but the list now answers a narrower question: what changed in this product?