Is it possible to do pagination by oldest to newest for posts?

[honeyedoasis]

Just wanted to check if there was a way to do this before making a pull request.

---

As for the pr, I am planning to hooking up this reverse parameter in this sorted call

mkdocs-material/src/plugins/blog/plugin.py

Line 136 in 34ec8b4

reverse = True

[squidfunk]

Thanks for offering! We currently have a feature freeze due to the foundational work we're currently putting all our efforts in. Since this touches all areas of Material for MkDocs, we decided to temporarily stop adding more to the API surface that we might need to reconsider afterwards. If you decide to create a PR, please understand that we can only consider merging it once we're done with the foundational work.

I hope my reasoning makes sense, and hope for your understanding.

[kamilkrzyskow]

In the mean time you could hack it with a hook. You can access the loaded functions and instance after it has been loaded, then after on_files re-sort them again to fit your liking.

This is something which I have often done when extending the blog features in the mkdocs-nype theme:

• custom_blog_categorization example
• similar_blog_posts example

At this point I'm not sure if I figured it out myself or if I first saw it in the i18n plugin first, so I will give credit there.

The blog plugin executes on_files with a delayed priority of -50, so your hook would set it to -75 or -100 to change the order after the blog fills in the data structure of blog_instance.blog.posts

Or in on_config you could monkey-patch the loaded on_files function of the blog plugin. Note that you can't monkey-patch it directly via import chain, as the reference to the original has been loaded in MkDocs, you need to modify it in config.plugins.events
An example how to access that can be seen here, and the new replacing function would of course need to copy the whole functionality of the previous one, while making the change you want.
This would enable better performance, as the replaced function would sort it correctly immediately.

I would say that the first approach is good enough here, as we don't have to care for performance that much.

[honeyedoasis]

Wow thanks for the details!! I got it working with the second method of overriding on_config. The config.plugin.events thing was very confusing indeed haha.

This method has really unlocked a lot of potential modifications 😃

Code here: https://gist.github.com/honeyedoasis/4c4077d61595d2666664dce00c77734a

[squidfunk]

Oh wow, monkey patching entire plugins – @kamilkrzyskow, you really know your way around MkDocs 🤟 To the interested reader: note that this requires you to check every release whether the source of the plugin changed, or behavior may be undefined, but as said, we're in the process of making this easier. In the meantime, this is a good workaround!

[kamilkrzyskow]

I tend to use pinned version of python modules mkdocs-material==9.5.49, and tend to update when the need arises, so I rarely need to test for regressions of such monkey-patches. I could be biased based on the feature freeze here and in the MkDocs repository, which didn't change the logic of related parts, so I don't remember the maintenance to be tedious. However, it's worth noting that using a hook is sort of a commitment to maintain it along the way, as it's more "personalized" than a plugin.

Code here: https://gist.github.com/honeyedoasis/4c4077d61595d2666664dce00c77734a

Thanks for sharing your solution, I've noticed the plain blog_plugin: BlogPlugin = config.plugins.get("material/blog") or config.plugins.get("blog"), which would only work on the first BlogPlugin instance. Nype websites tend to use more blog instances, so I consider a loop like shown in the examples a better alternative https://squidfunk.github.io/mkdocs-material/plugins/#multiple-instances
The BlogPlugin of the Material theme will be always scoped to material/blog, blog won't work unless you use an external plugin with this entry point.

This method has really unlocked a lot of potential modifications 😃

Oh wow, monkey patching entire plugins – @kamilkrzyskow, you really know your way around MkDocs 🤟

There is also the next level, which I've figured out when working on the mkdocs-nype theme.
MkDocs loads/imports relevant modules in this order:

1. Theme
2. Plugins
3. Hooks

Before working on the theme, I have always used hooks, so I had to use the monkey patch during the event loop.
This was less than ideal in some cases, so during the theme import I monkey patch the BlogPlugin directly together with a BlogConfig extension.

I haven't tried it myself, but going with this logic, one could use a plugin which does the same thing. Plugins are loaded in a loop, so it should be possible to achieve the same result as the theme __init__.py, with a correct order of plugins in the plugins list/mapping

plugins:
  - search
  - monkey_patch_blog_plugin_before_its_loaded_into_mkdocs
  - blog

[honeyedoasis]

Thanks for sharing your solution, I've noticed the plain blog_plugin: BlogPlugin = config.plugins.get("material/blog") or config.plugins.get("blog"), which would only work on the first BlogPlugin instance.

That's a good point, I was planning to add multiple blogs too!

Updated with:

def on_config(config: MkDocsConfig):
    blog_plugins = [(name, p) for name, p in config.plugins.items() if isinstance(p, BlogPlugin)]

    for blog_name, blog in blog_plugins:
        for i, event in enumerate(config.plugins.events['files']):
            if hasattr(event, "__self__"):
                if event.__self__ is blog:
                    config.plugins.events['files'][i] = types.MethodType(patch_on_files, blog)
                    print(f'sort_posts_latest: Patching {blog_name}')