WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Mark Jaquith Toggle Comment Threads | Keyboard Shortcuts

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

        http://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 http://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. (http://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/
      http://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., http://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

     
  • Mark Jaquith 3:31 am on July 11, 2012 Permalink
    Tags:   

    Recognition, and news about the 3.5 cycle 

    Before we kick off 3.5 development tomorrow with the scope session, there are a few quick announcements!

    Andrew Nacin’s prolific contributions, encyclopedic knowledge of the codebase, and his increasing development leadership have undoubtedly been known to you all. We’re now recognizing that leadership by promoting Nacin to a Lead Developer!

    Daryl Koopersmith has had temporary commit for the past few release cycles, and should be known to you for his work on nifty features such as the theme customizer, distraction-free writing, and our fast-fast-fast linking dialog. We want him to keep bringing it for many releases to come, so we’re dropping the “temporary” bit and letting him keep ongoing commit access.

    Next, Jon Cave (“duck_”) is having his temporary commit extended once again for the 3.5 cycle. Jon’s keen eye has been quite helpful, especially when it comes to improving WordPress security.

    Finally, we’re trying something a little bit different for the 3.5 cycle. We’re going to have a specific release leader — someone who has both primary authority and primary responsibility for the release. They’ll lead the scope discussion, they’ll coördinate the development process, they’ll crack the whip when people aren’t delivering on things they promised, and they’ll make the hard decisions about whether features stick or get punted. If this works, we can make this a rotating gig.

    For the 3.5 cycle, Andrew Nacin will take the lead, and Daryl Koopersmith will be his second-in-command. These are your point people for this release. I, for one, am excited to see what they (and you) can accomplish!

     
  • Mark Jaquith 1:26 pm on July 5, 2012 Permalink  

    Canonical redirects and IIS 

    Canonical redirects, which were disabled on IIS several releases ago, have ben reënabled for IIS. I’d like any issues with IIS redirects to get worked out in this cycle, and would appreciate thorough testing by everyone with access to various IIS environments. File new tickets for any issues you encounter.

     
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