Make WordPress Core

Tagged: team-update Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 4:53 am on January 23, 2013 Permalink
    Tags: , , team-update   

    Autosave and Post Locking Update 

    Today we had our first scheduled meeting.

    Consensus was, for a first pass:

    • Display a simple lock/padlock icon next to locked posts within the post list screen, leaving the “Request Lock” button for the post edit screens.
    • When a post is locked, hide the Quick Edit link, and disable batch edit for the post
    • To unlock a post, the user will enter the post edit screen, then click a button to request a lock.  This will trigger a request to appear for the user with the current lock, where they can decide whether or not to allow the new lock.

    As far as development tasks go, @azaozz is planning on finishing a first run at the “Heartbeat” API to be committed before the end of the week. I’ll begin working on the list table changes for post listings. We’re currently looking for volunteers to aid, as there’s plenty of room for help! Additional tasks will include the UI for handling post lock requests and auto-save to local storage.

    We’ll certainly chat more about this tomorrow in dev chat, and are planning another meeting this Friday (2013–01–25), at 21:00 UTC (the same time as dev chat), unless this doesn’t work for many of you looking to help. Please post here, or come to the chats if you’re interested in helping with this project, and we’ll get in touch with you for further details!

     

    • John Saddington 12:20 pm on January 23, 2013 Permalink | Log in to Reply

      fantastic. i’m on pins waiting for this implementation. can’t wait!

    • mindctrl 3:25 pm on January 23, 2013 Permalink | Log in to Reply

      The idea for implementing post locking is for a person to manually click a Request Lock button in the edit post screen? Would that show up on all installs or only installs that are multi-author? Why not automatically lock a post when editing it so the workflow is streamlined?

      • Andrew Ozz 4:32 pm on January 23, 2013 Permalink | Log in to Reply

        Good questions. The Request/Take over a lock button will only show when the same post is being edited by another user. Under normal circumstances posts would never be locked on installs with only one user. However if the user opens the same post on two different devices (computers) or in two different browsers, the first instance should lock the second. That should also happen if several people use the same user account.

        We already monitor when a post is being edited and show a warning. The purpose of the enhancements is to actually prevent saving a post from two different places simultaneously.

        • mindctrl 5:59 pm on January 23, 2013 Permalink | Log in to Reply

          Thanks for the clarification. Sounds great.

          Will this be implemented in the mobile apps? I’m wondering what would happen if someone tried editing a locked post from a smartphone or tablet, and would those devices be able to lock and/or take over a locked post?

      • Mike Schroder 6:22 pm on January 23, 2013 Permalink | Log in to Reply

        That’s the idea — you’d get the lock automatically if the post isn’t locked by anyone. Then, if it’s already locked, you have the option to request the lock from the author that holds it. The feature would still exist on single-author installs, but you wouldn’t notice it, because you’d be the only one able to hold locks.

        [edit] Previous comments weren’t showing when I typed this. @azaozz‘s comments above explain further :) [/edit]

    • Mark Jaquith 8:52 pm on January 23, 2013 Permalink | Log in to Reply

      Unless I’m misunderstanding, this approach seems like it could result in posts becoming permanently locked.

      1. Open post for editing
      2. Walk away
      3. ???
      4. Profit

      • Mike Schroder 9:18 pm on January 23, 2013 Permalink | Log in to Reply

        To resolve this issue, we’ve talked about including a concept of activity via keystrokes and maybe mouse movement to maintain the lock assignment (otherwise, a user would lose the lock after X amount of inactivity).

        • Andrew Ozz 7:49 pm on January 25, 2013 Permalink | Log in to Reply

          We can also monitor user activity comparing autosaves to the server. If there are no changes for x minutes, user is inactive. Maybe we can set another flag for “user-active” in the post lock and toggle it based on autosaves.

  • Max Cutler 5:30 pm on March 2, 2012 Permalink
    Tags: team-update,   

    Team Update: XML-RPC (on behalf of westi)

    In our second cycle, the primary focus was CRUD methods for taxonomies. The work was tracked in #18438, and covers both the core implementation and the unit tests.

    We also spent more time refining the cycle 1 work (CRUD for all post types), tracked in #18429. This included fixing some date bugs (related to #15098), adding support for getting/setting post thumbnails (related to #15098), and writing unit tests.

    After using the posts methods from cycle 1, it became clear that the post type information methods from #18436 were highly desirable. The old patches on that ticket were updated and aligned with the rest of the XML-RPC work for this release.

    westi was not available for much of this cycle, so Marko and I worked on our own; he is now reviewing our final patches and will comment or commit shortly. In the meantime, I’m finishing up work on XML-RPC documentation for the codex, which should be ready by beta. Marko and I will also continue to expand the XML-RPC unit tests suite (now around 75 tests).

     

  • Helen Hou-Sandi 6:11 am on February 29, 2012 Permalink
    Tags: , team-update   

    Team Update: Browsing Buddies 

    @getsource and I did some in-person hacking at WordCamp Phoenix over the weekend. New patch on #19816 for multiple screenshots that seems good to go in as a first pass after a JS sanity check and probably an update to using .data() instead of .attr() tomorrow before dev chat. Will definitely need some UI/UX once that’s in, and will also likely need a little update for whatever the .org API response will be.

    There is also a new patch on #19815 that adds a class member variable and removes a global (yay!) and passes data via JSON instead of parseQuery. Eyes also welcome on that.

     

  • Lance Willett 6:51 am on February 28, 2012 Permalink
    Tags: team-update,   

    We’re digging in full bore to get things done by freeze. #19978 is the primary ticket.

    Tasks that need to happen by Wed Feb 29:

    • Finish the styling (Drew)
    • CSS file cleanup (Lance)
    • RTL stylesheet
    • Editor stylesheet

    The last big missing piece for styling is post formats.

    Update Wed Feb 29: see my comment below.

     

    • Lance Willett 5:41 am on February 29, 2012 Permalink | Log in to Reply

      Update: Twenty Twelve is not going to make the cut for 3.4.

      The design isn’t quite finished, and we risk a rushed, incomplete product by forcing it in.

      We’ll continue working on it so it’ll be ready at the start of the 3.5 development cycle, and do a longer report soon on why it was delayed so we can prevent it from happening again.

  • Daryl Koopersmith 11:04 pm on February 27, 2012 Permalink
    Tags: , team-update   

    Team Gandalf Update 

    Last week marked the end of our second cycle and the beginning of our sprint to get things done. We began by doing just that: last Friday, we merged the theme customizer into core. There’s still quite a bit to do and polish, so please keep that in mind. Development is being trac(k)ed at #19910.

    In the past week, we’ve introduced better JS APIs, working preview navigation (you can click URLs and it works, hooray), namespaced attributes (which will allow us to enable form submission within previews), and more. We also uncovered and fixed a fairly insane bug that stemmed from a low-level bug in Opera’s JS engine. Good times.

    Moving forward, the main goals are to integrate more setting types (headers, widgets), improve the refreshing process, polish the UI, and remove any vestigial plugin cruft. Dominik’s time will be limited over the next few weeks due to exams, so if any of this sounds exciting to you, please let me know.

     

    • drecodeam 3:43 am on March 10, 2012 Permalink | Log in to Reply

      @koopersmith. I really like this idea and would love to contribute to it. I dont have much experience in the WordPress core code, but if you can guide me towards your roadmap, things to do or some bugs, i would love to contribute to whatever i can.

    • Paal Joachim Romdahl 12:04 pm on March 11, 2012 Permalink | Log in to Reply

      Is it possible to try out the current (or soon to be current version) and create a video tutorial on what is coming into the next version of WordPress? Customization is so very important, and I look forward to checking out what you have created! My youtube channel: youtube.com/user/paaljoachim

  • Joseph Scott 4:24 am on February 25, 2012 Permalink
    Tags: team-update   

    Team Update: Bugs-RPC

    Unfortunately nothing happened for us this cycle. Since I will be out for awhile starting in a few days it has been proposed that the two XML-RPC teams be merged together.

     

    • Eric Mann 1:13 pm on February 25, 2012 Permalink | Log in to Reply

      That said, I think the majority of our outstanding tickets are ready to go. I’ll follow up with the rest of the team ASAP.

  • Helen Hou-Sandi 5:55 am on February 22, 2012 Permalink
    Tags: , team-update   

    Team Update: Browsing Buddies 

    @getsource (DH-Shredder) spent some more time over the past week working with @dkoopersmith refining the infinite scroll JS for #19815, which was committed earlier today. We briefly discussed having more results/pagination for some of the other theme-install.php tabs with @nacin (requires changes on the API end), as well as the recurring thought that perhaps the featured tab should show first. Therefore, the other patch that restricted the JS enqueue to the theme-install.php search tab only was not committed for the time being.

    After reviewing some comps with @jane, we started on the display of multiple screenshots. An initial rough patch will be up on #19816 soon. We still need to hash out the details of retrieving multiple screenshots, both in get_themes() and from the .org API, and how those images will be added to the extended details div without displaying in no JS, as discussed when first scoping the feature. We also need to take into consideration what happens when the window is resized. Provided that we can get that sorted out tomorrow, it looks like we’re on target for the cycle.

    I wrote the Theme Review Team and gave them an update on the anticipated screenshot sizes, which will remain at 300×225 (4:3), constrained by CSS. Gandalf functions as the large screenshot :) The screenshots in the list table view will be enlarged to match, as there is more space now that details are hidden by default.

     

  • Lance Willett 10:00 pm on February 20, 2012 Permalink
    Tags: team-update,   

    Team Update: Twenty Twelve 

    We are still plugging away at theme styles and related code changes. See the task list on our last update for the exact things we’re working on and who’s working on what.

    I’ll keep that list updated as we continue to crank on the theme. You can also follow along in the main Trac ticket: #19978.

    One thing that came up this week is a minor revamp to the default comment markup, see #20088 for notes and a patch. If those changes are approved we can delete a big chunk of code from Twenty Twelve’s functions file.

     

  • Daryl Koopersmith 3:59 am on February 17, 2012 Permalink
    Tags: , team-update   

    Team Gandalf Update 

    Yesterday marked the halfway point of our second cycle. We’re moving along at a steady clip. The main goal for the coming week is to tie up any loose ends and begin integrating the plugin into core. Until then, follow our progress at #19910 and in the plugin repo.

    We’ve made considerable progress in the past week. We completed a first pass for menu locations and have almost all of the elements we need for custom backgrounds (all that remains is the file upload dialog and fixing the color picker). We also added the ability to alter/choose a static front page within the customization (as decided in dev chat yesterday). Under the hood, we’ve made numerous improvements including working APIs (including rendering controls, previewing, and saving) for theme_mods and options, proper handling of multidimensional IDs, and a whole bunch of bug fixes.

     

  • Aaron D. Campbell 4:14 pm on February 16, 2012 Permalink
    Tags: , , team-update   

    Team Update: Headerators 

    We’ve pretty much wrapped up flexible headers (#17242) for both width and height. We’re currently reviewing a patch on #19840 and hope to have that finished this cycle. Our next project will be to work with Team Gandalf to help integrate flexible headers into their theme preview.

     

← Older posts

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