Dev Chat Agenda, March 25, 2015

Welcome!

The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bug? Create a ticket in our bug tracker.

Want to contribute? Get started quickly with our tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on our reports page, like patches needing testing.

Other questions? We also have a detailed handbook for contributors, complete with tutorials.

Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

» Beta 2 was tagged last week as scheduled and we’re heading toward tagging Beta 3 this week.

Time/Date: March 25 2015 21:00 UTC:

Reminder for those on Daylight Saving Time – If you’re already on Daylight Saving Time, the core dev chat will be an hour later for you until next week, though still 21:00 UTC. The above time link should give you the correct time and date for your local timezone.

Agenda

Decisions
- Shiny Updates: Auto-activation behavior
- wpLink modal: Behavior for working links lacking source text
- Pursue or Punt: #26601 – Inappropriate content in headings on admin screens
- About page highlights
- Make/Core Posts – Ideas: Schema change, query class changes, TinyMCE views changes, twemoji front-end loader, update on HTML5 widgets revert, etc.
Upcoming Milestones overview
- Beta 3 (90 tickets on Report 6)
  - Start finishing up tickets with string changes
  - Start About page
- Beta 4 (50 tickets on Report 6)
  - Soft string freeze (all string changes completed save for the About page)
  - Start finishing up the About page
- RC 1 (0 tickets on Report 6)
  - About page finished
  - Hard string freeze
Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!

#4-2, #agenda

Aaron Jorbin 5:03 pm on March 25, 2015
RE: Shiny Updates –

24 hours ago I wouldn’t be advocating this, but there are a couple of really good reasons that we shouldn’t do auto-activates.

1) Plugins that require after activation steps (such as connecting for jetpack or google analytics, updating permalinks for buddypress, etc) aren’t obvious. We need a way for plugins to provide a notice upon activation of next steps
2) Since the menu isn’t updated, users still need to do a page refresh in order for the changes to actually go in affect and for them to utilize the features of many plugins.
3) There are plugins such as maintenance mode ones that users will not want to be activated right away.

I really like the idea of auto-activating since I think it helps to discourage users from having code that isn’t actually being used from being on the server and also saves the user a step, but in reality, they aren’t saved a step.

We have at least two options for what to do instead.

1) We remove shiny installs from the release. This is fairly easy to do as we just need to remove the js bindings on that page and remove the ajax actions. Since much of the infrastructure code is in place now, I think that it’s possible to continue development of shiny installs in a plugin. This would enable us to work on things such as:
- Adding the ability for plugins to register “notifications” for users on what they need to do after installing.
- Add the ability for plugins to “opt-out” of auto installs
- Work on adding in menu items or at least a link to a plugins setting screen.
2) Turn off auto-activation and instead do some UI changes when a user installs a plugin. I’m thinking a notice banner inside the plugin card giving the option to activate. This can either be a shiny (ajax) activation or a traditional activation. We also could change the “install” button to be “activate”.

At this point, I recommend option 1. Shiny updates is still a solid MVP and a win for the users. It also sets us up for some bigger wins down the rode.
- Eric Lewis 5:21 pm on March 25, 2015
  
  I’m in favor of option 1 as well. It’s late in our release cycle to be making user-facing decisions that bear such heavy impact.
  
  Shiny Updates is a great improvement, let’s focus the rest of our effort there and follow-up on Shiny Installs later.
- Gary Pendergast 10:47 pm on March 25, 2015
  I’m strongly in favour of option 1. Providing an Activate option gives us one of two problems:
  - If it’s a Shiny Activate, it’ll have most of the same problems we’ve run into with auto-activate.
  - If it directs to the old activate screen, it’ll interfere with currently running Shiny Installs, and probably other things.
  I’m also in favour of seeing if we can turn this into a plugin. I think the Shiny Updates dev process has well and truly shown that the trunk dev model is totally broken.
- Shailesh 9:14 pm on March 26, 2015
  
  What if we convert Install button in Activate It after plugin is downloaded?
  If user click on activate button, page will open in new window something like target=”_blank”. So current other progress will not affected.
  
  Same for already activated plugins. We can put Deactivate It button and onclick we can deactivate it in new window.
- Chuck Reynolds 2:31 am on March 27, 2015
  
  agreed. glad the auto-activation was stopped.
  Something to consider going forward… a filter to disable the auto-activate after install.

Comments are closed.

WordPress.org

Welcome!

Communication

Dev Chat Agenda, March 25, 2015

Agenda

WordPress.org

Welcome!

Communication

Agenda

Share this: