Howdy Students! Google Summer of Code is a program in which Google sponsors exceptional college students to develop open source code under the guidance of mentoring open source projects. WordPress is applying to be participating as a mentoring organization again this year. Though we won't know if we're accepted for a while, this page contains information about potential projects and mentors. Students who complete their summer projects successfully and on time are paid a stipend by Google that adds up to $5,000 for the summer. Project progress is evaluated at midterm and at the end for payment consideration. To apply for a GSoC slot working with WordPress, you should be proficient in PHP and/orjQuery, and have familiarized yourself with the WordPress codebase.
If you have your own idea for a project, include it in your application and describe it thoroughly. You are not limited to ideas from this list.
Know you want to propose a GSoC project around WordPress, but aren't sure what you want to do? Below are a few ideas we think would work well as GSoC projects. Also see the popular ideas submitted by members of the WordPress community. If you share one of their passions, why not make that idea your own? Also, check out the ideas from 2011 to get an idea of some past projects.
Note that you can't take already released code and claim it as part of your project. So, if you propose one of the ideas that have already been implemented by former students, you will have to code it from scratch.
Sidebar widgets are created by extending the `WP_Widget` class with custom data, functionality, and markup information. Dashboard widgets in the WordPress admin are, however, far less abstract. Certain widgets rely on the same code (i.e. feed widgets) without a clean abstraction layer to prevent changes to one from breaking another. This is one of the biggest reasons #19239 hasn’t gone anywhere yet. Merging the widgets required some hackery and the new widget in that proposed patch isn’t abstracted enough to be reusable anyway.
The project will have two parts:
Deprecating the post by email functionality has been on a list of proposals for quite a while, and despite a patch (#22942) that disables the feature (similar to how Links were recently disabled), momentum has stalled since no clear alternative exists.
The project would be to create a new plugin that extends post-by-email functionality in a clean, well-coded, extensible manner. This plugin will eventually be hosted in the .org repo, after which time the patch on the above ticket will be updated for WordPress 3.7.
WordPress uses auto-incrementing integers as IDs for every data table. This is easy to parse, but also leads to various problems. For example, one of the most talked-about “vulnerabilities” in WordPress is the ability to slurp down user IDs and login names programatically since user IDs are auto-incrementing integers. This could be prevented by changing the data structure to use UUIDs instead.
Also, while posts necessarily need an integer ID (used in default permalinks) there is also a GUID field in the posts table that is misused by developers as it looks like a URL rather than an GUID.
The project would be done in two parts:
Users The first part of the project will be to update User data structures to support real, dynamically-generated UUIDs for IDs rather than auto-incrementing integers. User creation and search methods would likewise be updated to support the new data structure.
Posts Second, updating post data structures such that new posts populate the GUID field with a true UUID (rather than the current post permalink) would prevent a lot of developer confusion as to what the field is and how it’s used. (Regular post IDs should remain integers since they’re used in the default link structure.)
Text widgets have morphed into holders for all kinds of content that normally would be in posts or pages, but gets put in a widget for design purposes. Until such time as we re-think widgets and content areas, this project idea would supercharge text widgets specifically to add things like rich editing, revisions, and autosave to make these content holders more useful. Applicants should be familiar with the code underlying widgets, TinyMCE, and revisions.
The WordPress web admin works okay on touch-oriented devices, but it's really better suited for being driven by a mouse right now. Ideally using just an alternative stylesheet, go through WP from the login to the menus to comment moderation and make it sing on a touch device. Bonus points for expanding into JS and adding gestures where they make sense, like comment moderation.
This is an idea that's been suggested many times and it never seems to make it into a release. We'd love for someone to take this one. When you first set up a WordPress site, there are certain steps you have to go through. Pick a theme, change your password, edit your tagline, choose your comment settings, etc. It would be great if on the Dashboard screen there was a module that kept track of how many of these things you've done, and marked off your progress, much as LinkedIn does when you set up a profile. Each successive login would offer the user an option to finish/enhance their site setup by completing another thing(s) they haven't gotten around to yet.
For a rough idea, see a previous year's project, Mike Whitfield - Setup Meter.
The existing importers/exporters use XML. This project would convert these two plugins to use JSON for a leaner, less error-prone import/export experience. Applicants should be familiar with the import/export plugins and JSON.
WordPress sends out a bunch of email notifications for new users, comments, password resets, and more. Right now they're all plain-text -- let's bring them into the 21st century with well-designed HTML + CSS that brings additional functionality into the notifications, makes them more readable, and is optimized and tested across common web mail clients, desktop mail clients, and phones including iPhone, Android mail, and Blackberry.
Also see Enhanced Emails from Gsoc 2011.
WordPress saves post revisions, but changes to theme files are not recorded, though the presentation layer is sometimes just as important. Build a versioning system for template files within the theme editor.
For a starting point, see a previous year's project, Andrew Nacin - Theme Revisions.
Improve comment moderation in the administration pages so that when threaded comments are enabled they are displayed when moderating individual posts comments. It would also be useful to allow comment re-parenting so as to fix issues where a comment reply is not associated with the correct parent. Support should also be added to the XML-RPC api to allow an external app to implement similar functionality.
For a rough idea, see a previous year's project, Matt Harzewski - Comments.
WordPress media handling functions have recently been redesigned, with new features added and significant recoding of existing features. There are many components to the media overhaul, extending any of which could make a great Summer of Code project. We'll be looking to add things like slideshows, better gallery functions, creating more user settings for media files and templates, and dozens of other features that could be packaged up for SoC projects.
Currently, if you want to move your WordPress install to a new host and keep the same domain, you only need to move all the files (WordPress Core, Themes, and Plugins), and then export/import the database. It’s pretty straight forward, but still more complex than many users are capable of.
However, if you want to change the domain (even without moving to a new host) you have to export the database, do some search and replace on the .sql file, and then re-import the updated database. Even then, if the new domain has a different number of characters in it than the old one did, you can run against problems if any of the places you replaced the name happened to be inside a serialized array (almost all the options, including things like widget settings, text widget text, etc).
The goal of this project would be to make a these kinds of transitions simple and smooth. If only the domain is changing, then when the user updates the WordPress URL we would update internal links in their posts, settings, image urls, etc. If they are moving to a new host, allowing them to install WordPress at their new host and enter their credentials for their old host (WordPress admin credentials as well as FTP credentials) and WordPress would simply import everything (posts, settings, uploads, theme, plugins, etc).
For a similar project, see a previous year's project, Brian McKenna - Automatic Migration
If you look at trac, there are literally hundreds of tickets for bugs, enhancements, feature requests and blessed tasks that never quite make it in. Not every GSoC project has to be a big single-feature goal. Helping us improve existing core WordPress code is also very valuable. For a Full-Throttle Trac Annihilation project, you'd want to identify the areas of code you're most comfortable working with, and identify a scope/minimum set of tickets that you will fix and close by the end of the project term. This could be based on a component, such as accessibility, comments, UI cleanup (Jane would love this) or upgrading, or could be a selection of specific tickets you think are important to address and would provide you with a summer challenge. The benefit of this project type is that you will have the entire development community to give you feedback as you work.
In various places in the WordPress UI, there are times when you're waiting for something to happen: a post to publish, a file to upload, a plugin to install. Each of these instances uses a different method of showing the user what's going on: a spinner, "crunching," and plain text announcements when it's done, respectively. This project would be to create a progress bar for actions that require time to elapse, and embed it into all the functions of this type.
GlotPress is a web-based collaborative translation tool. It is a web alternative to poEdit and the rest desktop gettext editing tools. Code-wise GlotPress is based on BackPress and a tiny MVC layer on top of it. The project will be to add functionality to GlotPress:
You will like the project if you also like object-oriented programming and clean, self-explanatory code.
WordPress is translated into more than five dozen languages. Currently translations for plugins and themes are bundled by the theme or plugin author in the download package, with the translations manually loaded in code. For core, the translations are bundled in localized distributions of WordPress.
The goal of this project would be to separate translations from existing download packages for themes, plugins, and core, by implementing language packs. These packs would be downloaded from the GlotPress installation at translate.wordpress.org (where they would be built on the fly). While language packs may eventually be implemented in WordPress core, this is conceivable as a plugin. The plugin should be able to install a language pack for a specific localization and load it automatically. Ideally, the plugin author would only need to internationalize a plugin and a translator to enter translations into GlotPress, and WordPress should be able to handle the rest.
Work is also necessary in GlotPress for this (support for plugins and themes, ability to build download packages, etc.), so this task can probably serve as two separate projects.
The P2 theme allows users to post directly from the front end. Extracting this functionality into a template tag that could be used by any theme and extended for use in custom post types would make it easier for other theme developers to have this functionality.
There are probably other improvements you could make and you need to have a clear proposal on which issues you want to work on during your GSOC project.
WordPress used to support Google Gears as a "turbo" mode, which cached static admin assets (images, CSS, JS) in the browser. This was a significant performance boost to the administration area. While most HTML5 APIs center around online-offline applications, a cache manifest can be used to replicate old behavior.
The WordCamp.org network powers hundreds of sites for WordCamp events across the globe. There are many things on WordCamp.org that require more work including, but not limited to: a better themes directory, improved ticketing functionality (additional payment gateways, waiting list, live streaming, etc.), various shortcodes and generators, network-wide reporting tools, better forms and surveys.
You'd work on the enhancements of your choice, so talk to Konstantin Kovshenin during the application period to decide what you want to prpose for your project.
WordPress for webOS is a great app built with web technology. Several new web-centric mobile platforms are springing up and it would be great for WordPress to have a presence on each. Let's take the webOS app and convert it to run on one or more of these new platforms: Firefox OS, Tizen, or Ubuntu Mobile.
Did you know its possible to share information directly in-between iOS apps? We'd love for other iOS apps to be able to share directly to WordPress for iOS. Modify the app with the necessary changes to support sharing text and images from other apps and document an API for other developers to use.
Many apps support sharing to Facebook and Twitter, so why not WordPress! Pick your favorite mobile platform and create a drop-in native library that other app developers can use to add a Share to WordPress feature to their own apps. As a bonus, support sharing to multiple blogs!
BlackBerry has a brand new OS out but its not complete until there is a native WordPress for BlackBerry app in its market! Create a simple, native, WordPress app for the new BlackBerry OS. Possible ideas include short form blogging and photo sharing.
The WordPress mobile apps all support adding images to posts but they are lacking good options for aligning and sizing images. Pick your favorite mobile platform and improve the image presentation, alignment, and sizing options in the post and pages editors.
The views for posts and pages in the WordPress for iOS app is okay, but it could be better! Create a way to display a lists of posts with most of their content, and a way to expand to view it all. Tapping an item allows you to edit it. The goal is to have something awesome to replace the posts/pages lists in the app!
The WordPress mobile apps all support posting images but many people like to keep copies of their images on other services as well. Pick your favorite platform, and add support for cross posting photos to Google+, Facebook and Dropbox when publishing photos to a WordPress blog.
WordPress for Android is missing a few things for its post's list that could really make it better. Add in support for showing post thumbnails in the list. Also, if a list is empty, create a nice placeholder to show instead of a blank screen.
WordPress for Android has Quick Photo, and Quick Video features. These are great but why do we need two when we could have one even better Quick Post feature! Merge the functionality of Quick Photo and Quick Video and also add support for Quick Text. Your goal is to make it simple to quickly post text, images and video in as few steps as possible.
The WordPress ecosystem can benefit from having two-factor authentication backed by WordPress mobile apps. The WordPress iOS, Android, and other applications should have the ability to "turn on" two-factor authentication (using the HOTP algorithm) for a user. This would require a WordPress plugin to recognize the connection and require the second token on login.
Hey mentors: please don't edit this section without talking to Jen Mylo first. Thanks!
Additional members from the WordPress open source community will be added as mentors based on project needs.
Additional members of the WordPress core contributor community will help guide students through interaction on the blog we will set up up for this purpose, where they will give feedback on weekly student reports and respond to student questions.
Excited by the possibilities, and want to know what you have to do to apply? Awesome!