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.

If you copy/pasted, via mouse-swipe, the password from some other web page, you may have inadvertently picked up an invisible character (tab, etc). Perhaps, in /includes/global.inc.php, entering the password manually may help - avoids copying over unwanted bytes.

I just reloaded your prior post with new content added. PHP Fatal error: require_once(): Failed opening required '/home/testshop/public_html/includes/lib/smarty/plugins/modifier.replace.php' in /usr/www/users/xxx/cache/skin/013463d28fb18a8fc0c766ac6b3777fc1a45f311_0.string.php on line 18 This suggests that when the move to a new host was made, all the stuff in the /cache/ folder came along with it. That will probably cause problems. Please have CubeCart clear its internal cache (in admin, top-right corner is a button to do so).

Hey, Bingo! addTabControl() is what i was looking for thanks

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.

Great thnx it worked

I believe there is a bad database query that will cause an incredible amount of time for large resultsets. In /classes/seo.class.php, find: private function _getCategoryList($rebuild = false) Five lines down, find: $query = sprintf("SELECT C.cat_id, C.cat_name, C.cat_parent_id, S.path FROM `%1\$sCubeCart_category` as C LEFT JOIN `%1\$sCubeCart_seo_urls` as S ON S.item_id=C.cat_id AND S.type='cat' AND S.custom='1' ORDER BY C.cat_id DESC", $GLOBALS['config']->get('config', 'dbprefix')); Change to: $query = sprintf("SELECT C.cat_id, C.cat_name, C.cat_parent_id, S.path FROM `%1\$sCubeCart_category` as C LEFT JOIN `%1\$sCubeCart_seo_urls` as S ON S.item_id=C.cat_id WHERE S.type='cat' AND S.custom='1' ORDER BY C.cat_id DESC", $GLOBALS['config']->get('config', 'dbprefix'));

Does this happen on every page load, or only waiting for CubeCart to process what was POSTed and to send back a fresh page, and only for certain POSTs? In admin, CubeCart does not use the cache. So, every query communicates with the database. In admin, Store Settings, Advanced tab, enable debug mode and enter your workstation's IP address in the adjacent field (www.showmyip.com). Now, when getting pages, below the content, there will be a grey section listing database queries, and also at the bottom, a "Page Load Time". For each query, there is a value in seconds. Don't be mislead by a number shown like: (9.0837478637695E-5 sec). The E-5 says to put a decimal and 4 zeroes in front of the nine, making this a very small number. Rarely will a query have a decimal and only one zero. The Page Load Time should also be small - less than one second. CC629 could have multiple sections of debug data - one for processing the POST, and a second when the browser is told to fetch the after-POST page. You aren't mentioning the storefront, so we can assume it is functioning normally?

Replied to your email.

I upgraded today didn't make any difference