WordPress URLs ending in .html

juanma · 23 February 2021 10:44

@cristianbote It seems URL’s defined with a specific extension (.html in this case) doesn’t load properly from SSR rendering

Can you check this to decide if this is a bug that need to be addressed or if this is something we should explain in our documentation

hsbas · 23 February 2021 11:11

Hİ @juanma,

Thank you for your interest and detailed explanation.

We do not have a special reason to use the .html extension, but the link structure has been like this for 4 years. It would not be healthy to update the link structure as “post name” as stated in the document, because we have more than 20,000 articles. So the only thing we can do is remove the “.html” at the end of the link.

But you will appreciate that making such a link structure change directly on an authoritative site like this can be risky for Google indexes.

I am very hesitant about what I should do.

cristianbote · 23 February 2021 14:00

Hi @hsbas, I am looking into it.

Meanwhile I’ve found this community question How do I link to my WordPress pages (not posts) that have a .htm extension in the URL?, where @mmczaplinski linked to post about how from a SEO point of view, the document extensions are ignored https://www.searchenginejournal.com/googles-john-mueller-says-parameters-urls-not-matter/246675/#close.

cristianbote · 24 February 2021 08:53

Open up a bug to track this further Navigating to a Server Side Rendered url with an extension, `.html`, shows 404 page · Issue #727 · frontity/frontity · GitHub

hsbas · 24 February 2021 09:43

Hi @cristianbote

I will be excitedly waiting for the problem to be solved.

Thanks!

cristianbote · 24 February 2021 14:13

Hi @hsbas,

There’s been some more progress on the issue and the fix it’s fairly straight. Would you be open to contribute with the fix yourself?

We would love and welcome any contribution! We have a fairly easy to start contribution guide. There’s nothing else like fixing an issue on an open-source software.

Let me know if there’s more that I can do in here.
Have a great one!

luisherranz · 2 March 2021 09:39

@hsbas I’ve just realized that you can also do this in a package, modifying the handlers in the init function:

export default {
  actions: {
    myPackage: {
      init: ({ libraries }) => {
        libraries.source.handlers.map((handler) => {
          handler.pattern += "(\\.html)?";
          return handler;
        });
      },
    },
  },
};

Could you please try it out and let us know if it works?

hsbas · 9 March 2021 19:23

Hi Luis,

I tried this in mars-theme index.js file. It didn’t work. I also tried in console but nothing changed. I can reach the same post multiple times with different browser tabs but when I press refresh button, it gives me 404 error.

Did you tried this action? Maybe I’m missing something.

SantosGuillamot · 12 March 2021 11:04

I think the issue is because we are using the init function, which doesn’t guarantee that the libraries from other packages have been initialized. In this case the handlers from wp-source.

In Frontity, the packages are initialized in the order they are defined in the frontity.settings.js file. In the case of the default mars-theme, the theme is before the wp-source package. This means that when we call the init function of the theme, the handlers don’t exist yet.

There are two easy ways of solving this:

Use the beforeSSR action instead of init:

export default {
  actions: {
    myPackage: {
      beforeSSR: ({ libraries }) => {
        libraries.source.handlers.map((handler) => {
          handler.pattern += "(\\.html)?";
          return handler;
        });
      },
    },
  },
};

Move the wp-source package to the top of the frontity.settings.js file so it is initialized before the theme.

I’ve tested both and they seem to work fine for me, but I guess that using beforeSSR is safer.

Could you please test if this works for you as well @hsbas ?

hsbas · 12 March 2021 12:10

Hi,

I guess I didn’t understand exactly where to use these actions. When I check “frontity.libraries.source.handlers” value at the console, I don’t see handlers ending with “.html”.

For mars-theme, can you tell me where I should place this action you’ve sent?

SantosGuillamot · 12 March 2021 12:21

For mars-theme, can you tell me where I should place this action you’ve sent?

Sure! In the case of the default mars-theme I think you could edit the index.js file. This could be it:

import Theme from "./components";
import image from "@frontity/html2react/processors/image";
import iframe from "@frontity/html2react/processors/iframe";
import link from "@frontity/html2react/processors/link";

const marsTheme = {
  name: "@frontity/mars-theme",
  roots: {
    /**
     * In Frontity, any package can add React components to the site.
     * We use roots for that, scoped to the `theme` namespace.
     */
    theme: Theme,
  },
  state: {
    /**
     * State is where the packages store their default settings and other
     * relevant state. It is scoped to the `theme` namespace.
     */
    theme: {
      autoPrefetch: "in-view",
      menu: [],
      isMobileMenuOpen: false,
      featured: {
        showOnList: false,
        showOnPost: false,
      },
    },
  },

  /**
   * Actions are functions that modify the state or deal with other parts of
   * Frontity like libraries.
   */
  actions: {
    theme: {
      toggleMobileMenu: ({ state }) => {
        state.theme.isMobileMenuOpen = !state.theme.isMobileMenuOpen;
      },
      closeMobileMenu: ({ state }) => {
        state.theme.isMobileMenuOpen = false;
      },
      beforeSSR: ({ libraries }) => {
        libraries.source.handlers.map((handler) => {
          console.log(handler.pattern);
          handler.pattern += "(\\.html)?";
          return handler;
        });
      },
    },
  },
  libraries: {
    html2react: {
      /**
       * Add a processor to `html2react` so it processes the `<img>` tags
       * and internal link inside the content HTML.
       * You can add your own processors too.
       */
      processors: [image, iframe, link],
    },
  },
};

export default marsTheme;

hsbas · 12 March 2021 12:24

Yes, I did it the same way. But for some reason, nothing changed:

SantosGuillamot · 12 March 2021 12:55

Oh, I see. I just checked that the post was loading correctly in SSR.

With the second option I suggested, using the init function instead of beforeSSR, but moving the wp-source package before the mars-theme package in the frontity.settings.js file, it seems to appear also in the console. Did that work for you?

@luisherranz Do you know the pros and cons of each approach? Should we go back to initial idea of modifying the pattern in wp-source directly?

hsbas · 14 March 2021 11:41

In this case, it works for the first page. But the same problem occurs when I surf between pages and refresh.

SantosGuillamot · 16 March 2021 09:17

You’re right. I’ve noticed that it only works for the latest post. The older ones don’t work in SSR with these solutions. I’ve written what I found in the issue to keep researching the issue there.

luisherranz · 17 March 2021 16:00

The ending .html is not the only change to the URLs of that site. It also contains the post id and the slug is not complete, so it can’t be used.

I have made a video to explain a possible solution. It also contains the configuration for the tags and categories.

This is the init function:

init: ({ libraries }) => {
  const { handlers } = libraries.source;
  const postTypeHandler = handlers.find((h) => h.name === "post type");
  const tagHandler = handlers.find((h) => h.name === "tag");
  const categoryHandler = handlers.find((h) => h.name === "category");

  // Configure the post type URLs.
  postTypeHandler.pattern = "/(.*)?/:slug-:id(\\d+).html";
  postTypeHandler.priority = 20;

  // Add tag + category handler.
  handlers.push({
    name: "category + tag",
    priority: 30,
    pattern: "/:slug",
    func: async (...args) => {
      try {
        await tagHandler.func(...args);
      } catch (e) {
        await categoryHandler.func(...args);
      }
    },
  });
};

It wouldn’t work as it is because it would require that our postTypeHandler checks if there is a params.id and use that instead of the params.slug to retrieve the content from the REST API. But I think a change like that would make sense. It is also explained in the video.

The code would be something like this:

const apiParams = { _embed: true, ...state.source.params };
params.id ? (apiParams.include = params.id) : (apiParams.slug = params.slug);

const response = await libraries.source.api.get({
  endpoint,
  params: apiParams,
});

EDIT: @hsbas how are the URLs of the pages? They also need /:slug?

bhagvan.vrinsofts · 1 June 2021 05:05

Can i use this one code for only pages ?

Thank you.

luisherranz · 1 June 2021 08:32

Sure, you can add a custom handler for your pages

Docs: @frontity/wp-source - API Reference

bhagvan.vrinsofts · 15 June 2021 16:21

Hi @all ,

I have created code for pages. we can use below code for .html pages.

init: async ({ libraries }) => {
const { handlers } = await libraries.source;
//const postTypeHandler = handlers.find((h) => h.name === “post type”);
libraries.source.handlers.push({
name: “post type”,
priority: 20,
pattern: “/(.*)?/:slug.html”, // post or page or attachment
func: postTypeHandler({
// Those are the default endpoints plus “product”
endpoints: [“pages”],
}),

We can use this one code for pages and add in index.js file.

bhagvan.vrinsofts · 24 June 2021 18:21

Hi @all

I have used above code .html link for pages then link is working fine. but i have faced after url slash.(.html/)

So can you please help me how we remove / after url.

Thanks.