Upgrade to Foundation 6.7.4

Migration notes from 6.6 (none for 6.6.1)

Refactor XY Grid cell mixins: This is a big one! (See migration notes)

Off-canvas event: Renamed closed.zf.offcanvas to close.zf.offcanvas

New _settings.scss variables:
$closebutton-default-size: medium;
$closebutton-z-index: 10;

The new settings.scss variables are trivial, and there's no custom off-canvas events in theme calling closed.zf.offcanvas from a quick project search of the folder, so it's really the xy_grids. If we decide to split layout from this base theme, it'd be reliant on having an updated branch of xy_grids for people to use (not technically reliant, but from a user perspective) when the update is pushed on this theme.

The only real issue seems to be integation with the xy_grids layout module.

The community driven 6.7 branch changes up tooling a bit, I had to do a bit of intervention on a static site I upgraded from 6.6 to 6.7, but this seems like a reasonably straightforward push.

Off the top of my head what'd need to be done:

* update static css/js resources in theme/subtheme to 6.6.3
* update https://www.drupal.org/project/xy_grid_layouts to the 6.6 conventions vs < 6.5 (or just note that it needs to be updated)

Ok, I've created a patch that updates the base theme and the STARTER build process. These updates don't do a whole lot to the css/js itself (beyond the update to the Foundation version.) The BIG difference is to bring the build process in line with the Foundation project itself. I think this makes sense that way we can keep up with all of the package versions, not just the theme itself, and the build process along with the Foundation project. I think we make it harder on ourselves by trying to do something unique rather than just use the packages and tools they have already decided on. Thoughts?

To test:
Either create a new subtheme from the STARTER or --
- Copy over the .babelrc and config.yml from the STARTER template to the root of your sub theme. Add your site uri to the config.yml in your subtheme.
- Copy the package.json from STARTER into your subtheme. Make sure to keep the correct project name.
- Overwrite gulpfile.js in your subtheme with gulpfile.babel.js from the STARTER template.
- Copy the /js/foundation_init.js to your js folder in your subtheme.
- Delete the node_modules directory and the package.lock files from your sub-theme. And then run npm install

Some things will probably break, especially if you're not already up to date with the latest version of the dev branch. But does it build? Looking at the patch, does this make sense? Once we do this I think we will be ready to move to Beta/stable releases.

I'll try and test this out in the next few days, but using their build process makes total sense!

Ok, I tested this on a site and here are a couple additional upgrade notes I came across:

• I updated my _settings.scss file. I'm attaching a diff for other ppl to reference, but i don't think it'll work for other ppl to directly apply because the file has theme-specific settings.
• I copied the zurb_foundation.scss file from the base theme into the _drupal.scss file in my sub-theme.
• Because of the update to the $callout-padding variable (changes to a map called $callout-sizes), I had to update some custom scss that used that variable to be map-get($callout-sizes, default);
• Because of some updates to js I had to update a couple places where I was initializing Foundation elements in the code. For example: new Sticky($('.full-width-header-region'), options); changed to new Foundation.Sticky($('.full-width-header-region'), options);. An Interchange element I had was using the type: 'src' in options, but that was changed to 'background', new Orbit changed to new Foundation.Orbit.

I didn't have any custom XY Grid cell mixins like @erutan points out above. I did a quick search for xy-cell in my scss and didn't have anything. But these migration notes continue to be useful.

I also didn't have any offcanvas elements so I didn't need to refactor that.

Also worth noting: I could run npm install with node 12 and node 14. node 16 is not yet supported.

I'm using Node 14 on a static site running zurb-template - they support 12 and 14 according to the foundation repo, but worth noting for sure.

I was upgrading off of the latest dev and had a lot things to put in my settings.scss, but it was an easy merge. I'd recommend diffing your current _settings.csss against the one from the startertheme / github - if you have a GUI tool like Kaleidoscope it'll shine here.

Apparently the `$body-safe-padding: false` is the only real change since 6.6.3 interestingly enough. I was missing the maps for hi-dpi, callout-padding and a few other things and my sites has been compiling fine all this time. It's a very prototype data heavy site so not a ton of custom theming on it, which makes for a pretty clean test.

History of _settings.scss over time.

Note re: Overwrite gulpfile.js in your subtheme with gulpfile.babel.js from the STARTER template. Overwrite isn't quite right, delete your gulpfile.js and copy over gulpfile.babel.js - keeping the latter named gulpfile.babel.js in your theme dir.

I have SSH setup for Drupal.org and have pushed to Gitlab before, but authenticating against the issue fork was giving me issues for whatever reason so it was simpler to just make a .diff

renaming PROXY to BROWSERSYNC is opionated, but makes it a bit clearer perhaps what it is for? You can pass ports over that variable so the previous port onewas redundant. I cleaned out panini, style sherpa, and unCSS (the latter makes a ton of sense for something like Foundation, but would need to have custom selenium tests or something to scan a site & interact with exposed filters on views etc or something ridiculous for a Drupal site vs SSG).

package.json, config.yml, & gulpfile.babel.js still have some extra stuff in it from the Panini SSG in the foundation zurb template - it's still trying to parse SSG *html files. I clarified some wording on config.yml too - it's a bit odd to have a new local server proxying another, but this could be used to test theming changes on a non-local dev/qa site (or prod!) so that's a neat bonus.

Writing up some gotchas and linking out to previous Zurb upgrade guides would make sense, but aside from the server function hack not quite working for browsersync it seems fine. Line 41 of gulpfile.babel.js could perhaps be optimized since we're not using unCSS, but that can wait.

I think we can RBTM this, but there definitely needs to be patch upgrade notes.

Ok I committed your changes - thanks for reviewing and making that diff! Ok, I think we're good to go. I'm going to merge and then spend some time on the release/upgrade notes. I'll ping this issue when I'm done -- feel free to review and add other notes you think would be helpful!

Ok marking this as fixed. I've copied the overview of these notes to this release notes page (that we can publish with the next release.) Feel free to edit or expand it however you think is helpful!

Will do, I'm a bit time constrained now but will have more flexibility in two weeks.