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

Create digest page from Wireframe #86

Open
3 of 6 tasks
MirandaEcho opened this issue Feb 18, 2020 · 7 comments
Open
3 of 6 tasks

Create digest page from Wireframe #86

MirandaEcho opened this issue Feb 18, 2020 · 7 comments
Milestone

Comments

@MirandaEcho
Copy link
Collaborator

MirandaEcho commented Feb 18, 2020

ENN Digest Page Wireframe (1).pdf

  • Create template (if not done already)
  • Text area at top for description, link to FAQ page (pending link from ENN)
  • Add search to top
  • List of posts under search
  • Set up widget areas
  • Insert widgets in sidebar
@MirandaEcho MirandaEcho added this to the FRES-011 milestone Feb 18, 2020
@benlk
Copy link
Collaborator

benlk commented Feb 18, 2020

Status:


The problem with the widget areas is as described in #77 (comment):

For unknown reasons, creating a sidebar named "Digest Sidebar" in Theme Options > Layout > Sidebar Options, and saving that sidebar in the sidebar picker at Posts > Categories > "Digests" > edit > Archive Sidebar, results in that sidebar not being found by the elaborate fallback queue in sidebar.php, and as a result the sidebar is not output.

The expectation was that we'd be able to use existing Largo functionality to create a named widget area and output it only on this page.

Instead, that named widget area is not output upon the page.

It is not known why this is the case.

Our options are:

  1. try to debug the thing
  2. hardcode it so that this template only ever shows the hardcoded sidebar, which I'll call "Digest Sidebar", with the effect that the setting in the Digest category edit page is silently ignored

1 has an unknown amount of time. 2 makes things weird in a way that might confuse the client, but shouldn't take more than an hour.

@MirandaEcho
Copy link
Collaborator Author

I thought we had decided to hardcode it given the difficulty, so let's go ahead with that.

@benlk
Copy link
Collaborator

benlk commented Feb 19, 2020

Screen Shot 2020-02-19 at 16 41 06

@MirandaEcho I'm guessing that we should add some padding to these textwidgets?

@MirandaEcho
Copy link
Collaborator Author

@benlk - yes please. We didn't budget any fancy styling, but some basic cleanup would be good. Lets remove the border and make the button match the other button in the sidebar, at least.

Also, what's up with the description/title for the subscribe widget and all that extra text there?

@benlk
Copy link
Collaborator

benlk commented Feb 19, 2020

In that screenshot, I used a Ninja Forms widget. The extra text is what the widget was configured to output.

We should ask them if they're using Ninja Forms for the mailchimp signups now rather than the ENN Mailchimp Subscribe widget we built them.

@benlk
Copy link
Collaborator

benlk commented Feb 20, 2020

The default style of the widget is to have padding and border; it looks like Largo removes the padding at certain viewport sizes:

https://github.com/INN/largo/blob/1744bbc7ae99f501129d158c3b585cddf6b5409e/less/inc/widgets.less#L214-L222

The theme contains a style that removes the borders when the widget has the "Reverse" background class applied, so not removing the border here is more-respecting of the existing styles.

@benlk
Copy link
Collaborator

benlk commented Feb 20, 2020

There's CSS being injected via the Customizer that makes the Ninja Forms button wider than the column on some screen sizes:

#nf-field-33 {
  padding: 0.75em 2.3em;
	margin: 16px 0 0 0;
}

And a lot of other CSS affecting the Ninja Form.

Here's where I ended up at on Desktop:

Screen Shot 2020-02-19 at 20 15 21

And on Mobile:

Screen Shot 2020-02-19 at 20 15 45

These changes try not to have an adverse effect on the article pages, which have different layouts for that text.

But the fact of the matter is, the Ninja Forms widget has weird markup that makes it hard to guarantee that the input won't go beyond the container, because an input type="button"'s text content isn't text, but instead its value attribute. The CSS rules for wrapping text don't apply.

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

No branches or pull requests

2 participants