Use wp-rest-jsonapi-serializer

[oskarrough]

With the help of @EmberSherpa's https://github.com/EmberSherpa/wp-rest-jsonapi-serializer we can potentially eliminate the need of most, if not all, of the serializer in this repo. Which is nice.

[MartinMalinda]

I'm not sure if we want to add more dependencies on the server though. Especially for themes It might be a good idea to keep the number of dependent plugins low.

[sheriffderek]

If Taras's implementation of the serializer is more robust ~ than it may make sense to offload that responsibility, but at the core / that's mostly what this addon is, right? Maybe we should get his input and long-term intentions. He's an wonderful fella, but he may have only been temporarily excited for that one week.

Post, Tag, Category, Author, Taxonomy // TODO: create an Ember Addon to provide these defaults

If The serializer focuses and sticks to the Ember style idiomatic approach / than maybe it should stand on it's own, but otherwise ~ it may be better to combine forces / or we'll just have two competing addons with limited attention.

In general I could see this addon in many parts. I may not need to write, or use categories - for example. It would be nice to keep it as light as possible with a config or something to decide what is actually incorporated / or to have the addon broken up.

I expect that not too far in the future, there will be many many more opinions - but as it is, we seem to be on an island for the time being.

[taras]

If Taras's implementation of the serializer is more robust ~ than it may make sense to offload that responsibility, but at the core / that's mostly what this addon is, right?

Customizing Ember Data serializers is the right solution when you don't have control over the backend. When people create WordPress sites, then have access to the WP admin, so they can install whatever plugins necessary.

It's also important to note that I created wp-rest-jsonapi-serializer to enable a scenario where the users are accessing Ember App with Fastboot. WordPress only provides the API. In this scenario, themes that are created for WordPress are completely useless. I would argue that they're useless for the kind of projects that Ember + WordPress stack would be useful for.

www.embermeetup.com is a good example of this setup. I use total 0 themes and 15 plugins on the entire site. Here is the list of plugins:

-Admin Columns -CloudFlare Flexible SSL -Disqus Comment System -GitHub Updater -Pods - Custom Content Types and Fields -Regenerate Thumbnails -Simple Image Sizes -SVG Support -Video Thumbnails -Video Thumbnails Pro -Wordpress SuperSonic with CloudFlare -WP Force SSL -WP REST API -WP-Mail-SMTP -WP-REST JSONAPI Serializer

Most of these plugins provide low level customizations to WordPress.

He's an wonderful fella, but he may have only been temporarily excited for that one week.

WordPress for me is just using something that I know to help me support a hobby(EmberMeetup.com). I'd be happy to support anyone is evolving wp-rest-jsonapi-serializer if they'd like to grow it for the purpose of using it for work.

If The serializer focuses and sticks to the Ember style idiomatic approach / than maybe it should stand on it's own, but otherwise ~ it may be better to combine forces / or we'll just have two competing addons with limited attention.

I would suggest like to combine efforts. Possibly, even create ember-wordpress organization and move wp-rest-jsonapi-serializer to that organization. We can create a site that talks specifically about using Ember + WordPress together. ember-wordpress could provide default Post, Categories and Tags models.

In general I could see this addon in many parts. I may not need to write, or use categories - for example. It would be nice to keep it as light as possible with a config or something to decide what is actually incorporated / or to have the addon broken up.

The right way to do this in Emberland is to wait for treesharking to finalized. With tree shaking, you'll be able to install an addon and use what you need and everything that you don't use will be shaken out of your project. So, I'd suggest that we don't worry about this right now.

I expect that not too far in the future, there will be many many more opinions - but as it is, we seem to be on an island for the time being.

If we start to tell people about it, then we might be able to attract more people to this project. In that case, they'll likely be a lot more people's opinions. This will be great because it'll give us real use cases for this code base.

[sheriffderek]

In this scenario, themes that are created for WordPress are completely useless.

For my uses, I just create an Ember app and consume the API for brochure like sites. So, I also don't see how a WordPress theme would really be involved at all. You can't use the PHP widgets, so we just recreate those sorts of things with components.

I use a few plugins like Admin Columns, Advanced Custom Fields, Custom Post Type UI, and Adminimize to make the Admin nice ~ and then I leave that to the client to fill out, while I build the front-end.

I like it, for one - because I'm used to the admin and the clients are... that being said, the Admin (actually clicking from post to post to page etc.) is the most time consuming part of my development process. I keep hearing whispers about some Ember CMS that's supposed to happen. I know that Ghost was made with ember. If an Ember CMS that is ember-speed arrives, I'll jump to that train right away.

Either way, there are a lot of businesses with a lot of data tied up in MySQL and WordPress, so I'm sure many people will be wanting to use this soon.

Good points across the board from Taras

[taras]

@sheriffderek you'll like how Pods integrates with wp-rest-jsonapi-serializer, although the UI is kinda rudimentary. It'd be cool to create an admin replacement with Ember and use all the good stuff like Mobiledoc. But I can't even imagine who'd pay to support an effort like that.

[sheriffderek]

I think Django does something with it's admin - where it just builds the UI for the admin pages based on the API. It would be fun if there was an Advanced Custom Fields type situation for post-types/ resources and the associated fields... that was as simple as writing some JSON / but someone would have to stand to make $$$ to spend that time. In many cases, Its proven faster to just type the blog post in a template than to use WP.

postTypes: [
  post: {
    name: 'post',
    ...
  },
  project: {
    name: 'Project',
    fields: [
      {
        title: "Project title",
        type: "text",
        limit: 140
      },
      {
        description: "Project description",
        type: "wysiwyg",
        limit: 500,
        imageUpload: false
      },
    ]
  }
] // or something...

RE: pods, I'm kinda weary of them with the new RFC ~ kinda waiting to see where things fall ~ but if you say it's a cool integration / I'll take your word for it! : )

[taras]

@sheriffderek oh, I'm referring to Pods Framework It allows to define custom post type, fields and relationships. wp-rest-jsonapi-serializer uses pods information automatically sideload data from relationships.

[sheriffderek]

That sounds really great. I hadn't used that before / and I was having some worries about how best to deal with relationships. I'll check it out. : )

• Derek

On Wed, Aug 10, 2016 at 4:37 PM, Taras Mankovski notifications@github.com wrote:

@sheriffderek https://github.com/sheriffderek oh, I'm referring to Pods Framework http://pods.io It allows to define custom post type, fields and relationships. wp-rest-jsonapi-serializer uses pods information automatically sideload data from relationships.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oskarrough/ember-wordpress/issues/23#issuecomment-239036907, or mute the thread https://github.com/notifications/unsubscribe-auth/AB-IuYHfwcm5odJnrgg4D01rE4aSNS_Nks5qemCpgaJpZM4JgbUf .

[daltonrooney]

@taras wp-rest-jsonapi-serializer is a very interesting way to approach Ember/WordPress compatibility. As primarily a WP developer who is very, very new to Ember, I've learned a lot already from this repo and from yours.

Thinking about wp-rest-jsonapi-serializer from the WordPress side of things, I have a couple of issues/suggestions. Maybe I should be posting this to your repo, but since this thread is already open it might be useful:

1) The decision to require Pods may ultimately limit the usefulness of the plugin. There are dozens of frameworks that do what Pods does and anyone who is heavily invested in one may be unlikely to switch. If there's any way to make Pods optional or use lower level WordPress APIs to accomplish the same thing, that might be preferable.

2) I've registered custom fields for my API using register_rest_field, but these are not returned when using wp-rest-jsonapi-serializer. I assume this is related to the decision to use Pods, but fields that are registered by other plugins should hopefully be recognized and returned as part of the API.

3) From what I can tell, your plugin modifies the API for all clients, not just Ember clients (correct me if I'm wrong). For a small single-purpose site this makes perfect sense but again this may limit broader use. Quickly checking the WP REST API docs, the API already supports a few query parameters that change the format of the output (_envelope and _embed) so maybe it's a matter of adding a new query parameter for Ember and only running your filters when that query parameter is present.

I'm really looking forward to more crossover between them Ember and WordPress communities as I think they may be a very powerful combination when used together. Thanks everyone for your contributions.

[taras]

@daltonrooney you might want to checkout https://github.com/EmberMeetup/website it's a complete Ember app with WordPress as backend.

The decision to require Pods may ultimately limit the usefulness of the plugin.

Agree. I created it as a solution to my needs. I needed something that would support relationships. From what I know, WP doesn't provide any kind of built in relationships setup.

If there's any way to make Pods optional or use lower level WordPress APIs to accomplish the same thing, that might be preferable.

I'm totally open to this.

I've registered custom fields for my API using register_rest_field, but these are not returned when using wp-rest-jsonapi-serializer.

I didnt know about this field or how it works. I'll need to look into it. Is it post type specific?

From what I can tell, your plugin modifies the API for all clients, not just Ember clients (correct me if I'm wrong).

Yes, it's an all in solution at the moment.

Quickly checking the WP REST API docs, the API already supports a few query parameters that change the format of the output (_envelope and _embed) so maybe it's a matter of adding a new query parameter for Ember and only running your filters when that query parameter is present.

Using query params with Ember Data would be awkward. A better solution would be to activate wp-rest-jsonapi-serializer when JSONAPI content type is detected in the header.

I'm really looking forward to more crossover between them Ember and WordPress communities as I think they may be a very powerful combination when used together. Thanks everyone for your contributions.

Agree. Are you interested in helping me evolve wp-rest-jsonapi-serializer? I'd be happy to add you as a contributor and work with you to make the integration better. My team can also help you learn Ember.

[taras]

It looks like we can do a lot more with metadata now than was possible few years ago according to https://make.wordpress.org/core/2016/05/03/a-data-schema-for-meta/

We should take this conversation to wp-rest-jsonapi-serializer issue. See you there.

[oskarrough]

Closing until/if something happens in the other repo :)