There are a few days left to submit proposals to OSCON. It would be great to see the sessions there that are about WordPress actually being presented by people involved in the project, so I’d like to encourage/beg/urge some of you to submit a proposal based on your involvement in the core project and/or the cool stuff that’s come out in the past year. The submission deadline is January 30, and the event itself is in Portland, OR July 20-24, 2014. To apply to speak at OSCON, go to http://www.oscon.com/oscon2014/public/cfp/308
Recent Updates Page 4 Toggle Comment Threads | Keyboard Shortcuts
This is a major upgrade for the WordPress editor. There are many changes in 4.0:
- New UI and UI API.
- New theme.
- Revamped events system/API.
- Better code quality, readability and build process.
- Lots of (inline) documentation.
- And generally many improvements everywhere.
All default TinyMCE plugins have been upgraded. The WordPress implementation custom plugins were upgraded too. Looking in the plugin repository, there are a lot of WordPress plugins that add a TinyMCE plugin. Because of all the API changes, most of these plugins would need an update too. If you are the author of such plugin, please test it in trunk now.
Generally there are three groups of TinyMCE plugins added by WordPress plugins:
- Custom plugin created specifically for the WordPress plugin. If you’ve developed this kind of plugin, please see the 3.x to 4.0 migration guide and the 4.0 API documentation.
- WordPress plugins that add third-party or default TinyMCE plugins would (of course) need to be updated to include the 4.0 version of the plugin. The PHP global $tinymce_version can be used to determine which plugin to load.
- Mini-plugins that only add a button to the toolbar. This works pretty much the same. It is advisable to update to use the ‘dashicons’ icon font instead of image icon.
Due to a lot of stuff in my lap for the next few months, I don’t have the time to keep chasing down things for Search. If anyone would like to take point, I’d be glad to help in any way possible, I just don’t have the time to wrangle it personally for the foreseeable future.
We were supposed to discuss WordPress 3.9 during the weekly meeting last week, but in the absence of a decision on a release lead, and with a lot of 3.8.1 things to get through, it got pushed to today. 2100 UTC, #wordpress-dev (so, in an hour).
I’ll be the release lead for WordPress 3.9. Expect some familiar faces helping me out, including Andrew Ozz, who will be overseeing all of the TinyMCE work already underway this cycle; Helen Hou-Sandí, who will be spending most of her time working on and advising ongoing feature plugins efforts; Sam Sidler, who will be helping with project management; and Mike Schroder, who will be backing me up for this release.
Today we’ll be:
- Setting a schedule. The tentative 2014 roadmap decided in December slated 3.9 for April 15. That’s 90 days from now, and sounds good to me.
- Reviewing feature plugins. Lots of things in progress — let’s take a quick look.
- Brainstorming on what this release should be focusing on. There are plenty of possibilities when it comes to iterating on existing features (especially those added in the last five releases — the customizer, media, audio/video, theme browser, admin UI), general bug-fixing, long-standing architecture and API improvements, and such.
- Discussing changes to workflows. Changes to Trac, ticket reporting, re-doing our components tree, a new Git mirror, and such make this release look a lot like 3.7, when we kicked off the new core development repository. We could use continual help to identify how we can make it easier to contribute, break through bottlenecks, etc. We also need to tag some tickets as good-first-bug!
Hope to see you today. Have any idea, thought, or suggestion about 3.9 or for today’s meeting in particular? Please leave a comment so I can prepare for it. Talk soon.
I’m pleased to share we now have an official Git mirror for the WordPress core development SVN repository.
git clone git://develop.git.wordpress.org/
Read-only mirrors are also set up for a few other WordPress.org repositories, including BuddyPress, bbPress, and the old core.svn “build” repository:
git clone git://buddypress.git.wordpress.org/
git clone git://bbpress.git.wordpress.org/
git clone git://core.git.wordpress.org/
git clone git://glotpress.git.wordpress.org/
Make sure you use the git protocol (not http) and include the trailing slash.
Can you use develop.git.wordpress.org for core development? Yes! For all practical purposes, the SVN and Git repositories are now equals. Pick your poison; use whatever you’d like for all your development and deployment needs.
For creating patches: If you’re into the command line, simply use
git diff— to be specific,
git diff --no-prefixis ideal. This format is easily applied with
patch, just like SVN diffs. For more, check out scribu’s post on contributing using git. Might also be a good time to plug grunt-patch-wordpress, a work in progress — help make it awesome, if you can.
With this mirror, we’ve applied some lessons we learned from previous experiences:
- Tags for major releases receive an extra .0 (“3.8.0″, not “3.8″), making them compatible with tools requiring semver-like version numbers, and allowing branches to have their own namespace (“3.8″, not “3.8-branch”).
- Committer data is pulled from WordPress.org.
- The SSL versions of the SVN repositories are used.
Note that these Git repositories have different hashes than anything currently mirrored on GitHub. We never did break these hashes as promised a year ago. Next steps will be to figure out how to best mirror these to GitHub (and replace what’s there), which is complicated by now having old and new repositories for core development. Additionally, I’m sure we’ll find at least one glitch in this in a matter of a few days, so consider the next week or so a beta test.
Edit: Well, I mentioned the next week would be a beta test. We found an error (that didn’t take long) in how authors got synced over, so we’ll be breaking the hashes tonight.
There are a lot of other repositories on WordPress.org not yet mirrored. Notably: plugins and themes. These are massive multi-project repositories and will require a bit more investment.
I wanted to do a Make post on my wants for Audio / Video in 3.9 to solicit feedback and spark some discussion about what the community wants / needs / doesn’t want / doesn’t need. Adding audio / video in 3.6 was a great first step, but there are some things we can do to continue to modernize Media and give our huge user base even more ways to display and manage their content. We can also make some changes that help developers navigate the new world of MediaElement.js, Backbone, and Underscore.
First Things First: New Icons
#26650 Replace media file type icons with Dashicons
There are some lingering icons in the admin that don’t look as pretty as their MP6ify’d brethren
Document the “new” Media code introduced in 3.5
In 3.5, we overhauled Media. @Koop produced some beautiful code, and a LOT of it. Raise your hand if you’ve ever dived in and tried to program against it? Raise you hand if you understand how all of it works? Me neither. As a community, we need to help each other learn what it is and what it does. Documentation will go a long way in getting us all on the same page. Do we have a documentation standard for JS? We need one. While this isn’t the easiest place to start, it is a necessary one. I would be happy to spend time on this, as I have spent many hours recently reading the code and learning how it works. The main files: media-editor.js, media-views.js, media-models.js
Support subtitles for Video
#26628 Use the content of a video shortcode when provided.
This ticket speaks for itself, and already has a patch.
Generate audio/video metadata on-demand
#26825 Add ability to generate metadata for audio / video files on-demand
Add “Playlist” and “Video Playlist” shortcodes
#26631 Add a “playlist” shortcode
My ticket already contains a patch, but is still considered a work in progress. I think the playlist shortcode should produce markup that does the following:
- Works out of the box with any existing theme: the HTML should be semi-bulletproof. Many of the Player libraries make heavy use of DIVs instead of items that might be overridden easily with CSS: LIs and the like.
- Gives the developer total control if they want to write their own implementation
- Exposes enough data to the page so the themer/dev can make their own decision regarding display of album cover, track meta, captions, etc.
My current implementation drops data onto the page for each playlist inline. A wrapper div “.wp-playlist” will have a script tag in it with type=”application/json”. I do this so that if ‘wp-playlist.js’ is unenqueue’d, the developer still has the data necessary to write their own implementation. The data is reachable in JS like so:
var data = $.parseJSON( el.find('script').html() );
My current UI for playlist is a basic one, and uses Backbone Views to render the tracklist on load and update the “current” playing track view. There are 2 camps of people when it comes to “JS on the frontend” – one who doesn’t like it (others) and one who says “who cares” (me). One of the reasons I am posting this at the beginning is so we can flesh out issues like this.
Abstract Gallery logic into “Collection” logic that Galleries, Playlists, etc can use with minimal registration code
I have already done a first pass at this in the playlist shortcode patch. It goes like this: a “gallery” is really a “collection” of attachments of type “image.” A “playlist” is really a “collection” of attachments of type “audio.” So they should extend or be instances of a “collection”-type class. Currently, the Gallery code has to be dupe’d. By abstracting this code, Gallery, Playlist, Video Playlist, + any other “collection” of media type can be registered minimally.
- In our playlist JS code, emit events that others can hook into – maybe a video playlist is: News clip, ad, news clip, ad, etc. When emitting events before / after an ad, the dev could disable next/prev buttons
- Make a playlist embeddable on other sites via an iframe or embedded markup
- Register an endpoint for audio / video that will expose the “embed code” via oEmbed
One thing I’d like to work on is improve our reports on Trac with the hope we can better manage the ticket queues. We currently have about 50 reports on Trac. Many of them were created in a push 5-6 years ago to build reports around keywords. A number of others are one-offs created in the last few years for specific use cases. In reality, few of these are ever used on a day-to-day basis.
I checked the access logs to get an idea of the most popular reports. Besides the first six reports (my favorite “home base” is report 6), they are report 16 (“Needs Patch”), report 18 (“Blockers for Releases”), and report 21 (“Latest Tickets”).
What I’d like to do is brainstorm all sorts of new reports we should have. How can we make what we have better? I’ll then go to work about implementing them. Dream big — if the data’s there, I’ll figure out the gnarly SQL required. We can also think about how we can improve columns, grouping, ordering, etc. If you have a concept for a report but aren’t sure how we’d query for those tickets, toss the idea out there and maybe someone will add to it.
I’l probably design a new /report screen so it’s not just a list ordered by something random like when the report was created, and so we can highlight important reports, group similar reports together, and put less emphasis on some of the more specialized ones.
Here are some half-baked ideas, to start us off:
- Open tickets without a response. Find all tickets where no one has commented, or where only the reporter has commented. This would create a punchlist of tickets to review. (Ideally, the report should always be empty.) The ability to group or filter this by component would be helpful, for contributors who specialize in and want to take responsibility for different areas.
- Report of “dead” tickets. Tickets that haven’t been modified in four years are ripe for action and/or closure. We should empty a report of this nature, then reduce it to 3.5 years, then 3 years, etc.
- Good first bugs. A report of all tickets marked as a good first bug. (None yet, as the keyword is new.) Next steps: How can we best identify these kinds of tickets?
- Report of “untriaged” tickets. Our milestones have gotten out of hand, which is something we should discuss. Tickets should immediately leave “Awaiting Review” once they’ve been initially reviewed, but then not forgotten about if they are shifted to “Future Release”. Let’s figure out metrics for what makes a ticket “untriaged”. We could create a simple UI to filter by component for a report like this. We currently have Tickets Awaiting Review which groups tickets by the “Version” they were reported against — maybe this is a good start.
What’s your idea?
Monday’s long list of improvements to Trac was just the first course. Introducing per-ticket notifications.
Just above the comment box, you’ll see a new notifications pane. Here, you can watch/unwatch tickets.
This means Trac’s terrible email address CC feature is gone. (Last night, I migrated over about 15,000 CCs going back nine years.) Old comments that are just CCs are now hidden via JS, which makes a few of the busier or popular tickets easier to skim.
You can also click the star next to the ticket number at the top:
Coming soon: You’ll be able to watch/unwatch a ticket directly from a report, like starring conversations in a Gmail inbox (edit: added). You’ll also be able to subscribe to entire components and milestones (here’s a sneak peek). And, @-mentions will let you add someone to a ticket.
A note on how this is implemented: isn’t just subscribe/unsubscribe. “Watch” can also be thought of as “Vote” or “Star” or “Favorite”. We’ll soon add a star count to reports (next to the new Comments column — edit: added). If you’re watching a ticket, you’ll always get notifications. If you’re not, you might still get notifications if you reported the ticket, or are subscribed to that ticket’s component or milestone, or if you’ve been mentioned (and the notifications box will tell you that). From there, you have the option to actively “Watch” the ticket, passively continue to receive notifications, or specifically mute/block notifications coming from that ticket.
Follow-up question from @sabreuse, about watching/voting/starring/favoriting: If you subscribe to the “firehose” (wp-trac mailing list) and receive all notifications anyway, should you star tickets anyway as an indication of interest? Yes, I’d say so! (If you receive the mailing list to the same email address as your WP.org profile, you’ll only receive one email. It’s possible your mail client could ascertain you received it as a BCC versus just via a mailing list, though I’m not sure.)
Feedback, ideas, suggestions are very much appreciated. Also, all of this code is open source (a lot of it is a WordPress plugin).