Skip to content

Loading…

Display _s_posted_on Content Programatically #177

Closed
wants to merge 2 commits into from

4 participants

@BFTrick

Right now the _s_posted_on function prints out the same content no matter what page you're on and the theme uses CSS to determine which content to show or hide. We should change this so that the _s_posted_on function programmatically determines which content to display and the CSS just styles the content.

@sixhours

I do see your point, though this makes it harder for less PHP-savvy users to alter the theme to display the author all the time if they so choose. Overriding the byline display with custom CSS in a child theme or plugin is easier, and it keeps the code simpler in template-tags.php. It's a toss-up for me.

@andrewryno

I would expect a large majority of _s users to be PHP-savvy, especially when it's a simple if/else. It's a starter theme meant for theme developers.

+1 on this change from me. Personally I don't remember the last theme where I didn't change this myself anyway. Using CSS to optionally display content is bad practice, IMO.

@philiparthurmoore

This will probably make supporting users who want to tweak their themes with CSS only a lot harder. For example, authors of single-author blogs who want their names always displayed on all views (home, archive, etc.) versus those who don't. In hosted environments like WordPress.com, where PHP manipulation isn't an option, only custom CSS will work as a suitable solution for supporting users' customization demands on themes created with _s.

@BFTrick

Excellent point @philiparthurmoore . Just curious, are there a lot of authors that know they can manipulate the CSS in that way?

@philiparthurmoore

Just curious, are there a lot of authors that know they can manipulate the CSS in that way?

Yes. Custom Design is how theme customization is supported on WordPress.com and it's used by a lot of users (like a lot a lot).

@BFTrick

Interesting. Let me rephrase a little: Do users know that you can make that specific element visible? If a ton of people do it then it seems silly to implement this.

@philiparthurmoore

Do users know that you can make that specific element visible?

It's not that they know or do not know. It's that they ask for it, and we have to figure out a way to make it happen. CSS is the best answer. Questions like, "Why is my author name not showing like when I was using [some other non-_s-based theme that shows author names always]?" come up all the time.

@andrewryno

How many themes/blogs on WordPress.com use _s? My thought is that underscores is promoted with: "I'm a theme meant for hacking so don't use me as a Parent Theme." Why should a change not be made because it would stop people from overriding it using a child theme CSS (or any other custom CSS)?

@philiparthurmoore

How many themes/blogs on WordPress.com use _s?

I'm assuming you mean _s as a starting point. I could probably answer this at some point in the next week or so; we need to put a marker in style.css for a number of _s-based themes on WordPress.com and it's still an open Trac ticket.

My thought is that underscores is promoted with: "I'm a theme meant for hacking so don't use me as a Parent Theme." Why should a change not be made because it would stop people from overriding it using a child theme CSS (or any other custom CSS)?

_s is a starter theme meant for hacking, to be sure, but it doesn't mean that other considerations shouldn't be taken into account, like 1) what happens when you have a hosted environment with a lot of themes based on a starter theme; 2) what happens when a user wants to make a visual change to his/her site that can only be achieved with either manipulating PHP or either hiding/displaying things with CSS?; and 3) which is harder: adding markup back in at the start of every project or taking it out?

It's too much trouble on our end to add markup back or remember to do it with every single theme project that starts from _s than it is for you to remove it, and that doesn't even address the statement of "Using CSS to optionally display content is bad practice, IMO."

@BFTrick

@philiparthurmoore Thanks for the info. Makes sense why you would choose to leave it as is. :)

@andrewryno

Even if there is a large number of themes on .com that use _s as a starter theme, I'd also be interesting in how many keep in the .byline { display: hidden; } anyway. I bet that most will remove it since most derivative themes of _s are going to be rather customized in that area anyway (or at least mine are, I could be wrong in the general case).

1) what happens when you have a hosted environment with a lot of themes based on a starter theme;

This shouldn't matter. _s isn't a parent theme. Those themes use _s as a starting point, so any further updates to _s aren't applied to that theme. Adding a breaking change doesn't affect any of the current themes.

2) what happens when a user wants to make a visual change to his/her site that can only be achieved with either manipulating PHP or either hiding/displaying things with CSS?

You can argue this for literally any theme ever made. What if a user wants to add a slider? What if they want it to fade? What if they want the nav to be above the logo, not below? There are so many different use cases that you can't argue that you need to make a theme to work for every possible case. Just look at roots. They include so much useless stuff that almost no one wil ever use, just because a small subset will.

3) which is harder: adding markup back in at the start of every project or taking it out?

Honestly for this case I feel like it's exactly the same. It's just a different method of doing the same thing.


Close this issue if you want (you are actually an active contributor). The pull request itself isn't my issue. I've used this theme a lot and only starting to try to contribute, but I just don't want to see yet another simple, minimalist, dev-friendly theme turn into a theme that tries to make it easy to use for the average user. I don't feel like that was the original intention of the theme. Sorry for the rant. :)

@philiparthurmoore

Adding a breaking change doesn't affect any of the current themes.

A breaking change isn't the concern. We've "broken" tons of things with changes. The question is one of workflow and productivity, as well as theme support. If we decide that "all themes on WordPress.com should do this or that", then the change will probably be made in _s. It's too much trouble to assume that people are going to remember to add things back in that definitely need to be in.

What if a user wants to add a slider?

With a plugin.

What if they want it to fade?

What if they want what to fade? They could do this with CSS.

How do you propose that this particular issue of author bylines being displayed on single-author versus multi-author blogs be handled in a hosted environment that will allow consistency across all themes and flexibility at the same time?

but I just don't want to see yet another simple, minimalist, dev-friendly theme turn into a theme that tries to make it easy to use for the average user.

+1. I don't think this is an issue big enough to fight for, to be honest. If you can explain to me why you think that using CSS to optionally display content (in some cases) is bad then I'll be able to understand you better. I don't understand why you say that it's bad for this case.

@andrewryno

Yeah, sorry I don't mean to argue like this is a huge change that is necessary. I just don't like the thought of using CSS to show/hide things over PHP because it's "easier" (or any other change, not limited to CSS vs PHP).

As far as why hiding text with CSS is bad, it's just bad practice and search engines will punish you for it. BUT in this case you're really just hiding a name/link, so it's negligible. Sorry to derail the thread. I just felt that closing it without some discussion would mean it could be used as a precedent for other similar changes. :)

@philiparthurmoore

Don't ever apologize for making everyone better. That's what you're doing: making us better. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Showing with 11 additions and 12 deletions.
  1. +11 −5 inc/template-tags.php
  2. +0 −7 style.css
View
16 inc/template-tags.php
@@ -123,15 +123,21 @@ function _s_comment( $comment, $args, $depth ) {
* @since _s 1.0
*/
function _s_posted_on() {
- printf( __( 'Posted on <a href="%1$s" title="%2$s" rel="bookmark"><time class="entry-date" datetime="%3$s">%4$s</time></a><span class="byline"> by <span class="author vcard"><a class="url fn n" href="%5$s" title="%6$s" rel="author">%7$s</a></span></span>', '_s' ),
+ printf( __( 'Posted on <a href="%1$s" title="%2$s" rel="bookmark"><time class="entry-date" datetime="%3$s">%4$s</time></a>', '_s' ),
esc_url( get_permalink() ),
esc_attr( get_the_time() ),
esc_attr( get_the_date( 'c' ) ),
- esc_html( get_the_date() ),
- esc_url( get_author_posts_url( get_the_author_meta( 'ID' ) ) ),
- esc_attr( sprintf( __( 'View all posts by %s', '_s' ), get_the_author() ) ),
- get_the_author()
+ esc_html( get_the_date() )
);
+
+ // Print the byline span only on a single post page and on multi author blogs
+ if ( is_single() || is_multi_author() ) {
+ printf( __( '<span class="byline"> by <span class="author vcard"><a class="url fn n" href="%1$s" title="%2$s" rel="author">%3$s</a></span></span>', '_s' ),
+ esc_url( get_author_posts_url( get_the_author_meta( 'ID' ) ) ),
+ esc_attr( sprintf( __( 'View all posts by %s', '_s' ), get_the_author() ) ),
+ get_the_author()
+ );
+ }
}
endif;
View
7 style.css
@@ -418,13 +418,6 @@ a:active {
.entry-meta {
clear: both;
}
-.byline {
- display: none;
-}
-.single .byline,
-.group-blog .byline {
- display: inline;
-}
.entry-content,
.entry-summary {
margin: 1.5em 0 0;
Something went wrong with that request. Please try again.