bsmither

PHP 7+ no longer supports the MySQL extension (without the 'i'). The cPanel situation may just call any appropriate extension as being for communication with a MySQL database server. (I have no knowledge of cPanel.)

During the running of 'setup', CubeCart makes some tests: certain folders must exist and be writable, and key PHP extensions must be initialized. For CubeCart 6.5+, PHP 7.4+ (8.2 recommended but will probably be required for CC652+), the extensions include: MySQLi, GD Image library, Simple XML parser, cURL, ZipArchive, and the MultiByte String library. The test during setup is reported as a list of Pass/Fail line items on the second page shown. Setup will not proceed to the third page if any item shows as failed. CubeCart continuously checks to make sure the version of PHP is compatible, so should PHP change versions (7.4 downgrade to 7.3, for example), CubeCart will make complaints. However, CubeCart does not do continuous compliance checks for the presence of required extensions.

Turn it off?

Anything in the admin, Error Logs, System Error Log tab? Create PHP's error_log and review it after receiving reports. https://forums.cubecart.com/topic/51550-how-to-create-the-error-log/

If you can live without Google Analytics for a month, try removing your GA code from Store Settings, Features tab, (at the bottom) Tracking ID. Then have CubeCart clear its internal cache. This will prevent the GA javascript from being part of the web pages sent out to your visitors.

This is how I read it... If the visitor needs to have the browser make everything bigger (the browser's internal zoom feature), the image, being displayed at its 'natural' dimensions (16x16 or 24x24, or whatever), zooming in will only make the image blurry. (Browsers generally suck at enlarging images.) However, if the image is larger than what is required, 64x64 for example, but the screen real-estate (or the specific attributes in the <img> tag or CSS) only gives it 16x16 space to display it, then there is plenty of extra definition available to the browser when it needs to enlarge the image - keeping it nice and sharp.

Volteq is using Foundation, which has its own set of vendor jQuery plugins in the skins' /js/ folder. Mastech is using Kurouto, which uses CubeCart's generally available set of vendor jQuery plugins in CubeCart's /js/ folder. The generally available javascript files in CubeCart's /js/ folder allows for all CC5 skins to use the same files and keeping those files updated is easier. CC6's skins can be radically so different that it makes no sense to fixate on one set of javascript files.

What is the specific version of CubeCart 5? We strongly recommend CC5.2.17.

It was mentioned earlier that all paths have had the .html suffix removed. Please go through the rows again, looking for paths that have the suffix .html and remove that suffix.

As insane as it sounds, I still have to ask: are you looking at the correct database? In CubeCart_seo_urls, what is the value in the 'item_id' column for "switching-dc-power-supply"? What is the value in the 'redirect' column?

The redirect feature was implemented to solve the case where "foobar" was changed to "barfoo", or some other different spelling, or even a now unneeded .html or now needed .html suffix -- where the older URL has been released out into the Internet. Redirects cannot be created while using the same, complete spelling of an existing 'path'.

What is the value of 'item_id' for "switching-dc-power-supply"? What is the value in 'redirect'?

Unfortunately, no. (Personally, I liked the ability to switch off seo-friendly URLs.) In CubeCart_seo_urls, find the row with type 'cat' and path 'switching-dc-power-supply'. Does it exist?

The database table CubeCart_seo_urls will have 'path' values that end without .html. There may be a few 'path' values that do end in .html but these records must also have 'redirect' values of "301", and must have the same 'item_id' of a matching record of the same 'type', without .html. So, look in CubeCart_seo_urls for any paths that end in .html and report back.

Have CubeCart clear its internal cache. That will force CubeCart to rebuild and cache a fresh rendering of the "Shop by Category" listing (aka Top Nav Bar in Foundation), with the correct links (with or without .html as set in Store Settings). Has the issue with some links working and some links not working been figured out?

The .htaccess file should have nothing more than this: # Session data may be written here if the default # server config has a problem. They need protection. # Relates to Session->_start() # Code snippets are also stored here and must be protected. <FilesMatch "^(sess_|snippet_|es.json)"> deny from all </FilesMatch> If that is all that is in .htaccess, then leave it as it is.

I would question the GA rows as I am sure any GA plugin would NOT use code snippets. If the rows in the database table do not have a description (or a description that makes sense) or author, delete it.

As above, delete the rows in CubeCart_code_snippet. Delete all files (except index.php and .htaccess) from that folder. Do not access your site until you have done both.

Ok, the index.php file is fine. Look in the database, at the table CubeCart_code_snippet. Delete all records found in that table.

You have a serious problem. That stuff, when decoded, looks like code that wants to act as a server for malware. I can't be sure. It will be somewhat difficult to determine where this code lives. Firstly, look at the folder /includes/extra/. If there is any file in there other than .htaccess and index.php, delete it and post back with what you found.

Look at the database table CubeCart_history. It will have rows that indicate when CubeCart was upgraded to a specific version. Try deleting any row that has a version 6.x.x in it -- assuming you upgraded from CubeCart 5.something.something (5.2 is not specific enough).

When you go through the downgrade/upgrade process, you might be missing the .htaccess file -- which, as discovered earlier, will cause problems with how the hosting environment works if missing.

CubeCart checks for what storefront skin to use in this sequence: 1. Session 2. Config 3. First Found 4. Foundation So, if a visitor (including each admin) uses the Skin Selector made available to visitors on the storefront, that choice is stored in the visitor's 'session'. If there is no skin having been selected in the visitor's session, CubeCart uses the Default Skin as specified in Store Settings, Layout tab. If that skin somehow does not exist (which would be strange, but has happened), CubeCart will use the first found of all other installed skins - as long as it is not Vanilla. Finally, as of more recent versions of CubeCart, the last resort is Foundation. Therefore, if all you get is Kurouto, even after changing the default skin in admin config settings, you will need to log out of admin (thus killing that 'session'). Then you should see the skin as set in admin settings. If I used this URL: https://mastechpowersupply.com/linear-dc-power-supply Note: No .html I get the 404 response back directly from the web sever - not CubeCart. This tells me that the .htaccess file does not have the proper mod_rewrite directives, or that the web server is not configured to allow .htaccess directives to be executed (needs hosting company support).

Many "Warnings" have been found in CubeCart - even in CC651 - because PHP 8 has decided that what once 'Notices' are now 'Warnings'. Nothing bad is going to happen. These messages are being found and fixed in CC652 (not yet published). The "page=all" should put an entry in admin, Error Logs, System Error Log table. I don't recall seeing this happen with CC651, but there is a fix for this that was implemented in CC6410. That edit requires that the info provided in the skin's config.xml file have the following: <layout> <products> <perpage amount="6" /> <perpage default="true" amount="12" /> <perpage amount="24" /> <perpage amount="48" /> <perpage amount="96" /> </products> </layout> Early versions of Kurouto do not have these statements. Add them just above the <styles> statement. (Or update Kurouto to v1.0.4) Then, have CubeCart clear its internal cache (lit button at the upper-right corner of admin screens).

CubeCart does not use these specific statements, but the hosting environment does. Other statements related to mod_rewrite is what CubeCart requires.