Foxhound Is the First REST API Powered Theme on WordPress.org

Foxhound made its debut on WordPress.org yesterday. The React-based theme is the first in the directory to use the REST API endpoints included in WordPress 4.7. Foxhound sports a tasteful blog design with single-page app functionality that loads posts instantly. Check out the live demo to see how fast the content loads.

The theme was designed and developed by Kelly Dwan and Mel Choyce, who have collaborated on several free themes hosted on WordPress.org. They recommend installing the WP-API Menus plugin, as the REST API does not yet support menus. After installing Foxhound, there are only two things required to make it look like the demo: Set the front page to display the latest posts and set up a menu. There are no additional customization settings.

Kelly Dwan notes on Foxhound’s GitHub repository that the theme should be considered “experimental” and users can expect a few restrictions:

  • The theme does not display anything if javascript is disabled. (Should not affect SEO or accessibility)
  • The API cannot be blocked by a security plugin. Some plugins recommend blocking the users endpoint, but that is required to show the author archive. If you need to block the user endpoint, the rest of the theme should work but might be unstable if anyone tries to visit an author archive.
  • Permalinks for pages and archives are changed by this theme. They will be reset if/when you deactivate the theme. You might want to set up redirects using something like Safe Redirect Manager.
  • This theme does not support hierarchical category archives – only parent category archive pages can be displayed. This may be fixed in a later version of the theme.
  • Plugins may not work as expected, especially if they add content to the front end of the site. Most Jetpack features do still work.

Because Foxhound is so different from traditional WordPress themes, it could not go through the usual theme review process. Themes that require the WP REST API are currently reviewed outside of WordPress.org when a theme author pings the Theme Review team. They apply a “Special Case” tag that allows the theme to bypass Theme Check. (The tag is also used for other themes that break the rules in innovative ways.)

“We don’t have a lot to go on yet with those types of themes,” Key Reviewer Justin Tadlock said. “Foxhound was the first. We’re supposed to be looking over another soon. As more of these types of themes come in, we’ll be able to figure out ways of making it easier to submit them.”

30 Comments


  1. The theme does not display anything if javascript is disabled. (Should not affect SEO or accessibility)

    I am sorry, what?..

    Report


    1. I agree. That statement doesn’t make any sense. How can SEO and accessibility not be affected if nothing is displayed if JS is disabled?

      Report


      1. I would like to point out that linked Google’s post tells to use progressive enhancement, which is exact opposite of hard JS dependency to display content.

        Report


      2. The post content doesn’t appear in Googles cache of the demo site either.

        Report


      3. But to be fair, the content IS indexed by Google: https://cloudup.com/ckWeAEwqGxp

        Not having progressive enhancement (server side rendering in this case) goes against established best practice. Some of the reasons for that being best practice are no longer valid, or at least not as important (such as SEO and accessibility), but if the JavaScript doesn’t load because of a bad connection, you got no content.

        That can happen to anyone, but it is probably more common for those less privileged (ie live in areas where good internet isn’t a thing). It seems a shame to democratize publishing on the one hand, but then to present that content in a way that leaves some readers behind and unable to access it.

        I know the percentage of people affected is only very small, but they are real people. I’ll stop before I go on to how small percentages of the internet add up to large numbers of people and how we really care about that for some things (*cough* PHP version *cough*).

        Anyway, I like the idea that we’re experimenting with themes that use the WP REST API and great work Kelly and Mel for leading the way – but I do think such themes should serve up the basic content if JavaScript doesn’t load. Hope we see people doing that as we get more of these themes.

        Report


      1. yes, when you are totally broken and don;t want to be compatible with anything, you can be fast.

        Report


  2. Congrats! The first of many I hope :)

    Report


  3. I love seeing experimental themes come through the directory like this. It’s tough being the first because everyone is going to point out all the things wrong with it. :) But, it’s a good learning experience.

    Report


    1. I have mixed feeling on a themes like this in the directory.

      Official repo had always stressed baseline functionality and adhering to requirements. It had been a curse (driving boring “WordPress look” designs) but also a blessing for site owners who are far from diving into a technical nuance.

      The very recent Zerif debacle was essentially about a theme being “different” and not adhering to requirements, thus unacceptable to stay in official repository.

      So where is the line now? Are there “bad different” themes that should be thrown out and “good different” themes that should be celebrated?

      Myself I would be more concerned about random site owner out there installing theme like this than anything Zerif (to my knowledge) did.

      Report


      1. I don’t have mixed feelings at all, people that want to do JS app style sites should use ghost not wordpress. The most basic element of a wordpress themes is to trigger wp_head and wp_footer on every page load, something that do not make any sense in the case of this kind of themes.
        Currently if a user installs this theme, he is going to run to complain to 90% of the plugin authors about their plugins not working.

        The other alternative is to make a different section in the directory for “one page apps” which is what this “theme” actually is.

        Report


      2. great point; these types of themes should not be in the main catalog.

        Report


      3. I disagree. These themes are the future of WordPress IMO. Those developers who are fighting against it will be left behind. Old school jQuery themes will soon be a thing of the past. That’s the truth.

        Report


      4. No one is fighting it, comments on the tavern are just as part of wakeup routine.

        People that want to spend their time into debugging JS problems on all browsers (and it is hard to debug JS) are welcome to do that, but wordpress is not fast enough and the data structure is just not right to be used as a general application server.

        Some people want to make a circle into a square, others already seen the mathematical prof that it is impossible and have no inclination to waste their time.

        Report


      5. The key reviewers were asked if we could look over the theme and consider it. We said we would. Ulrich and I, maybe some others too, gave a pretty tough list of changes that we said would be necessary. But, we wanted to see how a theme like this might do in the repo.

        I’m not exactly happy about some of the limitations, but it doesn’t hurt to try out some new things once in a while. We also know that the theme author is working on some of those things.

        One major issue, and it’s not something the TRT has direct control over, is that themes don’t have the benefit of the readme.txt system that plugins have. That’s where I’d want the theme to be able to put a big warning up that it’s experimental and to list all of the limitations.

        The TRT has always been open to allowing exceptions if theme authors come and talk to us. Explain the situation. Convince us that you have an idea worth trying. We’ll give you a fair shake.

        Report


  4. This is great! Server Side rendering can always be added later as well as optimizations to reduce the JS bundle size.

    Report


  5. Hate to be contrarian but “so what” if the pages load quickly? It’s all client-side so I’m not sure why this is surprising. Also, other than people who go on a gorge-fest of installing every plugin that catches their eye, I have never had a WP website suffer from “slow” page loading. We are not writing FPS games, here.

    Also, if this (i.e. hundreds of .js files which you cannot convince me are not a huge PITA to debug) is the future of theme development…then I’m going to be “done” with WP before too long.

    Report


    1. I wouldn’t get too stressed out if I were you. The addition of a single experiment to the directory doesn’t mean that all new themes will act like this.

      This is an opportunity to see what works (speed), and what doesn’t (everything else). There are still hundreds of problems to solve.

      PHP folks will have a long long runway before worries can be fully justified.

      Report


    2. Chuck – It’s not just the speed that’s new here. It’s the potential to do some really interesting functionality behind the scenes while users are browsing your site and more. 10up has done an unbelievable job with http://wamu.org/. It’s a react-powered WP site with a full podcast bar built-in at the bottom. So you can listen to a podcast and browse the site at the same time. You can read more about it here, https://10up.com/blog/2016/wamu-react-rest-api/. This is the future of WP in my eyes.

      Report


      1. So far I’ve heard the “uninterrupted music and/or podcast” reason two out of the two times someone has tried to explain to me why an all-JS site is important.

        BTW, that site is s-l-o-w and the console reports several errors on a simple page load. Not very impressive. But as with most bleeding-edge things I get it…it is a work in progress. Just not my cup of tea that’s all.

        Report


    3. Hate to break it to you but JavaScript is the future of front-end development!

      Report


    4. I get it, trust me. I just don’t agree with the “all or nothing” mentality. I like to use technologies best suited for the solution, appropriately. I use JS all the time to do cool things with my sites — but I’m not interested in spending hundreds of hours to re-invent wheels that don’t need re-inventing.

      I guess I’m in the minority but that’s ok.

      Report


  6. Beautiful article, I would like to point out that Google’s linked posting says to use progressive enhancement, which is exactly the opposite of JS’s rigid dependency on displaying content, that is rather relevant

    Report


  7. Awesome loading speed. I am also in love with the font and simplicity of the design. Great work!

    Report

Comments are closed.