v155f PHP 8.1, language override, Warning: constant TEXT_MAIN already defined?

[neekfenwick]

I'm moving to PHP 8.1 and running into lots of Warning level errors that make me think the standard advice for setting up language overrides may not be optimal. I think this problem has arisen because PHP 7 did not raise this situation as a Warning, but PHP 8 does. From https://docs.zen-cart.com/user/new_u...ics/overrides/ :

- Create a new directory /includes/languages/english/YOURTEMPLATE/ if it doesn’t exist
- Copy includes/languages/english/account.php to this new directory
- You now have includes/languages/english/YOURTEMPLATE/account.php

In my case, for simplicity, I'm on the home page of the site, so the page name is 'index'. Out of the box, there is includes/languages/english/index.php. The advice says to create a folder and copy the file, to make includes/languages/english/my_template/index.php, and edit strings I want to change. includes/modules/require_languages.php will then load the my_template version, but then also load the core english/index.php as well. because all the strings are defined there as well, we get a Warning raised about the constants already being defined. It seems to only complain about the first one encountered, TEXT_MAIN, but commenting that one out in the core english/index.php just means the next one is then raised as a Warning.

So, this may be a silly question, but does the process of setting up a language override deliberately result in duplicating constant definitions, resulting in these Warnings, or am I misunderstanding the process and ought to do something else? If this is caused by my moving to PHP 8, with PHP 7 not raising this error, was it acceptable before and needs addressing now we're all going to be moving to PHP 8 (PHP 7 goes EOL at the end of this year)?

I'm eyeing the possibility of upgrading our site from 1.5.5 to the latest, but am not sure if this is 1.5.7d (Feb 2022) or if 1.5.8 is about to be released. If 1.5.8 is just around the corner and has better PHP 8 support it'll be worth waiting for. An upgrade to different ZC version is going to be a pretty huge task for us. Any advice please?

Thanks!

[mc12345678]

1.5.7d was relatively hastily released to provide the support needed for at least php 8.0 while also likely 8.1 with a few cases of similar issues. 1.5.5 was designed for a highest php version of 7.1.

Even when using php 8.0 with zen Cart 1.5.7, you may want to disable the reporting of duplicate definitions from within the admin, configuration, logging section.

Yes, in the next revision the language handling is modified to support removal of these duplicates but as usual, there is likely to be little forewarning of when it will be issued but instead a statement that it has been issued. Far better to do the upgrade to 1.5.7d now.

[neekfenwick]

I see, thank you mc12345678 .. sounds like we'll target 1.5.7d then. An ability to mute duplicate definition Warnings sounds interesting, I didn't think such a thing would be possible.

Tried installing 1.5.7d as a test, got stuck in zc_install when it tries to query the orders_status table, which of course doesn't exist in an empty database. Bit confusing. Will try again tomorrow.

[torvista]

I'm moving to PHP 8.1

Unless you want to waste your time chasing debugs all day, stay on php8.0x until you are using ZC158, where all these issues are already fixed.

[neekfenwick]

Unless you want to waste your time chasing debugs all day, stay on php8.0x until you are using ZC158, where all these issues are already fixed.

Thanks, I appreciate the heads up. Any migration between ZC versions is a big job for us and quite risky in terms of customer facing downtime and chaos in our production warehouse, and we certainly will want to target PHP 8.1. So, I guess I'll sit on this for a few months, stay on php7.4, and hope ZC158 comes out. If ZC157d does not really play well with PHP 8.1 then it's not an attractive platform, as we certainly don't want to migrate to 157d only to have to migrate to 158 shortly after.

[marcopm]

Why not migrate to PHP 8.0 for now? It works perfectly with ZC 157d

[dbltoe]

Why not migrate to PHP 8.0 for now? It works perfectly with ZC 157d

Because the OP is using 1.5.5f

@neekfenwick
Establish a subdomain (e.g. test.your_ddomain.com) with a directory located "above the root" (e.g. home/_test vs home/public_html/_test.

You can use it to play with 1.5.7d to your heart's content AND, with it above the root, you can use whatever PHP version you want.

The reason I would do this now is that is the payment fixes and a security fix in 1.5.7# files. If you are using PayPal and/or Square, you may find yourself without a viable payment method soon.

[neekfenwick]

Because the OP is using 1.5.5f

Indeed. Than you @marcopm for the suggestion but we're using quite an old version of ZC. I've happily attacked an attempt to run it on PHP 8.1 and fixed minor issues like lack of parenthesis around ternary operators and quite a lot of references to undefined variables like $_SESSION['customer_id'] used in a boolean context a la Javascript, but it's pretty tedious. I'm left wondering, what has changed in ZC since then that we would benefit from? Despite the burden of migration, I'm feeling we need to move to a newer ZC. One issue I face, like many of us at the coal face, is that the business owner who pays my bills won't want to do it until something breaks, but I can wave the obsolescence of PHP 7 in his face (without using long words like obsolescence).

Establish a subdomain (e.g. test.your_ddomain.com) with a directory located "above the root" (e.g. home/_test vs home/public_html/_test.

You can use it to play with 1.5.7d to your heart's content AND, with it above the root, you can use whatever PHP version you want.

The reason I would do this now is that is the payment fixes and a security fix in 1.5.7# files. If you are using PayPal and/or Square, you may find yourself without a viable payment method soon.

Cheers @dbltoe, good points. We don't use Paypal or Square, we're using a very old Sage Pay module, which does have a rather nasty security hole in that you can edit the basket in another tab while at the payment page and essentially get products for free but no-one seems to care much about that. The previously mentioned business owner doesn't want to change it because nothing has broken yet. I've added modifications that compare the basket pre- and post-payment and alert us to irregularities.

Since you mention it, we have a wildcard SSL certificate and root access to our host, so instead of installing it 'above the root' as you say, which I did do for years, we can also set up an Apache VirtualHost foo.oursite.co.uk and configure this 'foo' domain to a DocumentRoot different to our production site. This is rather moot at this point as I'm working entirely on my local dev system so it's all foo.oursite with a FilesMatch->SetHandler conf directive telling it to use the php81 socket to serve the test site. Changing PHP versions is trivial, actually making the software work with that PHP version is the much larger problem, at this point necessitating migration to a newer ZC :)

[dbltoe]

Another consideration.

For seven months, PHP 7.4 has technically been security fixes only and will go End of Life (EOL) in four.

A LOT of hosts will drop 7.4 within a month of EOL. And, that always seems to happen when you're on a two week vacation.

The best time to get current is always yesterday.

[neekfenwick]

A LOT of hosts will drop 7.4 within a month of EOL. And, that always seems to happen when you're on a two week vacation.

True, however we have root on a dedicated server and are not going to be caught out by our host suddenly deprecating our version of PHP.

This argument seems more relevant to those on shared hosting or less dedicated hosts, who are going to be bitten in the arse when this change comes, so it's a valid point.

The best time to get current is always yesterday.

I'm surprised ZC dev isn't more up to date, with php8.0 being released in late 2020, over 2 years ago. From @mc12345678 earlier post "1.5.7d was relatively hastily released to provide the support needed for at least php 8.0 while also likely 8.1 with a few cases of similar issues." When wanting to move to the latest release version of PHP (8.1 in our case) I'm hesitant to put serious migration effort in to a version of ZC that doesn't well support it. I'm sure this is an old argument and don't want to sound ungrateful to the ZC team :)