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
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>
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>
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>
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>
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>
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>
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>
closes: CNVS-31785
test plan:
all builds should pass
Change-Id: I2925934692a3d2f115f1289d7b50cb72d8cb907f
Reviewed-on: https://gerrit.instructure.com/104492
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
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>
Fixes: CNVS-33551
note:
- this change was to address a11y issues reported in
CNVS-33476 and CNVS-33477 ***
test plan:
- as a user navigate to the unthemed canvas login screen
- the login button as well as the "request password" button
have been updated to look like the inst-ui ghost button
- as an admin navigate to an account to test the theming of the
login button to ensure still looks/functions as expected
- take a spin with the minimalist, state and possibly a
custom theme to ensure the "login link color" is applied
to the login button
- example view: https://www.screencast.com/t/hmp2Ny8E
Change-Id: Iad76a3d3be144503b62552566bc89f65118e7ca4
Reviewed-on: https://gerrit.instructure.com/97001
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Dan Sasaki
Product-Review: Colleen Palmer <colleen@instructure.com>
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>
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>
Change-Id: I50aab5792fdd793356a13355f0850cdced105d6a
Reviewed-on: https://gerrit.instructure.com/89319
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
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>
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>
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>
closes CNVS-27874
TEST PLAN:
1) run webpack build
2) should be fast
Change-Id: I3d0b07cb7417cbd235bd628375d9888c6cc8d090
Reviewed-on: https://gerrit.instructure.com/74112
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
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>
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>
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>
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>
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>
closes: CNVS-21804
this will also do a better job of cleaning up
the app/stylesheets/brandable_css_brands dir
(so when you compile sass, it won't do stuff
for brandConfigs that aren't being used anymore)
test plan:
open theme editor, make some changes, hit preview.
as a different user in a different browser,
open theme editor, make changes, press save.
now in the first window, try to hit save.
before it would break, now it will work
Change-Id: I094f737d35c854764a7c361bec4798b8a2203410
Reviewed-on: https://gerrit.instructure.com/58102
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Product-Review: Jennifer Stern <jstern@instructure.com>
Tested-by: Jenkins
QA-Review: Nathan Rogowski <nathan@instructure.com>
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>
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>
Rob Orton