Using 4.7.0-dev, 404 pages have blank/empty <li> entries.

For example, non-existent section list: http://dev-demo.eu.textpattern.co/index.php?s=bogus-section-that-does-not-exist

Screencast attached in the zip file. I'll see if I can figure out what needs fixing.

SafariScreenSnapz001.mp4.zip

Is your feature request related to a problem?

No just a suggestion.

What is the feature?

For canonical links you could add this simpler solution recommended by @bloatware:

<link rel="canonical" href="<txp:page_url context trim="/" />">

Into all pages, never mind the context. Note the trim attribute needed here to reflect le current URL address scheme (for SEO).

STR: create few articles in, say, articles section and search for some common term on articles page: /articles/?q=a. The whole search results block is output for every article.

The reason: articles section uses archive page which has no search-specific code, so the default search_results form is used for every article.

Version 4.7.0 of webpack was just published.

The version 4.7.0 is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

It might be worth looking into these changes and trying to get this project onto the latest version of webpack.

If you have a solid test suite and good coverage, a passing build is a strong indicator that you can take advantage of these changes directly by merging the proposed change into your project. If the build fails or you don’t have such unconditional trust in your tests, this branch is a great starting point for you to work on the update.

Your Greenkeeper bot :palm_tree:

See discussion here: http://forum.textpattern.com/viewtopic.php?id=47366

Whilst my personal preference is still Schema.org microdata, I'm testing out JSON-LD as a possible replacement. Pros/cons of the change:

1. Pro: Google's Structured Data Testing Tool has become way too opinionated on what microdata is mandatory - leading to overly-complex HTML. They also break the spec and contradict Schema.org documentation on numerous occasions (e.g. publisher cannot be a Person on Google Testing Tool, but is allowed in Schema.org documentation).
2. Con: JSON-LD shares the above problem - so it won't lead to a reduction in code (in fact it leads to generally more code as you can't have multiple entry points in JSON, and also duplicates content already in the HTML).
3. Pro: Google has done a complete 180 and now recommends JSON-LD over microdata (they used to favour vice-versa).
4. Con: microdata is more human-readable than JSON-LD.
5. Pro: I can create a misc-type Form template to power JSON-LD in the page head.
6. Con: if you add in more images and/or file downloads via additional forms, we'll have to include additional JavaScript in the body of the page ad-hoc. More code bloat compared to HTML attributes (and not as tidy as I'd like - I'd prefer to house all JSON-LD in head, but that is impossible here).

Example JSON-LD for a blog individual article:

<script type="application/ld+json">
    {
        "@context": "http://schema.org",
        "@graph": [
            {
                "@type": "Blog",
                "blogPost": [
                    {
                        "@type": "BlogPosting",
                        "headline": "Blog example title",
                        "description": "This is where a blog article extract/description would be.",
                        "url": "http://textpattern.dev/blog-article.html",
                        "mainEntityOfPage": "http://textpattern.dev/blog-article.html",
                        "datePublished": "2016-01-21T10:43:39Z",
                        "dateModified": "2016-01-22T14:32:01Z",
                        "discussionUrl": "http://textpattern.dev/blog-article.html#comments-head",
                        "image": {
                            "@type": "ImageObject",
                            "url": "http://placehold.it/832x554",
                            "width": "832",
                            "height": "554"
                        },
                        "author": {
                            "@type": "Person",
                            "name": "Phil Wareham"
                        },
                        "publisher": {
                            "@type": "Organization",
                            "name": "Textpattern CMS",
                            "logo": {
                                "@type": "ImageObject",
                                "url": "http://textpattern.com/assets/img/branding/textpattern/textpattern.png",
                                "width": "320",
                                "height": "52"
                            }
                        },
                        "interactionStatistic": {
                            "@type": "InteractionCounter",
                            "interactionType": "http://schema.org/CommentAction",
                            "userInteractionCount": "3"
                        },
                        "comment": [
                            {
                                "@type": "Comment",
                                "author": {
                                    "@type": "Person",
                                    "name": "Joe Q. Public"
                                },
                                "dateCreated": "2016-01-25T16:55:03Z"
                            },
                            {
                                "@type": "Comment",
                                "author": {
                                    "@type": "Person",
                                    "name": "Phil Wareham"
                                },
                                "dateCreated": "2016-01-26T11:20:01Z"
                            }
                        ]
                    }
                ]
            },
            {
                "@type": "WebSite",
                "name": "Textpattern CMS",
                "description": "Textpattern CMS is a free, open source content management system with a browser-based interface in over 40 languages, excellent support and full range of features.",
                "url": "http://textpattern.dev/",
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": "http://textpattern.dev/?q={q}",
                    "query-input": "required name=q"
                }
            },
            {
                "@type": "Organization",
                "name": "Textpattern CMS",
                "url": "http://textpattern.dev/",
                "logo": "http://textpattern.com/assets/img/branding/textpattern/textpattern.png"
            }
        ]
    }
</script>

Hi,

this theme fetches two JS resources from their respective repositories: html5.js and css3-mediaqueries.js.

This imposes a few performance penalties. Read on here: http://zoompf.com/blog/2012/05/html5shiv-and-serving-content-from-code-repositories

Both resources from googlecode.com are delivered with this HTTP reply header:

Cache-Control: public, max-age=180, i.e. 180 seconds cache life time.

I think you should reconsider the distribution method.

Cheers,

Robert

Hi Phil, What do you think about this code to display article categories? Few more tags but much more readable…

In the article.default.txp form it would change:

<!-- only display categories if they are actually set for an article, otherwise omit -->
<txp:if_article_category>
    <br>
    <strong>
        <txp:text item="categories" />
    </strong>
    <span itemprop="keywords">
        <txp:if_article_category number="1"><txp:category1 title="1" link="1" /></txp:if_article_category><txp:if_article_category number="2"><txp:if_article_category number="1">, </txp:if_article_category><txp:category2 title="1" link="1" /></txp:if_article_category>
    </span>
</txp:if_article_category>

to:

<!-- only display categories if they are actually set for an article, otherwise omit -->
<txp:if_article_category>
    <br>
    <strong>
        <txp:text item="categories" />
    </strong>
    <span itemprop="keywords">
        <txp:if_article_category number="1">
            <txp:if_article_category number="2">
                <txp:category1 title="1" link="1" />,
                <txp:category2 title="1" link="1" />
            <txp:else />
                <txp:category1 title="1" link="1" />
            </txp:if_article_category>
        <txp:else />
            <txp:category2 title="1" link="1" />
        </txp:if_article_category>
    </span>
</txp:if_article_category>

Thanks for your work!

Pages and forms have filenames ending .txp and I propose they should be renamed .html, per @gocom's advice here: http://forum.textpattern.com/viewtopic.php?pid=276862#p276862

I raised this because I'm making a public theme and I wish to follow policy where possible, and it follows that the default theme should follow the preferred naming convention.

Textile supports block modifiers for horizontal alignment: !<foo.jpg!, !=foo.jpg!, !<>foo.jpg!, !>foo.jpg!. From version 2.3 on it uses four classes to indicate image alignment when it renders a HTML5 document:

• align-left
• align-center
• align-justify
• align-right

I think the theme should include style rules for those.

Out of the box, Textpattern doesn't include OpenGraph elements in head. This means Facebook and the like use best-guess to populate article summaries, and it looks a bit wonky.

As of 4.6.2, the default looks like this:

My site: Welcome to your site
Welcome to your site Posted Aug 29, 12:00 AM Comments 1 What do you want to do next? Modify or delete this article? The article list is the place to start. Change this site’s name, or modify the style of the URLs? It’s all up to your preferences. Get yourself acquainted with Textile, the humane mark...

Is OpenGraph in scope for some sensible defaults? Maybe paring back the description (and improving readability) by specifying the article excerpt or first paragraph of the body, removing the posted date, and removing the number of comments.

I really, really like the metadata included in the default theme…so much so that I use it for cribbing on new builds. Basic OpenGraph would be sufficient to make a Facebook share more likely, and it need not be overly complex.

Changes:

• Webpack
• AutoBuild/Repair manifest.json, if need. Data is taken from /src/templates/manifest.json(if exists) or /package.json or used default.

@philwareham please check the file /dist/default_theme/default.css there are differences associated with autoprefixer, but I do not know how critical they are.

Bumps stylelint-order from 5.0.0 to 6.0.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps stylelint from 14.16.0 to 14.16.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps sass from 1.56.2 to 1.57.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Is your feature request related to a problem?

Kind of (regarding best practices).

What is the feature?

The current image rendering model does not check for the existence of associated alt text:

    <p itemprop="image" itemscope itemtype="https://schema.org/ImageObject">
    <img loading="lazy" itemprop="url contentUrl" src="<txp:image_url link='0' />" alt="<txp:image_info type='alt' />">
    <meta itemprop="width" content="<txp:image_info type="w" />">
    <meta itemprop="height" content="<txp:image_info type="h" />">
    </p>

Perhaps this is room for a small amendment (use of a hyphen is acceptable in terms of SEO practices)?

    <p itemprop="image" itemscope itemtype="https://schema.org/ImageObject">
        <img loading="lazy" itemprop="url contentUrl" src="<txp:image_url link='0' />" alt="alt="<txp:evaluate query test='<txp:image_info type="alt" />'><txp:image_info type="alt" /><txp:else />-</txp:evaluate>">
        <meta itemprop="width" content="<txp:image_info type="w" />">
        <meta itemprop="height" content="<txp:image_info type="h" />">
    </p>

As suggested by @bloatware here: https://forum.textpattern.com/viewtopic.php?pid=332047#p332047

Is your feature request related to a problem?

Nope!

What is the feature?

Maybe it's the time to add a "Dark Mode" support into the Default theme? Simply because it's a user choice, after all.

Here is a simple way with few lines of CSS:

@media (prefers-color-scheme:dark) {
    html{background-color: #000}
    body{filter: invert(100%)}
    header *,header a,footer *,footer a{filter: invert(0%)}
    img{filter: invert(100%)}
}

Note: changing heading links color, gives a little darker white on "Dark Mode" but keeps a good contrast ratio on "Light Mode":

h1 a,
h2 a,
h3 a,
h4 a,
h5 a,
h6 a {
color: #333;
}

Expected behaviour

No TXP warnings when Number of extra parser sweeps (Admin -> Preferences -> Advanced options) is set to 0

Actual behaviour

TXP preventing errors located into the search_display form.

Steps to reproduce

Set Advanced Preferences Number of extra parser sweeps to 0 value.

Additional information

As explain by @bloatware on the forum (see: https://forum.textpattern.com/viewtopic.php?pid=332178), the search_display form need some amendments:

<h1 itemprop="name"><txp:text item="search_results" /></h1>

<txp:search_result_count />
<txp:article[1] pgonly="1" pageby="10" />
<txp:if_search_results>
[...]