-
-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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
WORK IN PROGRESS Add a NodeID (or something) to content entities #6318
Comments
We'll eventually need this on the page context for |
The first variant, yes, but not the "latter". I have added one more section about that one, but this is still a draft. |
It's hard to stay out of the weeds here, but some observations. Correct my misconceptions.
|
@moorereason I think you can call this README based implementations, and it's safe to say that even if the above have headines and pretty formatting, it's early thoughts. I can answer your questions more generally:
Some ideas for the "not straight forward part":
Note that the above is mostly talking about the "server watch mode". There are some additonal thoughs to be had around doing the full buid effectivley, keyword being date based remote updates ("give me all updates since ..."), caching with hashes of the items to detect changes on a more fine grained level etc, which is also relevant in watch mode. The aboe looks complex, and proably is. My goal is, however, to make it look simple to the end user. I have seen other SSGs where creating "source adapters" seems like a very daunting task. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This is work in progress
This ties directly into #6310 -- but is important enough to warrant its own discussion.
I will discuss 2 slightly related IDs in this proposal. The latter may only be of internal interest and possibly not exposed in any API, but time will show.
Content NodeID
Given this example content tree:
So, the different
_content.py
content adapters can, in general, prodce any ofI suggest something fairly simply that would fit nicely into a prefix tree for fast lookups:
The above have some nice features that we need:
/blog/post/index.leaf/
belongs to the same bundle. Which means fast prefix scans and inserts./blog/index.branch
belongs to the same section etc./en/
is English content.There are some open questions re language etc., but we'll sort out those details when that comes...
The above looks rather odd, and we can work on that, but this isn't something that you print on a T-shirt, so it does'nt have to be pretty.
The important part is that
/blog/index.branch
identifies the Blog section etc._content.py
will then also produce pages/resources with potentiallywith same IDs and will form some kind of composite relationship. We could probaly create a formal/custom definition for this, but I suspect that the default order of these will be 1: Content file 2: Content plugin and resources from 2: Will complement 1: (new files and metadata will be added), logically:Content SourceID
Today, when we get a change event for a content file, we do (little simplified):
That change event will be on the form
/Users/bep/sites/mySite/themes/content/blog/article/sunset.jpg
. Hugo has this clever concept of a big union file system, so that filename does not map directly where to find this object, so iterate all the module paths until we find one with a matching prefix (/Users/bep/sites/mySite/themes
) and then we walk up the directory tree to find the best directory to start walking from (blog/article
if it's a bundle).This works, and is not particulary hard to reason about.
But the above falls short when we start composing content from multiple sources, and these sources are either not files or they have filenames that do not map particulary well into the content tree.
The file
/blog/_content.py
may look something like this:So, when we get a change event for
/Users/bep/sites/mySite/themes/assets/data/content2.yaml
we need a way to rebuild from the owning node(s) without having to rebuild the whole thing.The text was updated successfully, but these errors were encountered: