search

WordPress / wordcamp.org

WordCamps are casual, locally-organized conferences covering everything related to WordPress.
https://wordcamp.org
130 stars 74 forks source link

Jetpack: Which modules should be activated by default for new WordCamp sites? #494

Closed coreymckrill closed 1 year ago

coreymckrill commented 4 years ago

I recently saw a report that the Sharing module was off on a new WordCamp site. That seems like one that should definitely be on for new sites. It made me wonder what the default states are for other modules.

In mu-plugins/jetpack-tweaks/new-sites.php we've got the default_jetpack_modules() function hooked to jetpack_get_default_modules, which modifies the set that Jetpack turns on by default. It looks like we're removing Widget Visibility from the defaults, and then adding the Contact Form, Shortcodes, Custom CSS, and Subscriptions.

Ideally, I think, we'd specify the state of every module (known at the time) so that we could be sure every site had a consistent set.

The modules, as of Jetpack 8.3, and the state they currently start in on WordCamp sites:

I would probably also enable these by default:

I'm also not sure why we turn off Widget Visibility. It seems useful for event sites, unless there's some kind of conflict with other functionality.

iandunn commented 4 years ago

My bad, I should have left a comment with the reason widget-visibility was disabled. I don't remember the reason, but performance was probably at least part of it. My instinct would be to disable everything by default, unless it meets one of these conditions:

That keeps the UI cleaner, and the site faster. Organizers can always manually enable any other modules that they'd like.

andreamiddleton commented 4 years ago

I would probably also enable these by default: Copy Post Publicize Sharing Sitemaps Tiled Galleries

I agree that these would be good to turn on by default. I'm also inclined to turn on:

WP.me Shortlinks Lazy Images Likes Comment Likes

Per @iandunn's thought about

disable everything by default, unless it meets one of these conditions: Used by WordCamp code (Remote CSS, Coming Soon, etc) Used by 80% of camps

Are we able to identify which modules are used most often, on the network?

coreymckrill commented 4 years ago

Lazy Images

I think this one actually breaks something for us. Which makes me think that there are some modules here that we should actually prevent from being activated as well.

Are we able to identify which modules are used most often, on the network?

We can write a script to get a count of how many sites have each module activated.

ryelle commented 4 years ago

Lazy Images

I think this one actually breaks something for us.

It did break the blocks, but that was fixed. I don't think it breaks anything else, unless you've seen something different?

coreymckrill commented 4 years ago

I don't think it breaks anything else, unless you've seen something different?

Nope, same thing. I just couldn't remember if it got fixed or we just turned off the module.

coreymckrill commented 4 years ago

I compiled module usage for all sites that successfully completed an event since the beginning of 2016. The year is somewhat arbitrary, but that's when we started modifying the default set of modules that start activated.

Updated to show the module name rather than the sometime-misleading slug.

Sites surveyed: 517

Protect: 517 (100 %)
Subscriptions: 517 (100 %)
Contact Form: 517 (100 %)
Extra Sidebar Widgets: 517 (100 %)
Shortcode Embeds: 517 (100 %)
Custom CSS: 517 (100 %)
Site Stats: 513 (99 %)
Notifications: 503 (97 %)
Site verification: 497 (96 %)
Sharing: 475 (91 %)
WP.me Shortlinks: 455 (88 %)
Custom content types: 445 (86 %)
Publicize: 434 (83 %)
Beautiful Math: 431 (83 %)
Post by email: 418 (80 %)
Gravatar Hovercards: 411 (79 %)
Enhanced Distribution: 313 (60 %)
JSON API: 294 (56 %)
Sitemaps: 281 (54 %)
Image CDN: 129 (24 %)
Tiled Galleries: 117 (22 %)
Carousel: 99 (19 %)
Likes: 87 (16 %)
Comments: 70 (13 %)
Widget Visibility: 55 (10 %)
Lazy Images: 47 (9 %)
Related posts: 44 (8 %)
Monitor: 41 (7 %)
Markdown: 32 (6 %)
Asset CDN: 32 (6 %)
Secure Sign On: 23 (4 %)
Comment Likes: 19 (3 %)
Infinite Scroll: 14 (2 %)
Copy Post: 3 (0 %)
WordPress.com Toolbar: 2 (0 %)
VideoPress: 1 (0 %)
coreymckrill commented 4 years ago

I actually don't think these numbers are particularly meaningful because A) some of the modules haven't been available for the entire time period, and B) I suspect Jetpack has changed what is on by default over the time period.

Also, C) Jetpack used to hide the ability to toggle individual modules behind an obscure "debug" link, so a lot of organizers probably never discovered the available functionality.

coreymckrill commented 4 years ago

I think we should pick a set of modules that are generally useful to events and make sure those are on by default so that their functionality is immediately discoverable. That's the best UX for organizers and attendees.

Then there are some that we might want to prevent from being turned on, and some that we might want to prevent from being turned off.

iandunn commented 4 years ago

Subscriptions, Contact Form, and Custom CSS are used by Coming Soon and Remote CSS, so I think they should always be on.

On by default: I guess Stats, since you can't gather that data retroactively if it's off by default. Protect seems fine. Publicize/Sharing is probably something most teams want. The CDN ones and Markdown might be nice. I don't see a compelling use case for the others, but I don't feel strongly.

None of them jump out as something we'd want to disable entirely.

timiwahalahti commented 2 years ago

Created a PR to add some new default modules. Left following ones out: