[4.0][RFC][WIP] assets restructure#21294
[4.0][RFC][WIP] assets restructure#21294dgrammatiko wants to merge 5 commits intojoomla:4.0-devfrom dgrammatiko:4.0-dev-assets-restructure
Conversation
| } | ||
| }, | ||
| }, | ||
| ); |
There was a problem hiding this comment.
Unexpected newline before ')' function-paren-newline
| }; | ||
|
|
||
|
|
||
| const uploadPath = options.uploadPath; |
There was a problem hiding this comment.
Use object destructuring prefer-destructuring
| * @since 2.5 | ||
| */ | ||
| Joomla.overrider.insertResults = (results) => { | ||
| const self = event.target; |
There was a problem hiding this comment.
Unexpected use of 'event' no-restricted-globals
| * @since 2.5 | ||
| */ | ||
| Joomla.overrider.searchStrings = (more) => { | ||
| const self = event.target; |
There was a problem hiding this comment.
Unexpected use of 'event' no-restricted-globals
| if (res.data.redirect) { | ||
| location.href = res.data.redirect; | ||
| } else { | ||
| location.href = 'index.php?option=com_installer&view=install'; |
There was a problem hiding this comment.
Unexpected use of 'location' no-restricted-globals
| } | ||
| // Always redirect that can show message queue from session | ||
| if (res.data.redirect) { | ||
| location.href = res.data.redirect; |
There was a problem hiding this comment.
Unexpected use of 'location' no-restricted-globals
| throw new Error(json); | ||
| } | ||
| if (json.start) { | ||
| totalItems = json.totalItems; |
There was a problem hiding this comment.
Use object destructuring prefer-destructuring
|
BEFORE this is merged the suitabole documentation must be available - unlike with the other recent change |
|
hm, need to think, it a huge rush, |
Sure, that's why i opened this as RFC
There won't be a single PR for this simply because it cannot. There are way too many things happening here:
|
|
1000 files is a bit hard to review what exactly you did here. Would be easier if it was done in smaller steps. Especially as some changes seem to be unrelated to each other. Regardless of that some things I noticed:
|
true, and I agree
The impact is really minimal here. The reason is that even if you had some layout overrides in your template (J3) those are completely useless in J4, so one way or another if you have to do a new layout override you will start from a core layout which will have already the correct path for the assets
This needs to be balanced. The pro here is that we get the tools to work with any template, and thus the core is providing the right tooling for development. The con is that we change slightly the behaviour of the template css/js (now can be overridable) |
Maybe for core that's true, I can't even say. But for 3rd party it certainly will not be true. Especially not when it comes to extensions which are supposed to work both in J3 and J4. There JS and CSS will be the same or very similar. Question still stands what the benefit is. The assets are already grouped by components/modules/plugins due to the prefixed naming convention (com_foo, mod_foo, plg_foo_bar) we use. This looks like a change for the sake of change to me.
I don't understand. You expect 3rd parties will use the core tools to build their templates? I honestly doubt that they will. Or you rather mean any (both) of the core templates? |
|
Mmmmmh very big and dangerous change... especially for the Joomla! ecosystem of extensions and templates |
Can we not use the |
What are you talking about? Almost all scripts are exposed through an HTMLHelper method. So what will be broken? Also the system directory remains as is. So I'm confused what will be broken?
Yes! That is how I understand adding value to the product by providing easy tools to develop on this platform. My point of view, you don't have to agree with me here
I think you got this wrong. css folder in the templates still is the ruling folder. I'm not proposing to change this! What is different is that the template's own css file will not be in that folder but rather in the |
Do you really expect all the template clubs with their own frameworks to change - I think that's highly unlikely |
You're thinking about core here. I'm arguing from a 3rd party view. That's where the confusion comes from.
Those extensions that use the media folder, also use the Joomla API to include the files. Otherwise it makes not much sense to use the media folder. So I'm not talking about 3rd parties who do their own thing. I'm concerned about those who follow the "best practice" proposed by the core example.
Stop dreaming 😆
Yep, understood that. I didn't get you wrong. But think about it (again from 3rd party). Your change means that it is expected for templates to put their files into the media/template/foo folder. Let's think about it a bit: |
Obviously, the big players have their own tools and I don't expect them to follow the core here. But for many developers, small shops this could be a great help or if you prefer a good way to attract devs to use this product instead of something else. Of course for those that are already offering a number of modules/components/plugins/templates, our tools will have 0 effects as they already have a working toolchain that covers their specific needs (distribution, etc). The idea is not to eliminate other peoples tools but provide sanely and simple tools for the newcomers. How do you expect to grow in a world that every half decent project already provides a great cli for RAD? |
**I'll skip the first sentence here. ** Maybe I should stop pushing for any change, as it seems that people are happy with all the well supported, well documented dying technologies that are quite familiar... |
We're talking about the minimising scripts here, right? Those aren't specific to Joomla at all.
And here the ultimate "shut down" arguments which are completely offtopic start again. |
|
@Bakual please stop commenting, you have no clue what I'm suggesting and all your comments are totally irrelevant... |
Then by all means explain |
|
What do you want me to explain? The |
|
I understood that part, and haven't said anything against that part. I'm fine with moving the source files to whatever place you want them. |
Those changes affect ONLY components/modules/plugins/templates that will use the tool (eg: mainly the core). Joomla as always is not dictating anything, so you can still have your |
It's not dictating, that's true. But it sets "best practice" by example and "good devs" are expected to follow the conventions. Or do you think it will look nice if there are folders for components/plugins/modules/templates and 3rd parties still put their assets in to media/com_foo?
Serious question here because I really don't know: Why would I need a "Joomla tool" for compiling ES6 or vuejs? Afaik those are pretty standard jobs to do which are quite unrelated to Joomla. |
|
The idea is going in the right direction, looking for a way to support JavaScript Apps, SPA, etc; and our current set of assorted scripts that Joomla is packing today. Before accepting a media-source as the right place to locate the source code, I would like to know what are the long-term goals:
In general, my questions are:
As far as I am aware, the currently supported use case is the legacy method for the regular desktop setup, and support for a modern mobile ecosystem is out of the picture. |
|
Im a fan of the src folder for assets, but I would prefer a resources folder on extension level. |
That is also another approach but due to the current structure of Joomla this will make the tooling way too inefficient (way too many folders to watch and recurse). But I'm ok if we decide to go that way (by the way since we have backend/front end scatter code which one will be the true source of code?)
@anibalsanchez that is the idea and since we already have an app already build on Vue we should expose the how-to so people can follow. Basically, if you clone this and check the |
hm, I always thought it already like that, |
|
Yeah, there are always ways to hack your way around. What a value most of this PR is the idea of trying to introduce a proper method to support them at the core level. I plan to test it as soon as I have time to review it in detail. |
This PR doesn't magically make core support SPA infrastructure. Likewise, nothing about the core infrastructure today (3.x, not just 4.0) can't support SPA, you just have an ecosystem not written to support it and if you really want to use Joomla in that structure you're stuck doing a lot of heavy lifting on your own as a result.
Joomla is not designed out-of-the-box as a page builder solution and taking an existing CMS and making such a major editorial workflow change like that, unless you somehow already have major VC and investor demand for it, is nothing short of controversial and polarizing to the existing ecosystem and would cause more harm than good.
If you expect to just take anything off the Joomla ecosystem and use it, you're probably right. You're trying to build for a use case that core can support but the manner in which most extensions are packaged and delivered doesn't. There are only so many changes core can make to suit your workflow, good luck convincing the rest of the ecosystem to follow your desires. |
|
I'm slightly unsure about the I mean we don't need to override css assets - it's cascading and we support having the custom.css file still at the template level - so it's really just about js assets I guess - and I'm not sure whether there's a major advantage to that or not Otherwise everything else seems totally sensible to me |
I think my explanation here caused a lot of misunderstanding. Let me explain a little bit the situation HTMLHelper::_('stylesheet', 'template' . ($this->direction === 'rtl' ? '-rtl' : '') . '.css', ['version' => 'auto', 'relative' => true]);This means that the asset (css/js) can be overrided but the override is the source If we move the files to HTMLHelper::_('stylesheet', 'media/templates/administrator/' . $this->template . '/css/template' . ($this->direction === 'rtl' ? '-rtl' : '') . '.css', ['version' => 'auto', 'relative' => false]);Will put us to the exact same spot we were before moving the assets to the media folder (template css and js are't overridable). I guess this clears up what I meant by assets becoming overridable and that is down to us if we want to allow such change, so moving the assets will not change the previous behaviour if we don't want to change it! |
I guess it's more that I can see advantages of moving media to the media directory if the aim was to place all media in a common directory (kinda moving towards a structure of having entry folders like www/ in modern php apps - but ultimately all our overrides would still be placed in css/js - so I'm just struggling to see the benefit of this change. |
|
Afaik we only use the HtmlHelper for the template CSS and JS files so we can make use of the versioning feature and it automatically looks in the correct template folder ( |
Exactly what I had in my mind. Of course this needs the relevant change in the HTMLHelper::include method (one check if /media/templates/$clientId/$templateName exists we use the media for the overrides, if not we use the $clientId/templates/$templateName so 100% B/C). |
|
Let's get the sources separated as this is quite urgent and then we can talk about the restructuring and other exotic ideas. I'm closing this, small steps... |
12 participants
Summary of Changes
Restructure the media folder to meet the 2018 requirements.
In short:
media-sourcewhich as the name indicates contains the sourcesvueis introduced and will render any SPA, check out this branch and runnpm run build:mediaManto get the media manager.build/mediamedia-sourcerm -rf media-sourcebefore packagingWhy?
The javascript group had already discussed a way to implement something similar to Laravel's mix. This is my personal take.
So why this is even a thing?
Basically, with this structure, the core development stack provides the necessary tools to build everything for the front end, supporting components/modules/plugins/templates.
Here is how it looks like
Testing Instructions
Warning: This will not compile the assets correctly right now as the build tools are not yet adjusted!!!
Documentation Changes Required
This affects only the developers but I see it as a huge step forward, providing sensible tools means we care...
Of course this needs plenty of documentation
@yvesh @dneukirchen @mbabker @wilsonge @laoneo @Fedik @anibalsanchez