WordPress.com is removing the markdown settings. Should we follow suit? I am all for removing these settings if there are no major objections.
To clarify, we would enable markdown on both posts and comments and simply remove the settings for them.
CC @rickybanister @jeffgolenski @georgestephanis @samhotchkiss
I'm good with that. I like when 'things just work'.
The justification I saw and that resonated with me is—if you know markdown, you'll simply try it and appreciate when it 'just works' and if you don't know what it is, seeing it as a setting will not really help you.
@rickybanister Jetpack is never that simple. There could be plugins that conflict or some edge-case I could never thin of. Can't hurt to ask first.
CC @jeherve @kraftbj
Are we going to keep an area where we at least present a link for folks to learn more about markdown? It's a handy tool that a lot of non-tech folks could benefit from, but don't know about. It's nice if it "just works" and you know what it is, but if you don't know, then you don't know.
@jeffgolenski nope, but it might be a fun Justine Timeâ„¢ message when using the editor.
I think it'd be fine to enable it by default, as long as one can deactivate the module and thus turn both options off from the full module list / advanced settings.
Deactivating the full module is useful when folks already use another Markdown plugin for example, or when they use a combination of shortcodes or specific markup that's not compatible with Jetpack's Markdown module.
@jeherve Well removing the options would mean there is no UI for disabling. :/
But we'll still have a full module list somewhere with the possibility to deactivate modules (like Markdown) and thus not loading them at all, I assume?
@jeherve that was the whole point of having the UI there in the first place. It's not really a problem for WordPress.com since we control what works on there, but JP is the Wild West.
So no, there is no full module list that most users can access, unless they qualify for the fallback because of old browsers or the like, or they install a plugin that gives them a full module list.
I assume wp-admin/admin.php?page=jetpack_modules will remain available, like in the current version of Jetpack. We had talked about adding a link to that full module list to the new interface. Was it decided to not add any link then?
I'm unsure, and would defer to @samhotchkiss on the result of that decision. I just know that the last I heard, most folks probably weren't going to have it -- but I could be mistaken.
I assume wp-admin/admin.php?page=jetpack_modules will remain available, like in the current version of Jetpack. We had talked about adding a link to that full module list to the new interface. Was it decided to not add any link then?
I don't think we're removing it in the next release or two.
I had started working up a modern version of it:

I hope we don't have to implement something like that
@rickybanister Why? What's your reasoning here?
For reference, here are a related issue where folks expressed the need for bulk capabilities and a full module list:
Because it's obtuse and confusing and edge-case. The reason we removed many module toggles was to simplify settings and make it so if you don't use a feature, you don't need to know what a 'module' is. To reference something @johnmaeda said the other day, Jetpack feels like the cockpit of a Cessna rather than a software service. I understand why we would implement something like the above, but it feels like an admission that we couldn't solve the problem in a more graceful way.
Depositing my $0.02:
Power users have different needs. Those who spin up dozens of Jetpack sites for their clients and know which features they need and which they don't benefit from bulk management. I have even received multiple requests from people at WordCamps about making it easier (possible) to clone feature setups from one Jetpack site to another.
That said, we do have filters that provide this functionality, which IMO is not too much to ask of a developer who is spinning up so many sites. In a way, I feel the filter is likely easier to implement than using bulk management.
I'm on board with the direction the UI is going, as long as it's a clear, open, and conscious decision that we are not providing any sort of UI for power users while offering _some_ way for them to accomplish the same thing (i.e. filters).
In the spirit of this Issue's goal -- I am a bit concerned about auto-activating (especially on upgrade from an older version), as it has the potential to modify the front-end content of their site without them knowing what/where it's coming from.
In the end I'm also okay with it as long as this has been considered.
In a way, I feel the filter is likely easier to implement than using bulk management.
@dereksmart that is comforting to hear. That was my suspicion as well.
After thinking about it for a bit, I think we should remove the Markdown settings. For those who disabled it, it will be off and, if needed, we can point them to the old-timey bulk management while it's still around.
PR: #9015
It's worth noting that only 3% of sites have this feature active currently, so we should not auto-activate it, especially for existing sites.
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.
I'm thinking in the near future we can remove the markdown option in favor of just letting it be a block. Or at least in 2021 when classic editor support is dropped.
Let's close this as duplicate of #10294, where we've been discussing potential solutions.
Most helpful comment
@jeherve that was the whole point of having the UI there in the first place. It's not really a problem for WordPress.com since we control what works on there, but JP is the Wild West.