Dev Chat Agenda, March 25, 2015

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? 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.

» BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 Puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.): #26601 – Inappropriate content in headings on adminadmin (and super 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 ticketticket Created for both bug reports and feature development on the bug tracker.? 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. 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 UIUI User interface 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 MVPMinimum Viable Product "A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. I think the Shiny Updates dev process has well and truly shown that the trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. dev model is totally broken.
- Shailesh 9:14 pm on March 26, 2015
  
  What if we convert Install button in Activate It after pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to disable the auto-activate after install.

Comments are closed.

WordPress.org

Welcome!

Communication

Agenda

Share this: