WordPress.org

Make WordPress Core

Updates from Konstantin Obenland Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 8:48 pm on April 26, 2016 Permalink |
    Tags: ,   

    Shiny Updates Kickoff for 4.6 Chat Summary 

    This is a summary of the shiny updates chat from April 26. (Slack log)

    Attendees: @ocean90, @swissspidy, @ethitter, @adamsilverstein, @karmatosed, @obenland

    Topics:

    • Remaining work
      On the updates-core.php side there is quite a bit of work remaining. On the plugin/theme management part outside of that, there is actually fairly little work remaining.
      Since the two parts vary in their readiness so much, it was proposed to go ahead with the theme/plugin management part and propose that for 4.6, while leaving the rest to be continued to be iterated on.
    • More user tests
      @obenland will reach out to @mapk and @karmatosed to get a final round of user tests in, to make sure the new workflows are up to par.
    • update-core.php changes
      Autoupdate settings will be pulled as they are not ready to be worked on yet. @swissspidy volunteered to work on #5, mainly merging the three tables and adding JS handlers for core and language updates.
    • Schedule for 4.6 inclusion
      Core patch should be ready by June 1 for merge on June 8. The remaining time is for creating visual records, user tests, and a merge proposal.

    Next meeting is on Tuesday May 3, 19:00 UTC.

     
  • Konstantin Obenland 12:00 pm on April 18, 2016 Permalink |
    Tags: , ,   

    Shiny Updates Chat 

    While 4.5 came a little too early for Shiny Updates v2, I think it would be worthwhile to try getting the plugin and theme management changes into WordPress 4.6. Regular chats have been dormant for a while, but I’d like to continue them starting Tuesday April 26 at 19:00 UTC in the #feature-shinyupdates Slack channel.

    Topics for this first chat will include remaining work, the need for more user tests, how to proceed with update-core.php changes, and a schedule for 4.6 inclusion of shiny theme/plugin installs/updates/deletes.

    There are still plenty of opportunities to get involved and help bring this iteration over the finish line. Please come join us next week and contribute to the abolishment of The Bleak Screen of Sadness™.

     
  • Konstantin Obenland 6:43 pm on January 27, 2016 Permalink |
    Tags: , , shiny-updates   

    Shiny Updates v2 

    Shiny Updates v2

    What is Shiny Updates?

    With the stated goal of “Hiding the The Bleak Screen of Sadness”, the shiny updates team is working on bringing a smoother experience for managing plugins and themes to WordPress.

    Shiny Updates v2 is an effort to continue the shiny updates effort from WordPress 4.2. The original shiny update feature only includes shiny plugin updates. The new version aims to extend this to all aspects of updates, installs, and deletes for plugins, themes in WordPress.

    There are numerous screens in the Admin that allow you to install, update, and delete themes, plugins and WordPress itself. Shiny updates is exploring ways to improve their design and especially to offer a better user experience by improving perceived performance and limiting confusing notifications.

    What does it do?

    The shiny updates plugin currently enables the following features:

    • Deleting single plugins, bulk updating and bulk deleting plugins from the plugin page.
    • Shiny plugin installs from the plugin install screen: multiple actions can be queued up.
    • Shiny theme installs, updates, and deletes, multiple queue-able, including multisite.

    What is still being worked on?

    Currently the team is brainstorming a complete rethink of the core updates page (update-core.php), working to improve clarity and enable easier Update All functionality. Work on that is happening here: https://github.com/obenland/shiny-updates/issues/5

    How can I help?

    Anyone can help by testing the plugin! Download and install the plugin, then test out all the shiny features: try installing, updating, and deleting plug7ins and themes, including bulk actions, on both single and multisite. Does everything work as expected? Are there any jarring flows? Missing notifications?

    Please report any issues on the Github repository, or drop in the #feature-shinyupdates channel in Slack to ask questions or give feedback. It’s also where we have our weekly chats, on Tuesdays 19:00 UTC. Thank you!

    P.S. Props @adamsilverstein for ghost-writing this post.

     
    • Philip Ingram 7:41 pm on January 27, 2016 Permalink | Log in to Reply

      Curious if any discussion has been opened regarding plugin updates via upload? Currently if a plugin exists, the upload fails.

      If I want to update an active plugin, it must provide updating via the core update method, ftp/file manager via overwriting files or I must deactivate, delete, upload and reactivate the plugin (which could uninstall functionality not to mention change functionality while disabled)

      I believe it would definitely improve my workflow if I could simply upload a newer version and be asked if I’d like to overwrite the current version.

      Another concept would be to archive the previous version with a max retainer threshold of x version back. This also helps address issues where a plugin update breaks existing functionality, a simple shiny update roll back/forward could be applied.

    • Ryan Boren 7:59 pm on January 27, 2016 Permalink | Log in to Reply

      Note that if you have the beta tester plugin, feature plugins can be installed from Plugins > Add New > Beta Testing. Details here: https://make.wordpress.org/core/handbook/testing/beta/

  • Konstantin Obenland 5:49 pm on October 20, 2015 Permalink
    Tags: , ,   

    Document title in 4.4 

    WordPress 4.1 introduced a way for themes to support a new way of rendering the document title, letting Core handle its generation and output. The next step followed just recently (#31078), deprecating wp_title() and replacing it with a more comprehensive way to generate titles.

    UPDATE 12 November – wp_title has been reinstated until alternative usages have been identified and a path forward for them defined.

    Plugin authors can now check for theme support and have a few new filters available that will allow them to change or replace the title in a reliable way:

    • 'pre_get_document_title' short-circuits wp_get_document_title() if it returns anything other than an empty value.
    • 'document_title_separator' filters the separator between title parts.
    • 'document_title_parts' filters the parts that make up the document title, passed in an associative array.

    This latest change makes the new API (almost) feature complete and theme authors are discouraged from using wp_title() in the future. If it was decided to add a UI to let users choose the make up of their document title, or another improvement to how title generation works, we now have a forward compatible way to handle these things.

    To upgrade themes from using wp_title() to declaring theme support for core’s title-tag without breaking backwards compatibility with WordPress 4.0 and older, theme authors can check if the callback function exists and add a shiv in case it does not:

    if ( ! function_exists( '_wp_render_title_tag' ) ) :
    	function theme_slug_render_title() {
    ?>
    <title><?php wp_title( '-', true, 'right' ); ?></title>
    <?php
    	}
    	add_action( 'wp_head', 'theme_slug_render_title' );
    endif;
    
     
    • Pippin Williamson 6:10 pm on October 20, 2015 Permalink | Log in to Reply

      As much as I love this improvement, I really don’t think a deprecated notice should be thrown here. The sheer number of themes using wp_title() is overwhelming and it will be a support / maintenance nightmare.

      • WebMan Design | Oliver Juhas 6:24 pm on October 20, 2015 Permalink | Log in to Reply

        I completely agree! This will be huge impact.

      • Konstantin Obenland 6:43 pm on October 20, 2015 Permalink | Log in to Reply

        At the point of release, theme support will have been introduced a year earlier, with the WPTRT adding it as recommended from the start. Two default themes will have been shipped with it, and it’s used in over 300,000 themes derived from _s since November ’14. And as Justin pointed out, it will have been required for the theme repo for more than a quarter of that time.

        While legacy themes will obviously still use it, there has been quiet a bit of theme developer education around this. The current landscape of document titles is really not as bleak as some make it sound.

      • Chuck Reynolds 2:15 am on October 21, 2015 Permalink | Log in to Reply

        I agree there will be a lot of questions but I also agree it’s time.

      • Coen Jacobs 10:08 am on October 22, 2015 Permalink | Log in to Reply

        If we’d go by that reasoning, there would be never any change possible. Production environments need to have debug mode switched off, so no notices there. Second, this change has been coming for so long, themes that have been actively maintained have had the chance to introduce their own way to deal with the deprecation already.

        • Samuel Wood (Otto) 9:32 pm on October 23, 2015 Permalink | Log in to Reply

          Like it or not, many live webhosts default to having the PHP display_errors flag enabled. Every time a new deprecated notice is added, sites all across the web break. Since this is going to affect themes, right on the front-page of the site and everywhere else, then that’s a lot of breakage. We cannot hope to upgrade all sites in time for this breaking change.

          Suggestion: Make the deprecated notice system not quite so stupid. Yes, users need to know things. However, if display_errors is on, and it’s the front end of the site (or the login page), and WP_DEBUG is not turned on, then we should probably shut it off if a deprecated notice is thrown. Throwing a notice out on login breaks logins (by breaking cookies), and throwing one on the main site makes for “broken” sites in the eyes of users. And all for a notice that a function, which still likely works okay, may not work in the future.

          I’m fine with the title change. But “deprecated” messages should not be so strong as to actually cause people to want to rollback WordPress versions.

          Yes, BTW, I do realize that _deprecated_notice only triggers when WP_DEBUG is explicitly on. Still, sometimes it is through auto-installers or something else. We should have some better way of warning people than displaying these notices right on the front end of the site.

          • FolioVision 3:13 am on November 3, 2015 Permalink | Log in to Reply

            We strongly agree here Samuel. While improving core structure is wonderful, transition should be gradual and over time. There’s no overwhelming benefit to breaking the web in this particular case. Gently gentlemen.

    • Justin Sainton 6:15 pm on October 20, 2015 Permalink | Log in to Reply

      +1 to not throwing a notice. this will be basically _every_ theme.

      • Pippin Williamson 6:15 pm on October 20, 2015 Permalink | Log in to Reply

        Including themes that are superbly built.

      • Simon Prosser 8:45 pm on October 20, 2015 Permalink | Log in to Reply

        Notices are only displayed with WP_DEBUG on, whats the issue?

        • Sybre Waaijer 6:29 am on October 22, 2015 Permalink | Log in to Reply

          The problem is that when a user wishes to turn it on to discover a nasty bug on a live site it will absolutely destroy the SEO value of the site if a search engine spider sees it.

          It would be better to enqueue the deprecation notice within the footer or any other part other than the tag.</p> <p>However, it’s suffice to say that I’ve been working for a good 40 hours to compromise the wrongly used wp_title tag within the header without using buffer rewriting.</p> <p>This update will force users to switch to a better theme, and it will also force theme developers to use the standards.<br /> From there it will also save a lot of developers heaps of time 🙂 So I’m pretty much all for the deprecation notice, wherever it actually may be.</p> <p>You know what, keep the deprecation notice within the title 😀 Hurray for standards!

    • Justin Tadlock 6:22 pm on October 20, 2015 Permalink | Log in to Reply

      I just wanted to note that WordPress.org themes are no longer encouraged to have the back-compat code. Title tag support is now required.

    • Aaron D. Campbell 6:49 pm on October 20, 2015 Permalink | Log in to Reply

      There is a fine line to be walked between backward compatibility and pushing ahead into better things. I think this is one of those cases where we’re walking that line very well. Themes are encourage (or in the case of .org, required) to push ahead into the newer/better way, and any theme that uses the older way **still works as it did before**. The notice deprecated function notice is not only just a notice (not an error or warning), but it’s only triggered by default if WP_DEBUG is on.

    • Drew Jaynes 7:12 pm on October 20, 2015 Permalink | Log in to Reply

      I see an inevitable question popping up: “What do I use instead?”

      The simple answer is nothing.

      If you add add_theme_support( ‘title-tag’ ); to your after_setup_theme callback, the title will just be handled. An internal core function adds it via the wp_head hook. No need to add anything to your theme’s header.php file, just remove the legacy wp_title() call.

      The ‘title-tag’ theme support was (as mentioned) added to core a year ago.

      Also, as @obenland alluded, there are several filters available for customizing the output:

      • pre_get_document_title – short-circuits wp_get_document_title() if it returns anything other than an empty value.
      • document_title_separator – Makes the separator between title parts filterable.
      • document_title_parts – Makes the parts that make up the document title filterable, passed in an associative array.
    • Jose Castaneda 8:47 pm on October 20, 2015 Permalink | Log in to Reply

      Sweet! One less thing for theme authors to maintain!

      • Ross Wintle 2:48 pm on October 22, 2015 Permalink | Log in to Reply

        So the simple answer is actually: “add `add_theme_support(‘title-tag’);` to your `after_setup_theme` callback! 😉

      • Ross Wintle 2:49 pm on October 22, 2015 Permalink | Log in to Reply

        Oh bother – that was a reply to @drewapicture above. Why is the reply button at the top of comments here?! You can tell I don’t comment on make blog very often.

    • catchmyfame 9:14 pm on October 20, 2015 Permalink | Log in to Reply

      Should https://codex.wordpress.org/Theme_Development#Template_File_Checklist be updated to *not* encourage the use of wp_title()? I didn’t see the equivalent checklist at https://developer.wordpress.org/themes/

    • simonrcodrington 9:51 pm on October 20, 2015 Permalink | Log in to Reply

      I’m all for moving forward with better things. As long as this is a developers notice when debugging is turned on and not an admin level notice that bothers users, I’m all for it.

    • Ahmad Awais 8:44 am on October 22, 2015 Permalink | Log in to Reply

      Fantastic! I just hope that theme authors will adopt this thing as quickly as possible.

    • Ross Wintle 2:47 pm on October 22, 2015 Permalink | Log in to Reply

      Confession: I’ve not been keeping up with developments in wp_title() in the last few releases. And I’m a developer who reads the make blog!! It’s only just now become clear that there is a new best practice from the one I started using several years ago. I suspect that there are many other developer like me, and many who don’t read the make blog!!!

      As a developer that creates custom themes for clients, I’m happy for a notice to be issued (to remind me to do it in future work!). I accept the need for (well documented and communicated) deprecation, but I’d really appreciate some guarantee on removal from core. I have a LOT of custom themes out there that I’ve built over the last four or five years. They all use wp_title somewhere. I’m hoping that I won’t be needing to update all that legacy code.

      Should the codex for wp_title be updated at this point to reflect the new best practice?

      • Drew Jaynes 3:04 pm on October 22, 2015 Permalink | Log in to Reply

        Should the codex for wp_title be updated at this point to reflect the new best practice?

        The code reference page for wp_title() will be updated with the deprecation notice when 4.4 is released. By that point, the wp_title() Codex article will already be redirecting to the code reference, as well.

    • BackuPsNL 4:05 pm on October 22, 2015 Permalink | Log in to Reply

      Hi

      How to call the new title function with the separator of choice?
      How to get just the title without the wpsite name?

      I liked the way wp_title() worked.

      I am not happy with this code change… 🙁

      • Konstantin Obenland 3:32 pm on October 23, 2015 Permalink | Log in to Reply

        How to call the new title function with the separator of choice?

        You can use the document_title_separator filter to change the separator to whatever you like. You can now even customize it to change based on what kind of page is being viewed!

        How to get just the title without the wpsite name?

        When you filter document_title_parts you can just change or unset the part that you don’t want to show up.

        • BackuPsNL 8:54 am on October 24, 2015 Permalink | Log in to Reply

          How does this work with the Yoast Seo plugin. As in the previous version i could just call wp_title and i got the correct yoast seo title when the plugin was activated.

          Now i have to enable force rewrite titles in that plugin settings to get the correct title in my page.

          With the Yoast plugin enabled and with force rewrite titles off i do not get the correct title as entered in the yoast seo title field in the page.

          I want to use my own title function as i dont like how wp presents it now.

          From wordpress you get Title – Page – Blog But i want Title – Blog – Paged

          There is no way to change the order or how wordpress presents the title. is there? If so please provide a example how todo so.

          • Konstantin Obenland 7:59 pm on October 24, 2015 Permalink | Log in to Reply

            The API was not usable for plugins until now. I’m sure SEO plugins will provide a way to interact with it by the time 4.4 ships.

            • BackuPs 4:29 pm on December 9, 2015 Permalink

              I updated the post to reflect that wp_title() has been reinstated until alternative usages have been identified and a path forward for them defined.

              Luckily the depricated notice has been removed at the final release of wp 4.4.

              I should have waited updating the theme core files on the final release and not have worked with the beta 4.4.xxx

    • johnstonphilip 4:57 pm on October 22, 2015 Permalink | Log in to Reply

      I had used wp_title to generate facebook open graph meta tags. What would one want to use for that instead moving forward?

      <meta property="og:title" content="” />

      • johnstonphilip 4:58 pm on October 22, 2015 Permalink | Log in to Reply

        ok so the php was stripped out of that comment. Here it is again without the php tags

      • Konstantin Obenland 3:34 pm on October 23, 2015 Permalink | Log in to Reply

        Using wp_title() to display anything other than the document title is not really ideal. In your case you’d want to use the wp_head action to attach a callback that would output that html.

        • Nathan Shubert-Harbison 10:37 pm on November 5, 2015 Permalink | Log in to Reply

          What would you use to print the page title inside the `wp_head` action though?

          • Samuel Wood (Otto) 4:27 pm on November 11, 2015 Permalink | Log in to Reply

            Ideally, you would not be rolling your own code to do this in the first place. Many plugins can do this for you, such as SEO plugins, Facebook specific plugins, Sharing plugins, Jetpack, etc. Themes would not have this sort of code in them.

            That said, the OpenGraph title for, say, a Page, would ideally be the title of the Page, not the wp_title(). OpenGraph is for sharing content, after all. So get_the_title() would be what you want to use, although you would probably need to preload the_post() and do a rewind_posts() to get that in the normal manner. It’s not an ideal situation to pre-load posts, but it is doable by plugins. It is poorly doable by themes, they’re doing it in the wrong order, basically.

    • Shah Alom 2:43 pm on November 12, 2015 Permalink | Log in to Reply

      Have basic confusion!

      What is the difference between

      add add_theme_support( ‘title-tag’ ) to function file directly

      and

      in the after_setup_theme callback hook

    • Konstantin Obenland 6:37 pm on November 12, 2015 Permalink | Log in to Reply

      I updated the post to reflect that wp_title() has been reinstated until alternative usages have been identified and a path forward for them defined.

    • Darko A7 4:41 am on November 17, 2015 Permalink | Log in to Reply

      This feels like a downgrade to me, what I had in few lines of code just the way I like it in one visible place, now have to do with filters and what not. Why?

      Anyway, I was doing a quick beta testing (4.4-beta4-35649) and there are absolutely no options to customize titles (separators, handling empty search strings…). This is a big omission, since they are supposedly now generated and handled by core.

      • Konstantin Obenland 4:33 pm on November 17, 2015 Permalink | Log in to Reply

        Separators can be changed with the document_title_separator filter, adjustments for special cases can be done by filtering document_title_parts .

    • BobNwp 6:36 am on December 11, 2015 Permalink | Log in to Reply

      This is going to be VERY, VERY long, but it would behoove you to read it all and discuss it amongst yourselves.
      ———————————

      WP “deprecates ” far too often! There is the principle of backward compatibility and it is a serious issue.

      Given the number of sites using WP (hundreds of thousands, or maybe millions??), there is no excuse for the number of things you drop and replace in the package.

      I believe that you would find that a large percentage of questions posted in the forums are about things that have been dropped or changed?

      Have any of you people ever worked in a real data processing shop and learned the foundation and principles of software design, coding, modification, and problem determination and problem resolution?

      I’ve been at this since 1973 (everything from basic programming to designing, coding, implementing telecommunications software and systems support for large IBM mainftrame shops) and I have never run into a product, either PC or mainframe, which drops or changes as many things as WP. – never.

      I’ve never encountered a package that requires such attention to release changes simply to keep a site up and running.

      The hallmark of a good software package is backward compatibility. An installation of WP created years ago should continue to work if an upgrade is done. Sure, it won’t be taking advantage of the latest and greatest features, but it should work as it had before the upgrade.

      You need to step back and take a realistic look at the way you drop functions and change other things.

      Seriously – you are not using generally accepted design and modification principles.

      WP is far to complicated for what it does. It is a bloated attempt to be everything for everyone.

      You documentation is poor and you have invented terms and methods which do not correspond with the terms and meaning used elsewhere.

      When I step back and look at this, it seems that you are more interested in doing things in the fanciest way you can; you can’t leave well enough alone; you are confusing “bleeding edge” software ideas with creating and maintaining an easy to use product which is fully backward compatible.

      Yes, there can come a time when something must be changed, but you go about it all wrong.

      I history language,, and then I’ll end this:

      In the 1960s, IBM took a billion dollar gamble on what became the IBM System/360. The top designers and engineers were taken to a motel and told that they would stay there until they had a system design which met what at the time were revolutionary ideas.

      One was staggering in its implications. The system they designed MUST be backward compatible – period

      A customer must be able to purchase the smallest system and be able to upgrade to a faster, larger system with absolutely no changes in software!

      They achieved that and many other revolutionary accomplishments.

      When the IBM System/360 was announced in 1964 (I was in elementary school at the time and knew nothing about computers) what it presented was a rlarge, serious, startling evolution in computing.

      The System/360 could be used for any purpose. It was the first general purpose system and it laid the foundation for everything that has occurred since then.

      When I say that no software changes were needed, I mean NONE.

      You could disconnect the main system from the peripherals, slide in a new one, cable everything up and IPL (Initial Program Load -“boot” to you) from the same disks with the same operating system configuration used for the previous system. Certainly there would be new features available, but they did not replace or change other features available on the other model.

      Unless the programmers were told that they were running stuff on a new system, the only way they would know it would be to go into the machine room and see the new unit or they noticed that things were running faster.

      I’ve been involved with five System/360 upgrades and I cannot remember any problems. Programs written, compiled, and link-edited on the previous system ran exactly as they had been running on the new system with not changes. The operations staff had newer, “modern” consoles but they controlled the system with the same commands and procedures.

      One upgrade was from a System 360/125 to a System 370/148 – a very large jump. The 370 was the next line of IBM systems – totally compatible with the 360. New features were available on the 370, such as the very first virtual storage – I think that was available in the early 1970s. I know it was available when I started in 1973.

      If IBM were to have announced that the new release of COBOL or some other language, was not compatible with the previous release and changes were necessary – customers would have stormed the offices and lynched everyone.

      If IBM changed the instruction set of a new model, which would require all software, including operating system and other support packages, to either be replaced or recompiled/assembled and link-editted, customers would have set upon the complete destruction of IBM.

      Short of violence, IBM would find that no one was buying the new systems. Businesses have more than enough to do without having to change all the software, applications and system.

      MS did this with VB – VB 6 programs were not compatible with VB Net. You had to made code changes.

      They got away with it because they have spent enough money to convince everyone that whatever they do is correct and “you simply don’t understand things as well as we do.”

      To close this out – stop the continuous dropping and changes of functions and features. Create a product which is backward compatible.

      Try to it picture the problem that would occur when a WP site that was running for years suddenly broke because you people dropped some function. The company/person might not find out it was broken for several days, during which customers would be running into the problems.

      Not everyone using WP has the time to monitor your site to try and stay up-to-date on what you are going to drop next.

      Please, bring a little sanity to WP.

      Bob Novell

  • Konstantin Obenland 3:15 pm on September 23, 2015 Permalink
    Tags: ,   

    4.3 Retrospective Results 

    I missed posting the 4.3 post mortem recap before I went on vacation, so without further ado:

    We discussed the 4.3 release in Slack, where I asked for things that should be improved and things that went well, in order to get some feedback on how I did and helpful tips for future release leads (please find the Slack log here):

    Should be improved:

    • Figure out some ways to get more testing and more eyes on betas and RCs.
    • Not having feature plugin complete (with core patch) before the merge window.
    • The menu customizer proposal could have been written differently in anticipation of community perception.
    • The people who are able to test term splitting properly are very limited. Not sure how to wrangle people for this kind of specialized testing.
    • there seemed to be a lack of movement at the end of the cycle.
    • Features like site icon should be done as a feature plugin.
    • The merge proposal could have been proof-read by someone from the core team.
    • Getting dev-notes written up earlier.
    • There were also not a lot of feature plugins ready for core at the start of 4.3.
    • Don’t think it’s really okay to be relaxing standards in the name of forcing something to fit a deadline.
    • We did a freeze/RC maaaaybe 24 hours before release that had significant changes in it, that did not feel good.
    • We completely changed features after beta 1.
    • I think in 4.2 we discovered that have a core mentor involved much earlier also helped get it to that “ready” place. Or closer to ready.
    • Find a way to increase participation for bug scrubs.

    Went well:

    • passwords went really well.
    • We had a solid crop of guest committers that really made things go well for there project area.
    • Update to 4.3 went really smoothly over all as well.
    • We had some epic traction on Formatting component patches during this cycle. I’m a bit surprised how many tickets we closed with 4.3 because those are usually very problematic.
    • Touch and small screen usability improved significantly. Two of my top five issues were fixed outright and progress was made on a third.
    • I demoed the keyboard shortcuts in the editor to some people and they were like “DAMN, that’s amazing”.
    • i’m really happy about list table changes!
    • Shared taxonomy terms are dead.
    • WE RELEASED ON TIME!!!!

    I’m probably a little biased, but contrary to what the amount of bullet points in each section might suggest, I agree with @samuelsidler who said: “Almost everything went really smooth.” I’m proud of what we accomplished, and the download and update numbers speak for themselves. Thank you again for everyone who helped out during the release, let’s make 4.4 even better!

     
    • Sebastien SERRE 8:50 pm on September 23, 2015 Permalink | Log in to Reply

      WE RELEASED ON TIME!
      Did you had a train to catch?
      I prefered reading as in Debian’s Log, we’ll released when it will be ready than as WordPress is used on billion of websites…
      Note that ididn’t read your entire post as I just see that the most Important in WordPress is : RELEASING ON TIME ! WTF!

      • Helen Hou-Sandi 5:56 am on September 24, 2015 Permalink | Log in to Reply

        The bullet points Konstantin listed above are all direct quotes from different people, which can be seen in the Slack meeting log linked above. There is no assignment of more or less value to any one item.

      • Bjørn Johansen 7:47 am on September 24, 2015 Permalink | Log in to Reply

        Releasing on time is a testimonial of good project management.

    • FolioVision 12:40 am on September 24, 2015 Permalink | Log in to Reply

      Thanks for the great summary Konstantin.

      Some issues on the receiving end: massive security issues in 4.3 release which caused emergency patching with 4.3.1 not to mention compromised sites.

      The most important part of your report for me is: “Don’t think it’s really okay to be relaxing standards in the name of forcing something to fit a deadline.”

      Amen. I’m with Sebastien.

      The release schedule is far too sharp. There should be half as many major releases per year if quality and security are not to suffer (small fixes can come more often in .x.x releases).

      • Helen Hou-Sandi 6:21 am on September 24, 2015 Permalink | Log in to Reply

        I would note that security issues that are discovered or disclosed are not always or even typically introduced in the preceding major version, and 4.3.1’s three fixes were no exception. Certainly the timing was less than ideal and I can understand the perception, but let’s not spread misinformation please.

  • Konstantin Obenland 5:30 pm on August 20, 2015 Permalink
    Tags: ,   

    WordPress 4.3 Post Mortem 

    I’d like to do a review of the WordPress 4.3 release cycle, talk about what went well, what didn’t, and ideally derive specific items that we can improve on.

    Let’s do that in the #core channel on Slack on August 24 2015 20:00 UTC, the usual dev chat time.

     
  • Konstantin Obenland 4:42 pm on August 12, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda for August 12 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    Time/Date: August 12 2015 20:00 UTC:

    1. RC Notes
    2. Component Updates
    3. Open Floor
     
  • Konstantin Obenland 4:56 pm on August 5, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda for August 5 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    This will be a rather short meeting I assume. We’ll be discussing code freeze, RC3, and a timeline for the last two weeks of this release.

    Time/Date: August 5 2015 20:00 UTC:

    1. RC Notes
    2. Component Updates
    3. Open Floor
     
  • Konstantin Obenland 5:04 pm on July 29, 2015 Permalink
    Tags: ,   

    Dev Chat Agenda for July 29 

    Here’s the agenda for today’s Dev Chat in the #core channel on Slack.

    We’re getting ready for RC1 so lets discuss blocker, RC guidelines, and everything else related to RC.

    Time/Date: July 29 2015 20:00 UTC:

    1. RC Notes
    2. Feature Updates
    3. Component Updates
    4. Open Floor
     
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
Skip to toolbar