multi blog instances share the same `post_date_format` date filter about mkdocs-material HOT 8 CLOSED

So given that the Post/Page object should have a reference to the File object is there a way to get the Blog instance?

Currently not. The thing is: you don't want the blog instance, which is a View, a subclass of page, you want the blog plugin instance to access the formatting capabilities. I don't think it's a good idea to pass the plugin instance to the template, since template authors could call hooks from the template, potentially leading to infinite loops. I've lately started to implement far more modular plugins, and the blog plugin is a good candidate to switch to the same approach, factoring out the formatting capabilities, but I currently have no bandwidth to do it, as I'm working tirelessly on very big upcoming changes (still tba).

Given File.generated() this is outdated ✌️:

Correct. We can definitely switch to the new File.generated API, but I'd consider it a very low priority issue, since everything works the same right now, so why change something that currently works nicely 😉

from mkdocs-material.

Additionally, when making this reproduction, a very odd thing happened. Even though I've set the movies examples to 2018 and 2011 in the files, they display as 2018 and 2010 when rendered on the website. First was floating point imprecision and now date imprecision 😆

from mkdocs-material.

Thanks for reporting. Hmm. I think this one will be very hard to solve, since we cannot guarantee a specific environment for each blog page. Thus, I'd say this is currently unfixable with the architecture of MkDocs, as all plugins have to go through on_env, and it's not possible to scope the environment to specific pages.

from mkdocs-material.

Note that what you proposed, i.e, attaching a date filter explicitly to a blog post is a pattern that is not encouraged by MkDocs. Thus, opening a discussion upstream might be the best idea. I'm tagging this as not feasible for now. This must be taken upstream in order to find a way how to register rendering environment extensions per page.

on_env only allow to alter the global environment, not on a per page basis, and on_page_* does not receive env (see diagram), which is mutable anyway, so side effects all the way up/down. Thus, upstream.

from mkdocs-material.

Hmm, when you mentioned on_env for each page, I thought of on_page_context. I'm not sure if a filter needs to be defined via env.filters to work with the | filter syntax, would have to check if it works with any variable available, also I'm not sure if the event isn't skipped for the posts.

Aside from that I don't think there is a need for on_env for each page 🤔
Considering that in the blog plugin each structure class Post, View etc. extends Page and later adds custom properties to them I would say it has long passed the point of "pattern that is not encouraged by MkDocs", but to your point is there any docs where MkDocs truly actively discourages a specific approach?

File.generated_by was accepted as a valid marker with the release of 1.6.0, and before it was just a convention. Just like File.page and Page.file have a sibling connection, I would promote the same for GeneratorPlugin.page and Page.generator 😅

So if my approach with

post.config.date.created | post.blog.date_filter

isn't feasible, because it uses a filter through a chain of references that are attached to a post, then how about this:

def get_creation_date(post: Post):
    # Using the blog plugin reference from the post
    format = post.blog.config.post_date_format
    return self._format_date(post.config.date.created, format, config)
env.filters["post_creation_date"] = get_creation_date
env.filters["post_update_date"] = get_update_date  # omitted the definition above

post | post_creation_date

Yet another idea to work around it would be to save the post_date_format in the front matter / config of the Post
Later on set it inside the template in the context set post_date_format = post.config.post_date_format
And later pass the context to the filter, but I'm not sure if using the @pass_context decorator would be enough.
Use the post_date_format from the context 🤔
That's probably my least favourite solution to this issue, too many sequential disconnected actions.

from mkdocs-material.

I'm not sure it's worth the trouble breaking out of the canonical way to do this in Jinja. If you can come up with something that lends itself to the way MkDocs exposes the functionalities to plugin authors, and which doesn't "feel" (too) off, we can consider it, but I currently have no bandwidth to explore this 😅

Additionally, registering additional filters is something we "just" do, but which is not mentioned in MkDocs documentation anywhere whatsoever, so I think it's worth raising this over at MkDocs, i.e., how the maintainers would recommend registering additional template filters, potentially scoping environments to different pages/sections. Given that Tom has started a major rewrite of things (sharing progress in his Insiders repository), it is probably a very good time to discuss this with him, so he can consider it for his design and implementation ☺️

from mkdocs-material.

I've tagged this as upstream now ✌️

from mkdocs-material.

I wrote the Issue upstream, I've considered another one to ask about extending the generated_by of the File object to the Page object itself. However, the Page object by default has a reference to the File object, even if it's virtual, so I guess this is not needed.

So given that the Post/Page object should have a reference to the File object is there a way to get the Blog instance?
I initially thought, that it's not possible as the generated_by value is a string with the name of the plugin material/blog.
However, during my testing it turned out that each next instance of the blog has a number in the name material/blog #2 etc.

So given that the now non-hacky approach of using the external File.generated() constructor would properly set the unique name with the number it would be possible to get the blog instance via config.plugins[post.file.generated_by], but still the template would have to be modified to include a post aware filter, so let's hope MkDocs will extend on_page_context with env.

Given File.generated() this is outdated ✌️:

from mkdocs-material.