WordPress.org

Make WordPress Core

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 3:27 am on September 6, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Team rep nomination/vote 

    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).

     

    • Jen Mylo 4:18 pm on September 6, 2013 Permalink | Log in to Reply

      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.

  • Kat Hagan 8:44 am on September 6, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Post By Email Plugin: Version 1.0 is live! 

    I just released version 1.0 of the Post By Email plugin, which includes the following updates:

    • Support for IMAP and SSL connections
    • Option to “mark as read” instead of deleting messages after posting them (IMAP only)
    • Only fetch unread messages (IMAP only)
    • Added contextual help to the admin panel
    • Support for HTML-formatted emails
    • Under the hood: refactoring, bugfixes, properly checking nonce for AJAX requests, etc.

    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.

     

    • Scott Taylor 3:33 pm on September 6, 2013 Permalink | Log in to Reply

      turns out, the New York Times newsroom has a lot of interest in this feature – we’ll probably take a look at this soon

  • Alex King 5:25 pm on September 6, 2013 Permalink | Log in to Reply

    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?

    • Kat Hagan 6:54 pm on September 6, 2013 Permalink | Log in to Reply

      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.

      • Alex King 10:33 pm on September 6, 2013 Permalink | Log in to Reply

        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.

        • Kat Hagan 10:43 pm on September 6, 2013 Permalink | Log in to Reply

          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.

  • Alex King 5:26 pm on September 6, 2013 Permalink | Log in to Reply

    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?

  • Alex King 5:29 pm on September 6, 2013 Permalink | Log in to Reply

    It also created 2 posts for each new (unread) email. Could the core functionality still be active as well?

    • Kat Hagan 6:51 pm on September 6, 2013 Permalink | Log in to Reply

      (Duplicate comment, sorry. Comment form was misbehaving.)

    • Kat Hagan 6:56 pm on September 6, 2013 Permalink | Log in to Reply

      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!

      • Alex King 10:32 pm on September 6, 2013 Permalink | Log in to Reply

        I think you could have the plugin disable the core checking by using the `enable_post_by_email_configuration` filter.

        • Kat Hagan 10:39 pm on September 6, 2013 Permalink | Log in to Reply

          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).

  • Alex King 5:35 pm on September 6, 2013 Permalink | Log in to Reply

    The post creation from HTML emails is a welcome new feature though. :)

  • Jen Mylo 5:26 pm on September 5, 2013 Permalink | Log in to leave a Comment
    Tags:   

    Team Rep 

    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!

     

    • Jen Mylo 6:52 pm on September 5, 2013 Permalink | Log in to Reply

      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!

  • Brian Richards 1:53 am on September 5, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Add Inline-Docs for Hooks 

    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.

    How to contribute:

    1. Leave a comment on this post with the file(s)* you’re about to edit (check the comments first to make sure it’s not already being edited)
    2. Edit fervently and make a patch quickly
    3. Submit your patch to the Add Inline Docs for Hooks trac ticket
    4. Update your comment here to say patch submitted
    5. Rinse and repeat!

    *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.

    Determining the @since version for hooks

    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.

    Keeping Discussions Focused:

    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.

    Files needing patches: (checked files are completed)

    186 files total

     

  • Andrew Nacin 5:37 pm on September 4, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    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.

     

  • Ryan McCue 2:20 pm on September 4, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    JSON REST API: Coming Soon 

    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.

     

  • Brian Richards 2:21 am on September 4, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    3.7 Inline Docs Office-Hours Meeting 

    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!

     

  • Lance Willett 7:49 pm on September 3, 2013 Permalink | Log in to leave a Comment
    Tags: , ,   

    We’ve made lots of great progress over in Twenty Fourteen theme land.

    This update is long because it’s my first one since we kicked off. Subsequent reports will be shorter.

    Goals

    In short, make it an awesome default theme.

    1. Polish, “break”, and perfect the theme.
    2. Add enhancements and new features.
    3. Integrate with 3.8 plugin projects as we can.

    Who we are

    (These are WP.org usernames.)

    • Leads: lancewillett, obenland, and iamtakashi
    • Many patches have come in! Thanks to: cainm, celloexpressions, DrewAPicture, eherman24, Frank Klein, georgestephanis, iamtakashi, Jayjdk, jeherve, joedolson, Jonnyauk, kovshenin, Kuzmanov, MikeHansenMe, nofearinc, obenland, rickalee, sabreuse, and SergeyBiryukov.
    • Many other contributors have joined the fun, including but not limited to: cfinke, chellycat, jazzs3quence, johnbillion, karmatosed, McGuive7, nacin, nhuja, paolal, RDall, rmccue, taupecat, trishasalas, and shaunandrews.

    You can get still get involved in any of these activities:

    • Putting up new tickets for bugs or enhancements (plus a patch if you can).
    • Review and test patches on existing tickets, add comments to the ticket.
    • Join the 3.8 plugin projects like Featured Content.
    • Help with theme breaking: IE, RTL, accessibility.

    Big things we’re working on now

    So far we’ve seen 38 related tickets in Trac opened, closing 24 already. View all open tickets.

    • (Possible) removal of Custom Header Image support: #25094
    • Accessibility review and fixes: #25054
    • Adding a “Contributor” page: #24863
    • Allowing color customization for “accents”: #25220

    The removal of the header image, along with which customization options to allow and support, has been a very healthy discussion. See #25094 if you want to read along.

    Big things we’ve already tackled

    • Updating to use HTML5 markup from core for search, comment form, and comment list.
    • Added missing archive templates.
    • Many usability fixes.
    • Lots of code cleanup.
    • Added Editor Styles to enhance the visual editor.
    • Sidebar improvements: widgetizing special Post Formats display, making right sidebar optional, and more.

    One thing I wanted to highlight was removing the Social Links options from the theme. Instead inserting the search form and the search form toggle through filterable template tags, so that a plugin could hook in and add that feature back in. (Full chat log.)

    Related plugin projects

    Work continues on Featured Content and the Authors widget: #24856.

    Office hours and Trac triage

    We’ve had regular and very productive office hours on Tuesdays and Thursday at 17 UTC (In your time zone: 17:00 UTC). Thanks to everyone who’s joined us, your input is very valuable.

     

  • George Stephanis 4:00 pm on August 30, 2013 Permalink | Log in to leave a Comment
    Tags: , Features as Plugins, Omnisearch   

    Omnisearch! 

    Howdy, folks!

    Terribly sorry for the delay, but I’m pleased to announce that Omnisearch will be meeting Fridays at 5pm Eastern Time, 21:00 UTC, Thursdays at 6pm Eastern Time, 22:00 UTC, in #wordpress-core-plugins on freenode. Happy to adjust it later, if that’s too early or late for folks in other timezones.

    —

    Omnisearch is a central search form, meant to simplify the process of finding what you’re after. It is designed only for the WordPress Admin Interface — not the front end.

    By default, it searches Posts, Pages, Media, Comments, and the Plugins Directory. However, it’s easy to hook into, and provide custom results from third-party modules, such as Grunion Contact Form in Jetpack.

    Omnisearch has been living in Jetpack for a few months now, and has gotten mostly positive reviews. The only complaints that I’ve heard were that it doesn’t search media (which has since been added), the relevance isn’t always ideal (it just uses the default search that happens when you use the existing search form on the posts page or the like), and some coming from a misunderstanding where they were expecting it to be on the front-end of the site — not merely an admin tool.

    —

    Interested parties include @japh, with @lessbloat helping to design some user testing to determine its usefulness as a part of core.

    If interested, you can install it yourself here, which will override the version in Jetpack if you happen to have that installed [ I made sure to only include the Jetpack one if ( ! class_exists( 'WP_Omnisearch' ) ) ] :

    http://wordpress.org/plugins/omnisearch/

     

    • George Stephanis 9:23 pm on August 30, 2013 Permalink | Log in to Reply

      First meeting was just @lessbloat and myself, discussing how to properly test.

      It looks like the plan is going to be to get a dummy install together with a large set of sample data, and deliver some tasks to find content. Some will be directed at finding media, some may be directed at finding a specific post or comment, and some may be at finding a snippet of text with no context as to where it may be.

      Once done, we’ll see which completion paths the user tried to take to accomplish the tasks.

      Then we’ll test again, but with Omnisearch available. Probably with some subtle hints to it, but certainly not enough to spell out exactly how they do it. I’d like to add in a couple new ways to access Omnisearch, such as a dashboard widget, and see which paths (admin bar search, menu item, dashboard widget, or other) the users use to get there. If there is a clear preference to one over another, let’s make sure it’s available in the final result.

      For now, I’ll be getting the content ready to import into a dummy site to test with early next week, around Tuesday-ish. We should have some data and results next week.

  • Kat Hagan 7:27 am on August 30, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Post By Email weekly update 

    This week, I finally released the Post By Email plugin into the official repository, which inspired me to do a lot of incidental cleanup (readme files, test instructions, etc.).

    I finished updating the Core deprecation patch for 3.7 — it’s in the plugin repo and will be submitted back to Trac once my mentors get a chance to review it.  (Comments and feedback welcome!)

    I also powered through the remaining infrastructure tasks.  The latest version is 0.9.9 (look how close that is to 1.0!  SO CLOSE) and includes the following:

    • Improved error and status logging
    • Scheduled mail checks via wp_cron
    • Prettified settings page (with stuff like consistent date/time display)
    • Autoloading of Horde library files (HT to ryanmccue for the example)

    If you happen to have access to an unsecured POP3 mail server and want to test this and see what breaks, I’d love to hear about it.  (Be sure to patch Core with the deprecation patch first to avoid weird behavior.)

    The 1.0 release will include IMAP and SSL, at which point I will start requesting beta testers in earnest.

    I just spent the last few hours tracking down a bug in my clear_log function, which turned out to be caused by the Settings API validation function being triggered when an AJAX function (called from the settings page, but not with a form submit) called update_option.  I worked around that, but haven’t yet figured out why it’s happening at all — any insights would be appreciated.

     

    • pescadito01 7:51 am on August 30, 2013 Permalink | Log in to Reply

      Nice!
      Can i apply as 1.0 beta tester?
      Best Regards, Pescadito

    • Konstantin Kovshenin 9:14 am on August 30, 2013 Permalink | Log in to Reply

      Oh hey there!

      The thing is that once you register_setting with a sanitize_callback argument, WordPress adds a filter on sanitize_option_{$option_name} which runs every time an option is updated, via an admin page, or front end, or XML-RPC, etc., or as in your case – an AJAX handler. This means that your post_by_email_validate will run every time update_option runs, regardless of the context.

      Your hack during the validate function:

      $options['log'] = $input['log'];

      I haven’t tested it, but it looks like somebody can easily write anything to that log by hi-jacking the settings form. I may be wrong though.. In any case, taking the log out of the main options array may be a better idea, since you don’t want to autoload it on every request anyway – logs can get big over time. Also note that logging in that fashion can cause some race conditions because of the way the object cache works with options.

      I don’t know what your end goal with logging is, but I’d suggest looking at PHP’s error_log which can easily be written to wp-content/debug.log in WordPress.

      Hope that helps!

      • Kat Hagan 4:46 pm on August 30, 2013 Permalink | Log in to Reply

        That’s exactly what I was missing, thanks!!! I knew the hack was terrible but I honestly just needed to check something in last night so I could write this post. :P

        The log originally started out as a separate option, but George recommended adding it in to the main settings array in an earlier code review. Maybe he can weigh in on this?

        The log is meant to be user-facing (i.e. not just for debugging) — it’s a record of any errors that occurred but also status messages (like “Got 3 emails” or “No emails found” or whatever). So I’m not sure using error_log for that makes sense.

        • George Stephanis 11:14 pm on August 30, 2013 Permalink | Log in to Reply

          Now I’m rethinking myself. As you’re not going to load the log on 99%+ of page views, it’d probably be better as a seperate option with autoload turned off. Save some bandwidth between the db server and wp, as well as avoid loading it all into memory.

    • Jen Mylo 2:26 pm on August 30, 2013 Permalink | Log in to Reply

      The deprecation patch should be put on a trac ticket for community review rather than in the plugin repo (which I see isn’t really “the plugin repo” but your own github repo where your’e doing the work). Can you put it on a trac ticket? Thanks.

      • Kat Hagan 4:41 pm on August 30, 2013 Permalink | Log in to Reply

        Hi Jen, I didn’t really want to put the patch back into Trac until Justin and George got a chance to look it over, as I’m pretty sure there are changes that will need to be made. I’m hoping they’ll have a chance to review before our next meeting on Tuesday.

        The Github repo is actually a mirror of both the plugin repo and the GSoC repo, so, yes, it’s in the plugin repo too. :)

    • ← Older posts

    c
    compose new post
    j
    next post/next comment
    k
    previous post/previous comment
    r
    reply
    e
    edit
    o
    show/hide comments
    t
    go to top
    l
    go to login
    h
    show/hide help
    shift + esc
    cancel