ylqjgm
/
canvas-lms
mirror of https://github.com/instructure/canvas-lms.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
canvas-lms/lib/brandable_css.rb

363 lines
17 KiB
Ruby
Raw Normal View History

da licença part 26 add consistent license headers to all source files (ruby, coffeescript, javascript) except for vendor files Change-Id: I74f079254fdbff56b4f9d7013b01f11fc862777a Reviewed-on: https://gerrit.instructure.com/110049 Tested-by: Jenkins Reviewed-by: Jon Jensen <jon@instructure.com> Product-Review: Jon Jensen <jon@instructure.com> QA-Review: Jon Jensen <jon@instructure.com>
2017-04-28 03:59:16 +08:00
#
# Copyright (C) 2015 - present Instructure, Inc.
#
# This file is part of Canvas.
#
# Canvas is free software: you can redistribute it and/or modify it under
# the terms of the GNU Affero General Public License as published by the Free
# Software Foundation, version 3 of the License.
#
# Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
# A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
# details.
#
# You should have received a copy of the GNU Affero General Public License along
# with this program. If not, see <http://www.gnu.org/licenses/>.
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
require 'pathname'
require 'yaml'
don't proceed like normal if brandable_css cmd fails fixes: CNVS-23632 it turns out, the way I was doing this ruby would create a sh subprocess and brandable_css would be it's subprocess. so $? would be the sh process (which would always exit successfully). test plan: * in theme editor, try to preview a theme * but before you do, do something to make it so brandable_css will fail (like uninstall node or rm -rf node_modules or use activity monitor to view active processes and kill brandable_css when it appears) * it should say "something went wrong generating..." instead of continuing like everything worked Change-Id: I3c80c18381bb52c71d4b79d5b151988d6cf5cc3b Reviewed-on: https://gerrit.instructure.com/63948 Reviewed-by: Jacob Fugal <jacob@instructure.com> Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-09-25 01:37:49 +08:00
require 'open3'
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
include asset host in theme json files also include asset host in ENV.active_brand_config_json_url closes CNVS-29764 test plan - use a real s3 bucket for canvas cdn - create a new theme - should have one custom image uploaded - should have some default images - in the browser console `ENV.active_brand_config_jons_url` should include the asset host - open the json url - default and custom image urls should work Change-Id: I1dd1c11617db624e93686da706b94afee738df12 Reviewed-on: https://gerrit.instructure.com/81445 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
2016-06-03 06:15:44 +08:00
module BrandableCSS
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
APP_ROOT = defined?(Rails) && Rails.root || Pathname.pwd
CONFIG = YAML.load_file(APP_ROOT.join('config/brandable_css.yml')).freeze
BRANDABLE_VARIABLES = JSON.parse(File.read(APP_ROOT.join(CONFIG['paths']['brandable_variables_json']))).freeze
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
MIGRATION_NAME = 'RegenerateBrandFilesBasedOnNewDefaults'.freeze
Create predeploy rake task to handle Theme Editor closes: CNVS-21990 This is the rake task we call from a job server once that has new code before restarting all the app servers. It will make sure that our s3 bucket has all static assets including the css for custom themes people have created in the Theme Editor test plan: * make sure you have an config/canvas_cdn.yml file * `rm -rf public/dist` * run `bundle exec rake brand_configs:generate_and_upload_all` * in log/development.log you should see it write a _variables.scss file for each brand_config in any shard to disk, compile the css for each of those brands and push all the js/css/images/etc to s3 * browse pages in canvas, the css/images/js should be served from your "host:" configured in canvas_cdn.yml and none should 404 this change also includes: better error message when brandable_css manifest doesn't exist if the manifest file can't be found, this will tell you the full path to the file it was looking for so that if it can't find the manifest file,it will tell you the path to the file it was looking for. test plan: with RAILS_ENV=production: * rm -rf public/dist * try to access a page the error that it give you should tell you the full path to the json file it tried to read. if we haven't loaded rails yet, we still want to look at RAILS_ENV to get which style of css to generate Change-Id: I2dbb12541d6a28e90a326a51f0cddb90f313842f Reviewed-on: https://gerrit.instructure.com/58809 Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com>
2015-07-20 23:49:03 +08:00
use_compressed = (defined?(Rails) && Rails.env.production?) || (ENV['RAILS_ENV'] == 'production')
SASS_STYLE = ENV['SASS_STYLE'] || ((use_compressed ? 'compressed' : 'nested')).freeze
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
translate brandable css variable names test plan: * theme editor variable names, group names and helper text should all be lolcalized closes #CNVS-23768 Change-Id: I01846a0c0354342cc5593d6ac153f117ccc39b64 Reviewed-on: https://gerrit.instructure.com/65809 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: Clare Strong <clare@instructure.com> Product-Review: James Williams <jamesw@instructure.com>
2015-10-26 22:59:25 +08:00
VARIABLE_HUMAN_NAMES = {
Change main font color through Theme Editor Fixes: CNVS-30709 Test plan: - Clear cache / restart Canvas - Go to Theme Editor in your Canvas instance - You should now see a new field for Main Text Color, as well as some new additions to the test page on the right of the Theme Editor sidebar: http://screencast.com/t/JrBJ0FgOxbA - Updating the value of this field with a new HEX color should change the main font color of Canvas, as well as the secondary links (like the cog dropdown) that also use the main text color. - I did a find-and-replace for `color: $ic-color-dark` --> `color: $ic-font-color-dark`, which is why there are so many files in this commit. Because $ic-color-dark has the same HEX color as $ic-font-color-dark, however, there should be zero impact to all these changes. They were just done so users can now theme the colors via Theme Editor. Change-Id: Idabfa6649ecf40e439df4a8672529ea6dbd7fa01 Reviewed-on: https://gerrit.instructure.com/89934 Tested-by: Jenkins Reviewed-by: Stephen Jensen <sejensen@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Chris Hart <chart@instructure.com>
2016-09-09 04:39:50 +08:00
"ic-brand-primary" => lambda { I18n.t("Primary Brand Color") },
"ic-brand-font-color-dark" => lambda { I18n.t("Main Text Color") },
"ic-link-color" => lambda { I18n.t("Link Color") },
translate brandable css variable names test plan: * theme editor variable names, group names and helper text should all be lolcalized closes #CNVS-23768 Change-Id: I01846a0c0354342cc5593d6ac153f117ccc39b64 Reviewed-on: https://gerrit.instructure.com/65809 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: Clare Strong <clare@instructure.com> Product-Review: James Williams <jamesw@instructure.com>
2015-10-26 22:59:25 +08:00
"ic-brand-button--primary-bgd" => lambda { I18n.t("Primary Button") },
"ic-brand-button--primary-text" => lambda { I18n.t("Primary Button Text") },
"ic-brand-button--secondary-bgd" => lambda { I18n.t("Secondary Button") },
"ic-brand-button--secondary-text" => lambda { I18n.t("Secondary Button Text") },
"ic-brand-global-nav-bgd" => lambda { I18n.t("Nav Background") },
"ic-brand-global-nav-ic-icon-svg-fill" => lambda { I18n.t("Nav Icon") },
"ic-brand-global-nav-ic-icon-svg-fill--active" => lambda { I18n.t("Nav Icon Active") },
"ic-brand-global-nav-menu-item__text-color" => lambda { I18n.t("Nav Text") },
"ic-brand-global-nav-menu-item__text-color--active" => lambda { I18n.t("Nav Text Active") },
"ic-brand-global-nav-avatar-border" => lambda { I18n.t("Nav Avatar Border") },
"ic-brand-global-nav-menu-item__badge-bgd" => lambda { I18n.t("Nav Badge") },
add option to set badge text in theme "global nav" Fixes: CNVS-28071 test plan: - as an admin using new ui - navigate to theme editor - click the second section "Global Navigation" - you should now see a field titled "Nav Badge Text" customize the nav badge background color AND the nav badge text color to ensure it is working properly (example: http://screencast.com/t/fgZ0qsUE0EUT) Change-Id: I8924ab90b29e0282585c9244cc8c1add9eef2d0b Reviewed-on: https://gerrit.instructure.com/75773 Tested-by: Jenkins QA-Review: Nathan Rogowski <nathan@instructure.com> Reviewed-by: Colleen Palmer <colleen@instructure.com> Product-Review: Colleen Palmer <colleen@instructure.com>
2016-03-31 02:11:36 +08:00
"ic-brand-global-nav-menu-item__badge-text" => lambda { I18n.t("Nav Badge Text") },
translate brandable css variable names test plan: * theme editor variable names, group names and helper text should all be lolcalized closes #CNVS-23768 Change-Id: I01846a0c0354342cc5593d6ac153f117ccc39b64 Reviewed-on: https://gerrit.instructure.com/65809 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: Clare Strong <clare@instructure.com> Product-Review: James Williams <jamesw@instructure.com>
2015-10-26 22:59:25 +08:00
"ic-brand-global-nav-logo-bgd" => lambda { I18n.t("Nav Logo Background") },
"ic-brand-header-image" => lambda { I18n.t("Nav Logo") },
"ic-brand-watermark" => lambda { I18n.t("Watermark") },
"ic-brand-watermark-opacity" => lambda { I18n.t("Watermark Opacity") },
"ic-brand-favicon" => lambda { I18n.t("Favicon") },
"ic-brand-apple-touch-icon" => lambda { I18n.t("Mobile Homescreen Icon") },
"ic-brand-msapplication-tile-color" => lambda { I18n.t("Windows Tile Color") },
"ic-brand-msapplication-tile-square" => lambda { I18n.t("Windows Tile: Square") },
"ic-brand-msapplication-tile-wide" => lambda { I18n.t("Windows Tile: Wide") },
"ic-brand-right-sidebar-logo" => lambda { I18n.t("Right Sidebar Logo") },
"ic-brand-Login-body-bgd-color" => lambda { I18n.t("Background Color") },
"ic-brand-Login-body-bgd-image" => lambda { I18n.t("Background Image") },
"ic-brand-Login-body-bgd-shadow-color" => lambda { I18n.t("Body Shadow") },
"ic-brand-Login-logo" => lambda { I18n.t("Login Logo") },
"ic-brand-Login-Content-bgd-color" => lambda { I18n.t("Top Box Background") },
"ic-brand-Login-Content-border-color" => lambda { I18n.t("Top Box Border") },
"ic-brand-Login-Content-inner-bgd" => lambda { I18n.t("Inner Box Background") },
"ic-brand-Login-Content-inner-border" => lambda { I18n.t("Inner Box Border") },
"ic-brand-Login-Content-inner-body-bgd" => lambda { I18n.t("Form Background") },
"ic-brand-Login-Content-inner-body-border" => lambda { I18n.t("Form Border") },
"ic-brand-Login-Content-label-text-color" => lambda { I18n.t("Login Label") },
"ic-brand-Login-Content-password-text-color" => lambda { I18n.t("Login Link Color") },
"ic-brand-Login-footer-link-color" => lambda { I18n.t("Login Footer Link") },
"ic-brand-Login-footer-link-color-hover" => lambda { I18n.t("Login Footer Link Hover") },
"ic-brand-Login-instructure-logo" => lambda { I18n.t("Login Instructure Logo") }
}.freeze
GROUP_NAMES = {
"global_branding" => lambda { I18n.t("Global Branding") },
"global_navigation" => lambda { I18n.t("Global Navigation") },
"watermarks" => lambda { I18n.t("Watermarks & Other Images") },
"login" => lambda { I18n.t("Login Screen") }
}.freeze
HELPER_TEXTS = {
"ic-brand-header-image" => lambda { I18n.t("Accepted formats: svg, png, jpg, gif") },
"ic-brand-watermark" => lambda { I18n.t("This image appears as a background watermark to your page. Accepted formats: png, svg, gif, jpeg") },
"ic-brand-watermark-opacity" => lambda { I18n.t("Specify the transparency of the watermark background image.") },
"ic-brand-favicon" => lambda { I18n.t("You can use a single 16x16, 32x32, 48x48 ico file.") },
"ic-brand-apple-touch-icon" => lambda { I18n.t("The shortcut icon for iOS/Android devices. 180x180 png") },
"ic-brand-msapplication-tile-square" => lambda { I18n.t("558x558 png, jpg, gif (1.8x the standard tile size, so it can be scaled up or down as needed)") },
"ic-brand-msapplication-tile-wide" => lambda { I18n.t("558x270 png, jpg, gif") },
"ic-brand-right-sidebar-logo" => lambda { I18n.t("A full-size logo that appears in the right sidebar on the Canvas dashboard. Ideal size is 360 x 140 pixels. Accepted formats: svg, png, jpeg, gif") },
"ic-brand-Login-body-bgd-shadow-color" => lambda { I18n.t("accepted formats: hex, rgba, rgb, hsl") }
}.freeze
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
class << self
def variables_map
@variables_map ||= BRANDABLE_VARIABLES.each_with_object({}) do |variable_group, memo|
variable_group['variables'].each { |variable| memo[variable['variable_name']] = variable }
end.freeze
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
def variables_map_with_image_urls
@variables_map_with_image_urls ||= variables_map.each_with_object({}) do |(key, config), memo|
if config['type'] == 'image'
remove rails 4.0 support Change-Id: Id1900160375644ea33badaa9d9f9185fab6b81ac Reviewed-on: https://gerrit.instructure.com/92726 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins Product-Review: James Williams <jamesw@instructure.com> QA-Review: James Williams <jamesw@instructure.com>
2016-09-23 04:09:09 +08:00
memo[key] = config.merge('default' => ActionController::Base.helpers.image_url(config['default']))
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
else
memo[key] = config
end
end.freeze
end
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
def things_that_go_into_defaults_md5
variables_map.each_with_object({}) do |(variable_name, config), memo|
default = config['default']
if config['type'] == 'image'
# to make consistent md5s whether the cdn is enabled or not, don't include hostname in defaults
default = ActionController::Base.helpers.image_path(default, host: '')
end
memo[variable_name] = default
end.freeze
end
def migration_version
# ActiveRecord usually uses integer timestamps to generate migration versions but any integer
# will work, so we just use the result of stripping out the alphabetic characters from the md5
default_variables_md5_without_migration_check.gsub(/[a-z]/, '').to_i.freeze
end
def check_if_we_need_to_create_a_db_migration
rails 5.2 closes #CORE-1301 #CORE-1302 Change-Id: I687132b066d12cf35e3c7a593dff9b2a91337f33 Reviewed-on: https://gerrit.instructure.com/147220 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins Product-Review: James Williams <jamesw@instructure.com> QA-Review: James Williams <jamesw@instructure.com>
2018-04-17 23:07:21 +08:00
path = ActiveRecord::Migrator.migrations_paths.first
migrations = CANVAS_RAILS5_1 ?
ActiveRecord::Migrator.migrations(path) :
ActiveRecord::MigrationContext.new(path).migrations
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
['predeploy', 'postdeploy'].each do |pre_or_post|
migration = migrations.find { |m| m.name == MIGRATION_NAME + pre_or_post.camelize }
# they can't have the same id, so we just add 1 to the postdeploy one
expected_version = (pre_or_post == 'predeploy') ? migration_version : (migration_version + 1)
give better errors for initial_setup closes CORE-1981 test plan - rake db:initial_setup should tell you when you need to run compile_assets Change-Id: Ia63196a6c81dba11987104242eabdf6e8d29519e Reviewed-on: https://gerrit.instructure.com/170858 Reviewed-by: Cody Cutrer <cody@instructure.com> QA-Review: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> Tested-by: Jenkins
2018-11-03 00:54:31 +08:00
raise BrandConfigWithOutCompileAssets if expected_version == 92630630174579589147
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
raise DefaultMD5NotUpToDateError unless migration && migration.version == expected_version
end
end
def skip_migration_check?
# our canvas_rspec build doesn't even run `yarn install` or `gulp rev` so since
# they are not expecting all the frontend assets to work, this check isn't useful
Rails.env.test? && !Rails.root.join('public', 'dist', 'rev-manifest.json').exist?
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
def default_variables_md5
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
@default_variables_md5 ||= begin
check_if_we_need_to_create_a_db_migration unless skip_migration_check?
default_variables_md5_without_migration_check
end
end
def default_variables_md5_without_migration_check
Digest::MD5.hexdigest(things_that_go_into_defaults_md5.to_json).freeze
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
end
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
def handle_urls(value, config, css_urls)
return value unless config['type'] == 'image' && css_urls
"url('#{value}')" if value.present?
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
# gets the *effective* value for a brandable variable
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
def brand_variable_value(variable_name, active_brand_config=nil, config_map=variables_map, css_urls=false)
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
config = config_map[variable_name]
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
explicit_value = active_brand_config && active_brand_config.get_value(variable_name).presence
return handle_urls(explicit_value, config, css_urls) if explicit_value
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
default = config['default']
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
if default && default.starts_with?('$')
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
if css_urls
return "var(--#{default[1..-1]})"
else
return brand_variable_value(default[1..-1], active_brand_config, config_map, css_urls)
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
# while in our sass, we want `url(/images/foo.png)`,
# the Rails Asset Helpers expect us to not have the '/images/', eg: <%= image_tag('foo.png') %>
ThemeEditor: fix 404 to default preview images fixes: CNVS-22258 test plan: * open theme editor and open the "watermarks and other images section. you should not see any 404's in the browser console and you should see a default for each except for the 'watermark' * in IE, make sure you don't see a "broken link" image for the watermark Change-Id: Iea743e8efc5115e2f4dfae6b8d12f26d4f3f346f Reviewed-on: https://gerrit.instructure.com/59793 Reviewed-by: Jacob Fugal <jacob@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-08-01 06:38:28 +08:00
default = default.sub(/^\/images\//, '') if config['type'] == 'image'
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
handle_urls(default, config, css_urls)
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end
Use css variables for primary & secondary buttons closes: CNVS-38412 test plan: * check this out * run bundle exec rake brand_configs:generate_and_upload_all * compile assets * make sure buttons look how they did before * especially check in ie11 Change-Id: If1d87ef9fa5c184cc21b1b51212d26ee1c7c1da5 Reviewed-on: https://gerrit.instructure.com/120726 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-07-28 03:24:10 +08:00
def computed_variables(active_brand_config=nil)
[
['ic-brand-primary', 'darken', 5],
['ic-brand-primary', 'darken', 10],
['ic-brand-primary', 'darken', 15],
['ic-brand-primary', 'lighten', 5],
['ic-brand-primary', 'lighten', 10],
['ic-brand-primary', 'lighten', 15],
['ic-brand-button--primary-bgd', 'darken', 5],
['ic-brand-button--primary-bgd', 'darken', 15],
['ic-brand-button--secondary-bgd', 'darken', 5],
['ic-brand-button--secondary-bgd', 'darken', 15],
More conversions of sass vars to css vars Closes: CNVS-38435 Test plan: * check the places where these variables are used * they should look exactly how they did before * especially test these things in high contrast mode Change-Id: Idfb5a9f240d2710af1891eeb8a478678ac4c38bd Reviewed-on: https://gerrit.instructure.com/120896 Tested-by: Jenkins Reviewed-by: Pam Hiett <phiett@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-29 05:26:12 +08:00
['ic-brand-font-color-dark', 'lighten', 15],
['ic-brand-font-color-dark', 'lighten', 30],
['ic-link-color', 'darken', 10],
['ic-link-color', 'lighten', 10],
Use css variables for primary & secondary buttons closes: CNVS-38412 test plan: * check this out * run bundle exec rake brand_configs:generate_and_upload_all * compile assets * make sure buttons look how they did before * especially check in ie11 Change-Id: If1d87ef9fa5c184cc21b1b51212d26ee1c7c1da5 Reviewed-on: https://gerrit.instructure.com/120726 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-07-28 03:24:10 +08:00
].each_with_object({}) do |(variable_name, darken_or_lighten, percent), memo|
color = brand_variable_value(variable_name, active_brand_config, variables_map_with_image_urls)
computed_color = CanvasColor::Color.new(color).send(darken_or_lighten, percent/100.0)
memo["#{variable_name}-#{darken_or_lighten}ed-#{percent}"] = computed_color.to_s
end
end
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
def all_brand_variable_values(active_brand_config=nil, css_urls=false)
Use css variables for primary & secondary buttons closes: CNVS-38412 test plan: * check this out * run bundle exec rake brand_configs:generate_and_upload_all * compile assets * make sure buttons look how they did before * especially check in ie11 Change-Id: If1d87ef9fa5c184cc21b1b51212d26ee1c7c1da5 Reviewed-on: https://gerrit.instructure.com/120726 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-07-28 03:24:10 +08:00
variables_map.each_with_object(computed_variables(active_brand_config)) do |(key, _), memo|
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
memo[key] = brand_variable_value(key, active_brand_config, variables_map_with_image_urls, css_urls)
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
end
end
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
def all_brand_variable_values_as_json(active_brand_config=nil)
all_brand_variable_values(active_brand_config).to_json
end
Generate JavaScript file file for brand configs closes: CNVS-34333 things like inst-ui can now just look for a global variable named `CANVAS_ACTIVE_BRAND_VARIABLES` that will be present on every page to get all the colors/variables they need to do theming. you may need to run: `bundle exec rake brand_configs:generate_and_upload_all` to generate these files for all the brands you already have in your local db for testing this locally. that rake task is ran in every deploy so they will get created for all the existing brand_cofigs in prod/beta test plan: * with no brand applied: * load a page * view source and make sure there is a script tag something like this: <script src="/dist/brandable_css/default/variables-xxxxx.js"></script> * open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#008EE2” (the default canvas brand primary color) * go to the theme editor and set your “brand primary” to e.g: #629f56 * load a page, and open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#629f56” Change-Id: Ie48d0dbcb8a79429d3d55779efdbf4ef07c636c6 Reviewed-on: https://gerrit.instructure.com/99509 Tested-by: Jenkins Reviewed-by: Ed Schiebel <eschiebel@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-01-13 07:26:23 +08:00
def all_brand_variable_values_as_js(active_brand_config=nil)
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
"CANVAS_ACTIVE_BRAND_VARIABLES = #{all_brand_variable_values_as_json(active_brand_config)};"
Generate JavaScript file file for brand configs closes: CNVS-34333 things like inst-ui can now just look for a global variable named `CANVAS_ACTIVE_BRAND_VARIABLES` that will be present on every page to get all the colors/variables they need to do theming. you may need to run: `bundle exec rake brand_configs:generate_and_upload_all` to generate these files for all the brands you already have in your local db for testing this locally. that rake task is ran in every deploy so they will get created for all the existing brand_cofigs in prod/beta test plan: * with no brand applied: * load a page * view source and make sure there is a script tag something like this: <script src="/dist/brandable_css/default/variables-xxxxx.js"></script> * open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#008EE2” (the default canvas brand primary color) * go to the theme editor and set your “brand primary” to e.g: #629f56 * load a page, and open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#629f56” Change-Id: Ie48d0dbcb8a79429d3d55779efdbf4ef07c636c6 Reviewed-on: https://gerrit.instructure.com/99509 Tested-by: Jenkins Reviewed-by: Ed Schiebel <eschiebel@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-01-13 07:26:23 +08:00
end
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
def all_brand_variable_values_as_css(active_brand_config=nil)
":root {
#{all_brand_variable_values(active_brand_config, true).map{ |k, v| "--#{k}: #{v};"}.join("\n")}
}"
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
def public_brandable_css_folder
Pathname.new('public/dist/brandable_css')
end
def default_brand_folder
public_brandable_css_folder.join('default')
end
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
def default_brand_file(type, high_contrast=false)
default_brand_folder.join("variables#{high_contrast ? '-high_contrast' : ''}-#{default_variables_md5}.#{type}")
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
end
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
def high_contrast_overrides
Class.new do
def get_value(variable_name)
{"ic-brand-primary" => "#0770A3", "ic-link-color" => "#0073A7"}[variable_name]
end
end.new
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
end
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
def default(type, high_contrast=false)
bc = high_contrast ? high_contrast_overrides : nil
send("all_brand_variable_values_as_#{type}", bc)
Generate JavaScript file file for brand configs closes: CNVS-34333 things like inst-ui can now just look for a global variable named `CANVAS_ACTIVE_BRAND_VARIABLES` that will be present on every page to get all the colors/variables they need to do theming. you may need to run: `bundle exec rake brand_configs:generate_and_upload_all` to generate these files for all the brands you already have in your local db for testing this locally. that rake task is ran in every deploy so they will get created for all the existing brand_cofigs in prod/beta test plan: * with no brand applied: * load a page * view source and make sure there is a script tag something like this: <script src="/dist/brandable_css/default/variables-xxxxx.js"></script> * open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#008EE2” (the default canvas brand primary color) * go to the theme editor and set your “brand primary” to e.g: #629f56 * load a page, and open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#629f56” Change-Id: Ie48d0dbcb8a79429d3d55779efdbf4ef07c636c6 Reviewed-on: https://gerrit.instructure.com/99509 Tested-by: Jenkins Reviewed-by: Ed Schiebel <eschiebel@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-01-13 07:26:23 +08:00
end
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
def save_default!(type, high_contrast=false)
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
default_brand_folder.mkpath
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
default_brand_file(type, high_contrast).write(default(type, high_contrast))
move_default_to_s3_if_enabled!(type, high_contrast)
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
end
Generate css, json & js files for themes on build Closes: CNVS-38601 This change makes it so if you have a database connection, it will look at the db for the brand_configs that exist there and generate them all when you compile_assets. It should prevent people in dev mode from getting the vanilla white page that you get when you get a 404 for the css file That has all of your brand_configs css variables. Test plan: * set up a custom theme for yourself in canvas * rm -rf public/dist * check this out * run bin/rake canvas:compile_assets * load a page, * you should not get a 404 for a css file or js file with your brand_variables * the page should be themed and not be a vanilla white page Change-Id: I796ac99c06aafe5d7d229e457988094a7b48e8bd Reviewed-on: https://gerrit.instructure.com/122155 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-08-10 01:25:10 +08:00
def save_default_files!
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
[true, false].each do |high_contrast|
['js', 'css', 'json'].each { |type| save_default!(type, high_contrast) }
Generate JavaScript file file for brand configs closes: CNVS-34333 things like inst-ui can now just look for a global variable named `CANVAS_ACTIVE_BRAND_VARIABLES` that will be present on every page to get all the colors/variables they need to do theming. you may need to run: `bundle exec rake brand_configs:generate_and_upload_all` to generate these files for all the brands you already have in your local db for testing this locally. that rake task is ran in every deploy so they will get created for all the existing brand_cofigs in prod/beta test plan: * with no brand applied: * load a page * view source and make sure there is a script tag something like this: <script src="/dist/brandable_css/default/variables-xxxxx.js"></script> * open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#008EE2” (the default canvas brand primary color) * go to the theme editor and set your “brand primary” to e.g: #629f56 * load a page, and open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#629f56” Change-Id: Ie48d0dbcb8a79429d3d55779efdbf4ef07c636c6 Reviewed-on: https://gerrit.instructure.com/99509 Tested-by: Jenkins Reviewed-by: Ed Schiebel <eschiebel@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-01-13 07:26:23 +08:00
end
end
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
def move_default_to_s3_if_enabled!(type, high_contrast=false)
Generate JavaScript file file for brand configs closes: CNVS-34333 things like inst-ui can now just look for a global variable named `CANVAS_ACTIVE_BRAND_VARIABLES` that will be present on every page to get all the colors/variables they need to do theming. you may need to run: `bundle exec rake brand_configs:generate_and_upload_all` to generate these files for all the brands you already have in your local db for testing this locally. that rake task is ran in every deploy so they will get created for all the existing brand_cofigs in prod/beta test plan: * with no brand applied: * load a page * view source and make sure there is a script tag something like this: <script src="/dist/brandable_css/default/variables-xxxxx.js"></script> * open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#008EE2” (the default canvas brand primary color) * go to the theme editor and set your “brand primary” to e.g: #629f56 * load a page, and open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#629f56” Change-Id: Ie48d0dbcb8a79429d3d55779efdbf4ef07c636c6 Reviewed-on: https://gerrit.instructure.com/99509 Tested-by: Jenkins Reviewed-by: Ed Schiebel <eschiebel@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-01-13 07:26:23 +08:00
return unless defined?(Canvas) && Canvas::Cdn.enabled?
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
s3_uploader.upload_file(public_default_path(type, high_contrast))
Generate JavaScript file file for brand configs closes: CNVS-34333 things like inst-ui can now just look for a global variable named `CANVAS_ACTIVE_BRAND_VARIABLES` that will be present on every page to get all the colors/variables they need to do theming. you may need to run: `bundle exec rake brand_configs:generate_and_upload_all` to generate these files for all the brands you already have in your local db for testing this locally. that rake task is ran in every deploy so they will get created for all the existing brand_cofigs in prod/beta test plan: * with no brand applied: * load a page * view source and make sure there is a script tag something like this: <script src="/dist/brandable_css/default/variables-xxxxx.js"></script> * open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#008EE2” (the default canvas brand primary color) * go to the theme editor and set your “brand primary” to e.g: #629f56 * load a page, and open your dev console and type: console.log(CANVAS_ACTIVE_BRAND_VARIABLES['ic-brand-primary’]) * it should log “#629f56” Change-Id: Ie48d0dbcb8a79429d3d55779efdbf4ef07c636c6 Reviewed-on: https://gerrit.instructure.com/99509 Tested-by: Jenkins Reviewed-by: Ed Schiebel <eschiebel@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-01-13 07:26:23 +08:00
begin
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
File.delete(default_brand_file(type, high_contrast))
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
rescue Errno::ENOENT # continue if something else deleted it in another process
end
end
Generate JSON file for brand configs Refs CNVS-28275, closes CNVS-28885 Generate a json file to go along with the scss file for each brand config. The intention is that the json file for each brand config will be pushed to the cdn. One difference from the scss file is that it includes all variables, even if they are not specified in the brand config. Variable that have not been customized will use the default value. In addition to generating a json file for each brand, a json file for that inclues all default values is generated so other services don't need to know the defaults if no brand config is available. To allow for long term caching the filename of the json file includes a hash of the current defaults (including fingerprinted urls for default images). This way when the defaults change (or a default image) it will point to a new file even if the brand config didn't change. Test plan: - Save a new brand config. - Look in public/dist/brandable_css/[brand config hash]/ - There should be a [hash of defaults].json file - Should include custom values from brand config - Should include default values not specified in the brand config - Run rake brand_configs:clean && rake brand_configs:write - Should generate json file for all brand configs - Open console in browser - ENV.active_brand_config_json_url should be path the current brand json file - Go back to the default brand - ENV.active_brand_config_json_url should be path to default json file - Test with a real s3 bucket for the CDN - JSON files should be uploaded to the CDN - ENV.active_brand_config_json should work when used with ENV.ASSET_HOST Change-Id: Ibcaf54a2bff324f419a7614a8d3906c0c49aed9e Reviewed-on: https://gerrit.instructure.com/77427 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Simon Williams <simon@instructure.com>
2016-04-20 04:55:21 +08:00
def s3_uploader
@s3_uploaderer ||= Canvas::Cdn::S3Uploader.new
end
Fix link & brand-primary color HC & ie11 Closes: CNVS-38498 CORE-25 CORE-338 test plan: * turn on high contrast * using ie11, make sure that all the links and things that should be the brand-primary color look right. (Dark, not light, blue) * make sure they also look good in edge 15 and chrome with HC on. Change-Id: I83cb35aa40c774bcd8e4c0a1a18b8cb0875e9a0c Reviewed-on: https://gerrit.instructure.com/129911 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-10-17 06:07:03 +08:00
def public_default_path(type, high_contrast=false)
"dist/brandable_css/default/variables#{high_contrast ? '-high_contrast' : ''}-#{default_variables_md5}.#{type}"
Write css file with brand variables closes: CNVS-38408 NOTE: this does not actually change any behavior, it just gets things set up so we can actually start using css variables in follow-on commits. test plan: * with this checked out, * run bundle exec rake brand_configs:generate_and_upload_all & compile assets * open a page in canvas * there should be a stylesheet near the top of the <head> with css variables of all the theme editor variables. Change-Id: I2caa210917d9245ae103d1444d6353ecfdeb59fe Reviewed-on: https://gerrit.instructure.com/120574 Reviewed-by: Simon Williams <simon@instructure.com> Tested-by: Jenkins QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 06:16:44 +08:00
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
def variants
simlify variants Change-Id: Id29132581c4c5ab0e5199e1ae3ff79851b4a0f42 Reviewed-on: https://gerrit.instructure.com/79046 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
2016-05-09 12:23:09 +08:00
@variants ||= CONFIG['variants'].keys.freeze
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end
def brandable_variants
@brandable_variants ||= CONFIG['variants'].select{|_, v| v['brandable']}.map{ |k,_| k }.freeze
end
def combined_checksums
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
if defined?(ActionController) && ActionController::Base.perform_caching && defined?(@combined_checksums)
return @combined_checksums
end
file = APP_ROOT.join(CONFIG['paths']['bundles_with_deps'] + SASS_STYLE)
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
if file.exist?
@combined_checksums = JSON.parse(file.read).each_with_object({}) do |(k, v), memo|
upload css direct to s3 and optimize unbranded css fixes: CNVS-22276 what this change does: * changes it so if you have a 'host' set in canvs_cdn.yml, when you run brandable_css it will push the css files directly to s3 instead of writing them all to disk. * fixes the bug where brandable_css thought it had to re-compile css files that have not changed * changes the way we load css bundles that don't include any branding or use any of the variant variables (like: $use-high-contrast or $use-new-styles). before, we generated a unique css file for each variant and each brand for any of those bundles. this will instead point everyone to same url if the file uses none of those variables. test plan: * with no canvas_cdn.yml file: * run compile_assets * run it again, it should say "no changes" quickly * the css in canvas should work * now, rm -rf public/dist/brandable_css * save a canvas_cdn.yml with proper s3/cloudfront settings * compile_assets * canvas should work and use the css that was uploaded to s3 in previous step * compile_assets again, it should say "no changes" within a few seconds. * if you can, delete a css file from s3 & run brandable_css again. it should see that it needs to regenerate that file and do so correctly. when testing the css in the UI, especially make sure to look for: * try loading the equation editor in different variants, (e.g.: high contrast, new styles, legacy) the css for it should always be loaded from <cdn>/dist/brandable_css/no_variables/... * keep your js console open, there should not be any 404s * check the screenreader_gradebook most of the changes actually happened in brandable_css: https://github.com/ryankshaw/brandable_css/compare/6e0ddc59...master when code-reviewing, please do a thorough scan of those changes too. Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838 Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838 Reviewed-on: https://gerrit.instructure.com/61495 Reviewed-by: Jacob Fugal <jacob@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Rob Orton <rob@instructure.com>
2015-08-21 07:13:25 +08:00
memo[k] = v.symbolize_keys.slice(:combinedChecksum, :includesNoVariables)
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end.freeze
fix brandable_css so it works when rails is not loaded this will fix our gulp guard test plan: check out code run `bundle exec guard` hit enter it should not throw an error Change-Id: I01e5c82783039e542dfdb6f76f70a5a3232ee793 Reviewed-on: https://gerrit.instructure.com/57897 Tested-by: Jenkins Reviewed-by: Chris Hart <chart@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-08 06:08:27 +08:00
elsif defined?(Rails) && Rails.env.production?
Remove remaining dynamic brand css code closes: CNVS-39103 CNVS-39104 CNVS-38650 test plan: * do a general css styling regression pass * make sure that the urls to css files look like /dist/brandable_css/new_styles_normal_contrast/<bundle>-<fingerprint>.css and not: /dist/brandable_css/<big long md5>/new_styles_normal_contrast/<bundle>-<fingerprint>.css * make sure that stylesheets loaded by handlebars templates work eg: go to the calendar page and make sure it is styled correctly * verify that the theme editor works. especially the process when you hit "preivew" and "apply" * set up config/canvas_cdn.yml to use the dev cdn * run `bundle exec canvas:compile_assets && bundle exec rake canvas:cdn:upload_to_s3` * load a page, all the css should load from the cdn * verify the theme editor works when using the cdn too. * also review the changes in the brandable_css npm package: https://github.com/ryankshaw/brandable_css/compare/c6bef...b159d5 Change-Id: I55db41e90f6bc54183a661128f1050445a086d6b Reviewed-on: https://gerrit.instructure.com/120912 Tested-by: Jenkins Reviewed-by: Cody Cutrer <cody@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-26 07:19:15 +08:00
raise "#{file.expand_path} does not exist. You need to run brandable_css before you can serve css."
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
else
# for dev/test there might be cases where you don't want it to raise an exception
# if you haven't ran `brandable_css` and the manifest file doesn't exist yet.
# eg: you want to test a controller action and you don't care that it links
# to a css file that hasn't been created yet.
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
default_value = {:combinedChecksum => "Error: unknown css checksum. you need to run brandable_css"}.freeze
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
@combined_checksums = Hash.new(default_value).freeze
end
end
# bundle path should be something like "bundles/speedgrader" or "plugins/analytics/something"
upload css direct to s3 and optimize unbranded css fixes: CNVS-22276 what this change does: * changes it so if you have a 'host' set in canvs_cdn.yml, when you run brandable_css it will push the css files directly to s3 instead of writing them all to disk. * fixes the bug where brandable_css thought it had to re-compile css files that have not changed * changes the way we load css bundles that don't include any branding or use any of the variant variables (like: $use-high-contrast or $use-new-styles). before, we generated a unique css file for each variant and each brand for any of those bundles. this will instead point everyone to same url if the file uses none of those variables. test plan: * with no canvas_cdn.yml file: * run compile_assets * run it again, it should say "no changes" quickly * the css in canvas should work * now, rm -rf public/dist/brandable_css * save a canvas_cdn.yml with proper s3/cloudfront settings * compile_assets * canvas should work and use the css that was uploaded to s3 in previous step * compile_assets again, it should say "no changes" within a few seconds. * if you can, delete a css file from s3 & run brandable_css again. it should see that it needs to regenerate that file and do so correctly. when testing the css in the UI, especially make sure to look for: * try loading the equation editor in different variants, (e.g.: high contrast, new styles, legacy) the css for it should always be loaded from <cdn>/dist/brandable_css/no_variables/... * keep your js console open, there should not be any 404s * check the screenreader_gradebook most of the changes actually happened in brandable_css: https://github.com/ryankshaw/brandable_css/compare/6e0ddc59...master when code-reviewing, please do a thorough scan of those changes too. Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838 Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838 Reviewed-on: https://gerrit.instructure.com/61495 Reviewed-by: Jacob Fugal <jacob@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Rob Orton <rob@instructure.com>
2015-08-21 07:13:25 +08:00
def cache_for(bundle_path, variant)
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
key = ["#{bundle_path}.scss", variant].join(CONFIG['manifest_key_seperator'])
fingerprint = combined_checksums[key]
raise "Fingerprint not found. #{bundle_path} #{variant}" unless fingerprint
fingerprint
end
def all_fingerprints_for(bundle_path)
variants.each_with_object({}) do |variant, object|
upload css direct to s3 and optimize unbranded css fixes: CNVS-22276 what this change does: * changes it so if you have a 'host' set in canvs_cdn.yml, when you run brandable_css it will push the css files directly to s3 instead of writing them all to disk. * fixes the bug where brandable_css thought it had to re-compile css files that have not changed * changes the way we load css bundles that don't include any branding or use any of the variant variables (like: $use-high-contrast or $use-new-styles). before, we generated a unique css file for each variant and each brand for any of those bundles. this will instead point everyone to same url if the file uses none of those variables. test plan: * with no canvas_cdn.yml file: * run compile_assets * run it again, it should say "no changes" quickly * the css in canvas should work * now, rm -rf public/dist/brandable_css * save a canvas_cdn.yml with proper s3/cloudfront settings * compile_assets * canvas should work and use the css that was uploaded to s3 in previous step * compile_assets again, it should say "no changes" within a few seconds. * if you can, delete a css file from s3 & run brandable_css again. it should see that it needs to regenerate that file and do so correctly. when testing the css in the UI, especially make sure to look for: * try loading the equation editor in different variants, (e.g.: high contrast, new styles, legacy) the css for it should always be loaded from <cdn>/dist/brandable_css/no_variables/... * keep your js console open, there should not be any 404s * check the screenreader_gradebook most of the changes actually happened in brandable_css: https://github.com/ryankshaw/brandable_css/compare/6e0ddc59...master when code-reviewing, please do a thorough scan of those changes too. Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838 Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838 Reviewed-on: https://gerrit.instructure.com/61495 Reviewed-by: Jacob Fugal <jacob@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Rob Orton <rob@instructure.com>
2015-08-21 07:13:25 +08:00
object[variant] = cache_for(bundle_path, variant)
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end
end
end
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
give better errors for initial_setup closes CORE-1981 test plan - rake db:initial_setup should tell you when you need to run compile_assets Change-Id: Ia63196a6c81dba11987104242eabdf6e8d29519e Reviewed-on: https://gerrit.instructure.com/170858 Reviewed-by: Cody Cutrer <cody@instructure.com> QA-Review: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> Tested-by: Jenkins
2018-11-03 00:54:31 +08:00
class BrandConfigWithOutCompileAssets < RuntimeError
def initialize
super <<-END
It looks like you are running a migration before running `rake canvas:compile_assets`
compile_assets needs to complete before running db:migrate if brand_configs have not run
run `rake canvas:compile_assets` and then try migrations again.
END
end
end
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
class DefaultMD5NotUpToDateError < RuntimeError
def initialize
super <<-END
update error for brand configs Change-Id: Ied45e592512d019c958432a62a32c637d92aa51e Reviewed-on: https://gerrit.instructure.com/191093 Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins Product-Review: Rob Orton <rob@instructure.com>
2019-04-27 04:38:46 +08:00
If you did not make changes to assets, your node modules are probably out of date.
try running the following ./script/nuke_node.sh
If this does not resolve the issue, you have probably made the changes to
either app/stylesheets/brandable_variables.json or one of the images it
Ensure db migrations exists if brand defaults change closes CNVS-39664 Test plan: * start your rails server, it should work * make a change to app/stylesheets/brandable_variables.json * restart your rails server * it should throw raise an exception * do what it says in the error message * after you moved those files an restarted rails like it said, * start your rails server, it should not throw an error Change-Id: I30042f59baa31908c2e902445fb1bf3b06f3b45c Reviewed-on: https://gerrit.instructure.com/127667 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-28 07:22:53 +08:00
references so you need to rename the db migrations that makes sure when this change is deployed it
makes a new .css file for the css variables for each brand based on these new defaults.
To do that, run this command and then restart your rails process. (for local dev, if you want the
changes to show up in the ui, make sure you also run `rake db:migrate`).
mv db/migrate/*_#{MIGRATION_NAME.underscore}_predeploy.rb \\
db/migrate/#{BrandableCSS.migration_version}_#{MIGRATION_NAME.underscore}_predeploy.rb \\
&& \\
mv db/migrate/*_#{MIGRATION_NAME.underscore}_postdeploy.rb \\
db/migrate/#{BrandableCSS.migration_version + 1}_#{MIGRATION_NAME.underscore}_postdeploy.rb
FYI, current variables are: #{BrandableCSS.things_that_go_into_defaults_md5}
END
end
end
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
end