automattic / newspack-theme Goto Github PK

Add a section in the header to display 'breaking' news.

Should this always be news, or could it also be a text string? The cohort asking for it also expressed an interest in using it to draw attention to newsletter and membership campaigns, though we might want to differentiate the two but have opportunities for both.

Is there a special approach we need to take for dismiss-able messages and AMP?

Example from Washington Post:

Filing a separate issue for this comment from @jeffersonrabb in #49, just so it doesn't get lost when that PR is merged:

Regarding the new script defined in package.json, if there are going to be loads of style packs we'll need a new script definition for each one, which seems like an easy thing to forget to do. I'm wondering if we can cook up a build process that automatically iterates over all directories in /sass/styles and processes all based on the same rule. Since there's only one there's absolutely no reason to worry about this now, but I'll investigate this a bit and possibly file a new PR.

Twenty Nineteen has some cool functionality with the comments, where it displays a stacked set of avatars next to the comment count.

This can be removed from the header area of single posts, and from the comment area.

• Comment count overlaid at the top
• Comment avatars stacked next to the actual comments.

Would be good to explore the headline treatment in Style D a bit more, as a means of brand expression (cut into image; overlay; transparency).

Also consider if this is something that should be on the theme style level, or the block style level.

The base theme we're starting with, Twenty Nineteen, displays a large featured image at the top of single posts, with the post title and meta overlaid on top. Example:

https://2019.wordpress.net/?p=91

Though the theme's styles are not finalized, it's very unlikely it will include something similar. These elements can be separated in the theme, and the unneeded code removed.

Right now, the custom fonts added in #39 aren't inherited by everything in the Newspack blocks (eg. the post meta is always the default sans-serif font).

This may be an issue that needs to be resolved in the blocks to make the styles less specific - it needs more investigation.

Right now, the colour picker in the Customizer allows you to pick the colour hue, and the theme determines the saturation and lightness.

To give more control, the theme should instead allow picking a specific hex value -- that way you can match specific brand colours without them being slightly adjusted in saturation/brightness.

It still may need to break it down to HSL to create a darker shade of the colour for the editor.

Describe the bug
The currently used version of VIP Coding Standards is 0.4.0. This is out of date, and is not compatible with the latest versions of WPCS.

Expected behavior
Please use VIPCS 2.0, which was released a few minutes ago :-)

Make a 'sticky' navigation available in the theme; could use the 'shorter' menu designs mocked up in styles D and E, and used for the feature articles for style B and C.

Example: https://www.propublica.org/

The bare-bones style pack example added in #41 should also generate an enqueue editor styles, to give you a true WYSIWYG experience.

Depending on the layout, you may not always want to display the page title on the static front page.

Adding an option to the Customizer should make doing this easier, without having to actually remove a page's title, or remove the output fully from the page template.

Look into adding breadcrumb trail to theme.

What would the path be for articles (Home > category > story?). First dig into how these are typically handled on news sites.

@jeffersonrabb suggested removing the CSS files from the GitHub repo. Due to the style packs, editor styles and RTL styles, a lot of files are generated/changed for every basic style change (like fonts and colours).

Removing the files from the repo means that there will be less noise when reviewing PRs, and it will help avoid merge conflicts.

The CSS will still be bundled with releases, and generated locally when testing changes.

Describe the bug
In the Customizer, when I have a custom color selected, I get a flash of the color when the page is first loaded for .5 seconds, and then it all gets replaced with the default Newspack color. Selecting a custom color doesn't show the color in the Customizer, and it's always mighty blue all the time. On the site frontend, the custom color works great.

In the inspector, if I examine e.g. a Search button I see the default color is active:
style.css

.button, button, input[type="button"], input[type="reset"], input[type="submit"] {
    background: #2A7DE1;
    ...
}

At a lower priority (striked through in the inspector), my custom color is inactive:
http://{site}/?customize_changeset_uuid={uuid}&customize_theme=newspack-theme&customize_messenger_channel=preview-0

.main-navigation .sub-menu, .sticky-post, .entry .entry-content .wp-block-button .wp-block-button__link:not(.has-background), .entry .button, button, input[type="button"], input[type="reset"], input[type="submit"], .entry .entry-content > .has-primary-background-color, .entry .entry-content > *[class^="wp-block-"].has-primary-background-color, .entry .entry-content > *[class^="wp-block-"] .has-primary-background-color, .entry .entry-content > *[class^="wp-block-"].is-style-solid-color, .entry .entry-content > *[class^="wp-block-"].is-style-solid-color.has-primary-background-color, .entry .entry-content .wp-block-file .wp-block-file__button {
    background-color: #eab700; /* My custom color */
}

Potentially related to #52? (The issue happens without a style pack active in my testing, though)

To Reproduce
Steps to reproduce the behavior:

1. Go to Customizer
2. Set a custom color. Observe it doesn't preview.
3. Save. Refresh the page. Observe custom color is overriden by style.css.

Expected behavior
I expected the custom color preview to preview normally.

Prior to the work done in #17, the theme's allowed you to pick a single custom colour, and a darker hue would be generated to be used in some sections on hover, and to become available in the editor.

It was removed temporarily to simplify switching the theme from hue to hex, but should now be readded to work with the hex colour.

Mock up comments for the different styles.

Describe the bug
If you have less content in the sidebar, it won't fill the available space on smaller screens.

To Reproduce
Steps to reproduce the behavior:

1. Add one sidebar widget -- a good one is the search widget, but anything narrow -- say a Navigation widget with a menu full of short links -- will also work.
2. Make the screen narrow enough for the sidebar to stack underneath the primary content area.
3. Scroll down and view the sidebar.
4. Note it doesn't fill the available space.

Screenshots
If applicable, add screenshots to help explain your problem.

Expected behavior
100% wide elements -- the search, the widget headers -- should fill the available space when the sidebar is stacked on smaller screens.

Though the eventual plan for the theme is to have a header that can be customized, let's start by building out a basic fallback that allows a few different looks, just by how many menus you assign.

Here's a rough placement for the different elements (though the actual appearance will also depend on the current style).

Describe the bug
Once you've added and saved a Font Provider in Customizer > Typography, you can't delete it without getting an error:

However, if you have something in that field, the font is always loaded, even if you're not using it in any styles.

To Reproduce
Steps to reproduce the behavior:

1. Navigate to Customizer > Typography
2. Add a Font Provider URL.
3. Click 'Publish'
4. Empty Font Provider field.
5. Click 'Publish' again.
6. See error.

I think it would be enough to allow an empty value in this field again, or even have some kind of Default/Custom toggle (like the custom colours) so you can keep filled in options saved, but still turn them off.

This issue came up in #49 -- from @jeffersonrabb:

Ideally we wouldn't have to muddy the theme with styling for one specific block (.wp-block-newspack-blocks-homepage-articles) especially one that isn't core. I know TwentyNineteen has plenty of styles for .wp-block-image and others, but it feels a little different when we're talking about a non-core block even though there's a strong assumption that block and theme will be paired. Could there be a more general way to do this, where the styles are applied based on a semantic tag, or maybe an additional style (.use-body-font or something?) is defined and then applied in the block?

Though we can fix the specific issue being discussed there by using a semantic tag, it will still be an issue for other areas of the theme/block styles -- copying over my comment:

For other kinds of styles -- like the underline in #42 -- that might be better handled with a special class, but we still might end up with block-specific styles in the theme for weird cases, like to get it displaying correctly in the editor 😕 I'm not sure the best approach there -- maybe a separate stylesheet? Or turn it into a block style, instead of something that would be in the theme?

I'm opening up this issue so we can discuss our approach further -- it would be great to keep the styles in the theme more generic and lightweight, or at least have some tidier way to deal with custom block-specific styles.

Need to look into more social links and calls to action for sharing:

• Add links underneath the article as well, with a call to action text
• Is it possible to add links to blocks, like the pullquote block (or move to https://github.com/Automattic/newspack-blocks).
• Investigate other possible locations (floating? May be best suited to the 'feature' stories)

• Ability to have 'see all topics'-type links in the menu, so not everything has to be listed out.
  • This could be approached though Custom Links, and custom classes on those links to visually distinguish them from the rest.
• Ability to show descriptions in the menu -- example from Propublica's 'Series' dropdown -- could be technically handled through menu descriptions, but the theme will need to output them.

Explore not hiding all of the menu links underneath a 'Menu' toggle on mobile -- it could be that there's double-level header, or some other visual approach, that has a bit more room for this.

This would help highlight more important links, and not rely on a second click to get to them.

Currently the content area of the 404 and no results pages looks like this:

It needs some refining, including making the search smaller.

The theme has already been updated to centre the content, for simplicity as a starting point for a actual new design.

The editor styles should also be updated to match -- right now the content is still slightly offset.

The custom fonts added in #39 should also be included in the preview editor. So both the font CSS and styles to enqueue the fonts themselves need to be added there.

Add logo resizer functionality to theme; adjust logo styles as needed.

Add styles to the single articles to use for columnists that highlight the author, and optionally their focus area. Example.

Describe the bug
The build process we're using for the theme turns the Sass files into CSS files, and then generates RTL styles from those CSS files.

When you run the build when there are no CSS files yet, you'll get errors because the RTL styles can't be created, since there's nothing to create them from.

This is easy to work around locally -- you just run npm run build twice, or if you're running npm run watch, let it error out and resolve itself.

However, it could be a problem for building releases as it works now.

To Reproduce
Steps to reproduce the behavior:

1. If you have them, delete the CSS files that are turned into RTL styles (right now they are style.css, styles/style-1.css, and styles/woocommerce.css.
2. Run npm run build.
3. Note the following errors in the console:

Error: ENOENT: no such file or directory, stat '/var/www/build.newspack.test/public_html/wp-content/themes/newspack-theme/style.css'
Error: ENOENT: no such file or directory, stat '/var/www/build.newspack.test/public_html/wp-content/themes/newspack-theme/styles/style-1.css'
Error: ENOENT: no such file or directory, stat '/var/www/build.newspack.test/public_html/wp-content/themes/newspack-theme/styles/woocommerce.css'

4. Run the npm run build again.
5. Note that all the files build correctly the second time.

Brought up in #76 by @jeffersonrabb:

Where is the dek text drawing from, and how can I get set up to view that?

This needs to be figured out. If we can turn the "post meta" (byline, date and shares) into a block, it can be a paragraph, with a paragraph style we set. If not, we might have to go a custom field route.

I've seen the Custom Excerpt used for something similar (Twenty Sixteen as an example), but that would show up on the homepage and archives, and the same content probably wouldn't make sense in the two different contexts.

Explore some richer ways to display related content - example from NY Mag:

Can probably pull off now with the Newspack Blocks, but would be good to put together some visual examples.

Right now the homepage mockups are either strong on images, or no images. It would be good to do something in the middle, to show how things hold up with more of a mix.

The bare-bones style pack example added in #41 should also generate an enqueue RTL styles, so they're used for RTL languages.

This issue is to track the potential need for additional ad spots in the Newspack theme:

There are spots ads can be added without editing the theme, like below the content and at the top and bottom of the sidebar.

Ads can also be added by using widgets, or added to the content area using block we're currently developing.

This leaves spaces outside of the content area, and dynamic pages like:

• Archive pages - like category, tag, author, and custom post type archives; content is currently not editable, as it's all dynamically generated. Will have a widgetized sidebar.
• Blog posts page - similar to the above, the page that shows all of the posts on a site. Content for the most part is not editable; since it is an actual page when not set to the front page, we can update the theme to output the_content before the posts are displayed, but can't edit the post output. Will have a widgetized sidebar.
• Search results - content is currently not editable. Will have a widgetized sidebar.
• 404 page - uses a template with static content; can't be edited via WordPress.
• Image/attachment - all page content is dynamically generated, so can't be edited via WordPress.

... and the header and the footer.

For the dynamic pages, if we can't hook into things dynamically, we could manually add hooks to the theme.

For the header and footer, potential spots include above and below the header, and above the footer.

Have an area for navigation that highlights specific topics or stories, prefaced with a label.

Example from Mother Jones ("In the News"):

Example from Rivard Report ("Don't Miss"):

Describe the bug

When editing the "Site Identity" section in the Customiser it's possible to choose to hide the site title by unchecking the "Display Site Title" box. However, the change is not reflected in the customiser. The change is reflected outside of the customiser, however.

To Reproduce
Steps to reproduce the behavior:

1. Go to Customiser
2. Open the Site Identity section
3. Add a site logo
4. Uncheck "Display Site Title"
5. Observe that the logo is present but site title remains
6. Click Publish
7. Exit Customiser and go to the front page
8. Observe that the logo is present, but not the site title

Screenshots

I initially saw this on my own staging site:

but also reproduced in my local Newspack dev environment:

Expected behavior

In Customiser, the Site Title should disappear when "Display Site TItle" is unchecked.

The theme should have at least one more custom colour option in the customizer.

This colour should behave the same as the existing colour: it should show up in the editor, and a variation with a darker shade should be automatically generated.

This colour should also be applied to some existing elements (links, menu, or buttons).

Twenty Nineteen includes font fallbacks for a number of non-latin languages, which is important for a default theme.

For our purposes, however, it's not necessary to cover all of those possibilities in the theme's default settings. These font fallbacks should be removed from the theme.

In the preview, if the styles define different fonts or colours, they override the custom fonts and colours in the Customizer preview.

This is because, in the preview, the style pack styles are enqueued via JavaScript, and at the very end of the header. Any styles that come before it are overridden.

I'm not totally convinced we need to include colours/fonts in the style packs, but this would be a nice thing to fix.

Steps to reproduce:

1. Navigate to Customizer > Style Packs, and pick Style Pack 1.
2. Navigate to Typography, and set up a custom typeface.
3. Note it's not previewing.
4. Navigate to front end; note the style pack and typeface is correct.
5. Navigate back to the customizer - the font will not be wrong.

This isn't exactly a theme issue, but this seems the best place to track it for now:

We currently have one site in the cohort group that has an audio player that 'sticks' once you start playing it, and will follow you around as you navigate the site without interrupting the audio.

Hoping we can use what's already been built for this site, and integrate it into the theme.

In #71, a sidebar section was added to page.php without my considering that that file is also used for the front page. So if you add a widget to the sidebar, it also displays below the front-page content at full width:

Create an article mockup that includes embeds, to showcase more content.

Create a mockup showing what the flyout menus look like.

Would be good to work in things like 'More X' links, and descriptions, as described #85.

Mock up the links (regular, focus, hover) for all the different styles.

The Newspack theme's header is kind of complex, so I wanted to list out the requirements in an issue so I can keep track of it. The tasks listed here will likely grow longer, and may at some point be broken out into separate issues where it makes sense.

• Build base styles for desktop
• Build base styles for AMP (mobile and desktop) - started in #120
• Build non-AMP styles and behaviour for mobile menu
• Make sure non-mobile menu works well on touch devices - AMP
• Make sure non-mobile menu works well on touch devices - non-AMP
• Add 'header background' toggle and add styles
• Add 'logo center' toggle and add styles (related exploration #72)
• Add 'shorter' toggle and add styles (related exploration #72) - PR pending in #119
• Add 'overlap' toggle and add styles (related exploration #72) have opted to move this to the style pack -- see discussion in #112
• Add 'overflow' offscreen menu, both for sections and for menus not shown in some cases (like the 'shorter' simplified menu).
• Add search icon and ability to toggle the search - PR pending in #116
• Test/fix/add custom colour support
• Test/fix/add custom typography support

Some related issues:

Needs Design: #89, #85

Enhancements: #90, #88, #84

The strings marked for translation throughout the Newspack theme should be escaped, to follow best practices for WP.com.

Some newsrooms have a wide variety of content types (longform investigations, shorter follow ups, medium-sized stories, standalone data interactives...). The homepage blocks should have the ability to differentiate between these different types of reporting.

Note: may be more of an issue for the Newspack Blocks, or something that can be address through both.

Investigate an optional second level of menu, similar to The Guardian:

Question: will it work with the current headers?

Some publications group stories under beats; other under projects/series. How can these be differentiated on the homepage?

Consider adding a description for each homepage section's beat/project/series.

Also, what should topic landing pages look like?

Note: parts of this issue may make sense to move to the Newspack Blocks repo.

• How will they be 'grouped' (category)?
• Need ability to edit an existing archive page, or does it make sense to create static pages? Explore options for best approach.