WORK IN PROGRESS: Add a Page interface

[bep]

This commit adds a new resources/page package with a new Page interface and then use that interface for the core Pages definition (for .Site.Pages etc.).

The above description looks small and isolated. The number of refactorings needed to get there should show that this was very much needed. The old Page struct was getting too big; it was hard to understand and maintain, but most importantly hard/impossible to extend to other non-file sources (see #5074).

The new Page interface is still too big (see below), but that it now is an interface means that it's much more easily composable, which adds flexibility but is also much easier to understand.

A shorter version:

type Page interface {
	resource.Resource
	resource.ContentProvider
	resource.LanguageProvider
	TranslationsProvider
}

With the above, it's much easier to split and reuse the content handling (shortcodes, word counting etc.), language handling (some sources may not have a concept of language/translations, so we provide a default implementation) etc.

And having all the Page types in its own package (Page, Pages, WeightedPageetc.) means it is much easier to get proper test coverage without having to create a new Hugo site for every test case.

One of the primary goals of this commit is to not break anything. One relevant comment would be that the embedded source.File interface is now moved to a File() method. A Page isn't a file, and all the file related methods, mostly used for the build logic, very much cluttered the API. Luckily the docs on Gohugo.io is mostly on the form .File.Dir. The .Dir variants are kept for now and deprecated.

We really need this for #5074

[bep]

@spf13 @regisphilibert @digitalcraftsman @moorereason @anthonyfok @budparr and gang. This is a rather technical PR (see the description above), and it's very much a work in progress (I'm not too far away), but if you have some fundamental objections to this, now is the time to speak out (also if you see something obviously wrong in the code, but remember: This is WIP, so I probably know about it).

I kind of wish I had done this earlier, but it seemed like such a daunting task (it was/is), but I have no realistic hope of doing #5074 without first fixing this.

[regisphilibert]

Its hard for me to understand what this would change (if any) from the user standpoint.

[moorereason]

What you've done so far makes sense. My only concern is from a larger design standpoint. I was thinking we would be targeting the i/o (afero/vfs) layer instead of completely abstracting away the Page itself. But like I said, I haven't spent time researching this, so I'm going to take your word for it. 👍

Also, I agree with you about splitting Page out into its own package for testing purposing (even if it's not an interface). It's a huge chore, but hugolib could use more of this. 😁

[bep]

I was thinking we would be targeting the i/o (afero/vfs) layer instead of completely abstracting away the Page itself.

Sure, I have thought similar myself -- but in the end, breaking up a machine to get the bolts needed so you can build the machine ... The problem here, however, is not where you choose to integrate any new page source, but that we have a hugolib package with a Page struct that is so tightly coupled with everything, that even thinking about adding more on top of it (I dread the thought of adding "if source == "wordpress" or something in there ...), is making my head spin. So, I'm convinced that the route I'm taking is at least on a conceptual level, the right one.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.