Goal - I am setting up an asset pipeline using grunt to convert and compress image files for a website.
Issue - grunt-responsive-images fails to find gm/convert.
Warning: Could not execute GraphicsMagick/ImageMagick: identify "-ping" "-format" "%m:%T:%s" "src/css/images/test.jpg" this most likely means the gm/convert binaries can't be found
GraphicsMagick is installed, and I am able to call gm version from the same directory:
GraphicsMagick 1.3.25 2016-09-05 Q16 http://www.GraphicsMagick.org/
If I comment out the engine: 'im' line below, the task runs and size and compression settings are applied.
grunt.initConfig({
responsive_images: {
dev: {
options: {
// engine: 'im', <--does this invoke gm?
sizes: [{
name: 'small',
width: '30%',
suffix: '_small',
quality: 60
},{
name: 'large',
width: '50%',
suffix: '_large',
quality: 40
}]
},
Question 1 - What is engine: 'im' doing?
Question 2 - How is grunt-responsive-images resizing and compressing images files when engine: 'im' isn't specified? Is it using built-in image tools?
UPDATE
When I changed engine: 'im' to engine: 'gm', the tasks completed with no errors. Maybe im = imageMagick and gm = graphicsMagick? Also, maybe, grunt-responsive-images can find gm, but cannot find im?
Question 3 - How would I fix grunt-responsive-images to work with imageMagick (like I see in many tutorials)?
Thank you!
I found the answers in the documentation: grunt-responsive-images\options
Answer 1 -
options.engine: Chooses which graphics engine to use when resizing images. To use GraphicsMagick, set this to gm. To use ImageMagick, set this to im. You'll need the relevant engine installed.
Answer 2 -
I had gm installed via npm, and grunt-responsive-images was using that to compress and resize. I did not have imagemagick installed. brew list did not show imagemagick (graphicsmagick was listed, and probably why I thought I had installed imagemagick).
Answer 3 - The fix is simple; install imagemagick with homebrew:
brew install imagemagick then check with brew list. Now grunt runs with either 'gm' or 'im' engines selected.
Related
To get along better with my coworkers, I have atom configured with 2-space tabs, but in some files, I prefer 4. I'm trying to figure another file type, in this case, my Foo.pro files that are created with Qt Creator.
I've tried a few dozen things, and nothing seems to work. I'm editing my ~/.atom/config.cson and then restarting atom, and there's no change.
Here's my latest attempt:
"*":
core:
customFileTypes:
"source.pro": [
"pro"
]
disabledPackages: [
"autocomplete-plus"
"markdown-preview"
"markdown-preview-plus"
"spell-check"
]
telemetryConsent: "limited"
themes: [
"atom-light-ui"
"one-light-syntax"
]
editor: {}
"exception-reporting":
userId: "283f523f-3348-4956-97f6-a73675e6e9c6"
"tree-view":
hideVcsIgnoredFiles: true
welcome:
showOnStartup: false
".basic.html.text":
editor:
tabLength: 4
".html.source":
editor:
tabLength: 4
".source.pro":
editor:
tabLength: 4
".shell.source":
editor:
tabLength: 4
".shtml.source":
editor:
tabLength: 4
I'm fairly sure some of these others aren't working, either. Within Atom, if I open my .pro file and do Alt-Cmnd-P, it says the file type is text.plain.null-grammar. And tab width is still 2 characters. So clearly I'm doing something wrong.
You'll notice I'm attempting to define a custom file type (way at the top) and then define the tab length (near the bottom).
It seems like you need to install a grammar for .pro files, for example language-qtpro, otherwise the source.pro scope won't be active.
(I believe this works because of the fileTypes field of a grammar package, which activates the scopeName field.)
It appears, that Atom reverses the scopes for the language in config.cson, so rather than using .source.pro it should be .pro.source (as with the others in your example). At least that's what it does, when you set up indentation in the package settings for a language.
Since you mentioned that you want to get along better with colleagues: Have you looked into using the editor-agnostic EditorConfig standard to share indentation settings with them? Whenever your project contains an .editorconfig file, that will override your personal preferences that you would use when no such file exists. EditorConfig is supported by many editors, directly or through plugins.
I'd like to add a grunt task that accepts a version number. This version number will then be set in the package.json file. I have found grunt-bump, which bumps the version number, but I would like to set the version number to a known value, that will come from the build server.
Grunt task:
grunt.registerTask('setversion', function() {
// Something to go here to update the version number.
});
package.json:
{
"name": "scoreboard",
"version": "0.2",
...
}
Anyone got any idea's?
You could use something like:
grunt.registerTask('setversion', function(arg1) {
console.log("Attempting to update version to "+arg1);
var parsedJson= grunt.file.readJSON("package.json");//read in the current
parsedJson["version"] = arg1; //set the top level version field to arg1
grunt.file.write("package.json", JSON.stringify(parsedJson, null, 2));
});
add in some error checking etc.. make sure package.json is writable and execute with grunt setversion:newVersion e.g.: grunt setversion:0.3
Thanks for the answer, but it turned out to be a lot more straightforward. I am using TeamCity, so I ran an NPM task with the following command, where %system.build.number% follows the pattern n.n.n, e.g.: 0.1.6.
--no-git-tag-version version %system.build.number%
How can I compile a LESS file to output a source map file (.css.map) in addition to a CSS file? Is there a way to do it on both command line (NodeJS's lessc) and on any GUI-based programs?
Update: New shortest answer
The docs have been updated! As new features hit LESS, sometimes the docs lag behind a bit, so if you're looking for bleeding-edge features, you're still probably better off running lessc (see longer answer) and checking what pops out of the help text.
http://lesscss.org/usage/
Short answer
You're looking for any number of the following options from the command line:
--source-map[=FILENAME] Outputs a v3 sourcemap to the filename (or output filename.map)
--source-map-rootpath=X adds this path onto the sourcemap filename and less file paths
--source-map-basepath=X Sets sourcemap base path, defaults to current working directory.
--source-map-less-inline puts the less files into the map instead of referencing them
--source-map-map-inline puts the map (and any less files) into the output css file
--source-map-url=URL the complete url and filename put in the less file
As I write this I'm not aware of any GUI options that generate maps (source maps were only added to LESS in the last few months) -- sorry to not have any better news. I'm sure they'll add support in as they update over the next year.
Longer answer
If you run lessc from the command line without any parameters it will give you all the options. (In my experience, this is more up to date than their documentation, so it'll at least get you pointed in the right direction.) with all the most recent map stuff included.
The easiest combo to use for dev is --source-map-less-inline --source-map-map-inline as that will give you your source maps embedded in your output css.
If you'd like to add a separate map file, you can use --source-map which, from my.less will output my.css and my.css.map
For reference: when I run my copy (v 1.6.1 at the moment) I get
usage: lessc [option option=parameter ...] <source> [destination]
If source is set to `-' (dash or hyphen-minus), input is read from stdin.
options:
-h, --help Print help (this message) and exit.
--include-path=PATHS Set include paths. Separated by `:'. Use `;' on Windows.
-M, --depends Output a makefile import dependency list to stdout
--no-color Disable colorized output.
--no-ie-compat Disable IE compatibility checks.
--no-js Disable JavaScript in less files
-l, --lint Syntax check only (lint).
-s, --silent Suppress output of error messages.
--strict-imports Force evaluation of imports.
--insecure Allow imports from insecure https hosts.
-v, --version Print version number and exit.
-x, --compress Compress output by removing some whitespaces.
--clean-css Compress output using clean-css
--clean-option=opt:val Pass an option to clean css, using CLI arguments from
https://github.com/GoalSmashers/clean-css e.g.
--clean-option=--selectors-merge-mode:ie8
and to switch on advanced use --clean-option=--advanced
--source-map[=FILENAME] Outputs a v3 sourcemap to the filename (or output filename.map)
--source-map-rootpath=X adds this path onto the sourcemap filename and less file paths
--source-map-basepath=X Sets sourcemap base path, defaults to current working directory.
--source-map-less-inline puts the less files into the map instead of referencing them
--source-map-map-inline puts the map (and any less files) into the output css file
--source-map-url=URL the complete url and filename put in the less file
-rp, --rootpath=URL Set rootpath for url rewriting in relative imports and urls.
Works with or without the relative-urls option.
-ru, --relative-urls re-write relative urls to the base less file.
-sm=on|off Turn on or off strict math, where in strict mode, math
--strict-math=on|off requires brackets. This option may default to on and then
be removed in the future.
-su=on|off Allow mixed units, e.g. 1px+1em or 1px*1px which have units
--strict-units=on|off that cannot be represented.
--global-var='VAR=VALUE' Defines a variable that can be referenced by the file.
--modify-var='VAR=VALUE' Modifies a variable already declared in the file.
-------------------------- Deprecated ----------------
-O0, -O1, -O2 Set the parser's optimization level. The lower
the number, the less nodes it will create in the
tree. This could matter for debugging, or if you
want to access the individual nodes in the tree.
--line-numbers=TYPE Outputs filename and line numbers.
TYPE can be either 'comments', which will output
the debug info within comments, 'mediaquery'
that will output the information within a fake
media query which is compatible with the SASS
format, and 'all' which will do both.
--verbose Be verbose.
If the command line doesn't suite you, Grunt is great at this type of thing. You can configure the grunt-contrib-less plugin to generate inline maps with a config like this:
less: {
options: {
sourceMap:true,
outputSourceFiles: true
},
lessFiles: {
expand: true,
flatten:false,
src: ['**/*.less'],
dest: ['dist/'],
ext: '.css',
}
},
https://github.com/gruntjs/grunt-contrib-less
Example to Create Map and CSS file from Less File
Install latest Node JS and go to command prompt and run npm install less, Now less installed successfully
Go to Command Prompt and move to less file folder that we are going to create
For e.g., I am going to change HelloWorld [Less File]
In Command prompt go to C:\Project\CSS or give the correct path in the below command.
Run following Command in Command Prompt
lessc HelloWorld.less HelloWorld.css --source-map=HelloWorld.css.map –verbose
Now CSS and Map file is generated in the respective folder.
For more reference check the link : royalarun.blogspot.com
I am using command line options in my grunt script: http://kurst.co.uk/transfer/Gruntfile.js
However the command grunt --vers:0.0.1 always returns 'undefined' when I try to get the option:
var version = grunt.option('vers') || '';
Can you help me get this working ?
I tried different (CLI) commands:
grunt vers:asd
grunt -vers:asd
grunt vers=asd
as well as using :
grunt.option('-vers');
grunt.option('--vers');
But no luck so far. Hopefully I am missing something simple.
This is my package.js file:
{
"name": "",
"version": "0.1.0",
"description": "Kurst EventDispatcher / Docs Demo ",
"devDependencies": {
"grunt": "~0.4.1",
"grunt-contrib-yuidoc": "*",
"grunt-typescript": "~0.1.3",
"uglify-js": "~2.3.5",
"grunt-lib-contrib": "~0.6.0",
"grunt-contrib-uglify":"*"
}
}
The proper syntax for specifying a command line argument in Grunt is:
grunt --option1=myValue
Then, in the grunt file you can access the value and print it like this:
console.log( grunt.option( "option1" ) );
Also, another reason you are probably having issues with --vers is because its already a grunt option that returns the version:
★ grunt --vers
grunt-cli v0.1.7
grunt v0.4.1
So it would probably be a good idea to switch to a different option name.
It is worth mentioning that as the amount of command line arguments you want to use grows, you will run into collisions with some arguments that grunt uses internally.
I got around this problem with nopt-grunt
From the Plugin author:
Grunt is awesome. Grunt's support for using additional command line options is not awesome. The current documentation is misleading in that they give examples of using boolean flags and options with values, but they don't tell you that it only works that way with a single option. Try and use more than one option and things fall apart quickly.
It's definitely worth checking out
The log rotation for Plone product installation would be a nice feature. What are the current best practices regarding the log rotation integration into Plone?
I found this article: http://encolpe.wordpress.com/2010/06/17/how-to-get-log-files-rotate-in-zope-with-buildout/ but as there are no documentation on plone.org I'd like to ping the community for the good known best practices not to fill up their hard disks.
ZConfig has support for the standard library RotatingFileHandler and TimedRotatingFileHandler. Taking an example from the ZConfig tests:
<eventlog>
<logfile>
path /path/to/file.log
level debug
when D
interval 3
old-files 11
</logfile>
</eventlog>
This will roll over the logs every three days, keeping 11 old files.
You place these config snippets your buildout using the event-log-custom/access-log-custom parameters in your instance recipe. plone.recipe.zope2instance
Similar to what Laurence said above but keeps size under 10mb and saves only 1 old file.
<eventlog>
level INFO
<logfile>
path /path/to/plone4/var/log/client1.log
max-size 10mb
old-files 1
</logfile>
</eventlog>
plone.recipe.zope2instance can generate this now. For example, you can specify the following options:
event-log-max-size = 10mb
event-log-old-files = 3
Here's what we do, it's simple but works:
In your buildout you add this part:
[logrotate]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/logrotate.conf
output = ${buildout:directory}/etc/logrotate.conf
And in templates/logrotate.conf
rotate 4
weekly
create
compress
delaycompress
missingok
${buildout:directory}/var/log/instance1.log ${buildout:directory}/var/log/instance1-Z2.log {
sharedscripts
postrotate
/bin/kill -USR2 $(cat ${buildout:directory}/var/instance1.pid)
endscript
}
${buildout:directory}/var/log/instance2.log ${buildout:directory}/var/log/instance2-Z2.log {
sharedscripts
postrotate
/bin/kill -USR2 $(cat ${buildout:directory}/var/instance2.pid)
endscript
}
Add whatever other log rotations you need. Then it's about linking /etc/logrotate.conf to the generated file.
Mikko, you should ask me directly ;)
My blog article is still good and this feature is still undocumented in Zope2. It can be used with Plone 4 and Plone 5. The extension iw.rotatelogs was designed for Plone 3 only.
Using logrotate is not fine because it doesn't handle the case of logwriting during the rotation. It can make your instance crash silently and writing logs in RAM until your restart the instance.
I've been using iw.rotatezlogs since at least early Plone 3 very successfully. I see from your link that I should no longer need iw.rotatezlogs.
I don't like to rely on logrotate, since it's not usable on the one Windows server I have to deploy to.
As near as I can tell, the pure-zope solution (which I stil haven't tested) doesn't do logfile compression (at least I can't see it in ZConfig/components/logger/handlers.xml which is where I think it should be defined), so I suspect I'll be staying with iw.rotatezlogs.