Menu icon Foundation

My Posts





My Comments

Matthias Hormann commented on Tobias Feld's post 5 days

You’d probably need to introduce a new {{include …}} helper since the partials includer {{> partial}} doesn’t support arbitrary file names (and extensions).
Example at https://github.com/helpers/handlebars-helper-include
 

Matthias Hormann commented on Matthias Hormann's post 10 days

Hey Rafi, good to see you respond.
It was actually not critique, because I’m still a little unsure myself what would be the best way to handle these cases. I just thought I’d mention it since people might just not know.
I myself ran across it lately when changing my »navigation« partial which gets included via »layouts/default.hmtl« and the generated pages wouldn’t change date/time.
I also use heavily parametrized pages, for instance the German privacy/data protection laws are a nightmare, so I use a »data/v.yml« file to specify which to use, like so:
# DATENSCHUTZ (Privacy)

Select the services you use by setting their "use: true", respectively

For some modules, you might have to fill in additional parameters,

i.e. google-analytics.

privacy:
modules:

allgemein:
  use: true
  partial: datenschutz-allgemein
  heading: Datenschutz

cookies:
  use: true
  partial: datenschutz-cookies
  heading: Cookies

google-analytics:
  use: false
  partial: datenschutz-google-analytics
  heading: Datenschutzerklärung für die Nutzung von Google Analytics

  trackingID: UA-XXXXX-Y
  cookieDomain: auto
  name:
  hitType: pageview

  browser-plugin:
    use: true
    heading: Browser Plugin
  optoutcookie:
    use: true
    heading: Widerspruch gegen Datenerfassung
  auftragsdatenverarbeitung:
    use: false
    heading: Auftragsdatenverarbeitung
  ip-anonymisierung:
    use: true
    heading: IP-Anonymisierung

and in the actual »datenschutz« (privacy) page include them like this (each type has its own legal text in a separate partial):
<div class="row content">
{{#each v.privacy.modules}}
{{#if this.use}}
<section class="small-12 columns">
<h3>{{this.heading}}</h3>

    {{&gt; (lookup . 'partial')}}
  &lt;/section&gt;
{{/if}}

{{/each}}
<section class="small-12 columns">
<p><small><em>Quellen: <a href="…" rel="nofollow" target="_blank">…</a> u.a.</em></small></p>
</section>
</div>

Just to show an example :-)

Matthias Hormann commented on Brandon B's post 15 days

Your CSS (usually) gets compiled into /dist/assets/css/app.css, and your background.jpg might live in /dist/assets/img/background.jpg.
So you would use something like
body {

background-image: url('../img/background.jpg');
background-repeat: no-repeat;
background-size: cover;
}
So you need to "step up" on level from where you are (the location of the compiled CSS file), leaving you in the "assets" folder, then "go down" into the "img" folder. :-)

Matthias Hormann commented on Matthias Hormann's post 15 days

P.S.: Regarding the foundation stack, it could even come »built-in«, i.e. script and gulp task defined with an empty »deploy« function, like so (in »gulpfile.babel.js«):
 
// add gulp-prompt for deployment (npm install --save-dev gulp-prompt)
import prompt from 'gulp-prompt';

// Deploy site to production server
gulp.task('deploy',
gulp.series('build', deploy_function));

// Deploy to production server
// TODO: Fill this in if you want to use it
function deploy_function() {
}

For a recent project, I had to use vinyl-ftp, and it looked like this:
// Deploy to production server, via ftp
function deploy_ftp() {
var conn = ftp.create(FTP_OPTIONS);
// need to set glob because otherwise only empty "dist" gets ftp’ed
// set base to "dist" otherwise it’ll make a "/dist" folder in target
// set "dot: true" to make it ftp hidden files like ".htaccess"
return gulp.src(PATHS.dist + '/*/', { base: PATHS.dist, dot: true, buffer: false })
.pipe(prompt.confirm('Really sure you want to deploy to the live server?'))
// comment out next line to ftp ALL, not just newer/different size files
.pipe(conn.newerOrDifferentSize(FTP_OPTIONS.dest))
.pipe(conn.dest(FTP_OPTIONS.dest));
}

FTP_OPTIONS are being defined in config.yml:
# DEPLOY (using vinyl_ftp)

npm run deploy –or–

gulp deploy --production

FTP_OPTIONS:
host: "example.com"
port: 21
dest: "/"
user: "username"
password: "password"
parallel: 10
log: gutil.log

Matthias Hormann commented on Thesi Marchon's post about 1 month

N.B.: You could even go and have the meta description also in the front matter of each page, like:
src/pages/de/gallery.html:
---
layout: default-de
title: Galerie
desc: Fotogalerie
longdesc: Einige Fotos bestehender Installationen.
keywords: Fotos,Galerie,Installationen,Ansichten
---
and then use Panini variables to expand these in your layout file, say src/layouts/default-de.html:
<!doctype html>
<html class="no-js" lang="de">
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>{{ title }}</title>
<meta name="description" content="{{ longdesc }}">
<meta name="keywords" content="{{ keywords }}">
<link rel="stylesheet" href="{{root}}assets/css/app.css">

</head>
<body>
{{> navigation-de}}
{{> header-de}}
{{!-- Seiten aus src/pages/de werden hier eingefügt --}}
{{> body}}
{{> footer-de}}

&lt;script src="{{root}}assets/js/app.js"&gt;&lt;/script&gt;

</body>
</html>

Matthias Hormann commented on Thesi Marchon's post about 1 month

On of the easiest solutions that come to mind is the following:
In src/layouts, create one file for each language, i.e.
 
src/layouts/default-en.html:
{{!-- This is the base layout for ENGLISH. --}}
<!doctype html>
<html class="no-js" lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<link rel="stylesheet" href="{{root}}assets/css/app.css">
</head>
<body>
{{> navigation-en}}
{{> header-en}}
{{!-- Pages from src/pages/en go here --}}
{{> body}}
{{> footer-en}}
</body>
</html>
 
src/layouts/default-de.html:
{{!-- Dies ist das Basis-Layout für DEUTSCH. --}}
<!doctype html>
<html class="no-js" lang="de">
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<link rel="stylesheet" href="{{root}}assets/css/app.css">
</head>
<body>
{{> navigation-de}}
{{> header-de}}
{{!-- Seiten aus src/pages/de werden hier eingefügt --}}
{{> body}}
{{> footer-de}}
</body>
</html>
 
Then, in your actual pages, just specify the desired layout using front matter:
 
src/pages/index.html
---

layout: default-de

<!-- Start Seiten-Inhalt -->

<!-- Ende Seiten-Inhalt -->

 
src/pages/en/index.html:
---

layout: default-en

<!-- Start page content -->

<!-- End page content -->

 
This could probably all structured differently, but it’s an easy solution.
I’d probably even go so far as to have only one index.html file in src/pages that detects the user’s browser’s accept language and tries to switch to the desired language automatically (if available). To keep it all apart, you might use »language subfolders« below, like src/pages/en, src/pages/de and so forth.
 
Have fun!

Matthias Hormann commented on David Titherly's post about 1 month

Thanks for coming back with an answer to your own question, David. It might come in handy at some time, thanks!

Matthias Hormann commented on Matthias Hormann's post about 1 month

Well, it seemed to have installed the node module "foundation-cli" under both /usr/lib AND /usr/local/lib, so I kinda "hotfixed" it by deleting some files under /usr/local, see https://github.com/zurb/foundation-cli/issues/58.
More or less resolved for now, but I’d still like to know how it came about.

Matthias Hormann commented on Matthias Hormann's post about 1 month

Even more odd:
$ sudo npm uninstall -g foundation-cli
unbuild foundation-cli@2.2.1

$ sudo npm install -g foundation-cli@2.2.1
/usr/bin/foundation -> /usr/lib/node_modules/foundation-cli/bin/foundation.js
foundation-cli@2.2.1 /usr/lib/node_modules/foundation-cli
├── is-root@1.0.0
├── colors@1.1.2
├── semver@4.3.6
├── nopt@3.0.6 (abbrev@1.1.0)
├── which@1.2.14 (isexe@2.0.0)
├── string-length@1.0.1 (strip-ansi@3.0.1)
├── multiline@1.0.2 (strip-indent@1.0.1)
├── paint-by-number@1.0.0 (chalk@1.1.3)
├── rimraf@2.6.1 (glob@7.1.1)
├── js-yaml@3.8.3 (esprima@3.1.3, argparse@1.0.9)
├── async@2.3.0
├── update-notifier@0.2.2 (is-npm@1.0.0, semver-diff@2.1.0, chalk@0.5.1, configstore@0.3.2, latest-version@1.0.1)
├── inquirer@0.8.5 (ansi-regex@1.1.1, through@2.3.8, figures@1.7.0, cli-width@1.1.1, readline2@0.1.1, chalk@1.1.3, lodash@3.10.1, rx@2.5.3)
├── lodash@4.17.4
├── npm@2.15.12
└── bower@1.8.0

$ foundation -v
Foundation CLI version 2.1.0

Can’t be just the version text, since foundation kits list and foundation blocks list also don’t work …
 

Posts Followed





Following

    No Content

Followers

My Posts

My Comments

You commented on Tobias Feld's post 5 days

You’d probably need to introduce a new {{include …}} helper since the partials includer {{> partial}} doesn’t support arbitrary file names (and extensions).
Example at https://github.com/helpers/handlebars-helper-include
 

You commented on Matthias Hormann's post 10 days

Hey Rafi, good to see you respond.
It was actually not critique, because I’m still a little unsure myself what would be the best way to handle these cases. I just thought I’d mention it since people might just not know.
I myself ran across it lately when changing my »navigation« partial which gets included via »layouts/default.hmtl« and the generated pages wouldn’t change date/time.
I also use heavily parametrized pages, for instance the German privacy/data protection laws are a nightmare, so I use a »data/v.yml« file to specify which to use, like so:
# DATENSCHUTZ (Privacy)

Select the services you use by setting their "use: true", respectively

For some modules, you might have to fill in additional parameters,

i.e. google-analytics.

privacy:
modules:

allgemein:
  use: true
  partial: datenschutz-allgemein
  heading: Datenschutz

cookies:
  use: true
  partial: datenschutz-cookies
  heading: Cookies

google-analytics:
  use: false
  partial: datenschutz-google-analytics
  heading: Datenschutzerkl&auml;rung f&uuml;r die Nutzung von Google Analytics

  trackingID: UA-XXXXX-Y
  cookieDomain: auto
  name:
  hitType: pageview

  browser-plugin:
    use: true
    heading: Browser Plugin
  optoutcookie:
    use: true
    heading: Widerspruch gegen Datenerfassung
  auftragsdatenverarbeitung:
    use: false
    heading: Auftragsdatenverarbeitung
  ip-anonymisierung:
    use: true
    heading: IP-Anonymisierung

and in the actual »datenschutz« (privacy) page include them like this (each type has its own legal text in a separate partial):
<div class="row content">
{{#each v.privacy.modules}}
{{#if this.use}}
<section class="small-12 columns">
<h3>{{this.heading}}</h3>

    {{&gt; (lookup . 'partial')}}
  &lt;/section&gt;
{{/if}}

{{/each}}
<section class="small-12 columns">
<p><small><em>Quellen: <a href="…" rel="nofollow" target="_blank">…</a> u.a.</em></small></p>
</section>
</div>

Just to show an example :-)

You commented on Brandon B's post 15 days

Your CSS (usually) gets compiled into /dist/assets/css/app.css, and your background.jpg might live in /dist/assets/img/background.jpg.
So you would use something like
body {

background-image: url('../img/background.jpg');
background-repeat: no-repeat;
background-size: cover;
}
So you need to "step up" on level from where you are (the location of the compiled CSS file), leaving you in the "assets" folder, then "go down" into the "img" folder. :-)

You commented on Matthias Hormann's post 15 days

P.S.: Regarding the foundation stack, it could even come »built-in«, i.e. script and gulp task defined with an empty »deploy« function, like so (in »gulpfile.babel.js«):
 
// add gulp-prompt for deployment (npm install --save-dev gulp-prompt)
import prompt from 'gulp-prompt';

// Deploy site to production server
gulp.task('deploy',
gulp.series('build', deploy_function));

// Deploy to production server
// TODO: Fill this in if you want to use it
function deploy_function() {
}

For a recent project, I had to use vinyl-ftp, and it looked like this:
// Deploy to production server, via ftp
function deploy_ftp() {
var conn = ftp.create(FTP_OPTIONS);
// need to set glob because otherwise only empty "dist" gets ftp’ed
// set base to "dist" otherwise it’ll make a "/dist" folder in target
// set "dot: true" to make it ftp hidden files like ".htaccess"
return gulp.src(PATHS.dist + '/*/', { base: PATHS.dist, dot: true, buffer: false })
.pipe(prompt.confirm('Really sure you want to deploy to the live server?'))
// comment out next line to ftp ALL, not just newer/different size files
.pipe(conn.newerOrDifferentSize(FTP_OPTIONS.dest))
.pipe(conn.dest(FTP_OPTIONS.dest));
}

FTP_OPTIONS are being defined in config.yml:
# DEPLOY (using vinyl_ftp)

npm run deploy –or–

gulp deploy --production

FTP_OPTIONS:
host: "example.com"
port: 21
dest: "/"
user: "username"
password: "password"
parallel: 10
log: gutil.log

You commented on Thesi Marchon's post about 1 month

N.B.: You could even go and have the meta description also in the front matter of each page, like:
src/pages/de/gallery.html:
---
layout: default-de
title: Galerie
desc: Fotogalerie
longdesc: Einige Fotos bestehender Installationen.
keywords: Fotos,Galerie,Installationen,Ansichten
---
and then use Panini variables to expand these in your layout file, say src/layouts/default-de.html:
<!doctype html>
<html class="no-js" lang="de">
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>{{ title }}</title>
<meta name="description" content="{{ longdesc }}">
<meta name="keywords" content="{{ keywords }}">
<link rel="stylesheet" href="{{root}}assets/css/app.css">

</head>
<body>
{{> navigation-de}}
{{> header-de}}
{{!-- Seiten aus src/pages/de werden hier eingefügt --}}
{{> body}}
{{> footer-de}}

&lt;script src="{{root}}assets/js/app.js"&gt;&lt;/script&gt;

</body>
</html>

You commented on Thesi Marchon's post about 1 month

On of the easiest solutions that come to mind is the following:
In src/layouts, create one file for each language, i.e.
 
src/layouts/default-en.html:
{{!-- This is the base layout for ENGLISH. --}}
<!doctype html>
<html class="no-js" lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<link rel="stylesheet" href="{{root}}assets/css/app.css">
</head>
<body>
{{> navigation-en}}
{{> header-en}}
{{!-- Pages from src/pages/en go here --}}
{{> body}}
{{> footer-en}}
</body>
</html>
 
src/layouts/default-de.html:
{{!-- Dies ist das Basis-Layout für DEUTSCH. --}}
<!doctype html>
<html class="no-js" lang="de">
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="ie=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<link rel="stylesheet" href="{{root}}assets/css/app.css">
</head>
<body>
{{> navigation-de}}
{{> header-de}}
{{!-- Seiten aus src/pages/de werden hier eingefügt --}}
{{> body}}
{{> footer-de}}
</body>
</html>
 
Then, in your actual pages, just specify the desired layout using front matter:
 
src/pages/index.html
---

layout: default-de

<!-- Start Seiten-Inhalt -->

<!-- Ende Seiten-Inhalt -->

 
src/pages/en/index.html:
---

layout: default-en

<!-- Start page content -->

<!-- End page content -->

 
This could probably all structured differently, but it’s an easy solution.
I’d probably even go so far as to have only one index.html file in src/pages that detects the user’s browser’s accept language and tries to switch to the desired language automatically (if available). To keep it all apart, you might use »language subfolders« below, like src/pages/en, src/pages/de and so forth.
 
Have fun!

You commented on David Titherly's post about 1 month

Thanks for coming back with an answer to your own question, David. It might come in handy at some time, thanks!

You commented on Matthias Hormann's post about 1 month

Well, it seemed to have installed the node module "foundation-cli" under both /usr/lib AND /usr/local/lib, so I kinda "hotfixed" it by deleting some files under /usr/local, see https://github.com/zurb/foundation-cli/issues/58.
More or less resolved for now, but I’d still like to know how it came about.

You commented on Matthias Hormann's post about 1 month

Even more odd:
$ sudo npm uninstall -g foundation-cli
unbuild foundation-cli@2.2.1

$ sudo npm install -g foundation-cli@2.2.1
/usr/bin/foundation -> /usr/lib/node_modules/foundation-cli/bin/foundation.js
foundation-cli@2.2.1 /usr/lib/node_modules/foundation-cli
├── is-root@1.0.0
├── colors@1.1.2
├── semver@4.3.6
├── nopt@3.0.6 (abbrev@1.1.0)
├── which@1.2.14 (isexe@2.0.0)
├── string-length@1.0.1 (strip-ansi@3.0.1)
├── multiline@1.0.2 (strip-indent@1.0.1)
├── paint-by-number@1.0.0 (chalk@1.1.3)
├── rimraf@2.6.1 (glob@7.1.1)
├── js-yaml@3.8.3 (esprima@3.1.3, argparse@1.0.9)
├── async@2.3.0
├── update-notifier@0.2.2 (is-npm@1.0.0, semver-diff@2.1.0, chalk@0.5.1, configstore@0.3.2, latest-version@1.0.1)
├── inquirer@0.8.5 (ansi-regex@1.1.1, through@2.3.8, figures@1.7.0, cli-width@1.1.1, readline2@0.1.1, chalk@1.1.3, lodash@3.10.1, rx@2.5.3)
├── lodash@4.17.4
├── npm@2.15.12
└── bower@1.8.0

$ foundation -v
Foundation CLI version 2.1.0

Can’t be just the version text, since foundation kits list and foundation blocks list also don’t work …
 

Posts Followed

Following

  • No Content

Followers

  • No Content