I am working on phpspreadsheet where i am downloading the users account details, but phpspreadsheet is rounding off the account numbers and also removing the 0 from starting.
Example:
Original=> 545778985645453699
After PHPSpreadsheet code => 545778985645453700
Original=> 0256884555
After PHPSpreadsheet code => 256884555
I want numbers to be exact like i am pulling from DB using laravel.
Tried, converting datatype but its making cells value to 0. Tried numberformat its also not working.
$spreadsheet = new \PhpOffice\PhpSpreadsheet\Spreadsheet();
$sheet = $spreadsheet->getSheet(0);
$sheet->fromArray($Final, null, 'A1');
$sheet->getStyle('A1:A1')
->getNumberFormat()
->setFormatCode(\PhpOffice\PhpSpreadsheet\Style\NumberFormat::FORMAT_TEXT);
$writer = new \PhpOffice\PhpSpreadsheet\Writer\Xlsx($spreadsheet);
Is there any alternate colution for this issue, or am i doing anything wrong here.
Quite an old question but I had this problem as well, PHPSpreadSheet was changing big numbers like 1606778294323857 into 1606778294323860. If you just need to have those values as is and do not need to have it "formatted" (type) as number, this helped me.
Solution was to set the type to String explicitly:
$sheet->getCell('A1')->setValue(1606778294323857)->setDataType(DataType::TYPE_STRING);
My version of PHPSpreadSheet: 1.16
Related
When I import product data or I upload image directly to a product I get the following message (was not uploaded. Filename is too long; must be 90 characters or less)
Recently my magento has been updated and I didn't have this problem before.
Does anyone know how I can increase the number of characters slightly?
enter image description here
I was able to solve the problem myself.
The file in question is located in the following folder
vendor\magento\framework\File Uploader.php
search for the following code:
// account for excessively long filenames that cannot be stored completely in database
if (strlen($fileInfo['basename']) > 90) {
throw new \InvalidArgumentException('Filename is too long; must be 90 characters or less');
Adjusting this file is not the best method, I have to add
For anyone finding this question on Google, I wanted to share additional findings, as I've faced the same issue. Perhaps you will find them helpful.
As #Timo already wrote, the limit of 90 characters is hard-coded in the getCorrectFileName() method in vendor\magento\framework\File\Uploader.php (in older versions of Magento).
public static function getCorrectFileName($fileName)
{
(...)
$maxFilenameLength = 90;
if (strlen($fileInfo['basename']) > $maxFilenameLength) {
throw new \LengthException(
__('Filename is too long; must be %1 characters or less', $maxFilenameLength)
);
}
(...)
}
Since this method is static, writing a plugin is not possible and apparently providing a preference won't work as well.
It seems that there was a fix for this already available in Magento, but only in versions 2.4.2 and 2.4.2-p1. Then, for whatever reasons it got removed. See the related Github issue.
Since Magento v2.4.5 the file name length is now limited to 255 characters:
private const MAX_FILE_NAME_LENGTH = 255;
(...)
public static function getCorrectFileName($fileName)
{
(...)
if (strlen($fileInfo['basename'] ?? '') > self::MAX_FILE_NAME_LENGTH) {
throw new \LengthException(
__('Filename is too long; must be %1 characters or less', self::MAX_FILE_NAME_LENGTH)
);
}
(...)
}
So, until you upgrade your Magento version to 2.4.5 or newer, it seems that making a change in the core code is the only option, either manually or using a composer patch.
We're building a system to validate mobile phone numbers.
To achieve this, when a user adds his number, we are sending him a text message with a 6 digit code.
We don't want this code to go in our database as we don't like to clutter our database with fields that have no business meaning.
So we came up with the idea to reuse pragmarx/google2falibrary, have it generate an OTP code, dispatch it to the user by a text message, and then the circle would be round.
So basically we wanted to use the phone number, prefixed by somehting secret as the "secret" for the pragmarx/google2fa library:
$secret = '1263' . $mobile->country_code . $mobile->subscriber;
$google2fa = new Google2FA();
$google2fa->setEnforceGoogleAuthenticatorCompatibility(false);
$google2fa->getCurrentOtp($secret);
The above results in a secretsimilar to 12633232970987. However, the call to getCurrentOtp throws an exception Invalid characters in the base32 string. which is obviously not what I was hoping for.
So, I tried adding
$secret = base_convert($secret, 10, 32)
and pass that to the getCurrentOtpmethod, but that returned the same error. Checking into the library code, I see the following constant:
const VALID_FOR_B32 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567';
My base_convert returns a string that has other characters in there though. Are these really the only valid characters?
My alternative would be to just have the library generate a random secret, but we don't really want to do that, as that would require us to keep that secret somewhere in the database (or at least in cache), which we would like to avoid. The idea is that we could generate the code for a mobile number using the number as the secret, and let the OTP mechanism deal with expiring codes.
Anyone has any suggestion how I can resolve this?
So, I'm trying to make smarty format a number like 1000.66 to 1,000.66 but when I use {$number|number_format:0:'.':','} it just rounds it up to 1,001...
I've googled but I can't find anything about it...
|number_format just uses the php function of the same name. Your problem is that you specified the number of decimals as 0, and the function rounds up the number provided. Try with
{$number|number_format:2:'.':','}
I'm trying to use trans_choice() to simply format a string to either "comment" or "comments" depending on the number of them. It should be fairly straightforward, like this.
In my view:
{{ trans_choice('posts.num comments', $post->comments->count()) }}
In the posts localisation file:
return [
'num comments' => 'comment|comments',
];
However, every single one returns just "comment". And if I go into tinker:
>>> trans_choice('posts.num comments', 1);
=> "comment"
>>> trans_choice('posts.num comments', 2);
=> "comment"
>>> trans_choice('posts.num comments', 4);
=> "comment"
I'm sure I'm missing something obvious but it looks to me as if I've followed the documentation perfectly.
Edit: The problem seems to lie somewhere in Symfony\Component\Translation\MessageSelector, but I haven't yet figured the cause out.
Finally found the answer. Apparently, if the locale isn't available in Symfony's PluralizationRules class, the translator defaults to the first pick - that is, always index zero. By changing the locale name (I didn't even realise it was misspelled...), I got it working.
I know this post is old, but I ran into this issue, so hoping my solution helps someone if Joel's solution doesn't work.
I'm working with Laravel 7.x, and am using localization on a project for differences between US an CA English, (i.e. Center vs. Centre).
I have my localization folders set up with en being the default folder and en_ca as the Canadian English folder, where en is also the fallback language.
When using trans_choice() I found I had to specifically set the the counts in my translation strings, otherwise the translation engine would just spit back the singular when viewing pages in the non-default locale.
Once the changes were made, trans_choice() worked, no matter what locale was set.
For example, wherever I had:
'general.posts' => 'Posts|Posts',
I changed it to:
'general.posts' => '{1} Post|[2,*] Posts',
After that everything worked.
If you're brazilian that's probably your answer!
I just had the same problem and found out it was because of my locale option (and lang folder).
Instead of 'br' we must use 'xbr' in order to Symphony find it in PluralizationRules (vendor/symphony/translation/PluralizationRules).
In that file there's an array with all languages available, so may check it out.
P.S. I'm using Laravel 5.3
I need to change Magento's default decimal format. I mean, when I save '1' to a decimal field, it becomes '10000.0000' with this '.0000' in the end.
I need to change it to another format, which uses ',' instead of '.' to separate decimal (and currency) numbers.
This is the Brazilian standard and it's not being used even after changing the store language. This change should be reflected mainly in the admin side.
Thanks a lot!
==Edited==
I haven't solved the problem yet. I'm using PT-BR (Brazilian Portuguese) as default language and it still using the wrong decimal character.
It seems Magento have some not-localized price formatting (I mean, hard-coded) in a few points of code. For example: magento\js\prototype\validation.js at line 426 have:
|| (!isNaN(parseNumber(v)) && /^\s*-?\d*(\,\d*)?\s*$/.test(v));
but instead it needs to be
|| (!isNaN(parseNumber(v)) && /^\s*-?\d*(\,\d*)?\s*$/.test(v));
to fit into PT-BR format (or other locales to).
Am I right? Does anybody could fix this issue?
if you want to check in admin area for this change
you go to in admin left bottom drop down
and select
Português (Portugal) / português (Portugal)
it will show you currency as you want. Also if you doesn't install you package go to
http://www.magentocommerce.com/translations/list/19
download your package and add it to your
locale folder and select from configuration for front end also
hope this will sure help you.
I've applied the following change to the file magento\js\prototype\validation.js (line 426):
|| (!isNaN(parseNumber(v)) && /^\s*-?\d*(\,\d*)?\s*$/.test(v));
and also, changed the file lib/Varien/Data/Form/Element/Abstract.php by adding the first if statement:
public function getEscapedValue($index=null)
{
$value = $this->getValue($index);
if(is_numeric($value)){
$value= number_format($value, 3, ",", ".");
}
...
this changes have solved the problem so far. Do you see any side-effect?
Comments are welcome! Thanks!
Newer versions of Magento are based on Zend Framework currency locale format so the best way to do this is to change the language.xml from the Zend directory, more information is on this great article.