bsmither

Just remove the line. (But be aware that an upgrade will replace the edited file. CubeCart upgrades are 'whole-cloth'.)

Not directly, however, please examine the .htaccess file in CubeCart's main folder. If there exists the following lines: ##### START CubeCart .htaccess ##### ### GZIP Compression ### <ifmodule mod_deflate.c> AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript </ifmodule> then these directives will compress text-type content of all content - not just the product page.. See: https://en.wikipedia.org/wiki/Mod_deflate (Your hosting provider may have already configured the web server to automatically do this.)

The "Make Payment" feature is not yet perfect. It's being worked on. The confusion, if I have this right, is that the customer is still logged in, and/or has stuff in their shopping basket already (saved to the database). If the customer, having logged in, finds themselves with stuff already in their shopping basket, the basket must be emptied, then when the customer clicks Make Payment, the checkout cart contents should show the updated inventory and other particulars.

Image compression? CubeCart takes a source image, typically PNG or JPG, 750x750 pixels for example, then creates sized variants specific to the intended layout area and page. The source is uploaded to /images/source/, and CubeCart's variants are saved in /images/cache/. The specific variants are coded in the skin's config.xml file. Take a look a Foundation's config.xml file in a programmer's text editor. Here, you will find image nodes with the reference attribute indicating where the image is used. The product page uses 'medium' and 'gallery'. The maximum attribute specifies the length of the longest side, maintaining proportionality, but never longer than the original. (That is, if the source is 450x450 pixels, variants could be smaller, but will never be larger than that.) And, of course, the browser can scale the image to fit the layout's placement if the HTML coding allows it. Note also the quality attribute. For many image formats, there is the 'compression ratio', expressed as a 'quality' -- 100 being very lightly compressed, if at all, and 10 looking like crap. I have visited web pages that initially show a super-blurry image (high compression), then eventually, under javascript control, fetches a high-quality (large filesize) image to replace the blurry one. Currently, CubeCart does not do this.

According to: https://developers.google.com/speed/docs/insights/v5/about Google constructs a mobile environment by simulating the performance characteristics of a Motorola G4 (maybe using the data plan and not using Wi-Fi?). The desktop environment is a simulated tower box on ethernet. So, from your observations, are you using the same device to make your comparisons? I used Firefox's "Responsive Design Mode" which does not simulate a "mobile network". Please know that CrUX, PSI, FCP, FID, LCP, etc are above my pay-grade.

I see the Foundation skin. Foundation uses CSS to alter its layout based on the width of the viewport the browser gives to CSS. So essentially, the site will respond with everything to show the page whether it be 'desktop' width (large) or 'mobile' width (small). If, by 'performance', you mean the time elapsed at which the site delivers the page (and its resources) to the browser, its all good for me. If that is not what you mean, please mention what we should be looking for.

Please try this: In the Card_Capture module, gateway.class.php, at line 138, find THIS PART: = implode(' ',unserialize($item['product_options'])); Change THIS PART to: = implode(' ',unserialize($item['product_options']) ?: array()); PHP 8.1 is much more picky about what is required vs. what is given. If $item['product_options'] cannot be unserialized, a false is returned, which cannot be used with implode(). The added code will determine if unserialize() returns false, and if so, will give an empty array to implode(). I have not tested this.

When the function call is made to add a tab, there is a parameter one can use to place it relative to other tabs. The thing is, the standard tabs show up in context, in the order the function is called. For example, in products.index.inc.php: Near lines 666-667: $GLOBALS['main']->addTabControl($lang['common']['general'], 'general'); $GLOBALS['main']->addTabControl($lang['common']['description'], 'description'); These two tabs will show only when adding/editing a product, and in this order. Thus we can assume the array element order index (the 'key' to an array) will be 0 to start and gets assigned to 'general'. Next, the index will be 1 and gets assigned to 'description'. The function call has these parameters: $name, $target = '', // the ID of the <div> with the content $url = null, $accesskey = null, $notify_count = false, $a_target = '_self', $priority = null, $onclick = '' So, $GLOBALS['main']->addTabControl("Venue Info", 'venue', null,null,false,'_self',1,''); The function will check if there is a tab already at priority=1, and if there is, add 0.01 to the priority passed in. Thus, when the array of tabs are ready for the template, a sorted array will put 'venue' (=1.01) after 'description' (=1). Not specifying a priority has the effect of placing the tab 'in sequence', that is, after those tabs already added via the function call sans priority, but before any other tabs added via the function call sans priority. So, the sequence depends on when the hook got played. Unless, as explained above, a priority value (greater than zero) is passed in.

To have the module show us certain details about the rate request, please enable CubeCart's internal Debug Mode (admin, Store Settings, Advanced tab, enable debug mode and enter your local IP address in the next field (www.showmyip.com). Then, make this small edit: In the FedEx module, shipping.class.php, near line 229-230, find: $response = $this->_client->getRates($request); //findReasons($this->_client); Change to: $response = $this->_client->getRates($request); findReasons($this->_client); When the FedEx module makes a rate request, the actual request and response will be shown in the debug popup window, near the bottom. (You might need to allow your browser to show popups. If so, you may need to close that popup and have the browser reload the checkout page.)

The FedEx module works. "the US set as the only country" If by that you mean the US was entered in the module's "Allowed Zones" tab, then please know that the module will not even be used if CubeCart determines the order's billing (or delivery) address is not one of the countries listed on this tab. So, for you to say that "it" gave a message (about an International order, but regardless), then the order's address must be have been in the US. But just for an experiment, remove the countries from the "Allowed Zones" tab. Have CubeCart clear its internal cache.

It's a bug. In /classes/catalogue.class.php: Near lines 1847, 1850, 2009, 2044, and 2105 The statement (in part) makes a call to: ... searchCatalogue($original_search_data, 1, ... Replace the 1 with $page

Unfortunately, no. That is because we are using a file named cubecart.default.css -- the 'default' part of the name is important. CubeCart skins provide for sub-themes: typically based on a color palette. But they can also be based on whatever else is needed. Please examine Foundation's config.xml file. Each <style> node describes a sub-theme, with 'default' being the only sub-theme present. (There is also the 'red' sub-theme provided as an example. Thus, there would also be a cubecart.red.css file in the /css/ folder.) When CubeCart gets upgraded, all stock files are overwritten. That would include the skin's config.xml file (should you have added a sub-theme), but not the new cubecart.red.css file, nor any sub-theme specific images. But by using CubeCart's 'hooks' system, we can take a particular approach to solve persistent sub-themes.

Of these posted above, it seems your search page is getting hit with attempts at breaking into the database. (This happens to everyone.) CubeCart is constructing a search query, but the database says the query has errors in it. Please make a test purchase - you can stop at actually entering your CC number - to determine if there is an actual problem.

Currently, the Foundation CSS rules restrict the max-width of a "row" to be 62.5em -- that is, a bit more than the width of the capital letter 'M' for 62 times of the base font being displayed. In the Foundation file /css/cubecart.default.css, add this new line: .row {max-width:none;} Have CubeCart clear its internal cache. CubeCart's layout arrangements include a particular layout for 'small', 'medium', and 'large'. Foundation provides for 'x-large' and 'xx-large', but CubeCart does not use them. Thus, as the screen width gets wider, all the objects get proportionally wider as well.

Unfortunately, the image is too blurry to read. Please copy/paste the text into a post.

Please know that 99.99% of these errors are caused by a combination of a particular school of programming style and PHP8.1 -- and are harmless. Everything that mentions "Undefined variable", "Undefined array key", and a few others can be ignored. You might hit one or two situations that would cause some apparent weirdness, but nothing catastrophic.

In admin, near the bottom of the left-pane navigation, click 'Redirects'. Here, you will be able to add obsolete URLs to point to the new URL. CubeCart will tell the browser there is a 301 Redirect. For example, "wormhole-generator.html" redirects to "wormhole-generator" (knowing that, now, CubeCart manages the inclusion of ".html" internally). Hopefully, you have a list (from a database backup?) from the table CubeCart_seo_urls of the obsolete URLs.

I am having trouble getting to: https://www.volteq.com/files/public/manuals/index.php

Asking the web server to show the contents of a folder as a list requires the web server to populate a "directory list" template. A default template is part of the web server internals, and some web servers have an external module available that adds just a bit more layout and styling. Please review the hits from this internet search: https://duckduckgo.com/?q=web+server+index+listing+styling&ia=web CubeCart has no role in gathering, formatting, styling, and displaying contents of a folder to a customer. (In admin, of course, you need a list of images, digital downloads, backup files, etc, but what is shown to the admin is not a direct listing.)

The CubeCart programmers decided that 38 characters would be the limit (40, if you counted the '...' added at the end) for the product name when being displayed in a "panel". A panel is what you get in a "grid view" of three by however many rows is needed. (This is opposed to the "list view" of wide blocks in a single column, where there is plenty of room for a long title.) In the template content.category.php, near line 143, begins a <div> block having the class "product_grid_view". A few lines later is an <h3> heading tag holding the $product.name , but with a modifier to truncate the phrase to 38 characters, plus the ellipsis. You can customize the skin template by changing that value, but realize that a customized template will get overwritten on the next upgrade. Also realize that the "panel" is only so wide. But it will get to be as tall as needed.

For download? That is, download - not viewing within a web page - but perhaps still using a web browser? If actually fetching an image by a web browser, it will be the browser's responsibility to scale the image to fit the screen. Same for a plain text file - which has no styling. If the files are PDF's, then that text has already been styled and laid out, where the browser, with its internal PDF viewer, has only the option to zoom in/out but likely cannot reflow the text to fit the screen. So, what is the nature of the files?

You would make a timestamp value using PHP's time() function. You would use the timestamp value as an argument in PHP's date() function to display a human-readable result. And, yes, the 'live-from' column is a product's date that, until up to that time, the product is not revealed to the customer.

Good to hear!

The very first line of the .htaccess file posted above should be deleted. That rewrite directive at the top of the listing may be causing the web server to not process any of the directives in the file.

"when I go to the website and [hover the mouse over] the links, they all show up without the .html" That's how it's supposed to work. But you say none of them work. In what way do they not work? That fact that you have to add the .html extension to the web address in the browser in order for the web server to pass the rewritten URL to Cubecart suggests that the rewrite directive in the .htaccess file is not correct. The directive I posted above must be exactly as it is in the .htaccess file, and there must be no other directive in that .htaccess file mentioning 'seo_path'.