Ready to get started?Download WordPress

Make WordPress Core

Updates from January, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Ryan Boren 3:48 pm on January 22, 2015 Permalink |  

    Dev Chat Summary, January 21st 




    • @drewapicture is the 4.2 release lead.
    • @wonderboymusic will be feature lead for a lot of media/image stuff.
    • 4.1.1 will drop within a week.
    • All 4.1 guest committers are renewed for 4.2.
    • The tentative target release date for 4.2 is April 8th.
    • Wednesday meetings will continue as usual.
    • Weekly Friday bug scrubs start next week.
    • This Week in Core posts will resume.
    • The 4.2 feature plugins are, tentatively: Press This, Customizer Theme Switcher, and Shiny Updates. Customizer Menus is a possible long shot.
    • The general focus of 4.2 will be polishing existing UIs in terms of mobile and accessibility.


    • @nacin will post about guest commit renewal on make/core.
    • @drewapicture will post weekly bug scrub times on make/core.
    • @dh-shredder will start This Week in Core posts while permanent contributors are located.
    • @johnbillion will add a page to the core handbook on development processes for mobile.
    • @pento will post about contributing to Shiny Updates on make/core.
    • All feature plugins will post an update to make/core.
    • Component maintainers will make a list of the main issues affecting their components.
    • @johnbillion will post a call for component maintainers on make/core.

    Links Mentioned


    (More …)

  • Jeremy Felt 4:59 am on January 14, 2015 Permalink |

    Today’s Multisite Office Hours 

    We’re continuing multisite office hours in the new year on Tuesdays at 20:00 UTC in the #core-multisite room. This is a wrap-up of today’s discussion with some goals we have in mind.

    Major takeaways today:

    • Rapid iteration on new and existing ideas can sometimes be done best as a featured plugin. It would be nice to find some areas of multisite that could be addressed this way and start working for a release in 4.3 or 4.4. It is likely too late to include any new feature plugins in the 4.2 cycle and that’s ok.
    • A good sit is needed with @nacin’s multisite roadmap from late 2013. We should revisit this, see what progress has been made, and compare with the world today. As @sam mentioned, it would be nice to see an updated version that references the previous version.
    • Some workflow study is in order. We talked a bit about the painful workflows for multisite management in closed and open networks. Taking a good look at the pain points in current flows for new users, sites, plugins, themes, etc… would be good to get a grasp on priority. Looking at how WordPress.org is organized could provide a good model for a closed network.
    • With of the above combined (and more!), some actual prioritized goals for multisite would be nice. Bug fixes can continue to be addressed as they come in, but without established long term goals we’re “floating aimlessly” (props @earnjam) each cycle with our wish lists. :)

    So. The next week is for thinking, commenting, and collaborating. If anything above sounds interesting or inspires you a bunch, please leave a comment so we can start organizing around things.

    Also – we now have a #core-multisite channel in Slack, so hop in there any time with ideas or questions.

    Thanks all for the lively discussion today!

    Tickets that came up – #30486, #20846, #14569, #18301, #20774, #27606, #30202, #29411

    For the long version, office hours started in #core and then moved to #core-multisite if you’re looking for logs.

    • emarukyan 6:50 am on January 14, 2015 Permalink | Log in to Reply

      Hi, I’m the one who has created many websites on WordPress, for media agencies.
      There are couple of things I would like to see in WP Network.

      1. Option in WP Network setup – shared library or separate library (as it is right now)
      2. adding arbitrary domain on a network, not just sub domains of a single domain.

      Because none of the current plug-ins can be used for heavy load multilingual websites, I use WP Network to solve languages problem. So that’s why sometimes I need shared library across all networks, to have same featured image on the post for different languages.

      Thank you.

      • Ipstenu (Mika Epstein) 2:19 pm on January 14, 2015 Permalink | Log in to Reply

        Adding arbitrary domains is certainly on the radar, though plugins can do that already.

        Multilingual is likely not to be something solved in Multisite at this time.

    • Sam 12:30 am on January 15, 2015 Permalink | Log in to Reply

      Who were you trying to notify and email with the @sam tag mate? I am “@sam“, and it’s not me…

      (If it is someone else who goes by just @sam in some area of WordPress, would you mind directing me to them? Maybe I can ask them to stop constantly trying to reset their password with my user name too.. Haha.)

    • Ihor Vorotnov 9:55 pm on January 21, 2015 Permalink | Log in to Reply

      With all the respect to all of the core team, multilingual is feature that has to be solved asap. There are dozens of ideas and concepts, I personally wrote about this several times. That’s a core feature. It has to be in core. Multilingual plugin developers are ready to do all the job, they are just limited by the core limitations itself.

      • Ipstenu (Mika Epstein) 11:10 pm on January 21, 2015 Permalink | Log in to Reply

        MultiLingual and multiSITE are not the same thing. I’m not arguing that we shouldn’t have a core solution, but I don’t think that solution should be Multisite.

  • Nick Halsey 7:07 pm on December 19, 2014 Permalink |
    Tags: ,   

    Menu Customizer: Call for Contributors 

    After a few months off from working on the Menu Customizer to focus on improving the Customizer API in core, I’m starting to pick up development on the feature-plugin. Now that it’s approaching a reasonably usable state, and is compatible with the latest major release of WordPress (4.1), I’d like to begin efforts to see if we can propose merging it into core for WordPress 4.2.

    But there is a lot of work to be done. When Menu Customizer was my GSoC project, it was closed to contributors per GSoC rules. But development is now open to everyone, and I could use a lot of help with both development and non-development tasks. Here’s a list of items that need work:

    •  Development
      • Build-out the core API for adding Customizer sections and controls entirely with JavaScript, #30741 and its related tickets (PHP, JS)
      • Drag & Drop menu item reordering needs to do sub-menus (code imported from nav-menus.php is commented out in menu-customizer.js currently) (JS)
      • Fix problems with previewing updates to menu items, and with previewing newly-added menus once items are added (JS)
      • Eliminate the PHP closure that currently facilitates menu previewing, for PHP 5.2 compatibility (PHP)
      • Redo the add-menu-items “panel” to lazy-load its contents & utilize Backbone sub-views (PHP, JS)
      • Improve the core Customizer on mobile, then make Menu Customizer work on mobile (CSS)
      • Think about an API or otherwise action hooks to allow plugins to add menu item fields, #27066, #21898, #18584, etc. (PHP)
      • Inline docs audit, once we’re mostly done (PHP, JS)
      • Comprehensive code review by people like @westonruter, @ocean90, or @nacin, once we’re mostly “done”, preferably before a core merge proposal. Initial code review/cleanup from anyone can start now
    • Design
      • Overall UI audit/review, propose changes
      • Consider things like #29158 in relation to how the menus UI looks
      • Discuss approach to screen options (currently an icon in the Menus panel header)
      • UX audit, propose changes
      • Evaluate user flows & menus use-cases
      • Conduct user tests
    • Other
      • General user feedback – getting the word out about the plugin and collecting feedback (reviews & support forms on the .org repo would be a good place for feedback). Anyone reading this can try the plugin and provide feedback too :)
      • Accessibility audit
      • Backwards-compatibility audit; in particular, assessing whether Menu Customizer could replace the Menus admin screen, and what further features or use-cases would need to be addressed to do so
      • Research the history of the Menus UI in core and document how Menu Customizer addresses ongoing concerns; also consider open tickets in the Menus component (for merge proposal)

    Development is happening on the WordPress.org plugins repo the a GitHub repo. Some helpful links: create a ticket, Menu Customizer tickets, development log. It’ll probably also be possible to contribute via Github if that’s your preference – talk to @westonruter about how he does it.

    This project will primarily take place over the next month, when core development is largely on hold for the holidays and between releases, and when I’m in between semesters at school. The goal is to be merge-ready before the 4.2 feature-plugin merge consideration happens in January. If you’re interested in helping out, please comment on this post or ping me in WordPress Slack in #core (@celloexpressions).

    Due to the timing of this project around the holidays, we’ll probably do mostly asynchronous communication, but I would like to try a kick-off meeting in #core Slack on Monday, December 22, 2014 18:00 UTC; please come by if you’re interested!

    • diddledan 9:11 pm on December 19, 2014 Permalink | Log in to Reply

      Hi Nick,

      you may find my plugin https://wordpress.org/plugins/custom-menu-fields/ useful as it provides an api for menu fields to be added by plugins. I’ve not updated it in a while, but you’re welcome to have a look and reuse anything you like the look of (we are all GPL afterall :-p) – I might be able to have a look at your code over the weekend or holiday period and see if I can develop and send you any patches I think you might find useful.

    • Nick Halsey 7:51 pm on December 22, 2014 Permalink | Log in to Reply

      Had our first meeting today. Ongoing discussion will happen in the new #core-customize channel on Slack, so stop by if you have any feedback or want to help out!

  • John Blackbourn 2:13 pm on December 14, 2014 Permalink |

    Release candidate status meeting 

    Just a quick reminder that there will be a meeting in #core today December 14 2014 20:00 UTC to discuss new tickets that have been reported against RC1 and any other issues from the forums, etc.

    Drop a comment here if there’s anything specific to RC1 that you think needs discussing.

  • Ryan Boren 2:53 pm on December 11, 2014 Permalink |  

    Dev Chat Summary, December 10th 




    • RC


    • About page text will land tonight (Wednesday the 10th).
    • Moving API docs into the plugin and theme handbooks will be discussed at the next docs meeting.
    • A heads up email to plugin devs will go out after RC.
    • RC will go out tonight.
    • @nacin will alert hosts and one-click installers in advance release.
    • 4.1 final targeted for Tuesday.
    • Release dry-run on Monday.
    • Status check-in meeting on Sunday.


    • @stephdau and @nacin will enable localized results for plugins after RC.
    • @nacin will work on the plugin developer email.
    • @melchoyce @ryelle @helen @jorbin will work on the about page. First draft design due by Friday.
    • @nacin @markjaquith will make the final decision on Focus, Distraction Free Writing naming, branding, text.
    • @nacin will alert hosts and one-click installers in advance of release.

    Links Mentioned


    (More …)

  • John Blackbourn 4:15 pm on December 10, 2014 Permalink |
    Tags: ,   

    Release candidate and today’s dev meeting agenda 

    4.1 was originally due for release today, but a few tickets in the 4.1 milestone have held things up a little. The release candidate will be tagged in time for today’s dev meeting at December 10 2014 21:00 UTC, and the target release date is now Monday, December 15th Tuesday December 16th.

    Here’s the agenda for today’s dev meeting:

    • Documentation from various make/core posts need to go into the plugin handbook and theme handbook.
    • The 4.1 page on the Codex is in progress.
    • Eyes on the support forums – the alpha/beta forum has seen almost no activity so we need eyes on the forums as a whole.
    • ‘About’ page design – @melchoyce, kelly, @helen #30435
    • Plugin developers – update your plugin’s readme files to indicate support for 4.1 once RC1 is released. You’ve tested all your plugins with the beta, yeah?
    • Looking for something to do? Tickets reported against trunk needs some continued triaging.
    • Status of plugin directory l10n and recommended plugins tab. @stephdau @tellyworth
    • Discuss status of l10ns for polyglots.
    • Discuss a status update meeting type thing on Sunday.
    • Discuss release plan. @nacin
    • Any other business.
    • Jeff Chandler 7:26 pm on December 10, 2014 Permalink | Log in to Reply

      One possible reason for the Alpha/Beta forums having low activity is that there hasn’t been much in the way of beta release communication on the WordPress.org development blog. There’s a small mention of a beta at the bottom of the 4.0.1 security update post but that’s from Late November. Hopefully, news of the RC1 release will be published on the official blog and that might get things going again on those forums.

      In that post, I’d also like to see specific items you want people to test.

    • Stephane Daury (stephdau) 8:39 pm on December 10, 2014 Permalink | Log in to Reply

      Plugin Directory l10n

      I’ve just uploaded a major milestone to #760-meta which bring the complete solution to life, as what I’d qualify as a sophisticated proof-of-concept (as in still needs a lot of work/testing but shows everything off):

      • code & readme translation processing
      • localized directories content translation display (wporg code already use gettext for its strings, that’s covered)
      • translation caching policy, as well cache expunging on interaction with translate.wordpress.org (imports, edits, etc)
      • api content translation display when passed a language param (arbitrary, not set-in-stone)

      See screenshots showing it in action here: https://cloudup.com/cmAHT9qu2Wx

    • Lance Willett 8:56 pm on December 10, 2014 Permalink | Log in to Reply

      For release plan, I’ll be on duty to prepare new versions of default themes for submission to Themes directory.

    • Michel - xiligroup dev 12:48 pm on December 11, 2014 Permalink | Log in to Reply

      Just a question of release : why when, testing feature on a temporary website, updating from admin from 4.1beta2 …734, we arrive directly to 4.2 alpha… and with no RC release…
      Please tell how to fin RC nighty build

    • conservativeread 1:06 pm on December 11, 2014 Permalink | Log in to Reply

      same issue here updating from admin from 4.1beta2 we arrive directly to 4.2 alpha

    • Xavier Borderie 2:03 pm on December 11, 2014 Permalink | Log in to Reply

      @michelwppi @conservativeread As discussed on Slack, “[the developers] branched 4.1 a bit earlier this time, that’s why you’re getting 4.2-alpha. The plugin gives you the nightly build from trunk, not the branch.”

    • Michel - xiligroup dev 4:18 pm on December 11, 2014 Permalink | Log in to Reply

      @[the developers]
      Branching is practical for developers… but not for ‘devoted’ testers… the update page in WP dashboard is unusable with / for RC versions… So need to use again FTP client even on localhost… and avoid again to go to 4.2 alpha… I am sure that developers can solve the UX issue ;-)

      • Knut Sparhell 5:09 pm on December 11, 2014 Permalink | Log in to Reply

        I second this. I was really annoyed by experiencing the beta tester plugin took me to 4.2.alpha insted of 4.1-RC1. If you (leads) are going to branch out before last RC in the future please give us a beta tester with three options (point releases, beta/RC or trunk). Those who always want latest alphas select trunk, betaRC-testers select beta/RC. During the cycle we can change option from trun to btea/RC to avoid this, and still have alphas at the start of a cycle.

  • Ryan Boren 10:42 pm on December 4, 2014 Permalink |  

    Dev Chat Summary, December 3rd 



    • Focus rolled out to wordpress.com.


    • Beta 3
    • RC1


    • Recommended plugins will move to a new tab in the plugin installer. The popular plugins tab will remain.
    • Strings will be released to translators on Wed. the 3rd.
    • RC1 possibly on the 3rd. Possibly not.


    • @tellyworth will move recommended plugins to a new tab.
    • @johnbillion will work on about page text, clearing the 4.1 milestone, and triaging tickets reported against trunk.
    • @nacin will release strings.
    • @johnbillion will tag RC1.

    Links Mentioned


    (More …)

  • Ryan Boren 2:11 pm on December 3, 2014 Permalink |  

    Dev Chat Summary, November 26th 




    • Beta 3


    • Beta 2 (soft-released)


    • Term splitting will be pulled from 4.1 and considered for inclusion at the beginning of the 4.2 cycle.
    • Focus will default to off.
    • The particulars of Focus UX will be documented.
    • RC1 will be Monday the 1st.
    • The final beta will be on the 27th or 28th.
    • Focus will roll out to wordpress.com for testing.
    • String freeze on Wednesday December 3rd.
    • The about page will get attention this weekend in preparation for string freeze.


    Links Mentioned


    (More …)

  • Ryan Boren 8:18 pm on November 20, 2014 Permalink |  

    Dev Chat Summary, November 19th 




    • Beta 1 released





    • @boone and @mboynes will make a list of plugins affected by term splitting.
    • @johnbillion will tag Beta 2 on Thursday.
    • @nacin and @dd32 will investigate breakage with the Beta Tester plugin.

    Links Mentioned


    Taxonomy Roadmap

    johnbillion [15:02]
    I’m going to kick right off with #30335

    #30335: Splitting shared terms on term update breaks backward compatibility when using an old term_id

    boone [15:03]
    Thanks johnbillion

    boone [15:04]
    Summary: we are splitting shared terms when they are updated. But this means that one of the previously shared term_taxonomy_ids will get a new term_id. If anyone has stored that term_id somewhere (like in postmeta), it will no longer fetch the proper item.

    boone [15:04]
    mboynes and I have worked out some backward compatibility for passing the old `term_id` to `get_terms()`, `get_term()`, and `WP_Tax_Query`.

    boone [15:05]
    nacin’s thought was that this was “too heavy” but he was willing to be convinced.

    mboynes [15:05]
    while this is an edge case bug, it can affect some of the most widely plugins (including but not limited to yoast seo, jetpack, Google XML Sitemaps, ACF, etc.

    boone [15:05]
    I personally think it’s a pretty lightweight way to prevent breaking most cases of this sort of thing.

    georgestephanis [15:05]
    @boone: Is the current implementation changing the Term ID of the currently updated one, or of the term that conflicts with it?

    boone [15:06]
    The one that is updated gets a new term_id.

    mboynes [15:06]
    some of those plugins will still have to make updates, but #30335 will significantly mitigate the likelihood of this edge case being encountered

    A whole bunch of technical discussion…

    nacin [15:30]
    Are we OK with punting on this until post beta 2? I’d like to see what else breaks in the wild.

    boone [15:30]
    johnbillion’s call, but definitely OK with me

    nacin [15:30]
    That kind of data is helpful.

    mark [15:31]
    Also how catastrophic it is when it breaks.

    nacin [15:31]
    So when we split a term, we’re abandoning the old term ID entirely?

    boone [15:31]
    mboynes: Maybe you and I can talk a bit more about assembling examples of plugins and how they’d be supported (or not) by our fix

    ethitter [15:31]
    I definitely think we should wait before reverting. Better to see what breaks now and know, rather than guessing.

    mboynes [15:31]
    @boone sure thing

    boone [15:31]
    nacin: No. The updated term gets a new term ID. All others are kept in place.

    nacin [15:31]
    Got it, it comes down to knowing old term_id + taxonomy => new term_id

    mboynes [15:31]
    I would suggest that, if you want to wait, do a partial punt

    boone [15:32]
    nacin: Exactly

    mboynes [15:32]
    at the very least, let’s store the change in the option

    mboynes [15:32]
    otherwise, that data (the old term id => new term id relationship) is lost

    nacin [15:32]
    mboynes: so you mean try to protect data during beta?

    mboynes [15:32]

    nacin [15:33]
    I’m not against that.

    boone [15:33]
    Storing data about split terms is not the worst thing in the world even if we don’t provide backward compatibility. But we can cross that bridge when we come to it.

    mark [15:34]
    I’m good with that.

    johnbillion [15:34]
    Yeah that’s not a bad idea

    nacin [15:34]
    I think mboynes just means that if we break a site tomorrow, it’d be nice to be able to “fix” it come beta 3 or whatever.

    mark [15:34]
    So people who miss the hook firing.

    mark [15:34]
    Can update in a month

    mboynes [15:34]
    My last $0.02 on this for today: I’ll be honest, I will be surprised if this does come up during beta. This is a long-tail issue, but I don’t think that makes it any less significant.

    mark [15:35]
    I like the idea of the data being there for a plugin to cleanup later.

    nacin [15:35]
    mark: or core, if we merge this. (and I suspect we will.)

    nacin [15:35]
    mboynes: I don’t expect to say “oh, there’s no breakage, let’s not do it.” Rather, I hope to see some particularly esoteric breakage that might make us think about other pieces.

    helen [15:35]
    yeah i think having an “out” is important, not nearly as concerned about perfect back compat so much as being able to be rescued.

    johnbillion [15:35]
    So the plan of attack then is: 1) Store a record of split terms for the moment. 2) Leave term splitting as-is for beta 2. 3) Post some info about how popular plugins break and whether the proposed fix from @mboynes fixes them

    boone [15:35]
    I have a feeling that seeing a handful of popular plugins that would be covered by our proposed fix might help to decide the issue one way or another. So mboynes and I will work on that, and we can talk more next week.

    Plugin i18n

    johnbillion [15:39]
    Next up, @stephdau has had to nip out but I just wanted to give a brief update on the plugin directory internationalisation work that he’s doing

    johnbillion [15:39]
    Steph has posted a comment on the agenda post with a load of details

    nacin [15:40]
    It’s just a lot of complicated juggling of overly complex systems. :simple_smile:

    johnbillion [15:40]
    Briefly, the plugin directory will get internationalised in time for 4.1 which I think is *ace

    stephdau [15:42]
    must run, @nacin will cover language packs plan

    nacin [15:43]
    I actually have nothing really to report there. It works, it just needs plugins to be opted in, which will happen over the next 1.5 months.

    johnbillion [15:44]
    So the only thing that needs changing in core is a toggle in the plugin browser, so users can toggle between plugins available in the installed locale and all plugins, correct?

    nacin [15:44]

    Twenty Fifteen

    johnbillion [15:45]

    johnbillion [15:45]
    Moving on, #30404

    WordPress Trac [15:45]
    #30404: too close to the left sidebar by using woocommerce theme

    johnbillion [15:46]
    It looks like Twenty Fifteen’s sidebar is going to cover up content that is too wide to fit in the main content area and could potentially be a pain point

    adamsilverstein [15:47]
    is lurking

    johnbillion [15:48]
    Thoughts? It may mean having to look again at the scrolling vs. fixed behaviour of the sidebar

    celloexpressions [15:49]
    I really don’t think this is something the theme can/should reasonably address. Might be able to set some sort of max-width on the main body container, but not really related to the fixed vs. unfixed sidebar

    johnbillion [15:50]
    The issue is content getting clipped underneath the sidebar instead of just flowing outside of the content area

    azaozz [15:51]
    Looks like `max-width: 100%` would do it?

    celloexpressions [15:51]
    probably, if placed on the appropriate container out of the actual content areas

    johnbillion [15:53]
    Okay, well let’s see what we can do

    deltafactory [15:53]
    Does this encourage plugins devs to consider better CSS practices?

    johnbillion [15:54]
    Possibly, but it might also affect things like really wide tables (I’ll test after the meeting unless someone else wants to)

    Release Schedule

    johnbillion [15:54]
    Next up, release schedule

    johnbillion [15:55]
    I’ll tag Beta 2 tomorrow evening

    johnbillion [15:55]
    I’d like to push RC back one week, unless @nacin or @mark disagree

    johnbillion [15:56]
    Also Petya asked about string freeze – we don’t want it happening too late so translators have plenty of time to do their translations.

    nacin [15:56]
    We don’t need to tie a string freeze to RC. I’ll release strings next week so they can get started. The bulk of the strings will be the about page.

    nacin [15:57]
    The plan for RC is next Wednesday?

    nacin [15:57]
    Next Monday.

    nacin [15:57]
    Yeah, pushing that to Dec 1 is OK to me.

    johnbillion [15:58]
    Dec 1st it is. That’s still 9 days of RC

    nacin [15:58]
    I’d aim to get it out at the end of next week.

    nacin [15:59]
    But acknowledging it’ll slip through the weekend.

    nacin [15:59]
    Expecting to get 40 tickets closed over the weekend, though, is not something you can ever count on.

    johnbillion [15:59]
    Also, Thanksgiving

    nacin [16:00]
    Right. I for example will be working but traveling Tue–Sun. Not that I have been much help this release.

    Beta Feedback

    johnbillion [16:00]
    Moving on, we’ve had a few small issues reported in the Alpha/beta forum but nothing major

    johnbillion [16:01]
    #30339 is the worst, which is a simple fix but didn’t get picked up by our current unit tests

    #30339: Infinite loop while checking for post slug uniqueness

    johnbillion [16:02]
    Trac tickets reported against trunk since Beta 1 for those interested: https://core.trac.wordpress.org/query?status=!closed&type=defect+(bug)&version=trunk&component=!Build%2FTest+Tools&time=2014-11-14..2014-11-19


    johnbillion [16:03]
    Now onto everyone’s favourite new feature, the new DFW mode

    johnbillion [16:03]
    What, if any, is the current concensus? cc @mark @janneke

    mark [16:04]
    #30356 needs a fix, obviously.

    #30356: Focus v2: admin menu slides the wrong way with RTL

    nacin [16:06]
    I haven’t seen a whole lot of feedback on focus.

    nacin [16:06]
    it’s kind of tough to search for feedback because it’s tough to describe.

    mark [16:06]

    mark [16:08]
    I think we fix that bug and let it ride defaulted on for now

    ipstenu [16:09]
    I’ve only seen one forum post about it, nacin.

    nacin [16:09]
    When we start to toy with a pointer we can think about the default.

    WordPress Trac [16:09]
    #30356: Focus v2: admin menu slides the wrong way with RTL

    nacin [16:10]
    Is it on for all post types by default?

    nacin [16:10]
    As long as it supports title & editor, I imagine?

    johnbillion [16:10]
    Just editor

    nacin [16:11]
    it’s possible that also requiring the title to be supported will more clearly delineate when the editor is designed to be front and center.

    azaozz [16:11]
    Same as editor scrolling, off for mobile, IE8, when no editor, etc.

    johnbillion [16:12]
    Ok let’s fix the RTL and roll with it for another week

    mark [16:12]

    Beta Tester Plugin

    johnbillion [16:12]
    @kimparsell asked me to mention #30405

    WordPress Trac [16:12]
    #30405: WordPress Beta Tester Plugin Broken + svn trunk update also fails

    nacin [16:13]
    odd. cc @dd32 ^

    nacin [16:13]
    As of today?

    kimparsell [16:13]

    dd32 [16:13]
    Super-odd.. I’m not sure whats happening, but I’ll check it out today

    kimparsell [16:13]
    My local installs run the Beta Tester plugin, set to bleeding edge nightlies.

    nacin [16:14]
    So, we never bumped the version string in version.php, that could be it

    dd32 [16:14]
    I suspect that’ll be it

    kimparsell [16:14]
    To update, all I have to do is load a page, and it is auto-updated.

    kimparsell [16:14]
    The auto-updates aren’t working for me as of today.

    kimparsell [16:14]
    I cannot reproduce the SVN issues.

    morganestes [16:15]
    That ticket has two different but slightly related issues.

    morganestes [16:15]
    Since the reporter also opened an issue on the plugin support itself, can we keep the trac on focused on the `svn up` issue? (edited)

    honeysilvas [16:16]
    I tried using the Beta Tester plugin this past weekend and it didn’t work

    johnbillion [16:16]
    Do we need to put the rev number back into the version string in version.php @dd32 ?

    kimparsell [16:16]
    It would be nice to have that and/or the date, if possible.

    kanedahanso [16:17]
    joined #core

    dd32 [16:17]
    Yeah, it’s also preventing auto-updates from autoupdating dev sites as 4.1-beta1 (WP) == 4.1-beta1 (API offered version)

    nacin [16:17]
    I think @dd32 and I broke some things. We’ll take a look.

    nacin [16:17]
    `svn up` is not broken, so I’m not really sure what to say about that.

    Bug Scrub

    johnbillion [16:18]
    That’s all I have for this week’s meeting except to say that Friday’s bug scrub will be a 4.1 scrubtactular and you’re all invited

    ocean90 [16:19]
    Where we should review this list too: https://core.trac.wordpress.org/query?status=!closed&type=enhancement&type=task+(blessed)&milestone=4.1&groupdesc=1&group=type

  • John Blackbourn 7:00 pm on November 19, 2014 Permalink |
    Tags: ,   

    Agenda for November 19th dev chat 

    Agenda for today’s dev chat in #core Slack (November 19 2014 21:00 UTC).

    Current status: A little over 100 tickets in 4.1 milestone

    • John Blackbourn 7:15 pm on November 19, 2014 Permalink | Log in to Reply

      • Stephane Daury (stephdau) 9:21 pm on November 19, 2014 Permalink | Log in to Reply

        As I’m going to have to take off before the chat ends, here’s where things are at:

        The system will work as follow:

        • monitors plugins.svn.wordpress.org
        • on commit, and based on a being-determinded trigger logic, we:

        * process the codebase using makepot.php
        * and/or extract translatable strings out of the parsed readme (paragraphs, list items, etc) using code I’m working on right now
        * either or both will give us a tmp pot file

        • we take the pot file and import it to glotpress, to approriate project (using existing import scripts for that)

        * code EG: https://translate.wordpress.org/projects/wp-plugins/wordpress-importer/dev
        * readme EG: https://translate.wordpress.org/projects/wp-plugins/wordpress-importer/dev-readme

        We’d now have community translation for both code and readme, for a dev and stable branch for each plugin.

        • ReadMe is kept in own GlotPress “project” because it’s used in far fewer contexts than the code’s, so we didn’t want to burden the code pot/po/mo files with the readme’s content.
        • We’ll be using https://translate.wordpress.org/projects/wp-plugins/ (might be renamed “plugins”). Was told it’ll scale.

        Next step is to use the data:

        • for plugin directory pages and API responses:

        * when accessed on localized site, or when passed a language (API), we’ll take the plugin slug
        * we query the glotpress db directly for all readme approved strings for plugin
        * we loop on them and regex replace them out of the readme content (bbpress topic_content)
        * cache the heck (long ttl) out of that (per readme section)
        * display

        That covers displaying on the sites (wp.org, fr.wp.org, etc), as well as in core, via the wp.org plugin API, since we’re already passing the local install’s laguage when querying it.

        I’ll leave the language packs part to @nacin to explain, it’s his baby :)

    • Kim Parsell 8:24 pm on November 19, 2014 Permalink | Log in to Reply

      I’d like to add #30405 to the discussion list. The Beta Tester plugin isn’t auto-updating my local installs (bleeding edge nightlies) as of today.

    • Boone Gorges 8:26 pm on November 19, 2014 Permalink | Log in to Reply

      Could I request that #30335 be moved up in the order a bit? I have to leave the meeting after the first hour and I want to make sure I’m there for the discussion.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc