Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wordpress-source-plugin] Self Tag is not returning proper URL #10427

Closed
zackerydev opened this issue Dec 12, 2018 · 4 comments
Closed

[wordpress-source-plugin] Self Tag is not returning proper URL #10427

zackerydev opened this issue Dec 12, 2018 · 4 comments
Labels
stale? Issue that may be closed soon due to the original author not responding any more. status: blocked This issue/PR can't be solved at the moment and shouldn't be closed/merged type: upstream Issues outside of Gatsby's control, caused by dependencies

Comments

@zackerydev
Copy link

Description

I have two apps Using Gatsby JS and the Wordpress-Source-Plugin. One of them is working just fine authenticating and loading the proper WP routes into the GraphQL Schema. This one was created a year or more ago. I also have a newer Wordpress blog that I am using as a data source, however when Authenticating this one I am seeing issues in the Schema. The default route here:
https://public-api.wordpress.com/wp/v2/sites/[WORDPRESS-BLOG]
Normally returns data like this:

{
  "namespace": "wp\/v2",
  "routes": {
    "\/wp\/v2\/sites\/WORDPRESSBLOG\/posts": {
      "namespace": "wp\/v2",
       ...
      "_links": {
        "self": "https:\/\/public-api.wordpress.com\/wp\/v2\/sites\/WORDPRESSBLOG\/posts"
      }
   ...
}

However, in my case, on the newly created Wordpress blog, the default indexing path is returning https://public-api.wordpress.com/ for EVERY Self property.

This could be a bug on Wordpress's Side, but the fix for me for now was to change the getRawEntityType function in fetch.js to this:

const getRawEntityType = route => route.substring(route.lastIndexOf(`/`) + 1, route.length);

While also passing in the path Key to that function on line 615 again in fetch.js

const entityType = getRawEntityType(key) // Excluding the "technical" API Routes

I can provide a PR with this fix if it is valid, but I could just be missing something simple.

Steps to reproduce

  1. Create a new Wordpress Blog, file an API key for it to be able to query things like Media Routes
  2. Add the wpcom_app_clientSecret, wpcom_app_clientId, wpcom_user, wpcom_pass to gatsby-config.js under the Wordpress plugin.
  3. Run gatsby develop

Expected result

The gatsby-source-wordpress plugin should pull all data from the routes provided by https://public-api.wordpress.com/wp/v2/sites/[WORDPRESS-BLOG]

Actual result

Gatsby loads all of the routes from the same URL, if the self key is not correctly representing the key.

Environment

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
  Binaries:
    Yarn: 1.5.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: 42.17134.1.0
  npmPackages:
    gatsby: ^2.0.66 => 2.0.66
    gatsby-image: ^2.0.20 => 2.0.20
    gatsby-plugin-manifest: ^2.0.9 => 2.0.12
    gatsby-plugin-offline: ^2.0.15 => 2.0.19
    gatsby-plugin-react-helmet: ^3.0.2 => 3.0.2
    gatsby-plugin-sharp: ^2.0.12 => 2.0.12
    gatsby-plugin-typography: ^2.2.1 => 2.2.1
    gatsby-source-filesystem: ^2.0.12 => 2.0.12
    gatsby-source-wordpress: ^3.0.20 => 3.0.20
    gatsby-transformer-sharp: ^2.1.8 => 2.1.8
@lukemorton
Copy link
Contributor

I can confirm this is happening for me too. The WordPress.com REST API v2 returns a different self reference for an older site compared to a newer one.

Old:
"self": "https://public-api.wordpress.com/wp/v2/sites/$site/users/me"

New:
"self": "https://public-api.wordpress.com/"

lukemorton added a commit to lukemorton/gatsby that referenced this issue Dec 22, 2018
## Description

As reported in gatsbyjs#10427 some WordPress.com sites return a `_links.$.self` with a fullpath `https://public-api.wordpress.com/wp/v2/sites/$site/users/me` and others without `https://public-api.wordpress.com/`. This means it is not a reliable way of removing the `baseUrl` from the `fullUrl`.

Instead we pass the route key in as the `fullPath` rather than the `fullUrl`. We then extract the `basePath` from the `baseUrl` before finally removing the `basePath` from the `fullPath`.

We also need to extract the raw entity type from the `fullPath` rather than route.

We also need to build the `fullUrl` from `baseUrl` and `fullPath` so I introduced the `buildFullUrl` function to do just that.

I’ve included tests for both WordPress.com and WordPress.org.

## Related Issues

Fixes gatsbyjs#10427.
@pieh
Copy link
Contributor

pieh commented Dec 28, 2018

Please check this comment - #10624 (comment) for update on the issue - there is open PR but it has some problems for non-wp.com + it really does look like bug on wp.com rest endpoints. In the comment there is link to alternative version of the wordpress plugin that works with those weird wp.com responses in case this blocks you currently

@pieh pieh added status: blocked This issue/PR can't be solved at the moment and shouldn't be closed/merged type: upstream Issues outside of Gatsby's control, caused by dependencies and removed status: inkteam to review labels Dec 28, 2018
@gatsbot gatsbot bot added the stale? Issue that may be closed soon due to the original author not responding any more. label Feb 10, 2019
@gatsbot
Copy link

gatsbot bot commented Feb 10, 2019

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

@gatsbot
Copy link

gatsbot bot commented Feb 21, 2019

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

Thanks again for being part of the Gatsby community!

@gatsbot gatsbot bot closed this as completed Feb 21, 2019
pieh pushed a commit that referenced this issue Mar 27, 2019
…d to fix fetching for wordpress.com hosted sites and proxied urls (#10624)

## Description

As reported in #10427 some WordPress.com sites return a `_links.$.self` with a fullpath `https://public-api.wordpress.com/wp/v2/sites/$site/users/me` and others without `https://public-api.wordpress.com/`. This means it is not a reliable way of removing the `baseUrl` from the `fullUrl`.

Instead we pass the route key in as the `fullPath` rather than the `fullUrl`. We then extract the `basePath` from the `baseUrl` before finally removing the `basePath` from the `fullPath`.

We also need to extract the raw entity type from the `fullPath` rather than route.

We also need to build the `fullUrl` from `baseUrl` and `fullPath` so I introduced the `buildFullUrl` function to do just that.

I’ve included tests for both WordPress.com and WordPress.org.

## Related Issues

Fixes #10427.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale? Issue that may be closed soon due to the original author not responding any more. status: blocked This issue/PR can't be solved at the moment and shouldn't be closed/merged type: upstream Issues outside of Gatsby's control, caused by dependencies
Projects
None yet
Development

No branches or pull requests

4 participants