Make WordPress Core

Updates from Konstantin Obenland Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 1:06 am on May 27, 2016 Permalink |
    Tags: , ,   

    This is a summary of the shiny updates chat from May 24. (Slack log)

    Attendees: @ocean90, @swissspidy, @mapk, @ryelle, @melchoyce, @adamsilverstein, @obenland


    • Open Pull Requests
      • @swissspidy was waiting for feedback and a merge on PR120, which happened right after conclusion of the meeting.
      • @ryelle was waiting for clearance to re-globalize pagenow in order to make more parts of shiny updates testable.
    • Overall status
      We should be at a point where we can write the merge proposal and a patch in the coming week. We have one more week to fix more bugs and get some more user eyes on update-core and themes. @ocean90 mentioned two core tickets that should be fixed before merge, #13071 and #36914 and asked for review and testing there.

    Next meeting is therefore on Tuesday May 31, 20:00 UTC.

  • Konstantin Obenland 7:50 pm on May 17, 2016 Permalink |
    Tags: ,   

    Shiny Updates Chat Summary 5/17/16 

    This is a summary of the shiny updates chat from May 17. (Slack log)

    Attendees: @ocean90, @swissspidy, @j-falk, @mapk, @ethitter, @obenland


    • Accomplished work since last week
      • Review requests were posted to the Accessibility, Flow, Polyglots, and Design teams.
      • The feature project landing page was written and published.
      • @swissspidy merged update-core.php into master.
      • Lots of bug fixes and smaller enhancements went in.
    • Activate after install
      We discussed what the best way would be to provide users with the ability to activate a plugin after it was installed. @swissspidy offered to work on a way that would switch the install button to an activation link after the install queue emptied, so it can be user tested for a more informed decision.
    • Update core
      @swissspidy‘s update-core work was merged into master, where it will remain to receive a broader test coverage than it would in a branch. All updates (except for ‘update all’ button) work via ajax.
    • Open floor
      We decided on a new meeting time, 20:00 UTC, that is one hour later than before.

    Next meeting is therefore on Tuesday May 24, 20:00 UTC.

  • Konstantin Obenland 8:16 pm on May 11, 2016 Permalink |
    Tags: ,   

    Shiny Updates Chat Summary 5/10/16 

    This is a summary of the shiny updates chat from May 10. (Slack log)

    Attendees: @ocean90, @swissspidy, @paaljoachim, @j-falk, @mapk, @obenland


    • Accomplished work since last week
    • Remaining work
      The landing page for feature projects still needs to be written, as well as contributor groups asked to review Shiny Updates. @ocean90 opened a few issues that need addressing as well. These things should all be done by the time of the next meeting though.
    • Activate after install
      Shiny Updates introduced a disconnect between installing a plugin and then activating it. @mapk offered to solicit more UX feedback to address what happens when there are plugin install request in the queue while the user wants to activate a plugin, and how WP signals a successful installation while changing the button action to Activate.
    • Open floor
      …was mostly spent on discussing approaches to update-core.php and inconsistencies between the theme and plugin install UI.

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

  • Konstantin Obenland 7:43 pm on May 4, 2016 Permalink |
    Tags: , ,   

    Shiny Updates Chat Summary 5/3/16 

    This is a summary of the shiny updates chat from May 3. (Slack log)

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


    • Accomplished work since last week
    • Remaining work
      @obenland will work on the Shiny Updates landing page for feature projects and fix a bug that were discovered during the most recent user test. @mapk offered to conduct another user test focused on the new interactions with some learnings from the previous one. Goal is to identify any hiccups or behaviors that are unexpected to users. @swissspidy wants to continue working on update-core.php and see if we can get it into shape for 4.6.
    • Most recent user tests
      We briefly talked about the most recent user test (linked above). It showed a variety of bugs that @obenland initially assumed were based on being in subviews of the plugin list. After the meeting it turned out that the test site ran an outdated version of WordPress that didn’t include some of the date that Shiny Update needs to work. It was a good demonstration of progressive enhancement here though, as all actions still worked, they just weren’t shiny. More user tests to come, to make sure that users agree with the new interactions.
    • Schedule for 4.6 inclusion
      Next up is writing the merge proposal that was requested to be published around 6/1, definitely before 6/8.

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

    • Scott Fennell 7:55 pm on May 4, 2016 Permalink | Log in to Reply

      Hello! I have a question about the shiny updates work — and thanks for the work, by the way.

      I have written a plugin for my own personal use (not a .org plugin) which allows me to use the core update class for updating plugins/themes that are hosted in a private bitbucket account. It works by flitering the plugin/theme data at `pre_set_site_transient_update_plugins` and `pre_set_site_transient_update_themes`.

      I was wondering if the shiny updates work could jeopardize either of those filters. Would you be able to comment on this concern?

      Aside: My plugin is pretty similar to a more well-known project called GitHub Updater.

      • Konstantin Obenland 8:03 pm on May 4, 2016 Permalink | Log in to Reply

        Hi Scott, thanks for your feedback!

        Shiny Updates doesn’t use these filters, it’s more focused on the UI of installing/updating/deleting plugins and themes. I’d encourage you though to download and activate the plugin to test how it interacts with your plugin just to make sure (and maybe let us know if you encounter any bugs or weird behavior).

    • Andy Fragen 8:03 pm on May 4, 2016 Permalink | Log in to Reply

      Hey Scott! Aside from some styling changes that will likely need to be made, the functionality of GHU and Shiny Updates work great together.

  • Konstantin Obenland 10:02 pm on May 2, 2016 Permalink |
    Tags: ,   

    Shiny Update Visual Records

  • 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


    • 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 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>
    	add_action( 'wp_head', 'theme_slug_render_title' );
    • 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


      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


      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

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
Skip to toolbar