[#24294] - Transfer of script options generation
- Closed
- 17 Jul 2020
- Medium
- Build: 4.0-dev
- # 24294
- Diff
- smirnov-d:scripts-renderer
- Failure continuous-integration/drone/pr the build failed Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
Transfer of script options generation from the StylesRenderer.php to the ScriptsRenderer.php
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
Then this needs to move to the meta renderer, or its own renderer, otherwise the styles renderer is stuck in the head and according to some people's best practices having that in the head is wrong.
@dgrammatiko @mbabker
Based on your answers I'd like to make sure we are on the same page here:
@mbabker is agree that this block is not supposed to be in the styles;
@dgrammatiko think that this should be in the <head> only;
Please correct me if I'm wrong here.
My opinion:
I agree with initial request: something that belongs to (used by) scripts is supposed to be in scripts.
Basically if we building the modular system for those metas, styles, scripts we should be able to use functionality separately.
Now goes example:
I remove meta and styles (I do not need those, I do not what to allow 3rd party components to influence my template [yes, it's strict to be what I put in there]), but I want to be able to use scripts.
Now i use JText::script('LANG_STRING').
As a result I have empty result for Joomla.JText._('LANG_STRING').
Reason: lang strings are pushed to "script options" which are rendered in styles; and I do not have those. [xtd-buttons, editor settings are also depend on rendering "styles" block this way]
My question:
@dgrammatiko why do you thing that script options should always be rendered in <head>?
| Labels |
Added:
?
|
||
I remove meta and styles (I do not need those, I do not what to allow 3rd party components to influence my template [yes, it's strict to be what I put in there]), but I want to be able to use scripts.
For the record, I think this is a very bad idea. I get the reasoning for style related stuff, but for metadata you've essentially killed off everything in core and every plugin that handles setting page data, a lot of this being your SEO related stuff (which includes basic things like your <title> tag). Realistically you should be pulling things out of the arrays in the Document class before everything is rendered, not excluding rendering completely.
This options element is a bit of a special case in that it is acting as a container to transfer data from the server to the client and that data should be available as quickly as possible, and it needs to come before the scripts actually start being included (so as this PR is it's actually pretty broken because it renders the options element after the rest of the page's JavaScript). IMO this specific <script> tag should remain in the head and not be shuffled around with the rest of the script output.
why do you think that script options should always be rendered in ?
Because this is not aa actual script, it's just some json data passed from PHP to Javascript. It can be echoed anywhere in the page but for consistency and actually not creating any problems to the order of execution it's better to stay in the head. This tag is not render blocking so there is no benefit moving it to the scripts renderer.
@mbabker I hear you, but still believe the idea that Joomla is something bigger that WP or any other regular website engine. So I might be building the internal custom platform (for example HR platform) that have nothing but login page available for the public and SEs.
@dgrammatiko first of all don't be so sure about the benefit part.
(quick example here: there is cases when SEs are only loading the N bytes of the page, and if you put big JSON with a lot of strings in the head you might run into a issue).
second thing here:
if Joomla makes it modular and possible to play around with this rendering block you actually mean that I can play around with those and put styles after scripts.
(And IMHO that's not something where you can quote Uncle Ben: "With great power comes great responsibility" )
third (and staring) point:
I should be able to use modules independently.
Putting it to the start of the rendering block may make sense, but I still think it should be within scripts block. You can't fight the logic: scripts are using these lines, styles - do not.
the changes are wrong,
the <script type="application/json" class="joomla-script-options"> block should be always over all scripts.
I do not really see much reason to moving thing around here, but styles or meta are fine locations for it.
upd: meta sounds logical for this block
still do not understand how someone find styles for this "fine"
It just because of ordering, a styles should always come up first than scripts (if it not, then you doing something wrong).
If someone want to change location of this block then just place it in Meta, and everyone will be happy. It a kind of meta anyway.
But as I said I might be reordering scripts and styles, or removing last one at all.
You may remove anything, but then it not Joomla! issue, it an issue of your project. I think.
If someone want to change location of this block then just place it in Meta, and everyone will be happy. It a kind of meta anyway.
As I argued above:
there is cases when SEs are only loading the N bytes of the page, and if you put big JSON with a lot of strings in the head you might run into a issue
And for:
but then it not Joomla! issue
Yes, for 3.x and now for 4.x, since it's allowed by core (by splitting it to a different renderers) modularity.
(quick example here: there is cases when SEs are only loading the N bytes of the page, and if you put big JSON with a lot of strings in the head you might run into a issue).
What search engines? And honestly, if they are truly only loading the first N bytes of the HTML document, then they're probably screwing up something anyway because any good search platform today is not only analyzing <meta> and <title> tags found within a <head> element and that behavior implies that they are seeing very little, if any, of what is in your document's <body> (and it gets even worse when you start considering the markup structure for your template which generally is going to include your site title, navigation, and probably a search element; if you're working against a 4 kilobyte limit then a page like https://www.joomla.org/announcements/release-news/5761-joomla-3-9-4-release.html probably doesn't get indexed correctly at all because the body content is so deep into the DOM).
there is cases when SEs are only loading the N bytes of the page, and if you put big JSON with a lot of strings in the head you might run into a issue
I did not said the JSON block should be a first ever loaded thing
At the end of meta are fine.
Also as @mbabker mentioned that not really good argument. Additionally when site has gzip enabled then someone will get N bites of
Please fix conflicts.
| Labels |
Added:
Conflicting Files
|
||
this can be closed, it much changed in j4
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-07-17 17:20:55 |
| Closed_By | ⇒ | Quy |
Please use tabs and not spaces for indentation.