6 Comments

  1. Michael Houghton

    Good news.

    WPGraphQL is really excellent already and IMO should be in core as soon as possible.

    Report

  2. Justin W Hall

    Congrats Jason. And well deserved! Even while in Beta, WPGraphQL was a great. A solid graphQL option is great for developers and even better for the greater WordPress community. Now to the moon 🚀.

    Report

  3. Kayzar Boulila

    IMO should be in core as soon as possible.

    Report

  4. Kellen Mace

    Congratulations, Jason! I know you’ll do an excellent job at WPE and am excited to see what’s in store for WPGraphQL! 🙌

    Report

  5. Rick Conlee

    Well, I’m glad that someone in the WordPress ecosystem is embracing a cloud native strategy finally. I left WordPress recently in favor of a static site generator because I manage a bunch of blogs and it was getting harder and harder to manage everything at scale in a way that was more DevOps friendly. Does this mean that headless WordPress will allow for a setup similar to Hugo where content can be stored in Git and generated on deploy? That’s the dream right there. If that is the case, I’ll make the plan to come back to WP eventually.

    Report

    • Martin

      headless WordPress will allow for a setup [..] where content can be stored in Git and generated on deploy?

      That is not the idea here – headless WP still needs a web server to run.

      From what I understand the idea is: The WordPress instance can be hidden and is usually not directly accessible from the frontend. So no more “attacks” on /wp-login.php, etc. Also: you can separate frontend and backend, meaning WP runs in a secret webserver somewhere (only known by editors) and when generating the static site, you deploy to another host (just as you do with Hugo/Jekyll/Nuxt), e.g. AWS S3 or Netlify.

      The big advantage here is – in my opinion – that you can setup your WP so, that editors will love it. It will be a better experience for them than editing Markdown files in your GitHub UI explorer. In addition to that, since you can easily automate deployment, much less headaches of “can I update this or that plugin?” and more “oh, my pipeline broke because update X removed Y”.

      Report

Comments are closed.

%d bloggers like this: