bsmither

Deleted the 'config' row in the database, fetched the Store Settings page, but code is still present in the Offline Message editor? Please find the web server's error log (not PHP's error log). If the web server is logging "Denied by Policy Rule" or some such (there might not be any logging at all with respect to this), then I would think the hosting provider has integrated some sort of security module on the web server. There are numerous forum conversations that conclude these protocols interfere with common data being saved when passing through the web server.

Ok, this is interesting. It says this is PHP 7.3. That means CC65+ will have myriad problems. CC6410 should show several odd behaviors, but shouldn't crash when showing the install/setup screen.

Create a file named info.php. The contents of that file are: <?php phpinfo(); ?> Have your browser ask for this file specifically: http://www.olivewoodturning.co.uk/info.php (This file already exists at /setup/info.php.) If you still get a 500 error, the problem is not with CubeCart.

So those errors were generated from CC649. Is there an "error_log" file where CC651 is being installed? Also, those "Illegal String Offset" errors imply that there is being a search made against store inventory where the data passed in to that search function is a plain word, as opposed to an array having a word or words. A bug report has been made.

Would these errors be from an earlier version? Line 1782 is a comment line in catalogue.class.php, version 6.5.1.

PHP 8.1 is a good version to run CC651, so I would have to think the problem lies elsewhere. My search on the Internet for these errors all mention the programming language C++. There could be a separate error log file belonging to PHP. If there might be a separate error log file that PHP will write to, see the following conversation that could help get access to that error reporting: https://forums.cubecart.com/topic/51550-how-to-create-the-error-log/ If that gives no additional info, I encourage you to contact your hosting provider.

I have never seen this before. Please let us know what version of PHP is being used.

This issue was fixed in CubeCart 6.2.7 a few years ago. Please see: https://github.com/cubecart/v6/commit/b54b241d2445d927c24682feb35aa7375e01c1a7

@Al Brookbanks will need to be consulted on that question.

I will be cautious and say probably not 100%. Based on seeing that the PayPal Commerce Plugin v1.0.0 is dated 2020-FEB-03, and CC6114 is dated 2018-MAR-07. The version of CC most closely dated to the plugin is CC629 dated 2020-FEB-27. However, scanning through the /hooks/ files in PayPal Commerce Plugin v1.8.5 (the hook code most likely needs to be more tightly coupled to the core code where the hooks are called), I find that the hooks used go way back to CC5, and looking at the code in those files show nothing that would require any particular version of PHP (there have been changes to make the code operate better under PHP8.1, but no regression problems). There is a reference for v1.2.1 - Adds T&C's before "Make Payment" button. (Requires CubeCart 6.2.9 and higher using default skin)

"is there any way of checking whether other files/programs have been upgraded correctly" Try this: In the main folder, note the date/time of the file ini.inc.php. There is no reason to have edited this file, so its timestamp should not have been altered. IF, when unzipping the CC651 archive zip file, the timestamps stated for the files would carry over to the workstation filesystem, then (apart from time zone offsets) those times should match. Then IF, when FTP'ing the files from your local workstation to the site, the timestamps carry over, then (apart from time zone offsets) those times should match. My copy of the CC651 zip archive file, when examining the contents within, has as the timestamp - presumably when the archive was created - is 2023-03-28::08:08 Created (and 08:05 Modified - however that happens). So, on the server, look at several directory listings and note the files' (not necessarily the folders) date/times. They should be close to 28 Mar 2023.

You might be interested in reading this, regarding that unexpected equals sign: https://forums.cubecart.com/topic/58344-upgrade-6410-to-651-fails-to-whitescreen-of-store-homepage-error-cubecartclassphp2173/

That hash is the list of options, but serialized and base64 encoded, so as to fit better in the database. Those changes were implemented in CC642. So, the question remains, did your installation get completely upgraded to the the latest version? See: https://github.com/cubecart/v6/issues/2705

For your client, they must be running a version of CubeCart older than CC640, along with PHP being too new for CC640. There will be many incompatibilities. Anyway, for this specific Exception, please see: https://github.com/cubecart/v6/issues/2487 https://github.com/cubecart/v6/commit/b366d549e68861b9b70a2fcb0937d8d704f0e2ed and make the edit. The line number of this statement changes from version to version. The error message states the code with the problem is on line 224.

If your site is being hosted, you probably have a control panel. Among all the tools available to you via that control panel, there should be a tool to view "Errors". This might be errors reported by the web server, or it might be errors reported by PHP.

I will need to know more about the "Shop-by-Manufacturer". Is it a plugin? It seems you were having issues with a plugin a year ago: https://forums.cubecart.com/topic/53397-enhanced-manufacturers/

Not sure of what you want. If you are wanting to make the Category Name on a View Category page have an <h1> tag, that would need an edit on the skin template content.category.php. The names of the products - having very little space to display - have an <h3> tag. The <h3> tag on the product name could be changed to an <h1> tag, but with a style attribute that forces the font size to display the same as it was before.

In the file /classes/gui.class.php, near line 945, starts the "_displayCookieDialogue()" function. About 20 lines later starts an if() block of code that determines if the dialog should be displayed. If so, then there is an if() block of code that tests for the presence of a site document flagged as Privacy from the database. If $privacy is found, the variable $dialog will contain the dialog language phrase simply having %s replaced with the store name, and %PRIVACY_URL% replaced with the http url of the document. If not, then it gets just a little more complicated as %s will still get replaced with the store name, but there is a regular expression function, preg_replace(), that will remove the <a privacy_url> and </a> tags. So, we have to assume that $privacy was found in the database. It seems we are still dealing with this from many months ago. See: https://forums.cubecart.com/topic/57522-404-errors/

Please verify: in admin, Documents, in the list of documents, make sure one of the documents has the Privacy radio button checked. If there is, then a replacement should happen - where %PRIVACY_URL% becomes an actual URL. <a href="%PRIVACY_URL%">privacy policy</a> If not, then the <a> and </a> tags are supposed to be deleted, leaving only the friendly text. Comparing what I see at csrocketry: Chris Rocket Supplies, LLC uses cookies. For more detailed information about these cookies please see our <a href="%PRIVACY_URL%">privacy policy.</a> Please accept to continue or block all non-essential cookies. Standard language phrase: %s uses cookies. For more detailed information about these cookies please see our <a href="%PRIVACY_URL%">privacy policy</a>. Please accept to continue or block all non-essential cookies. Note that there is a period as part of the friendly text for the phrase being used, where the stock phrase has the period after the closing </a> tag. I have no idea if the preg_replace() function (to strip the link tags) will malfunction with that period as part of the friendly text.

That looks like the "Accept Cookie Dialogue". But there is core code that is supposed to change %PRIVACY_URL% to the actual link (the Gui->_displayCookieDialogue() function). I see you are using Foundation, and the cookie dialog seems to be displaying correctly.

As of the moment I tested the site, the SSL certificate is not configured correctly. It is valid against: c6s.361.mywebsitetransfer.com The IP addtress loteriagringa resolves to is: 132.148.237.25 If this is not the correct IP address of the server you moved to (which may or may not matter at all), it could be the case that the world needs to wait until the "Internet Phone Book" update propagates across the world. Visiting just the FQDN (no subfolder, no index.html or index.php), I get: Future home of something quite cool. If you're the site owner, log in to launch this site If you are a visitor, check back soon.

When you say "it wasn't exactly what I was looking for," is it because the referenced conversation results in "it automatically reverts back to inches"? In admin, Store Settings, General tab, to change the choices for the length dimension unit, edit the admin source file "settings.index.inc.php": Near line 434, find: $select_options = array( About 25 lines later, find: 'product_size_unit' => array('cm' => 'Centimeters (cm)', 'in' => 'Inches (in)'), Change to: 'product_size_unit' => array('cm' => 'Centimeters (cm)', 'mm' => 'Millimeters (mm)', 'in' => 'Inches (in)'), The conversation referenced above affects the details specified on a per product basis.

If you are using a custom skin, or maybe one originally developed for CC5, several links are hard-coded to have .html suffixes. Please see this conversation: https://forums.cubecart.com/topic/57069-minimaliser-skin/

Please remind us of that other conversation. As best I know, this dimension (as well as weight) is used in shipping calculations where the size of the container affects the charges. However, I cannot locate any significant places in the code where this store setting is used. When adding/editing a product, the dimension unit can be specified for that product.

Using an external database utility, such as phpMyAdmin (a tool provided to you in your hosted account's control panel), view the table CubeCart_system_error_log. Hopefully, the error will have been logged there.