[wp-meta] [Making WordPress.org] #31: WordPress.org global footer link changes

Making WordPress.org noreply at wordpress.org
Sun Aug 18 19:38:24 UTC 2013


#31: WordPress.org global footer link changes
--------------------------+-----------------------
  Reporter:  devinreams   |      Owner:  iandunn
      Type:  enhancement  |     Status:  assigned
  Priority:  normal       |  Component:  General
Resolution:               |   Keywords:  has-patch
--------------------------+-----------------------

Comment (by iandunn):

 Replying to [comment:20 Otto42]:
 > I see that your diff moves the standard alignment classes into wp4.css.
 Is this safe? The problem with the wp4.css is that it is used across the
 whole site, including the make blogs and everything else. The reason I
 only added those classes to the blog-wp4.css is that only the news site
 was missing them. I presumed that the make sites would have those already,
 since they're inheriting them from the P2 theme.

 [[br]]It's not a big deal to me either way, but I figured it'd be better
 to have to them in a single, central/global place, rather than reproducing
 them on every site that doesn't have them from an existing theme. I can
 see us wanting to use them on static pages or new areas/sites in the
 future, so it just makes it easier. I tested all the sandboxable sites
 with the new CSS and didn't notice any conflicts. I'm happy to switch it
 back, though, if you think that'd be better.
 [[br]]

 > When developing, handling the static caching server is a PITA. So it's
 best to not use the s.wp and best to not update the number for
 cachebusting, because it causes increases when we have to deploy, since we
 have to stage the CSS first, then do the cachebust separately.

 [[br]]Sounds good, I've reverted the cachebusting indices in 31-meta-
 wporg.2.diff.
 [[br]]

 > Any place we're referencing url(http://s.wordpress.org) for anything in
 a CSS file willalso need to be updated to use the "no-static" trick. If
 you examine header.php, you'll see that if the site is being accessed via
 https, it adds the "no-static" class to the html element. You can use this
 to refer to the correct URL and avoid the SSL problem. Examine the uses of
 .no-static in the wp4.css to see how this is done. This is part of the
 ssl-all-the-things initiative, to allow everything to work properly over
 https. [...] I see you're already modifying the no-static classes in the
 diff properly, just added that there to be sure, since there may be more
 url() refs that got missed somewhere.

 [[br]]Sounds good. I'm assuming we'll update all the existing URLs in
 #wp22811.

--
Ticket URL: <http://meta.trac.wordpress.org/ticket/31#comment:22>
Making WordPress.org <http://meta.trac.wordpress.org/>
WordPress blogging software


More information about the wp-meta mailing list