[theme-reviewers] Double enqueuing script, style & google fonts

Ulrich Pogson grapplerulrich at gmail.com
Tue May 13 15:35:11 UTC 2014


One thing I would add to the standard naming of third party scripts is that
if it is dependant on jQuery then it should include jquery in the handle.
e.g. FitVids would be jquery-fitvids. This is what WP core does.

Scenario 3 - I am not sure why a plugin would need to enqueue a font. If
there was a point where a plugin was enqueuing the same font then the user
could easily dequeue the font and also contact the plugin/theme developer
to see if the handle could be changed.

Interesting Fact: WordPress core loads open-sans font. If your theme is
using it then you can just use the handle 'open-sans'.


On 13 May 2014 16:41, Justin Tadlock <justin at justintadlock.com> wrote:

> What Chip said.  Some other general guidelines to follow:
>
> * The handle should be the script name in all lowercase.
> * If the script name is more than one word, hyphenate them in the handle.
>
> These conventions follow WP core, so that will help decrease the chances
> of double-loading a file.
>
>
> On Tue, May 13, 2014 at 8:02 AM, Chip Bennett <chip at chipbennett.net>wrote:
>
>> Here's what I would suggest:
>>
>> 1. If a script or stylesheet is custom to the Theme, then it should use a
>> Theme-specific prefix
>> 2. If the script/stylesheet is bundled with core, it should use the
>> core-registered handle
>> 3. If the script/stylesheet is an otherwise third-party resource, I would
>> suggest merely using the script/stylesheet slug as the handle.
>>
>> In the third case, there's no standard, so there's no way to ensure that
>> the script/stylesheet won't get double-enqueued, no matter what you do. But
>> by *not* prefixing it, you maximize the likelihood that a Plugin attempting
>> to register the same script/stylesheet will use the same handle.
>>
>> The point about namespacing in Themes is that it applies to things that
>> are *custom* to the Theme: Theme-defined functions, variables, constants,
>> transients, meta data, stylesheets, scripts, etc. A bundled, third-party
>> script or stylesheet isn't custom to the Theme.
>>
>>
>> On Tue, May 13, 2014 at 8:55 AM, mudthemes support <contact at mudthemes.com
>> > wrote:
>>
>>> Well thanks for replying but my question is a bit different from the
>>> answer. Here it goes:
>>>
>>> # Scenario 1:
>>>
>>> Suppose Theme ABC enqueues a script which is a publicly available
>>> Javascript library (suppose 'tabulous.js'). The handle theme uses to
>>> enqueue the script is 'theme_slug_tabulous' and not 'tabulous'.
>>>
>>> In this case if another plugin also enqueues 'tabulous.js' then the
>>> theme will output two different tabulous.js files.
>>>
>>> Question: In case of a publicly available library, shouldn't the theme
>>> must use 'tabulous' instead of prefixing the theme slug.
>>>
>>>
>>> # Scenario 2:
>>>
>>> Another Theme XYZ enqueues a custom made javascript code with handle
>>> such as 'responsive' (without the theme-slug prefix).
>>>
>>> Question: In this case, should not the theme prefix the handle?
>>>
>>>
>>> # Scenario 3:
>>>
>>> Different themes use different handles to enqueue Google fonts such as
>>> 'Google-font-x'. Now this could create trouble when the same fonts are also
>>> enqueues via a plugin.
>>>
>>> Question: Is there any way to define a specific handle for a specific
>>> Google font and reduce the issue of duplicacy.
>>>
>>>
>>> Any suggestions, Thanks in Advance.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2014-05-13 07:27, Emil Uzelac wrote:
>>>
>>>> INCLUDING STYLESHEETS AND SCRIPTS # [2]
>>>>
>>>>         * Themes are REQUIRED to enqueue all stylesheets and scripts,
>>>> using wp_enqueue_style() [3]/wp_enqueue_script() [4], and hooked into
>>>>
>>>> an appropriate hook via callback function, rather than hard-coding
>>>> stylesheet/script links or tags in the template.
>>>>
>>>>         * Themes are REQUIRED to use the Theme-specific hook for
>>>> admin-enqueued scripts/stylesheets, e.g.
>>>> admin_print_scripts-appearance_page_$menu_slug
>>>>         * Themes are RECOMMENDED to hook stylesheet and script enqueue
>>>> callbacks into `wp_enqueue_scripts`
>>>>         * Themes may OPTIONALLY link the default stylesheet (style.css)
>>>>
>>>> directly in the document head, or via wp_enqueue_style(). Whichever
>>>> method is used, the default stylesheet must be referenced
>>>> via get_stylesheet_uri() [5]
>>>>
>>>>         * Themes are REQUIRED to use core-bundled scripts, if using such
>>>>
>>>> scripts
>>>>
>>>> On Tue, May 13, 2014 at 2:58 AM, mudthemes support
>>>> <contact at mudthemes.com> wrote:
>>>>
>>>>  A question regarding enqueuing script, style & Google fonts. When
>>>>> enqueuing them in a theme, the handle prefix should be what?
>>>>>
>>>>> 1. JS Scripts and CSS files
>>>>> i) For publicly available libraries?
>>>>> ii) For custom created codes?
>>>>>
>>>>> 2. Google Fonts
>>>>> 1) When enqueued using <link> tag.
>>>>>
>>>>> Any suggestions, please?
>>>>> _______________________________________________
>>>>> theme-reviewers mailing list
>>>>> theme-reviewers at lists.wordpress.org
>>>>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers [1]
>>>>>
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1] http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>>> [2]
>>>> http://make.wordpress.org/docs/theme-developer-handbook/
>>>> releasing-your-theme/theme-review-guidelines/#including-
>>>> stylesheets-and-scripts
>>>> [3]
>>>> http://make.wordpress.org/docs/theme-developer-handbook/
>>>> releasing-your-theme/theme-review-guidelines/Function_
>>>> Reference/wp_enqueue_style
>>>> [4]
>>>> http://make.wordpress.org/docs/theme-developer-handbook/
>>>> releasing-your-theme/theme-review-guidelines/Function_
>>>> Reference/wp_enqueue_script
>>>> [5]
>>>> http://make.wordpress.org/docs/theme-developer-handbook/
>>>> releasing-your-theme/theme-review-guidelines/Function_
>>>> Reference/get_stylesheet_uri
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140513/e1de88b8/attachment-0001.html>


More information about the theme-reviewers mailing list