[theme-reviewers] Theme Scan Failing

Fri Dec 3 07:01:24 UTC 2010

Sayontan,

I agree with Otto here and I use method #1 in my plugins when I need to
generate dynamic css. If the overhead of processing php on each request is
an issue for you, might it be a good idea to store the dynamic css in an
autoloaded option and print the value of the option to the head?

-Mike

> Otto,
> Method 1 is not better than Method 2 if a lot of your CSS is dynamic, as
> is
> the case with most themes that offer a lot of styling options. In such a
> case using Method 1 you would be repeatedly running a lot of PHP calls to
> dump the same CSS each time into your HTML. This is really inefficient
> particularly in contrast to one extra HTTP request to get a pre-generated
> file. Hence it is not something that can be shoved aside by saying "get
> over
> it" - Method 2 does improve caching performance significantly on several
> occasions.
>
> Sayontan.
>
> On Thu, Dec 2, 2010 at 10:13 AM, Otto <otto at ottodestruct.com> wrote:
>
>> 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
>> >
>> _______________________________________________
>> 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
>