QUESTION Theme scripts & styles enqueu

[naug]

Hello all, I just discover this wonderfull tool that is GS. Coming from wordpress, it seems more appropriate for certain kind of small projects. I allready love it !

Still some questions I can't figure out : where do we enqueu custom styles/scripts while developping themes. The function given in the Wiki is very simple but where should I type it ? Is it similar to WP where register and enqueu are located in the function.php file.

Must be a stupid question but I can't find out ^^

Sorry for my poor english, french people aren't famous for their foreign language skills

[Tyblitz]

In my knowledge you should only register & enqueue scripts/styles when developing plugins. (The wiki Theme pages don't mention it.) Most themes include their assets with regular <script> & <link> tags into their template.php file, or an include like head.inc.php
Generally you'd have those tags point at an assets folder (or separate css, js, img, .. folder) in your theme directory.

[lnickel]

Really? Is that bad practice? I have been writing my scripts and css inside a functions.php page. This is what I have been doing and its been working fine for me. I like doing it this way so I can load a specified script or link based on the page slug if needed.

PHP Code:

$template = $TEMPLATE;

register_script('jquery-1.11.1.min', $site_url. 'theme/'. $template. '/assets/js/vendor/jquery-1.11.1.min.js', '1.11.1', TRUE);
queue_script('jquery-1.11.1.min', GSFRONT);

$site_url = $SITEURL;

register_style ('style', $site_url.'theme/myTheme/style.css', '1.0', 'screen'); 
queue_style('style', GSFRONT); 


[shawn_a]

Yeah but its not supported outside of plugins... so as with any feature/bug it can break at anytime.
disclaimer: I do this all the time as well, even inside components with my hook_component plugin

At some point I would like to engineer these things into themes, as well as ability to register plugins, components, and assets.

The problem with this, is what happens when a plugin is already queueing core jquery or jqueryui on front end.
queue_script('jquery', GSFRONT);

[Tyblitz]

The problem with this, is what happens when a plugin is already queueing core jquery or jqueryui on front end.
queue_script('jquery', GSFRONT);

Then shouldn't the solution be as simple as having a global $live_assets similar to live plugins (and eventually subdivided into 'front' & 'back', and only add if not present yet?

[lnickel]

Yeah but its not supported outside of plugins... so as with any feature/bug it can break at anytime.
disclaimer: I do this all the time as well, even inside components with my hook_component plugin

At some point I would like to engineer these things into themes, as well as ability to register plugins, components, and assets.

The problem with this, is what happens when a plugin is already queueing core jquery or jqueryui on front end.
queue_script('jquery', GSFRONT);

Yikes!! Ok so for now I will only include in something like header.inc.php

Thanks for the heads up! So far nothing is broken but you are right what if a plugin I need to use is queueing it!

I forgot to add this in my post but I am plugging into the global vars something like this: I dont know where I got it LOL.

I know just enough to be dangerous

global $SITEURL;

global $TEMPLATE;

[shawn_a]

ideally we would have better queuing and dequeuing and queue checking.
we have globals
$GS_scripts and $GS_styles, but these are for internal use.
items can be queued at any time so it might be difficult to check the queue, ideally you queue what you want, and GS decides how to output it.

So you could queue `jquery` version 1.11 and someone else queues 1.9, and we would output the best version. This is not implemented yet, but would be ideal for these situations. We could also make registering assets easier, so that you register your own assets or override core ones. In 3.4 this is how various stuff works, it would be possible to override the code_edit and html_edit assets for example. This is still kind of ifffy.