Use the latest page update time instead of the current time
Now the date of the gzip file will change only once per day, based on the pages' update date. The sitemap.xml itself also changes once per day already.
The "get-deps" command will still be provided inside MkDocs like before (and is not deprecated at all) but is now implemented in a separate repository and can be used directly from there as well.
This separation of code was done because obtaining just the "get-deps" part with very few dependencies can be useful: one can run it in a main environment but then install actual MkDocs with dependencies in a virtual environment.
If a Markdown extension immediately resolves the path inside its initialization (rather than just storing it for later as I was hoping) then it was failing the initial validation run that MkDocs does without populating an actual page yet.
Example message:
WARNING - Doc file 'dev-guide/themes.md' contains a link '../user-guide/configuration.md#google_analytics', but the doc 'user-guide/configuration.md' does not contain an anchor '#google>
It is not enabled by default. To enable, use config `validation: {anchors: warn}`
The implementation only detects Markdown anchors, not raw HTML anchors. As such it may have false positives.
```markdown
<a id="undetectable-anchor"></a>
## Detectable anchor
```
There are plans to improve that in the future.
But that's just about user-authored HTML.
As for HTML that Markdown extensions insert: it will also work correctly if they insert the HTML as etree elements and will never work if they insert it via `htmlStash`. Basically the same rules as for what `toc_tokens` is able to detect.
This was aimed at user-facing "file not found" errors from "serve" but it can catch errors from plugins as well, and it only makes the errors very confusing.
* If source page and destination page is excluded, cap log level to DEBUG
* If source page is excluded, cap log level to INFO
Co-authored-by: Chris Mayfield <mayfiecs@jmu.edu>
For every plugin, the user can set `enabled: false` (or something based on an environment variable) and it will not kick in at all.
If the plugin has its own `enabled` config, there's no change for it in that case.
If one config option completely fails validation, that means its value remains "raw" from YAML, which can cause unpredictable errors when validating other options that might look at the value. Instead just decide one error is enough.
