I'm using the following code...

#!/usr/bin/perl

use CGI::Carp qw(fatalsToBrowser);

use strict;
use warnings;

use lib ( "$ENV{'DOCUMENT_ROOT'}/../lib", "$ENV{'DOCUMENT_ROOT'}/../..
+/prod/lib" );

use Bod::CRM;
use Site::Utils;

die "X - " . $file{'receipt', 'file'};
[download]

The variable $file{'receipt', 'file'} is defined using our and exported with Exporter in the private module Site::Utils.

Different die statements give very different results
die "here!"; - CGI::Carp works as expected
die "X - " . $xxx; - CGI::Carp works as expected - global symbol $xxx requires...
die "X - " . $file{'receipt', 'file'}; - CGI::Carp doesn't write anything to the browser - I just get a 500 error from the browser.

How can this be?

Having changed server from CentOS to Debian 12 and Perl version from 5.16.3 to 5.36.0, I am having lots of difficulties with character encoding. A topic I don't properly understand. This problem is currently manifesting itself as a failed Stripe webhook. The webhook was working fine before and now it isn't!

Stripe gives me this error:
Invalid encoding: ISO-8859-1

I have checked the Debian encoding (I think) and it says:

~# echo $LANG
C.UTF-8
[download]

Here is a very cut-down version of my code to demonstrate the problem:

#!/usr/bin/perl

use CGI::Carp qw(fatalsToBrowser);

use strict;
use warnings;
use utf8;

use JSON;

print "Content-type: application/json; charset=UTF-8\n\n";
print encode_json {
    'testing' => 'some test',
};
[download]

If I call the webhook endpoint in browser, I get the expected JSON output but Stripe gives me the encoding error.

Given that only two things have changed, server OS and Perl version, it must be one of these. Is there anything I need to do on the server to ensure that it is serving UTF-8 output correctly?

There are other problems that I think are unconnected, but wise monks may find helpful as they could have the same cause...

• .htaccess files don't work - they cause a 403 error as soon as RewriteEngine is enabled
• When I edit some (but not all) Perl scripts, the permissions change from the Plesk psacln group and the correct owner to root
• When duplicating or copying a Perl script the permissions always change to root and from 755 to 644
• If I set up FTP accounts, they only have read permission regardless of what group(s) the account gets put in

I am using Spreadsheet::Read to provide a universal way to read spreadsheets that users upload. I'm using this module because I have no idea what flavour of spreadsheet users might want to upload.

This module relies on others to do the work of reading the data. Is there a way to install the modules it uses "on demand"? So only when we first see a Lotus 1-2-3 spreadsheet, for example, do we install the module to read it.

The purpose of this is to convert the spreadsheet to CSV, so I have it in a standard format for the next part of the processing, which is mapping the data fields ready to import into a CRM - perhaps I am overthinking the universal spreadsheet part...

After a server change, we are getting lots of strange characters from an encoding issue.
Double spaces and emojis are displayed as Â

I think this issue is related to the change from Perl version from 5.16.3 to 5.36.0. From the Perl Delta, I note there have been some changes to the way Perl handles UTF encoding, but I don't understand the implications of this.

We've also upgraded MariaDB from 10.5 to 10.11 but both the character set and the collation are the same. utf8mb4 and utf8mb4_general_ci respectively.

This issue is not just about data that was created prior to the change. Although emojis created after the change are not mutilated, double spaces are.

All web output is UTF8 encoded using:
Content-Type: text/html; charset=UTF-8

Any suggestions where I should look to solve this issue.

I've just found out the HMRC (the UK's taxation department) uses Perl for at least some of its operations...

The system is troubled today and I received this error revealing the language

Ref: /home/ewf/MODULES/Common/PaymentApiService.pm

Error Code 401 at line 30
[download]

Update: corrected typo in title

We've started the process of moving hosting server to a cheap VPS - just non-essential (read "hobby") sites for now whilst we get to grips with it and I learn how to manage a server...

All is going relatively well so far, but I've found an anomaly with time settings. Can anyone explain what is going on?

The 'old' server observes DST whereas the 'new' server doesn't. If I run timedatectl on the 'new' server it tells me it is set to UTC. I don't have access to run the same command on the 'old' server.

Here in the UK we are now on BST (GMT+1) so things that are time dependent (like Google Calendar feeds) that have been moved over are all 1 hour out. If I get the time from the MariaDB database SELECT NOW() I get GMT, as expected.

However, I have a bit of test code left in a page that only I use. It's a bit of JavaScript document.write(document.lastModified); which shows the time in BST. Doen't that time get passed in the HTTP headers from the Perl generated web page? Perl is, of course, also reporting GMT.

The obvious solution seems to be to change the server time from UTC to GMT.
Will that then observe UK DST?
Are there any reasons not to change the server to GMT bearing in mind that the entire codebase was written on a server that observes DST?

Update: - the "obvious" option to set would be 'Europe/London' but that is not included in timedatectl list-timezones

I have some common modules that are used in several places so I have created a directory for them at /usr/lib/perl_modules. I want to include this location in @INC for every user, including CRON.

I've added export PERL5LIB=/usr/lib/perl_modules in both /etc/environment and /etc/profile.

When I list the environment variables, PERL5LIB is there as expected. But when I try to use on of the modules I get an error:

Can't locate my_module.pm in @INC (you may need to install the my_modu
+le module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/
+perl/5.36.0 /usr/local/share/perl/5.36.0)
[download]

I suspect the environment variable is set for root that I'm using to list the variables, but not for whatever process is running the script within Apache.

How can I properly set PERL5LIB for all users and processes or is there a better way to get an extra entry in @INC for every script without having to use lib in every script?

We operate a number of websites, all of which operate on the same server.

Currently, I am the only developer. But that is likely to change over the next 18 months or so. I'm making some changes that present the opportunity to make some improvements to the internal design and security of the sites. I'm looking for some input on the "best" way to do this. Any input welcome but especially around global site variables.

Currently we have this directory structure (plus a few others omitted for simplicity:

site/prod/bin/
site/prod/lib/
site/prod/template/
site/prod/www/
site/test/bin/
site/test/lib/
site/test/template/
site/test/www/
[download]

Every site has identical code in prod and test (except for during development of course) except for one file site/lib/vars.pm which declares the site variables needed for that site and environment. Things like the DB credentials, the DB instance to connect to, Stripe keys, API keys, etc.

use strict;
use warnings;

our $env_db_user     = 'dbusername';
our $env_db_pass     = 'dbpassword';

our $env_paypal      = 'PP username';

# etc, etc, etc
[download]

When we bring another developer onboard, I want to split the site variables into two - those they have access to (test database schema name, text Stripe keys, etc) and those they don't (live Stripe keys, database credentials, etc). I could relocate this file to further up the directory structure where they don't have access, but I feel sure there is a better way to handle this as it must be a common problem in multi-developer environments.

What I have works well and it not in need of imminent change. But I have opportunity to make it more robust as I am making other changes.

What advise can you give on this matter kind and wise Monks?

I need to install a Mail Transfer Agent that will be used with MIME::Lite

I understand that the modern choices are Postfix or Exim. However, MIME::Lite says it uses sendmail which is pretty old isn't it?

I have never looked at MTA's before so any advice would be appreciated. This is being installed on a RaspberryPi. Does the MTA only deal with outgoing mail or will it manage incoming mail as well? If not, what do I need for that?

I'm creating user-defined custom fields in Maria DB using the JSON Data Type. I've never had cause to use this data type before so I've been playing learning by running queries directly against a test database to get the syntax right. I thought I'd got this to the point where I can use it and imagined that there could be some issues with getting the DBI placeholders right.

But I seem to have hit a more tricky issue...

I started with this DBI query:

$row->{'inuse'} = $dbh->selectrow_array("SELECT COUNT(*) FROM Person W
+HERE Account_idAccount = ? AND JSON_EXISTS(custom, ?)", undef, $accou
+nt, "$." . $row->{'name'});
[download]

However, I slowly removed the placeholders to test where things were going wrong. To the point where I arrived at this with no placeholders...

$row->{'inuse'} = $dbh->selectrow_array("SELECT COUNT(*) FROM Person W
+HERE Account_idAccount = 35 AND JSON_EXISTS(custom, '$.test3')");

die $dbh->errstr if $dbh->err;
die $row->{'inuse'} if $row->{'inuse'};
[download]

But, if I run the same query directly against the same database:

SELECT COUNT(*) FROM Person WHERE Account_idAccount = 35 AND JSON_EXIS
+TS(custom, '$.test3')
[download]

Is there a problem using the MariaDB JSON Data Type with DBI or have I missed something else obvious?