Leaderboard

You will run into a number of minor issues -- all because PHP 7 (7.4 is what I run, so not sure about earlier PHP 7 versions) is more strict about several things. (Another site I manage is running PHP 7.3 with it making no complaints at all. The server environment is commercially hosted by a seriously professional crew, so they wouldn't run PHP 7.3 if it caused issues with CubeCart.) Much of the above mentioned issues will be fixed in CC6.2.10. These issues are minor because they (nearly all of them) only cause PHP 7.4 to complain, but do the job anyway. Go for it!

It should be never; for CSS3. See https://www.w3.org/TR/css-speech-1/#speaking-props-speak and https://www.w3docs.com/learn-css/speak.html But, because no (current) web browser will act on it, it's safe to delete it. Or leave it - no harm done.

The "better font rendering" rules are valid, but only MacIntosh OSX browsers understand it. So, the CSS validator may be accepting rules for only a specific browser, or (more likely) only rules that all browsers must know about.

Regarding this: src : url("fonts/icomoon.eot?#iefix-hwvopr" the #iefix is to fix an issue in Internet Explorer 8 and below with respect to a CSS font-face rule having more than one source location. So, probably best to keep that. but not the -hwvopr.

Here is what I am coming to understand. The font files have a certain name, that's all well and good, and the browser will cache them internally. But what if the font file changes? It has the same name. Thus, a technique is used called 'cache-busting'. Many browsers will know to fetch a fresh copy when it sees a querystring on the URL. The querystring starts with a question mark - and that's all that is (usually) needed. This querystring, starting with the question mark, ?-hwvopr most likely indicates a version code, or a package number from a collection of packages of sets of icons on someone's ICOMoon premium account. As such, delete as mentioned earlier. It is up to you if you want to keep the cache-busting question mark. Regarding the message posted above, was there an indication of what triggered it? If it was a -t then I would expect the trigger to be hit a lot more times - for everything.

As is currently coded, CubeCart must have the images under its own management. However, because CubeCart is 100% human readable and can be changed to do whatever, it is not beyond some effort to make some small changes to the skin templates to make image links point to the CDN - assuming the filenames are using a calculable syntax. That is, "CDN_address/images/product_code.jpg", where product_code is exactly the same as what CubeCart has.

Welcome DeAllen! Glad to see you made it to the forums. Make a backup of your database, first. I suggest this because I haven't yet verified the following procedure works without any issues. In admin, Images, after having FTP'd all the images to the /images/source/ folder (distributing them to sub-folders as needed), click the Update File List tab.

I would recommend not using the admin.tabs hook. This seems to be best used if one needs to modify an existing tab(s) that are ready to be displayed. This could sometimes include adding more or deleting some tabs from an existing admin function (such as adding/editing an item of inventory). If your plugin is creating an entirely new admin feature (not enhancing any other administrative task), and because plugin modules can have their own admin control panels (/skin/admin/index.tpl) with corresponding controller code (/admin/index.inc.php), perhaps using ACP->addTabControl() would work better. But if your plugin is enhancing an existing feature/function, and need to include your relevant tabs (for the corresponding panels of settings), then the admin feature you are modifying may have a specific hook to use (such as editing a product -- admin.product.tabs) where the addTabControl() call would be placed.