Display _s_posted_on Content Programatically #177

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
4 participants
@BFTrick
Contributor

BFTrick commented Mar 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@sixhours

sixhours Apr 2, 2013

Contributor

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.

Contributor

sixhours commented Apr 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andrewryno

andrewryno Apr 2, 2013

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.

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 comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Apr 2, 2013

Collaborator

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.

Collaborator

philiparthurmoore commented Apr 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@BFTrick

BFTrick Apr 2, 2013

Contributor

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

Contributor

BFTrick commented Apr 2, 2013

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

@philiparthurmoore

This comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Apr 2, 2013

Collaborator

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).

Collaborator

philiparthurmoore commented Apr 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@BFTrick

BFTrick Apr 2, 2013

Contributor

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.

Contributor

BFTrick commented Apr 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Apr 2, 2013

Collaborator

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.

Collaborator

philiparthurmoore commented Apr 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andrewryno

andrewryno Apr 2, 2013

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)?

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

This comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Apr 2, 2013

Collaborator

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."

Collaborator

philiparthurmoore commented Apr 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@BFTrick

BFTrick Apr 2, 2013

Contributor

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

Contributor

BFTrick commented Apr 2, 2013

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

@andrewryno

This comment has been minimized.

Show comment
Hide comment
@andrewryno

andrewryno Apr 2, 2013

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.

  1. 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.

  1. 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. :)

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.

  1. 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.

  1. 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

This comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Apr 2, 2013

Collaborator

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.

Collaborator

philiparthurmoore commented Apr 2, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andrewryno

andrewryno Apr 2, 2013

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. :)

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

This comment has been minimized.

Show comment
Hide comment
@philiparthurmoore

philiparthurmoore Apr 2, 2013

Collaborator

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

Collaborator

philiparthurmoore commented Apr 2, 2013

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