search

getpelican / pelican

Static site generator that supports Markdown and reST syntax. Powered by Python.
https://getpelican.com
GNU Affero General Public License v3.0
12.52k stars 1.81k forks source link

Need to insert HTML comment of original content filename #2484

Closed egberts closed 5 years ago

egberts commented 5 years ago

This :Slug: else :Title: makes it harder to determine what the original content file name is. So, when you want to go back and edit the file, the output file name may not be similar enough with the content filename and the end-user is often forced to use grep tool to locate the original/content file.

The objective is to update each page with an HTML comment notation where the original content file is:

<title="slugified title">
<!-- content filename: article/original-filename.md -->

What is the variable name that has the original content filename so that it can be written into the base.html in form of

bryanbrattlof commented 5 years ago

Hi'ya @egberts, I was just doing this myself.

This isn't documented anywhere, nor is it setup like the other variables for use in the templates, so I guess it's a "use at your own risk" kind of thing, but article.get_relative_source_path() works for me.

It's a part of the base Content object so Page, Article, and Static have it when building.

Hope that helps.

egberts commented 5 years ago

Yep, that does it, @bryanbrattlof .

I inserted the following to the beginning of my template file, in this example article.html:

<!-- articles.html begins -->
<!-- source file: {{ article.get_relative_source_path() }} -->
{% extends "base.html" %}
{% block title %}{{ article.title }}{% endblock %}

And got the resultant output file:

<!-- articles.html begins -->
<!-- source file: articles/api-security-checklist.md -->
<!-- base.html begins, seeded by blog/articles/api-security-checklist.html  -->
<!DOCTYPE html>

Closing this as solved.

avaris commented 5 years ago

There is article.source_path which is documented.

bryanbrattlof commented 5 years ago

Thanks @avaris, I went with the relative path, mostly because I use gitlab-ci to build, which puts the content directory in a weird path (/builds/bryanbrattlof/<repository>/...) which makes the output a little long especially when you nest your content in more folders like I do.

/builds/bryanbrattlof/website/content/articles/2018/baseball-analytics/english.rst

But you are right, the best approach would be to use article.source_path if you need something more stable, and should have mentioned that.

Looking further I did see #2416 in the PRs but is this something we still want to include or have we moved on?

egberts commented 5 years ago

I too went with Bryan because I also emulated GitLab's funky top-level directory that results in a longer SITEURL for our blog's top-level directory.

Simple example supported is:

SITEURL=https://example.net/

The ideal but complex examples that I am trying to get supported are:

SITEURL=https://example.net/blog
SITEURL=https://gitlab.com/builds/egberts/<repo>

As a result, I've had to make an extension to the SITEURL:

SITEURL = 'https://example.net'
SITE_SUBPATH = 'blog'
RELATIVE_URLS = True if developing_site else False
SITE_DIR = ''
SITE_URL_TOP_LVL = '/'   # do not use double-slash here
if len(SITE_SUBPATH):
    # Do not let SITE_DIR be an absolute file path    
    SITE_DIR = SITE_SUBPATH + '/'
    if RELATIVE_URLS:
        SITE_URL_TOP_LVL = '/' + SITE_SUBPATH + '/'
    else:
        SITE_URL_TOP_LVL = SITEURL + '/' + SITE_SUBPATH + '/'

And prefix in all the various variable names using either SITE_DIR or SITE_URL_TOP_LVL