Menu icon Foundation

Engineer | Maine, US

I am the owner of Mainely Web which has been providing web hosting and e-mail services since 1997.

My Posts

  • NEW
  • Nodejs and Foundation 6 on Linux Mint

    By John Vedral

    Linux Mintnodejs

    A word of advice. Do not use the nodejs included in the Linux Mint repos. As of Linux Mint 17.3 Rosa, the repo version is out of date and has the additional problem of namespace conflict with another package. If you try to use the version distributed in ... (continued)


My Comments

John Vedral commented on anyway's post almost 2 years

I haven't tested it yet, but you could accomplish the compression using mod_deflate. Skip the gzip process in your build script and add the following to your .htaccess file.
<IfModule mod_deflate.c>
<filesMatch ".(js|css|html)$">
SetOutputFilter DEFLATE
</filesMatch>
</IfModule>
While the gzip method I describe does the compression in advance, the deflate method does it on the fly. Deflate is very fast and should not cause an undue burden on your server, but this will depend on the server load and capabilities.Please test and let me know if it works as intended.

John Vedral commented on anyway's post about 2 years

Your remaining steps depend upon whether you are running your own server or using a service provider. Filename errors (spaces, caps, etc), server configuration (no gz support, etc), error log contents (may give more information about the exact error), and the full contents of your .htaccess file can all come in to play in your diagnosis.
Depending on how you are deployed, you will need to approach each of these issues in turn.

John Vedral commented on anyway's post about 2 years

I would start diagnosing the issue by performing a directory listing on the server to verify that the gz files exist in the same server directory as the uncompressed files and that the permissions make them readable.
On GNU/Linux I would use the following to get full details.
ls -la

John Vedral commented on anyway's post over 2 years

I have found that a significant size reduction and speed increase can be achieved by adding a gzip stage to our build scripts. This creates additional .gz files for each one of our .css, .js, and .html files.
To make it all work, the .htaccess file for the web site is modified to deliver the smaller gzipped file if the web browser supports it, which I believe 100% do. All of our development and server work is done using Linux, so you may need to adapt the following if you are using a different platform.
Here is an overview of the build script.
#!/bin/bash

Build the production web site

cd ~/Documents/mydevdir
npm run build
for name in ls dist/*.html;do gzip <$name >$name.gz;done
for name in ls dist/assets/css/*.css;do gzip <$name >$name.gz;done
for name in ls dist/assets/js/*.js;do gzip <$name >$name.gz;done
tar czf dist.tar.gz dist

copy the file to the server

scp dist.tar.gz ...

connect to the server and untar the files to the production directory

ssh ...
And here is the portion of the .htaccess file which causes the server to deliver the compressed file to the web browser.
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}.gz" -s
RewriteRule ".*.css" "$1.css.gz" [QSA]

# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

# Serve gzip compressed HTML files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.html" "$1\.html\.gz" [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
RewriteRule "\.html\.gz$" "-" [T=text/html,E=no-gzip:1]

&lt;FilesMatch "(\.js\.gz|\.css\.gz|\.html\.gz)$"&gt;
  # Serve correct encoding type.
  Header append Content-Encoding gzip

  # Force proxies to cache gzipped &amp;
  # non-gzipped css/js files separately.
  Header append Vary Accept-Encoding
&lt;/FilesMatch&gt;

</IfModule>
 

John Vedral commented on Luke's post over 3 years

I can't tell from your screenshot what may be wrong, however, I can tell you what I would do to fix it.
In production:

I would restore a backup of the site from when it last functioned properly so that my production site was working again.

Then back to development:

Make sure that I am using the standard grid instead of flex grid.

I have found the flex grid to be too cutting edge for many browsers.

Comment out the uncss line in my gulpfile if needed.

If I am using something like the ZURB Template, the uncss optimizations can cause some misbehaviors. I comment it out in my projects.

Check the divs to make sure that they all match up with a partner.

I have found that many layout issues come from mismatched divs. Each browser behaves differently when rendering a page with broken tags.

Take each component, one by one, refer to the Foundation 6 documentation and fix them one at a time.

Check callouts, columns, orbits, etc to be sure that you have all of the correct breakpoints and other code.

Compile to production code.

Production code may sometimes behave differently from the unoptimized development code.

Publish to a temporary area on my production server.

I always want to see how things act under the production web server, so I send the code to a development folder on the server before copying it to the production folder.

Test with as many different web browsers as possible on mobile devices, laptops, and desktops.

Make a checklist: Chrome, Chromium, Firefox, IE, Opera, Safari, smartphone browsers, tablet browsers, and on and on.

Repeat steps 4 through 7 until the results are satisfactory.

I rarely get it right the first time.

Publish to production.

Success! Or at least good enough.

John Vedral commented on Barbara Ahart's post over 3 years

The link for upgrading to 6.2 does contain some of the information, however, the issue exists with brand new projects using the foundation zurb template for sites.
Probably the template needs to be updated with the required changes so that new projects don't have the additional manual steps.
I will investigate the code on github and see if it is something I feel comfortable submitting as a pull request.

John Vedral commented on Barbara Ahart's post over 3 years

The following code will accomplish the same thing as my previous reply.

npm install babel-register babel-preset-es2015 

John Vedral commented on Barbara Ahart's post over 3 years

I had the same exact problem running foundation sites from the command line on Linux Mint. In addition, it could not find the babel plugins for es2015. My solution was to install the missing modules manually using

npm install babel-register babel-plugin-transform-es2015-arrow-functions babel-plugin-transform-es2015-block-scoped-functions babel-plugin-transform-es2015-block-scoping babel-plugin-transform-es2015-classes babel-plugin-transform-es2015-destructuring babel-plugin-transform-es2015-template-literals babel-plugin-transform-es2015-parameters babel-plugin-transform-es2015-shorthand-properties babel-plugin-transform-es2015-spread babel-plugin-transform-es2015-modules-commonjs

I am investigating the issue further to see why the modules are not found. As far as I can tell, they are installed in subdirectories which may not be detected by the existing code. Loading them manually installs them in the top level node_modules directory.

John Vedral commented on Marko A's post over 3 years

You have a typo in step 1.

sudo apt-get ln -s /usr/bin/nodejs /usr/bin/node

should be

sudo ln -s /usr/bin/nodejs /usr/bin/node

Posts Followed





Following

    No Content

Followers

My Posts


My Comments

You commented on anyway's post almost 2 years

I haven't tested it yet, but you could accomplish the compression using mod_deflate. Skip the gzip process in your build script and add the following to your .htaccess file.
<IfModule mod_deflate.c>
<filesMatch ".(js|css|html)$">
SetOutputFilter DEFLATE
</filesMatch>
</IfModule>
While the gzip method I describe does the compression in advance, the deflate method does it on the fly. Deflate is very fast and should not cause an undue burden on your server, but this will depend on the server load and capabilities.Please test and let me know if it works as intended.

You commented on anyway's post about 2 years

Your remaining steps depend upon whether you are running your own server or using a service provider. Filename errors (spaces, caps, etc), server configuration (no gz support, etc), error log contents (may give more information about the exact error), and the full contents of your .htaccess file can all come in to play in your diagnosis.
Depending on how you are deployed, you will need to approach each of these issues in turn.

You commented on anyway's post about 2 years

I would start diagnosing the issue by performing a directory listing on the server to verify that the gz files exist in the same server directory as the uncompressed files and that the permissions make them readable.
On GNU/Linux I would use the following to get full details.
ls -la

You commented on anyway's post over 2 years

I have found that a significant size reduction and speed increase can be achieved by adding a gzip stage to our build scripts. This creates additional .gz files for each one of our .css, .js, and .html files.
To make it all work, the .htaccess file for the web site is modified to deliver the smaller gzipped file if the web browser supports it, which I believe 100% do. All of our development and server work is done using Linux, so you may need to adapt the following if you are using a different platform.
Here is an overview of the build script.
#!/bin/bash

Build the production web site

cd ~/Documents/mydevdir
npm run build
for name in ls dist/*.html;do gzip <$name >$name.gz;done
for name in ls dist/assets/css/*.css;do gzip <$name >$name.gz;done
for name in ls dist/assets/js/*.js;do gzip <$name >$name.gz;done
tar czf dist.tar.gz dist

copy the file to the server

scp dist.tar.gz ...

connect to the server and untar the files to the production directory

ssh ...
And here is the portion of the .htaccess file which causes the server to deliver the compressed file to the web browser.
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}.gz" -s
RewriteRule ".*.css" "$1.css.gz" [QSA]

# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

# Serve gzip compressed HTML files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.html" "$1\.html\.gz" [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
RewriteRule "\.html\.gz$" "-" [T=text/html,E=no-gzip:1]

&lt;FilesMatch "(\.js\.gz|\.css\.gz|\.html\.gz)$"&gt;
  # Serve correct encoding type.
  Header append Content-Encoding gzip

  # Force proxies to cache gzipped &amp;
  # non-gzipped css/js files separately.
  Header append Vary Accept-Encoding
&lt;/FilesMatch&gt;

</IfModule>
 

You commented on Luke's post over 3 years

I can't tell from your screenshot what may be wrong, however, I can tell you what I would do to fix it.
In production:

I would restore a backup of the site from when it last functioned properly so that my production site was working again.

Then back to development:

Make sure that I am using the standard grid instead of flex grid.

I have found the flex grid to be too cutting edge for many browsers.

Comment out the uncss line in my gulpfile if needed.

If I am using something like the ZURB Template, the uncss optimizations can cause some misbehaviors. I comment it out in my projects.

Check the divs to make sure that they all match up with a partner.

I have found that many layout issues come from mismatched divs. Each browser behaves differently when rendering a page with broken tags.

Take each component, one by one, refer to the Foundation 6 documentation and fix them one at a time.

Check callouts, columns, orbits, etc to be sure that you have all of the correct breakpoints and other code.

Compile to production code.

Production code may sometimes behave differently from the unoptimized development code.

Publish to a temporary area on my production server.

I always want to see how things act under the production web server, so I send the code to a development folder on the server before copying it to the production folder.

Test with as many different web browsers as possible on mobile devices, laptops, and desktops.

Make a checklist: Chrome, Chromium, Firefox, IE, Opera, Safari, smartphone browsers, tablet browsers, and on and on.

Repeat steps 4 through 7 until the results are satisfactory.

I rarely get it right the first time.

Publish to production.

Success! Or at least good enough.

You commented on Barbara Ahart's post over 3 years

The link for upgrading to 6.2 does contain some of the information, however, the issue exists with brand new projects using the foundation zurb template for sites.
Probably the template needs to be updated with the required changes so that new projects don't have the additional manual steps.
I will investigate the code on github and see if it is something I feel comfortable submitting as a pull request.

You commented on Barbara Ahart's post over 3 years

The following code will accomplish the same thing as my previous reply.

npm install babel-register babel-preset-es2015 

You commented on Barbara Ahart's post over 3 years

I had the same exact problem running foundation sites from the command line on Linux Mint. In addition, it could not find the babel plugins for es2015. My solution was to install the missing modules manually using

npm install babel-register babel-plugin-transform-es2015-arrow-functions babel-plugin-transform-es2015-block-scoped-functions babel-plugin-transform-es2015-block-scoping babel-plugin-transform-es2015-classes babel-plugin-transform-es2015-destructuring babel-plugin-transform-es2015-template-literals babel-plugin-transform-es2015-parameters babel-plugin-transform-es2015-shorthand-properties babel-plugin-transform-es2015-spread babel-plugin-transform-es2015-modules-commonjs

I am investigating the issue further to see why the modules are not found. As far as I can tell, they are installed in subdirectories which may not be detected by the existing code. Loading them manually installs them in the top level node_modules directory.

You commented on Marko A's post over 3 years

You have a typo in step 1.

sudo apt-get ln -s /usr/bin/nodejs /usr/bin/node

should be

sudo ln -s /usr/bin/nodejs /usr/bin/node

Posts Followed

Following

  • No Content

Followers

  • No Content