A proud Canadian who grew up in Toronto and its suburbs, I am currently a bioengineering undergraduate at the University of Pennsylvania in Philadelphia, with hopes of working in the clinical and public health roles of a physician. The connection to coding might seem tenuous, but I am a firm believer in pursuing passions, despite how incongruous they may seem. As I wrote in my application, WordPress has offered me much in the way of community and inspiration, and I hope to gain better insight into my own aspirations through this internship.

Like many in the community, my involvement with WordPress has included some plugins, and sites developed for work and student organizations. Although I’ve worked on two separate open source PHP projects, this is the first opportunity I’ve had to contribute to something that can reach so many people; indeed, the past Ten Good Years have yielded not only a collection of lines of code, but a huge and intensely active ecosystem of developers, designers, and users. To have the chance, even for 3 short months, to be a part of it, is both exhilarating and terrifying at the same time!

My project is to improve the migration experience and the portability of WordPress. Just the thought of moving WordPress elicits headaches because of all the things that can go wrong, as one stunningly recent discussion in the community reminded me.

For this project, I’ll be treading across both familiar and foreign territory. By current plans, I’d like to bring domain/URL renames to the backend and WP CLI, improve media handling and progress feedback in the WordPress-to-WordPress importer, and build in some semblance of plugin & option migration to the export/import workflow. (Subject to further change with notice.) More details will come in the days ahead.

I’m really thrilled to be working with all of you! In addition to my weekly updates here, my notes-to-self and handy links to Trac/source can be found on my project site. I’d love to hear your feedback here and throughout the project.

For those who missed the discussion on wp-hackers about my proposal, I’m working on a JSON-based REST API for core. I started on this with an initial proof-of-concept back at the end of last year, and I’m now working on expanding this out into a larger project. The code is being written as a plugin for testing, with the goal of having it integrated into core in some form post-GSOC.

I’m planning on following a release strategy similar to MP6, with a weekly release along with the updates included in the release. At the moment, I’m working on completing the basic reading and writing of post data having just completed the major design documents, and I’m hoping to get the first weekly release out next week. I have a more detailed timeline which you can check out in my announcement post on my blog.

(You’ll notice I’m currently about a week behind on my schedule, which I suspected may happen, as I’m in the midst of my final exams here. I’ve allocated an extra week just before the midsemester review for catching up if I don’t do so before then.)

As it is, the plugin is in a usable format, and you can grab it from either GitHub or Subversion. I’d also recommend checking out the GSOC Trac issues if you’d like to keep track of the status. I’d love to have your feedback (especially on the design documents) as I move forward.

Cheers, and I look forward to working with you all in the coming months!

So, web development and WordPress are mostly just hobbies of mine — I hope to change this in the future. I did a couple of paid jobs creating WordPress websites and also have a couple of plugins in the repository. I really like the idea of open code and bringing web publishing forward this way. Not having one brand control so many websites directly is a huge advantage in comparison to other web publishing tools.

My project will be bringing WordPress native revisions to the theme and plugin editors. Some developers are of the opinion that it would be best to strip the code editors from WordPress core. I think they are an important launch pad for average WordPress users to get into touch with their site’s code base. It’s a first step on the way to submiting a first patch to core.

An obvious problem when enabling users to edit their websites code is that they might break things. Changes can result in fatal errors which might break their whole site. With code revisions it will be easy to reverse to a specific version of a faulty site when something breaks. The idea here is not to make the editors interesting to developers but to make them more comfortable to use for website owners.

Happy to work with you guys and to get some feedback. With enough eyes, all bugs are shallow

I live in the Bay Area and have been a freelance web developer for the past couple of years, so as you can imagine, I work with WordPress quite a bit. I’ve written custom themes, taxonomies, post types and plugins, but nothing that I’ve been able to release back to the community.

Even though contributing to an open source project has been a goal of mine for many years, I was never able to figure out how to get started until now. When a friend sent me the OPW page and I saw WordPress on the list, I leapt at the chance to get more involved with a tool (and a community) that I’ve worked so much with, and in the process really level up my WP knowledge.

For my summer project, I’ll be removing the “post by email” functionality from core, deprecating it and replacing it with an official plugin. This addresses Trac ticket #22942.

There are some more details in the initial version of the proposal I wrote up. Note that I haven’t yet hashed through the plan with my mentors, so standard disclaimers apply. (Details subject to change without notice. Void where prohibited. Not labeled for retail sale.)

Feel free to comment with feedback, or just to say hi. I’m looking forward to working with you!

One of the original goals of bumpbot was to reduce the noise when doing code review on a commit that involved JS or CSS. But these commits can occur fairly often and still cause noise.

The concern is two-fold:

1. Will skipped commit numbers cause people to look around for them, so instead of saving time, it actually increases time spent on these?
2. If a bot screws up and no one is around to hear it, does it make a sound?

I think #1 is surmountable. #2 can be solved in a few ways. One, the commits will still be posted to IRC by svn-bot, and viewable in Trac’s timeline. Two, we could continue to have them sent to a few people, if necessary. Also, these bots have made few mistakes over the years, as every time there’s been a bug, we’ve fixed it. Of course, it’s all just VCS, so any issue can be reverted. And we have protection in place around releases to make sure the bots did their jobs and “run clean”.

Anyone have a strong opinion either way?

I fought hard for it, and a lot of people put a lot of effort into it. But the result just isn’t compelling, or obvious, or any of the things that it should be. It’s not just a matter of polish, it seems to be a fundamental issue with the concept. The release can’t be held up any longer for this. It needs to come out. I should have made this decision earlier. That’s on me. But letting it ride would be the worse mistake.

Here is the proposed plan for extracting it, and for dealing with other tangentially related or other release-related items:

Post Format Things to Move to the Plugin

• The posts screen UI, including icons in H2 #24452 #24502
• Enabling all formats by default #24452
• The custom screen options (go back to what we had before) #24452
• The content/excerpt/title necessity modifications in wp_insert_post() #24503
• Content area size changes #24452
• structured-post-formats support and post_formats_compat() #24453 #24454
• Revisioning of the post format and post format metadata keys #24455

Post Format Things to Keep in Core

• Icons on edit.php (perhaps adding them to the radio format chooser to sync that context) #24519
• post-new.php?format= shortcut
• aside/status auto title generation (when blank)
• URL extraction function (renamed from get_content_url() to get_url_from_post_content())
• Post Format previewing #24483

Upgrade Path for Beta Dogfooders

• Consider rolling upgrade that pieces together post_content based on existing meta keys
• Alternatively, include this as a tool in the post formats plugin
• Perhaps a WP-CLI component to the post formats plugin, so those upgrades can be done on the command line, once

Strategy for Media

• Leave most of wp-includes/media.php — keep audio/video support
• Call functions directly rather than calling do_shortcode() #24505
• Have wp_get_(audio|video)_extensions() wrap wp_get_mime_types( $type = null ) if feasible #24504 (NOPE)
• Remove or make sane attachment_url_to_postid() #24458
• For A/V shortcodes, include the attachment ID, instead of just the URL (makes attachment_url_to_postid() unnecessary) #24458
• Transition those IDs on import #24458
• Consistency: embed shortcode takes URL as its content, but a/v ones take an attribute — make both for both? #24456

Shortcodes

• Keep shortcode_exists() and has_shortcode()

What Else?

Did I miss anything? Is there something that doesn’t seem like the right path forward to you? Let’s hash this out so we can move on it.

This week focusing on RTL again, especially concerning :before and :after and Genericon placement, see #24287. Turns out we’ll need flipped versions of lots of the glyphs—which Joen is now working on. After Joen completes the Genericons font updates are ready we’ll sync them into Twenty Thirteen.

Next is another quick pass at editor styles, including RTL support there.

I’ve been reviewing a lot of proposals and ideas. But if you’re waiting until the last minute (like I’m doing with this post), here are some random nuggets:

• Original ideas are encouraged! We have a great ideas page but we’re not going to complain if you submit something else.
• You don’t need to be a computer science student! We’ve had liberal arts majors and things turned out just fine.
• Please demonstrate your abilities by making an attempt to contribute to WordPress core or by writing a plugin. Even though this may happen after applications have closed, it could help.
• You can submit more than one proposal. This is good because we won’t accept two students for the same proposal. And because you might have two great ideas but aren’t sure which one aligns better with our interests. That’s okay — submit them!

Finally, here are four more ideas in case nothing else appeals to you. (I’ll make sure these make it onto the ideas page next year.) If you’re still hunting, see if any of these set off bells in your head: (yes, there are WordPress plugins for everything, but innovation and new approaches are good things)

• Activity. Activity streams, action history, notifications. Imagine what a dashboard could look like for a busy, multi-author site, and how helpful it could be to see what’s truly going on “right now” — as well as what you missed.
• Meetups. Local WordPress communities organize a lot of meetups. A set of tools for organizers and the local community could be really helpful. (These tools could include integration with meetup.com and wordpress.org profiles.)
• Dependencies. Allow plugins and themes to be dependent of one another. A theme could require a plugin or example, and WordPress would handle installing that plugin when you install that theme. Similar idea: Compatibility metrics. (Or: Can we be sure it is safe to upgrade everything?)
• Bug tracker. WordPress can be a great platform for developer tools. Why not a bug tracker? (Read the 2010 ideas page for more.)

Of course, there’s a lot of other great ideas on the 2013 page. If you haven’t looked recently, I added a few at the start of the application period, including some JavaScript-heavy stuff (editor modes, HTML5 application cache, TinyMCE views). Good luck!