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
     
  • Konstantin Obenland 7:45 pm on April 28, 2015 Permalink |
    Tags: , ,   

    WordPress 4.3 Kickoff 

    First I’d like to thank @drewapicture for his outstanding work in 4.2! I was particularly impressed with his ability to keep meetings on track and in time, I’ll work on making sure that won’t change going forward. :) A lot of the structure and artifacts he put in place have been proven quiet successful and I’d like to continue that, so you shouldn’t see too much change in that regard either.

    Release Date

    We’re aiming to release on Tuesday, August 18th. The 4.3 schedule is live and can be found here: https://make.wordpress.org/core/version-4-3-project-schedule/

    Deadlines are not arbitrary, and with your help I fully intend to get this version shipped comfortably on the 18th. Past releases have been quite good about releasing on time, let’s make that a signature trait of the WordPress project!

    Features

    WordPress 4.3 will be all about enabling users of touch and small-screen devices. @ryan has been testing flows on a myriad of different devices the past few releases and uncovered many things that desperately need attention.

    @joedolson has published a post over on make/accessibility about a11y priorities.

    If you see anything that sparks your interest feel free to leave a comment here and attend the kickoff meeting tomorrow, when we go through the list of things that were suggested. Specifically, Admin UI can will need a lot of hands. The meeting will also be a good time to suggest additional areas that you want to work on.

    Kickoff

    We’ll kick 4.3 off with a 2-hour meeting in #core at the usual time, April 29, 20:00 UTC.

     
    • sara cannon 7:55 pm on April 28, 2015 Permalink | Log in to Reply

      Excited for this release! I would love to help out with the Network Admin UI

    • Dave Navarro, Jr. 7:58 pm on April 28, 2015 Permalink | Log in to Reply

      Would like to see an update of the AUDIO shortcode as well to pull the title text from the audio file and display it.

      Really excited for the Shortcake stuff, hope it makes it.

    • Nick Halsey 9:51 pm on April 28, 2015 Permalink | Log in to Reply

      I have several ideas for continuing to work on themes in the Customizer building on 4.2. Would like to aim for adding theme install in 4.3, which would require a shiny install process, and shiny updates could work into that well too. I won’t be able to get started on that for a couple weeks, but should have a functional and tested proposal together well before the scheduled decision time.

      Along with the other mobile and touch improvements, I’d really like to see the much-needed Customizer UI design changes happen as well, hopefully we can pick back up with #31336 soon cc @folletto @designsimply.

      FYI, as is usually the case, I won’t be able to make most dev chats again this cycle.

    • aradams 10:07 pm on April 28, 2015 Permalink | Log in to Reply

      Hello All,

      I am not part of Make, just a WP user & designer. I have watched the unfurling of the New Editor saga over at WP.com and am concerned that there might be movement to implement that Editor to replace “Classic” editor for self-hosted WP. Could someone speak to that? I would be most grateful.

      • Konstantin Obenland 2:28 am on April 29, 2015 Permalink | Log in to Reply

        There are no plans that I’m aware of.

      • James Huff (MacManX) 5:27 am on April 29, 2015 Permalink | Log in to Reply

        You can use the new editor at WordPress.com for your self-hosted WordPress.org blog already if you have the Jetpack plugin installed and its Manage module active. Note that you’ll actually be using the new editor *on* WordPress.com, and can continue to use your WordPress.org blog’s Dashboard and “classic” editor as normal.

        Considering that WordPress.com and Jetpack are both products of Automattic Inc, and WordPress(.org) is not, I’m pretty sure there will be no deeper integration or replacement.

    • Pete Nelson 10:59 pm on April 28, 2015 Permalink | Log in to Reply

      Just a couple of patches waiting for that sweet, sweet commit: #31813 #31029

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

      Admin UI – In #26311 I added a patch to make the “export admin screen” more responsive, I did this by replicating existing functionality from other admin screens, turns out these screens use tables, details of who, what and where tables are used in admin screens is also listed in that ticket.

    • mrjarbenne 3:50 am on April 29, 2015 Permalink | Log in to Reply

      It would be great to see this attended to: https://core.trac.wordpress.org/ticket/29606. Still can’t re-order gallery images on mobile (on iOS at least)

    • Max 7:37 am on April 29, 2015 Permalink | Log in to Reply

      I am not sure if that relates to Admin UI but #12706 is something which has been flowing around for a very long time without getting any closer to being fixed…

    • Ryan Boren 9:31 am on April 29, 2015 Permalink | Log in to Reply

      The touch bug I most want to see fixed is #29906. It is lingering desktop bias that fouls important toolbar flow.

    • leemon 12:45 pm on April 29, 2015 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list

    • Torsten Landsiedel 1:13 pm on April 29, 2015 Permalink | Log in to Reply

      It would be really great to fix https://core.trac.wordpress.org/ticket/28303 in 4.3. I know this is a problem just for a bunch of languages, but files being overwritten is always a big problem and people are complaining in our local forums.

    • Ryan Boren 7:47 pm on April 29, 2015 Permalink | Log in to Reply

      Perennial wish, retire media-new.php.

      https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/

      Seems like most of the work would be hooking the media addition ui from the grid view into the list view with some row insertion ajax. The list view would also need to become a full screen drop target like grid view.

    • pingram3541 8:07 pm on April 29, 2015 Permalink | Log in to Reply

      Would love to see the ability for nesting multiple shortcodes of the same name. Many themes and plugins could benefit, especially when building grids and nesting columns etc. The logic is fairly simple but there is no way to filter this currently.

      Another thing I’d love to see is the ability to define query “orderby” based on multiple meta_key, meta_values, currently you can pass an array to order by a single meta_value + any of the other orderby arguments but not 2 or more meta_keys.

    • Weston Ruter 9:59 pm on April 29, 2015 Permalink | Log in to Reply

      My proposals as I’ve also blogged:

      Customizer Partial Refresh
      This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available.

      Customizer Transactions
      A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal.

      Customizer Concurrency/Locking
      This is an important one for a client project I’m involved with, and so I’m having to prioritize it. I’m working on a client site that will have many users in the Customizer at a time, and given the way the Customizer is currently implemented (as with most areas of WP), there is no concurrency/locking support. So I’m working on adding locking at the control/setting level. See #31436.

    • RENAUT 11:31 pm on April 29, 2015 Permalink | Log in to Reply

      what about reviewing all the mails send by wordpress ?

  • Ella Iseulde Van Dorpe 2:14 am on April 23, 2015 Permalink |
    Tags: ,   

    TinyMCE views API improvements 

    In WordPress 4.2 there will be changes to the experimental TinyMCE views API. We don’t recommend this for use in production unless you closely follow the development.

    If you’re using it we’d love to get some feedback: bugs, suggestions, things you wish you could do with it… You’re also welcome to leave a comment with a link to your project. I’d love to know what kind of content you’re using it for and how you’re using it.

    Summary of the changes:

    • Simpler registration.
    • An easier way to update the view in the edit method.
    • You can choose to leave the text instead of replacing it with a loader. This is especially useful for our oEmbed views because we don’t know if the URL can be embedded until we get a response from the server.
    • You can now update the view text with a text of a different type (e.g. audio to playlist).
    • No need to use the setIframes method directly, render and setContent will handle it for you.
    • Already rendered views will never refresh again while editing other content. They do refresh when undoing or redoing things though, because TinyMCE resets the whole content unfortunately.
    • Options set in the match method (previously toView) will be added automatically to the view instance.
    • A couple of memory leaks were fixed and there’s a better way to bind and unbind views.
    • We added documentation for all the methods.

    How to use the API

    Registration:

    window.wp.mce.views.register( 'unique_name', {
    	...
    } );
    

    If you’re converting shortcodes to views, make sure unique_name is the same. They’ll be matched automatically. If you’re interested in custom matching, take a look at the embedURL registration in core.

    If the content of your view is static, you can set the content property directly, if it is dynamic, overwrite getContent. In most cases an ajax request is needed to generate the content, so use the initialize method and cache the content. Passing it through render will cache it automatically.

    This example will display the most recent images.

    initialize: function() {
    	var self = this;
    
    	wp.ajax.post( 'query-attachments', {
    		query: {
    			post_mime_type: 'image'
    		}
    	} )
    	.done( function( response ) {
    		self.render( _.map( response, function( data ) {
    			return '<img src=' + data.sizes.thumbnail.url + ' alt=' + data.alt + '>';
    		} ).join( '' ) );
    	} );
    }
    

    To add UI for editing a view, you need to add an edit method. This example is taken from the gallery view. Use the callback to update the view with the modified text (shortcode).

    edit: function( text, update ) {
    	var frame = wp.media.gallery.edit( text );
    
    	frame.state( 'gallery-edit' ).on( 'update', function( selection ) {
    		update( wp.media.gallery.shortcode( selection ).string() );
    	} );
    
    	frame.on( 'close', function() {
    		frame.detach();
    	} );
    }
    

    It is not recommended to run JavaScript in the editor iframe. If you need to run scripts it is best to use a sandbox iframe inside the view. The API will automatically do this for you if it detects scripts in your content. For example the Google Maps API might alter the editor’s iframe body. This is not acceptable because the body content is serialised by TinyMCE on saving.

    In this example the content will be put in an iframe and you can do anything you want in that document.

    content: [
    	'<script src="//maps.googleapis.com/maps/api/js?sensor=false"></script>',
    	'<style>img { max-width: none; }</style>',
    	'<div id="map" style="width: 100%;height: 500px;"></div>',
    	'<script>new google.maps.Map( document.getElementById( "map" ), { zoom: 0, center: new google.maps.LatLng( 0, 0 ) } )</script>'
    ].join( '' )
    

    If you do want to run scripts, use the bind and unbind methods and make sure there are no memory leaks.

     
  • Drew Jaynes 3:48 pm on April 20, 2015 Permalink |
    Tags: ,   

    This Week in 4.2: April 20 – 26 

    This is the jump-start post for the fourteenth (and final!) week of the WordPress 4.2 release cycle.

    Last week, we tagged RC1 and “hard froze” strings. We’ll likely tag RC2 today as well. We’re still on track for releasing 4.2 this week.

    Core Meetings this week:

    Priorities this week:

    All commits in RC stages must be approved by at least one lead developer, preferably two.

    Please, if you’re patching open tickets, ensure you’ve provided enough context on tickets for your fixes to help out those leads who may be coming along to review them.

    As of Monday, there are 14 open tickets on report 6:

    • #31651 – Change Twemoji CDN to W.org – @pento
    • #31988 – TinyMCE: pasting an embeddable URL in Firefox doesn’t show preview – @azaozz
    • #24054 – (get_)comment_class() should include a is_user_member_of_blog() class – @jeremyfelt
    • #31669 – views improvements continued – @azaozz
    • #31890 – Link to existing content added in Text Editor disappear after switch to Visual editor and back – @azaozz
    • #31929 – 4.2 About Page
    • #31984 – Shiny Updates – some glitches – @jorbin
    • #31987 – Theme Customizer: Widget search field hidden in Safari – @helen
    • #32002 – Theme Switcher: Missing back button and marking active theme – @helen
    • #32004 – Audio/video list and gallery – date dropdown and message – @helen
    • #32006 – Problem with setting width and height of embedded media – @azaozz
    • #32007 – Twenty Fifteen: Image captions are shifted down in TinyMCE – @azaozz
    • #32022 – Press This: Margin is too big forcing wrapping on mobile – @azaozz
    • #32000 – Some translators comments – @SergeyBiryukov

    Recent notable updates:

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

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

          Yay! That makes me a happy panda… lol

        • marsjaninzmarsa 9:33 pm on May 1, 2015 Permalink | Log in to Reply

          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.

          You’ve inspired me. 😀
          https://github.com/marsjaninzmarsa/WordPress-Emoji-Might

    • 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

    • Mike Crantea 5:23 pm on April 23, 2015 Permalink | Log in to Reply

      I noticed that when changing the option in the admin from Writing to not convert emoticons to graphics, the inline styles and the emoji JS still comes through. I believe they should be ignored when the site owner does not want to use this feature.

      • Ipstenu (Mika Epstein) 11:58 am on April 24, 2015 Permalink | Log in to Reply

        Comes through on the editor or on the pages people visit?

        Unlike smiles, one can enter emoji into text without using emoticons like :)

        This, for example, is emoji — 😐

        This is a smilie: 😀

        So one can have both, one, or none

        • Monika 10:44 am on April 25, 2015 Permalink | Log in to Reply

          “Comes through on the editor or on the pages people visit?”
          The scripts are still at wp_head, if I disable “convert smilies” or not, this is frustrating.
          And my old smilies are broken. 😥 and so on… :(

  • 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!

     
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