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 

    19 open tickets. Last 7 days: +0 tickets

    19 open tickets defect (bug) enhancement feature request
    Awaiting Review 4 5 1
    Future Release 6 1 2
     
  • Tammie 2:51 pm on August 25, 2015 Permalink |
    Tags: , ,   

    Introducing Twenty Sixteen 

    WordPress 4.4 will see a brand new default theme; that’s right, today is time to meet Twenty Sixteen! The process of selecting the Twenty Sixteen theme was a long one, taking several months. Lots of themes were considered, eventually settling on the one you see below. It’s a perfect fit!

    00.twentysixteen

    Twenty Sixteen features a new, never-released design that has some really unique touches on a traditional blog layout. It adapts well to different devices and is a joy to use.

    Twenty Sixteen is a modernised approach of an ever-popular layout — a horizontal masthead and an optional right sidebar that works well with both blogs and websites. It has custom color options that allow you to make your own Twenty Sixteen. The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.
    @iamtakashi

    Let’s take a look at more!

    We have the pleasure of welcoming back Takashi Irie as the designer of Twenty Sixteen. This year, the core team developing our new default theme will be myself and @iamtakashi — and you! We hope you can join us in getting Twenty Sixteen out to the world. Along with us, @iandstewart and @samuelsidler will be making sure the ship stays on course and giving us their wisdom as we charter the default theme seas.

    How can you get involved?

    There will be weekly meetings every Monday and Friday 16:00 UTC in #core-themes for half an hour. These weekly meetings will start once the theme has initially landed in core. If you are interested in contributing, subscribe to this blog (if you haven’t already), and leave your name in the comments. Once we’re ready, we will give everyone a ping and we’ll let you know on this blog too.

    Want to know more about default themes?

    There are some great links where you can find out more about past default themes.

    The road to releasing a new default theme is long, but we’re already well on our way! The next step is to commit the initial code to core. From there, we will begin testing and patching. We hope you join in the adventure of releasing Twenty Sixteen.

     
    • Nikhil Vimal 2:54 pm on August 25, 2015 Permalink | Log in to Reply

      I would be interested in helping!

    • Frankie Jarrett 2:57 pm on August 25, 2015 Permalink | Log in to Reply

      Pretty :-)

    • Drew Jaynes 3:05 pm on August 25, 2015 Permalink | Log in to Reply

      Congrats all around!

    • Ciprian 3:11 pm on August 25, 2015 Permalink | Log in to Reply

      I still think it looks a bit outdated. The default themes should be more modern, more 2016ish.

      • Mattias Tengblad 3:38 pm on August 25, 2015 Permalink | Log in to Reply

        +1

      • Paal Joachim Romdahl 4:55 pm on August 25, 2015 Permalink | Log in to Reply

        Agreed.

      • Arnan de Gans 6:21 pm on August 25, 2015 Permalink | Log in to Reply

        Yep, this looks like a 1998 html page :(

      • WTech 6:29 pm on August 25, 2015 Permalink | Log in to Reply

        +2 (imho 2014 is better)

      • Matt Mullenweg 11:52 pm on August 25, 2015 Permalink | Log in to Reply

        For the folks who think it looks old, definitely share some links to themes you think are more modern, it could be a good inspiration for twenty-seventeen (which is just around the corner).

        • waltson 5:37 am on August 26, 2015 Permalink | Log in to Reply

          Hi Matt .Really thanks for giving a chance to interact with you .I like wordpress, and i am working on it from few months .I like the 2016 theme. But please see the below points

          (1)Could you please add some more functions that assist in working with forms.

          (2)Captcha support by default

          (3)Could you please add some more permalink structure tags like %taxonomy%,%sub-taxonomy%,%sub-category% and way to arrange them

          (4) great pain is trying to make WP work with Angular.js or similar for building web apps.

          The most important ting is that please give some importance to https://wordpress.org/ideas/view/latest , because we only have this place to express our ideas . It would be very happy if we get correct reply and concentration from the wordpress team .

          I am looking forward to your reply.

          Thank you .

          • Paal Joachim Romdahl 8:12 am on August 26, 2015 Permalink | Log in to Reply

            Hi Waltson. A better place to post what you wrote would be in the “WordPress 4.4: What’s on your wishlist?” thread further down this page.

            • Sam wc 9:08 am on August 26, 2015 Permalink

              But Paal , these are some good ideas .Why we waiting for implement this in WordPress 4.4 . If these ideas make sense and it is important it can be implemented int he very next WordPress update.

            • Aparna123 9:25 am on August 26, 2015 Permalink

              Waltson is right

            • Sam wc 3:04 pm on August 27, 2015 Permalink

              WordPress team not looking at Frame work such as laravel,Yii,cakephp etc.Please make it very powerful such as this frame work. Because we love wordpress never wan’t to down when compare with these frameworks .

          • Aparna123 9:23 am on August 26, 2015 Permalink | Log in to Reply

            Good things Waltson.Generally there is lack of form handling and validating function in WordPress.Captcha is also important .

        • Adrian Pop 1:08 pm on August 26, 2015 Permalink | Log in to Reply

          I also think is kind of an oldish design – forget about sidebars! I really like Satellite (https://wordpress.org/themes/satellite/) and Ryu (https://wordpress.org/themes/ryu/) is one of my all-time favorite – Thaks Mr. Takashi :)

        • Sam wc 3:03 pm on August 27, 2015 Permalink | Log in to Reply

          WordPress team not looking at Framework such as laravel,Yii,cakephp etc.Please make it very powerful such as this frame work. Because we love wordpress never wan’t to down when compare with these frameworks .

        • transl8or 5:11 pm on August 27, 2015 Permalink | Log in to Reply

          I don’t think it looks old.
          It’s very very classical, kinda puristic und could be quite elegant with good pictures.

          Nevertheless I have two concerns about this theme:

          • The Frame; especially when it’s black, the site could somehow look like a newspaper obiatury.

          So I hope the customizer options will support a checkbox or simular to switch the frame on or off.
          Or maybe even have it only left & right vs. top & bottom.
          Or just choose the frame color individually so that it will be the same as the background color.

          • The Primary Menu; especially in the desktop version.

          I’m often very unhappy with lot’s of menus within WordPress Themes because they seldom look kinda “design consitent” for the whole site nor for bigger websites with lots of pages (not blogs, with mainly posts and infinite scroll).
          The later comes mostly with horizontal menu.

          — —

          As a suggestion for this theme, I could imagine a “sidebar integrated” menu, like you can see it in the Ascetic theme see here:
          http://demo.alienwp.com/ascetica/
          Could be a challenge with a full-width page, or pages with full-width header-image though.

          Or a menu like the Materialist Theme uses, see here:
          https://wordpress.org/themes/materialist/
          But on the upper right side.

          I like simplicity of the menu in the Libre Theme and the Theme in general;
          but it still has the issue of going “white over white, or even over content” when you create a site with a menu that has loads of items and levels.

          — — —

          Talking about the Materialist Theme brings me to the next topic.

          A more modern design approach for Twenty Seventeen?!?

          How about Material Design, Semi Flat Design, more colorful options and/or a “lighter, thinner, more playful & transparent look” for the menu/navigation, input-form elements and fonts.
          Oh, and I’d like to see an option in the Customizer for the primary menu to either be a “fixed navigation bar” or not more often.

          Examples:

          http://www.nuabikes.com/

          http://www.brindisatapaskitchens.com/

          http://revelator.com/

          http://www.wonderfullywild.co.uk/

          https://niice.co/

          http://branding.cards/

          http://simplehonestwork.com/

          http://evandorlot.com/portfolio/naaataa-fashion-branding/

          Google Resources on “Material Design”:

          https://www.google.com/design/spec/material-design/introduction.html

          :)

        • sonofara 2:46 am on August 28, 2015 Permalink | Log in to Reply

          20Sixteen is clean, responsive and is definitely a perfect startup template which can be transformed into an eye catching website.

      • chrishoward 5:50 am on August 26, 2015 Permalink | Log in to Reply

        Yes. Reminds me of 2012.

        I think the main prob is the sidebar. That sort of stuff is all in footers in modern designs.

      • stuk 3:22 pm on August 26, 2015 Permalink | Log in to Reply

        +1

    • Lara Littlefield 3:16 pm on August 25, 2015 Permalink | Log in to Reply

      I’m so excited to have photos displayed in such a unique way like this in a default WordPress theme. 2016 is beautiful!!

    • Helen Hou-Sandi 3:18 pm on August 25, 2015 Permalink | Log in to Reply

      Woohoo! I’ve still got that musician bias – like Twenty Fifteen, this looks like it can serve as a really solid base for portfolio sites, especially with some creative thinking around colors and content.

    • web2033 3:23 pm on August 25, 2015 Permalink | Log in to Reply

      Happy new 2016 ^_^

    • Mel Choyce 3:24 pm on August 25, 2015 Permalink | Log in to Reply

      <3

    • Matthew 3:26 pm on August 25, 2015 Permalink | Log in to Reply

      awesome stuff

    • Philip Arthur Moore 3:27 pm on August 25, 2015 Permalink | Log in to Reply

      Happy to help do some theme breaking. Can’t wait to see this land. Takashi’s designs…are they ever not amazing? Another hit; cannot wait to see this on millions of sites. Great work gang.

    • Ihor Vorotnov 3:35 pm on August 25, 2015 Permalink | Log in to Reply

      One more blog theme with a font that looks ok only with latin characters? Looks nice, but… Come on guys, there’s life outside US. There are other languages out there. WordPress is not only for blogs anymore.

    • Ajay 3:40 pm on August 25, 2015 Permalink | Log in to Reply

      This is definitely looking very clean. Twenty Fifteen was OK look wise, but this definitely looks like a worthy base for any new site.

    • Nick Halsey 3:48 pm on August 25, 2015 Permalink | Log in to Reply

      I’m honestly not a fan based on the screenshots, but that’s okay – even a default theme shouldn’t try to satisfy everyone. Something feels off with it for me.

      Based on the way the colors seem to work, again based on the screenshots, we should probably explore making the text colors auto-generate to light or dark based on the selected background color, for simplicity and to minimize contrast issues. The Fourteen Colors plugin for Twenty Fourteen does something similar.

    • Chrisdc1 3:51 pm on August 25, 2015 Permalink | Log in to Reply

      Looks good, I’d be interested in helping as well,

    • Ahmad Awais 4:02 pm on August 25, 2015 Permalink | Log in to Reply

      I’d love to contribute.

    • Sakin Shrestha 4:03 pm on August 25, 2015 Permalink | Log in to Reply

      Looks really nice and clean. Would love to contribute… Thanks

    • Donna Fontenot 4:18 pm on August 25, 2015 Permalink | Log in to Reply

      This is exactly what WordPress does NOT need. Another boring, snoozefest old-school blog layout. Wake me when WP joins the rest of the world in 2015 and beyond. (BTW, I tried really hard to come up with a nice way to say that, and I just couldn’t, so here is the comment in all its straight-forwardness.)

    • MRWweb 4:25 pm on August 25, 2015 Permalink | Log in to Reply

      Let’s get some alt text in that image gallery! #a11y

      There are some really nice touches in the screenshots. I like the pull quote a lot (though wonder how it will be applied with the editor).

      At some point, I’d love to hear the core team be a little clearer on how the new theme is selected and why there have been two blog themes in a row. (It also might not be too late to add an interesting static front page option to Twenty Sixteen to make it more versatile!) I tend to follow this stuff and had no clue this process was happening. I certainly understand the need for fewer cooks in the kitchen, but at least letting some more people suggest ideas for priorities might be nice. Maybe even a poll or two.

      I’ve heard for years now many people clamoring for a “new Twenty Twelve” and still hope to see another “CMS” theme as a default soon. (It’s remained quite popular: https://docs.google.com/spreadsheets/d/1UV4UGFCdTdNhK8v7l9s6J0uI5Y-QMRocSET63NO3CVc/edit?usp=sharing)

      • Nick Halsey 7:11 pm on August 25, 2015 Permalink | Log in to Reply

        You’re not missing anything – there is a complete lack of transparency in the default theme process prior to the “announcement” posts. Even frequent contributors have heard absolutely nothing about it prior to today.

        My biggest complaint is that we have now had the same designer do the last three default themes. Takashi’s work is amazing, but it’s definitely time to give someone else an opportunity to fill this role as has been done in the past. Since the extremely outside-the-box Twenty Thirteen, we’ve gone back to progressively less and less compelling designs with each default theme.

        • MRWweb 8:59 pm on August 25, 2015 Permalink | Log in to Reply

          > Takashi’s work is amazing, but it’s definitely time to give someone else an opportunity to fill this role as has been done in the past.

          I agree. Even if Twenty Fifteen—which I like quite a bit—were by the objectively best designer in the world (that is not a thing, but for the sake of argument…) the core team should be doing more to promote and diversify the designers who show what WordPress can do and be. The idea that there aren’t other designs who can do this—and wouldn’t drop all sorts of other commitments if given the chance!—just doesn’t make sense.

          I hate being negative in what is an otherwise worthwhile celebratory post and call-to-action, but I really hope this can stop being so untransparent and homogenous.

    • Felix Arntz 4:26 pm on August 25, 2015 Permalink | Log in to Reply

      Plain and simple – and great. Looking forward to replace Twenty Fifteen on my blog :)

    • Emil Uzelac 4:30 pm on August 25, 2015 Permalink | Log in to Reply

      So Fresh, So Clean!

    • Nilambar Sharma 4:31 pm on August 25, 2015 Permalink | Log in to Reply

      Simple and nice. I am willing to contribute… :-)

    • voldemortensen 4:48 pm on August 25, 2015 Permalink | Log in to Reply

      Is there a way to get involved with this *before* it lands in core? I am a frequent core contributor and I have Slack open all day. I’ve heard nothing about this until literally a few minutes ago.

    • Shapeshifter 3 5:12 pm on August 25, 2015 Permalink | Log in to Reply

      “The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.”
      @iamtakashi

      I like the concept !

      Is there any way to download the current alpha version of this, so I can upload it to my own website to preview it with my own personal content?

      I’m interested to know what the current Theme Customizer currently offers in Content (width) and Layout options.

    • Orangedrop 5:16 pm on August 25, 2015 Permalink | Log in to Reply

      For once purely based on screens I don’t know if I’m down this ! That said you can’t please everybody all of the time :) I would love to get my grubby mitts on it and break it a few times so please count me in ! Thanks guys and as always keep up the awesome work.

    • Brent Jett 5:39 pm on August 25, 2015 Permalink | Log in to Reply

      I’d like to know more about how this theme will be implemented in terms of customizer fields, editor styles, custom widgets/shortcodes etc… I’m a big believer in designing themes for the WP user as much as the reader. Where are these discussions currently being had? Is this project on github somewhere?

    • dannybrown 5:54 pm on August 25, 2015 Permalink | Log in to Reply

      Yawn. Sorry, but this design (as far as looks goes) is so 2012.

    • dshanske 6:15 pm on August 25, 2015 Permalink | Log in to Reply

      I would be interested in ensuring that the theme is microformats compliant.

    • Gaurav Tiwari 6:20 pm on August 25, 2015 Permalink | Log in to Reply

      Make it look like commercial themes. If WP is no longer blogging focused CMS why should the default themes be?

    • LittleBigThings 6:36 pm on August 25, 2015 Permalink | Log in to Reply

      Cool and clean, a bit Twenty Twelve-like. Hope to see some unique features in the Customizer. I would love to follow it up and help out testing.

    • Tomas Mackevicius 6:41 pm on August 25, 2015 Permalink | Log in to Reply

      Looks great! Can we see live demo?

    • Karthikeyan KC 6:44 pm on August 25, 2015 Permalink | Log in to Reply

      To be honest, twentyfourteen looks better than twentysixteen. Anyways, it’s good for the default one. :)

    • Tomas Mackevicius 6:52 pm on August 25, 2015 Permalink | Log in to Reply

      But 2014 was not built on _s, I hope 2016 is.

    • WebMan Design | Oliver Juhas 7:07 pm on August 25, 2015 Permalink | Log in to Reply

      Looks great, very clean! I’d like to contribute too :)

    • SanjayaBhai 7:10 pm on August 25, 2015 Permalink | Log in to Reply

      Twenty sixteen.. Hope it will be great…. But please make this themes more modern/Beautiful … It’s seems classic .

    • Alex Mills (Viper007Bond) 7:25 pm on August 25, 2015 Permalink | Log in to Reply

      It’s been a long time since I’ve run a default theme but I’ll be switching for this one!

    • George Stephanis 7:28 pm on August 25, 2015 Permalink | Log in to Reply

      I’m pulling for twentyseventeen to be Kubrick redone responsively. :)

      • Ryan Hellyer 9:42 am on August 26, 2015 Permalink | Log in to Reply

        I’ve been toying with forking Kubrick like that for many years now, but never gotten around to it.

      • Drew Jaynes 8:41 pm on August 26, 2015 Permalink | Log in to Reply

        FWIW, I already did it. I created a child theme for Twenty Twelve called Nubrick, that created a responsive version of Kubrick. The header used CSS gradients and everything else was matched to a tee with some obvious improvements. Might have it laying around here somewhere, have to look.

    • Tarik Cayir 7:59 pm on August 25, 2015 Permalink | Log in to Reply

      That’s sweet and incredible!

    • Morten Rand-Hendriksen 8:14 pm on August 25, 2015 Permalink | Log in to Reply

      Sign me up. I’ve done a lot of work with pull-images of the kind proposed here and know some of the pitfalls. I’ll contribute what I can and where it helps.

    • Valeriu Tihai 12:14 am on August 26, 2015 Permalink | Log in to Reply

      Happy to help

    • WP Sites - Brad Dalton 1:37 am on August 26, 2015 Permalink | Log in to Reply

      How about a widgetized page template which can be used as the front page. Widgets in columns are popular and so are full width sections. The genesis sample child theme is hugely popular because you can easily add custom functionality unlike any of the default themes.

    • Matt (Thomas) Miklic 2:03 am on August 26, 2015 Permalink | Log in to Reply

      This is a beautiful theme and I can’t wait to use it myself.

    • Aaron Brazell 2:13 am on August 26, 2015 Permalink | Log in to Reply

      I like the image offset a lot and I want a one-column option, so glad to see that in there. Agree with previous commenters saying it looks a bit dated, but I also don’t think that’s twntysixteen per se… I think the “blog layout”, which is a guiding principal, is a bit dated. I’d love to see twentyseventeen place less emphasis on text content, top down, left-right, sidebar, header and more of a focus on rich media. Photographs, videos, etc… with natural integrations (no external APIs) with social content (and not just FB and Twitter)… it’s such a rich internet, but the blog approach to the project might be influencing the frontend a bit much and not keeping up. :)

    • nick6352683 2:38 am on August 26, 2015 Permalink | Log in to Reply

      Anything, and I mean anything would be better than 2013, 2014, and 2015. I prefer 2012 over those, and 2016 seems more or less in line with 2012. The whole discussion is pretty much mute for me, as I always opt to use “premium” type themes, with tons of bells and whistles, but I’m very biased as I develop my own themes, with extra functions and shortcodes.

    • webdevmattcrom 3:33 am on August 26, 2015 Permalink | Log in to Reply

      Definitely interested in contributing, sign me up!

      I love that this does feel like it’s heading back toward a cleaner Twenty Twelve feeling. I like that the sidebar is on the right by default, but especially considering RTL it would be nice to have a Customizer option to put the sidebar on either side. In that vein, since the Customizer is getting more and more prominence it would be great to see this theme really flaunt some great aspects of the Customizer as a strong example of “Decisions not Options” while still providing flexibility in look and feel.

      Looking forward to seeing this come to life.

    • Amit Kvint 6:32 am on August 26, 2015 Permalink | Log in to Reply

      Definitely interested in contributing, sign me up too!

    • Brian Krogsgard 7:12 am on August 26, 2015 Permalink | Log in to Reply

      Is Ian Stewart the default theme lead?

      There is obviously a lot of decision making going on in regard to default theme design that nobody really knows about, and it is really confusing. It is so different than the rest of WordPress development.

      So, how would someone go about getting involved earlier in the process (at the design level!), short of going to Matt Mullenweg? I might add that going to Matt on how to get involved (though he appears the primary gatekeeper on default theme design) is likely quite intimidating for most folks.

      A lot of talented designers would probably like to get involved in this process but don’t know it’s possible or how to start. Some information and light on the process itself would be most welcome, I’m sure.

    • Philip Arthur Moore 8:55 am on August 26, 2015 Permalink | Log in to Reply

      The fact that there are so many passionate responses here is pretty cool.

      History time:

      Default themes won’t be for everyone, and ultimately I share Brian’s thoughts above. I think it’d be GREAT for 10000% transparency around the default theme making, designing, and proposal stages before posts like this are made. (Honestly it makes no difference to me personally but the community seems to benefit quite well from feeling like we have a chance to contribute to such a public and front-facing piece of WordPress.)

      But that aside, however the theme came to be, I think the first drafts shared are quite nice and absolutely cannot wait to help break things once it lands into Core. I’ve no doubt that there are some pretty serious design and development challenges that will come out of these drafts, and it’s going to be exciting to take part in that.

    • Subharanjan 9:04 am on August 26, 2015 Permalink | Log in to Reply

      Clean and Simple !! Looks awesome :)

    • Fotis 9:20 am on August 26, 2015 Permalink | Log in to Reply

      Perfect.

    • Ryan Hellyer 9:46 am on August 26, 2015 Permalink | Log in to Reply

      I like this new design. Simple, yet elegant.

    • stuk 10:24 am on August 26, 2015 Permalink | Log in to Reply

      To me it seems quite outdated and useless as any default theme, is it not?
      Quite clear that their intention is not to add extra features to WordPress, and indeed the basic theme can support only a maximum basic options.

      But also simply bad design. If it’s the preview we let people install with the system, so it seems bad.
      Nothing to do with new design trends.
      Despite the WordPress developers insist that the system is already more than a blogging system infrastructure, they continue to release static templates without AJAX and without REST, and yet the basic theme is a theme of a blog, not a website.

      In one word: shame.

    • David Bennett 11:42 am on August 26, 2015 Permalink | Log in to Reply

      It reminds me of Linen from TheThemeFoundry, and it has the open, airy look of themes from ElmaStudio. I like it. The only thing I wonder about are the horizontal dividers in the sidebar. The Daily Dish theme from StudioPress has black sidebar dividers overpower the theme somewhat. The dividers in The Daily Dish are thicker but if a blogger has a lot of widgets it can start to look like the i Ching.

    • Elisa 12:19 pm on August 26, 2015 Permalink | Log in to Reply

      I like it :)

    • CYBERsprout 1:28 pm on August 26, 2015 Permalink | Log in to Reply

      Looks great! A very modern design.

    • ldbaldwin 2:43 pm on August 26, 2015 Permalink | Log in to Reply

      I would be interested in contributing on some leve, (testing, documentation, etc.). Thanks!

    • cramdesign 2:47 pm on August 26, 2015 Permalink | Log in to Reply

      I think it looks great. The structure is a traditional setup but I think that the overall design, typography and image handling is very current. I agree that the dividers in the sidebar might be a little too heavy but, then again, that is easily changed with css and let’s be bold every now and again.

    • firewatch 3:34 pm on August 26, 2015 Permalink | Log in to Reply

      I’m interested in contributing, thanks!

    • djsteveb 9:20 pm on August 26, 2015 Permalink | Log in to Reply

      Wish all the like and dislike comments could be removed here. Give specifics or save the screen space.

      Sorry ya’ll but the default theme does not need to be any one person’s idea of pretty or modern, it’s default and certainly not the only option for anyone running wp.

      What the default themes have been lacking since 2012(?) is documentation, transparency, and support.

      All that fancy responsiveness is fine if you like things as is. Simply trying to move the left sidebar to the right with 2015 is a nightmare – I miss the days of simply change float left to float right.

      Yes I know, “modern design” is beyond that – I have learned how to move things around with bootstrap, and foundation… moving things with 2014 / 15 is a joke. No documentation, no support – no transparency with updates.

      Either given backend option for the most common changes, or make it easier for people to change things with code. Having to make edits and then change screen sizes and search for ways to change rules for each media query is a joke, with no docs, and no warnings about updates.

      Given that the default theme is the only thing we can count on that will get any kind of support from buddypress, rtmedia and other plugins – many are indeed stuck with the default theme base – pretty or not – those things can be adjusted if the options are understood, documented, supported.

      My comment on takshi’s site still waiting moderation (August 25, 2015 at 12:37 am ) – maybe it’s akismet limbo. Support on the wp repo is total confusion – even other professional sites that created right sidebar child theme break with basic background color change – is it them? Is it the theme? Was it working then an update fixed something and broke others?

      I am happy to contribute what I can (20% through my php course!) – I was planning to make a video tutorial from the text how-to for making themes at themeshaper.com – however it states it’s outdated. I stumbled across a trello that has documentation for theming in the works – but that may be finished in 2017?

      Given that the default theme has total power over so many things WP – I prefer no java, nothing complex, basic – make it easy to mod it so people can make it prettier and modern on their own. Not left in limbo choosing no support, no docs with wp plugins that work (and look basic) – or get a theme that looks better is modifiable – but then does not work with plugins and gets no love or support from plugin systems.

      Frankly the older default themes were much easier to make better. Anything default that is complex is just going to shrink the amount of WP users that can actually mod something on their own without a degree in javascript and php. You might as well force us to use sass and less and bower. Really shrink the amount of people that can enhance a basic default theme.

      Maybe pull all the extra stuff out and make it an option plugin like some do with “jetpack features” – I just want BP to work with something that can be modded – either with lots of backend theme options (colors, sidebar on, sidebar off, move to footer – basic stuff really, or easy css that the average person can figure out or get basic support from the community to figure out. (please take out all third party bloat, eg- google fonts, gravatar, emoji and put them as optional plugins, pretty please!)

      Or convince BP and rtmedia (and others) to work with / provide support themes based on bootstrap and or foundation – then the default theme can be whatever it wants to be and we can peruse the documentation for those frameworks, and make adjustments easily.

      Sorry to long rant, (and I started with ‘save the screen space – seriously sorry, very frustrated with all this!) I want to see WP, and things associated with it continue to succeed, however I concur that many of the past two years’ not-so-transparent decisions have not made this easy for most of the average users IMHO.

      • rahul286 5:40 pm on August 28, 2015 Permalink | Log in to Reply

        I am from rtMedia team.

        I like your idea of themes using a base js/css framework like bootstrap and or foundation. But our reason for supporting default themes is they work nicely with BuddyPress as well as other plugins. Mainly because many plugin developers also check test plugins with default themes.

        That being said, our inability to support most themes is mainly because most themes are not tested with BuddyPress. In fact wordpress.org only shows 28 themes that claim to support BuddyPress – https://wordpress.org/themes/tags/buddypress/ and 1 of them is default theme and 1 other (rtPanel) is our theme.

        • djsteveb 9:52 am on August 29, 2015 Permalink | Log in to Reply

          @rahul286 – Thank you for chiming in on this issue. I don’t expect your team or any other to have the ability to support every edge case theme created for wp, and I am glad you guys at least make an effort to keep rtmedia working with whatever updates get pushed by automattic at least. Your media plugin is the only reliable way for buddypress users to get picture and other media uploads, so it’s continuing functionality is imperative.

          It is sad there are so few themes tagged to work with BP – of course there are many that do work with bp and yet they are not tagged that way in the repo – and there are several that are available outside the wp org system – however my experience has been that we can not count on other themes to work with bp and rtmedia properly no matter where they are from. I have tried 24 of those you mentioned 😉

          This is exactly why I feel a new default theme must be carefully considered, and it should be easier to modify than the past two – as we are indeed basically stuck using 2014 / 2015 /2016 for bp sites or gamble with lots of things not working – and no support or docs to fix things. This is not an rtmedia fault – it’s just where things have gone with bp in general I guess.

          There are some who think my thoughts on this are 100% wrong, at least one person replying to a similar comment I made in regards to these issues at wp-tavern – ( http://wptavern.com/first-look-at-the-twenty-sixteen-default-wordpress-theme#comment-72326 ) – however I think people have not seen the amount of support that has been needed to keep self hosted wordpress sites with plugins working properly with major updates and the basic issues that revolve around the default theme, and those that vary from it, is the starting point for almost every issue bp / rtmedia and many others plugins breaking with users sites.

    • Marcus Tibesar 11:26 pm on August 26, 2015 Permalink | Log in to Reply

      IMO there is too much white horizontal space between the gravatars and the content.

    • Marcus 9:44 am on August 27, 2015 Permalink | Log in to Reply

      I would love to help out

    • weblizar 11:38 am on August 27, 2015 Permalink | Log in to Reply

      Hi,Like to contribute.

    • abe_charles 12:43 pm on August 27, 2015 Permalink | Log in to Reply

      Have to say that Twenty Sixteen default theme is very weak. It deserves to be placed on life support because it looks like something created in 2010. It’s plain black and white by default with options for different colour options but still quite stale.

      I thought Twenty Fifteen was poor but looking at Twenty Sixteen it’s as if WordPress is taking two steps backward by presenting this piece of crap. You have a disgruntled blogger in me and this theme ain’t gonna fly. At least you have a few more months before the year 2016 so get back to the drawing board and change the direction of this theme. It’s too late for April Fools.

      Repeal, repeal and stop making the images fall off the page. That’s frustrating. Come with a better theme.

    • Mel Choyce 8:22 pm on August 27, 2015 Permalink | Log in to Reply

      I think it’s important for people to remember that this theme was made by a real, live person. Disparaging contributors and their work is inappropriate and not welcome in this community.

      You are welcome to your opinion, but if you want to give feedback, please keep that feedback respectful and constructive. Critiquing the design and the default theme building process is fine. Calling this theme “crap” or “useless,” however, is not constructive feedback and not appropriate for these contributor blogs. As Matt Miklic mentioned, that kind of feedback is abusive and unhelpful.

      Here’s how to structure good design feedback:

      • Empathize. Remember that behind every design is a person. If you wouldn’t say it to this person’s face, don’t say it here.
      • Start with “I think…” and finish with “because…”
      • Comment on particular elements that don’t work in the design, like the typography, colors, hierarchy, and composition. Try to be as specific as possible.
      • Stick to goal-oriented feedback: “This theme can become a better default theme for more users if it did [x], [y], and [z].”
      • Frame feedback as suggestions, not mandates. “What if you…” and “How about if you tried…” are great ways to present alternate ideas to a designer.

      Thanks for helping us keep WordPress a positive place to contribute.

    • abe_charles 12:44 pm on August 28, 2015 Permalink | Log in to Reply

      Apologies for the insensitive remark. I never meant to cause offense, I thought that the opinion was valid but it went too far. It’s just that I have been waiting for Twenty Sixteen theme for a few months and to see what it will look like or what it looks like I am disappointed. It does need work for real. It’s too plain and looks like not much thought was put into it. It’s rather plain and basic. I was expecting Twenty Fourteen 2.0 or Twenty Fifteen 4.0

    • modparlor 2:01 pm on August 29, 2015 Permalink | Log in to Reply

      Neat. Looking forward to this new minimalist theme. One request though: Could you please add in a font-switcher into the customizer. A thing desperately lacking in the 2015 theme IMHO. I can add in my own fonts, I know, but a dropdown with a set of 30+ Googlefonts would be easyer for quick tryouts.

      That aside, thanks for the neat themes and the ongoing work on WP.

  • Scott Taylor 3:58 pm on August 19, 2015 Permalink |
    Tags:   

    WordPress 4.4: What’s on your wishlist? 

    4.4 has unofficially kicked off, now that 4.3 is out the door. As with any release, we want to garden Trac, squash bugs, add new tools for dev, and wow our users.

    I have spoken to many of my fellow core contributors about their own wish lists. Now, it’s your turn:

    • What do you want to see happen in 4.4?
    • What are pain points for users?
    • What features can we add or iterate upon to empower our user base?

    It can be anything: big or small.

    As most of you know, I am leading WordPress 4.4

    If we’ve never met, hello! You can learn a lot about me here:

     

     
    • Justin Sainton 4:04 pm on August 19, 2015 Permalink | Log in to Reply

      Biggest hope for me is that we’ll see the REST API actually land in core. Anything that can be done to that end, I think, would be the biggest win for 4.4.

      Sidenote: SUPER excited for you leading this release. It’s going to be epic :)

    • Nicolas Juen 4:05 pm on August 19, 2015 Permalink | Log in to Reply

      Infinite child themes, handled by a Walker or something like this.
      Metadata API functionnal and usable. On terms too.

    • pro99 4:06 pm on August 19, 2015 Permalink | Log in to Reply

      Two factor auth built into WordPress or JetPack,using a standard code generator e.g. Google Authenticator, would be great.

      • George Stephanis 4:13 pm on August 19, 2015 Permalink | Log in to Reply

        Howdy! We’ve got a group working on that as a feature plugin for core right now!

        https://github.com/georgestephanis/two-factor

      • Monika 4:24 pm on August 19, 2015 Permalink | Log in to Reply

        I never use a third party two factor auth built. Neither jetpack ( at austria we are not allowed to use this plugin due our private protect law) nor Google…

        • George Stephanis 4:26 pm on August 19, 2015 Permalink | Log in to Reply

          Google Authenticator is actually just an implementation of the RFC 6238 TOTP Standard — https://tools.ietf.org/html/rfc6238 — anything that uses Google Authenticator can use other code generators just as easily, such as Authy.

        • Bego Mario Garde 7:19 am on August 20, 2015 Permalink | Log in to Reply

          @Monika “at austria we are not allowed to use this plugin due our private protect law…” – As far as I know, you can still use Jetpack in developer mode (i.e. with direct access to w.com disabled) though?
          I also doubt that two factor authentication for a user login would affect privacy protection for website visitors.

          • Monika 7:50 am on August 20, 2015 Permalink | Log in to Reply

            yes, we can use Jetpack in developer mode, but user “john doe” doesn’t know how and why :-). So it is better to say: don’t use it. It is really expensive if someone is taking you to the court!

            • atomicjack 2:48 pm on August 20, 2015 Permalink

              Privacy laws don’t restrict the use of two-factor authentication.

              They just provide an alternate, more secure method of authenticating a user – they do not transmit any personally identifiable information, at most, a username and token.

    • nicholas_io 4:08 pm on August 19, 2015 Permalink | Log in to Reply

      Congrats Scott.

      If possible, I would love to see Fieds API into core on 4.4.

    • kraftner 4:11 pm on August 19, 2015 Permalink | Log in to Reply

    • electricbrick 4:12 pm on August 19, 2015 Permalink | Log in to Reply

      Fixing the media attachments export bug would be HUGE. It’s been an open bug in Trac for 4 years. 4 YEARS.

      https://core.trac.wordpress.org/ticket/17379

    • dpegasusm 4:15 pm on August 19, 2015 Permalink | Log in to Reply

      Would be awesome to finally see a way to sort media when uploading. There has been discussion of it and a highly rated idea here:

      https://wordpress.org/ideas/topic/how-about-ability-to-sort-media-by-saving-them-into-folders-when-uploading

      • Mel Choyce 4:18 pm on August 19, 2015 Permalink | Log in to Reply

        What if you could tag media? Same kind of concept, but a bit more flexible since you could put media into multiple groups.

        • Andy Mercer 4:23 pm on August 19, 2015 Permalink | Log in to Reply

          Tagging and then creating pseudo-folders via the tags would be ideal, as long as there was an easy way to sort, graphically, with drag and drop simulating “moving”, though really just changing tags.

          • trailness 9:45 pm on August 19, 2015 Permalink | Log in to Reply

            +1. We have thousands of uploads and it’s hard to even sort through and remove old items that should have died years ago. Tagging would help immensely.

            • dantewaters 5:45 am on August 30, 2015 Permalink

              Agreed, it would be great if they could be sectioned off (where you still see them but they are sectioned by months). Similar to photos on IOS where the images are sorted by location.

        • rkoller 4:45 pm on August 19, 2015 Permalink | Log in to Reply

          That would be useful!

        • Dave Navarro, Jr. 5:11 pm on August 19, 2015 Permalink | Log in to Reply

          +1 to this, I am using a third-party plugin now to add a custom taxonomy to media uploads. With over 300 users posting stories and uploading media on a weekly basis, this is critical to media management.

        • Helen Hou-Sandi 5:17 pm on August 19, 2015 Permalink | Log in to Reply

          “Media library filtering” is written on my whiteboard behind me. I’d love for searching to do better matching – we’ve tried and it has a ton of gotchas, but it would be worth trying again early in a cycle.

        • dpegasusm 5:59 pm on August 19, 2015 Permalink | Log in to Reply

          Tagging would help the items and seeing that media is just a post type shouldn’t be that difficult to implement. Could this be turned into a feature plugin item? i would love to help on it.

        • fatpat76 6:37 pm on August 20, 2015 Permalink | Log in to Reply

          +1

      • kkalvaa 7:02 am on August 20, 2015 Permalink | Log in to Reply

        Folders sounds like a good idea until you have a system with hundreds of badly named folders with a less and less consistent system. The flat system media system of WordPress is a lot better than folder based media.

        A tag based system to help filter would however be quite good.

      • Christian Ruggeberg 8:04 am on August 20, 2015 Permalink | Log in to Reply

        +1 Any kind of a better media handling / overview / management is almost one of the greatest wish from the users i support!

      • Alvaro Gois dos Santos 11:25 am on August 21, 2015 Permalink | Log in to Reply

        +1

      • Michaela 7:14 am on August 24, 2015 Permalink | Log in to Reply

        This would also be one of my favorite wishes to WP 4.4: Having the possibility to sort Media Uploads in different folders, tagging Media and Rename Files after Upload.

      • chatmandesign 5:11 pm on August 28, 2015 Permalink | Log in to Reply

        Agreed. Folders, tagging, some way to sort Media is desperately needed.

    • Hapiuc Robert 4:18 pm on August 19, 2015 Permalink | Log in to Reply

      Big news i see, one UX issue i have discovered today with a client was sortable terms. I think it will be great to have sortable terms in the new WordPress version.

      Also better mobile detection for mobile devices will be great.

    • Josh Levinson 4:19 pm on August 19, 2015 Permalink | Log in to Reply

      Term Meta would be great!

    • Seth Rubenstein 4:20 pm on August 19, 2015 Permalink | Log in to Reply

      Shortcake completion and in core is the biggest thing we should focus on in 4.4.

    • jadpm 4:20 pm on August 19, 2015 Permalink | Log in to Reply

    • PeterRKnight 4:25 pm on August 19, 2015 Permalink | Log in to Reply

      • Rest API
      • term meta
    • Eric Binnion 4:26 pm on August 19, 2015 Permalink | Log in to Reply

      Under the hood, it would be nice if we could factor out some of the logic that handles new users and invites in `wp-admin/user-new.php`. This would make it a bit easier for us to create endpoints for that functionality. I’m glad to help with that.

      On a related note, I have a ticket in that adds an action for when a user is invited. https://core.trac.wordpress.org/ticket/33008. This would be of use to us on WordPress.com so that we could send notifications.

    • Spacedmonkey 4:27 pm on August 19, 2015 Permalink | Log in to Reply

      My wish list is very developer

      • Shortcake
      • Term meta
      • Rest API
      • Post statuses
      • shawfactor 1:15 pm on August 20, 2015 Permalink | Log in to Reply

        Term meta is not required. Once you add meta to a term you might as well have a post. WordPress would be better served by adding the ability to create relationships between posts.

    • thomaswm 4:28 pm on August 19, 2015 Permalink | Log in to Reply

      No more mixed content when accessing a WordPress website via HTTPS. The scheme of the src-URLs of embedded images should adapt automatically to the scheme of the page URL.

    • WP Sites - Brad Dalton 4:35 pm on August 19, 2015 Permalink | Log in to Reply

    • Schwarttzy 4:35 pm on August 19, 2015 Permalink | Log in to Reply

      Sanatize function for choice in customizer

    • Shapeshifter 3 4:35 pm on August 19, 2015 Permalink | Log in to Reply

      Complete the integration of the RICG Responsive Images Plugin into the core AND possibly increase the current number of standard Media Size options available to match breakpoints. See this to see what I’m talking about:
      https://wordpress.org/support/topic/the-future-use-of-breakpoints-in-this-plugin-and-wordpress?replies=1
      (and I might be wrong).

      My thought is make WordPress core fully Mobile First responsive regardless of any theme used.

      • rkoller 4:40 pm on August 19, 2015 Permalink | Log in to Reply

        i’ve suggested an improved way to handle breakpoints for the RICG responsive images plugin a while back. it got closed due to the scope for the plugin but i still think it would be an useful addition and possibly relating to the things you’ve suggested and wanted:
        https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images/issues/45

        • Shapeshifter 3 4:59 pm on August 19, 2015 Permalink | Log in to Reply

          rkoller,

          Really good thought process on your end (much more orderly than mine)!

          Maybe the plugin needs to remain separate, but the core developers might be able to revisit the Image Sizes Media Settings and rethink their usage.

          Maybe in the back of my head, I was thinking that the core could have a wide-spectrum standard set of breakpoints automatically preset for theme developers and end users similar to Google is doing.

          • rkoller 5:07 pm on August 19, 2015 Permalink | Log in to Reply

            Yep ithings should be kept separate between the actual plugin functionality and the handling of image size creation and so on imho. but i wouldnt clutter the interface with too many automatical presets. that would just raise confusion. i would rather stick more or less to my suggested approach. it is unobstrusive. as default wordpress behaves more or less the same like today but with the suggestions from the issue the flexibility could be leveraged tremendously as well as the number of megabytes saved on the server raised significantly.

      • Scott Taylor 12:49 pm on August 25, 2015 Permalink | Log in to Reply

        Responsive Images are on my mind for 4.4

    • pingram3541 4:42 pm on August 19, 2015 Permalink | Log in to Reply

      shortcake/shortcode – ability to nest same name shortcode, would be great for columns/containers. There is a light weight regex hack floating around on stackexchange somewhere

      Plugin hook for page/post template, let plugins get in on the design regardless of theme

      Term meta

      Rest API

    • Scott Kingsley Clark 4:44 pm on August 19, 2015 Permalink | Log in to Reply

      • Rest API
      • Term meta
      • Fields API :)
      • Shortcake
    • schlimpf 4:44 pm on August 19, 2015 Permalink | Log in to Reply

      Native multi-domain support for network installations.

      This feature is missing way too long now.

    • Ryan Kanner 4:48 pm on August 19, 2015 Permalink | Log in to Reply

      • Rest API
      • Term Meta
    • tharsheblows 4:51 pm on August 19, 2015 Permalink | Log in to Reply

      Scaling Users on single installs as well as multisite.

    • andreasnrb 4:53 pm on August 19, 2015 Permalink | Log in to Reply

      Custom comment types #12668

      • dshanske 6:34 pm on August 19, 2015 Permalink | Log in to Reply

        I will give a +1 on this. Better functionality around comment types would be great.

        • Setzfehler 3:05 pm on August 25, 2015 Permalink | Log in to Reply

          Yes, and by the way a possibility to decide what to show in recent comments widget: only personal comments without track- and pingbacks, or all comments including track- and pingbacks!

    • Brent Jett 4:56 pm on August 19, 2015 Permalink | Log in to Reply

      It’d be great if Customizer had some notion of “Saved sessions” or settings presets where you could preview multiple configurations, select a favorite, or save groups of settings to come back to later. Also themes might offer various configurations or looks this way. And also:

      • Shortcake
      • Rest API
      • Customizer Partial Refresh API
      • Customizer Repeater/Collection Control
      • Nav Menu Item Metadata (and nav menu admin hooks for fields)
    • Doug Wollison 5:02 pm on August 19, 2015 Permalink | Log in to Reply

      I’d like to see some further improvements to the media manager, such as adding a media taxonomy out of the box for organizing; integrated into core rather than still reliant on plugins.

      Also, I think the Settings API, specifically options.php, should be adjusted to allow for settings saved from certain pages to not require the manage_options capability. I like using the API for easily building admin pages with settings fields, but it’s annoying how even though I can set a capability requirement for getting to the page, I can’t set one for actually saving the options manageable on that page. Maybe also add a version for more easily registering custom meta fields on users.

      I’d also like to see term meta would be awesome, along with an order manager UI for pages and other hierarchical post types, and filtering said post types by parent.

      Oh, I can’t recall, but do post revisions include meta data? That would be good to have if not already.

    • Jonathan Desrosiers 5:10 pm on August 19, 2015 Permalink | Log in to Reply

      Adding WP_Tax_Query support to WP_User_Query: https://core.trac.wordpress.org/ticket/31383

      Progress towards term meta (https://core.trac.wordpress.org/ticket/10142) would be nice too!

    • rkoller 5:12 pm on August 19, 2015 Permalink | Log in to Reply

      A complete Multilingual API. So far only interface microcopy is localizable but it would be nice if it could be extended to the content as well that there isnt a need for a plugin to do the heavy lifting. WordPress should be able to do that out of the box.

    • Nick Halsey 5:15 pm on August 19, 2015 Permalink | Log in to Reply

      All three current components in the Customizer UI Experiments should be ready for merge in 4.3; most notably, device preview toggles: https://wordpress.org/plugins/customizer-ui-experiments/.

      Let’s finish revamping the toolbar – #32678 / https://github.com/helenhousandi/wp-toolbar-experiments. We have a working patch that could use a refresh and a mostly functional version in plugin form, along with extensive discussion and iteration via design mockups.

      I’d love to get theme installation into the Customizer, but will have time. Might be able to do at least the development if @folletto and others work on refining our initial concept design.

      • Davide 'Folletto' Casali 5:17 pm on August 19, 2015 Permalink | Log in to Reply

        Sure thing. You’re thinking of the full screen sliding thing, or an initial “installation” step in the current iteration? :)

        • Nick Halsey 9:36 pm on August 19, 2015 Permalink | Log in to Reply

          Probably the full screen version. Maybe keep the existing UI and add add new buttons that open the full-screen browser, which would largely mimic the existing tabbed theme-install experience but with the addition of an installed tab. Theme installs/downloads would happen inline like shiny plugin updated do.

      • nikeo 7:02 am on August 21, 2015 Permalink | Log in to Reply

        Yep agree, +1 for theme install in the customizer.

    • Lara Littlefield 5:19 pm on August 19, 2015 Permalink | Log in to Reply

      REST API in core! 🎉

    • Tracy Levesque 5:19 pm on August 19, 2015 Permalink | Log in to Reply

    • joncampbell 5:28 pm on August 19, 2015 Permalink | Log in to Reply

      Lets implement this multipart mail fix: https://core.trac.wordpress.org/ticket/15448

    • Ricky Lee Whittemore 5:29 pm on August 19, 2015 Permalink | Log in to Reply

      REST API
      Term Meta
      Posts 2 Posts
      Shortcake
      CMB2-like Metabox Registration
      Radio Button Taxonomies – https://core.trac.wordpress.org/ticket/14877

    • Travis Smith 5:29 pm on August 19, 2015 Permalink | Log in to Reply

      I would like to see:

      • Term meta
      • Rest API
      • Post statuses
    • Roy Tanck 5:35 pm on August 19, 2015 Permalink | Log in to Reply

      I mostly work with multisite and corporate clients, and I’d love a “WP_Query_Network” class that mimics WP_Query, but queries the whole network’s content (by default, it’d obviously need “include_sites” en “exclude_sites” parameters). I realize this would be a very ambitious undertaking, and one which doesn’t suit a well-known multisite implementation, but this would really help multisite installs where blogs are used to separate departments or projects but content needs to be aggregated.

      • Jeremy Felt 5:46 pm on August 19, 2015 Permalink | Log in to Reply

        We can start with `WP_Network_Query` first. 😉 https://core.trac.wordpress.org/ticket/32504

        Querying an entire network’s content is definitely ambitious. I think it would be interesting to see some various approaches as featured plugins. Because of the varying sizes of networks, having a core solution would be tough. One preferred way now would be to mirror content in something like Elasticsearch that is better at handling these types of queries.

        • Roy Tanck 7:12 am on August 20, 2015 Permalink | Log in to Reply

          Yeah, we’d need some very clear naming ;). I remember reading that ticket and being disappointed that it didn’t do what I had in mind :).

          Ambitious, yes. But imho it’s _the_ feature still missing in multisite. Elastic (or GSA, etc) is fine for search, but I’d like to be able to display the ten most recent posts across a network using just core components.

          Feature plugin material for sure.

      • nicholas_io 5:50 pm on August 19, 2015 Permalink | Log in to Reply

        Take a look at this plugin that I wrote: https://wordpress.org/plugins/wp-central-posts-network/

        It`s not a WP_Query_Network but it alows you to select posts from any site within the network.

      • Piet Bos 6:49 am on August 22, 2015 Permalink | Log in to Reply

        +1 that would be super useful indeed!

    • francesdath 5:38 pm on August 19, 2015 Permalink | Log in to Reply

      Proper multilingual without a plugin. I’ve used/tried most of the plugins and at best all of the implementations feel (or are) somewhat sktetchy and non-WordPress
      Better HTTPS (@thomaswm)
      Improved media manager (sorting when uploading, etc @dpegasusm)
      Rest API
      Shortcake

    • Stagger Lee 5:40 pm on August 19, 2015 Permalink | Log in to Reply

      Would like to see improvements in these areas:

      • User profile screen.

      To be make as post edit screen. Means we could add custom metaboxes, collapse metaboxes, use featured image in profiles (avatar ?), rearange drag and drop sections (metaboxes) in profile screen. Anyway WordPress would benefit tremendously if profiles worked similar way as post/pages.

      • User/Role dependent TinyMce settings. (as Drupal has long time ago)
      • Visual Editor in comments, maybe optional as one checkbox in settings.
      • Post/Page/Settings/etc.. Save and Close button. Saving close edit screen and redirect to the list.
      • Easy to adapt Dashboard.
      • Random Math captcha in the core for registration, login, comments. Forms can follow and use core code.
      • Default featured image fallback.
      • Put basic robots.txt in root.
      • Put Interconnect script for converting URLs in core folder, or implemented in settings. Dont know how other people do but I am using it 100%, on all websites. If this doesnt qualify as candidat for core, I dont know what would.
      • Number of revisions and Autosave interval as settings in backend.
      • Backend left sidebar auto adapting to longer menu item names, adapting middle area too.
      • One or two metaboxes of beer and collapsible so kids cannot see them. :)
    • rahulnever2far 5:40 pm on August 19, 2015 Permalink | Log in to Reply

      • Shortcake
      • RICG Responsive Images Plugin
      • Fields API
      • Term meta

      :)

    • codeinwp 5:44 pm on August 19, 2015 Permalink | Log in to Reply

      I would love to see some love here : https://core.trac.wordpress.org/ticket/19627 :)

    • Abcmoteur 5:45 pm on August 19, 2015 Permalink | Log in to Reply

      A better modern comment system. Ajax and vote buttons. Thanks!

      Note : here we doesn’t have to reload page to see new comments. 😉

    • dziudek 5:49 pm on August 19, 2015 Permalink | Log in to Reply

      I think that better plugin security management is very important in a world where WordPress is engine for 1/4 of the Internet: https://core.trac.wordpress.org/ticket/33374

    • Dave Navarro, Jr. 5:51 pm on August 19, 2015 Permalink | Log in to Reply

      +1 Shortcake
      +9 REST API (appreciate all the hard work they are doing, but it’s been dragging on too long)
      +1 Nav Menu Admin update
      +1 Taxonomy for the Media Library

      I’d also love to see a hook fired when WP is about to to update so that existing backup plugins can automatically backup first. Also, WordPress should, at bare minimum, backup/export the DB before any update on its own if a backup plugin is not installed. I think it’s criminal that it doesn’t do this already. Optimally, WordPress should have an internal backup/roll-back functionality.

      Responsive design is nice, but many (if not most) sites need “mobile” support. I’d love to see better mobile detection built into core. I use a plugin called “mobble” to do that now.

      I would LOVE to see a standard UI toolkit (based on jQuery UI) in core for building metaboxes, option pages, widgets and more. A ton of bloat I see in themes and plugins are people using massive UI toolkits or rolling their own. A standard API for UI in core would increase performance and cut down on the bloat.

    • Jeremy Ward 6:13 pm on August 19, 2015 Permalink | Log in to Reply

      +1s for REST API and Fields API.

      Not necessarily user-facing, but I would love to see (and be involved with) some sort of internal code quality evaluation/updates (e.g., refactoring class files as described here: https://core.trac.wordpress.org/ticket/33413, but also ensuring core files follow, at a minimum, WordPress’s own coding standards, as there are certainly places in the codebase that can and should be simplified).

    • Brent Jett 6:22 pm on August 19, 2015 Permalink | Log in to Reply

      It’d also be great to see the awesome work done on Shortcake UI combined with the WP_Widget class into one structure so that WordPress has one interchangeable component format with a unified way to declare input fields.

    • Brian Krogsgard 6:32 pm on August 19, 2015 Permalink | Log in to Reply

      In terms of a user facing feature, I’d like to renew the 4.2 effort for new user onboarding, starting with the “Welcome to WordPress!” metabox. It got some traction with a “Flow” team, and those results are on Make Flow. But I’d love to see that get kickstarted again and offer a better onboarding experience in 4.4.

      • Hugh Lashbrooke 8:04 am on August 21, 2015 Permalink | Log in to Reply

        Definitely agree here. The onboarding copy could do with some improvements along with the whole NUX. Very excited about where the Flow team can take things in that regard.

    • Frank Bueltge 6:34 pm on August 19, 2015 Permalink | Log in to Reply

      My wishlist is short, but old.

      • relationship between posts, taxonomy,…
      • multisite topics, clean api like single install, as example the settings api
    • Brian Krogsgard 6:37 pm on August 19, 2015 Permalink | Log in to Reply

      At the risk of being an unpopular opinion, I would actually not say the REST API should go into version 4.4.

      I personally think that the REST API should be a two-step process. I think it’d be great for the Core team to give a stamp of approval in 4.4, and perhaps lay some groundwork if the team needs certain things in core for the API to achieve certain things. But most of all, it needs that final “yes, this will be in core” sooner than later. I’d like to see that this release cycle.

      Then, I’d actually propose that the merge itself is given a full additional release and see it go into WordPress 4.5. That gives this extremely important feature two releases to be worked on and ironed out and tested. The first release would also allow more developers to see that it is indeed meant for core and give them the encouragement needed to put it into production with confidence.

      • Dave Navarro, Jr. 7:01 pm on August 19, 2015 Permalink | Log in to Reply

        The problem I see with that is that it’s LONG OVERDUE and needed by so many. Sure, sure, we can install the beta plugin on any sites where we HAVE TO HAVE IT (like we are now), but it “scares” people who don’t understand what’s going on.

        NOTHING is perfect and stuff gets already into core that doesn’t work out the gate, so lets get it in core already.

      • Josh Pollock 7:15 pm on August 19, 2015 Permalink | Log in to Reply

        What part of the API do you think shouldn’t be in core right away? Are you suggesting infrastructure, but not default routes go in? Seems like that would guarantee low adoption.

      • NateWr 9:18 pm on August 19, 2015 Permalink | Log in to Reply

        If such an approach were taken (and I would rather it just go in now), it would be great to at least have the API in core but off by default. Then plugins and other products that wished to make use of it could do so. Until it’s in core, the “confidence” and “real-world use” everyone keeps clamouring on about will not materialize.

    • dshanske 6:45 pm on August 19, 2015 Permalink | Log in to Reply

      #32653 Linkbacks are being defaultly disabled because of misuse and that the benefits do not outweigh the downsides. By improving the presentation, we can make it worth turning on.

    • dshanske 6:54 pm on August 19, 2015 Permalink | Log in to Reply

      I’d also like to see about #30783.

    • Josh Pollock 7:20 pm on August 19, 2015 Permalink | Log in to Reply

      Obviously REST API in core.

      Also, would love to see cancel_comment_reply_link() work when used in an AJAX call (IE when $_SERVER[‘REQUEST_URI’] is not appropriate to use for the base of the link.) This is very similar to the fix in #31333. Tickets for this are #32299 and #28314

    • Aaron Jorbin 7:37 pm on August 19, 2015 Permalink | Log in to Reply

      I would like to see a new default theme.

    • thomask 8:11 pm on August 19, 2015 Permalink | Log in to Reply

      As a developer who uses WP from version 1.2 and who has made about 500 websites on it, i miss only one thing – BUILT-IN MULTILINGUAL SUPPORT. Most of the Automatic programmers are Americans and you do not simply care about other languages, but WP is now used mostly in other languages and believe me, that this thing is really pain in the ass with wordpress. Yes, there are some plugins, that creates tons of new db tables and none of them works perfectly, they are slow, sometimes they do some mishmash after upgrades and so on. And the most functional ones are not for free.
      I have experience with other CMS, that got the main team in Europe, where every country has its own language, sometimes even two or three, and in all such systems, multilanguage support is piece of cake, just click in the admin, what languages you want, and if it would be on separate domain, subdomain or with someting after .TLD/. They do not add any extra tables or complexity, simple every translaable item in DB (posts, taxonomies, fields), got language column.
      Loooong after this i would like build in custom fields setup, but this has very nice and easy programers way, how to do it (except some easy way how to setup the field input type, its saving to db and retrieving, what is too complex), and it has two or three very good plugins, that do not add extra complexity and which use default wp tables without any hacks.
      So please – MULTILANGUAGE! Do not listen to WP discussions where there are 99 % of americans or people, who do not need more then one language – people who need more than one language are very often simple not use WP, because of this lack of languages support.

    • b-rad 8:13 pm on August 19, 2015 Permalink | Log in to Reply

      If WordPress is going to be a serious CMS then it needs to have a way to manage groups of users. Content shouldn’t be limited to being owned by one person. I should be able to change the owner of a page or post to a group, and anyone with the sufficient permissions should be able to then edit that content. Blows my mind that this doesn’t exist yet.

      And a better media manager.

      And a way to disable that new 4.3 option of formatting shortcuts.

      • Jeremy Ward 9:26 pm on August 19, 2015 Permalink | Log in to Reply

        This is a great suggestion.

      • trailness 9:52 pm on August 19, 2015 Permalink | Log in to Reply

        +1 role management
        +1 media manager

        I am tired of using klunky plugins for both tasks.

      • Justin Tadlock 10:50 pm on August 19, 2015 Permalink | Log in to Reply

        Group management of posts? That sounds pretty cool. I might sit down at the drawing board and see how that would work as a plugin. I’d love to hear more about how you think this should work.

        • ckluis 12:03 am on August 20, 2015 Permalink | Log in to Reply

          I like the way some crms/project management solutions work with this where you can click on individuals or groups to assign them to a task/page/item.

          Also being able to assign notifications on updates seems like a win in those larger installs.

      • Stefano Aglietti 9:46 am on August 20, 2015 Permalink | Log in to Reply

        +1 on groups

      • Ipstenu (Mika Epstein) 2:49 pm on August 20, 2015 Permalink | Log in to Reply

        User Management also needs granular control over roles.

        Right now all plugins that do this have to edit directly in your database, which means when (and yes, when) things get messed up, you have to reset by finding a copy of the original settings and pasting them into the DB. I do this regularly for customers. There needs to be a better way.

        In addition, we need a BLOCKED user role. For people who were members and are now blocked for being idiots. There’s no real way to do that.

        • Doug Smith 3:26 pm on August 21, 2015 Permalink | Log in to Reply

          I’d also love to see the multiple roles per user that is already under the hood brought out to the UI.

        • Justin Tadlock 10:01 pm on August 22, 2015 Permalink | Log in to Reply

          I’d love to hear more about what type of trouble you’re seeing when things get messed up. I can count the number of times on one hand when a user of my role plugin has had to do a complete reset in the past 6 years (one of those people was me during testing when I accidentally locked myself out of my own site).

          • Ipstenu (Mika Epstein) 3:05 am on August 23, 2015 Permalink | Log in to Reply

            Never once have I seen it with your plugin, Justin. Other plugins let you edit the admin role, however, and users often have no idea what on earth it means to edit that role :/ In combination with other management plugins, where they try to make multiple roles for people, like store owners and management and members, it’s easy to get it all messed up very fast.

            The normal error they make is editing the default roles instead of making their own.

            The average roles people are missing and complain about:

            • Sidekick Admin – Someone who has access to all blogs on a multisite, but not to install plugins/themes
            • Moderator – Someone who can approve or spam or pend comments and nothing more
            • Moderated – Someone who always has to have all things (comments) approved.
            • Blocked – An account that has no access, no comments or anything (for people who were trolls/broke rules)
            • Stagger Lee 4:40 pm on August 24, 2015 Permalink

              @Mika, “BLOCKED” is the same as deleted account, unless it is time based.
              Or at least same as one simple list with blocked email adresses, principle is the same as “blocked” role.

              Blocked by 24 hours, by 1 day, by 1 week, by 1 month, etc…is needed together with “blocked” role in some manageable way.
              This is specially needed for bbPress forum too.

            • Stagger Lee 4:41 pm on August 24, 2015 Permalink

              Sorry for lapsus, 12 hours, one day.

            • Ipstenu (Mika Epstein) 5:18 pm on August 24, 2015 Permalink

              @stagger-lee – No Blocked is not equivalent to deleted, though I understand why people think it is.

              Deleted means the email can be used to make a new account. Blocked means that user gets told “You have no rights to this site.”

              Time based for blocking a user would be a nice thing to add on, and a filter could help if we had a role that was ‘disabled’ or blocked or whatever.

            • Justin Tadlock 1:22 am on August 29, 2015 Permalink

              Thanks for getting back to me. It’s always helpful to read about these sorts of things.

              FWIW, I always set up a “blocked” role on my sites. And, I set up a “spam” role to make a distinction between spammers and bozos. To really make this useful though in my own plugin, I need to create a UI for explicitly denying (not just removing) caps from those roles. It’s on the roadmap.

    • Mike Schroder 8:29 pm on August 19, 2015 Permalink | Log in to Reply

      I’d love to help out/guide RICG’s review and potential merge as needed, as part of that, tackle #15311, with an added queue for background image generation.

    • Adam Silverstein 8:33 pm on August 19, 2015 Permalink | Log in to Reply

      I’m going to continue plugging away at the revisions component and my effort to get revisioning of post meta into core.

    • scalopus 8:36 pm on August 19, 2015 Permalink | Log in to Reply

      == For Plugin Developer ==

      • composer

      This is pain situation, currently composer are use widely now, but I think if the plugin gonna use it, it will become dependency hell. we have to make better approach for plugin to work with composer and dependency package.

      == For User ==

      It is painful to know which plugin still active / no longer active, it should have status of plugin in the installed plugin page, or at least suggest similar plugin if the plugin no longer active.

    • davemacd 8:52 pm on August 19, 2015 Permalink | Log in to Reply

      Meta fields for custom taxonomy terms. That’s it for me.

    • Dave Navarro, Jr. 9:02 pm on August 19, 2015 Permalink | Log in to Reply

      AJAX support for post editing. It’s just about everywhere else and it’s a PITA to wait each time you hit submit on a post or page.

      • daronspence 11:23 pm on August 19, 2015 Permalink | Log in to Reply

        You would still have to wait even if they implemented an AJAX save as they wouldn’t want to allow anything to be edited while the save is unconfirmed. Also, this would probably create a big headache for plugins that add metaboxes based on the values of what’s on the edit screen.

    • TomHarrigan 9:08 pm on August 19, 2015 Permalink | Log in to Reply

      Fields API

      Post Formats 2.0

    • Ahmad Awais 9:08 pm on August 19, 2015 Permalink | Log in to Reply

      Congrats Scott!

      About the Wish List, here you go

      — UI enhancements in Dashboard (More of a CSS refresh, more modern and subtle)
      — WP REST API
      — Fields API – It can help developers get rid of a lot of bloated frameworks, which can bring a much bigger change than expected

      That’s all for now.

    • Julio Potier 9:11 pm on August 19, 2015 Permalink | Log in to Reply

      Hey congratz!

      In 4.4 why not theming the admistration side 😀

      • J.D. Grimes 9:22 pm on August 19, 2015 Permalink | Log in to Reply

        The REST API would go beyond that and allow for the site to be administered from any custom back-end. But theming the admin could be useful too, for smaller changes.

      • Ahmad Awais 9:25 pm on August 19, 2015 Permalink | Log in to Reply

        REST API will solve that problem in pretty innovative way.

    • Dave Navarro, Jr. 9:12 pm on August 19, 2015 Permalink | Log in to Reply

      I currently use Theme My Login to keep users out of the back end of the web site, but most of that functionality should be in WordPress itself. The ability to separate Admin from Front end for most users is critical as more and more plugins don’t allow defining roles for their actions.

    • Michael Beil 9:26 pm on August 19, 2015 Permalink | Log in to Reply

      • REST API
      • RICG
      • Shortcake
    • CotswoldPhoto 9:27 pm on August 19, 2015 Permalink | Log in to Reply

      Maybe enqueue for fonts. And enqueue the assets for the login screens (the admin assets).

    • Marko Heijnen 9:28 pm on August 19, 2015 Permalink | Log in to Reply

      I would like to see this release for WordPress to stop focussing on adding new features and work on looking at fixing bugs that got added in the previous releases. Currently we are at 3910 open tickets and we need to make a plan to reduce that.

      One thing that comes to mind is fixing broken/imperfect code like the changes made in 4,3 to the Site Icon feature. Also added .ico support would be a nice feature which could have been added in 4.3.

      I know we don’t refactor code just because we can but if we would have looked more at the customizer code then the Site Icon feature would be easier to add and we wouldn’t needed to add questionable code in 4.3

    • itonstandby 9:54 pm on August 19, 2015 Permalink | Log in to Reply

      WordPress additions for 4.4 I’d like to see implemented:

      • A way to roll back major actions such as WordPress, theme, and plugin updates. Hooks that would allow custom roll backs would be a plus for developers too. At the very minimum, allow a WordPress version rollback right after an update or upgrade. Restoring a site from backup is beyond most site owners and they end up crowdsourcing or hiring the work done when a core update or upgrade breaks their site. A core rollback would be much more sensible and would further the credibility of the WordPress platform.
      • An editor for the maintenance mode display the public sees. Having to use a coming soon plugin just to display a nice looking page while the site is in development or in maintenance mode is really absurd at this point for such a robust product as WordPress
      • The ability to use one WordPress dashboard to manage multiple WordPress sites. If I own one or two WordPress sites, no big deal to login to each one to do maintenance. But if I own five, it gets laborious and confusing. Just to be clear, I’m aware of multi-site WordPress. That’s not what I’m referring to here. Standalone sites should be able to be managed by the site owner from a central location without having to use buggy plugins or high priced services – some of which are not usable on all hosts such as managed WordPress environments.
      • More security. At a minimum allow the site owner to change the login URL to something unique. This is in most security plugins and is a huge boost toward securing a site. Take a look at the popular security plugins and you’ll notice they all have a firewall. How about adding a basic firewall to WordPress core? Then if more functionality is needed let the security plugin makers add it. But a basic firewall and security footprint is essential to keeping sites from becoming so easily hacked.
      • STOP – I repeat – STOP supporting old browsers. Make it optional by the site owner, of course, but I really don’t want Firefox v4 hitting my site. Nor do I want Windows XP users using IE6. Let’s stop them at the gate and redirect to a gracefully worded “your browser is too far out of date for this site” page.
      • chriscct7 4:31 pm on August 20, 2015 Permalink | Log in to Reply

        When a core update causes a fatal error, WordPress already automatically rolls back. Plugins and themes that cause a detectable PHP fatal error are blocked from actually being committed to WordPress.org as it is.

        WordPress core doesn’t support old browsers already, and in fact if you have an old browser and login to a WordPress install, you’ll see a browse happy notice, since WordPress 3.2

        The rest of these other suggestions fall well below the “design for the majority” standard it seems

        • Ipstenu (Mika Epstein) 7:58 pm on August 20, 2015 Permalink | Log in to Reply

          To tack on here, it’s incredibly hard to detect if a plugin is ‘going to’ break your site. 35k plugins. You can try and math out the possible combinations of using them on someone’s site, but the number is (to quote a mathematician) “Very large, buy me a beer.”

          Also the real issue with broken plugins is they generally require manual effort to roll back so automating is hard.

    • Arnan de Gans 10:04 pm on August 19, 2015 Permalink | Log in to Reply

      No new features (or nothing major) but just optimisations, speed increases, efficiency things.
      This can include dashboard improvements or better widget UI. But a bunch of under-the-hood improvements to make things faster and more lightweight on for example MySQL would be fun/useful.

      Some things I’d like to see;

      • Move transients out of wp_options into their own table.
      • A more intuitive UI for widgets.
      • Faster update checking where possible (not a WP problem per-se).
      • General speed increases for the dashboard (especially on larger sites).
    • Brian Bourn 10:06 pm on August 19, 2015 Permalink | Log in to Reply

      I’m not sure if a ticket for this exists or not, but I’d like to suggest a small UX improvement to the taxonomy term edit screen. Currently when a taxonomy term is edited then saved, the user is redirected back to the main taxonomy screen with the message: “Category updated.” (or other tax name).

      This can be confusing to navigate when there are hundreds of terms and someone wants to check the changes of the recently updated term.

      I believe it would be better for most users that upon save of the taxonomy term, they stay on the same screen and the same success message “Category updated.” is shown along with a link “View category” (or other tax name) similar to when posts or pages are updated.

    • Patrick Hesselberg 10:16 pm on August 19, 2015 Permalink | Log in to Reply

    • wido 10:40 pm on August 19, 2015 Permalink | Log in to Reply

      The Shortcakes, Fields Api and Rest Api would be great.

    • Peter Wilson 10:45 pm on August 19, 2015 Permalink | Log in to Reply

      Here’s a big long list. The comments stuff is most important, the rest are nice to haves.

      COMMENTS

      • Front end comments-reply.js is obtrusive and can throw errors on slow loads/large pages.Let’s make it unobtrusive #31590 (ego ticket)
      • This would be a good first step for ajaxafying them down the trac – probably after the Rest API goes in

      JQUERY & BUILD TOOLS

      • Dev version of jQuery included for SCRIPT_DEBUG – #32358
      • Merge jQuery & jQuery migrate into one file for performance – #32793
      • Add noConflict to jQuery as part of the build process – #32831

      PERFORMANCE

      • Preconnect headers for emoji – #33210 (worth adding for google fonts if used)
      • Single CDN for all/as many as possible externally hosted assets – #31801
    • MRWweb 11:03 pm on August 19, 2015 Permalink | Log in to Reply

      Separate capabilities for manage_widgets and manage_nav_menus!

      +1 for Post Formats 2.0, grandchild themes, and Media tags

    • Felix Arntz 11:07 pm on August 19, 2015 Permalink | Log in to Reply

      Beside the REST API of course and the Fields API, I would love to see:

      Use-case for my second point: for example, if you switched your site’s domain name, all image URLs and internal links would still work without running additional search/replace scripts for the database which is probably too complicated for the average user. The required behavior could be achieved by using some kind of shortcodes instead of the full URLs in the content.

    • aidanlane 11:31 pm on August 19, 2015 Permalink | Log in to Reply

      REST API and Shortcake please.
      Then step back and watch theme and plugin developers get creative, it’s going to be amazing!

    • lpghatguy 11:31 pm on August 19, 2015 Permalink | Log in to Reply

      I’d like to see ARIA roles on things like navigation menus — it was proposed before using the wrong ARIA role (menu/menuitem) and was immediately marked invalid. It’d be nice to have role=”navigation” and role=”navitem” on items out-of-the-box.

    • menkom 11:40 pm on August 19, 2015 Permalink | Log in to Reply

      I would personally like to see greater control over permissions and custom roles, dont see how a plugin is needed for this when Drupal has this as part of core and is one of its major strengths.

    • Luis Rodrigues 11:53 pm on August 19, 2015 Permalink | Log in to Reply

      Now that the term_id vs term_taxonomy_id mess is (one hopes) about to be sorted, I think it’s high time to get term meta moving.

      Support for screens of multiple sizes and pixel densities is a pressing issue, so giving the RICG plugin a boost would great.

      There are a few rather severe performance issues in multilingual installs that could be resolved by caching MO files (there is a plugin, but the optimization really belongs in core) and using PHP’s native gettext extension (#17268).

      Finally, having the WP REST API in core would be nice, but it’s not like the plugin is going anywhere. I’m awfully excited about it, but public APIs are a serious long-term commitment, so I’d try to learn as much as possible from early adopter use in the coming months before rushing it into the core.

    • fsylum 12:47 am on August 20, 2015 Permalink | Log in to Reply

      I would love to have the post status API been properly implemented (all the quirks surround the register_post_status).

      Another vote for REST API

    • seanbennick 1:37 am on August 20, 2015 Permalink | Log in to Reply

      May be a bit ambitious, but I would love to see child theme creation with a click.

    • dmccan 1:46 am on August 20, 2015 Permalink | Log in to Reply

      A voice in the wilderness … :)

      • Some type of comment love. There is a lot of dissatisfaction and many improved ways for handling them floating around. If we focus in core on things that 95% of people use, well, this is one of those areas. Even if it is just incremental improvements.
      • Easier migration from dev to production. We tell people to develop locally but it is a pain to move a site from dev to production. This is a frequently asked question (how to) in WordPress forums on Reddit and LinkedIn. Perhaps a setting that will switch from absolute to relative URLs and then when set off will pick up the new domain name and switch back? Or, will auto-magically run the script that changes the database serialized URLs?
      • Front end editing. Let’s not wait for 1000 different premium implementations. The features plugin stalled and it would be great if it was resurrected. This is a feature that would help WordPress maintain its leadership position.
      • Personal peeve: Custom post type editor in core. Understanding how WordPress handles CPTs was the biggest WTF disconnect for me when moving from Drupal to WordPress. In Drupal there is an editor to create them and specify the fields that get output when the page is viewed.

      Thanks for asking!

    • Scott Grant 1:47 am on August 20, 2015 Permalink | Log in to Reply

      Would love to see #16979 and WP_Comment get some ❤️️. Excited for 4.4! :)

    • Nilambar Sharma 3:45 am on August 20, 2015 Permalink | Log in to Reply

      My wishlist:

      • REST API
      • Term Meta
      • Improved Customizer Performance
      • Fields API
      • Built-in Multilingual feature
      • Image (or Media) Widget
      • Template tag for breadcrumb

      Also can we please look at these tickets?
      https://core.trac.wordpress.org/ticket/32972
      https://core.trac.wordpress.org/ticket/32668

    • Junrill Galvez 4:04 am on August 20, 2015 Permalink | Log in to Reply

      Would like to see REST API integrated and is there a chance of moving wordpress to a MVC Structure?

    • szaqal21 5:11 am on August 20, 2015 Permalink | Log in to Reply

      Add hook to print extra buttons (similar to Add new) in H1 tag for post.php and post-new.php screens, now it has to be done by JS.

    • Archie22is 5:40 am on August 20, 2015 Permalink | Log in to Reply

      Hey guys,

      I think the ability to be able to hide basic Php errors would be nice. I know it’s not ideal but I think it might come in handy for a couple of users and developers out there.

      At the moment I use a plugin called: https://wordpress.org/plugins/0-errors/ – mostly for small to mid-sized projects that do not have staging environments.

    • Pascal Birchler 7:03 am on August 20, 2015 Permalink | Log in to Reply

      I’ve been working on the oEmbed feature-as-a-plugin for quite some time now and it’s working very well so far — with and without the REST API. It only needs more users (perhaps on dotcom at some point) and some bug fixes.

      So what does it do exactly? Well, it makes WordPress an oEmbed provider. If you have that plugin active, people can embed any blog post from you on their site. Just like tweets or YouTube videos.

      Of course implementation is very strict because of security. Only sandboxed iframes are allowed etc.

      I’m pretty sure this can make it into WordPress 4.4 and I’ll work hard to get things done for the merge window.

    • Florian Girardey 7:06 am on August 20, 2015 Permalink | Log in to Reply

      Hi,

      First of all, thank you for asking us :)

      • A thing that seems to me very important is to make WordPress easier to use as an independent package, giving WordPress its own directory. I heard that using Composer is impossible because of the WordPress PHP version support, okay, but maybe there is something to do at least for the WordPress directory.
      • PHP version update… I know it’s a no but seriously everyone is asking for…
      • A native way to handle environments (staging/production) ?
      • Fields API
    • Ross Wintle 9:15 am on August 20, 2015 Permalink | Log in to Reply

      As a developer I support the following (bizarrely most of what Florian said directly above):

      • PHP version update – let’s move on please!
      • Environments – I guess this is achievable using wp-config, or actual server environment variables, but how about environment-specific options? So I can have a Google Analytics ID in my live environment only?
      • Fields API

      PLUS

      • Post relationships !!! Some API for defining relationships between post types and then querying based on that. I’d love to see:

      register_post_relationship([
      ‘from’ => ‘post’,
      ‘to’ => ‘country’,
      ‘type’ => ‘many-to-one’
      ]);

      and then

      $query = new WP_Query(
      [
      ‘post_type’ => ‘posts’,
      ‘posts_per_page’ => 10,
      ‘related_to’ => [
      ‘post_type’ => ‘country’,
      ‘post_id’ => get_the_ID(),
      ]
      ]
      );

      This, for me, is the key limitation of WordPress’s data model and there isn’t really any point in having a REST API until this kind of thing exists.

      On the REST API, I don’t think it’s a good idea to have it in core at present. WordPress isn’t an application framework, and I think having REST API in core means that you will see UI fragmentation which would lead to confusion for users. Plus, at the same time as we’re considering this, the BackPress revival is thinking about splitting up WordPress into constituent parts. We need to make a call: are we de-coupling all the things? Or are we implementing as much as possible in core?

      As a user and someone who recommends WordPress to other users I’d love to see:

      • Theme and Plugins editors disabled by default
      • Built-in brute-force security (could brute-protect be in core?)
      • I love the suggestions above of a roll-back ability for updates
      • Screen-width option in the customiser, so I can view my customisations in a width of my choosing (currently, on my laptop, when the customizer is visible, most sites drop into a tablet-view)

      Err…I think that’s all. Hopefully some useful ideas there.

    • atomicjack 9:25 am on August 20, 2015 Permalink | Log in to Reply

      Here’s mine… based solely on ideas suggested by the community:

      Clean up deprecations: https://wordpress.org/ideas/topic/time-to-remove-legacy-code-to-speed-up-wordpress

      Add Cookie Notice (this is law in the EU and should be easy for new blog owners to add the notice): https://wordpress.org/ideas/topic/add-core-functions-to-comply-with-eu-cookie-law

      Make email templates themeable: https://wordpress.org/ideas/topic/implement-all-system-emails-in-html-improve-look-and-feel

      • dshanske 5:20 pm on August 20, 2015 Permalink | Log in to Reply

        Re the templates…I think the current automated emails could be better broken up into pieces to make this work better. The plugins should handle the customization, but I think core could assist with it

      • colomet 9:13 pm on August 20, 2015 Permalink | Log in to Reply

        ++++ COOKIE IS NECESARY

    • Stefano Aglietti 9:44 am on August 20, 2015 Permalink | Log in to Reply

      • Rest API
      • Starting relationship between elements (post to post etc) relationships between termes I suppose need the revision of terms table completed
      • A method to purge and generate on the fly new image size, would be nice to have a choise to generate or not all registered dimension on upload if not when we request a dimension this is generated on the fly (like using photon but locally
    • Manny Fleurmond 12:10 pm on August 20, 2015 Permalink | Log in to Reply

      REST API and by extension standardized Backbone models and collections for posts and terms. This was already done for attachments when the media modals were created but it would really be nice to have once the REST API comes into core.

    • matthewgfc 1:04 pm on August 20, 2015 Permalink | Log in to Reply

      I would certainly appreciate a purge all comments button. I can’t tell how many times clients have abandoned management of their site and I find 5,000+ comments polluting the database.

    • stickypod 1:08 pm on August 20, 2015 Permalink | Log in to Reply

      Distinct Multisite WordPress Core

      1. Allow multiple websites with unique databases
      2. Build out the stylesheets, javascripts and possibly core to be served from a central location (CDN)
      3) Design propagation updates
      4) Build central social network platform distribution (RSS)

      My proposal is different from the current multisite because it requires each site to have it’s own unique database. Why? Because each site, though under the umbrella of one company, has it’s own unique data sets.

      For example, a car dealership can have one owner, but 7 different brands. While the dealership requires the same look across all it’s websites, the work involved to build and maintain 7 different sites is overwhelming.

      If the stylesheets, javascripts and possibly the core were served from one central location (CDN) the overall look can be updated from one central admin.

      When updates are required, the updates would occur centrally, and propagate through to the multiple sites.

      Social networks would need a central admin for distribution. For example, writing articles for one car brand will not work for another, but the ability to push the articles from a central location would be vital for workflow.

    • docflo 1:18 pm on August 20, 2015 Permalink | Log in to Reply

      I’d really like to see editable archive pages for custom post types, like “Posts Page” for posts. To be set in Settings > Reading Settings.

    • Andre 1:25 pm on August 20, 2015 Permalink | Log in to Reply

      For multi-network installations I’d love to see a Network Admin role added between Super and Site admin roles.

      I’d also love to see a cleanup feature that is multi-site and multi-network aware that can cleanup leftover database entries and files from deleted plugins, sites, and networks.

    • Torsten Landsiedel 1:54 pm on August 20, 2015 Permalink | Log in to Reply

      It’s a very small thing: extending blockquote with cite tag in TinyMCE @azaozz

    • Greg Ross 2:11 pm on August 20, 2015 Permalink | Log in to Reply

      How about removing JetPack and Hello Dolly from the distro, or at least not REINSTALL them after every upgrade!

    • Jacob N. Breetvelt 2:16 pm on August 20, 2015 Permalink | Log in to Reply

      I would like to have a re-install link for plugins, like you can re-install wp.
      I do not care if the de-activation and / or activation hooks are triggered, as long as it does what it says.
      If it says ‘plugin successfully re-activated’ it should use the activation hook etc.

      If such a link exists, it would greatly simplify support on plugins.

      • Michael Beckwith 11:17 pm on August 20, 2015 Permalink | Log in to Reply

        I agree with reinstall, but I already had a ticket shot down because you can just delete and re-install that way. Sadly I don’t think that one will fly.

    • seanbennick 2:16 pm on August 20, 2015 Permalink | Log in to Reply

      1) Better handling of the Media Library
      2) An auto pagination system of some sort that allows articles to be split into multiple pages based on:

      • # of words
      • # of paragraphs
      • Percentage of article (auto breaks into X pages of fairly equal length)
    • KARTHOST 4:33 pm on August 20, 2015 Permalink | Log in to Reply

      Here are my lists:
      1) REST API (like yesterday)
      2) Switch from Full http:// to https:// in Settings and make all needed changes site wide if site is already active (note: if some one needs partial https the various plugins can handle that easily enough)
      3) Permissions of Users (Admin and Editors) to allow access to only certain Pages and Posts/Categories and custom posts.

    • Ryan Boren 4:49 pm on August 20, 2015 Permalink | Log in to Reply

      • David Lingren 7:45 pm on August 20, 2015 Permalink | Log in to Reply

        I’d like to comment on your “Retiring media-new.php” proposal.

        In addition to the browser uploader, media-new.php offers a number of hooks that allow plugin developers a way to extend its functions.

        My plugin, Media Library Assistant (https://wordpress.org/plugins/media-library-assistant/), adds a form below the drag-and-drop area on the Media/Upload New Media screen. The form allows users to set defaults for standard fields, taxonomy terms and custom fields that are applied to items as they are uploaded. It uses the ‘upload_post_params’ and ‘post-upload-ui’ hooks provided in media-new.php.

        I have not developed an alternative approach to this feature that works in the grid view or Media Manager Modal Window (MMMW). I have found it very difficult to extend grid view and MMMW, and I am concerned that a media-new.php replacement will have similar issues.

        I hope you will think through and meet the needs of plugin and theme developers in any media-new.php replacement effort. Thank you for your consideration.

      • nikeo 7:06 am on August 21, 2015 Permalink | Log in to Reply

        +1 for Support opening images in a modal

      • Paal Joachim Romdahl 8:59 pm on August 22, 2015 Permalink | Log in to Reply

        +1 on opening images in modal.
        + 1 Toolbar revamp.

    • enshrined 4:49 pm on August 20, 2015 Permalink | Log in to Reply

      I’d love to see some movement on getting SVG uploads integrated at some point.

      https://core.trac.wordpress.org/ticket/24251

    • Fabrizio Azzali 5:55 pm on August 20, 2015 Permalink | Log in to Reply

      My Wisher in order

      • Multilingual
      • Cache built in
      • Meta SEO
      • Child Theme
      • Captcha on comment
      • Gallery as a stand alone item
      • Multiple sidebar
      • SVG upload
    • schlimpf 7:11 pm on August 20, 2015 Permalink | Log in to Reply

      Regarding the Media Library:
      What I am really missing is the possibility to structure the files uploaded. It can get really messy when having many uploads. Adding folders would really help….

    • David Anderson 7:26 pm on August 20, 2015 Permalink | Log in to Reply

      Make plugin and theme uploads able to upload in chunks, so that they’re not subject to PHP’s maximum upload limit. Nobody likes to upload a plugin to find it’s “too big”, and this is the sort of “just make it work” change that belongs in core. WP’s media library already supports chunked uploading. Here’s a plugin that does this for plugins: https://wordpress.org/plugins/upload-larger-plugins/

    • _ck_ 8:01 pm on August 20, 2015 Permalink | Log in to Reply

      Please read my proposal for 4.4 as a developer:

      https://ckon.wordpress.com/save-wordpress-future/

      It could really make a huge difference for WordPress performance.

    • Stanko Metodiev 8:10 pm on August 20, 2015 Permalink | Log in to Reply

    • closemarketing 8:56 pm on August 20, 2015 Permalink | Log in to Reply

      Edit Taxonomy and Categories admin pages with the full editor, and options.

    • Maciej Krawczyk 9:01 pm on August 20, 2015 Permalink | Log in to Reply

      Prevent bricking website during upgrade when browser tab is accidentally closed.
      https://core.trac.wordpress.org/ticket/33287

    • colomet 9:05 pm on August 20, 2015 Permalink | Log in to Reply

      prevent the upgrade of plugins

    • colomet 9:09 pm on August 20, 2015 Permalink | Log in to Reply

      export categories and tags

    • colomet 9:10 pm on August 20, 2015 Permalink | Log in to Reply

      Posibility of multilingual

    • colomet 9:18 pm on August 20, 2015 Permalink | Log in to Reply

      Maybe we do not need more features, just increase the general cuality of the site (speed and bugs and scalability)

    • Ben Hansen (ubernaut) 10:46 pm on August 20, 2015 Permalink | Log in to Reply

      probably a good idea to think about sunsetting support for blip oembeds since they are shutting down today.

    • Greg Raven 11:32 pm on August 20, 2015 Permalink | Log in to Reply

      Short of hosting with WP Engine or one of the hosts at that level, optimizing WordPress for speed continues to present a lot of challenges. I would love it if there were built-in speed optimization tools that actually worked on … say … Bluehost reseller accounts, and other “generic” hosting packages. Setting up W3 Total Cache and other similar plug-ins is about as fun as being turned inside-out very slowly.

    • Hussam Al-Tayeb 11:47 pm on August 20, 2015 Permalink | Log in to Reply

      Lower memory usage when displaying posts and pages especially 404 page not found requests. WordPress is getting hungry on memory even with just akismet as enabled plugin.

    • Michael Beckwith 12:12 am on August 21, 2015 Permalink | Log in to Reply

      @ error control operator hides fatal error on mysql_fetch_object – https://core.trac.wordpress.org/ticket/21870
      Performance Increase in apply_filter() (~11%) – https://core.trac.wordpress.org/ticket/26640
      We need a way to programmatically tell if we are in a sidebar – https://core.trac.wordpress.org/ticket/16443
      do_action/apply_filters/etc. recursion on same filter kills underlying call – https://core.trac.wordpress.org/ticket/17817
      deprecate category_description() in favor of get_category_description() – https://core.trac.wordpress.org/ticket/9927
      Parse shortcodes in text widgets by default – https://core.trac.wordpress.org/ticket/10457
      Performance enhancements for esc_url() – https://core.trac.wordpress.org/ticket/22951
      Encourage people to change default tagline – https://core.trac.wordpress.org/ticket/6479
      When deleting users without any links/posts, don’t ask to whom they should be reattributed – https://core.trac.wordpress.org/ticket/6405
      Allow Plugin/Theme updates from a uploaded .zip file. – https://core.trac.wordpress.org/ticket/9757
      Implementation of %my_taxonomy% in permastructs is incomplete – https://core.trac.wordpress.org/ticket/10786
      Pages whose ancestors are not all “published” cannot be used as parents for other pages. – https://core.trac.wordpress.org/ticket/11235
      Provide easy way to return url of thumbnail image – https://core.trac.wordpress.org/ticket/11571
      Trashed items interfere with page/post slug generation – https://core.trac.wordpress.org/ticket/11863
      Make the post thumbnail size filterable for the Featured Image meta box – https://core.trac.wordpress.org/ticket/28512

    • galbaras 12:26 am on August 21, 2015 Permalink | Log in to Reply

      Hi Scott,

      Congratulations and best of luck. You’re one important man now, along with quite a bit of pressure.

      To me, the current admin bar is more of a designer bar, because it focuses on activities related to building and styling the site, but not to administering it on an ongoing basis.

      For example, the admin bar contains a link to themes, but not to plugins. On average, WordPress sites probably have 25 plugins and only 1 theme, and plugins are updated far more frequently than themes are.

      Similarly, there are links to various ways of customizing the theme (menus, background, etc), but not to users or comments.

      A radical idea would be to replicate the admin menu used “inside” WordPress to make everything accessible from the front end via the admin bar. This way, each site’s unique combination of tasks and each user’s unique role will determine what is available.

      This approach has the advantage of making plugin-specific items available without any special code in the plugins.

      Alternatively, the admin bar should be redone based on the most common administrative tasks performed across WordPress installations. I’m sure wordpress.com can provide those stats.

      Happy to discuss via https://wordpress.org/support/topic/make-admin-bar-more-useful

      Best regards,
      Gal

    • Knut Sparhell 12:32 am on August 21, 2015 Permalink | Log in to Reply

      • Add Media (image) widget
      • Dependency management for plugins and themes
      • Private/non-upgradeable plugins (not allowed on the repo)
      • Term meta, table and API
      • Multilingual minimal support for posts
      • More flexible image sizes, multi sized
      • Fields API
      • Shortcake
      • Authors allowed to edit and publish own pages, like for posts
      • Install multiple plugins in one go
      • Remove Links Manager and add the code to the plugin
      • Settings reduction
      • Default featured image, as either first embedded or picked from media library
      • Better handling of posts statuses
      • Custom comment types
      • Widgets in posts table by default, as first class content
      • Multisite: Allow site admins to add users to site
      • Multisite domain mapping
      • Plan and time set for minimal PHP bump
      • J.D. Grimes 1:14 pm on August 21, 2015 Permalink | Log in to Reply

        +1 for dependency management. It really needs several releases worth of planning and discussion though. And I think that before we can think seriously about it we need to fix a lot of other things surrounding plugins and themes. There really needs to be a plugins working group, no?

      • Brent Jett 2:12 pm on August 21, 2015 Permalink | Log in to Reply

        +1 For Batch Install Plugins, particularly from the “Favorites” tab.

      • Naser Mirzaei 7:33 am on August 23, 2015 Permalink | Log in to Reply

        +1 Custom comment types
        it seems good to add comment_type field like post_type to implement something like ratings or reviews on comments

    • swalkinshaw 2:18 am on August 21, 2015 Permalink | Log in to Reply

      My only wish is that https://core.trac.wordpress.org/ticket/24152 gets reviewed since it’s been 6-7 months.

    • Anthony Hortin 2:48 am on August 21, 2015 Permalink | Log in to Reply

      Number one choice would a Customizer redesign. Very few people like the existing Customizer, as can be verified by the amount of discussion about it over the last few of months. If you want the Customizer to become more universally accepted among developers and end users, it needs to be redesigned and made significantly wider (whether that’s by allowing it to be ‘undocked’ or just generally wider). The single column layout leads to extremely long columns which means pages and pages of scrolling, which is horrible. The Customizer should be redesigned before anything else is added to it.

      I’d also love to see the ability to make folders in the media manager. Finding images on sites that have a huge amount of media, is extremely frustrating.

    • Michael Martinez 3:33 am on August 21, 2015 Permalink | Log in to Reply

      PAIN POINT FOR USER: When editing a long post that makes extensive use of BLOCKQUOTE, switching from TEXT to VISUAL mode for any reason results in WordPress just randomly repositioning the closing BLOCKQUOTE element and destroying the spacing of the paragraphs. It takes a lot of work sometimes to clean up this mess. The problem has persisted through several iterations of WordPress.

      PAIN POINT FOR USER: Having to scroll through pages and pages of listings of comments, feedback, posts, pages, etc. because everything is blocked in groups of 20. Would LOVE to see this become a configurable parameter. Better yet, would love for Core WordPress to make these collapsible entries. I do NOT want to see infinite scrolling. I just want to be able to see a list of titles that I can click on to expand and be able to change from 20 to 50 to 100 items. I hate having to install plugins to do this.

      • Michael Martinez 3:35 am on August 21, 2015 Permalink | Log in to Reply

        PAIN POINT FOR USER: Would also like the ability to sort the spam comments by IP address. Even better, the ability to export the comments’ IP addresses as a simple list. That makes it easier to see where the spam is coming from.

      • Sergey Biryukov 2:27 am on August 27, 2015 Permalink | Log in to Reply

        Number of items per page is configurable on Screen Options tab in top right corner.

    • fabianhenzler 5:08 am on August 21, 2015 Permalink | Log in to Reply

      Oh man it’s the REST API :)
      Blazing fast and easy to extend. Getting a 1000 posts in one batch in 100ms and easy extandability of custom routes and stuff would be awesome =D

    • Torsten Landsiedel 7:53 am on August 21, 2015 Permalink | Log in to Reply

      And it would be great if someone would spend some time on this one:
      https://core.trac.wordpress.org/ticket/17268

      (using native gettext would decrease memory usage)

    • stesod 8:32 am on August 21, 2015 Permalink | Log in to Reply

      It would be nice with support for changing upper or lower case from the context menu when editing a post.

    • pixelverbieger 9:18 am on August 21, 2015 Permalink | Log in to Reply

      a) better media management (folders, tags, groups or whatever)
      b) change the standard table prefix from “wp_” to something dynamic, like “wp_4dh6Bv3_”

    • woltis 9:23 am on August 21, 2015 Permalink | Log in to Reply

      What is really necessary:

      • A real good date-picker for posts and pages

      It’s really not state of the art to select the post date and time by manual entry of the date and a month-dropdown. I often have to look up the day for e.g. next monday in my computer calender, to enter it into WordPress. A small calendar in WordPress to select a special day really should be implemented.

    • Daisuke Takahashi 10:14 am on August 21, 2015 Permalink | Log in to Reply

      Please merge “WP Multibyte Patch”!
      https://wordpress.org/plugins/wp-multibyte-patch/

      WordPress has a lot of broken points for multibyte users without this plugin!

    • Adrian Pop 10:40 am on August 21, 2015 Permalink | Log in to Reply

      My wishes for 4.4 are:

      • Multilingual from core
      • Native reordering support for pages and taxonomies (drag&drop/numbering)
      • Shortcake
      • Fields API
      • Full SVG support
      • Better media library organisation (folders/filters/tags/dynamic search) and dynamic media resizing (for raster images)
      • Better UI for Customizer with Typography and Color support
      • Stagger Lee 10:03 am on August 22, 2015 Permalink | Log in to Reply

        You reminded me about this.

        I would like to see “Plugin organizer” and “Dynamic Widgets” adapted, changed and implemented in the core. At least as featured plugins first.

        While I dont use Dynamic Widgets on most simple webistes, with simple company presentation, I do use “Plugin Organizer” plugin on ALL websites. And it works, never failed.

        For now plugin is enough, but it is just one man, one plugin, and can dissapear. Some speed up of plugin would be also nice if it is in the core.

    • kraftner 10:42 am on August 21, 2015 Permalink | Log in to Reply

      And please finally fix the broken hook system for nested calls:
      https://core.trac.wordpress.org/ticket/17817

    • rkoller 11:08 am on August 21, 2015 Permalink | Log in to Reply

      Timber (http://upstatement.com/timber/) in the core would be neat.

    • Alvaro Gois dos Santos 11:35 am on August 21, 2015 Permalink | Log in to Reply

      A simple backup procedure included in the updates screen would be great. Even if there’re several backup plugins, average user would benefit a lot from a simple backup – instead of a message telling him to backup and pointing him to WordPress.org!

      I’m aware that WordPress can’t anticipate the numerous server and site configs, therefore maybe an elaborated backup system (like some plugins and services offer), with roll-back implementation, is asking for the impossible. But at least a simple way to backup the database and revert to that saved version. I guess it’s the minimum we should expect from a 50% marketshare CMS.

    • hexified 12:49 pm on August 21, 2015 Permalink | Log in to Reply

      I’d like the ability to export my wordpress site into more formats than just XML. (PDF, DOCX, CSV, etc). PDF and DOC would especially be useful.

    • chrisedmo 1:26 pm on August 21, 2015 Permalink | Log in to Reply

      I would like to see more work on the Api – or to have it included in this release :-) And I would like to see more work done in the image editing area. WordPress is massively lacking in this area. To have something like Glide (http://glide.thephpleague.com) included would bring WordPress to the current era. this is now more important than ever, especially with retina screens and the picture element in HTML/CSS. We need easy ways to spit out different sized images and to be able to handle compression etc would be a bonus.

    • Howdy_McGee 2:18 pm on August 21, 2015 Permalink | Log in to Reply

      If `/wp-includes/canonical.php` stopped throwing errors in my debug log for unchecked indices i’d be so happy… https://core.trac.wordpress.org/ticket/32229

    • Helen Hou-Sandi 3:13 pm on August 21, 2015 Permalink | Log in to Reply

      I’d like to rethink the publishing workflow – the metabox is overbearing and there are UI-induced problems, like how “status” and “visibility” are separate even though they are the same field (still just status). It’s also removed from the flow of composing a post – since we “dock” the bottom of the editor now, I think it would make far more sense to be there, and use the split button UI from Press This. There are lot of other considerations to be made (post types without an editor, what kind of label the current “publish” metabox gets instead, what happens if we ever manage to properly have custom statuses, etc.), but that’s a rough idea to start from.

    • HoaSi 4:04 pm on August 21, 2015 Permalink | Log in to Reply

      RICG Responsive Images
      Term meta

    • thomask 4:22 pm on August 21, 2015 Permalink | Log in to Reply

      One more idea (but still the multilanguage support is the most important for me) – migrating tags to posts, if not fully in DB, than at least the tag table view and edit view, so that they would use the same edit.php table and post-new.php table (of course with some widgets missing).

      It would have huge advantages – it would be easy to add extra custom fields to the tags the same easy as for posts, it would standardise it all so it would save a lot of that extra development for two different “item types”, and if it would be really considered the same “item”, with only different fields, it would allow also “post to post” relations (e.g. typicaly “actor” for “film”, or “author” for “book”) or “taxonomy to taxonomy” relations (e.g. “country” and “popularity”.

      and another idea: one extra column for custom fields. Currently all fields are onedimensional – key+value. But if you need twodimensional field (table of values with rows and columns), it is very hard to do it and you need extra plugins.

      and third thing, that I really hate with developing anyting in wordpress – missing form field definitions. So you have to always type e.g. input type = text, value …, so there is no standardised form field, with standardised look, standardised value check, standardised saving procedure etc. It would be great if all form fields would have their function, e.g.
      form_text(name, value, array(optionals: class, id, …), that would result in input type=text …
      form_number (name, value, array) -> input type=number
      form_input (name, value, array) -> generic input (without optional type it equals to form_text)
      form_textarea (name, value, array) -> textarea
      form_select(name, value, array values, array) -> select

      It would help all developers and plugin developers standardise the look and experience for customers, and faster the development

      • J.D. Grimes 7:08 pm on August 21, 2015 Permalink | Log in to Reply

        Re: form fields: See the Fields API

        • thomask 1:00 am on August 22, 2015 Permalink | Log in to Reply

          thx, i have seen it before but forgot it :-) This seems to be far more complex ten my proposal, and this OOP way is not typical for WP, but it seems it do what i was proposing. But it should also consist of the second step – rewrite all the WP forms, so that they will use the new fields API – this would assure, that i can really do all the fields everywhere. Because from what i see with my limited knowledge it seems, that this fields api can be used only in few preselected areas, so e.g. if i want to add another select with another filter next to the other filters above the post list table, it will not help me anyhow.

    • leemon 5:30 pm on August 21, 2015 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/10142 – Add metadata support for taxonomy terms
      https://core.trac.wordpress.org/ticket/21734 – Completely remove global terms
      https://core.trac.wordpress.org/ticket/14310 – Make template hierarchy filterable
      https://core.trac.wordpress.org/ticket/22938 – Presentation of hierarchical taxonomy in Media modal should be checkboxes rather than comma-separated tag list
      https://core.trac.wordpress.org/ticket/13310 – Extend option_name to varchar(255)
      https://core.trac.wordpress.org/ticket/32101 – Ability to mark plugin as unmanaged
      https://core.trac.wordpress.org/ticket/22942 – Remove Post by Email

    • Paal Joachim Romdahl 6:12 pm on August 21, 2015 Permalink | Log in to Reply

      Here are some of my ideas.

      • Reordering of all posts and all pages similar to how menus are handled. (very important as it is very tedious how ordering of posts is today.)
      • Media library sorting, replace image with another image and a download image library content button.
      • Better plugin handling. There was a suggestion some work on this earlier but I do not know what happened to the discussion.
      • Media Widget and TinyMCE widget. A remove active widgets button. Enable and disable widgets.
      • Better content creation is sourly needed. A visual grid/table/columns for an easy way to add content.
    • Randy Douglas 6:58 pm on August 21, 2015 Permalink | Log in to Reply

      We are pushing the limits of WordPress to make it a documentation CMS. We struggle with user dissatisfaction over the editor. They are comparing to Word/dreamweaver/visual studio. Anything you can do to make the editor better w/r/t the following would help:

      1) Continue to make it even easier to drop in word or PDF content and get rid of tags and work better with the tags it does not strip.

      2) Make the editor better. It has some of the following problems:

      a) Switching between tabs cause code to change or to lose changes
      b) WordPress introduces some code bloat on it’s own
      c) List positioning doesn’t work all that well
      d) It is not as good as some other live html editors
      e) Grammar/spell checking could be better out of the box
      f) It eliminates too much code. For example, sometimes you **really** need a
      tag. But WP assumes you meant to have a space, which cause the graphics to stay on the same line as the previous text line in many cases. There should be a built in break tag that sticks. You shouldn’t have to fool it by adding a blank class to the break tag. Similarly, it should not eliminate

      . I know that sometimes this is a mistake, but most commonly it is not. It should be easy to turn off this kind of heavy-handed code bloat stripping.
      g) The visual editor should work more like dreamweaver.
      h) There should be a setting where the editor may determine whether tag stripping occurs on save draft/publish or whether it keeps the text verbatim.
      I) Switching tabs should never change the content.

      Thanks for all your work. We really like WP overall.

      • Randy Douglas 7:03 pm on August 21, 2015 Permalink | Log in to Reply

        I forgot to mention that we have tried the default editor and are using the TinyMCE Advanced editor currently. I realize that some items could be introduced by these enhancements, but overall this editor seems to function like the original with extra features. This may be the most popular plugin (seems to be what most people use), so that may be consideration when working on the default editor.

    • JenniferBourn 7:02 pm on August 21, 2015 Permalink | Log in to Reply

      Thanks for asking for feedback and suggestions! One thing I would LOVE to see, is the Preserve Editor Scroll plugin (https://wordpress.org/plugins/preserve-editor-scroll-position/) rolled into core. It would make saving and editing your work so much easier. Right now every time I save what I’m writing or editing it jumps me back to the top and I have to scroll back down to where I was … I can’t be the only one who gets frustrated by this :) I think lost of users would benefit from this.

    • Patty J. Ayers 7:31 pm on August 21, 2015 Permalink | Log in to Reply

      All I ask:
      (1) Get rid of need for Kitchen Sink button
      (2) Change “Cheatin’ Uh?” to a real error message

    • Dave Navarro, Jr. 7:57 pm on August 21, 2015 Permalink | Log in to Reply

      Bring back “sorting” when searching the repository for plugins and themes. I’d like to sort them by number of installs and filter out anything that hasn’t been updated in a while.

      Also, I know this was briefly discussed, but you PLEASE indicate which plugins are free and which are “freemium”. The only people opposed are those who sell freemium plugins.

    • dryanpress 8:44 pm on August 21, 2015 Permalink | Log in to Reply

      Built-in concatenation method with minification would be nice to have as an alternative to enqueuing registered scripts. Running lots of plugins is typically discouraged, and while there are a host of reasons… WordPress’ and lower shouldn’t look like a firing squad aimed assets at an end-user’s machine. There are a handful of plugins that do this, perhaps one of them might serve as inspiration.

      + REST API
      + FIELDS API
      + SHORTCAKE

    • Fernando Tellado 11:23 am on August 22, 2015 Permalink | Log in to Reply

      :)

       REST API
       SHORTCAKE ++++
       GET RID OF AKISMET AS DEFAULT PLUGIN
       MULTILINGUAL SUPPORT
       SEO SETTINGS
       COMMENTS SYSTEM WITH SOCIAL INTEGRATION
       LIVE EDIT

    • Nathan Shubert-Harbison 6:29 am on August 23, 2015 Permalink | Log in to Reply

      For ease of deployment and migration, no longer store the site url in the database. Drupal, for all its shortcomings, doesn’t store the url in the database and migration is easier for it. It would be great if WordPress made this move.

    • Naser Mirzaei 8:38 am on August 23, 2015 Permalink | Log in to Reply

      • JSON Rest API
      • Fields API
      • Media Tag and Category
      • Remove Akismet and Hello Dolly from plugins
      • Update core with new features, make WordPress settings totally handle with Fields API.
      • Force new plugin developers to use core features, not their own.
      • Add a warning for plugins that tested and now used in core. like favicon
      • separate more features from core and add them as official plugins. like comments, multisite.
      • enable to set password on user registration and send activation email instead of password email
      • built-in minify and combine for html, css,js
      • Ability to add template for admin pages in theme
      • User Groups
      • More Ajax in admin
      • Email Templates

      Some of features that i and others requested should not be built-in, but its better to tag some plugins as official by WordPress development team

    • trickywinger 11:15 am on August 23, 2015 Permalink | Log in to Reply

      I’d truly love to see an easier way to change headers i.e. inserting sliders without having to change code. I can’t believe given so much is made of drag and drop, ease of use, anyone can do it blah blah blah… its not here already frankly. Sorry to whinge its just a major gripe, particularly if you’re not a WP expert. Simply stops me loving this software :)

      • trickywinger 11:32 am on August 23, 2015 Permalink | Log in to Reply

        Sorry Scott, just read my post and it really is grumpy… apologies mate. I do truly want to love WordPress, but I just can’t – yet. It simply doesn’t do what it claims – yet – unless you understand and more importantly keep up with the technology. I’ve read many of the posts on here and though they are pretty much all valid, they just read as if they are from people that love WP or the internet or computers etc. I haven’t seen a single ‘plain English’ comment. And in no way do I mean that as an insult guys, its just if its only you clever people that are developing WP it will continue to go the ‘isn’t this a neat idea’ route and too slowly towards the truly practical website building tool for the world, which this clearly should be (and somehow probably is at the moment).

        I’m reminded of the space race story of the Americans spending millions of dollars to develop a pen that would work in zero gravity while the Soviets used a pencil. Sometimes these things can be just over thought. Anyway enough said. I do love WP despite these comments, I’d just like to love it more!

        And before you ask, I’m a business consultant, have been for many years to some of the biggest companies in the world, have worked on Apple systems since it started and PC’s with DOS before that, so I’m not a newbie. I now run a local newspaper in Southern England, look after the odd website for friends and colleagues while playing as much guitar as I can.

        Once again sorry for being so grumpy Scott and the very best of luck going forward.

        :)

      • medical-hero 7:53 am on August 26, 2015 Permalink | Log in to Reply

        I really understand that only half way, I’m sorry. If you’re not an expert user you can have hardships with WP when it comes to special tasks. It’s because the audience developed itself. At first it’s coded for really fast posting without anything special. Then it was merged with the idea of a content management system (cms). So it’s neither fish nor fowl for many people. For simple bloggers WP is oversized. For others too limited without plugins so they load a bunch of them. I do so too because I can’t code PHP but want to expend it to a fully-fledged cms like typo3 in a easy way.

        My background: My very first internet project was in the late ’90ies. Later I served small online shops with osCommerce or a portal with php-nuke. Now I want (or have) to build advanced portfolio sites without needed coding knowledge or specialised plugins – that has hardships all the time but I love WP more. It’s like a long time marriage: My wife WP jerkes dinnerware at me and I have to buy some flowers… And then come my brother-in-law WPML, my sister-in-law Toolset and her step-sister PODS with their own families for x-mas… Help me, father, I’ve sinned! 😉

    • Kent McDonald 12:01 pm on August 23, 2015 Permalink | Log in to Reply

      When placing a link that directs to an outbound URL I would like action to DEFAULT to a new tab or window so my user is not yanked from my site. Currently I have to click an option box. I prefer my users to keep my original site open and have an option to read the destination link on a separate tab.

    • Glen Charles Rowell 3:52 pm on August 23, 2015 Permalink | Log in to Reply

      Can the galley link images to custom URLs yet?

    • Glen Charles Rowell 3:55 pm on August 23, 2015 Permalink | Log in to Reply

      Smarter responsive menus with an option to change the level of responsiveness would be great.

    • Leo_Nel 8:38 pm on August 23, 2015 Permalink | Log in to Reply

      Native support for replacing media without having to use a plugin such as https://wordpress.org/support/view/plugin-reviews/enable-media-replace

    • programmin 11:55 pm on August 23, 2015 Permalink | Log in to Reply

      It may not be related to WP directly but more for hosting, but have you started considering the implications of setting up WordPress sites with HTTP3?

    • chrishoward 2:48 am on August 24, 2015 Permalink | Log in to Reply

      Filter plugin searches by WP version

    • jakkub 2:12 pm on August 24, 2015 Permalink | Log in to Reply

    • buurtaal 2:42 pm on August 24, 2015 Permalink | Log in to Reply

      A better search

    • birder 4:49 pm on August 24, 2015 Permalink | Log in to Reply

      1. An easy way by a checkmark and Cat ID posts a single category on the front page display.
      2. Additional category pages display as under (1) above for Home
      3. Category archives only with the date and title, regardless of the number of contributory display on the other pages

      . At least 1 +2 pts my wish will be possible already, but given a tinkering in php is needed, which I – frankly -‘m too stupid. But I like to bet that this is not just me geht.Und my English comes from Google Translator, so please make allowances …

    • davert318 5:59 pm on August 24, 2015 Permalink | Log in to Reply

      First… endorsements:

      Ticket 31467 Images should default to not linking
      RICG Responsive Images
      Better searches

      Second, my own requests:

      I would like performance gains!
      I would like the featured image to be automatically set if none is specified, as it is with a plugin now

      It would be nice if the featured image could be chosen from a library of external images which have already been resized and used as featured images, if that makes sense. I often use image links because WordPress is only part of my site, not a standalone. When I do this, WordPress obviously makes a smaller version but I can’t select that from the media library.

    • primaryimage 10:58 am on August 25, 2015 Permalink | Log in to Reply

      Me (& my users!) would love to have a UI for columns in the WordPress back-end. I know Shortcode UI offers potential with this (+ there’s already visual editors available). but I think there’s an opportunity to have something relatively simple that’s standardised in core. At the moment different themes all use their own shortcode conventions and, even for straightforward two column layouts, it can get quite messy on the screen!

    • Marcus 1:25 pm on August 25, 2015 Permalink | Log in to Reply

      I’m all for the idea of fixing past tickets and JSON Rest API.

      As an idea though what about a Safe Mode? I just had to deal with this today, it’s an inevitably common scenario:

      Them: Hey, my site went blank, what gives?
      Me: Sounds like a plugin or theme update screwed up your site. Please disable your plugins via FTP.
      Them: What’s FTP?

      Wouldn’t it be awesome if there was an easy way for users to go in via a safe mode and disable plugins/themes. It could come with a default skeleton theme in the event there’s no default WP theme (or it has been modded). Additionally, maybe a limited number of logins since security plugins will be disabled too.

      A plugin that has this is – https://wordpress.org/plugins/safe-mode/ – awesome idea but the crux is most people need it when they can’t actually install it!

    • Ben Huson 2:16 pm on August 25, 2015 Permalink | Log in to Reply

      Better support for taxonomy fields in Medial Modal. See #28053, #22938 relating to implementing category checkboxes in the modal and #31691

    • DenverEric 5:11 pm on August 25, 2015 Permalink | Log in to Reply

      It would be great to see more of the most popular, low weight features migrated from Jetpack into the core like was done with the site icon in 4.3.

      Ideas for inclusion:
      -Widget Visibility
      -Contact Form
      -Carousel & Tiled Galleries
      -Extra Sidebar Widgets

    • Gabriel Mariani 5:41 pm on August 25, 2015 Permalink | Log in to Reply

      I don’t get what all the excitement is over the REST API, but what I would like is the silly ability to just upload a theme/plugin an overwrite the existing just like any other update would. Instead of uninstalling and reinstalling or uploading over FTP.

    • medical-hero 6:54 pm on August 25, 2015 Permalink | Log in to Reply

      My wish list – highest priority for me have the following points:

      • Native networks with domain mapping
      • Multi-language support (I won’t use WPML forever, way too expensive over the time for personal usage)
      • Native reordering support for pages and taxonomies (drag&drop and numbering)
      • Shortcake
      • Fields API
      • Full SVG support
      • media library (folders, filters, tags, ajax search and dynamic image resizing
      • REST API
      • Term Meta
      • Posts2Posts, Post2Pages, Pages2Pages, Pages2Posts, Post2CPT, Pages2CPT, CPT2CPT and so on
      • one2one, one2many, many2many bidirectional relationships and magic tags (pods)
      • And lastly better cms like workflows for professional admin and editorial groups as core plugin

      — more complex reviews like approval of one or several persons in different roles and processing steps
      — managing ideas, tasks and assignments in several steps to the final version of articles or other post types
      — reference plugins: Oasis Workflow, Edit Flow and Contenido

    • dunkelangst 7:17 pm on August 25, 2015 Permalink | Log in to Reply

      Please delete all emojis!!

    • wolf99 1:04 pm on August 26, 2015 Permalink | Log in to Reply

      Preventing the creation of users with the same nickname as username (Or an admin option to enable this) would be a nice quick little security improvement perk :)

      (In case you didn’t know, a lot of the automated attacks recently on WP scrape posts for publishing author names and then use those as user names in brute force attempts on the password gate. Preventing user names from being the same as author names closes of this avenue quite simply, by keeping usernames “internal” to a WP install).

    • Jacob N. Breetvelt 1:38 pm on August 26, 2015 Permalink | Log in to Reply

      Two more wishes:

      • wp_delete_post( $postid ); To also delete references to the post in any menu, active or not.
      • A way to add a stacktrace, especially to wp deprecated error messages, so you can easily find which plugin / widget is outdated.
    • closemarketing 2:28 pm on August 26, 2015 Permalink | Log in to Reply

      Fully support to responsive images. Make add_image_size, support diferent sizes depending of device, or the function wp get attachment support responsive images.
      Thanks!

    • mumbomedia 6:50 am on August 27, 2015 Permalink | Log in to Reply

      Opportunity to make custom folders in the media libary.
      This would come in handy if e.g. you have a large woocommerce shop with a great amount of product images. If you could make custom folders in the media libary you could make a folder for each product allowing you to easily find images which refers to deleted products and therefore you could delete these picture absolutely sure that they’re not used anywhere else.

    • galbaras 8:27 am on August 27, 2015 Permalink | Log in to Reply

      Hey Scott,

      One more wish: at the moment, the function check_comment() excludes trackbacks from automatic approval, because there’s no author email or author IP. However, when the author URL contains the current site, this should be pretty safe to approve automatically.

      Options:

      1. Always approve trackbacks from same site
      2. Add a new discussion setting to decide whether to do this or not
      3. Add a filter to override the return value of check_comment()

      Thank you,
      Gal

    • moritz.klassen 9:48 am on August 27, 2015 Permalink | Log in to Reply

      *BETTER PREVIEW MODE*

      It would be nice to be able to set the WHOLE website into a kind of “PREVIEW MODE”. So that you can see for example how a new article would effect the startpage or listing views.
      At the moment you can just preview a new article but sometimes its really difficult to calculate all sideeffects. So you never know how your startpage looks like after publishing.

      Thanks,
      Moritz

    • Sam wc 3:08 pm on August 27, 2015 Permalink | Log in to Reply

      WordPress team not looking at Frame work such as laravel,Yii,cakephp etc.Please make it very powerful such as this frame work. Because we love wordpress never wan’t to down when compare with these frameworks .

    • Sam wc 3:09 pm on August 27, 2015 Permalink | Log in to Reply

      (1)Could you please add some more functions that assist in working with forms.

      (2)Captcha support by default

      (3)Could you please add some more permalink structure tags like %taxonomy%,%sub-taxonomy%,%sub-category% and way to arrange them

      (4) great pain is trying to make WP work with Angular.js or similar for building web apps.

    • Matthew 4:10 pm on August 27, 2015 Permalink | Log in to Reply

      Just one thing. Fix bugs.

    • Dieter_Z 7:45 am on August 28, 2015 Permalink | Log in to Reply

      There is one thing I often miss:
      That editors are allowed to edit the menus and the widgets. Clients often need to make changes to the main menu or side menus and the footer area also. I think it should be a core feature that you can easily allow editors to make changes there. Only menus and widgets, no further items of “appearance”.

    • chatmandesign 5:24 pm on August 28, 2015 Permalink | Log in to Reply

      Besides the REST API & improved media management, I think one of the biggest existing issues with WordPress is the search system. It’s really not very useful without adding a plugin like Relevanssi or SearchWP. While the full GUI for weighting keywords, indexing custom fields, etc., that comes with those plugins is probably overkill for core, at the very least search should provide features like keyword relevance sorting, fuzzy matching, and “did you mean” recommendations that are standard in most modern search engines. I also think there should be standardized flags developers can use when adding custom post types to specify metadata fields that should be indexed for that post type.

    • chatmandesign 5:27 pm on August 28, 2015 Permalink | Log in to Reply

      Here’s another improvement I’d love to see: Better integration between the post editor and menu building. I’ve never understood why selecting which menu a post or page should show up in isn’t as simple as making a selection in a metabox when creating or editing the page.

    • chatmandesign 5:51 pm on August 28, 2015 Permalink | Log in to Reply

      Here’s a biggie: Login security improvements. Most security plugins require making a lot of decisions that are over the heads of average end users, but I can think of two fairly simple steps that could be taken to dramatically improve security without significantly complicating anything for users:

      1) Automatic account lockout for a predetermined short period of time (say, 5-20 minutes) after a set number of failed login attempts (say, 5-10) within a set period of time (again, 5-10 minutes). This is fairly minimal, but would slow brute force attacks WAY down. Couple it with an unlock system based on emailing an authentication code (usable once per lockout period perhaps) and you basically get quick ‘n’ dirty temporary two-factor authentication for locked out accounts, which prevents lockouts caused by brute force attacks from keeping out the legitimate account owner.

      2) Get rid of the default “admin” username. You have to enter an email address when setting up WordPress already, right? Instead of the administrator account defaulting to “admin”, it should default to the first part of the email address entered. That way it doesn’t require the user to make any more decisions than they already do, because there’s still a default username set, but it’s a different default for every user; and since it’s based on their email address (not something random), it’s just as easy for the user to remember.

    • goldnerj 6:48 pm on August 28, 2015 Permalink | Log in to Reply

      For large scale orgs, a feature where administrators can “lock out” anyone who’s not an admin. During maintenance windows, outages or other problems where people need to be shut out.

    • Matt Mullenweg 8:59 pm on August 28, 2015 Permalink | Log in to Reply

      I’ve read all the comments up to this point, lots of interesting suggestions and things raised.

      I realize the make/core blog is developer focused, but I wanted to particularly thank people who brought up user perspectives on things, or thought about how features or functionality impacts a new user’s experience or the overall growth curve of WordPress itself.

      It’s worth thinking about everything proposed in three buckets:

      1. New features and iterations on existing functionality that make WP easier to use for new and non-technical users of WP. These are our “headline” features. When we do these right, people adopt WP because of them, or are more likely not to churn. These days these features tend to be javascript-driven.], and ideally can be done as feature plugins first.
      2. Behind-the-scenes new and iterated functionality targeted at developers, the people who build sites for the people in the bullet point above. Think APIs, optimizations, performance, data structures. Out of the box these might not change anything in WP’s user interface, or require code (plugin, config file change) to activate. Developers are more likely to adopt WP because of these. Almost always PHP. Some (like REST API) make fantastic plugins.
      3. Maintenance, triage, bugs, unintended “features” on certain platforms. This is the important janitorial work that is ongoing and key to a healthy project. Think of open tickets, bug gardening, automated tests, some performance and optimizations. These are usually edge cases, but the edge cases add up. You probably never notice these unless you run into one personally. Always core commits.

      A good release is usually about 50% user, 30% dev, and 20% maintenance. Occasionally we should do releases that are almost entirely (80%) maintenance, just like you might do a deep clean of your house once or twice a year, like Apple is doing with iOS9 and El Capitan this year.

    • Guizillanet 9:13 am on August 29, 2015 Permalink | Log in to Reply

      It would be great, if a fonction to create child-theme was created. Just a button. It creates folder, function.php and style.css with the code to join the themes.

    • nfuller52 2:57 pm on August 30, 2015 Permalink | Log in to Reply

      Built in support for multiple environments with development and production available out of the box and development being the default

  • Robert Chapin 8:05 pm on July 23, 2015 Permalink |
    Tags: , ,   

    Changes to the Shortcode API 

    Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API. Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.

    With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.

    Reminder: Never, under any circumstances, should you hack core files. This includes downgrading specific files. Doing so could have unintended consequences on your WordPress installation, including major security implications.

    Basic Shortcode Usage

    A brief explanation on the original purpose of shortcodes will help to explain the change. In a basic post, like this example, shortcodes are used to insert dynamic code:

    Here are my images. [gallery]

    Here you can see that the shortcode stands on its own as a dynamic element within the blog post content. This is the central premise of the Shortcode API: make it easy to insert blocks of dynamic code.

    Shortcodes with Filtered Styles

    In today’s release of WordPress 4.2.3, however, we’ve added some new limitations that affect some existing plugins. Take, for example, the following shortcode, which is no longer recognized:

    <div style="background-image: url('[shortcode]');">

    The shortcode in the example above appears in a context that is no longer supported. Further, this use of a shortcode stretches the imagination for how the Shortcode API was intended to be used. Fortunately, there are some workarounds still available, so that site administrators are not overly restricted in their use of HTML.

    Workaround

    The following example still functions as expected and is considered more acceptable:

    <div [shortcode]>

    Going forward, plugins implementing shortcodes for inline styles should output the entire style attribute rather than a bare value. Keep in mind that this workaround – just as the original example above – is only available to administrators and editors (i.e. only roles with unfiltered_html). Less-privileged users are still prevented from using shortcodes to output whole attributes in this manner. If a plugin is intended to work with author and contributor roles, we recommend that the plugin output an entire <div>.

    Shortcodes with Bad Quotes

    The following example is also no longer allowed:

    <a href="/[shortcode query="?ref="]">

    In the above situation, the shortcode is now properly recognized as HTML and it is rejected by the API. Apart from the example being confusing, WordPress cannot parse that shortcode.

    Workaround

    Instead, either of the following examples would be appropriate:

    Example 1: <a href="/[shortcode query='?ref=']">
    Example 2: <a href='/[shortcode query="?ref="]'>

    Administrators as well as lesser-privileged authors can continue to use shortcodes in this way, as long is it conforms to the usual HTML filtering rules. However, as explained in the first example, administrators are now somewhat limited in this situation in one case: if the content in this href attribute is generated by a shortcode that does not conform to the HTML filters, then the shortcode is rejected for all users.

    We do not make this change lightly and understand that it may affect some usecases. The above examples and explanations should help plugin authors make the modifications needed to support the Shortcode API.

     
    • Mickey Kay 9:30 pm on July 23, 2015 Permalink | Log in to Reply

      And. . . half our client sites just broke :)

    • Dave Navarro, Jr. 9:55 pm on July 23, 2015 Permalink | Log in to Reply

      may affect “some” usecases…

      LOL! How about, you broke half the internet without so much as a “howdy do”.

      And if it worked before, why exactly can’t it work now? I am still not understanding why it had to change. WordPress itself was not intended for many of its uses today, are you going to start forcing people back into blogging? Designers/developers made better use of it than you intended and you don’t like that?

    • arippberger 9:56 pm on July 23, 2015 Permalink | Log in to Reply

      Can we get a list of the affected plugins?

    • Dave Navarro, Jr. 10:07 pm on July 23, 2015 Permalink | Log in to Reply

      Every single plugin that adds shortcodes that could be used inside of an HTML element. Not because it’s a security issue, but because someone doesn’t like how we play with our toys in their sandbox.

    • kitchin 10:12 pm on July 23, 2015 Permalink | Log in to Reply

      The shortcode API has never been well-defined, as far as I know. What html is allowed in a shortcode, and how shortcodes are allowed in html tags has changed over time. Scanning for the use case above would be difficult since it would involve the help files and sample tags shown to users, which may be formatted with sprintf, etc.

      The API should be defined. The test cases are the de-facto definition, but they are ad-hoc and clearly not complete. It’s very complex, with nesting issues and all the rest.

      I don’t know the security bug, but I wonder if malicious uses could have been filtered out more directly as a short-term fix, until the API was rewritten.

      • kitchin 10:20 pm on July 23, 2015 Permalink | Log in to Reply

        As a further example of complexity, many people are not aware that < and > are legal characters in html attributes, and some authors use them, for instance in sample code in the jQuery plugin Cycle2.

        The shortcode API was never intended to contain a complete html parser, and never claimed to. But it also did not strictly limit html or quoting, as it should have. Really it should have allowed either tags in html or html in tags but not both. Too late now.

    • Braad 10:19 pm on July 23, 2015 Permalink | Log in to Reply

      We’re experiencing some major frustration as a result of this change, and now plugins like Toolset’s Types and Views are basically non-functional. There are a lot of confused and unhappy people filling up their support forum right now: https://wp-types.com/forums/topic/types-shortcode-breaks-after-wordpress-4-2-3-autoupgrade/

      Even if this was a necessary change, it’s one that has far reaching implications, and it would have been nice to get a heads up that this was coming so we could have prepared. A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

      We’re already seeing people on support forums tell each other to just replace the shortcodes.php file with the version from 4.2.2, which as Mark Jaquith has pointed out is not a good idea, but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

      • chriscct7 10:49 pm on July 23, 2015 Permalink | Log in to Reply

        A simple “Hey, the next update to WordPress will remove support for this use case for shortcodes, so update your sites and plugins now” would have been enough.

        As stated above, this was not possible.

        but this will be what many non-developer users try when they find out that 4.2.3 broke their sites and they start googling…

        The majority of WordPress users who are not developers will not know how to replace a file on a remote web server.

        • Braad 12:31 am on July 24, 2015 Permalink | Log in to Reply

          Saying something like “Here is a use case for Shortcodes that will no longer be supported” is different from saying “Here is a security vulnerability and how you exploit it”. I have a hard time believing that some form of notice couldn’t have been given, even if it was only given a day before the update.

          But that said, the core devs who deal with this stuff are in a tough position and deserve a big thanks for their hard work. Hopefully they can find a way to keep supporting the affected shortcode use cases while still keeping things secure.

    • Angelika Reisiger 10:20 pm on July 23, 2015 Permalink | Log in to Reply

      Sorry, please delete my previous two posts. I could not post the complete code snippet.

      So here again:

      I tried to follow your recommendation in the article. But whatever I try, it does not fix the issue ticket #33097
      Below is the code:

      http://pastebin.com/8xvN2eb1

    • mvandemar 10:41 pm on July 23, 2015 Permalink | Log in to Reply

      This change is listed as “Improve the reliablity of shortcodes inside HTML tags.” It says absolutely nothing about this being a security issue. Do you have a link to the actual security issue this change fixed?

    • James Huff 10:44 pm on July 23, 2015 Permalink | Log in to Reply

      Thanks for doing this, both the security fix and the write-up!

      I appreciate that the concern was on security over functionality. Existing functionality can always be fixed, and sometimes a better way of doing things is found, but recovering from a security vulnerability is a *nightmare*.

      Thanks again for keeping us safe!

      • Dave Navarro, Jr. 10:56 pm on July 23, 2015 Permalink | Log in to Reply

        Nothing in this write-up says that this is a security issue. Nothing in the release notes say this is a security issue. This is about how they don’t like how shortcodes are being used, so they put a stop to it. And I guess if they don’t like it, they can change it. But if it’s not a security issue, why change it in a security release without any notification so that it breaks hundreds of thousands of web sites? Why not announce “in 4.3 your shortcodes aren’t going to work anymore” and release it then? Well, because someone messed up and merged the update into core prematurely. So rather than fix the mistake, just roll with it…

        • James Huff 11:00 pm on July 23, 2015 Permalink | Log in to Reply

          Nothing in this write-up says that this is a security issue.

          It’s in the very first sentence, “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You’re welcome to form whatever theory you’d like to, I’m just reflecting the published facts.

          As far as I see it, the developers had to make a choice, security or functionality. They chose security over functionality, and I’m thankful they did. It’s the right choice.

        • mvandemar 11:01 pm on July 23, 2015 Permalink | Log in to Reply

          @Dave – the very first sentence in here says that it is a security issue:

          “Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API.”

          You are correct though that nothing in the release notes, or the bug track that I can see, indicates that this is the case.

    • Curtiss Grymala 11:07 pm on July 23, 2015 Permalink | Log in to Reply

      First of all, I want to say that I do truly appreciate the quick security fix, and I fully appreciate how much work is going into keeping this codebase up-to-date.

      Granted, the original example I originally posted in my trac ticket (<a href="/[shortcode query='?ref=']">) was a bit confusing, but I don’t necessarily agree with the idea that this can’t be fixed just because it’s “invalid inout”. A perfectly reasonable example could have been something more like <img src="[post-thumbnail size="thumbnail" id=55]" alt="I want an alt attribute"/> (maybe an example where you want the user to be able to dynamically reference the featured image of another post) or something like that. I don’t see that example being confusing at all, but the results, for most users, will be terribly confusing.

      As someone else already mentioned, this had a major effect on the functionality of the Toolset (Views) plugin, but it also has major implications on a number of other plugins, and, due to the fact that these changes only occur inside of HTML tags (so things may not be visibly broken), it may be a long time before people fully realize how much of their sites are broken.

      Normal users will not understand why things don’t work; they’ll just know that they don’t work (as we have seen from all of the reports blaming the authors of Types & Views for these new issues).

      As plugin authors, we are now responsible for telling users that, if they want to use double quotes in their HTML tags, they have to wrap their shortcode attributes in single quotes. However, if, for some reason, they want to use single quotes in their HTML tags, then they have to wrap their shortcode attributes in double quotes. As if that’s not confusing enough; if we try to help our users out by building an MCE plugin that auto-inserts our shortcodes, we either have to build it to be smart enough to recognize whether there are single quotes or double quotes around the selection, or we’ll have to tell our users to change the tag because it won’t work this way.

      I, better than most, understand just how difficult fixing this issue can be without rolling back the fixes/changes that were released today, but I am not excited about the prospect of breaking so many existing implementations just because it’s tough to come up with a fix. I hope that some minds greater than mine will continue to look into possible solutions for this issue (not necessarily the background-image example, but at least the quotes-within-quotes issue), rather than just writing it off as a won’t-fix.

      • Ipstenu (Mika Epstein) 11:19 pm on July 23, 2015 Permalink | Log in to Reply

        For those playing at home, the trac ticket is https://core.trac.wordpress.org/ticket/33102

        • Curtiss Grymala 11:44 pm on July 23, 2015 Permalink | Log in to Reply

          Thanks, Mika. I probably should have included that link in my reply.

          Also, again, I want to make it clear that I’m not complaining about the security fix (I hope I’m not coming across that way). I agree 100% with @macmanx above, in that I’d much rather have to go through and fix code issues for clients (even if I have to do so for free) than have to deal with security intrusions.

      • Dave Navarro, Jr. 12:11 am on July 24, 2015 Permalink | Log in to Reply

        Custom Content Shortcode, Advanced Custom Fields, and hundreds of other plugins. This isn’t “just a few plugins” or “just a few sites”.

        And if it’s a legit security issue (I still don’t see it that way), then fine.. but handle it better. “We just couldn’t do it is a BS excuse.” And even if you couldn’t, you still should have posted a HUGE MONSTER post about the issue immediately so that there weren’t lost hours of trying to figure out the problem.

        Again, this was VERY VERY poorly handled and all I’m seeing are excuses.

    • mvandemar 11:19 pm on July 23, 2015 Permalink | Log in to Reply

      Actually, I see it now. The fixer of the XSS vulnerability is the same one who owns the bug ticket, namely miqrogroove. Someone just let me know that was where the actual issue was.

    • Mickey Kay 12:20 am on July 24, 2015 Permalink | Log in to Reply

      Third times a charm. . .

      Just to provide another example, in case it’s helpful, of the issue as experienced when using the Types & Views plugins (which seem to be a pretty huge use case based on feedback re: this issue).

      One example of how we might commonly use shortcodes within a Views template to output custom fields:

      <a href="[wpv-post-url]" title="[wpv-post-titlle]" rel="nofollow">[wpv-post-titlle]</a>

      If I had to guess, I would venture that we have upwards of 100+ sites we’ve built that use some form of the above example – all of which are now in theory broken.

      Just for clarification, can you illuminate how this is any more of a security risk than using PHP to spit out the custom field directly? Is it an issue of validation/sanitization? If that’s the case, then why is the decision being made to force a certain format, when validation and sanitization are the developer’s burden in all other cases (custom fields, theme options, customizer controls, etc)? Am I missing something?

      Thanks, and appreciate the open ears to all the feedback (however rough it might be getting at times :)

    • Mickey Kay 12:23 am on July 24, 2015 Permalink | Log in to Reply

      Goodness, this is ridiculous – tried 3 methods to include my code. How the heck do you include code in here? Not normal markdown?

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        It’s not markdown at all. Use code tags.

        <code>

      • Curtiss Grymala 12:49 am on July 24, 2015 Permalink | Log in to Reply

        You have to encode the angle brackets yourself (type the ampersand symbol, followed by either “lt;” or “gt;” – so, &lt; gets turned into <)

      • Samuel Wood (Otto) 8:52 pm on July 24, 2015 Permalink | Log in to Reply

        Perhaps unsurprisingly, we use shortcodes for that. The word “code” in square brackets will do the job for you on the make blogs.. Use “/code” to close the block.

        Example of code
        

        You can also use “php” for PHP code and “css” for CSS. Then it will have syntax highlighting as well.

        <div> html works too, it will encode the brackets for you </div>
        

        I fixed your most recent comment to have the correct syntax.

    • Dave Navarro, Jr. 12:23 am on July 24, 2015 Permalink | Log in to Reply

      So Gary Pendergast and others have convinced me that there really was a security issue, so my apologies for claiming it wasn’t. However, it still comes down to someone not taking the time to fix the security issue WITHOUT breaking so many live `web sites`.

      • Ipstenu (Mika Epstein) 12:49 am on July 24, 2015 Permalink | Log in to Reply

        Sadly that’s not always a tenable option.

        Once a security issue is known, it’s a mad race against time to get it patched before news gets out and people get hacked.

        • Dave Navarro, Jr. 12:56 am on July 24, 2015 Permalink | Log in to Reply

          Okay, well, I still think they could have make THIS post at the time the update was released and saved a lot of wasted time trying to figure out why sites didn’t work anymore…

          I’m gonna go see if I can find a snickers and if it will make me less cranky. I’ve bitched about this enough that someone on Facebook challenged me to do a better patch… Sadly regular expressions are a major weakness in my dev skills, but I’m gonna try anyway. There’s got to be a way to fix the security problem AND keep the prior functionality.

        • Timothy Jacobs 8:54 am on July 24, 2015 Permalink | Log in to Reply

          That is true in many cases, but not this one. The bug was disclosed in November of last year. Both were responsibly disclosed. And if you look at the trojan emoji security release, the core team has the ability to work on a patch for a long time. There simply wasn’t enough testing done before releasing this patch.

          • chriscct7 9:03 am on July 24, 2015 Permalink | Log in to Reply

            There was a heck of alot of testing done. However regardless of the amount of testing the way less than 1% of 1% of 1% of people use shortcodes makes it impossible not to break sites. For example: nested shortcodes inside of a single html attribute with mixed quotes.

            • Timothy Jacobs 9:23 am on July 24, 2015 Permalink

              I know not all bugs can be caught, but Views & Types seems to have quite a large user base… It just seems that the amount of testing done for this is much less than the trojan emoji bug.

    • mountainguy2 3:25 am on July 24, 2015 Permalink | Log in to Reply

      Downdate 4.2.3 broke my main site, took me 6 hours this morning to fix as I’m a total amature. These automatic updates are the height of lameness. It needs a one-click revert function, as well as a one-click revert that can be done somehow if admin access is broken, as happened to me.

      What is more, near as I could tell from reading, I was at risk for none of the vulnerabilities, I thus had my site broken for no good reason. Again the height of lame.

      MTN

    • codepage 4:42 am on July 24, 2015 Permalink | Log in to Reply

      this fix has broken easy 2 douzen websites of mine plus more of partners of mine. many plugins are broken. i’m working a lot with shortcodes and attributes in my designs. i have no idea on how to hack stuff where only the path is saved and i have for example an id as attribute. please fix this!

      • codepage 4:45 am on July 24, 2015 Permalink | Log in to Reply

        i use plugin OptionTree to make designs configurable. eg:
        <img src="[getoption">

        broke. how am i supposed to fix this? having the customer fill in the html code in a text field? that sucks.

    • lkraav 5:05 am on July 24, 2015 Permalink | Log in to Reply

      Following

    • Shailesh 5:51 am on July 24, 2015 Permalink | Log in to Reply

      Is this change also affect this case?

      <a href="[homeurl]/contact" rel="nofollow">Contact Us</a>

      In most themes I am using [homeurl] and [themeurl] to make dynamic url in links. So I don’t need to worry when I move site from local to live or sub directory to main.

    • Sam Rohn 6:04 am on July 24, 2015 Permalink | Log in to Reply

      here is an easy fix, this resolved WP 4.2.3 breaking some s2member shortcodes on one of my sites

      use single quotes ' for html attributes surrounding the shortcode, and double quotes " for the shortcode’s own attributes

      like this

      a href='[shortcode value="foo"]'

      NOT like this

      a href="[shortcode value="foo"]"

    • twinsmagic 6:39 am on July 24, 2015 Permalink | Log in to Reply

      I’m trying to get this to work:

      I also tried

      @Sam Rohn, your suggestion didn’t work for me unfortunately.

    • AmirHelzer 9:00 am on July 24, 2015 Permalink | Log in to Reply

      We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.

      This is a straight forward change, which takes us one day to complete.

      Would have been great to receive a heads-up about an upcoming change in WordPress, so we could do this change on time.

      We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

      What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

      Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

      What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

      We are your partners.

      Without WordPress (secure, stable and reliable), we would not exist.

      Without great themes and plugins, WordPress would not power 24% of the Web.

      WordPress core members already volunteer a lot of their time. I’m not asking for anyone to volunteer more time. Need help? Ask us. There is a huge community of developers who rely on WordPress. We would be happy to get involved and set up whatever is needed.

      Does this make any sense?

      • gfazioli 9:14 am on July 24, 2015 Permalink | Log in to Reply

        I agree!!

      • Mario Peshev 10:46 am on July 24, 2015 Permalink | Log in to Reply

        +1 – it’s not a one-time thing, it’s a process problem. And we had a late night urgent maintenance iteration due to a bunch of broken things for the same reason.

        It’s demoralizing for us and some of our clients don’t trust WordPress to be a stable and reliable platform that will run their business and let them sleep at night, without being afraid that things will break with zero changes on their end.

      • Rasheed Bydousi 2:10 pm on July 24, 2015 Permalink | Log in to Reply

        +1 You’re right. It shouldn’t be conducted in such a way. It is so annoying. Such changes shouldn’t be made arbitrarily. This isn’t a typical behavior pattern when it reaches to WordPress.

      • schutzsmith 2:50 pm on July 24, 2015 Permalink | Log in to Reply

        +1 Absolutely sums up how I’m feeling as well Amir! For instance, our digital agency runs on WordPress, we’ve built over 100 websites for clients on it, but as I tweeted this morning, this was the final nail in the coffin, we have to move away from WP because it’s literally killing our relationships with our own clients.

        I’m truly saddened by it because we’ve loved the community up until the last few months. It’s now at a point where we can no longer keep relying on WordPress to run a smooth and fruitful business.

      • Eliot Akira 3:03 pm on July 24, 2015 Permalink | Log in to Reply

        +1 – Thank you for articulating a sensible and constructive suggestion from the developers’ perspective. As someone who is one of the “folks who build WordPress sites for a living”, this issue has affected me greatly – spent most of the night trying to fix clients’ sites as well as doing the best to help plugin users. But more than the unexpected time and effort for support, as Amir states, the biggest worry for me is the loss of trust and reputation, both for myself as a developer but also for the clients regarding the reliability of the WordPress system.

        Last night, in a desperate attempt to find even a temporary solution, I made a plugin update which provided an option to patch one of the core files so that sites will be functional again. In hindsight, it was a poor judgement and bad mistake – but how the issue was handled was very disappointing. Apparently it was against the rules, and the plugin has been blocked from the official repository – without any warning or message to me. If someone had contacted me, I would have gladly removed the offending code. After all, I was only trying to help the situation. But now, I have no way to provide a reasonable update, and the users cannot access the support forum to get any information about why their sites are broken or what to do about it. Since there doesn’t seem to be any motivation to address the issue from the core side, we are all left hanging.

        “We are updating Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.”

        This seems to be the direction I need to take as a workaround solution, to resolve/render plugin shortcodes before passing to WP to process content. Just to note, in the original announcement are listed two cases (Shortcodes with Filtered Styles and Shortcodes with Bad Quotes) – but neither apply to the issue that I’m seeing across numerous sites.

        “What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.”

        I agree with this. At the same time, I can also see why the update was rolled out so quickly without prior notice, due to its sensitive nature. Perhaps the reasoning for not informing plugin developers is that some of them might try to exploit it. Another reason could be that there was no clear way to determine which plugins would be affected – and informing thousands of developers about a security vulnerability would have defeated the purpose of the update.

        I’m glad to see someone suggesting a positive way to look at the whole situation – what can we as developers and users learn from this on-going situation, and how can we contribute to improve the reliability and stability of WordPress sites.

        P.S. If someone of authority can contact me regarding the blocked plugin, I would really appreciate knowing how to remedy it. Almost immediately after the problematic update,I have pushed another update which removed the change. Both myself and the plugin users are waiting for any information that could help us.

      • safesoundaudio 4:03 pm on July 24, 2015 Permalink | Log in to Reply

        Well said Amir! You speak for many hundreds of us in this wonderful WordPress community.

      • dmccan 4:32 pm on July 25, 2015 Permalink | Log in to Reply

        I appreciate that the core team addresses these security issues. At this point, the WordPress ecosystem is so large that it is difficult to ascertain the impact of core changes, so I agree with Amir that we need a better process.

    • Herre 9:14 am on July 24, 2015 Permalink | Log in to Reply

      I fully understand this is an issue… but isn’t this a weird way of updating… almost al our clients are calling / e-mailing us at the moment as their sites seem to be broken…

      Normally it would be better to announce such huge impact changed to the plugin and theme developers…

      This means I need to fully reschedule my agenda… which already is full during holiday season…

    • JesseHeap 1:26 pm on July 24, 2015 Permalink | Log in to Reply

      Wondering if someone could provide some advice for us as I’m having a little trouble understanding what needs to change with shortcodes to fix our particular issue.

      The simpliest example I can give is below:

      Use Case: We use a short code to pass the HTTP_REFERER as a hidden value in our form:

      SHORTCODE in PAGE:

      Code in Theme Functions:
      //pcbReferrer
      function pcbReferrer_func() {
      return(getenv('HTTP_REFERER'));
      }
      add_shortcode( 'pcbReferrer', 'pcbReferrer_func' );

      Based on my understanding of the above, I’m not clear what I would change since we aren’t using attributes for this short code. I have other short codes that do use attributes which I’m trying to fix as well, but that’s a different story.

      • JesseHeap 4:09 pm on July 24, 2015 Permalink | Log in to Reply

        Here’s the solve in case this helps anyone:

        –ORIGINAL SHORTCODE THAT WAS NOT WORKING–

        Page Shortcode Reference:

        Themes Function Code:
        //pcbReferrer
        function pcbReferrer_func() {
        return(getenv(‘HTTP_REFERER’));
        }
        add_shortcode( ‘pcbReferrer’, ‘pcbReferrer_func’ );

        –NEW SHORTCODE THAT IS NOW WORKING–

        To solve this I moved the HTML into Themes Function PHP file. So I changed my form page shortcode to just:


        [pcbReferrer]

        And modified the function to include the HTML that was originally in the page:

        //pcbReferrer
        function pcbreferrer_func() {
        $output = '';
        return ($output);
        }

        Less then ideal as it intermingles more of the HTML with the shortcode and I always try to maintain as much separation as possible.

        But I certainly do not understand the security concerns of the prior approach so I’ll just assume this is the new constraint that we’ll need to follow for the sake of security…

        • JesseHeap 5:57 pm on July 24, 2015 Permalink | Log in to Reply

          Sorry I thought the <code> tags would leave the HTML alone but they are still stripping it away… This commenting system is a little frustrating…

    • safesoundaudio 4:02 pm on July 24, 2015 Permalink | Log in to Reply

      The change to allowed shortcode usage has NOT just affected a few RARE cases of shortcode uses. It has affected the functionality of hundreds (maybe even thousands) of websites including my own commercial site. Aside from the disaster it has caused to hundreds of web designers who use the excellent Toolset plugins, it has destroyed the functionality of a large number of other plug-ins. The forum is just full of examples today.

      As far as I can tell there was no advance notice. SOMEONE should have stopped and thought, ‘best we tell the community what we are planning’ The folks at Toolset seem to have been given no notice and they are probably the biggest plugin designers of the now disallowed shortcode usage.

      We can debate for ever what should be allowed and not allowed with shortcodes but that misses the point. Most of us are in the communication industry and this update has been very sadly lacking in foresight and communication.

      PLEASE role back this disaster of an update. I am 100% sure it was well intended but PLEASE look at the reality of what has happened.

    • crazycanuck27 6:00 pm on July 24, 2015 Permalink | Log in to Reply

      So I’m trying to pass a User Shortcode [currentuser_iserid] as a variable in an iframe and what worked for v4.2.2 suddenly broke and working to recover.


      … used to work but now it passes the shortcode as text. The shortcode works on its own. So is this an issue with the iframe and trying to pass a shortcode .. or quotes, or something else?

    • Claudio Esperanca 11:03 pm on July 25, 2015 Permalink | Log in to Reply

      is removed by TinyMCE when switching between HTML and WYSIWYG views as it is considered an invalid attribute for the tag, so it isn’t a perfect workaround.
    • minderdl 8:55 pm on July 26, 2015 Permalink | Log in to Reply

      While I can agree that wrong quotations do not need to work (i.e. one should only use single quotes inside double quotes and vice versa) the change also killed wrapping shortcodes:

      [blockcode]
      <a href="[myurl]">[mytitle]</a>
      [/blockcode]

      The href attribute will be empty, only mytitle will be replaced.

      Is this also considered “wrong” use of shortcodes??? Wrapping shortcodes are used for conditions, loops, etc. by several plugins. And this could not be changed in the same easy way like just changing quotation :-(

      With version 4.2.3 the part inside a wrapping shortcode is first processed by do_shortcodes_in_html_tags(). There all the replacement of the inner shortcode is done. Only afterwards, the result is passed to the wrapping shortcode callback. This has several problems: For wrapping shortcodes implementing a condition substitions will take place that might be completely unnecessary (ok, only a performance problem). But for wrapping shortcodes implementing a loop, the content will always be the same – i.e. the whole thing is completely broken.

      Did anyone thought about this?

    • FolioVision 9:53 pm on August 1, 2015 Permalink | Log in to Reply

      Surely 95% of the security issues could have been clamped with a minimal fix to be followed in next major version with a comprehensive fix – with proper warnings to all involved in shortcodes to clean up their act. Breaking people’s websites is always a bad idea.

    • Mav3000 7:23 pm on August 4, 2015 Permalink | Log in to Reply

      Hi, I am using a simple shortcode to output the URL of my site for use in URLs in my theme. e.g:

      <img src="[rs-get-site-url]/wp-content/themes/theme_1.0/images/icon_tick_2.png" alt="" />

      This is the shortcode code, in functions.php:


      add_shortcode('rs-get-site-url', 'rs_get_site_url_func');

      function rs_get_site_url_func() {
      return get_site_url();
      }

      Since the WordPress 4.2.3 update this has stopped working, but because I am not using bad quotes or variables, I don’t know why. How can I get this working in WordPress 4.2.3?

    • Mav3000 9:41 pm on August 4, 2015 Permalink | Log in to Reply

      In relation to my above post, I’m trying to use the shortcode in URLs like this:

      href=”[rs-get-site-url]/contact” and href=”[rs-get-site-url]/about” etc – these are critical to my site – how can I work around this problem?

      • Eliot Akira 2:31 am on August 5, 2015 Permalink | Log in to Reply

        @Mav3000,

        I believe the most forward-compatible way to solve it is to make the shortcode generate the whole link. That way you don’t need to use shortcodes in HTML attributes. A quick example based on your code above:

        add_shortcode('rs-link','rs_link_func');
        function rs_link_func( $atts ) {
        
          extract( shortcode_atts( array(
            'label' => '',
            'page' => '',
          ), $atts ) );
        
          $page = get_site_url().'/'.$page;
          return '<a href="'.$page.'">'.$label.'</a>';
        }
        

        Then you can use it like: [rs-link page="contact" label="Contact Page"]

    • syamkg 4:57 am on August 20, 2015 Permalink | Log in to Reply

      I am using a simple shortcode for random string generator function and it seems to be broken after recent WP Update 4.3.x

      function genTicketString() {
          $length = 8;
          $characters = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
          $string = '';
          for ($p = 0; $p < $length; $p++) {
              $string .= $characters[mt_rand(0, strlen($characters)-1)];
          }
          return $string;
      }
      
      add_shortcode('quoteticket', 'genTicketString');

      And this is how I was using to generate a reference number in contact form

      [dynamichidden ref_num "quoteticket"]

      It seems to have broken and I am new to WP & website development. Can someone please help me how to fix this,

      Thanks in Advance

    • slt-admin 10:19 am on August 20, 2015 Permalink | Log in to Reply

      Will there be a fix that website admins who don’t have understanding of html can use, and if so when might this be?

  • Ryan Boren 12:01 am on July 15, 2015 Permalink |
    Tags: , bubbles, , content-overrun, , edit-site, , , , , , network-admin, right-now, ,   

    Today in the Nightly: Site icons in the customizer, editor patterns, more accessible comment bubbles, row toggle focus styling 

    Install the nightly, and try out this fresh batch of shiny.

    Site Icons in the Customizer

    I’ve long wanted site icons in the customizer alongside site title and tagline. The identity information that I always want to edit when first setting up a site are now all together in the customizer.

    For more visuals, see these visual records.

    See #16434.

    Editor Patterns

    Create bulleted lists, ordered lists, and blockquotes using markdown like patterns. I find this particularly handy on phones when the editor toolbar is offscreen.

    Screen Shot 2015-07-14 at 4.39.12 PM

    See #31441.

    Better focus styling for list table row toggles

    See #32395.

    Better accessibility and design for the comments bubble

    The comments columns in our list tables were among the most confusing for screen reader users. Accessibility and visuals are now improved.

    See #32152.

    Eliminate content overruns on small screens

    An audit of content overruns on small screens resulted in many fixes.

    After:

    Before:

    See #32846.

    Styling improvements on small screens for Right Now in the network admin

    See #32962.

    Improved header information in Network Admin Edit Site tabs

    • Use the site’s name rather than URL in the Edit Site header.
    • Provide “Visit” and “Dashboard” links for the site on all tabs.

    After:

    Before:

    See #32525.

    Disambiguate “Automatically add new top-level pages to this menu”

    In the customizer, a menu’s auto-add pages option is now separated from the preceding menu location checkboxes.

    See #32820.

     Passwords UI Improvements

    Passwords received a couple of improvements. The show/hide toggles look better, and passwords ui is on the install screen. Passwords on the install screen still needs a little more flow work.

    See #32589 and #32925.

    For more visuals, see these visual records.

    Reduce link noise in media library list view

    This is visually subtle but removes confusion for screen readers.

    KL_7dmW58c

    See #32254.

     

    Previously: Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons

     
  • Ryan Boren 11:25 pm on July 8, 2015 Permalink |
    Tags: beta-testing-flow, , , list-tables, , , , toolbar   

    Today in the Nightly: Customize in the Toolbar, Passwords UI, List Tables on Phones, Dashicons 

    Development leading up to the first beta brought several visual changes. These are available right now in the nightly build. Switch a site to nightly builds and try them out.

    Customize in the toolbar

    To disambiguate between links to the Customizer and links to the Appearance screens from the front-end, Customize now has a top-level toolbar button rather than having links to it mixed with dashboard links in the site menu. This context mixing leads to disrupted user expectations as they navigate, as well as experiences that feel slower or actually are slower in some cases. See #32924.

    This means an additional top-level menu item, but the existing links to Widgets and Themes in the dropdown will now point to the admin, as the Dashboard and Menus links do. The advantage and goal for this change is to make it clear that you are about to enter the customizer. Deep links have not been added back in this go-round; this means that direct links to Header and Background are currently absent (with a very narrow exception related to old browsers). Those two deep links are still available in the admin menu under Appearance, which similarly mixes context but has not yet been addressed.

    More changes are coming to the toolbar. Peek at a possibility for more general improvements to the toolbar, being discussed in #32678.

    Phone friendly list tables

    List tables now scale down to phones. The column truncation strategy they used before didn’t scale down to small screens. A single column layout with disclosures is the new strategy. Some of our most important screens use list tables, notably Media and Posts. Truncated columns was number 5 on our top  5 impediments to flow on touch devices list.

    After:

    Before:

    See #32395.

    For more screenshots, see these visual surveys of the list table screens.

    Toolbar interaction fixes for touch devices

    I’ve been wanting this one for a long time.  Toolbar interaction was number 3 on the top  5 impediments to flow on touch devices.

     

    Fixed!

    Fixed!

    See #29906. That ticket is a good read.  It has: Visual feedback and visual surveys. Punting a working fix to the next release so that a new, more future proof approach could be tried. Development of touch capability detection. Working around iOS. Development of testing checklists. Lots of iteration.

    Passwords UI

    The password set/change UI was updated with these improvements.

    • Generate the password for the user
    • More tightly integrate password strength meter
    • Warn on weak passwords

    See #32589 for more screenshots.

    Dashicons update

    Dashicons received a big update.

    New icons:

    • .dashicons-admin-customizer (f540)
    • .dashicons-admin-multisite (f541)
    • .dashicons-editor-table (f535)
    • .dashicons-filter (f536)
    • .dashicons-hidden (f530)
    • .dashicons-image-filter (f533)
    • .dashicons-image-rotate (f531)
    • .dashicons-layout (f538)
    • .dashicons-sticky (f537)
    • .dashicons-thumbs-down (f542)
    • .dashicons-thumbs-up (f529)
    • .dashicons-unlock (f528)
    • .dashicons-warning (f534)

    Updated icons:

    • .dashicons-plus (f132)
    • .dashicons-yes (f147)

    dashicons-preview

    See #30902.

    Better styling for .form-invalid inputs

    See #32490.

    Responsive styling for my-sites.php

    My Sites now moves to a single column layout on narrow viewports. Here it is on an iPhone 6, an iPad, and a Macbook, as well as at full-width.

    Here’s what it looked liked before.

    my-sites-before

    See #31685 – Better responsive styling for my-sites.php

    Crosslinking Customizer Panels

    The graf in the Menus panel details about using the Customize Menu widget now links directly to the widgets panel.

    customize menus details

    See #32742.

    You might notice the misaligned question mark icon on that screenshot. #32733 is tracking that.

     Easy switching between production and nightly builds

    The beta tester plugin makes it easy to switch a site to nightly builds. Now switching back to the latest stable build is just as easy. It’s not the prettiest, but it is shown only to beta testers and will suffice until we finally refresh the Grand Unified Updater screen. For info on using the beta tester plugin to test with nightly builds, see the Beta Testing page of the core handbook.

    See #32613.

     

    Previously: Today in the Nightly: Site Icons, Text Editor in Press This

     
    • Thong Tran 12:06 am on July 9, 2015 Permalink | Log in to Reply

      Awesome updates. Btw, the ability to move a widget from one widget area to another has gone (in Customizer) in WP 4.3 beta 1, please bring it back.

      • Nick Halsey 3:50 am on July 9, 2015 Permalink | Log in to Reply

        To support a broader UX change made in #31336, it is no longer possible to drag & drop items between widget areas. However, the move-to-area functionality is still present along the reorder buttons when you enter the “reorder” mode, similar to the click-to-add functionality in the admin page.

    • Jon Brown 12:51 am on July 9, 2015 Permalink | Log in to Reply

      “Customize in the toolbar” getting it’s own top level menu is going to make me SOOOoooo happy you have no idea. Every time since 4.2.2 I hit that widgets link and get thrown into the customizer I scream curses at it my installs. Also just inspired me to write a plugin… to scratch another itch I’ve long had around that menu.

    • nikeo 8:48 am on July 9, 2015 Permalink | Log in to Reply

      Hi, thanks for this post.

      Funny : the customize button is something I’ve had to remove from my theme last year because there was “no real justification for elevating the Theme settings page to admin toolbar status.”
      See here : https://themes.trac.wordpress.org/ticket/18164#comment:5

      Well, I guess this is now 100% justified and of course I think this button is an excellent choice ! :)

    • Remkus de Vries 10:21 am on July 9, 2015 Permalink | Log in to Reply

      Love the move of giving the Customizer its own top level link. Love it.

  • Ryan Boren 10:56 pm on June 30, 2015 Permalink |
    Tags: , , , image-editor, , , site-icons, today-in-the-nightly   

    Today in the Nightly: Site Icons, Text editor in Press This 

    Here are a few cool things that recently landed in trunk. They are available right now in the nightly build. Install the nightly, and try them out.

    Site Icons

    We’ve wanted site icons in core for a long time. #16434 was opened four years ago and will be resolved as fixed for 4.3.

     

    Our crop controls are not easy to use on my iPhone 6+. The images overflow the right side of the screen. Horizontally and vertically scrolling an image bigger than the screen while working a rubber band select that resets when the image is tapped is not pleasant.

    Provide feedback on #16434 or on this post.

    See these visual records for more screenshots and flow storyboards.

    Text editor in Press This

    Press This now has a Text editor for editing HTML, just like the standard editor in post-new.php.

    32706.1-wide

    Provide feedback on #32706, in #core-pressthis, or on this post.

     Padding for image settings

    The Image Crop and Thumbnail Settings boxes received a little bottom padding.

    And so that we are always aware of what our mobile experience looks like, here are those settings boxes on an iPhone 6+.

    When you see a sidebar obscuring content on a phone, you can be pretty sure you’re witnessing lingering desktop bias. These screens were designed for desktops where you have room to use  sidebars. You can’t make a screen responsive and call it ready for a phone. The image flow effort is working on this.

    Provide feedback on #31845 or on this post.

    Manage in the Customizer

    Appearance > Menus received a “Manage in the Customizer” button to match Appearance > Widgets.

    Screen Shot 2015-06-30 at 3.16.57 PM

    Next, fix up mobile.

    image

    Provide feedback on #32808 or on this post.

     

    Previously: Today in the Nightly: Inline link toolbar and Press This split button

     
    • Emil Uzelac 11:05 pm on June 30, 2015 Permalink | Log in to Reply

      Just awesome!

    • Ryan Boren 11:45 pm on June 30, 2015 Permalink | Log in to Reply

      To create these posts, I work my way through the latest commits looking for changes to visuals. From the changesets, I visit the tickets. If the tickets don’t have before and after screenshots for both a desktop and a phone, I test the changes on a desktop and a phone and take screenshots. I upload those screenshots to the ticket. I comment on the ticket with any bugs I find in the process. I often find something, especially on phones. If I don’t have time to test and screenshot, I tag the ticket with needs-screenshots so I can get back to it later.

      Now that I have tickets with screenshots. I collect those screenshots and publish them as “Today in the Nightly” using the tool we’re all making together, WordPress. I often find bugs that way, too. Triage, recursive dogfooding, visual archiving, visual awareness, and a useful post to show for it. Recruiting drive: This is a great way to contribute. Help us with flow patrol, as we call it. :-)

    • Andre 4:27 am on July 2, 2015 Permalink | Log in to Reply

      I am just now playing with the beta 4.3, but regarding the site icon…I’m sure many will be extremely happy about that feature being part of the core. The only thing that should be given consideration is the labeling of it. I think it might confuse many end-users who may wonder what is a site icon when most are familiar with the term “favicon”, which as I understand, is the correct name for it. Just something to think about.

  • Ryan Boren 3:50 pm on June 9, 2015 Permalink |
    Tags:   

    Trust, Live Preview, and Menus in the Customizer 

    One of the most important things in WordPress is users being able to feel confident as they make changes to their content and more generally to their sites. Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

    The customizer is the result of a tremendous amount of work over many releases. It was first introduced in 3.4. In 3.9, it received its first big updates in the form of widgets support and improved header upload and cropping. 4.0 brought panels and contextual controls. Development really started to take off in 4.1 when JS-templated customizer controls and a JS api were introduced, making possible an ecosystem of live preview compatible plugins and themes. 4.2 followed that up with two important features, theme switching