Why does Moodle use PHP + MySQL for Images

Why does Moodle use PHP + MySQL for Images

by Curious L -
Number of replies: 2

I am genuinely curious about why Moodle uses PHP and MySQL to render images, Javascript, CSS, and more. Every asset has .php in the URL.

Why doesn't Moodle allow Nginx/Apache to serve static resources directly? These systems are fast and efficient at delivering static content. Why would you reinvent the wheel?

I realize that Moodle caches the CSS, JS, and images, but adding assets to the database and calling PHP is completely unnecessary in the first place. Does any other large PHP project serve files like this? I've never seen this before.

Not only does this create extra unnecessary calls to PHP and MySQL, it also completely breaks CDNs like CloudFlare. CloudFlare can deliver static assets much faster and simpler than Moodle can. 

If this is done for SCSS, there are other ways to render these assets ahead of time. If it's to authenticate permission to access a file, why would you need to do that for theme assets. I am so confused.

Is there a way to disable this functionality?

What am I missing?

Average of ratings: -
In reply to Curious L

Re: Why does Moodle use PHP + MySQL for Images

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Is the content really static? Which images are we talking about?
Average of ratings: -
In reply to Curious L

Re: Why does Moodle use PHP + MySQL for Images

by Leon Stringer -
Picture of Core developers Picture of Particularly helpful Moodlers

Why doesn't Moodle allow Nginx/Apache to serve static resources directly? – It does: configure $CFG->xsendfile (Nginx-specific instructions).

[…] it also completely breaks CDNs like CloudFlare. CloudFlare can deliver static assets much faster and simpler than Moodle can. – Potentially faster, simpler and wrong. For example, theme SCSS can be customised, Moodle will then regenerate the cache and serve the change immediately, the CDN will serve the stale content.

A lot of "static" content is held in Moodle's caching systems so database access is not necessarily involved after the initial load. Caching is configurable, some stores will hold items in memory. Page resources like JavaScript, CSS and images tend to be read from the Moodle server-side cache and then cached by the browser for the remainder of that session.

As I see it Moodle has to walk the line between optimising content delivery and ensuring the right users get the right content in an LMS where there can be a lot of changes to data. If you look under the hood at how that's done you'll see a lot of work has gone into tuning performance.

But there can always be improvement. If you have specific examples of items which could be improved then please share them – there's a Hardware and Performance forum for discussion of performance issues – or add them to the Tracker.

Average of ratings: Useful (1)