CSS

If you're at all concerned about performance, it's always better to keep your css (and js) in static files. Storing these in MODX means loading php and all the overhead associated with retrieving a MODX resource.

You also miss out on browser caching which means visitors have to download the same file again on every page load instead of simply downloading it once and then pulling it from a local cache next time it's needed.

@Lucas:

... it's always better to keep your css (and js) in static files ...

That's simply untrue. This depends on what you are doing with it. For instance, with MODX you can modify static files upon request and this will manipulate performance statistics, as well. The only way to remove MODX from performance statistics is to STORE the files outside of anywhere MODX has any control. Otherwise, it is subject to MODX security and other access parameters whether it is static or not. Even then, performance is subject to .htaccess and the way it manages URI requests. A poorly programmed .htaccess may affect performance of any site regardless of whether it is static, dynamic, in MODX or outside of any CMS.

You also miss out on browser caching..

Untrue, as well. Browser caching is based upon URI, content type, and content expiration. All of these may be set by whatever server script you would like. How the server serves it determines whether or not the browser may cache it. PHP, ASP, etc have nothing to do with it. You may serve cached PHP for instance.

Further Notes:

These options are set in the HTTP header. PHP has many such options to provide access to the HTTP Header. The only distinction is that it must be modified and served before any content is returned. If this were not the case, PHP minified CSS and JS coulld not be browser cached. In many cases they can and are browser cached. Your statement also removed server caching from the equation. Server caching can further manipulate performance statistics.

Additionally, there is argument as to whether browser caching is even preferable. It is largely based on the caching mechanism, because it is subject to the functionality of the browser itself. Browser caching is often linked to poor performance and even lack of performance. As a result, it is often the very first troubleshooting step in resolving most site-specific issues. How the code is designed, and how the interpreters utilize it will always be the deciding factor in performance, and whether caching is necessary or even desired. [ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]

@Frogabog

Don't be humbled. Be inspired! That is what MODX is all about.

Otherwise, it is subject to MODX security and other access parameters whether it is static or not.

This really is not the case - under a normal server configuration if a file called 'style.css' exists on the server then it will be served up directly without invoking MODX (and PHP). I wasn't referring to MODX static resources.

When speaking about performance, it is best not to speak generally unless you state that it is a general statement.

In that case, and going by the general nature of the original post, let it be stated that this was a general statement


My thoughts are pretty well summed up (along with some nice alternatives) in the 'answered' post here:
http://stackoverflow.com/questions/11853063/why-arent-php-files-used-for-custom-css-and-js [ed. note: okyanet last edited this post 14 years, 1 month ago.]

Indeed, don't get confused between a "static resource", which can act as a .css or .js resource, and a file directly accessed from the file system.

When your browser sees the stylesheet link, or a javascript href, it requests that resource using the URI attribute of the link or script tag. If it happens to be a MODx resource, then MODx is involved, processing the request and the requested resource just like any page (index.php?q=stylesheet.css). If it happens to be a direct file request, then it get served directly, MODx is not involved at all (assets/style/stylesheet.css).

If your stylesheet reference in your HTML head is to a MODx resource, that resource can be cached by the MODx cache system like any other MODx resource, minimizing the processing MODx does, again like any other MODx resource. The browser will do its own caching thing in either case, since it doesn't care where the .css file came from.

That's why the .htaccess file has these conditions:

@Lucas

... let it be stated that this was a general statement

Touche!!

under a normal server configuration if a file called 'style.css' exists...

Absolutely correct, unless .ht management or some other server parameter interferes. However, unless I'm misunderstanding the general nature of the OP, CSS and JS is often encouraged to be placed in a Media Source directory. If that is the case, and Media Source Directories are static files that have no MODX security (due to the nature of them being static files), then my previous statement was incorrect, but we've also invalidated the need for Media Source security completely.

However, my understanding is that files in the Media Source directories do indeed have MODX security standards placed upon them and my statement would be accurate. Again, that is provided my understanding of Media Source directory access is correct. Could you elaborate on security regarding files in the Media Source directories?

I wasn't referring to MODX static resources.

Absolutely understood, and neither was I. Media Source files are not Static Resources either. They are still part of the MODX subsystem and may still be manipulated by MODX plugins, snippets, etc.

... in the 'answered' post here:...

+1 for the link. It actively presents exactly some of the points from the both of us and many alternatives.

@Sottwell

Thanks for further clarification on both sides. Would you care to elaborate on files within the Media Source directories and how security in MODX handles those, as I believe this is where the core of the discrepancy in understanding is. In regard to files outside of Media Sources, Lucas is absolutely correct, which was stated in my original post.

Could you elaborate on security regarding files in the Media Source directories

This is really for users who are logged in to the manager (or a front end interface) and is used to restrict their ability to list, update or remove files within directories contained within a Media Source.

Imagine you are an admin user and through the Files tab you are able to browse and make changes to the core MODX files. This is obviously something most users should not be able to do. By creating a Media Source for the /assets/images folder for example, we can allow them to upload images without being able to view and tamper with files outside of that folder.

It doesn't affect the ability of any user to directly load a file via its full url - images are a great example of this in action. Anyone will be able to view an uploaded image in their browser, unless it is protected in some other way (such as an .htaccess):
www.site.com/assets/images/image.jpg

That's my understanding of how Media Source security works. If you want to restrict front-end access to a specific file on the filesystem (eg. a password-protected PDF download) that's where MODX Static Resources with appropriate user permissions are useful.

Apologies to the OP - this is all probably a bit more than you expected

It doesn't affect the ability of any user to directly load a file via its full url ..

I certainly hope this is not correct as I will have to perform some significant tests in this regard. Pending the results of a new post, I amend my original post to: my preference is to avoid the Media Source entirely unless there is a stronger security model backing the files. But again, understand that my bias is that I am a paranoid twit.

Apologies to the OP - this is all probably a bit more than you expected ..

Agreed! However, I think it was more than any of us expected either. Good, useful information and dialogue, though!! Hopefully, it provides some good, balanced information with which to make the decisions. [ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]

Hey - it's better to be paranoid than complacent about web security. There isn't really a lot of documentation on Media Sources, they're a fairly recent addition. Let us know how your tests get on!

Will do! The topic of Media Sources and security is a real concern to me, given my new site. I was hoping to allow users to upload source code, but that will have to remain on hold until I have some clear results regarding the security of Media Sources. Oh well, we are taught to throw out 1/2 of the features we want anyway... *sigh*