WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Mark Jaquith Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 11:10 pm on February 18, 2013 Permalink
    Tags: , ,   

    Screen Shot 2013-02-18 at 5.15.50 PM

    A first draft of the Twenty Thirteen theme is now in core, for your inspection and iteration. See: r23452

    A demo site is available for you to browse.

    @matt set the goals for this theme: a focus on blogging, and great support for post formats (which are getting attention on the backend in 3.6 as well). Under Matt’s guidance, @joen explored the artistic possibilities and was joined by @obenland and @lancewillett in bringing it to fruition.

    What you’ll notice first is the colors. Way more use of color than a bundled WordPress theme has had before. Each post format has its own color, so each is distinct, yet they are all complimentary. The bold colors encourage authors to try out all the different formats. This color extends the full width of the window, which breaks your blog up into a lush, segmented timeline. This effect is even more pronounced on mobile browsers, where the screen can be dominated by one or two posts at a time, in all of their chromatic fullness.

    On closer inspection, you’ll notice details, like the font-based icons (“Genericons”, by @joen) that scale up to any resolution or zoom level and can be easily recolored using CSS.

    You may notice some playful details, like the size-offset pagination arrows:

    Screen Shot 2013-02-18 at 4.52.23 PM

    Or the 404 page (which I’ll leave to you to find).

    One of the goals of having a new theme every year was to give ourself room to experiment. That hasn’t really happened. We’ve been far too conservative, trying to make themes that work reasonably well for everyone, but don’t push boundaries too much. That changes with Twenty Thirteen. It’s hard not to have a strong feeling about the theme, one way or another. It defies you to give it a shrug or a kurt nod. Some of you will hate it. And that’s okay. We’ll still be shipping Twenty Twelve, which is an excellent base theme and a canvas on which you can build anything from a blog to a static content site. But with Twenty Thirteen we’re taking a bold stance: this theme was meant for blogging, and it’s not a blank canvas. It comes pre-marinated with playfulness and warmth and opinions.

    Twenty Thirteen really prefers a single column layout. Widgets live best in the footer, where jQuery Masonry bricks them together (but it supports a sidebar, if you really insist). Header images have a fixed width and height, and will be cropped at smaller resolutions, so the best choice is an artistic header where not 100% needs to be shown all the time (it ships with three).

    Now that we have a first draft of Twenty Thirteen in core, it’s time to start iterating and sanding off some of the rough edges. Accessibility is still important, even when making bold artistic statements, and I’d be surprised if we didn’t have work to do there. We’ll need testing on lots of different browsers and platforms, and with lots of different plugins. @helen‘s Post Format UI team will need to give feedback on upgrading Twenty Thirteen to use the new post format API functions that are available.

    @lancewillett and @obenland will be holding Twenty Thirteen office hours on Tuesdays and Thursdays at 1700 UTC. Interested parties should make an effort to attend and help us get this beauty ready for beta!

     
    • Amy Hendrix (sabreuse) 11:18 pm on February 18, 2013 Permalink | Log in to Reply

      First impression: WOW

    • Michael Beckwith 11:18 pm on February 18, 2013 Permalink | Log in to Reply

      Holy color!

    • Alison Foxall 11:24 pm on February 18, 2013 Permalink | Log in to Reply

      Nice Mark!

      First thing I notice is that although the search bar sticks to the top with the Twenty Thirteen branding while you scroll, the main navigation is not up there with it on both large desktop screens and small device screens. Was there a reason for this or can this be changed by the user? And of course I\’m wondering if the user will be able to change those colors for each post format. :)

      • Mark Jaquith 2:26 am on February 19, 2013 Permalink | Log in to Reply

        It’s a known issue, and something I’d like rectified. The dropdown menu that you get on small screens would be great up there. And colors could be overridden by a child theme — probably a lot of option overload if we exposed that.

    • Mel Choyce 11:30 pm on February 18, 2013 Permalink | Log in to Reply

      WOW, instant love! The colors are bold but harmonious, the type is GREAT, and it’s got such a fabulous funky retro futurist feel. Thumbs up!

    • Emil Uzelac 11:34 pm on February 18, 2013 Permalink | Log in to Reply

      Pretty good for the first draft!

    • Xavier Borderie 11:46 pm on February 18, 2013 Permalink | Log in to Reply

      Wow indeed! I too was getting a feeling that the “clear white” theme spirit could feel overplayed if 2013 had it. I for one am very glad that the team is making such a bold move in a creative direction. I trust there will be enough theme option and color schemes so that users can make it their own in a few clicks.

      Great work!

    • aradams 12:10 am on February 19, 2013 Permalink | Log in to Reply

      Love the colors, love the flow. Nice to see creativity unleashed on the default theme!

    • Ipstenu (Mika Epstein) 12:13 am on February 19, 2013 Permalink | Log in to Reply

      Nice! Just … Amazingly nice. I’m gonna have to find a site to use that on. Maybe my own!

    • Marcel van der Horst 12:14 am on February 19, 2013 Permalink | Log in to Reply

      Can’t wait to try it out..

    • BrentLeavitt 12:22 am on February 19, 2013 Permalink | Log in to Reply

      I find that to be just delightful!

    • Aaron D. Campbell 12:23 am on February 19, 2013 Permalink | Log in to Reply

      So excited to have this in. It really is great!

    • Tony Scott 12:27 am on February 19, 2013 Permalink | Log in to Reply

      http://genericons.com/ seems to be behind a WP.com password.

    • Chuck Reynolds 12:32 am on February 19, 2013 Permalink | Log in to Reply

      Looking forward to the post format specific layouts and metadata.
      Would be nice if the video, once ‘fetched’, would autopopulate the title.

    • @mercime 12:50 am on February 19, 2013 Permalink | Log in to Reply

      Very Nice! Shades of BuddyPress :-)

    • trishasalas 1:01 am on February 19, 2013 Permalink | Log in to Reply

      …beautiful, you’ve managed to stick with the mimimal yet spice it up with jazzy colors. Instant LOVE <3

    • Austin Passy 1:03 am on February 19, 2013 Permalink | Log in to Reply

      The theme demo looks great. Like the direction it heading in.

    • Jose Castaneda 1:09 am on February 19, 2013 Permalink | Log in to Reply

      Looking forward to testing the formats. Now to get home and uptade core.

    • Eduardo Zulian 1:36 am on February 19, 2013 Permalink | Log in to Reply

      Just finished testing Twenty Thirteen with the new post formats scheme. Sweet. : )

    • Lori Berkowitz 1:37 am on February 19, 2013 Permalink | Log in to Reply

      Looks great! Also nice to see some post formats love :)

    • Edward Caissie 1:39 am on February 19, 2013 Permalink | Log in to Reply

      Except for the header trick … sorry, it’s just not doing anything for me.

    • Anthony Hortin 2:00 am on February 19, 2013 Permalink | Log in to Reply

      It’s lookin’ great so far! Well done to all involved!

    • Matt Mullenweg 2:12 am on February 19, 2013 Permalink | Log in to Reply

      It’s counterintuitive because this is a visually much more aesthetically opinionated base than we’ve had probably since Kubrick, but I think we’ll see a lot more customization and variations on Twenty Thirteen than Eleven or Twelve. It’s a delightful canvas to play on.

    • Justin Sternberg 4:25 am on February 19, 2013 Permalink | Log in to Reply

      Nice work all around! I couldn’t help myself: http://jtsternberg.com/

    • Sovit - (Theme Horse) 5:37 am on February 19, 2013 Permalink | Log in to Reply

      This one will be the great example to show that without choosing white color can also make clean and beautiful theme. Love the way designer play the colors.
      Thanks to all contributors. Its really Fantastic ! Can’t wait to see it out in my themes directory.

    • Noel Tock 8:04 am on February 19, 2013 Permalink | Log in to Reply

      Love the new direction, looking versatile and fluid, +1

    • Ryan Hellyer 9:37 am on February 19, 2013 Permalink | Log in to Reply

      And here I was thinking that WordPress default themes need to be bland and white.

    • Petya Raykovska 9:50 am on February 19, 2013 Permalink | Log in to Reply

      Wow. Bold move, I love it.

      I’d make the main navigation sticky though, together with the search bar and the site name.

      And it would be great to have some color palettes to choose from as visually color is the first thing you experience with this theme.

    • emzo 10:06 am on February 19, 2013 Permalink | Log in to Reply

      Default WordPress themes have always been great, but they’ve needed to be versatile and cater to the majority, and in doing so have had to be more conservative. This puts the fun back into WordPress, and definitely brings a smile to my face. I do agree that the collapsed mobile menu should be placed in the fixed header when scrolling though.

    • Luc De Brouwer 10:55 am on February 19, 2013 Permalink | Log in to Reply

      This. Looks. Awesome.

    • lonchbox 12:14 pm on February 19, 2013 Permalink | Log in to Reply

      Excellent work! I love the post formats styles :)

    • sourceforge 12:59 pm on February 19, 2013 Permalink | Log in to Reply

      there was a theme in tumblr directory by peter vidani, which used the colors for post types!

    • Monika 2:01 pm on February 19, 2013 Permalink | Log in to Reply

      it looks like Windows8 :-) colorful and dizzying.

    • mindctrl 2:12 pm on February 19, 2013 Permalink | Log in to Reply

      Nice and different direction. With this new bold approach, I’d like to see the base font size increased a bit more. Chrome is telling me it’s 16px, and with Source Sans Pro 16px looks more like 14px. It looks good and is easier to read at 18 or even 20px.

    • Aaron Aiken 2:50 pm on February 19, 2013 Permalink | Log in to Reply

      Absolutely beautiful. Good work!

    • Arnan de Gans 3:15 pm on February 19, 2013 Permalink | Log in to Reply

      Sponsored by Ubuntu I see…

    • Nashwan Doaqan 8:08 pm on February 19, 2013 Permalink | Log in to Reply

      It’s really a beautiful theme , but I don’t think It’s good to be a default theme ,It’s too colourful … Yes it’s different direction but many of WP users like the default themes because they are simple and have a less colours , I was thinking if you can make the colours system is optional in the theme control panel ….

      As I am seeing now , Its seems to be hard to use it as a framework , the default theme should be simple , clean , easy to customize and express WordPress main features !

      • Aaron D. Campbell 8:24 pm on February 20, 2013 Permalink | Log in to Reply

        Twenty Twelve will still be packaged with WordPress too. I do however think this theme will actually be pretty easy to extend.

      • Emil Uzelac 12:40 am on February 21, 2013 Permalink | Log in to Reply

        This is actually going to be a perfect default Theme and honestly, very easy to customize as well.

        Colors are post formats and they can be changed or removed ;)

    • Daniel 10:15 pm on February 19, 2013 Permalink | Log in to Reply

      Is there a reason why the fixed navbar replaces the navigation menu with the site title? Doesn’t that pretty much defeat the purpose of the fixed navbar to provide better accessibility to the site’s navigation? Why would I need a static bar with just a link to the front page?

    • David Radovanovic 12:37 am on February 20, 2013 Permalink | Log in to Reply

      ooooooooo, ahhhhhh – very awesome indeed! The long scrolling homepage, ever-adaptive elements, and I’m sure much more will be realized with a test drive. Thanks!! BTW – why the persistent header with banner on all pages? Am I alone in wondering why is the banner needed on pages other the homepage?

    • Jean-Francois Arseneault 5:35 am on February 20, 2013 Permalink | Log in to Reply

      Surprised to still see ‘Links’ in there as a post type…

    • shazdeh 9:03 pm on February 20, 2013 Permalink | Log in to Reply

      Love at first sight. :)

    • Zulfikar Nore 10:47 pm on February 20, 2013 Permalink | Log in to Reply

      Bold And Beautiful! A total change in direction from previous “Default” themes – this will make an awesome parent theme for developers to tinker with.

      Would like to chime in on the menu though….the sticky menu “bar” minus the menu is not doing it for me – I would like to see the menus as I scroll the page instead of a blank “bar”.

      Further more, since its bold in terms of color scheme – I would like to see the options to adjust the various sections incorporated in the Customizer’s Color section and not having to rely on changing them via child themes. As it is the child theme option would work for developer but not for the novice end user.

      But all in all, I’m totally loving what I see so far – now its time to go break it apart and see what I can conjure up :)

    • bjornsennbrink 9:48 am on February 21, 2013 Permalink | Log in to Reply

      What is up with the breaking of words in titles and in text? It was there in Twenty Twelve and is still around. Any insight on the word-breaking thingy would be great :)

    • alvarogois 2:58 pm on February 21, 2013 Permalink | Log in to Reply

      Strange unanimity… I’m a guy who likes color and bold, though I’m more for minimal. I don’t understand this theme and can’t picture it as a default WordPress theme. Maybe the focus here is on blogs, I get it, and giving the author a panoplia of customization options. I get it too. Nevertheless, I fail to realise how one goes from twentytwelve to this twentythirteen. Sure, it’s a cut, but I don’t see it as a step forward, something new, more like something else.

      (I could be wrong, though… me and Nashwan Doaqan up there…)

    • Marco Raaphorst 3:55 pm on February 21, 2013 Permalink | Log in to Reply

      cool, love it!

    • rilwis 5:32 pm on February 21, 2013 Permalink | Log in to Reply

      Amazing theme. I like it and have a good feeling when I see it at first. It’s great when you can push the boundaries so far. It’s time to show people that WordPress is easy to customize.

    • Brad Dalton 9:16 pm on February 21, 2013 Permalink | Log in to Reply

      Its like it or not based on my readers feedback. Personally i love it but also know you guys could seriously blow the socks off any premium theme out there. Built in hooks and conditional tags is where its headed i think. WordPress theme users are smarter now and want more. They understand the basics of coding. Extend further.

    • tomjanski 9:44 pm on February 21, 2013 Permalink | Log in to Reply

      The bold colors and bold theme. Bravo. It’s going to be a good one.

    • Shea Bunge 4:39 am on February 22, 2013 Permalink | Log in to Reply

      Wow… really, really good. It”d be nice to get the default theme out early this year. (I;ve always thought that the annual themes should be released at the start of the year, not the end ;)

    • lisafirke 3:34 pm on February 22, 2013 Permalink | Log in to Reply

      Gorgeous and playful. Bravo!

    • Tatiane Pires 3:06 pm on February 24, 2013 Permalink | Log in to Reply

      Great!
      I can’t wait to make a new theme for my blog based on Twentythirteen.

    • suzybyrnes 12:54 pm on February 27, 2013 Permalink | Log in to Reply

      love the full width. Agree with comments about fixed nav bar. Look forward to seeing what people do with it. Thanks v much.

    • bru.scopelliti 4:50 pm on February 27, 2013 Permalink | Log in to Reply

      What I have seen is very promising. Can’t wait the release

    • ecksteing 10:01 pm on February 28, 2013 Permalink | Log in to Reply

      Twenty Thirteen is absolutely beautiful. Love the use of differing colours per Post Format.

    • Hassan 8:04 pm on March 2, 2013 Permalink | Log in to Reply

      My first impression was color-shock!

      It reminds me of the new refresh of Windows.com after the release of Windows 8. Oh, and those arrows for Newer and Older Posts, It’s hard not to see the “Metro effect” there ;)

      Also, I love the theme!

    • Misha 5:37 pm on March 3, 2013 Permalink | Log in to Reply

      Oh, this theme is really nice on the whole! It’s interesting how it will look with a sidebar… I really need it.

  • Mark Jaquith 10:43 pm on January 16, 2013 Permalink
    Tags:   

    Feature Team Updates and Office Hours 

    The WordPress 3.6 feature teams should be updating here on make/core twice a week, on the following schedule. List any major developments, summarize any notable IRC conversations that happened, call for help where coding, testing, discussion is needed, etc. They don’t need to be long, unless a lot of stuff happened. The idea is that people who aren’t in IRC and Trac every day can still stay up to date on features and jump in when they can. And it will keep the teams aware of their progress (or lack thereof) on a more regular basis.

    Monday and Thursday

    • Autosave/Post Locking
    • Nav Menus
    • Post Format UI

    Tuesday and Friday

    • Editorial Flow
    • Core Maintenance and Architecture
    • Revisions

    Next, while many features are still being actively planned, the feature teams should hold IRC office hours where more realtime discussion can take place to get the features scoped and planned a little better. Feature teams should announce these hours here on make/core (can be part of their twice-weekly updates).

     
  • Mark Jaquith 8:49 pm on January 16, 2013 Permalink
    Tags:   

    Agenda for the weekly dev chat:

    1. Feature team updates
    2. Set up schedule for more frequent feature team updates
    3. Unstick anyone who is stuck
    4. Rallying call for Ryan’s code maint ticket list

     
    • Schwarttzy 8:55 pm on January 16, 2013 Permalink | Log in to Reply

      Hi, I’m new to this whole WordPress Core thing and would like to add to the core with an idea I have to help responsive web designers with featured images. Basically, add an option for setting an aspect ratio, instead of defining some fixed width and height. How do I get started?

      • Amy Hendrix (sabreuse) 11:51 pm on January 16, 2013 Permalink | Log in to Reply

        Hi Schwarttzy, and welcome! If you’re interested in contributing, you should start with the Core Contributor Handbook, which has a lot of information about the process and the tools we use:

        https://make.wordpress.org/core/handbook/

        It’s also incredibly useful to drop in on a few of the weekly dev chats in IRC — even though a lot of what happens there is updates on what different teams are doing, it’ll give you a good idea of what’s going on as well as the whole workflow. You’re also welcome to ask in #wordpress-dev if you need more help getting started; there’s usually someone around outside of meeting times.

        As for responsive images, there’s an existing ticket to make heights and widths filterable, although it hasn’t seen any action in a few months: you might want to start with getting familiar with the discussion and patches that have already happened in that effort. Check out #14110

  • Mark Jaquith 3:08 pm on January 15, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Code Maintenance and Architecture 

    Like with any release, much more is going on during the 3.6 cycle than just the user-facing items on our agenda. We’d like to hit the following code maintenance and architecture items as well. If your interested or have thoughts, speak up or jump on the tickets! Some of these really should happen early, and they’re pretty much all going to need unit tests.

    Use PDO for MySQL queries

    #21663 — The mysql_* functions in PHP are deprecated, so to get ready for future versions of PHP, we need to start routing queries alternatively for installs that support it.

    Caching and Misc DB Tasks

    No ticket for this? — Use magic methods to cleanup blogid and siteid in wpdb. These should fetch the canonical versions elsewhere. Also, support blog_id and site_id for consistency.

    #23167 and #23173 — Make our object caching more intelligent. One query per cache key. Stored IDs instead of objects where possible.

    #22174 and #20875 — Introduce and use wp_cache_get_multi(). Maybe. A bonus, if there’s time.

    #21760 — get_term_by() calls are not cached.

    #21401 — Load packaged object cache when advanced-cache.php and object-cache.php don’t implement wp_cache_init().

    #22661 — Allow object caches to degrade gracefully.

    Slashing Sanity

    #21767 — Remove stripslashes from API functions.

    #18322 — The Road to Magic Quotes Sanity.

    #22325 — Abstract GPCS away from the superglobals (maybe not, depending on #21767).

    #22023 — Remove UNIQUE for slug in wp_terms. Prep for future taxonomy architecture changes.

    Misc Performance

    #22301 — Performance problem with Recent Comments widget.

    Earlier Discussion

    IRC Logs from discussion of some of these items.

     
    • Ryan McCue 11:53 am on January 16, 2013 Permalink | Log in to Reply

      I’m happy to lead efforts on #22325 (GPCS abstraction), and work on #21767 (removing stripslashes) and #21663 (PDO). I think a high-level discussion on what we want out of the GPCS abstraction would be nice; @nacin said he was going to make a P2 post about it, but I don’t think he ever got to it with his busy schedule. :)

  • Mark Jaquith 4:20 am on January 10, 2013 Permalink
    Tags: ,   

    Git Mirror History Breakage 

    A few years ago, I started publishing a mirror of WordPress on GitHub. It was subsequently promoted to WordPress/WordPress. What I neglected to do, however, was provide an appropriate authors.txt file, until recently. That means that earlier commits are attributed to dummy e-mail addresses and as such cannot be associated with user accounts on GitHub. Considering the recent introduction of contributions on GitHub, this seems a shame. Also, if we were to move to Git in the future, we would probably want our official mirror to have the best possible data.

    Proposed

    That we re-run the git-svn import with a proper authors.txt file.

    Upsides

    We’ll have a proper Git mirror with good and consistent author data, that we can, if desired, use for a future migration to Git. Commits will be properly attributed in GitHub.

    Downsides

    This will break Git history. If you have a Git checkout of WordPress, either standalone or in a submodule, that’ll mean that you’ll have to rebase your master branch off of origin (or even better, blow the whole thing away and re-clone).

    So: thoughts? Would this ruin your day?

     
    • Gustavo Bordoni 4:25 am on January 10, 2013 Permalink | Log in to Reply

      If this means that WordPress is taking any sort of steps towards using Git as a solution for code versioning I’m all for it!

    • Scott Taylor 4:25 am on January 10, 2013 Permalink | Log in to Reply

      DO IT! And document the ideal way to mirror with authors.txt after, please. I mirrored a bunch of repos and forget to do the authors part and I haven’t collected the energy to start over yet.

      • Bryan Petty 5:18 am on January 10, 2013 Permalink | Log in to Reply

        Authors file is simple: one author per line: “loginname = Joe User “.

        Run this to generate your initial authors file (from the root of your SVN checkout):
        $ svn log -q | awk -F ‘|’ ‘/^r/ {sub(“^ “, “”, $2); sub(” $”, “”, $2); print $2″ = “$2″ “}’ | sort -u > authors.txt

        Fill in the file with real names and email addresses.

        I use a modified version of Mark’s script to mirror a ton of repos myself:
        https://gist.github.com/3061041

        It’s mostly self-explanatory, see forked gist for Mark’s version.

        • Mark Jaquith 6:02 am on January 10, 2013 Permalink | Log in to Reply

          Another thing I’d do is contact everyone in that file and get them to doublecheck that we have an e-mail address that they’re likely to control for life. Probably best to use e-mail at a personal domain, if they have one, instead of Gmail or a company e-mail address that they might lose in the future.

    • Daryl Koopersmith 4:25 am on January 10, 2013 Permalink | Log in to Reply

      I think an accurate repository is worth the temporary breakage.

    • Ryan McCue 4:27 am on January 10, 2013 Permalink | Log in to Reply

      +1, I’d say we do it.

      What’d be really cool is if we can get the props parsed so that git lists the commit author as whoever was prop’d, and the committer as the person who actually committed it. AFAIK, that’s not possible without a complicated script though.

      • Bryan Petty 4:56 am on January 10, 2013 Permalink | Log in to Reply

        That would be cool, but I really can’t even think of any way to do something like this with the current repo as is without amending commits after the initial clone, which would be extremely resource intensive and could take weeks to do. Given that and the work involved with integrating the same process into the mirror updates for future commits as well, I would just say forget it.

      • Mark Jaquith 5:58 am on January 10, 2013 Permalink | Log in to Reply

        Interesting idea. But wouldn’t be able to handle issues with multiple props recipients. But we could give it to the first person or just in this case give it to the committer.

        • Ryan McCue 7:39 am on January 10, 2013 Permalink | Log in to Reply

          Multiple props authors mean that it’s ambiguous who actually created the patch, so the committer should be assigned credit lest we accidentally attribute it to the wrong person.

          (Also, we’d probably want to make sure that we fix up typos. `rmmcue` for example. ;)

      • Peter Westwood 9:39 am on January 10, 2013 Permalink | Log in to Reply

        While parsing props like this would be cool I don’t think it would accurately reflect the way our process has worked and I would much rather put effort into collecting the props to commit data into a format we can integrate into the WP.org profiles more easily.

        I started on this a while back but haven’t finished yet, what I’m mostly missing is an 100% accurate props extraction method.

        • Ryan McCue 9:55 am on January 10, 2013 Permalink | Log in to Reply

          At the moment, there’s basically two forms of commits with props: 1) the committer is merely committing a patch that was on a ticket (this is where we’d want to split author/committer); and 2) the committer is writing the patch with inspiration from someone (we’d want author = committer in this case).

          As far as I’ve seen, 1 seems to be the much more common case, but 2 is fairly common too. It could be a problem. (Regarding effort, it’s relatively simple using git filter-branch, so that shouldn’t be much of an issue.)

    • Michael Beckwith 4:27 am on January 10, 2013 Permalink | Log in to Reply

      I do all my pulling of WP from the svn repo anyway, but I keep an eye on some development via github. No harm for my stuff

    • topdown 4:31 am on January 10, 2013 Permalink | Log in to Reply

      I think that authors/contributors should be recognized when ever possible…
      +1 I say fix it.

    • Mike Schinkel 4:48 am on January 10, 2013 Permalink | Log in to Reply

      Got for it!

    • Bryan Petty 4:59 am on January 10, 2013 Permalink | Log in to Reply

      I think you’re already aware that I actually use my own clone of the WP repo partly for this reason, but also because it’s nice having branch and tag names that are exactly the same as the branch and tag names in SVN. It would be nice if those were fixed up as well if you do this.

      • Mark Jaquith 5:56 am on January 10, 2013 Permalink | Log in to Reply

        Yeah, if we’re doing this, we should take the time to iron out all other niggling issues. Would love to have your input on that. My issue with branch names is that it create ambiguous references. So if you go to checkout “3.5” it will check out the 3.5 branch. In order to check out the 3.5 tag, you need to do git checkout tags/3.5. Not the end of the world. Might be worth it to get everything cleaned up.

        Hey, maybe we can just rebase me and retroactively teach me all this Git and Git-SVN subtleties! :-) Just don’t push me, man.

        • Ryan McCue 7:41 am on January 10, 2013 Permalink | Log in to Reply

          The way I do it for SimplePie is to name the branches spelled out (ala WP.org release notice slugs), such as one-dot-two. That avoids the ambiguity there. However, that’s probably a pain for WP.

          Another option I’ve seen which are popular: rename all tags (or all branches) to vX.X so that any one starting with v is the tag (or branch) and without is the opposite.

          • Boone Gorges 11:55 am on January 10, 2013 Permalink | Log in to Reply

            For my own stuff I do something like this. `3.5` is the tag, and `3.5.x` is the branch. I think Drupal does it this way.

            • Aaron D. Campbell 2:57 pm on January 10, 2013 Permalink

              Or enforce 3 digits for all tags and 2 for all branches, so 3.5 is a branch and 3.5.0 is the first 3.5.x tag

          • Bryan Petty 3:48 pm on January 10, 2013 Permalink | Log in to Reply

            Mark does already do this, which is why the branches are named #.#-branch.

            Anyway, git does assume you wanted the branch instead of the tag, but that’s almost always the case for me anyway. I almost never checkout the tags, and I don’t think anyone else does either (definitely not with SVN either). In the 5 months or so that I’ve had my mirror running, this has never gotten in my way once or annoyed me in any way.

        • Bryan Petty 3:58 pm on January 10, 2013 Permalink | Log in to Reply

          One other issue that’s really minor is that there’s still an iis branch in SVN that didn’t make it into your mirror that probably should.

    • sourceforge 5:12 am on January 10, 2013 Permalink | Log in to Reply

      it would be good, i have been asking /systems guys to install git as revision control, but it seemed only someone in some driver’s seat could ask for stuff there! git is fast, no problem if it breaks for a while! thanks for this! full ahead flank :)

    • Ozh 6:54 am on January 10, 2013 Permalink | Log in to Reply

      I think it’s possible to modify afterwards the author of each commit, so you don’t break the whole history
      https://gist.github.com/4032945

      • Ryan McCue 7:42 am on January 10, 2013 Permalink | Log in to Reply

        That will change the commit hashes, since the author/committer is stored as part of the commit object (which is used to create the hashes). There’s no way (by design) to change these after the fact without doing this.

      • Ryan McCue 7:44 am on January 10, 2013 Permalink | Log in to Reply

        (Also, forgot to note: even if this only changed one commit, this would cascade down through all subsequent commits, since the parent’s hash is also included in the commit object)

    • aristath 6:57 am on January 10, 2013 Permalink | Log in to Reply

      I think it would be a great step forward. Drupal also used to be in SVN and switched to Git a couple of years ago. It was entitled “the great git migration” and took almost a year to design, layout and implement the whole process but it was worth it. Using Git has many advantages! I believe that breaking the history is worth it in the long run.
      Sure it might be a bit inconvenient at first, but I believe that it could really give a new boost to WordPress development.

      • aristath 6:59 am on January 10, 2013 Permalink | Log in to Reply

        correction… Drupal used to be CVS, not SVN. But the principal is the same… :)

      • Ryan McCue 9:24 am on January 10, 2013 Permalink | Log in to Reply

        To clarify: this isn’t about moving WordPress to Git, this is about fixing up the Git mirror of the SVN repo. This is a step we’d need to take if it was decided to move WP to Git, but it’s not the main goal.

    • Remkus de Vries 7:28 am on January 10, 2013 Permalink | Log in to Reply

      Git ‘er done I say. Having to do a rebase / clone is no biggy at this stage.

    • Baki Goxhaj 8:59 am on January 10, 2013 Permalink | Log in to Reply

      Re-cloning WordPress is not a big deal and adding appropriate author information is the way to go toward the future, thus I think it should be done — the sooner the better.

    • Tareq Hasan 9:33 am on January 10, 2013 Permalink | Log in to Reply

      Surely go for it. A step towards SVN to Git.

    • Abhishek Ghosh 10:58 am on January 10, 2013 Permalink | Log in to Reply

      Git is always a better option but needs carefulness on individual basis. Many options for an user is to download. The developer is getting the option to create a better documentation or guide. Cloning is not really difficult.
      There are basic problems too, a good guide is needed for increasing awareness.
      As practically we are not shifting, there is time.

    • Mark Rowatt Anderson 12:06 pm on January 10, 2013 Permalink | Log in to Reply

      Two thumbs up – go for it!

    • Edward Caissie 1:26 pm on January 10, 2013 Permalink | Log in to Reply

      It reads like a lot of great points above … and I am all for them, too. Any rebase / clone issues would be far outweighed by the eventual benefits this will bring.

    • Amy Hendrix (sabreuse) 1:31 pm on January 10, 2013 Permalink | Log in to Reply

      +1 It’s really not a big deal to rebase now compared to not having a good history sometime later.

    • Tom Willmot 2:16 pm on January 10, 2013 Permalink | Log in to Reply

      +1 Do it. We run everything with WordPress as submodule, would not be hard to re-clone.

    • aaronholbrook 2:30 pm on January 10, 2013 Permalink | Log in to Reply

      +1, anything that would move us closer to using Git would be fantastic. Also not a big deal to re-clone if needed.

    • Chris Jean 3:00 pm on January 10, 2013 Permalink | Log in to Reply

      Sounds like a bandaid that needs to be ripped off. Better now than later when even more people use it.

    • mojowill 3:04 pm on January 10, 2013 Permalink | Log in to Reply

      I’d love to see a full move to GIT for everything on wporg!

    • Sam Parsons 10:45 pm on January 10, 2013 Permalink | Log in to Reply

      I’m all for the update in order to improve the history and prepare for a possible move to git. I’m wondering whether you plan to send a little message (could it be automated?) to all those who have forked the repo on github?

      https://github.com/WordPress/WordPress/network/members

      That would be hugely helpful in communicating the upcoming changes in case those people don’t read this blog (perish the thought).

      • Mark Jaquith 6:47 am on January 11, 2013 Permalink | Log in to Reply

        GitHub removed their private messaging feature, so I’d have no automated way of notifying everyone. This doesn’t concern me so much as we don’t accept pull requests on GitHub, so it’s not like their forks are functional in that way. I also think a lot of people fork repos and never update it from the upstream again. So they probably wouldn’t notice. And it’s easy enough to destroy it and refork it.

        What I was considering doing was putting a note on our project description on GitHub, for the next few months, providing a link to a post that explained what happened and how to resolve the divergent Git history.

    • Mark Jaquith 6:51 am on January 11, 2013 Permalink | Log in to Reply

      As the response was overwhelmingly positive (even from some of you who are traditionally serial devil’s advocates), I think we’re going to move forward with this. Thanks, all, for your feedback.

      What I’ll likely do it consult with various people (@bpetty, notably) about implementation, doublecheck the e-mail address in my authors.txt file (recommending that everyone use addresses at personal domains that they’re likely to control indefinitely), and then push out a WordPress-Fixup repo for people to audit, before pushing the new history to the WordPress repo.

      • Bryan Petty 7:02 pm on January 11, 2013 Permalink | Log in to Reply

        Confirming email addresses used would definitely be a good idea. I think a large portion of what you have now originally came from my list, which was meticulously put together from scouring plugin readmes, wp-hackers archives, and personal sites for publicly visible addresses since, at the time, I knew I wouldn’t be able to simply pull them from WP.org accounts used to make the commits (which would likely be the best source, aside from contacting everyone individually).

    • BFTrick 10:12 pm on January 15, 2013 Permalink | Log in to Reply

      This sounds brilliant.

  • Mark Jaquith 9:04 pm on January 8, 2013 Permalink
    Tags:   

    WordPress 3.6: Distraction-Free Writing improvements 

    Distraction-Free Writing (DFW) made its debut in WordPress 3.2. It’s good, but it has some problems:

    • It’s hard to discover. A tiny button that doesn’t stand out from other buttons.
    • The transition is a bit jarring. Your content goes away, you land on another screen, and your content reappears. It feels like there is a cost to switching.
    • It isn’t as fully-featured as it should be. If it isn’t capable of easily (and by that I, I mean without keyboard shortcuts) doing the majority of the formatting people need to do while writing, people are going to be disinclined to use it.
    • It could use some polish. Some of the interactions are janky, and it’s not very responsive to large screens. There are strange issues that happen when you get to the end of a line or do a line break near the bottom of the editor. The Esc key doesn’t work when in TinyMCE. Lots of little stuff like that.

    What I need is someone with CSS skills and JS competency to take on a bunch of little improvement projects for DFW. If you have those skills and care about making a beautiful and functional distraction-free writing experience for WordPress, speak up!

     
    • Chris Wallace 9:08 pm on January 8, 2013 Permalink | Log in to Reply

      I’d like to help if you need me to.

    • Andy Stratton 9:08 pm on January 8, 2013 Permalink | Log in to Reply

      I’m interested and would like to get an idea of the list fo things to be done (CSS/JS). I’ll probably try to get @bmoredrew to help me too – anything we have competency and time to do I’m interested.

    • Jeff Bowen 9:11 pm on January 8, 2013 Permalink | Log in to Reply

      I don’t have the bandwidth to lead this, but I’d love to pitch in

    • ckhicks 9:11 pm on January 8, 2013 Permalink | Log in to Reply

      I’d be happy to help explore current/popular trends in DFW environments and provide research, if needed. This is one of my favorite WP 3+ features, and it is prime real estate for greatness!

    • Eric Mann 9:16 pm on January 8, 2013 Permalink | Log in to Reply

      I’d love to help, though it would be useful if we had a concise list of all of the “janky” interactions so we know what we’re committing to.

    • Zach "The Z Man" Abernathy 9:17 pm on January 8, 2013 Permalink | Log in to Reply

      I’m on board to help with this. And I agree with Eric Mann. A playbook on what we’re committing to would be great.

    • Mel Choyce 9:49 pm on January 8, 2013 Permalink | Log in to Reply

      Not a terrible amount of js competency, but I’ve got css skills and would like to help out with this.

      • Slobodan Manic 7:56 pm on January 9, 2013 Permalink | Log in to Reply

        Similar skillset and would love to help with this one.

        There was probably talk about it already, but would moving full-screen button away from other buttons make sense? Perhaps next to Visual/Text tabs? Those two change the editor, so does full screen toggle.

    • theaccordance 10:01 pm on January 8, 2013 Permalink | Log in to Reply

      I completely agree with your assessment. The moment I found that the DFW toolbar lacked the ability to select headings I walked away from the Distraction-Free view; this is certainly something I’d like to see an improvement with.

      I just reviewed the full-screen views for a few apps on my Mac (which provide a similar experience to DF view), and with the exception of the top toolbar, the visual interactions remain fairly consistent. Would it be appropriate to approach the DF view in a similar fashion?

      Also, should consideration be given in DFW for additional functionality added to the normal TinyMCE via plugins?

      (Apologies if I should be bringing these questions up in a different location, I’m new and still getting acquainted with working on the core.)

    • adamsilverstein 10:18 pm on January 8, 2013 Permalink | Log in to Reply

      i’m in.

    • John Blackbourn (johnbillion) 3:37 am on January 9, 2013 Permalink | Log in to Reply

    • Mark Jaquith 3:48 am on January 10, 2013 Permalink | Log in to Reply

      As we have a lot of people willing to help, but none willing and confident to lead, and as this seems to be the least-well-defined of the features on the docket, it has been dropped as a scheduled feature and will instead be handled as the grab-bag of improvements that it is. I’ll work on getting it broken out into individual tasks and anyone interested should keep an eye out for “DFW” on Trac.

    • Robert Chapin (miqrogroove) 7:56 pm on January 14, 2013 Permalink | Log in to Reply

      Hi Mark, a less prominent yet important disadvantage of DFW is the lack of cross platform compatibility. iPad and other device support ahould be considered.

  • Mark Jaquith 7:42 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Autosave and Post Locking 

    I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.

    Things this will likely involve:

    • Local storage of post data while editing, in-between autosaves and manual saves.
    • More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
    • Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
    • Probably some interaction with the team working on improving Post Revisions.
    • UX work for making recovery from failure scenarios smooth, clear, and worry-free.

    @aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. :-)

     
    • Mike Schinkel 7:43 pm on January 7, 2013 Permalink | Log in to Reply

      +1!

    • Jon Brown 7:46 pm on January 7, 2013 Permalink | Log in to Reply

      +1 – May I suggest that versioning and autosaving of metadata be included in this push. I’ve seen several people become reliant on the revisions and auto-save of the content (yay, they trust it!) and then be disappointed to discover their excerpt or content in a metabox isn’t given the same treatment.

      • Mark Jaquith 7:55 pm on January 7, 2013 Permalink | Log in to Reply

        There’s at least one ticket that touches on that https://core.trac.wordpress.org/ticket/20299

        But yeah, we need to start thinking about the fact that as more people use WP as a CMS, a lot of their important data resides outside of post_content.

        • Travis Northcutt 8:01 pm on January 7, 2013 Permalink | Log in to Reply

          Absolutely this. We make heavy use of post meta in sites we build for people, and storing revisions would be a huge plus. Does anyone know of additional tickets that address this? (The one Mark linked to is specifically focused on the fact that previewing changes to a post updates meta (silently), which isn’t expected behavior).

    • Pippin (mordauk) 7:55 pm on January 7, 2013 Permalink | Log in to Reply

      Huge +1.

    • goldenapples 7:58 pm on January 7, 2013 Permalink | Log in to Reply

      +1, I’m very interested in helping work on these features. I’ve worked with the authors on the site I manage to find workarounds for a number of related problems and have several ideas I’d like to test out:

      • visualizing revision history as a tree rather than just a list (I look at vim’s :Gundo plugin as a rough UI example)
      • post meta as mentioned above, although that needs a LOT of thought (lots of postmeta is never shown in a meta box, or is not meant to be edited by authors…)
      • doing more to enable inter-user messaging along with the “heartbeat” autosave calls. Its possible to do something with websockets for the maybe 2% of sites that have that enabled, but for most people, the regular admin-ajax calls could be used to pass messages back and forth about what other users are viewing, if one user requests a release of the lock, etc.
    • adamsilverstein 9:07 pm on January 7, 2013 Permalink | Log in to Reply

      i’m interested in helping if i can

    • John Saddington 9:19 pm on January 7, 2013 Permalink | Log in to Reply

      omg. yes.

    • Arnan de Gans 9:22 pm on January 7, 2013 Permalink | Log in to Reply

      And on top of that… While you guys are at it, make the dashboard, the whole of it, faster. Better loading, faster rendering (?) Whatever. Often on sites that have a bunch of plugins active it get’s really sluggish.

      • Aaron D. Campbell 10:13 pm on January 7, 2013 Permalink | Log in to Reply

        This is largely dependent on what they plugins you’re talking about do on the dashboard. Sounds like they’re likely doing something wrong if they’re slowing down the dashboard that much.

      • Aaron Brazell 12:04 am on January 9, 2013 Permalink | Log in to Reply

        Or nuke it altogether. I don’t have numbers but I’m guessing the majority of people spend 1% of their time in the Dashboard. I find it altogether useless, although I’m sure some would disagree with me.

        When I login to WP to produce content, the first thing I do is click on Add New in the posts menu. That’s a hover and a click more than I need to get into content production.

    • John Kleinschmidt 9:46 pm on January 7, 2013 Permalink | Log in to Reply

      I have been doing a decent amount of work around offline storage recently and would love to help contribute on the JS side of things.

    • Md Mahmudur Rahman 10:10 pm on January 7, 2013 Permalink | Log in to Reply

      Excellent.

    • Grant Norwood 11:59 pm on January 7, 2013 Permalink | Log in to Reply

      Thanks, Mark. This is a great goal, and worthy of the urgency you’ve expressed! Since you mentioned post revisions, I’d like to recommend that we think about how to better compare post/page/CPT revisions within the rich text editor. As it is currently implemented, non-technical users have difficulty comparing large amounts of plain-text and raw HTML, and often give up immediately when using the compare feature. Developers are accustomed to the unified diff format, but we’re the only ones.

      Could we take inspiration from the review/editing/comparison tools used in other popular copy-editing apps (i.e., MS Word) that would make a copywriter feel more at home when comparing content revisions?

    • Gabriel Koen 9:18 pm on January 9, 2013 Permalink | Log in to Reply

      I’d like to lend a hand with this, I can provide user insight (our dev team has been fielding issues regarding this topic for a few years from a large staff of writers) as well as do PHP and JS coding for it.

    • Mike Bijon 12:49 am on January 13, 2013 Permalink | Log in to Reply

      I’d like to help with this during this cycle too.

      Since I’m time-limited to being effective on only 1-2 tickets per cycle, I be happy to help with tests and testing if time there would be valuable.

  • Mark Jaquith 2:04 am on January 2, 2013 Permalink
    Tags: , ,   

    WordPress 3.6 Planning Session 

    I hope everyone enjoyed the holidays! We’re back to our regularly scheduled IRC meetings tomorrow, and are going to start by scoping and planning out the 3.6 cycle. Wednesday, Jan 2, 21:00 UTC. Please make every effort to attend! The theme I’m proposing for 3.6 is “Content Editing”, so especially start thinking about editing, editorial workflows, revisions, autosave, DFW, etc. Also be thinking about what you’d like to work on and how much time you can commit this cycle.

     
    • John Saddington 2:45 am on January 2, 2013 Permalink | Log in to Reply

      booya. this will be awesome. can’t wait to see what 3.6 brings in terms of content editing, especially for editors of blog and blog networks. bingo.

    • Japh 2:49 am on January 2, 2013 Permalink | Log in to Reply

      I plan to be there, Mark! Looking to be an excellent release. I like the proposed theme. Depending what it ends up looking like, I imagine features for this version will be very relevant for me.

    • nofearinc 8:49 am on January 2, 2013 Permalink | Log in to Reply

      this seems way more handy than the gallery functionality as it covers every single user and would lead to performance and UX improvement. Very exciting.

    • Sara Rosso 9:25 am on January 2, 2013 Permalink | Log in to Reply

      Exciting. I’m going to follow along closely on this one! :)

    • Ron Rennick 2:38 pm on January 2, 2013 Permalink | Log in to Reply

      I hope to attend but will miss the first of the meetup. After discussing the multisite roadmap at WPCS I went through most of the multisite tickets. For 3.6 I think it would be good if we went through and cleaned up some of the small enhancements and UX inconsistencies. I’ll have a few hours a week throughout most of the 3.6 cycle to work on those items.

    • David Tufts 3:53 pm on January 2, 2013 Permalink | Log in to Reply

      As far as the custom fields and custom meta boxes go, I would like to see extendable form elements in WordPress similar to the extendable widgets. There should be a base form element class that all other form elements can extend, allowing for all form elements in the custom meta boxes to be generated using built in WordPress elements like, date picker, color picker, editor, etc. This would include input validation and all the sql validation as well. I have added something similar to this in the KickPress plugin that is in the plugin repository. (https://plugins.svn.wordpress.org/kickpress/trunk/kickpress-form-elements.php)

    • mojowill 8:54 am on January 3, 2013 Permalink | Log in to Reply

      Interested to see where this goes!

    • AqoonKaal 3:37 am on January 5, 2013 Permalink | Log in to Reply

      Thanks Mark for your dedication. When you say “Content Editing” does that include looking into the_excerpt lenght . For example if the_excerpt could accept two variables, say the_excerpt ($length, $more) so that you can assign different lenght for different categories like so: the_excerpt (“50″, “more”), or the_excerpt (“25″ “read more”), etc. That may help CMS part of WP (like E-commerce, Newpaper themes etc).

  • Mark Jaquith 9:02 pm on December 19, 2012 Permalink
    Tags:   

    WordPress 3.6 Cycle 

    I’m going to be leading the WordPress 3.6 cycle. I’d personally like the focus of the release to be about content editing (revisions, autosave, workflow, editing modes, etc), but of couse that won’t be locked down until we have our IRC planning meeting in early January.

    What I need in the meantime is to pick a backup lead. Someone who will help me with the planning, execution, and delivery of the release, as well as be able to step in if for some reason I am unable to finish. If you think you’d be a good person for that job:

    Apply to be the WordPress 3.6 Backup Lead

     
    • Marko Heijnen 9:09 pm on December 19, 2012 Permalink

      I’m curious if there would also be a focus on bringing the open tickets down. Even this release there where more tickets opened then closed.

      • Andrew Nacin 9:11 pm on December 19, 2012 Permalink

        Yes. This is going to be a separate initiative from the release itself. More in a few weeks.

    • Nashwan Doaqan 8:04 pm on December 20, 2012 Permalink

      Good , Sure thing we should add more features to WordPress , I have some ideas and I will open some tickets soon , anyway I hope WordPress 3.6 be another success version :)

    • Tom Lynch 10:56 pm on December 20, 2012 Permalink

      @markjaquith is there not room to look at the Settings API which I and others have highlighted several times and keeps being passed over?

    • Erlend Sogge Heggen 2:58 am on December 21, 2012 Permalink

      Would this update to “content editing” include a re-evaluation of TinyMCE and its alternatives? (such as wysihtml5, Aloha Editor and CKEditor)

      Some relevant discussions:
      http://wpmu.org/why-you-hate-the-wordpress-text-editor/
      http://wpmu.org/what-i-would-do-to-improve-wordpress/
      https://wordpress.org/extend/ideas/topic/improved-visual-editor

      • Mark Jaquith 8:23 am on December 21, 2012 Permalink

        I’d like to make it easier to support other editors, for sure. As for looking at alternatives — we do that constantly. But we’re also trying to work more closely with the TinyMCE team. A switch would have high costs, and it would have to be worth it. It behooves us to try as hard as we can to improve TinyMCE first.

        • Vitor Carvalho 9:38 pm on December 22, 2012 Permalink

          Easier support for other editors would be nice, but is it actually achievable? I mean, there are a lot of new JS editors with different configurations…
          I like TinyMCE, in fact neither I nor my clients have anything to say about it.

        • Erlend Sogge Heggen 12:22 am on December 29, 2012 Permalink

          Very understandable, thanks for replying.

    • mcfmullen 3:16 am on December 21, 2012 Permalink

      PLEASE make Social integration a standard feature. There is no reason that plugins ought to have their own seperate methods of authentication for twitter, facebook, etc – combining plugins kills them. If wordpress handled the authentication itself and allowed developpers only to focus on the specific features they want to implement, there is potential for users to combine any plugins they want without ever worrying about them killing each other while decluttering wordpress itself on useless cloned plugins that do nothing or die because of failed support to keep up with incessant authentication changes.

    • Mark Jaquith 7:52 am on December 21, 2012 Permalink

      There’s one improvement that I’d like to make, that’s pretty simple: built-in callbacks for some basic input types. Even just handling text input, checkbox, and textarea would cut down a lot on the slog. Happy to listen to other suggestions.

      • Vitor Carvalho 9:30 pm on December 22, 2012 Permalink

        It would be nice to have a WP_Form_UI class with some methods to handle form elements and merging it with Settings API for easier creation of pages and subpages in the admin. For example, one could create a page just extending a WP_Admin_Page class, as we already do with WP_List_table.

        • wycks 10:02 pm on December 30, 2012 Permalink

          This would be a massive benefit to developers and WordPress itself. Right now custom field wrappers are one of the most popular items on github for WordPress, making a more uniform API that covers those more constantly and integrates with internals would be very nice.

    • Ronald Huereca 12:55 pm on December 21, 2012 Permalink

      @markjaquith, would per-thumbnail editing (as defined in the theme add_image_size) ever be part of core? Right now it appears plugin territory (e.g., https://wordpress.org/extend/plugins/crop-thumbnails/), but would be nice if this were built into the new 3.5 image edit area.

      • Marko Heijnen 7:50 pm on December 27, 2012 Permalink

        I think for 3.6 this still would be plugin territory. There are some other things to address first to get to a per-thumbnail editing mode.

  • Mark Jaquith 9:32 pm on August 1, 2012 Permalink
    Tags: HiDPI,   

    How to Develop for HiDPI (“Retina”) without a Retina MacBook Pro

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