project: Moodle
summary: Improvements to dynamic scss compilation/caching etc
description: Dynamic SCSS compilation is an extremely heavy weight process, there are improvements we can do to improve the way it works for user and developers

1.summary: Compile SCSS files on the command-line
description: Rather than delegating it to a user request in the browser (and involving loadbalancer/php timeouts and so on). There should be a way to at least have the scss compiled on the command line (ideally it would be part of the cli installer process too). As suggested by mrverrall in his blog post:
2.summary: Investigate Petrs patches to sabberworm/PHP-CSS-Parser
description: skodak has contributed some patches to sabberworm/PHP-CSS-Parser but we didnt take them up (Thanks Petr for pinging). Given , we should investigate fred raised this and mentioned to me: bq. And on a side note, it seems that Petr had also improved the library to support fontAwesome properly. We never had to look into his patch because it worked, maybe now is the time. He said he brought the processing from 70 to 3.5s, and I know now his patch fixes something similar to mine
3.summary: Store last successful compilation in tempdir
description: When generating CSS content, store the last successful compilation for that theme in tempdir. This will allow a closer approximation whilst waiting for the theme to compile leading to a better UX.
4.summary: Use fallback CSS whilst waiting for CSS to build
description: When serving Just-in-time compiled themes, we should serve a fallback version of the theme while it is compiling. if the theme is currently available in localcache for the requested revision, serve it immediately and stop. if the theme revision is found in MUC, copy it to localcache, serve it immediately and stop. if theres a previous copy of the the theme, serve it now and _do not die_; attempt to get a lock for the theme generation if the fallback was served and it was not possible to get a lock, die immediately - there is no point generating the theme as it wont be served anyway. generate the new theme instance if the fallback was served, die immediately - there is no point serving the newly generated theme as the client has closed the connection. serve the newly generated theme
5.summary: Investigate lock timeout in styles.php
description: do we need to extend it? for clients waiting on the lock, how frequently do they retry and does this need to change?
6.summary: Provide a way to pre-compile all site themes during CLI upgrade and install
description: Look at: a Scheduled Task; or an Adhoc Task; or Grunt; or Some combination of the above. This will help where course themes are in use, and to disperse the load away from the frontend. This will help hosted solutions in particular. We should pre-compile the current site theme after a cli upgrade.
7.summary: Investigate off-loading the compilation of SCSS to a CLI Compiler
description: Need to consider: which compiler; arguments; whether this is a viable option or if the results are too different or unreliable; when to do this (theme designer mode only)
8.summary: Check vendor prefix list for agreed standards
description: Related to bawjawss comment in , we should look at whether the list of vendor prefixes needs to change based on whether those standards have now been agreed upon. The list of auto-prefixes is as follows: animation appearance backface-visibility box-sizing box-shadow background-clip background-size box-shadow column-count column-gap perspective touch-action transform transition transition-timing-function transition-duration transition-property user-select See
9.summary: New function to store CSS content for a theme
description: Basically, rewrite css_write_css to: take a theme name/config; take a revision; and take the compiled cSS then write to all agreed-upon locations: localcache (existing); MUC (); and temp ().
10.summary: Kill off CSS chunking and non-SVG support
description: This was for IE <= version 9. We no longer support these and the presence of chunking support complicates our processing.
11.summary: Use a per theme revision number to allow targeting specific themes for caching
description: At the moment we have a single theme revision number that is used for caching the compile CSS for themes. That means that as soon as one theme is recompiled the whole cache needs to be cleared in order to increment the revision number. This means we potentially lose cached theme CSS that hasnt changed and will need to be recompiled next page hit.

Below is an instruction that describes a task, paired with an input that provides an epic with this format: 
"project": "Name of the project" 
"summary": "Summary of the epic user story" 
"description": "Description of the epic user story". Write a response that appropriately completes the request.### Instruction:
Break this epic user story into smaller tasks to help the developers understand the epic better, you can divide this epic into as much as you want depending on the complexity of the epic.
### Input:
project: Moodle
summary: Improvements to dynamic scss compilation/caching etc
description: Dynamic SCSS compilation is an extremely heavy weight process, there are improvements we can do to improve the way it works for user and developers

### Response:
1.summary: Compile SCSS files on the command-line
description: Rather than delegating it to a user request in the browser (and involving loadbalancer/php timeouts and so on). There should be a way to at least have the scss compiled on the command line (ideally it would be part of the cli installer process too). As suggested by mrverrall in his blog post:
2.summary: Investigate Petrs patches to sabberworm/PHP-CSS-Parser
description: skodak has contributed some patches to sabberworm/PHP-CSS-Parser but we didnt take them up (Thanks Petr for pinging). Given , we should investigate fred raised this and mentioned to me: bq. And on a side note, it seems that Petr had also improved the library to support fontAwesome properly. We never had to look into his patch because it worked, maybe now is the time. He said he brought the processing from 70 to 3.5s, and I know now his patch fixes something similar to mine
3.summary: Store last successful compilation in tempdir
description: When generating CSS content, store the last successful compilation for that theme in tempdir. This will allow a closer approximation whilst waiting for the theme to compile leading to a better UX.
4.summary: Use fallback CSS whilst waiting for CSS to build
description: When serving Just-in-time compiled themes, we should serve a fallback version of the theme while it is compiling. if the theme is currently available in localcache for the requested revision, serve it immediately and stop. if the theme revision is found in MUC, copy it to localcache, serve it immediately and stop. if theres a previous copy of the the theme, serve it now and _do not die_; attempt to get a lock for the theme generation if the fallback was served and it was not possible to get a lock, die immediately - there is no point generating the theme as it wont be served anyway. generate the new theme instance if the fallback was served, die immediately - there is no point serving the newly generated theme as the client has closed the connection. serve the newly generated theme
5.summary: Investigate lock timeout in styles.php
description: do we need to extend it? for clients waiting on the lock, how frequently do they retry and does this need to change?
6.summary: Provide a way to pre-compile all site themes during CLI upgrade and install
description: Look at: a Scheduled Task; or an Adhoc Task; or Grunt; or Some combination of the above. This will help where course themes are in use, and to disperse the load away from the frontend. This will help hosted solutions in particular. We should pre-compile the current site theme after a cli upgrade.
7.summary: Investigate off-loading the compilation of SCSS to a CLI Compiler
description: Need to consider: which compiler; arguments; whether this is a viable option or if the results are too different or unreliable; when to do this (theme designer mode only)
8.summary: Check vendor prefix list for agreed standards
description: Related to bawjawss comment in , we should look at whether the list of vendor prefixes needs to change based on whether those standards have now been agreed upon. The list of auto-prefixes is as follows: animation appearance backface-visibility box-sizing box-shadow background-clip background-size box-shadow column-count column-gap perspective touch-action transform transition transition-timing-function transition-duration transition-property user-select See
9.summary: New function to store CSS content for a theme
description: Basically, rewrite css_write_css to: take a theme name/config; take a revision; and take the compiled cSS then write to all agreed-upon locations: localcache (existing); MUC (); and temp ().
10.summary: Kill off CSS chunking and non-SVG support
description: This was for IE <= version 9. We no longer support these and the presence of chunking support complicates our processing.
11.summary: Use a per theme revision number to allow targeting specific themes for caching
description: At the moment we have a single theme revision number that is used for caching the compile CSS for themes. That means that as soon as one theme is recompiled the whole cache needs to be cleared in order to increment the revision number. This means we potentially lose cached theme CSS that hasnt changed and will need to be recompiled next page hit.
