Make WordPress Core

Tagged: weekly-update Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 1:53 pm on September 15, 2016 Permalink
    Tags: , , weekly-update   

    Media Weekly Update (September 9) 

    This post summarizes the most recent media meeting, which takes places weekly in #core-images on Slack.

    Our next meeting is Friday, September 16 at 19:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

    It was brought up that the current meeting time is not great for @swissspidy or @flixos90, and they’d prefer to meet earlier, which we would start next week at Friday, September 23 at 17:00 UTC or alternatively on Thursday, September 22 at 17:00 UTC. Please sound off in the comments as to whether you’d be able to make either of the above to help decide on whether the meeting time will change.

    Agenda for the next meeting

    This week, we will check in on the priority projects for the 4.7 release. If you have specific tickets that you’d like to have discussed, please leave a comment on this post or reach out on Slack in the #core-images channel.

    Recap of the last meeting

    Our last meeting was Friday, September 9. You can read the conversation log in #core-images on Slack.

    Attendees: @mikeschroder, @markoheijnen, @flixos90, @adamsilverstein, @swissspidy, @paaljoachim, and @achbed.

    Media library organization improvements

    • @joemcgill and @swissspidy are working on adding the ability to search the media library by filename (#22744).
    • Following the meeting, @joemcgill posted some great notes on his thoughts regarding process for forming a roadmap for these improvements. You can read them on Slack.
    • Separately, we would like to engage members of the design team in initial conversations about what UI/UX improvements can be made to the media library to make it easier for people to organize and find their media. It’s likely that any UI changes in 4.7 would be relatively light, but we want to begin planning now and focus work during this release on getting as much infrastructure in place as we can.

    Improved full size image optimizations (#37840)

    Good conversation around ways to solve or work around the issue of increased CPU time/HTTP failures for image resizing.

    • Proposed closing #36534, and creating tickets from the issues found. It was great for gathering information, but has become a dropbox for all HTTP Error related tickets.
    • This is related closely to the full size image task because we want to avoid making the timeout issue worse when adding another resize.
    • In addition to running additional profiling to find what’s now taking the most time, one thing @joemcgill and @mikeschroder discussed in particular is a “try again” or “continue” button as a first jump into making it easier to recover when these failures happen. At the moment, this isn’t a thing because WP only saves meta after creating all sizes is completed successfully, and also because the code doesn’t support creating “the sizes that are left” (related: #15311).
    • @mikeschroder would also like to see investigation into making the HTTP Error more specific, but this could be part of the above project or solved without users needing to know the details, when WP can recover by itself.

    Core Media Widget (#32417)

    No Update. Reached out to @designsimply and @fab1en.

    HTTPS fixes

    No Update. Reached out to @johnbillion to see what plans are for 4.7.

    PDF Thumbnails (#31050)

    No time last week due to travel. @markoheijnen to send update this week.

    Accents in attachment filenames should be sanitized (#22363)

    @gitlost provided great feedback on the ticket (thanks!), but it looks like it’s going to need additional work before an initial commit.
    @mikeschroder looking into this with @markoheijnen at WC Tokyo this week.

  • Kat Hagan 1:47 pm on September 23, 2013 Permalink
    Tags: , weekly-update   

    Post By Email: OPW is over! 

    I can hardly believe it, but my summer internship is drawing to a close.

    This week, I released version 1.0.4 of the Post By Email plugin, comprised of minor bugfixes, tests, and documentation as I prepped the project for its evaluation phase.  I’ve added quite a bit of info to the readme page, including better installation and configuration instructions.

    Those of you following along on Trac may have noticed that I’ve kind of run out of tasks.  🙂

    Today is the official end of the OPW and GSoC programs, so I’ll be taking a short break from development work during the evaluation period.  But this isn’t goodbye!  I definitely plan to stick around and continue working on and supporting this project in the future — so keep those bug reports coming!

    I do want to take a second to thank all of you for being here for me as I learned the ins and outs of WordPress this summer.  I feel really good about where this project landed, and I know it’s because I had so many amazing resources every step of the way.  So, to everyone who left me comments, answered my questions on IRC or Twitter, reviewed my code, tested, reported bugs, offered suggestions, spoke at WCSF, or even just edited a Codex page or wrote a quick tutorial now and then: THANK YOU.  It really made the difference in those moments when I felt frustrated or overwhelmed.

    I don’t know exactly what the future holds, but I do know that I love being a part of WordPress, and I’m excited to continue working with y’all.  Let’s keep in touch.  🙂

  • Alex 10:02 pm on September 17, 2013 Permalink
    Tags: , weekly-update   

    Code Revisions: Last Week 

    The code revisions plugin reached version 0.95 – just leaving enough space for some final readme updates and hopefully no more bugfixes (because of no more bugs).

    But still, some final important enhancements got into this update. Mainly to ensure that all related revision data is removed when a package (theme or plugin) is uninstalled (#395).

    Last week now is about creating a screencast for you, the community and wrap up the documentation.

  • Kat Hagan 8:44 am on September 6, 2013 Permalink
    Tags: , weekly-update   

    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.

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

            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.

    • 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. 🙂

  • Kat Hagan 7:27 am on August 30, 2013 Permalink
    Tags: , weekly-update   

    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

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

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

  • Alex 11:49 pm on August 27, 2013 Permalink
    Tags: , weekly-update   

    Code Revisions: Week 10 

    First double-digit week. Most notable change this week: Code Revisions is now available in the plugin repository0.8 finally brings a uninstall automatism, fixes some bugs (#335, #351)  and cleans the code up (#325). The ticket list is actually getting quite short by now with primarily aesthetic stuff being left over.

    So I hope to get some people to test it now it’s in the repository. Maybe this will get me some more feedback to address in the weeks to come.

  • Kat Hagan 5:51 am on August 26, 2013 Permalink
    Tags: , , weekly-update   

    Post By Email: Roadmap for the final stretch 

    I met with my mentors this past week to hash out the spec for the final iteration of the Post By Email plugin.  It can be found here; I’m updating it as I finish tasks, as well as tracking them in the GSoC Trac.

    This week, I tested under PHP 5.2 and made a few small changes to the Horde library files to support both 5.2 and 5.3 (the Horde framework requires a minimum of 5.3).  I also refactored the admin-specific methods (adding menus and so on) into their own class, which is loaded only if is_admin().

    Of the original feature list, we’ve decided that supporting multisite is currently out of scope (though it may well work anyhow — it’s globally disabled in Core for a multisite install, but I can’t think of any reason to restrict it for the plugin).  Attachments and comment reply via email are on the “nice to have” list, meaning I might not get to them (at least, not before the official internship period ends).

  • Alex 6:00 pm on August 21, 2013 Permalink
    Tags: , weekly-update   

    Code Revisions: Week 9 

    Version 0.7 is tagged and I am planning to submit it to the WordPress.org plugin directory later today or tomorrow.


    Viewing code revisions now feels much more native: By default WordPress makes use of normalize_whitespace() before comparing two posts to one another. This results in loss of blank lines and missing multi-space indention as often seen in css files. I fixed this by plugging into the wp_text_diff() function (#302). Further more you now get the correct menu item expanded when viewing code revisions (#316).

    Besides those I am still struggeling with syntax checking (#335). Looks like I will be settling for just using ‘php -l’ if available. Problem there is I am still not able to get a reliable path to the php binary. Since PHP 5.4 there is the PHP_BINARY constant, so I need a way to get it manually in PHP versions lower than 5.4..

    • Aaron D. Campbell 6:20 pm on August 21, 2013 Permalink | Log in to Reply

      You might be able to try PHP_BINDIR and use the most common bin name (php or php.exe). If you really want to go out of your way, you could check the whole path for the binary using something like https://gist.github.com/aaroncampbell/6294506 but I don’t really think that’s necessary assuming that PHP_BINDIR is pretty common. Past that, just fail gracefully

    • Bryan Petty 6:36 pm on August 21, 2013 Permalink | Log in to Reply

      Yeah, I tend to agree with @aaroncampbell. Not so much worried about automatically finding it as much as just making it possible to manually define it within wp-config.php if necessary.

    • Andrew Nacin 6:48 pm on August 21, 2013 Permalink | Log in to Reply

      We seem to do okay without using the binary in terms of sandboxing plugins and showing any syntax errors.

  • Kat Hagan 5:42 am on August 16, 2013 Permalink
    Tags: , weekly-update   

    Post By Email: Getting back on track 

    It has sadly not been a very productive couple of weeks in Post By Email land — I’ve been struggling to balance conferences, travel, illness and other obligations, and ultimately hit that not-so-fun point of needing to take a few days off because the more work I tried to do, the less I was able to do.

    The good news is, I’m regrouping and made a few updates to the plugin — mostly minor fixes and code style cleanup.  This coming week, I’m planning to work with my mentors on the final roadmap of additional features that will be implemented between now and the end of September, so I will have that to share with you next week.

  • Alex 3:09 pm on August 13, 2013 Permalink
    Tags: , weekly-update   

    Code Revisions: Week 8 

    I skipped some weeks here; sorry for that. WordPress 3.6 was released and now there is quite some talk about 3.7 and 3.8 ongoing here – I really like the plugin approach! It actually is the same approach recommended to us GSoC students for the projects. Many features which can be put together by core developers when they team up might be essential to WordPress while maybe still not essential as part of core. This way WordPress development could get much more dynamic for the future.

    As of the discussion on my last post 0.6 the plugin now primarily uses php -l for syntax checking – if available. If not, I am still falling back to eval (#335).

    For the next weeks the plan is now to bring a more code-editor-like look to the code revision viewer: Show indention and lower the line spacing etc. This will need some not so pretty overwriting of pluggable functions because most spaces are stripped for diff-creation.

    Further more I will discuss releasing the plugin to the plugin repository with my mentors as preparation to final considerations if or if not this or part of this should get into core.

    • Ryan Bayne 3:27 pm on August 13, 2013 Permalink | Log in to Reply

      Great. Looking forward to the code editor improvement. While I’m still learning the core and the ways of WordPress. Things like that will make it just a little easier to take it all in and eventually contribute, eventually 🙂

    • Shea Bunge 9:40 pm on August 13, 2013 Permalink | Log in to Reply

      I recommend that you use CodeMirror for the code editor.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar