[theme-reviewers] Theme Scan Failing

[Otto]

Ugh. Okay, this may be a bit long winded.

For the cases where you're creating dynamic CSS, then there is one
correct way to do it, and several incorrect ways to do it. Let's go
over the possibilities.

Method 1: Insert the dynamic CSS directly into the HTML using the wp_head call.

Method 2: Write dynamic CSS to a file, link to the file in the head.

Method 3: Hook into the template-loader or init to create CSS output based on
a special GET variable you define.

Method 4: Style.php, which is linked to from the head, and outputs
dynamic css. Usually this has to include wp-load.


I listed those in that order because they go from "best" to "worst".
I'll explain why now. :)

Method 1 has the lowest server impact. When you make the call to get
the page, it creates the page and outputs all the dynamic stuff in one
shot. Some people find the CSS in the html to be aesthetically
displeasing, but the fact of the matter is that this is the fastest,
simplest, and best way to do it.

Method 2 has a problem in that you're doing file writing from the
theme. This is bad because you cannot guarantee that you have
permissions to even write files. Assuming you try to write them to the
uploads folder, then part of your theme is now outside the theme
directory, which is confusing. Also, by including the CSS as a
separate file, you're creating another call to the server, which even
Google Webmaster Tools will tell you is a thing to avoid.

Method 3 is the same as method 2, except now instead of writing the
file, you make a call to http://example.com/?css=whatever and then
your code intercepts that and produces the CSS on-the-fly, via
whatever means, then exits. This avoids the file writing problem, but
now it's not
only making an extra server call, but it's also loading all of
WordPress up again, which creates a higher server CPU impact.

Method 4 is the same as method 3, basically, except that you're
referencing some PHP file directly, which now has to a) find wp-load,
b) load WordPress, and c) produce the resulting CSS output. Worst of
all cases: two calls to the server, WordPress loads twice, and you're
now having to search around to figure out how to load WordPress again
just so you can access the database.


So the end statement here is to always use method 1. Okay, so you find
CSS in the HTML header code to be unpleasant. My advice: get over it.
Every other way of doing things not only requires an extra HTTP
request to the server, but most of them also require a whole lot of
extra PHP processing. Think about it this way: You've already got
WordPress loaded up to generate the page. The most sensible thing to
do is to go ahead and generate the dynamic part of the CSS right now
as well. Just make that dynamic part as small as possible. Minify it
into one-line if you want.

Note that WordPress itself uses method 1 for the custom background
image and custom header image stuff. It does it this way because it's
the best way to do it.

-Otto



On Thu, Dec 2, 2010 at 11:57 AM, Simon Prosser <pross at pross.org.uk> wrote:
> There is a more sensible way to do this. Use a style.php file that
> prints your custom css
> with text/css header and a far future expires, then the browser will
> cache it locally.
>
> My theme [JustCSS] uses this to cache the css.
> https://github.com/Pross/JustCSS
>
> On 2 December 2010 17:46, Sayontan Sinha <sayontan at gmail.com> wrote:
>> What about instances of caching? E.g. I have a lot of look and feel options
>> that can be set by the user. However if you attempt to print them out as
>> dynamic CSS on the fly it creates extra server load, not to mention an ugly
>> lot of CSS before the content in the page's source. Instead the CSS is saved
>> as a local file at the time of saving the options and then that file is
>> linked in the source.
>>
>> On Thu, Dec 2, 2010 at 8:50 AM, Otto <otto at ottodestruct.com> wrote:
>>>
>>> On Thu, Dec 2, 2010 at 3:02 AM, Sayontan Sinha <sayontan at gmail.com> wrote:
>>> > I am curious as to what qualifies as a better way of doing things. E.g.
>>> > I
>>> > have code where depending on selections certain stylesheets are grouped
>>> > together, then either they are compressed and/or minified.
>>>
>>> See, that sounds awfully functional to me. Why would you want the
>>> theme to be doing that?
>>>
>>> A theme is supposed to describe how the site looks, not how the site
>>> works. Sure, for custom jobs, we all do it and put this sort of thing
>>> in the theme, but remember that the directory is supposed to hold
>>> themes to be used for public consumption. Anybody can use them.
>>>
>>> So doesn't it make a bit more sense to make this sort of
>>> compression/minification more generic, able to apply to any theme, and
>>> then to put it in a plugin?
>>>
>>> Also, look into wp_enqueue_style, which is capable of minification and
>>> combining css files.
>>>
>>> -Otto
>>> _______________________________________________
>>> theme-reviewers mailing list
>>> theme-reviewers at lists.wordpress.org
>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>>
>> --
>> Sayontan Sinha
>> http://mynethome.net | http://mynethome.net/blog
>> --
>> Beating Australia in Cricket is like killing a celebrity. The death gets
>> more coverage than the crime.
>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>
>
>
> --
> My Blog: http://www.pross.org.uk/
> Plugins : http://www.pross.org.uk/plugins/
> Themes: http://wordpress.org/extend/themes/profile/pross
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>