Recently WordPress added QUnit as a JavaScript unit testing framework and added its first JavaScript unit tests. I thought I would walk through how to run the tests and how to write tests so that we can increase our JavaScript test coverage. All of these are based upon using the develop.svn.wordpress.org checkout which is where the JS unit tests live.
(More …)
This week, I finally have a new release for you! Version 0.5 is now available, with the following changes (and more!):
WP_JSON_Posts class. When implementing custom post type support, it’s recommended to subclass this.
The various types are now also only registered via hooks, rather than directly in the server class, which should make it easier to override them as well (#348)
view or edit) (#328).X-WP-Total and X-WP-TotalPages headers for information on post/pagination counts (#266)As always, the full changes are available if you’re interested.
This week finally brings media into the fold. The process for uploading media is a little different to creating normal posts, so here’s how you do it.
First, upload the file via a POST request to /media. This can either be as a standard HTTP multipart body, with the name field set to file, or as a raw file in the body with the Content-Type header. (You can also optionally send a Content-MD5 header if you’d like the server to check the consistency of your file.) This will give you a 201 Created status, and point you to the new resource. You can now update that resource with the correct post data.
This multistep procedure is required to enable raw file uploads, and I’m not entirely pleased with it, but it’s the only way without requiring multipart requests. I’d love to have feedback on this system, as I think practical use will eventually reveal the correct method here.
So, it’s time to start winding up the Summer of Code portion of the project. There’s still one week left for the Summer of Code project, so you may still see a release next week, but most likely in the form of smaller updates, especially with documentation and testing. As I finish up, it’s time to look forward to the future of the project. The plan is to form a Feature as a Plugin team as we work towards core integration in future releases. People have already volunteered for the team back in the 3.8 scoping days, and I’ll be getting in contact with them shortly, but it’s not too late to nominate yourself for the team; let me know if you’re interested.
Thanks to everyone for testing and for your feedback. Stay beautiful.
I’d make HTTP multipart the default upload method (if not the only one).
From my testing at http://make.wordpress.org/mobile/2013/06/06/xml-rpc-memory-improvements/#comment-17413, PHP doesn’t handle non-multipart uploads very well, memory-wise.
s/default/preferred/
That was my feeling too, but multipart is harder for clients to use, so I’m conflicted. Interesting that even streaming from php://input still appears to use large amounts of memory; thanks for the thoughts.
Do you have any documentation out for the API this provides?
Check out the files at https://github.com/rmccue/WP-API/tree/master/docs
My bad, probably should have checked out the repo first… Thanks Ryan!
There will be a weekly office hours meeting on Wednesday, September 11, 2013 at 18:00 UTC in #wordpress-dev. Agenda includes status update on the hooks initiative that kicked off last week, and answering questions anyone may have about the effort.
If you’re interested in participating, please plan on attending.
I just released version 1.0 of the Post By Email plugin, which includes the following updates:
I also made some changes to the Core patch and added it to the corresponding Trac ticket for community review.
Please do install and test this version and let me know how it goes!
This plugin is in beta; the usual caveats apply. Please be sure to back up your data and/or run this against a test email account.
As always, you can download the plugin from the official repository or from the Github mirror.
turns out, the New York Times newsroom has a lot of interest in this feature – we’ll probably take a look at this soon
Where do you want to receive bug reports? The plugin just downloaded and created posts from 500+ read emails from an account (creating 500+ duplicate posts) while the old core functionality would only create posts from unread emails?
Yikes! Here is fine, there’s also the support forum on the plugin repo and the Github issues page.
Are you using POP3 or IMAP? The old functionality worked only with POP3, which doesn’t have a notion of “unread”. So it would post everything in the inbox (read or unread), and then delete all messages afterwards. This is still how POP3 works; if you connect via IMAP, it should post only unread messages.
Note also that if you connect via POP3 and tell it not to delete messages, it will post duplicates every time it checks mail (once per hour). The settings page is confusing in that regard — it really shouldn’t allow you to select that option unless you’re using IMAP.
I was using the core system before. I enabled the plugin and used the same mailbox but specified IMAP instead of POP3. It found all the old, already imported emails. This is using a Gmail account.
So, that’s odd for two reasons:
1) There should not BE any “old, already imported emails”. The existing Core functionality imports and then deletes all messages from the inbox. It doesn’t do any kind of tracking of which messages have already been seen/imported. You’re definitely migrating from Core and not a plugin like Postie?
2) With IMAP it should definitely be using the SEEN flag to only load up unread emails.
Ohhhh… I may have just figured this out, at least partially. It would’ve imported your existing settings on plugin activation, and checked for new mail right away using those settings (so one check via POP3) before you changed the settings to use IMAP. Then if you checked again after changing the settings, IMAP would’ve just gotten the unread messages — which explains there being two posts for each of the new messages.
But that still doesn’t explain why there were a bunch of messages in the inbox that had already been imported.
So, thinking about this, I don’t think it’s actually possible you were using the old functionality with a Gmail account, because Gmail requires a secure IMAP connection — the Core functionality only supported non-SSL POP3. That being said, I’d love to figure out how to better support migration from your setup.
I think one thing I’ll do is add a delay after activation that forces the user to verify the plugin settings before it does a mailbox check for the first time. Obviously doing a straight migration isn’t going to work in all cases.
Where do you want to receive bug reports? The plugin just downloaded and created posts from 500+ read emails from an account (creating 500+ duplicate posts) while the old core functionality would only create posts from unread emails?
It also created 2 posts for each new (unread) email. Could the core functionality still be active as well?
(Duplicate comment, sorry. Comment form was misbehaving.)
Did you patch Core? Otherwise, yes, the old wp-mail.php would still run. Also look at the log in the Settings and see how many times it actually checked — if it checked the mailbox twice, that could explain the duplicates.
Thanks for helping me test this out!
I think you could have the plugin disable the core checking by using the `enable_post_by_email_configuration` filter.
Well, it’s a bit more complicated than that, because the (unpatched) wp-mail.php checks that filter BEFORE doing the “wp-mail.php” action. So if the plugin returned false for that filter, it would also disable the ability to trigger a manual check by hitting /wp-mail.php.
My first thought is that, when you activate the plugin, it should delete the global options — then Core wouldn’t have anything to do even if it was called. But that’s a non-reversible change (unless deactivating the plugin saved the options back to the global scope, which doesn’t really make sense in most cases).
The post creation from HTML emails is a welcome new feature though. 
As discussed in the weekly developer meeting, core contributors need to select a representative for the WordPress “team reps.”
There should ideally be two reps: a primary and a secondary/backup.
Primary duties are to post an update weekly on make/updates mentioning what we’re up to (you know, building core), and to meet monthly in IRC with the representatives from other teams (only one of the two reps need to attend). I would look through that blog to get an idea of expectations, and also the minutes from last month’s meeting.
Sometimes other teams will be working on something that affects core (or core should know about it), at which point you are in a perfect position to make sure communication lines are open. Thus, anything that comes up in updates or meetings that other core developers need to know about or act on should be communicated back to the rest of the contributors. This would occur ostensibly during the weekly core dev IRC meeting, or potentially posting to make/core (this blog) for feedback as necessary.
Qualities needed: knowledge of core and core development processes; dedication to following Trac, commit activity, IRC meetings, and make/core; strong communication skills; and an excess of patience.
A rep will serve for three months. After three months, they should be in a position to help pick someone to succeed them, probably in the form of nominating a few people to the group. We should be able to keep this pretty chill; this isn’t meant to be something that requires a board of election supervisors.
The current reps are me and Mike Schroder (@DH-Shredder). Mike and I would not mind continuing our duties, if only because we like to test our own patience/sanity. But we are also happy to step back if someone else wants to step up.
So, to nominate yourself or someone else, please fill out this very simple survey by the end of day Friday (today).
Nacin: As release lead this cycle, you can’t be team rep this time, remember?
Note to all: This time around we are only doing one rep per team, not two. A backup is good, but can change as needed.
It’s unanimous: @DH-Shredder is going to be core’s team rep for the next few months.
Thanks much!
Hi core team! Checking in on the team rep situation — just waiting on core team to pick one for the next three months before getting all the other teams going with theirs (their new ones, I mean; everyone else already chose). It’s been a couple weeks, so would like to get this wrapped up today if possible. I asked Jaquith in -dev just now about the result of the meeting yesterday, and he said: “I believe we were going to let people volunteer themselves or others.nominate, decide, soon.”
If that’s already underway, great, and please let me know later today who you all decided on.
If it’s not really a priority bc core development is taking up all the prioritized brain activity, may I suggest @dh-shredder? When Scribu bowed out last time, we all agreed for Shredder to replace him, but though I talked to him about it at WC San Diego and then posted his name on the team reps page on the make/updates blog, I apparently forgot to post a formal announcement. So if no one is feeling an urgent desire to step up and write weekly updates and relay news back and forth, maybe Shredder would be willing to take the 3-month term, formally this time?
Anyone you guys decide is fine, but please do decide today.
Thanks!
Nacin let me know he’s putting together a poll based on yesterday’s dev chat. Sorry for any confusion… when I asked this morning it sounded like it hadn’t gotten that far and I was hoping to speed things up. I’ll follow up with nacin tomorrow for poll results. Thanks!
The time to document ALL THE HOOKS used throughout core is nigh.
We’ve hashed out the process in a couple of different meetings in #wordpress-dev, and we’ve added a new leaf to the Core Contributor Handbook that covers the broader PHPDoc standards, as well as the specific hook documentation standards (the praise for the bulk of that work should go to Kim Parsell and Drew Jaynes, by the way).
our process for getting patches in hasn’t yet been proven, but we’re going to give it a shot here. If it proves to be unwieldy, we’ll try a different direction, and I’ll update this post. Until then, here’s how we’re going to go about everything:
At the bottom is a list of every file in core that has a call to either do_action() or apply_filters(). Files with a checkmark have been patched and are considered completed. Directly below is the process we’re attempting to make sure each of these files can get patched swiftly — with no duplicated nor wasted efforts.
*Note: We strongly encourage you to work on very few files at a time. In many cases, one at a time is probably best. In some cases it may make sense to tackle several at once. The important thing is that you realize your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch. It’s also important to note that we’re working with a small time-table, and need to be able to claim, edit, patch quickly — which is hard to do if someone were to lay claim to 20 files at a time, and then sit on them for a few days.
You can use svn blame and walk back through the history of a file to determine when any given hook was introduced. This can be fairly time-consuming, as you’ll have to compare which patch introduced the change with the date it was added via Trac, then use the date to determine which major release directly followed. We don’t want this to be a barrier for getting docs in, so please feel free to use “@since Unknown” to submit your patch, and someone more interested in tracing svn blame can add the version number later.
Any discussion about the specifics of a patch itself should happen on Trac, like it always does. Any discussion about the broader scope of what we’re trying to do should take place here on the make/core P2.
186 files total
To kick things of, I’m going to lay claim to these 3 files, because I’ve already started in them:
wp-comments-post.php
async-upload.php
wp-admin/wp-signup.php
Look for patches in the morning
I’ll grab: xmlrpc.php
I should be able to look at it tomorrow.
patch submitted.
Already started on wp-admin/includes/ajax-actions.php
My first time contributing and I started with wp-admin/admin-footer.php.
Excellent!
I also grabbed wp-admin/index.php.
Patch submitted
I’ll take wp-trackback.php, though there’s only one action in it. Might grab another after I finish that one.
I’ll take wp-admin/includes/taxonomy.php unless someone else feels possessive about it.
I will take the following to start and I’ll probably grab more later
wp-admin/comment.php (1 hook)
wp-admin/custom-background.php (2)
wp-admin/custom-header.php (6)
wp-admin/comment.php -> patch submitted
wp-admin/custom-background.php -> Patch Submitted
Since I’ve grown fond of it recently, I’ll grab wp-includes/nav-menu-template.php
Patch submitted, questions submitted too.
I’ll also take wp-includes/post.php
Hi Brian, I have a couple of questions that popped while I was documenting filters and I was hoping you could help clear things up for me so that I’m doing this right the first time around.
First, I’ve run into a couple of filters that pass an arrays as parameter. One of them has an array of arguments, which means, according to the standards for Actions and Filters, that I should document each argument in that array. But when looking at the other standards, specifically the section titled “Parameters That Are Arrays”, I shouldn’t document all the arguments and instead use the @see tag. Am I right to type the following then? `@param array $args Arguments from {@see wp_nav_menu()}.`
The second array isn’t an array of arguments, but just a list of string keys with string values. To me, it kind of makes sense to document the initial keys, but since I’m new to this I wanted to ask what you believe we should be doing? For an example, see http://core.trac.wordpress.org/browser/trunk/src/wp-includes/nav-menu-template.php#L89
And my last question: Usually the parameters used in actions and hooks are standard variables (i.e. $bar), but sometimes the parameters are fields from an object (i.e. $foo->bar), in that case. How should we document the latter? @param type $foo->bar…?
Thanks for any help! As a casual plugin developer I am very excited about this initiative and the opportunity to contribute!
Would it be a good idea to use http://adambrown.info/p/wp_hooks to figure out when the hook was first created?
I’ll work on wp-includes/author-template.php.
Patch submitted for wp-includes/author-template.php
I’ll work on wp-includes/author-template.php
Patch submitted for wp-includes/wp-db.php.
Patch submitted for wp-includes/theme-compat/comments.php and wp-includes/theme-compat/comments-popup.php.
Patch submitted for wp-includes/rss.php.
Grabbing wp-admin/user-new.php
I’ll take wp-includes/http.php and wp-includes/class-http.php as they seem to be coupled well.
I’ll work on wp-admin/includes/ms.php
Patch submitted for wp-admin/includes/ms.php
I have aslo same problem so I’ve run into a couple of filters that pass an arrays as parameter. One of them has an array of arguments, which means, according to the standards for Actions and Filters, that I should document each argument in that array@ http://onaplioa.com.vn
First time contributing and I will take wp-admin/ms-delete-site.php
Patch Submitted for wp-admin/ms-delete-site.php.
Relinquishing class-http.php as I realized parts were over my head. However, http.php is done.
Hey. Can I take wp-admin/options.php?
options.php submitted.
working on wp-activate.php
wp-activate.php patch submitted.
working wp-admin/admin-ajax.php
wp-admin/admin-ajax.php patch submitted.
@Brian and others, I read the standard for DocBlock headers and saw that @subpackage was included. I am not sure if you are aware, but @subpackage is deprecated, so you might not want to create a bunch of documentation on a tag that will one day not exist. More info here: http://www.phpdoc.org/docs/latest/for-users/phpdoc/tags/subpackage.html
Joshua, please read the preface to the Deprecated Tags section.
I’ll take wp-includes/shortcodes.php
patch submitted
I’ll take /wp-admin/includes/revision.php, wp-includes/revision.php and if I can get to it
/wp-admin/ajax-actions.php
Are we documenting JavaScript files? Whats the standard? Will review /wp-admin/js/revisions.js if we have a spec!
Adam: The hooks initiative only covers the PHP files listed above. There is a separate initiative to provide similar documentation for JavaScript files, but the standard hasn’t been written yet for the handbook.
Working on wp-admin/options-writing.php.
Submitted.
I’m claiming wp-admin/includes/nav-menu.php.
Patch submitted for wp-admin/includes/comment.php: http://core.trac.wordpress.org/ticket/25229#comment:48
I’m grabbing wp-admin/export.php
Editing wp-admin/includes/plugin-install.php and wp-admin/plugin-install.php — patches will be submitted on Sunday
Patches submitted.
Working through the media files. Claiming media-upload.php
Wait a sec.. is media-upload.php even USED anymore? I deleted ALL code in that file and then went to upload something and it WORKED.D’oh. Relinquishing that claim until I get my head out of my arse.
At the same time, calling dibs on and saying I submitted the patch for wp-admin/canonical.php
correction on my typo: wp-includes/canonical.php
Also Taking wp-includes/post-thumbnail-template.php
Submitted patches for the following:
wp-includes/feed-rss.php
wp-includes/feed-rss2.php
wp-includes/feed-atom.php
wp-includes/feed-rss2-comments.php
wp-includes/feed-atom-comments.php
wp-includes/feed-rdf.php
Grabbed wp-links-opml.php
Patch submitted: http://core.trac.wordpress.org/ticket/25229#comment:61
Grabbing wp-includes/load.php
Today’s #wordpress-dev developer meeting (20:00 UTC) should be fairly brief. Let’s do a quick status report on different 3.7 tasks and then hammer on any Trac tickets (especially complex ones or ones that need a decision, since many core developers will be present).
Please suggest any items for discussion, or any tickets we should consider.
After this meeting, at 21:00 UTC, will be a 3.8 office hours meeting (like last week) in #wordpress-core-plugins in IRC.
I’d like to get an enhancement for `wp_slash()` off my list, please: #24106
It’s been a while since you’ve all heard from me, so I wanted to check in and assure you I am still alive. I’ve been plodding along behind the scenes with the JSON API and mostly getting design documents sorted.
The big feature I’m working on at the moment – media – has turned out to be tricker than I initially thought. While media is technically handled via custom post types, it’s a completely different kettle of fish to normal post types, so I’ve been working through the conceptual issues behind this to ensure that the API stays consistent both internally and externally. I really believe that it’s worth my time to sit down and consider these conceptual issues in depth rather than pumping out the feature as soon as possible. (The implementation of the media-related endpoints is working locally, but I don’t want to push this up while it’s still in flux.)
I still hold out hope to push through media, but will likely reduce the scope of the other tasks to compensate, due to the complexity of media and the time it has taken so far. I’d like to personally apologise for this, this is a result of improper scheduling for the second half of the project.
Personally, the past month or so has been pretty stressful as well, due to a number of other things going on in the background. Balancing this project with university work has become a big issue recently, so I’m working through this as best as I can. Ideally, my preferred option at this point would be to push this project out of the Summer of Code phase and into the open source team phase rather than continuing to work on the project in isolation.
Along those lines, revisions will be bumped from the Summer of Code phase completely. While they are part of core functionality, they’re a rather large task that is secondary in importance to media and also behind taxonomy handling. I’d love to see these in the plugin at some point, but that won’t be happening during the Summer of Code phase. What I would love is for someone to volunteer to develop this (in a separate plugin for now, thanks to GSoC’s restrictions) for integration back in as soon as possible, which would also help with validating the API’s usefulness.
So again, sorry and hopefully I’ll have something better to show you next week. Thanks for your patience.
Feel free to email me, cio [at] rawvoice dot com, I can lend a lot of knowledge on the media side of things.
It’s been awhile since you’ve heard from any of us about the inline-docs initiative for 3.7. We’ve been getting our ducks in a row, so to speak, and we’d like to start pounding pavement this week.
We’re going to hold an office-hours meeting on Wednesday, September 4 at 18:00 UTC in #wordpress-dev. We’ll review where we left off last meeting, cover the details on how we want to proceed, and make sure the details about getting involved really do show up here on Make/Core.
This meeting is mostly to help us on the planning team make sure we’re on the same page, but all are welcome. As I said, the next action steps for interested parties will get posted back here.
Thanks, too, for all of the encouragement around this. We’re pretty excited about it!
Ryan McCue 1:37 am on September 14, 2013 Permalink | Log in to Reply
For anyone who’s wondering what the hell is going on on Windows: You have to run grunt via the Windows command line, and you cannot run it via Cygwin. If you do run it via Cygwin, you’ll see random inexplicable errors and missing output. It’s pretty annoying (in fact, it stops me from using Grunt), but you can’t really do anything about it.
Aaron Jorbin 4:31 am on September 14, 2013 Permalink | Log in to Reply
Sorry to here about the problems on Windows. According to Grunt’s FAQ, the problem is that Cygwin bundles an outdated version of node.js. Have you tried the suggestion to install node and npm separately and then use either Windows command prompt or PowerShell ?
Ryan McCue 10:48 am on September 14, 2013 Permalink | Log in to Reply
It’s actually a platform-limitation of Cygwin. You can work around it with
cygstart grunt ..., but it opens in a new window and doesn’t work with the current shell: http://code.google.com/p/mintty/issues/detail?id=56adamsilverstein 6:17 pm on September 14, 2013 Permalink | Log in to Reply
Great post, thanks for keeping this moving!
K.Adam White 5:50 pm on September 16, 2013 Permalink | Log in to Reply
For those on Windows, the “msys” shell that installs as “Git Bash” when you download the official Windows build of Git should work fine once you install the Windows build of Node.