Custom Post Types from `state.source.postTypes` no being handled

[millerf]

Bug report

From the documentation: https://docs.frontity.org/api-reference-1/wordpress-source#state-source-posttypes

In frontity.settings.js, I have:

state: {
        source: {
          api: "http://wordpress:8080/wp-json",
          isWpCom: false,
          postTypes: [
            {
              type: "member",
              endpoint: "member",
              archive: "member",
            }]
     }
}

But from a page starting with "/member/test" The post type from endpoints "posts,pages,media" with slug "test" not found' /member/test` is the right url, and the right slug

I had to create my own handler to make it work.

[michalczaplinski]

Hi @millerf! 👋

It's not very clear from your report what your problem is exactly so I'm gonna try to second guess here.

Normally, the type in the postTypes in the frontity.settings.js file should be the same as the slug of your Custom Post Type as described in the docs.

So, I believe that in your case the type should equal members/test.

[millerf]

Sorry, yes, I didn't explain myself very well.

Here, the post type is member.

But anyway as you can see in the error

 post type from endpoints "posts,pages,media" with slug "test" not found'

Frontity is not looking for any of the types provided in the settings "postTypes"...

[millerf]

To be more precise, I had to create this handler generator:

export default customTypeHandler = (customType) => (
{
    priority: 1,
    name: customType.type,
    pattern: customType.archive + "/:slug",
    func: async ({ route, params, state, libraries }) => {

        // fetch and populate the state 
        // https://docs.frontity.org/api-reference-1/wordpress-source#example-1 

    }
});

And call it on all the postTypes at init, IN MY "Main" package:

 actions: {
    Main: {
      /**
       * Generate the handlers for the different custom Types
       */
      init: ({ libraries, state }) => {
        state.source.postTypes?.forEach((postType) => {
          libraries.source.handlers.push(customTypeHandler(postType));
        })
      },
    }

I was expecting this to be done automatically by "frontity" as described in the docs. Or am I misreading something?

[michalczaplinski]

@millerf Your custom handler should be added to frontity handlers automatically once you declare it and push it onto libraries. Right here, in fact: https://github.com/frontity/frontity/blob/d3a371d73612b24770f87432683b370f2b211a7a/packages/wp-source/src/actions.ts#L132

So, you shouldn't need to do it inside of the init(), you can just do it at the top index.js of your frontity project.

Are you able to share a repo with the reproduction? That would go a long way towards getting to the bottom of this 🙂

[anantajitjg]

I had encountered the same issue and followed the instructions provided in the Frontity forum to fix this issue. Is this a bug? or do we really need to create a handler?

[millerf]

My point exactly. From the documentation we shouldn't need to create any handler: there should be created based on the 'postTypes'...

I think there is something wrong about it. Unfortunately, I csn't share any code and I don't have time to look into it...

If I ever get time I'll definitely look into it...

[luisherranz]

If using postTypes doesn't work it is certainly a bug.

@darerodz, could you please take a look?

[DAreRodz]

My point exactly. From the documentation we shouldn't need to create any handler: there should be created based on the 'postTypes'...

Yes, that's the purpose of state.source.postTypes.

I did a quick test just copying the settings you shared and the handler was automatically generated. @millerf could you confirm that the member handlers don't appear in your site?

Another possibility is that you overwrote actions.source.init somewhere in your code? That's the action that initializes everything in the wp-source package. Or maybe if you changed some handler priorities, but it is hard to say without looking at the code. :slightly_frowning_face:

@anantajitjg, would you share your code as you had the same problem?

[anantajitjg]

https://codesandbox.io/s/nostalgic-robinson-wt9zp?file=/frontity.settings.js

Go to any job detail page from 'Jobs' from Menu and refresh the page or directly go to a page.

For example: https://wt9zp.sse.codesandbox.io/jobs/it-help-desk-technician/

You will get 'Oops! 404' in page and you will get this from terminal:

{
    ServerError: post type from endpoints "posts,pages,media" with slug "it-help-desk-technician" not found
        at Object.eval (webpack-internal:///./node_modules/@frontity/wp-source/src/libraries/handlers/postType.ts:9:21)
        at process._tickCallback (internal/process/next_tick.js:68:7)
    name: 'ServerError',
    status: 404,
    statusText: 'post type from endpoints "posts,pages,media" with slug "it-help-desk-technician" not found'
}

[SantosGuillamot]

@DAreRodz In case it helps with the triage: If you first navigate to https://wt9zp.sse.codesandbox.io/jobs/, which is the archive for the post type, and then go to one of them, it works. It's failing when you do SSR.

[DAreRodz]

Great, thanks @anantajitjg, @SantosGuillamot! Taking a look right now.

[DAreRodz]

@anantajitjg, I found the problem and also a workaround. @millerf, check it out as well, maybe this solves your issue too.

Let's say you defined a post type like this:

postTypes: [
  {
    type: "awsm_job_openings",
    endpoint: "awsm_job_openings",
    archive: "/jobs",
  },
],

The thing is that, for this specific case, a wrong pattern is generated for the awsm_job_openings post type handler. That happens because the @frontity/wp-source package uses the type property to generate the pattern and it ends being "/awsm_job_openings/:slug/", which doens't mach the actual URLs (they start with [/jobs/](), e.g. [/jobs/it-help-desk-technician/]()).

If you are using the Custom Post Type UI plugin, I guess you created a awsm_job_openings post type, and then you set the Custom Rewrite Slug option to jobs (or some other steps with a similar result) thus changing the slug that appears in the links.

The workaround would be to add a redirection. Redirections transform links internally just before running the handlers. You can use them to transform a /jobs/it-help-desk-technician/ link to /awsm_job_openings/it-help-desk-technician/ so the generated handler for the awsm_job_openings post type would match.

This only happens internally so the final URL would still be /jobs/it-help-desk-technician/.

For adding a redirection, you have to follow a similar approach as adding handlers. In your index.js, first define the redirection:

const jobsRedirect = {
  name: "awsm_job_openings",
  pattern: "/jobs/:slug",
  func: ({ slug }) => `/awsm_job_openings/${slug}/`,
};

And then, add it to the redirections array inside libraries.source:

  libraries: {
    html2react: {
      /**
       * Add a processor to `html2react` so it processes the `<img>` tags
       * inside the content HTML. You can add your own processors too
       */
      processors: [image, iframe],
    },
    source: {
      redirections: [jobsRedirect],
    },
  },

---

@SantosGuillamot, I wouldn't say this is a bug because the @frontity/wp-source package was not designed to cover this case. But, anyways, I guess we should add an option to support this in the future.

What do you think? Should we add an option in wp-source to handle this case or is it enough with the workaround for now until we release the v2 of @frontity/wp-source?

---

@luisherranz, as you are the designer of the v2 of @frontity/wp-source, I mention you just so you have in mind these cases.

[anantajitjg]

Ok, I got it! Thanks @DAreRodz for the redirections suggestion. I have removed the custom handler and added the redirection and it worked perfectly. I hope this particular case will be handled in any one of the future releases of the @frontity/wp-source package. Thanks again.

[luisherranz]

Thanks for the investigation and workaround @darerodz!

I agree with you that this should not be a bug, because the WordPress API to create CPTs doesn't have a field to change the path. In the v2 of source, the patterns will be easily changed in the state, so solving things like this would be trivial. People can use redirections until then 👍

[luisherranz]

I am going to close the issue now but feel free to reopen if you think this is not 100% solved or the workaround doesn't work for you.