Archive for the ‘planning’ Category

MP-WP Roadmap Proposal

Saturday, March 7th, 2020

Now that I finally have a moment to breathe1, and will soon have an open schedule to dedicate towards republican work2, I figured this would be the right time to describe what I hope to accomplish in the coming months so that others can provide feedback, lest my outline not reflect what would actually be useful3.

The roadmap, in rough priority order:

  1. Finalize patch viewer plugin based on feedback
    Estimate: a few hours
  2. Add server-side selection code to base themes (if investigation to include this higher up the stack doesn't yield anything)
    Estimate: ~1 day
  3. Finish writing tests for the test suite
    Estimate: ~1 week
  4. Bulk image upload
    Estimate: ~1 week
  5. Code chopping (not in priority order)
    Estimate: variable/unknown
    1. Most (all?) of the dashboard "widgets"4
    2. Superfluous icons (all of them?)
    3. The theme editor found at /wp-admin/theme-editor.php5
    4. The plugin editor found at /wp-admin/plugin-editor.php6
    5. Import/export features7
    6. Useless "settings" and associated features
    7. All javascript8
  6. A republican theme, to replace one or both of the existing included themes
    Estimate: a few weeks, depending on revisions

Finalizing the patch viewer comes first since it's very close to being releasable as is9. Next is simply bringing the already-implemented server-side selection code into the main mp-wp vtree. This will likely need to be handled by adding the code to the bundled themes if indeed there's no easy way to include the feature further upstream.

Next we get to the medium-sized items, the first of which is completing the test suite to provide some assurance that subsequent larger changes don't break any existing functionality. As it stands the test suite covers posting and editing articles, as well as uploading and inserting images. Compared to the spec, this put coverage at about a third complete. The bulk image uploader should also be a quick win so I added that above code chopping.

That leaves the larger (and likely ongoing) trimming project, as well as a proper republican theme. The first slimming patch was one of the most satisfying pieces of work I've completed in recent memory and I'd very much like to experience that high again. I expect designing a republican theme to also be a pleasant and satisfying project, almost to the point that I see it more as a reward to be earned for completing the items before it. Plus everyone is already running their own (and to varying degrees, customized) themes, so I saw this as the least pressing item on the list.

There are other items that have been mentioned that I have not included here10—and the list of existing features due for the chopping block is not exhaustive—but altogether this feels like a good place to start.


  1. In 2019 it was the saltmines that were crushing me, these past two months it's been the escape process. []
  2. As was the plan. []
  3. In addition to publishing this for feedback, I'm also publishing it in the hope that it will inspire some designers and/or frontend-focused engineers who have been lurking to see this as a project they can get excited about and contribute to. This is a chance to work on the blogging platform of the republic and therefore the world. And all this without the trannyCoC bs or having to wade through god knows what kind of crap has been tacked onto turdpress since mp-wp forked from 2.7. So if you're interested I do hope you'll introduce yourself. []
  4. I find the 'Right Now' and 'Recent Comments' boxes to be somewhat useful for at-a-glance comment moderation purposes. []
  5. Use yer own damn editor. []
  6. Ditto here. []
  7. The existing mysqldump/mysqlimport commands should work fine for this. []
  8. Perhaps in stages, until completely gone. []
  9. I believe the only outstanding decision to be made is regarding the open/close tags. It's been about a month since the draft patch was published so I think at this point anyone who wanted to weigh in already has. I find myself agreeing with spyked's last comment suggesting that perhaps it be left as a constant in the file so that the operator can easily configure it to what best suits their blog and workflow. This leaves only the decision of what to choose as the default value for this const in the published patch, and for that I sort of like mp's suggested [1[ ... ]], where 1 is an index value mapping to a supported syntax (so for the inaugural patch, 1 == 'unix diff' since it will initially be the only supported syntax). []
  10. Such as redoing themes entirely. []