We are testing the Imageresizer.net and have found that the Preset Plugin seems to only work with width and height parameters and completely ignores the mode parameter i.e. mode=crop.
Is this a bug or simply not supported.
Many thanks
It is supported, but know that the presets settings and defaults values must be valid command/querystrings. Spaces or typos in the command string will cause that command (and potentially the rest) not to function.
Related
Sonar displays Rename function to match the regular expression ^[a-z][a-zA-Z0-9]*$ for any composable Jetpack Compose function starting with an uppercase. Is it possible to somehow suppress those logs?
Do not use the platform for Compose apps for now, since clearly, the developers have not yet adapted to the framework. Compose encourages you to use function names starting with an uppercase letters, but they are still 'functions', which traditionally start with a lowercase letter and hence the warning.
Unless they provide a way to manipulate the logs explicitly (check their FAQs), there's not much you can do, other than temporarily stopping their product's use in files containing #Composable definitions.
I am not sure if that is the best solution but at this moment I have not found better.
Just simply disable the inspection (alt+enter) at the warning and you should see the option.
I am looking forward for better idea.
In your Sonarqube Quality Profiles, change the kotlin:S100 rule ("Method names should comply with a naming convention") from
^[a-z][a-zA-Z0-9]*$
to the "Sonar way":
^[a-zA-Z][a-zA-Z0-9]*$
From what I can tell from the CSON README and other CSON usages I've found on the Internet, it's conventional to use single rather than double quotes for string literals. Because of this (and because I agree with the rationale I've generally seen behind this convention), I am using it for my Atom config files, such as keymap.cson:
'body':
'ctrl-tab': 'pane:show-next-item'
'ctrl-tab ^ctrl': 'unset!'
'ctrl-shift-tab': 'pane:show-previous-item'
'ctrl-shift-tab ^ctrl': 'unset!'
So far, this has worked fine for me. However, I am running into a problem when I try to use the same convention for my config.cson file as well. For instance, I am trying to have its contents set to the following:
'*':
core:
disabledPackages: [
'exception-reporting'
]
restorePreviousWindowsOnStart: false
telemetryConsent: 'no'
welcome:
showOnStartup: false
whitespace:
ignoreWhitespaceOnCurrentLine: false
But if I open Atom and hit Ctrl+= Ctrl+- (to play with the font size) or do some other similar change and then restore Atom back to its previous state, Atom changes my config.cson file to look like this:
"*":
core:
disabledPackages: [
"exception-reporting"
]
restorePreviousWindowsOnStart: false
telemetryConsent: "no"
editor: {}
welcome:
showOnStartup: false
whitespace:
ignoreWhitespaceOnCurrentLine: false
As you can see, it changed all the single quotes to double quotes and added an unnecessary editor section.
Is there a way to prevent Atom from making these sorts of superficial changes to my config.cson file? The reason this matters to me is that I am keeping my Atom config files in version control, so in order to prevent very noisy diffs, I would need to either disable this behavior or use inconsistent or suboptimal styling for my quotes, and I would find the former option much more preferable if it is possible.
If it's an option to switch the file-format, consider using config.json instead. Since JSON uses double-quotes by convention, there should be no conflict when making changes to your Atom configuration.
Atom is already in the transition to move away from CoffeeScript (and CSON) and you can use JavaScript/CoffeeScript and JSON/CSON interchangeably throughout the app.
As of v2.0.0, the cson-parser library uses the conventional default for quote type when stringifying CSON, so you can write a simple shell script using that library and run it on config.cson before committing to Git. It would also be relatively simple to remove things like the empty editor section in such a script before calling stringify.
You could potentially write this into an Atom package, as #idleberg mentioned in a comment, but I haven't tried that myself.
If season upgrades its cson-parser dependency to v2.0.0, that would solve the quote type problem, but the empty editor section would still need to be removed by something else.
I'm seeing many "unmappable character for encoding UTF-8" errors messages when I run a gradle build like this:
C:\5.0-Maint-New-Techs\src\com\avada\jms\base\JmsUtils.java:136: error: unmappable character for encoding UTF-8
� You can use arrays as well as primitive types for the values.
When I go to the lines that are flagged this way, they look perfectly fine in my editor. Not sure if this is a gradle or idea issue...any ideas on how to get around these errors?
Please change the non-ascii characters to double quotes(") or any other character(this is basically work around solution of the problem). This problem will be resolved. I think this issue is due to intellij.
We are trying to use grunt-lesslint in our project, as our UI developer is comfortable fix errors in less file. grunt-recess seems more powerful but not sure if it can point errors in less file itself. I am unable to comprehend enough from lesslint page, and there do not seem to be many examples. Does anyone know the following:
How to prevent lesslint from displaying on the console. I use formatters and the report file is generated, but it also prints on console, which I do not want to.
How to make lesslint fail only in the case of errors (not warnings). Also csslint seems to report errors also, while lesslint mostly gives warnings only, why is that so? Does lesslint throw errors as well? How to make it fail only in case of errors?
I tried using 'checkstyle-xml' formatter, but it does not seem to use it (I have used in jshint and it gives a properly formatted xml, which it does not give for lesslint).
Is it possible to compile less (many files or directories) in conjunction with lesslint? Any example?
Thanks,
Paddy
I'd say it's more of a common practice to display stdout for this kind of thing; the JSHint plugin does it, as does any other linting plugin that I've used. If you get in another developer that uses Grunt they'll probably expect stdout too. If you really want to override this, use grunt-verbosity: https://npmjs.org/package/grunt-verbosity
Again, this is a convention in Grunt; if a task has any warnings then it fails. The reason being if you lint a file and the linter flags something up it should be dealt with straight away, rather than delay it; six months time you have 500 errors that you haven't fixed and you're less likely to fix them then. Most linting plugins allow you to specify custom options (I've used CSS Lint and that is very customisable), so if you don't like a rule you can always disable it.
This should work. If there's a bug with this feature you should report it on the issue tracker, where it will be noticed by the developers of the plugin. https://github.com/kevinsawicki/grunt-lesslint/issues
Yes. You can set up a custom task that runs both your linter and compile in one step: something like grunt.registerTask('buildless', 'Lint and compile LESS files.', ['lesslint', 'less']); note that you'll have to install https://github.com/gruntjs/grunt-contrib-less to get that to work. Also note that, failing linting will not compile your LESS files; mandate that your code always passes the lint check; you'll help everyone involved in the project.
In my xampp it returns the following error, when i call functions without quotes ($_SERVER[SERVER_NAME])
Notice: Use of undefined constant SERVER_NAME - assumed 'SERVER_NAME'
What i must change in php.ini to correct this?
Thanks
UPDATE:
:) Sure i know, that if i add quotes, it will work, but i need to configure server to work without quotes too.
I clearly specify my problem. In my server it returns no warnings and no errors, if i do not use quotes. It is depend on xampp version. Now i install newer version of xampp on my local machine, and it show that notices, so i can't use my last projects, because there are handreds of that notices. (it returns such notice even when i use my defined variables, for example $myVariable[myItem]).
i can use
error_reporting(0)
But that will hide all errors. So i need to just specify new rules for my server, or use older version.
So, Why the downvotes?
Edit your php.ini to disable reporting of notices. find your php.ini by doing phpinfo()
error_reporting = E_ALL ^ E_NOTICE
Or do it in the script
<?php
error_reporting(E_ALL ^ E_NOTICE);
also consider setting display_errors = Off for live websites.
It's not constant, its an associative index. Use quotes:
$_SERVER['SERVER_NAME'];
Edit: If this is on a production environment and you simply need to hide these messages to buy you time to correct the real issue, add this to your page:
// Turn off all error reporting
error_reporting(0);
Don't change the configuration to fix your bad coding habits. This is what you should do:
$_SERVER['SERVER_NAME']
not this
$_SERVER[SERVER_NAME]
You could set the error level to ignore warnings, but you might miss some other important warnings if you do that. Just do it the proper way.
Don't change your php.ini, change your code:
$_SERVER['SERVER_NAME']
Also that is not called calling a function. $_SERVER is an associative array
Update
You must be able to add the quotes, suppressing those warnings is a very bad idea. That warning is basically a message saying "Your code is invalid, but I figured out what you meant soooo... you're lucky!". You won't always be that lucky if you choose not to use quotes.
The answer is that the boys that wrote PHP decided to change it for the sake of consistency in the PHP internals, ignoring the usability consequences to PHP programmers, and now you have to live with it. So you face the tough choice of either turning off all notifications or updating all your PHP defines.
PHP4 allowed the definition of unquoted constants and it was no problem. But I import perfectly good PH4 code to PHP5 and it breaks for no other reason than "you're a bad programmer".
If the authors of PHP wanted to do something truly useful then how about a notice for when a variable that has not been set (i.e. used as an lvalue in an expression) is used. I've had to deal with hundreds of bugs caused by misspelled variable names being allowed without any warnings from PHP.