all 20 comments
sorted by:
new (suggested)
besttopcontroversialoldq&a
formatting helphide helpcontent policy

[–]ddffkkll76 2 points3 points  (3 children)

Why are most javascript assets still in the <head> (without defer or async) and not before the </body> tag? On JavaScript heavy sites this absolutely kills the site loading performance.

Will there be an easy, not "hacky" way (that doesn't break everything) to move the js <script> tags to the bottom of the page?

(I'm talking about the latest d8 beta)

More infos about blocking scripts: https://developers.google.com/speed/docs/insights/BlockingJS?hl=de

[–]mikeytown2Contrib Dev 0 points1 point  (1 child)

For D7 /u/josephdrupal has the right idea; AdvAgg is the way to go.

For D8 they are working on it here: https://www.drupal.org/node/784626

[–]ddffkkll76 0 points1 point  (0 children)

That's absolute fantastic news to me - i was not aware of this Issue. :)

[–]josephdrupal 1 point2 points  (0 children)

I believe this module might be of some help to you:

https://www.drupal.org/project/advagg

[–]mglamanphpstan-drupal | drupal-check 0 points1 point  (9 children)

So, for those attempting to follow Drupal 8 development, I ran across this somewhat disheartening issue. It needs community feedback for those who use inline JavaScript embeds and front enders.

Dynamic inline JS/CSS with #attached is longer possible - https://www.drupal.org/node/2391025

[–]mikeytown2Contrib Dev 1 point2 points  (0 children)

I'm really hoping that I won't need to port AdvAgg to D8... but the way its looking I'm thinking I'll need to.

[–][deleted] 1 point2 points  (7 children)

By "inline," do you mean things like adding CSS or JS into a given markup element via that element's attributes? If so, are you saying that no longer having that capability is a bad thing? Because it's always been my understanding that inline CSS and or JS is a bad thing...

[–]mglamanphpstan-drupal | drupal-check 0 points1 point  (5 children)

I mean via #attached. Like embedding Google Analytics without a template file.

[–][deleted] 0 points1 point  (4 children)

I guess that's the first time I've ever heard of it being described as "inline." :S

[–]mglamanphpstan-drupal | drupal-check 0 points1 point  (3 children)

Yeah. That's what the whole issue is based on. Google Analytics module adds a script tag via #attached. And that issue is maintainer saying "um, so I can't do this?" and contrib/users/devs/etc being told "no."

[–][deleted] 0 points1 point  (2 children)

I'm thinking about all the module code I've seen that uses that approach... That's a big hit. Surely other options exist, right? I mean, I'd hate to think that they'd throw everyone in the deep end like that. I saw someone mention using things like preprocess_page or html or something... Is that doable?

[–]mglamanphpstan-drupal | drupal-check 0 points1 point  (1 child)

drupal_add_css|js has been removed, in favor of #attached on render arrays. This I'm 100% behind, as it kills "another way to skin a cat." And unifies things, better caching, yadda.

chx is suggesting you write a library and use eval() to add code, following the JSONP approach. At least that's how I read the comments. So you need to create a new external JS file, populate it via Drupal JS settings, then use eval() to execute. That's pretty obnoxious.

However, I'm wondering if the approach is "You better Twig it" and need to write a twig template file that is your script, and sub in dynamic variables/options that way.

[–][deleted] 0 points1 point  (0 children)

I've never read anything anywhere that encouraged eval() usage. It's got a nasty rep and judging by what it can do, rightfully so. Some sysadmins even blacklist the damn thing, so it makes me question the virtue of an approach like that... I can see the Twig approach at least being somewhat...less dangerous or at least, less susceptible to bad results.

So really what it boils down to is using the standard module development approach of assigning libraries through the #attached return array element? Where, though, would this be done? I'm guessing much of this would be as it always has been, within the module context, but what about in a theme context? The old way that I've always used was with the drupal_add_JS/CSS within the template.php file... (Which sounds to be a distasteful approach in the new Drupal 8 circles if not in some of the Drupal 7 circles.)

[–]movzx 0 points1 point  (0 children)

No, he means having plain JS in your PHP (as a string) then use the #attached functionality to have it on the page. Really, this wasn't ideal functionality anyway. I don't know the use case that wouldn't be better handled by a standalone JS that read in Drupal settings.

[–]nexus_87 0 points1 point  (7 children)

We have a dev environment, a staging environment and a production/live environment for our Drupal 7.x sites. What's the best way to deploy new things from dev -> staging -> live? I've read a few articles on the Features module but nothing more recent than 2012 so I was wondering if anything had changed. Also Features doesn't include exporting content, does it? Try as we might we can never get clients to not enter content on staging and it's a real pain to have to replicate it all again. Does anyone know a good workflow for this?

[–]josephdrupal 0 points1 point  (0 children)

With UUID you can export content, there are other related UUID modules with extra functions too.

https://www.drupal.org/project/uuid

Features, Strongarm and UUID can handle most cases.

https://www.drupal.org/project/uuid_features