28 Comments

  1. slaFFik

    In case near future is like 5 years or similar – then this title might be ok.
    WordPress core team is sluggish in implementing such things – and they have reasons for that, no doubts.
    Although (hopefully) REST API will be merged into core this year – that will be a really good boost.

    Report

  2. Dwain Maralack

    For anyone interested here’s a nice article on how you could run WordPress with Composer today: https://roots.io/using-composer-with-wordpress/

    Report

    • Peter Suhm

      Yeah, that’s a good approach, but it doesn’t solve the main issue. There’s no way to include 3rd party code in a public plugin. I mean, it’s possible, but can result in weird errors if two plugins rely on 2 different versions of the same dependency.

      Report

      • Kalen Johnson (@Kalenjohnson)

        That’s an issue that Composer helps solve. Packages don’t need to specify an exact version, they can use quite a few different ways methods to specify anything within a major release, a minor release, or a point release. As long as the package that is being relied on follows semantic versioning (and most Composer packages do), then you should be reasonably safe in having Composer pick the best package version to install.

        This is an issue that Composer helps solve, it doesn’t make it a problem. When installing WordPress plugins as Composer packages as well, multiple plugins can rely on a Composer package and that package only needs to be installed once. It’s a thing of beauty.

        Report

  3. richard

    I would like to see more security precautions. WordPress has become very vulnerable to attacks and hacks. Most of our sites record over 2000 attacks with Brute Force Attack and Securi installed. Most of these sites don’t even have that many daily visitors. Why is this? Why is WordPress so open to these attacks? Surely it must be possible to have the core more protected without adding half a dozen plugins and modifications….

    Report

    • Andreas Nurbo

      WordPress is a popular CMS and brute force attempts on login forms is an easy thing to do. This has zero to do with security in WordPress Core. Every login form gets bruteforced regardless of CMS be it Drupal, Joomla, some custom thing etc.

      Report

    • Paul

      According to core devs, a really useful tool such as a login limiter is plugin territory. No wonder WP has a reputation of being easy to hack…

      Report

  4. Bradley Kirby (@Bradley_Kirby)

    +1 on themes moving to javascript.

    People are going to be shocked at how much better themes will be once they’re freed from the chains of php.

    Report

    • Sunil

      This is big.

      There is a existing pool of existing talent when it comes to JavaScript development. And there is also a high demand for sophisticated user interfaces.

      I think these and other factors have the potential to change both the WordPress ecosystem and the way that it is perceived.

      Report

  5. Jeff Madsen (@codebyjeff)

    I couldn’t agree more that WP needs to start a major refactoring toward decoupling. I fully appreciate the massive number of existing users and code out there that cannot be simply dropped or broken, but WP cannot continue to hide its head in the sand about how brittle its codebase is.

    A gradual refactoring while *educating* WP plugin/theme devs on using the new techniques is long overdue

    Report

    • Diogenes

      A gradual refactoring while *educating* WP plugin/theme devs on using the new techniques is long overdue

      Uhh, I’d say that’s what’s been going on for the last several years already. WP is something like 18-20 percent JavaScript now.

      Report

  6. Cavalary

    One thing I’m hoping for is a feature-frozen (very) long-term release, to the tune of definitely over five years of support guaranteed, likely longer. No more changes or additions to features after a certain point, but maintained with all security patches (be they fixes or enhancements/hardenings) and bug fixes. For all of us who just want something that gets a simple (or less simple for some, but anyway) job done and keeps working smoothly.

    Report

    • Ted Clayton

      “LTS” (Long Term Service) distros became popular in Linux. They were intended at first for (sniff) business-users, and other special-cases. Regular people of course caught on, and started flocking to LTS releases. The idea & practice is spreading far & wide.

      Highly competitive sectors need to innovate and react rapidly. In part, they use a fast/frequent release schedule to do this. It lets them evolve & adapt. At this point, WordPress needs to give the appearance of competing with Drupal, which helps them feel like they are indeed competing/competitive. With the kind of dominance WP now has, any ‘competitor’ still alive has value, as insulation against monopoly-charges.

      But WP does have real & good goals they want to achieve, and they may be fully-loaded, just trying to maintain momentum. Adding the burden to maintain (multiple) LTS, or modifying the current product so it makes an LTS version practical, could be more than WP can swing.
      ===

      Note carefully that dependency-resolution (using PHP Composer, in this case) – a main topic here – strongly promotes release-stability and a more-conservative software paradigm, overall. It also isolates the system from its components, which helps with the kinds of things you want.

      So going with the Composer-dependency innovation would tend to favor the prospects for an LTS WordPress. It sounds like an enormous step, though.

      Report

  7. Ted Clayton

    The Debian Linux distribution became the de facto Linux software repository, package manager, and verification/security gate-keeper. The Ubuntu Software Center eg is a frontend into the Debian Repo.

    It is extremely important for the vast majority of Linux developers, that they get their stuff listed in the Repo asap, because the vast majority of stuff not in it, was actively rejected. If you aren’t Repo’d, the default assumption is there’s something bad-wrong.

    Today, Linux wares are written with one eye on the Repo requirements. The easier & smoother for the Repo authorities, the sooner your new package becomes socially acceptable. Not everyone & everything not in the Repo is criminal; there are specific contexts & reason why a project will not have been vetted. But the worst is the default assumption, because it is mostly true.

    The package manager systems in Linux let the user seamlessly install software from the Repo, while riding herd on all the dependencies. It’s a marvel. However, this dependency-management operates on the critical assumption that all the packages have been thoroughly shaken-down, are all compliant & consistent. That’s where all the work really is – whipping all those applications into proper shape, so the click-n-play Frontend can look like a genius.

    It so happens that the Linux app-count, and the WordPress app-count (plugins and themes) have converged. You’re looking at roughly 45,000 for both systems. Apps in Linux are bigger, but they are mostly compiled. WP apps are mostly smaller, but many are spaghetti/omg-ware.

    Vetting & proofing packages is the main work in keeping the Linux Repo viable. It is one of the largest & most-elite projects in the OSS world. Without this huge grunt-effort, any dependency-manager (including Composer) is just a GIGO-upgrade.

    The job in prepping WordPress plugins and themes for dependency is of the same approximate magnitude as doing the same for the entire Linux operating system and all its applications. But then, Linux is a fabulous system, significantly because they make this effort.

    Can WordPress address a challenge of this scope & scale?

    From Dwain Maralack’s using-composer link, above:

    So we’ve got WordPress installed and now we want to add some plugins. Thanks to composer-installers we can install them in the proper location right?

    Yes, but we’re limited to plugins that have a composer.json, require composer-installers AND have their package type set correctly. Obviously there aren’t many plugins that actually do this yet. But you can find an example here.

    In the Linux Repo, security has become official paranoia. Not only does the software have to be vetted – the vetters have to be vetted. The new system-layer that supports & enables dependency-resolution, also delivers new kinds of power to those entrusted with deploying it. There have been horror-stories. Safeguarding against misuse of the new powers will be another tough-nut, in the WordPress culture.

    Report

  8. Rick

    Ok,

    I’ll Byte.

    Composer, I understand why dependency management is important. In the same respect I understand marketing. Developer wise life could be easier. WordPress wise it does not open up lots of new plugins as pretty much every conceivable plugin has already been done. What it results in ultimately is further loss of product control by Automattic. I’d not do it.

    XML/RPC API. This is nothing new. Its simply a transport mechanism where WP apparently has been behind the curve. Yes, its important so WP installs can communicate better across services. XML/RPC will have a rather short life in terms of technology. The transport mechanism’s console games have pioneered and will continue to refine are the future as they are binary, compressed, validated and deal with very complex datum in highly structured manners. The big question for PHP is can in handle it? Without multi-threading, no way. Its dead. Apache has no problem with it nor does IIs, Nginx, Linux, MS Server alonf with C#. PHP just does not have the umph without threading ability.

    These digital transport (also secure transport) will be rearing their heads in 2-5 years. Which one becomes standard is very much up in the air right now. Since PHP developers keep their eyes on PHP they tend have no idea what is happening in the rest of the data technology universe. Sad but true.

    Will WP become a data engine for other applications? Nope. Well… I cant say “nope”. I can say, perhaps some relatively focused things where no money or least money wants be spent. Categories, text data in two formats and limited other capabilities along with procedural code doom it from whats coming in complex web applications. Again, people forget, PC/Mac OS are going as online operating systems. That means computers and devices become smart clients. Can you make Quickbooks online with WordPress? No. Can you make Halo online with WordPress. No.

    As a “Framework” engine it cannot suit general purpose complex tasking. Symfony can. Its slower than snail snot. Again, no multiple thread ability within PHP and a general structure of how Object Oriented Code is managed by PHP are BIG hang ups as other languages and frameworks provide faster processings, smaller resource footprints and from word go were created for the tasks suited. This is why managed C# is now 300% faster than PHP. Mono is more capable and faster than any PHP framework going and happily runs under Linux or Mac OS as well.

    WP is not ideal for a backend data service platform at least now. It’d take a ton of change to get there and in doing so would probably break its base usage now. Joomla thought similar, J! framework, J! CMS. Done nothing for them and J! framework is really good code, much more advanced actually albeit slower.

    So I disagree, all fronts.

    Automattic has a tremendous marketshare right now. The best move IMHO is sealing it. Making sure that it stays there and grows. Again IMHO that requires a restructure of its public assets to run more like a business and product (the volunteer scene) and towards not leaving the door wide open for others to exploit several really apparent weaknesses to anyone who’s worked for “the sharks” in business and either get put asunder, bought out, or loosing the development community wordpress enjoys.

    There are clearly people who have WordPress Community best interests at heart but with a community of 200,000,000 installs are not the right people in the right places.

    Report

  9. Alan Kellogg

    Okay, people have been pondering, how does WordPress do it? I have to ask what does WordPress do? Have we forgotten the people who use WP for blogging? Have we forgotten how many people use WP to blog? Is WordPress leaving blogging behind?

    One thing I’d like to see is closer cooperation with the W3C people, especially where CSS is concerned. Why. Because there are functions in CSS3 that are not being handled at all in WordPress.(I’ve got a demo blog to set up to illustrate a part of what I’m talking about)

    My goal is to see that our readers get something that looks good, and is a pleasure to read.

    Report

  10. rossnelliot

    Seems to me that the very idea that the WP backend will be decoupled from regular theme/templating is the reason for the delay in integrating the API into core. It means a lot to wordpress.com which is where a lot of money is.

    Report

  11. Niloufar

    Great article! You and your readers might also be interested in this blog post which suggests that WordPress as we know it will die soon and explains why it’s good news:

    https://artbees.net/themes/blog/wordpress-is-about-to-be-reborn-find-out-how-the-future-of-wordpress-is-a-game-changer/

    Report

Comments are closed.

%d bloggers like this: