Also note: this is what happens when you fall down the rabbit-hole of the complexities of rigging and weight-mapping in Blender, and balancing a new job plus freelance work.

There's also a caveat that I want the update server itself to be independent of my own website, so if manga-press.com ever goes down, the plugin updates are still available.

Of course, that could get derailed if I decide to commit maintaining my own update server instead of relying on WP(dot)org.

So we'll see. I may leave Comic Bookmarking on the table for a later release, and focus on JSON-LD instead.

It's another feature that I'm currently rethinking. While it might be a good idea for usability, what's the best approach?

Feature: Comic Bookmarking. This one is a tough one and is running neck-to-neck in terms of development difficulty with JSON-LD integration. Tl'dr, this feature is basically going to use LocalStorage for readers to bookmark their place for later.

Feature: Social Media integration. This isn't anything special. Just adds OG tags to the header of the comic. This also defaults to "Off" if users are utilizing another plugin for this feature.

Feature: Lightbox integration. Just adds a very simple lightbox script that should allow users to view a comic in a lightbox if they choose. This should also be integrated into the gallery template option for the archive page (oops, oversight on my part). Defaults to "Off"

QoL improvement: indicators on the Page screen to indicate which pages are assigned to be the Latest Comic and Comic Archive page, similar to how WordPress marks which page is used as the static Home Page.

Another part of 3.2 is bringing in features that were part of the original 4.1 release that turned out to be such a headache that I ended up pulling and replacing with the more stable 3.0. What were those features?

One thing that's going to set Manga+Press 3.2 apart from previous versions is I'm adding PSR-4 autoloading. The change wasn't without some headaches, since for some weird reason, the Calendar Widget wouldn't load without throwing errors.

What I mean by "feature flag" is some kind of conditional that a user can toggle on or off so that they can decide for themselves whether or not they want the fancy bells and whistles.

Ugh, data-modeling is hard. It's even harder when you're trying NOT to disrupt the workflow of existing users. Which on that note, maybe I hide these goodies behind a feature flag?

ComicStory would just be that page's description, plus—this isn't shown in the wireframe—but a new post type called "ComicCoverArt" would have to be added and would have a 1:n relationship with the Issue meta field?

Or perhaps I add a new data-point called "Issue." This wouldn't be a new custom taxonomy, but a meta field—which means that the field won't be autopopulated. In a weird way, that means that it would probably act more like a taxonomy but it has to be numbered because that's what JSON-LD is expecting.

My main problem is mapping the existing data, like the Series taxonomy, to the JSON-LD schema. It got me to thinking that maybe "Series" was a misnomer—maybe "Chapter" would have worked better instead? Unfortunately, it's too late to change it without breaking current installations.

Here's a wireframe of how the edit screen updates would look. The "creator" fields would match the additional fields in the schema and what I'm seeing is basically a repeater field that allows authors to add what they need.

To get an idea of what I'm talking about, visit this link: schema.org/ComicSeries