Benefits of putting design resources under site asset

[mrgrahambird]

Matrix Version: 5.3.2.0

I’ve noticed that Squiz’s own instances of Matrix typically show a site called “Designs”. However, there is already a “Designs” folder in the system. What are the benefits of putting Design files, Paint Layouts, CSS or otherwise under a site rather than using the native folder for this purpose?

Thanks,

Graham

[Bart]

The benefit is more so that you can contain design files separately to the sites/projects that require them. Rather than keeping them all in a global place.
If you keep all of your design files in the root design folder, you also have to apply all URLs of all your sites to that designs folder, meaning that a CSS file that is only used on one site could potentially get many uncessesary URLs/webpaths applied to it.

I spoke about it briefly at last year’s seminar https://matrix.squiz.net/resources/media/squiz-summit-2016/squiz-matrix-implementation-tips-and-tricks and you can download the system and site templates that I used in that talk here https://matrix.squiz.net/resources/templates/system-templates

[Douglas]

If you keep all of your design files in the root design folder, you also have to apply all URLs of all your sites to that designs folder, meaning that a CSS file that is only used on one site could potentially get many uncessesary URLs/webpaths applied to it.

Bart, you may recall me asking when you visited here in 2016 if we might ever see something documenting the standard Squiz Asset Map layout? I’ve wondered about querying if that system templates manuals page might see some documentation at some point with more explanation of the setup? I’ll have to give that video a good watching.

We do use the system Designs folder on our main Matrix instance (it has more assets, so I’ll call it the ‘main instance’). The web urls on that folder are only for two (of thirty one) of the system root urls, with ‘_designs’ suffixes. Individual Designs have again, just two urls, with urls matching the folder structure.

That doesn’t seem to match what you’re saying about having to apply the urls of all our sites to the designs folder?

[Bart]

Bart, you may recall me asking when you visited here in 2016 if we might ever see something documenting the standard Squiz Asset Map layout? I’ve wondered about querying if that system templates manuals page might see some documentation at some point with more explanation of the setup? I’ll have to give that video a good watching.

Yes, I remember. And we are overdue for creating some supporting documentation for that, or some best practice points at the least.

We do use the system Designs folder on our main Matrix instance (it has more assets, so I’ll call it the ‘main instance’). The web urls on that folder are only for two (of thirty one) of the system root urls, with ‘_designs’ suffixes. Individual Designs have again, just two urls, with urls matching the folder structure.

That doesn’t seem to match what you’re saying about having to apply the urls of all our sites to the designs folder?

I guess it really depends on your situation. The designs folder is at it’s core, just a site asset with a different icon really, and type code. You are free to use that for global files or just for 1 site or whatever. The benefit of moving everything under a global folder instead, is so that you can have additional global resources under there, not just things that need to sit under a site asset with a URL.

The problem in the past was that users used to often put ALL of their media files under that designs folder, which caused it to have every single site URL applied. If you are not doing that then it still makes sense to use it.

What we want to do in the future is probably have the ability for users to create their own “design folders” anywhere in the site, and not create one on the root of the system by default. The only default assets we really need are the Trash, System Config, and Users Folder really. The Designs, Media, and Web Services folders have really lost significance as their functionality can easily be replicated with just a Site asset.

Hopefully that makes sense and clarifies it a bit.

[quimby]

Bart’s already answered, but adding my 2c. We use a ‘_designs’ site for every site we build as well, helps organise everything, keeps permissions clean, etc. Also has some neat features like we can put assets into safe edit and only sys admins can see the changes, not even authors on the site can see it.

Having said that, we also have a _lib site, which sits off to the side and has every site URL applied to it (so yes there’s multiple), where we store truly global stuff like 3rd-party libraries, etc.

[mfong]

I’d also note that as sites were added and deleted from a Matrix instance, having a common Designs folder with everything in it often made it very hard to determine what could and couldn’t be safely cleaned up, leading to unnecessary bloat over time.

[Douglas]

And we are overdue for creating some supporting documentation for that, or some best practice points at the least.

As noted it would be helpful for that to be shared in some fashion - and hopefully with some explanation that there are cases like you suggest around when using the designs folder makes sense. I think we might be asking for something via formal channels.

An earlier standard practice we were shown by Squiz NZ staff was to keep assets that would never need a webpath separate from any site assets in a folder alongside, having webpaths creating a system load that should be avoided. Pages + images + files went into site assets, while listings and other mechanisms maybe did or didn’t depending on the implementer. Is this practice still encouraged - the new paradigm using Site Assets suggests perhaps not?

I’d also note that as sites were added and deleted from a Matrix instance, having a common Designs folder with everything in it often made it very hard to determine what could and couldn’t be safely cleaned up, leading to unnecessary bloat over time.

Bloat and cruft isn’t unique to Matrix and dealing with it is both a mixture of process (tidying up after development, removing old crufty assets/files/lines of code) and technical solutions (having ways to know what isn’t in use). What would be nice is some improvements in Matrix to provide technical solutions.

[mfong]

Bloat and cruft isn’t unique to Matrix and dealing with it is both a mixture of process (tidying up after development, removing old crufty assets/files/lines of code) and technical solutions (having ways to know what isn’t in use). What would be nice is some improvements in Matrix to provide technical solutions.

If you have a Squizmap account, see https://squizmap.squiz.net/matrix/5701 for the work that’s been done over time to improve the Safe Trash feature’s ability to detect assets in use.