WordPress.org

Make WordPress Core

Search Results for: gallery Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:02 am on January 29, 2014 Permalink

    Gallery 

    20 open tickets. Last 7 days: +0 tickets

    20 open tickets defect (bug) enhancement feature request
    Awaiting Review 5 5 1
    Future Release 6 1 2
     
  • Gary Pendergast 11:17 pm on April 2, 2015 Permalink |
    Tags: , , ,   

    OMG EMOJI 😎 

    One of the fun bits of the utf8mb4 upgrade is that we can now store emoji! Once your site is upgraded to utf8mb4, it can natively store any emoji character. There were a couple of problems with that, though:

    • Some browsers don’t know how to render emoji 👎, or they have bugs in their implementation 😢. Notably, Chrome either doesn’t work or has bugs, older versions of IE don’t work, and Firefox has bugs.
    • Not all sites will be able to upgrade to utf8mb4, which means they’ll be unable to save emoji characters that they enter.

    Not being able to use emoji makes everyone a sad panda (😭🐼), so we need to fix this. There are a few moving parts of our emoji support, so lets go through them.

    utf8 backwards compatibility

    If a site can’t be upgraded to utf8mb4, we convert emoji to their HTML-encoded equivalent, and store that, instead. From a UI perspective, post editing works as expected 🎉. Because fields need to be white listed to support this, we don’t allow it everywhere – just post_title, post_content and post_excerpt. We also allow it in the site title and the site description.

    Browser support

    There’s a small compatibility check included on every page, both on the front end, and in the Dashboard. For those interested, this adds 1-4ms (⚡️-fast!) to the page render time – the aim was to keep this as low as possible, to avoid affecting your UX. If you notice a little chunk of compressed JS at the top your HTML, that’s probably it. If you’d like to check out how it works in a more readable format, have a look through wp-emoji-loader.js.

    Email ✉️ and RSS 📯 (There’s no RSS emoji, give me a break.)

    Of course, the JS shim won’t work in email and RSS. So, we replace all emoji with a static PNG version in those cases.

    TinyMCE 📝

    In addition to the browser support JS, there’s a TinyMCE plugin that handles keeping emoji looking good, while you type. It’s pretty magical.

    Taxonomies and URL slugs

    You can totally make taxonomies and URL slugs with emoji in them. Because we love you, and want you to be happy. 😀

    So, that’s about it. If you have any questions about the implementation, drop them in the comments below.

    💩

     
    • Scott Kingsley Clark 11:19 pm on April 2, 2015 Permalink | Log in to Reply

      Does this mean post type names / taxonomy names / option names / meta keys support emoji now?

    • Adam Silverstein 11:24 pm on April 2, 2015 Permalink | Log in to Reply

      👏

    • Lara Littlefield 11:38 pm on April 2, 2015 Permalink | Log in to Reply

      🙌

    • Mustafa Uysal 11:41 pm on April 2, 2015 Permalink | Log in to Reply

      👏

    • Stephen Edgar 11:56 pm on April 2, 2015 Permalink | Log in to Reply

      👯😊👊

    • bravokeyl 12:11 am on April 3, 2015 Permalink | Log in to Reply

      Emoji in URL’s , Cool 1F382

    • Ihor Vorotnov 12:30 am on April 3, 2015 Permalink | Log in to Reply

      omg, will there be a way to prevent upgrading and completely remove this compatibility check and that ‘little chunk of compressed javascript’ which is a thing Google does not tolerate?

      • Gary Pendergast 12:36 am on April 3, 2015 Permalink | Log in to Reply

        There’s a plugin to disable emoji compatibility. It’s currently broken (it’s unhooking the wrong filters), but I assume it’ll be fixed before 4.2 is released.

        which is a thing Google does not tolerate

        Can you please clarify what you mean by that?

        • Ihor Vorotnov 2:53 pm on April 5, 2015 Permalink | Log in to Reply

          Google’s recommendations for faster and better sites include “remove any inline styles and scripts from your html source”. Which is actually a common sense – scripts are scripts, markup is markup. We were fighting for years to remove inline WP gallery styles and now we’ve got inline scripts. Awesome)

          It’s a good thing to include this compatibility in core, but turning emoji support (and adding extra inline script) by default isn’t. Most sites (not blogs) have serious tone of voice and don’t need emoji. Those who want them can turn them on in options or using add_theme_support( ’emoji’ ) for example. That’s how it should be, IMHO, not vice versa.

          • Gary Pendergast 12:16 am on April 6, 2015 Permalink | Log in to Reply

            Google’s recommendations for faster and better sites include “remove any inline styles and scripts from your html source”.

            That is true for large scripts and styles, but not for small scripts.

            For scripts needed for page rendering, Google recommends putting them inline, to avoid extra network requests:

            Scripts that are necessary to render page content can be inlined to avoid extra network requests, however the inlined content needs to be small and must execute quickly to deliver good performance.

            https://developers.google.com/speed/docs/insights/BlockingJS

            • Julie @Niackery 2:32 pm on April 6, 2015 Permalink

              Hi Gary, thanks very much for answering all the questions here! I’m finding the info very useful. I’m just wondering about the second part of the comment above. Currently my settings are not to convert emoji — so as of 4.2 this setting won’t exist anymore? Emoji will be converted automatically regardless of settings? Or will I have to readjust my settings? I really despise the idea of installing a plugin to configure something I should be able to do in my settings. I sincerely hope WordPress isn’t forcing emoji on every single install. As stated above, a great many sites will not appreciate having emoji turned on automatically, especially without the ability to disable without a plugin. WordPress shouldn’t force the use of a plugin to disable such a frivolous feature (which can’t possibly meet the 80% use requirement). Really hoping I’ve misinterpreted this, so I’m very much looking forward to your reply — cheers!

            • Gary Pendergast 1:32 am on April 7, 2015 Permalink

              This is where the difference between smilies and emojis becomes a little more important. The setting you’re referring to is specifically for converting smilies to images. This setting will continue to exist in WordPress 4.2, but will only apply to smilies.

              Emoji are a different case – they’re text, not images. They’re part of the Unicode standard, and all OSes and browsers are working towards supporting them natively. The problem is that the support is not 100% yet, so the emoji image replacement is all about providing a compatibility layer for those users. As native support is rolled out, the compatibility layer will automatically stop loading the image replacement code.

              While I appreciate that your specific usage may not require emoji support, it’s fairly clear from other platforms (including WordPress.com) that emoji are becoming an important part of communication – a simple way to convey a wide range of emotions in a text format. To take an easy example, look at any business page on Facebook – while the business news posts may not use emoji, you’ll struggle to find a comment thread replying to those posts that don’t contain emoji.

              The important part to remember is that, as of WordPress 4.2, all WordPress sites will support emoji. This is entirely a side effect of our improved Unicode support, and it cannot be disabled (in the same way you cannot disable some of the letters in the alphabet). The compatibility layer is focussed on improving the reading experience for your end users. You can disable that if you really want to, but I think the cases for disabling it are fairly narrow.

            • Julie @Niackery 4:05 pm on April 7, 2015 Permalink

              Thanks very much for that answer, Gary! I continued to read up on emoji some more after leaving that comment and suspected I was misunderstanding the issue. Thanks for clearing it all up — I’m assuming/hoping I’m not the only one who may have been confused about this 😉

              I hope you don’t mind my asking one last question — in Facebook or on my phone, I just click on the image of the emoji I want to use (as opposed to typing the symbols for emoticons, as I understand it). So does this mean that the support added to WordPress will also add buttons to the post editor? How would that work for those using the html editor?

              Thanks again for your help!

            • Gary Pendergast 12:37 am on April 8, 2015 Permalink

              Good news! We wrote a codex page, just to let you know how to use emoji:

              https://codex.wordpress.org/Emoji

              (Summary: On your mobile device, your emoji keyboard will work, both in the WordPress app, and if you visit your Dashboard in your Browser. OS X and Windows 8+ also provide emoji keyboards that you can use.)

            • Julie @Niackery 1:14 pm on April 8, 2015 Permalink

              Oh my goodness! You guys are the best :) Thanks a million!

        • Ihor Vorotnov 2:56 pm on April 5, 2015 Permalink | Log in to Reply

          and, btw, check current page’s url in Chrome on Windows.

          • Gary Pendergast 12:17 am on April 6, 2015 Permalink | Log in to Reply

            Windows 7 and earlier has no native rendering of emoji, so native controls (such as the URL bar) won’t render them correctly. Unfortunately, we don’t have any control over that.

    • marsjaninzmarsa 1:38 am on April 3, 2015 Permalink | Log in to Reply

      Ugh, this article in Feedly (via RSS) looks awful. 😞

    • Primoz Cigler 2:06 am on April 3, 2015 Permalink | Log in to Reply

      Hilarious, never seen the emoji in my URL bar before! 😀

    • Brandon Kraft 2:34 am on April 3, 2015 Permalink | Log in to Reply

      Emoji in URL, while supported per spec and fun, isn’t the greatest experience yet. I have a few notes on it toward the end of http://www.brandonkraft.com/b/2015/03/emoji-wordpress-and-you/

      Now that we support it, I would imagine more folks will sooner than later.

    • Nile Flores 3:14 am on April 3, 2015 Permalink | Log in to Reply

      I’d like to use my own emoji like I did back in the day. I’ve got all these emoticon sets I made that I can choose from. Possible to do this like I could in the past??? For example b2 grins by Alex King became wp grins and you could do this for both post types and comments, and then with a a filter, change the path to the directory of the emoticons you want to use if you wanted to use your own.

      What about like the old days when the comment form on posts, you saw the emoji load and just clicked to add them into your comment?

      • Gary Pendergast 3:40 am on April 3, 2015 Permalink | Log in to Reply

        You can absolutely use a different emoji set!

        As this is based on Twemoji, it uses their naming scheme for the image files. For single character emoji, that looks like “1f4a9.png” (💩). For two character emoji, that looks like “1f1ec-1f1e7.png” (🇬🇧). EmojiOne, for example, uses the same naming scheme, so a plugin to convert emoji to EmojiOne would simple use the “emoji_url” filter to change the location of the emoji images.

        We won’t be doing an emoji selector in core, though. It would be about 400KB of JSON, plus the images – pretty weighty to include on every page. :-)

    • Dave McHale 1:00 pm on April 3, 2015 Permalink | Log in to Reply

      As a chrome user, this does little to excite me. Rectangles in the URL, yay? My email notification about this post was LITTERED with rectangles in Gmail, though most emoji seem to render fine on the page itself. It seems like there are too many rendering support issues for this still… My $0.02

      • Pascal Birchler 5:37 pm on April 3, 2015 Permalink | Log in to Reply

        I use Chrome as well and the emoji in the URL is displayed just fine. And I’m sure Gmail supports emojis just fine too and the rectangles in the email were caused by the Jetpack email subscription.

      • Gary Pendergast 10:37 pm on April 3, 2015 Permalink | Log in to Reply

        Unfortunately, we can’t do anything about Chrome’s URL bar – that only works where the OS has native support for emoji.

        The email problem will be fixed next week: Jetpack’s email subscriptions go through WordPress.com, which I haven’t rolled full emoji support out to, yet. It’s on my list. 😎

    • Chris Van Patten 10:18 am on April 5, 2015 Permalink | Log in to Reply

      I noticed that in Chrome 42.0.2311.68 beta on OS X, the script still kicks in and replaces the emoji even though this version of Chrome fully supports emoji. There’s a noticeable flash as the system-standard emoji get replaced with the Twemoji variants.

      Is that intentional? I thought the aim was for the script to detect if the browser already supports emoji and only kick in if it doesn’t.

      • Gary Pendergast 10:24 am on April 5, 2015 Permalink | Log in to Reply

        This is intentional. Chrome OS X doesn’t render colour emoji if the font weight of the element they’re in is greater than 500 (ie, anything bolder than normal). So, rather than have invisible emoji under some circumstances, we’re replacing all emoji on the page. Once Chrome releases a version that does render emoji in bold elements, the script will automatically stop loading Twemoji.

        For reference, here’s the Chrome ticket for this bug: https://code.google.com/p/chromium/issues/detail?id=441946

  • Michael Arestad 7:42 pm on February 18, 2015 Permalink |
    Tags: ,   

    Press This Revamp Merge Proposal 

    What is it?

    Press This is a redesign of an existing feature with a focus on automation, speed, and mobile usability.

    Download the plugin and check it out for yourself!

    Features

    One of the requirements of core is at least feature parity with the old version of Press This. Here’s a comparison chart of where the new Press This is.

    Feature Old New
    Drag & drop install on desktop Yes Yes
    Editor, including: title, image/gallery addition Yes Yes
    TinyMCE buttons (minus kitchen sink) Yes Mostly [1]
    Ability to publish or save as draft Yes Yes
    Post formats Yes Yes
    Categories Yes IYes
    Tags Yes Yes
    Content Scraping Yes Improved [2]
    Media Discovery Yes Improved [3]
    Alert before closing/navigating away Yes Yes
    Can add to bookmarks Yes Yes
    Responsive, clean design, updated icons No Yes
    Fast loading (speedy!) No Yes
    Mobile installation No Yes

    [1] A number of TinyMCE buttons are removed intentionally. Only necessary WYSIWYG buttons are shown now.
    [2] Not only is it included, but it’s quite a bit smarter than the previous one.
    [3] Now is actually quite exposed in the UI.

    More generally

    • Trimmed down UI for extra-speedy reposting of your favorite left shark gif
    • Core architecture of the plugin/tools is an as-pure-JavaScript-app as possible
    • Currently AJAX-driven, but ready to be switched to using the WP-API endpoints as they become available in the future
    • Backward compatible with the current version of the Press This bookmarklet as bundled in WP, but also bring its own, more powerful one with it
    • Can blog content from any web page found online
      • highlighted text gets pulled in as a blockquote
        • if nothing is highlighted, it makes a good guess as to what should be quoted
      • in-page images get pulled in to choose from
        • Said images are augmented with meta data to sort them in the order the site advertises to be best
      • audio, video, and and twitter embeds are also listed in the suggested media to insert at your whim
    • Saving draft sends you into the full editor (and saves) so you can do your fancier WYSIWYG-y things
    • Publishing is awesome and quick
    • Image side-loading
    • Ultimate (the best ever probably) WYSIWYG toolbar that’s trimmed down to just B, I, Blockquote, Link/unlink, undo, redo (and lists on wider screens)
    • 2 modes
      • Direct access: Like quick post, but awesome and totally usable on a fancy phone
      • Bookmarklet
        • Similar to the older Press This in use. Save as bookmarklet > Press a site for quick reposting of things
        • If no content detected (new tab), you can use it like a quick post application

    So which problems are we solving?

    • Outdated UI –> Updated
    • No responsive styles –> ultra responsive
    • Decent automation –> better automation (suggested media, blockquote, etc)
    • Pretty dang near impossible to add as a bookmark and use on a tablet/phone –> Added our own tool page (temporary) to add improved markup (still could use a bit of finessing)
    • Suggested media was hard to find –> Now is hard to miss
    • A bit rough and slow to use and compose with –> Pretty dang streamlined

    What brought us to this solution and what other potential solutions did we explore?

    When we were initially exploring designs and ideas, a few people suggested just improving Post New. The main reason we opted not to was speed. Post New comes with all of wp-admin and its files. It’s a bit of a beast. We wanted an extremely light, extremely fast (both in performance and in usability) way to post and keeping Press This was a good way to go. We can also pull the ideas and techniques we like back into Post New if successful and useful.

    We experimented with SVG icons (one less http request, but ultimately removed as Dashicons are required for the editor). We planned to use the upcoming API. We have trimmed down stylesheets and JS (only the styles necessary for a PT view). There is no extra UI that could get in the way of going from 0 to published post. Press This also has the luxury of being able to fall back to the full editor (via Save Draft) for those that have plugins and other features the need to set before posting.

    Usability testing (not user testing y’all)

    We did a couple rounds of usability tests. One for a11y and another with some new users.

    Both had tremendous difficulty in even adding the bookmarklet. @marcelomazza did a pretty solid job fixing up the add bookmarklet screen.

    We ran into a number of a11y issues and addressed as many as we could. Could still use another round of a11y testing.

    Once the new users figured out how to install it, they didn’t have many issues creating a post. I’d like to do more with ultra Space Jam pro users like yourselves.

     Mega thanks to everyone involved so far:

    @stephdau @azaozz @marcelomazza @ryan @kraftbj @afercia @iseulde @melchoyce @folletto @georgestephanis @helen @drewapicture @danielbachhuber @dd32 (for epic Github > SVN sync)

    And thanks to all the testers so far!

     
    • Jeremy Felt 8:00 pm on February 18, 2015 Permalink | Log in to Reply

      This has really turned out excellent. There’s been a ton of progress over the last couple weeks and as an “every once and a while, but hoping to use it more” user of Press This, the new UI is looking great.

    • Ansel Taft 9:51 pm on February 18, 2015 Permalink | Log in to Reply

      “Trimmed down UI for extra-speedy reposting of your favorite left shark gif”

      Nice reference. I actually spit coffee in a pop of laughter you awesome jerk.

      “Jerk” not meant seriously.

    • Ionel Roiban 10:42 pm on February 18, 2015 Permalink | Log in to Reply

      Will test and see if it can actually work as a bookmarking service, something like Pocket (or its Open Source version Wallabag), or for content curation, similar to what Scoop.it does.

      • Michael Arestad 10:58 pm on February 18, 2015 Permalink | Log in to Reply

        I’ve actually been testing it as a bookmarking service, but it’s a little tricky the way I was using it. (actual bookmarks).

        • Ionel Roiban 11:26 pm on February 18, 2015 Permalink | Log in to Reply

          How about a Chrome extension. “bookmarklet” to me sounds like a quick hack, although it really works, pulling the image and highlighted text.

          I would also take it further, to content curation, the hot 2015 trend for SEO.

          Congratulations for bringing this feature back to life!

    • Stagger Lee 11:47 pm on February 18, 2015 Permalink | Log in to Reply

      Do you guys (mis)use Amphetamines ? :)

      I have never seen so much activity in any CSM community. You really deserve No. 1 place in the world of CMSs.

    • Shaped Pixels 6:11 pm on February 24, 2015 Permalink | Log in to Reply

      A suggestion…. if Press This detects a Copyright meta tag, that it doesn’t allow any content from that source to be scraped.

  • Pascal Birchler 3:31 pm on February 11, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s time for another run-down of what’s going on in WordPress core. This edition covers February 3rd, 2015 [31332] through February 11th, 2015 [31410].

    Quick info: If you’re interested in helping out with these updates, comment below, or ping @mike on Slack! There’s a dedicated #core-weekly-update channel and you can even use a super cool script to parse the logs.

    Without further ado:

    Customizer

    • Improve the Customize experience on mobile. [31384] #28784
    • Introduce an API to create WP_Customize_Settings for dynamically-created settings. [31370] #30936

    Updates

    • Replace $.post() calls with wp.ajax.post(), and clean up a bunch of the now unnecessary code. [31409] #29820
    • Use a positive wording for translations update notice. [31368] #28199
    • If the current user is not allowed to install/update plugins, we should return a JSON error, so it can be used by the JS handlers. [31335] #29820
    • Add capability checks to the ajax callbacks, to ensure the current user is allowed to install/update plugins. [31334] #29820
    • Add ajax-y updates to the plugin list page, and ajax-y updates and installs to the plugin card page. [31333] #29820
    • Updates: Display plugin update rows even for plugins which are not hosted by WordPress.org or the HTTP request times out on. [31382] #29583, #30767

    Embeds

    • oEmbed discovery fails on XHTML head links, adjust the regex to not match /. [31407] #31212

    Media

    General

    • Replace generic “Dear user” greeting in email notifications with a more personalized one. [31403] #31217
    • Update body class when switching between admin color schemes. [31400] #30488
    • Avoid inadvertent stomping of the original $args parameter passed to plugins_api_result and themes_api_result filters in plugins_api() andthemes_api(), respectively. [31363] #29079

    Comments

    • Switch to a string placeholder, as number_format_i18n() returns a string. [31402] #26553
    • Use _n() in comments_popup_link() when setting the default string to display if there are more than one comment. [31401] #26553
    • Use screen reader text instead of a title attribute in comments_popup_link. [31388] #26553

    Taxonomy

    • Don’t parse empty tax_input keys in edit_post(). [31392] #30615
    • Remove unnecessary array_shift() usage in get_terms() for better performance. [31365] #31182
    • Parse non-hierarchical tag input into term IDs before sending to wp_insert_post(). [31359] #30615
    • Update the DocBlock for wp_dropdown_categories() to reflect that the entire $args parameter array is optional instead of individual arguments. [31357] #30306
    • Use field-specific sanitization in WP_Tax_Query::transform_query(). [31346] #27810

    Database

    • WPDB: If a site is using the utf8 charset, and their version of MySQL supports utf8mb4, auto-upgrade them to utf8mb4. [31349] [31351] [31354] [31358] [31391] #21212
    • WPDB: The mysqli_query() call in wpdb::set_charset() had the parameters the wrong way around. [31374]

    Users

    • Add orderby=meta_value_num support to WP_User_Query. [31369] #27887
    • Remove leading space from the definition of a global cache group. This only applied in a rare situation during the switch_to_blog() process where no global groups were currently defined. [31348] #31243
    • Add useremail and userslugs as global cache groups. [31347] #31243

    Editor

    • Editor: prevent errors in editor-expand when the Text editor is not used. [31361] #31163
    • Fix displaying long tag names in the Tags postbox. [31332] #18946
    • MCE views: Always refresh the view after updating a gallery. This allows things like caption changes to be synced, as they are tied to the attachment and not the shortcode. [31343] #31239
    • TinyMCE: ensure the image toolbar stays visible when the image is much wider than the editor. [31362] #20696

    Build/Test Tools

    • Update Travis-ci Slack notification token [31352] #30755
    • Temporarily (I hope) remove PHP 5.2 from tests being run on Travis-ci. Travis-ci has disabled PHP 5.2. This has happened before when 5.2 didn’t compile and then was restored when that was fixed. #31244

    Posts & Pages

    • Introduce 'value_field' parameter to wp_dropdown_pages(). This parameter allows developers to choose the post field that will be used to fill in the ‘option’ attribute of the generated dropdown markup. [31338] #30306, #12494
    • Always pass back the custom classes get_post_class() was called with, even if the post was not found. [31408] #22271

    Thanks to @adamsilverstein, @afercia, @ArminBraun, @azaozz, @boonebgorges, @bswatson, @Bueltge, @celloexpressions, @ChriCo, @Corphi, @cweiske, @dd32, @dlh, @DrewAPictur, @DrewAPicture, @ericlewis, @F J Kaiser, @Funkatronic, @genkisan, @helen, @hissy, @ipm-frommen, @Ipstenu, @iseulde, @jfarthing84, @joedolso, @johnbillion, @jorbin, @lgladdy, @lgladdy for the initial patch, @nacin, @netweb, @obenland, @ocean90, @pento, @SergeyBiryukov, @siobhan, @tyxla, @valendesigns, @Veritaserum, @VolodymyrC, @vortfu, @westonruter, and @wonderboymusic for their contributions!

     
  • Michael Arestad 12:02 am on February 11, 2015 Permalink |
    Tags:   

    Press This update 2/10 

    The merge window is supposed to open tomorrow for feature plugins. That means it’s crunch time. Here’s where the new Press This is.

    Feature Parity

    one of the requirements of core is general feature parity with the old version of Press This. Here’s a comparison chart of where the new Press This is.

    Feature Old New
    Drag & drop install on desktop Yes Yes
    Editor, including: title, image/gallery addition Yes Yes
    TinyMCE buttons (minus kitchen sink) Yes Mostly [1]
    Ability to publish or save as draft Yes Yes
    Post formats Yes Yes
    Categories Yes In Progress
    Tags Yes In Progress
    Content Scraping Yes Improved [2]
    Media Discovery Yes Improved [3]
    Alert before closing/navigating away Yes Todo
    Can add to bookmarks Yes Yes
    Responsive, clean design, updated icons No Yes
    Fast loading (speedy!) No Yes
    Mobile installation No Yes

    [1] A number of TinyMCE buttons are removed intentionally. Only necessary WYSIWYG buttons are shown now.
    [2] Not only is it included, but it’s quite a bit smarter than the previous one.
    [3] Now is actually quite exposed in the UI.

    Before Core Merge

    Prior to merge, there’s a bunch that still needs to be done. With that in mind, @DrewAPicture has given us an extra week to accomplish this. Even still, we have a list of things that need to be done prior to devchat tomorrow, with the rest of the list done in a week.

    Before Tomorrow’s Devchat (February 11)

    Before Next Wednesday’s Devchat (February 18)

    If we’re able to accomplish all of the above, we should be ready for merge on February 18.

    Daily Chats

    In this final rundown, let’s meet daily in #feature-pressthis at 17:00 UTC to make sure we’re on track for merge. Anyone interested in helping, please join us.

    All development is done on Github: https://github.com/MichaelArestad/Press-This/

    Plugin on the plugin repo: https://wordpress.org/plugins/press-this/

     
  • Michael Arestad 4:11 am on February 6, 2015 Permalink |
    Tags:   

    Press This meeting notes 2/5 

    Huge discussion today! Lots of work to get done in the next week!

    Discussed

    • Install process
      • Boomarklet and direct link install methods (currently impossible on tools)
      • May end up creating page to test this
    • Other methods of getting to PT (url tricks)
    • Mobile flows
    • Quick post flow versus repost flows
    • Post formats
    • User testing
      • Questions that need answering
        • Is this an improvement over the current PT?
        • Will a user miss post format, tags, or categories if not present?
        • Will they feel compelled to use them if present?
        • Is taking a photo on mobile required?
        • Can a user find and add an image from a scraped site?
          • How quickly?
        • How quickly can a user add an image?
          • multiple images?
        • Is this efficient to use on mobile?

    To do

    Update

    We’ve refined a few of the features. We decided to let the user choose an image or video to add rather than guessing. It also freed up a little space. :) More bugs have been squashed. We’ve updated to the correct WP logo among other things.

    A few people have asked about functionality gained versus functionality lost in the current plugin, so let’s start there.

    Gained

    • improved media scraping
    • oEmbed
    • responsive design

    Lost

    • post formats
    • categories
    • tags
    • most of the WYSIWYG buttons (by design)
    • code editor (by design)

    The big question facing us is whether we should add Post Formats, Categories, and Tags for the initial merge at the risk of missing the 4.2 deadline. Now, it is still possible to set those by clicking/tapping the “Save Draft” button on the bottom, which saves the draft and redirects you into the full WP editor and all the meta boxes.

     

     
    • Stagger Lee 7:13 am on February 6, 2015 Permalink | Log in to Reply

      Why not twist philosophy a bit and put this plugin as optional URL field in post edit screen ?
      Call plugins scripts with Ajax, to not call them globally. This way you could solve lot of problems.

    • BizzThemes 10:45 am on February 9, 2015 Permalink | Log in to Reply

      Press This should move from core to a plugin as it’s practically a tool for spamming the web with duplicated content and doesn’t fit in core. Core developers should focus on building a better CMS for original developers and authors, not tools for lazy authors.

    • essayoh 7:20 pm on February 9, 2015 Permalink | Log in to Reply

      Will a user miss post format, tags, or categories if not present? – Any way to maybe auto-tag or auto-categorize all Press-This Posts through the Dashboard, rather than the Press This interface itself?

      Is taking a photo on mobile required? – Where it’s possible I think we should do it. The less friction between a desire to post something and that thing being posted, the better.

      Can a user find and add an image from a scraped site? – Yes

      How quickly? – Good question – some image-heavy sites (especially with image-heavy sidebars, footers, etc) can make the scraped image gallery pretty congested atm

  • Pascal Birchler 10:41 am on February 4, 2015 Permalink |
    Tags: ,   

    WordPress Core Weekly 

    Hi Everyone!

    It’s time for another run-down of what’s going on in WordPress core. This edition covers January 25th, 2015 [31282] through February 3rd, 2015 [31331]. If you’re interested in helping out with these updates, comment below, or ping @mike on Slack! There’s a dedicated #core-weekly-update channel and you can even use a super cool script to parse the logs. Without further ado:

    Themes

    • Allow version number in the overlay to be selected. [31330] #31205
    • Remove a Chrome workaround that causes theme screenshots to look too crisp and no longer appears to be relevant. [31316] #26584
    • Twenty Fifteen: move RSS icon style rule lower to prevent it from being overridden by other social icon rules. [31283] #31129

    Customizer

    • Ensure that WP_Customize_Setting::value() returns default value for setting if not dirty.
    • Allow WP_Customize_Manager::post_value() to accept a second $default argument.
    • Introduce WP_Customize_Manager::unsanitized_post_values()for accessing previously-private member variable _post_values.
    • Do require_once instead of require for Customizer classes.
    • Add unit tests for WP_Customize_Manager and WP_Customize_Setting. [31329] #28580, #30988

    Script Loader

    • Separate the tests for IE conditional comments support in WP_Scripts. [31317] #16024
    • jQuery UI: Add jquery-ui-core as dependency forjquery-ui-progressbar. [31322] #31208

    Upgrade / Install

    • WP_Upgrader: Remove references to non-existant variables that have never existed. [31327] #29087
    • Remove duplicate label on installation screen. [31282] #31131

    Internals

    • Plugins: Remove an unused parameter on install_plugins_upload(). [31326] #28964
    • Widgets: Add widget_nav_menu_args filter for Custom Menu widget arguments. [31325] #29463
    • Menus: Don’t display “Move” text without direction if there is only one menu item. [31320] #30765
    • HTTP API: Fix an issue where the limit_response_size parameter wasn’t working properly with large documents and the cURL transport. [31290] #31172
    • i18n: Exclude wp-includes/class-pop3.php in wp_frontend() to prevent having 25 unused translations. [31315] #31179
    • i18n: Tabs, not spaces for indentation. [31314]
    • Switch to a 403 response code in places where it is more appropriate than a 500 due to permissions errors. [31300] #30927
    • Update readme recommendations. [31291] #31173

    WP_Query

    • When using WP_Query’s fields => ids (or fields => id=>parent), make sure the returned result is always an array of integers. [31324] #31194, #27252
    • When querying for a specific post, allow posts with a non-public status to be returned as long as that status is specified.
      This makes it possible to, for example, retrieve a specific post using the p parameter of WP_Query, even if the post is in the Trash, by including the post_status=trash parameter. [31321] #29167
    • Improve support for ordering WP_Query results by postmeta.
    • WP_Meta_Query clauses now support a name parameter. [31312] #31045

    Posts

    • In get_sample_permalink(), override future status before generating permalink. [31323] #30910
    • In get_adjacent_post(), return private post if the current user has the capacity to read it. [31302] #30911, #30287

    Taxonomy

    • Introduce show_in_quick_edit parameter + filter for register_taxonomy(). Setting show_in_quick_edit to false when registering a custom taxonomy will hide the taxonomy when editing posts using Quick Edit. [31307] #26948
    • Don’t use term IDs for array indexes when caching object terms. Uncached results pulled from wp_get_object_terms() are zero-indexed (ie 0, 1, 2…). As a result, get_the_terms() was returning a strictly different array when pulling from the cache and when the cache was empty. [31287] #31086
    • Ensure that hierarchical is respected in get_terms() when multiple taxonomies are passed. [31285] #31118
    • Ensure that pad_counts is not discarded when the first of multiple taxonomies passed to get_terms() is non-hierarchical. [31284] #31118

    Media

    • Rename $instances to $instance in wp_audio_shortcode() and wp_video_shortcode() for consistency with gallery_shortcode() and wp_playlist_shortcode(). [31305] #31151
    • Pass the current shortcode instance ID to post_gallery and post_playlist filters. [31304] [31309] #31151

    Build / Test Tools

    • Introduce setExpectedDeprecated() and setExpectedIncorrectUsage() methods to WP_UnitTestCase. [31306] #28486
    • Improve organiation of tax_query and meta_query unit tests. [31286] #26999
    • Add basic unit tests for get_page_of_comment(). [31289] #11334
    • Add unit tests for show_option_all behavior of wp_list_categories(). [31301] #21881
    • Add tests for get_category_parents(). [31299] #30415
    • Add a unit test that expects wp_parse_args() to treat true and false in a query string as strings. [31310] #30753

    Admin

    • Accessibility: remove remaining instances of accesskey. [31331] #29715
    • Help/About: Don’t display the Help tab reference in Page Attributes meta box if Help tab was removed. [31303] #31164
    • Add New User: Remove trailing whitespace from button labels. [31298] #31175
    • Login: Reduce the size of the WordPress logo tap target on log in screen on mobile, to avoid unexpected redirect away from the form. [31318] #31185

    Thanks to @afercia, @Ankit K Gupta, @azaozz, @bananastalktome, @boonebgorges, @bswatson, @cyman, @dd32, @dmchale, @DrewAPicture, @ebinnion, @ericlewis, @Funkatronic, @garyc40, @helen, @hlashbrooke, @iamtakashi, @ipm-frommen, @jdgrimes, @jeremyfelt, @johneckman, @joshlevinson, @justincwatt, @kucrut for initial patch, @lancewillett, @meloniq, @michalzuber, @mzak, @nacin, @ninnypants for the initial patch, @ocean90, @prasoon2211, @rmarks, @SergeyBiryukov, @tomdxw, @tyxla, @valendesigns, @voldemortensen, and @westonruter for their contributions this week!

     
  • Ryan Boren 9:01 pm on January 27, 2015 Permalink |  

    Open Update Thread, Week of January 26th 

    It’s been awhile since the last open thread. What’s happening in your core development world? Share on the OUT.

     
  • Pascal Birchler 10:31 am on October 23, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi everyone!

    It’s this time of the week again: WordPress Core Weekly is here. This updates covers all commits since last week up to today, October 23rd.

    In case you missed it, there has been quite some activity here. I recommend you to check out these great summaries from this week to stay up-to-date:

    Now, let’s have a look at the recent comments!

    Admin

    • Themes: Make “Live Preview” the primary action and “Activate” secondary. [29957] #26899
    • Themes: Fix some theme install stylings [29959] #28148 #29556
    • Live-update site title in toolbar when changing the corresponding field in General Settings. [29963] #28682
    • Allow apostrophes in email addresses when adding users via the Dashboard. [29966] #18039
    • Admin menu changes [29978] #29806
      • Fix scrolling the pinned menu with a mouse wheel.
      • Fix pinning when the menu is only slightly taller than the viewport.
      • Disable pinning on IE8, updating CSS top makes it jump when scrolling with a mouse wheel.

    Customizer

    • Introduce customize_preview_$setting->type action to handle multiple settings of the same type. [29948] #29165
    • Extract content markup for panels to its own method,WP_Customize_Panel::render_content(). This allows to override the behavior of a panel and its contents. [29950] #29324

    Editor

    • Editor-expand [29929] #29954
      • Better calculation for the caret position when auto-scrolling while typing.
      • Fix auto-scrolling for non-WebKit browsers when the caret is above the top of the editor.
    • TinyMCE: update the default styles: make the font size larger and make it the same size in tables. [29986] #30038
    • TinyMCE: update to 4.1.6+. Adds support for cache-busting when auto-loading JS and CSS. [29994] #30079

    Twenty Fifteen

    • Make font-size/line-height in editor-style.css the same as in style.css. Remove margins from the editor body, interferes with autoresize in some browsers and is overriden in the default styles. [29909] #29799
    • No rem in editor-style.css for now. [29910] #29799
    • Add print styles. [29919] #29967

    Internals

    • Add a 6th (!) attribute to wp_get_attachment_link() to allow aria-describedby to be added to gallery output. [29914] #27402
    • Cache get_term_by() calls [29915] #21760
      • Add a helper function, wp_get_last_changed(), to retrieve a last-modified timestamp by cache group.
      • Original term cache entries maintain BC
    • wp_schedule_single_event() should not prevent scheduling a future duplicate event. It should only reject an event as a duplicate if there is already a similar event scheduled within 10 minutes of the given timestamp. [29939] #28213
    • Add ID attribute to style element from wp_add_inline_style(). [29956] [29958] #30032
    • Move password hint text to a function. Add password_hint filter. [29962] #21243
    • HTTP API: Support both the limit_response_size and stream parameters at the same time, allowing a partial file download. [29968] #26726

    Comments

    • Don’t print an empty HTML markup when comment_reply_link() returns no link. [29908] #29895
    • Use the comment API rather than direct SQL queries in comments_template(). [29965] #19623

    External Scripts

    Queries

    • Check that search value is scalar before parsing. Prevents PHP notices when non-scalar values are passed. [29912] #29736
    • Introduce nested query support to WP_Date_Query. [29923] #29822
    • Throw notices _doing_it_wrong() notices are now generated when passing out-of-range values (month=13) or invalid dates (2014-02-29) to WP_Date_Query. [29925] #25834
    • Support date_query by user_registered in WP_User_Query. [29934] #27283
    • Comment/post author in/not_in for WP_Comment_Query. [29935] #29885
    • Better “inclusive” support for string values in WP_Date_Query. [29936] #29908

    Thanks to @westonruter, @obenland, @tivnet, @joedolson, @DrewAPicture, @rianrietveld, @wonderboymusic, @tollmanz, @boonebgorges, @Manoz69, @iamtakashi, @kwight, @pauldewouters, @ideag, @ChriCo, @NikV, @nofearinc, @ew_holmes, @neoxx, @Viper007Bond, @nacin, @chriscct7, @tellyworth, @sc0ttkclark, @jorbin, @socki03, @ocean90, @convissor, @TobiasBg, @TomHarrigan, @jdgrimes, @jcastaneda, @celloexpressions, @avryl, @simonwheatley, @hardy101, @georgestephanis, @jesin, @hugodelgado, @nobleclem, @afercia, @bradyvercher for their core contributions!

    Revisions covered: [29906] to [29994]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.1.

     
  • Pascal Birchler 6:28 pm on October 15, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi everyone!

    It’s time for WordPress Core Weekly (formerly known as Last Week in WordPress Core) again! There have been suggestions to change the name of these summary posts to stop confusions about being the last week of WordPress.

    This updates covers all commits since last week up to today, October 15th. There has been much progress this week with lots of improvements to the WP_*_Query classes, fixes in the admin and of course the introduction of the Twenty Fifteen theme! The complete summary:

    Admin

    • Add missing labels to category filter dropdowns. [29870] [29871] #29921
    • Differentiate between invalid and missing admin emails when adding a new site [29877] #17890
    • Multisite: Do not send a welcome notification when noconfirmation has been flagged [29880] #16235
    • Admin menu: [29898] #29806
      • Fix pinning after resizing the window.
      • Merge the two DOM ready callbacks in common.js
      • Fix the submenus position adjustment on focus.

    Editor

    • TinyMCE: fix the ‘wpgallery’ plugin to use a placeholder for galleries when either the ‘wpview’ plugin or wp.mce is not loaded. [29883] #28756
    • Quicktags: move focusing the editor after inserting content to the end of the code blocks. [29884] #29944
    • Editor-expand: reset the editor height after the window is resized. [29886] #29952

    Customizer

    • Change instances of “Theme Customizer” to just “Customizer”, as the Customizer isn’t necessarily theme-specific. [29903] #29947
    • Only POST dirty settings to preview to improve performance. [29905] #29983
    • Don’t trigger a change event if two unchanged object values are equal, second pass. [29907] #26061

    Bundled Themes

    • Add an alt attribute with the site title for header images linked to the home page. [29842] #15926

    Twenty Fifteen

    Comments

    External Scripts

    • Update jQuery UI to 1.11.1. [29847] #29833
      • Rename all files, remove the jquery.ui. prefix. Add old files to $_old_files.
      • Add and use non-minified files in /src.
      • Add grunt task to minify jQuery UI files.
      • (Non-minified files will not be shipped.)

    Language Packs

    • Language packs: Remove translations when deleting a theme or a plugin. [29856] #29860

    Internals

    • Handle deficiencies in PHP’s parse_url in older versions of PHP (<5.4.7) in WP_HTTP::make_absolute_url(). [29851] [29850] [29861] #28001, #29886
      • Correctly handle url’s containing url’s in WP_HTTP::make_absolute_url().
      • Correctly support Schemeless URLs in WP_HTTP::make_absolute_url() by respecting the ‘host’ field if present in the relative url.
    • New remove() method and some unit tests for the WP_Error class. @29854 #28092
    • Return an error when adding a term to a non-existent parent. [29867] #29614

    Queries

    Thanks to @rianrietveld, @tschutter, @netweb, @joedolson, @bramd, @Fab1en, @ocean90, @stephenharris, @boonebgorges, @georgestephanis, @jesin, @afercia, @miqrogroove, @avryl, @mboynes, @transom, @DrewAPicture, @johnrom, @matt, @iandstewart, @iamtakashi, @obenland, @cainm, @kristastevens, @karmatosed, @chellycat, @lancewillett, @kwight, @davidakennedy, @otto42, @jakub.tyrcha, @studionashvegas, @tareq1988, @westonruter for their core contributions!

    Revisions covered: [29842] to [29907]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.1.

     
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
Skip to toolbar