Skip to content
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

Prevent generating folder & index.html for a specific page when "rendes = false" #2318

Open
wants to merge 26 commits into
base: next
Choose a base branch
from

Conversation

endesigner
Copy link

Adds front matter flag to prevent generation of page folder & index.html
discussion

Sanity check:

  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Code changes

  • Are you doing the PR on the next branch?

If the change is a new feature or adding to/changing an existing one:

  • Have you created/updated the relevant documentation page(s)?

#1356 may be related even though front matter flag that this feature provides must be applied to every page rather than whole section.

Keats and others added 25 commits March 19, 2023 20:37
* Reuse Client when checking urls and add timeout for requests
* Implement replace_re filter

* Cargo fmt

* add regex caching

* cargo fmt

* update docs, update unit test

* rename replace_re -> regex_replace
Relative links in the entry content do not currently have a base URI, so
will be resolved relative to the feed URI:

Given an entry with the content:

    <a href="some-resource.bin">

And URIS of:

 * entry: https://example.org/blog/some-entry/
 * feed:  https://example.org/atom.xml

The link URI will end up as:

    https://example.org/some-resource.bin

rather than the URI that ends up resolved in the rendered page:

   https://example.org/blog/some-entry/some-resource.bin

The atom and RSS formats allow for an xml:base attribute (itself
specified in [1]) to provide a base URI of a subset of a document. This
change adds xml:base attributes to each entry, using the page permalink.

This gives us something equivalent to:

    <entry>
     <content xml:base="https://example.org/blog/some-entry/">
      <![CDATA[
       <a href="some-resource.bin">
      ]]>
     </content>
    </entry>

[1]: https://www.w3.org/TR/xmlbase/

Signed-off-by: Jeremy Kerr <[email protected]>
* Fix multi-ligual json index

* multi-lingual search Fix cargo fmt
…tzola#2196)

* Add search into the serialized config (getzola#2165)

* Only expose index_format

* Create config.search struct

* cargo fmt
* Fix hard link panic and add better error info to std:fs errors

* cargo fmt

* Remove erroneously committed config change

* Remove console import; Use with context to provide additional error info

* improve error wording
* Add optional decoding="async" loading="lazy" for img

In theory, they can make the page load faster and show content faster.

There’s one problem: CommonMark allows arbitrary inline elements in alt text.
If I want to get the correct alt text, I need to match every inline event.

I think most people will only use plain text, so I only match Event::Text.

* Add very basic test for img

This is the reason why we should use plain text when lazy_async_image is enabled.

* Explain lazy_async_image in documentation

* Add test with empty alt and special characters

I totaly forgot one can leave the alt text empty.
I thought I need to eliminate the alt attribute in that case,
but actually empty alt text is better than not having an alt attribute at all:
https://www.w3.org/TR/WCAG20-TECHS/H67.html
https://www.boia.org/blog/images-that-dont-need-alternative-text-still-need-alt-attributes
Thus I will leave the empty alt text.

Another test is added to ensure alt text is properly escaped.
I will remove the redundant escaping code after this commit.

* Remove manually escaping alt text

After removing the if-else inside the arm of Event::Text(text),
the alt text is still escaped.
Indeed they are redundant.

* Use insta for snapshot testing

`cargo insta review` looks cool!

I wanted to dedup the cases variable,
but my Rust skill is not good enough to declare a global vector.
…atter (getzola#2237)

* Prevent spans crossing line boundaries in class formatter

* Add snapshot tests for classed highlighting
* sort page.assets by filename

Uses .to_str() to sort files and subfolders.

The .unwrap() may need work or be replaced by unwrap_or_default(). Given
earlier checks in the function it should work however.

* add tests for assets sorting

* fix rustfmt

* use existing loop instead of windows

* also check the non-recursive test

* use .zip() and add assert msg
* templates:atom: add support for multiple authors

Atom 1.0 [0] support multiple `<author>` entries in the feed. This commit
modified the template to generate as many `<author>` as the page's
metadata contains.

[0] https://validator.w3.org/feed/docs/atom.html#recommendedEntryElements

* Test we can have multiple authors in ATOM feeds
The `rel` and `type` HTML attributes are needed in the `base_url` (or
`section.permalink`) link so feed aggregators know that's the HTML page
that corresponds to the atom feed.

Note: The RSS template doesn't have this issue.
* use fs canonicalize to prevent path traversal

* fix cargo fmt
* Add ignored_static to config

* Make  handle ignored static files correctly

* cargo fmt

* Match on relative path rather than incorrect target path

* path -> partial path for serve static ignore

* remove debug println

* copy static directory if there is no ignored globset

* Update docs

* Deduplicate code with additional Option argument

* cargo fmt
* template:feeds: add extra block

* add missing >

* Revert "add missing >"

This reverts commit 45c6b9c.

* Revert "template:feeds: add extra block"

This reverts commit 596f7f1.

* Update docs for feed templates
)

* Introduce option to force directory when running the serve command

* Update documentation about the force flag on the serve command

* Resolve cargo fmt issue

* Reword new serve flag documentation
…etzola#2287)

The warning about unknown highlight languages was displayed even when
code highlighting was disabled via `markdown.highlight_code = false`.
This commit adds a condition to check this setting before issuing the
warning, effectively suppressing it when code highlighting is disabled.

Issue: getzola#2280
* Fixed "unnecessary mut" warning

* Fixed minor typo

* Use more than 8 threads for links checking if hardware supports it

* Fixed failing azure Linux check

* Avoid unnecessary HTTP requests to the same, already checked links
@endesigner
Copy link
Author

Any clue on the discrepancy of test runners?

@Keats
Copy link
Collaborator

Keats commented Sep 26, 2023

Not entirely sure

@@ -115,6 +115,10 @@ impl Page {
page.word_count = Some(word_count);
page.reading_time = Some(reading_time);

if !page.meta.render {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to still process slugs etc even if we don't render things?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Keats,

No, my intention was to stop processing of slugs, paths and sitemap entries if meta.render is set.

I assumed that, since parse() returns at this point, the job is done but your question makes me doubt that :) I'm not fluent in the codebase (or Rust for that matter) so if there are any other places where I should do the plugging please let me know.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's mostly a question of whether we want a fully populated page, except it's not rendered which I think is better?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's probably better to have the fully processed pages so if you query it in a template, you have all the info you need

@Keats
Copy link
Collaborator

Keats commented May 9, 2024

Something funky happened to the PR, can you rebase? Otherwise i'll take the commit directly on next

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet