Skip to:
Content

Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#6248 closed enhancement (fixed)

Add companion style support for the default WP themes

Reported by: Prometheus Fire Owned by: hnla
Milestone: 2.3 Priority: normal
Severity: normal Version:
Component: Core Keywords: close
Cc: ashley@…, stephen@…

Description

This ticket is to create a place to talk about the technical and theoretical aspects of getting styles for the default WP themes.

It stems from the discussion started in #6124 - which began with the discussion about TwentyFifteen.

It can also be used to track the progress of each of the other default themes which should get a ticket of their own. There are going to be a number of design decisions unique to each theme that may need to be discussed and having a separate ticket for each theme should be helpful in that regard.

Change History (20)

#2 @boonebgorges
3 years ago

  • Milestone changed from Awaiting Review to 2.3

#3 @boonebgorges
3 years ago

  • Type changed from defect (bug) to task

This ticket was mentioned in Slack in #buddypress by boone. View the logs.


3 years ago

#5 @mercime
3 years ago

  • Owner set to hnla
  • Status changed from new to assigned

#6 @hnla
3 years ago

Stylesheet File Formatting

I'm going to suggest that we ought to maintain some uniformity between companion stylesheet and BP default sheet, this will help in maintaining styles in a common fashion and helping contributors know where to locate rules.

I consider this very much open though to deliberation and adjustment as we iterate through patches, not set in stone.

I have updated the patch for #6124 to re-factor the twentyfifteen file to shadow the structure in the default theme with minor variations as a base to proceed from.

#7 @feedmymedia
3 years ago

  • Cc ashley@… added

#8 @hnla
3 years ago

@ Core Devs opinions on the following would be appreciated

  • 1. Less / SaSS - This has been raised before but feel we need to agree again whether we pre-process or not. Obviously we don't currently with our sheets, even though most of us will be working this way by default. IMO we haven't thus far, it may be a barrier to people getting involved, requires maintaining two files.
  • 2. Patches or Zip files: What is the best approach to working files and maintaining some principle of versioning? I have updated the current patch on the twentyfifteen and propose that as the base file we work from. Concerns are that with either approach we can stand to clash with multiple versions that then take additional time and work to resolve.
  • 3. Number of themes to tackle: I propose we tackle three initially as probably being the most we can manage and ensure a level of quality that we would wish within a release cycle

#9 @hnla
3 years ago

@PrometheusFire @feedmymedia

I would very much like to open a brief dialogue on proceeding with an initial two themes, as both of you have kindly offered to help on these companion sheets, and how we might best approach each one i.e as either a collaborative effort or both taking one on initially to get the ball rolling on.

I will be creating two new tickets for both Twentyfifteen and Twentyfourteen in those I'll set out the basic task guidelines and then suggest in each a brief discussion on the overall visual look each will take so there's an agreed visual style but will be looking to keep discussions brief and not allow things to get bogged down in too much discussion so we get down to styling and iterating on the work as it develops.

Companion stylesheet task - twentyfifteen #6291

Last edited 3 years ago by hnla (previous) (diff)

#10 @boonebgorges
3 years ago

  1. Less / SaSS - This has been raised before but feel we need to agree again whether we pre-process or not. Obviously we don't currently with our sheets, even though most of us will be working this way by default. IMO we haven't thus far, it may be a barrier to people getting involved, requires maintaining two files.

My view is to use Sass. That's what core is using in the few places where it's begun to adopt a preprocessor. The slight increase in barrier to entry is easily offset by the increased modularity and maintainability.

Patches or Zip files: What is the best approach to working files and maintaining some principle of versioning? I have updated the current patch on the twentyfifteen and propose that as the base file we work from. Concerns are that with either approach we can stand to clash with multiple versions that then take additional time and work to resolve.

I'm not 100% sure I understand the question, but I would suggest the following: Get your initial patch to a state where it's reasonably good and you are confident that you can complete it for 2.3, and then commit it to trunk. Then use smaller patches for ongoing development.

  1. Number of themes to tackle: I propose we tackle three initially as probably being the most we can manage and ensure a level of quality that we would wish within a release cycle

I'd suggest we do as many as possible. At the same time, I would strongly suggest trying to get at least one or two completely done for 2.3 - better to ship with a really great stylesheet for Twenty Fifteen than to ship with half-done stylesheets for three different themes. So, maybe focus 50% of dev effort on twentyfifteen, 30% on twentyfourteen, 20% on twentythirteen; if the latter themes end up not being done in time, we can punt, while if the former ends up being finished, those resources can be devoted to the latter themes.

#11 @hnla
3 years ago

My view is to use Sass.

Ok I'm preparing a Sass version of file in case we go in that direction, although I'm happy to I would say there is small gain in reality with the nature of these sheets and their complexity but people might be more comfortable working with pre-processor syntax.

I'd suggest we do as many as possible. At the same time, I would strongly suggest trying to get at least one or two completely done for 2.3 - better to ship with a really great stylesheet for Twenty Fifteen than to ship with half-done stylesheets for three different themes.

There would never be any question of shipping anything unless it was 100%, we can't release styles that are so so, they either do the job or don't. Three themes was suggested as a manageable number if there was sufficient interest in getting involved, but yes punt those that don't meet a standard we're happy with to the next release cycle.

#12 @DJPaul
3 years ago

Both bbPress and one of my many in-progress git branches have SASS implementations. We can talk details/get it done over at WordCamp London, hnla, if we don't get this resolved before then.

#13 @netweb
3 years ago

  • Cc stephen@… added

This ticket was mentioned in Slack in #buddypress by netweb. View the logs.


3 years ago

#15 @boonebgorges
3 years ago

In 9694:

In bp-legacy, load theme-specific stylesheets if found in the stack.

When enqueuing stylesheets, bp-legacy will look for files called
{stylesheet}.css, where {stylesheet} is the name of your current theme. This
will enable bp-legacy to ship with supplementary stylesheets that target
specific themes, such as WP's twenty* default themes.

Props r-a-y.
See #6248, #6124.

#16 @DJPaul
3 years ago

  • Milestone changed from 2.3 to 2.4

#17 @hnla
3 years ago

  • Keywords close added

Closing this ticket as served initial purpose and can remain as a reference. Further companion style tasks will run under their own tickets.

#18 @DJPaul
3 years ago

  • Milestone changed from 2.4 to 2.3
  • Resolution set to fixed
  • Status changed from assigned to closed

#19 @DJPaul
2 years ago

  • Component changed from API to Core

#20 @DJPaul
2 years ago

  • Type changed from task to enhancement
Note: See TracTickets for help on using tickets.