Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by bsmither

  1. I am out of ideas on what to suggest to get the problem to reveal why it is happening. As another experiment: In element.js_head.php, there is the last part of the last line that says: debug =false. Make that debug=true. Doing this should tell Smarty to not combine all the listed JS files, but rather output them as separate <link> statements. When I said: "In admin, Error Log, System Error Log tab, see if there are any log entries that pertain to JS or CSS files." I did not mean to examine the debug section at the bottom of the page. I meant to look at the System Error Log in admin.
  2. So you are saying that it is the un-altered CC643 catalogue class that causes the problem? Switching to using the customized version of that file then has CubeCart work as expected?
  3. A thought came to mind, which I will have to create a specific scenario to confirm. But as an experiment, in the file element.js_head.php, make a small and insignificant edit - like inserting a space at the beginning of a line. This tells the text editor that the file needs saving. Save the file. This will give that file a different date/time stamp which the Smarty {combine} function will notice and rebuild the file. Hopefully then, Smarty will properly deliver the result to the main.php template.
  4. Ok, getting it narrowed down. We assume that the file element.js_head.php is getting included, processed (because we see that the file exists in the cache), but the name of that file is not replacing the {include} statement. Yet, js_foot is. By the way, this all works on my copy of Noodleman's skin. It's hard to tell, but can you be certain you are using the latest version of his skin? Not that I would know if there is a difference. In admin, Error Log, System Error Log tab, see if there are any log entries that pertain to JS or CSS files.
  5. The statement is present? {include file='templates/element.js_head.php'} Does the template element.js_head.php actually exist? This file exists: https://www.kurraglenindustries.com.au/shop/cache/c40ca.js_foot.noodleman_v6_20200802191832.js So why doesn't the matching c40ca.js_head.noodleman_v6_zzz.js exist? (where zzz is the date/time the element.js_head.php file was last edited when created)? Look in the /cache/ folder for a file that starts with "c40ca.js_head.noodleman_v6".
  6. I just came across an unverified comment that suggests the PHP.INI file setting (can be overridden in .htaccess or by a command in the PHP script) for 'memory_limit' not be expressed as '2G' but rather '2048M'. This was referencing a PHP 7.4 quirk. Did your host recently upgrade your environment to PHP 7.4?
  7. As for the screen grab, you may be using a text editor (Mac?) that is getting confused over the DOS line endings. A DOS line ending is both a CR and a LF. OSX and Linux uses just a LF. But your editor is also effecting the CR - resulting in double line-spacing. PHP Info says 2G is the 'memory_limit". (That's way more than enough, but whatever.) So why is PHP complaining of:? PHP Fatal error: Allowed memory size of 11534336 bytes exhausted Let me look around, see what I can find. (You might also want to query your host provider about what memory they see for your environment.)
  8. The jQuery library is not loading. Please examine the template file main.php. There should be these statements: {include file='templates/element.css.php'} {include file='templates/content.recaptcha.head.php'} {include file='templates/element.google_analytics.php'} {include file='templates/element.js_head.php'} </head> <body> It is the element.js-head.php template file that is not getting built. I notice that there are additional statements: <script type="text/javascript" src="//platform-api.sharethis.com/js/sharethis.js#property=5c061b5841333f001182d6f1&amp;product=inline-share-buttons" async="async"></script> <script type="text/javascript" src="//widget.trustpilot.com/bootstrap/v5/tp.widget.bootstrap.min.js" async=""></script> Please double check that the additional statements did not damage any of the {include} tags.
  9. Is there a web site where we can see this?
  10. Welcome ledsales! Glad to see you made it to the forum. The GD class provides functions that allow CubeCart to create derivations from source images. Depending on the version of CubeCart, line 113 in the GD class should be: $this->_gdImageSource = imagecreatefromjpeg($file); PHP was given 11534336 bytes to run in (11 MiB) - which seems to be a mistake on the part of your hosting provider. (In admin, PHP Info, scroll to the core table and view 'memory_limit'. If it is not 256M, complain to your hosting provider.) When this "memory exhausted" error occurs (on a typical 256M system), that means the admin has managed to put an image file much greater than 350K in filesize onto the system. The GD library needs to uncompress that image file and that is when large filesizes expand out to consume lots and lots of memory.
  11. I see this as the problem we are trying to solve would say that the stock level displayed was at 2 and stayed at 2 even though the value reported by these log entries suggest the value did change. This points the finger directly at a rendered template page is getting cached. Or the hosting provider has implemented some sort of web server page caching. (I ran into that with Hiawatha Web Server.) But that is highly improbable. With CC643, you are able to change the skin for yourself. For you, choose to use the standard Foundation and make the same tests. On the Demo site, I changed the stock level from 153 to 150, did not clear the cache, and yet the View Product page did have the changed stock level.
  12. So from line 229, you viewed the SCO-2000 page at 19:25, then adjusted the stock level, then viewed the SCO-2000 page at 19:27. I assume you increased the stock level from 2 to 3? If so, all this looks good. (Actually, the SQL query that inserts the entry into the CubeCart_system_error_log database table, the timestamp of 1626478097 suggests the time this happened was at 2:2:37GMT -- though adjusting for timezone differences keeps the minutes and seconds the same, but minutes are different by about 25 minutes. I can't explain that.) However, the problem we are trying to solve would say that the stock level displayed was at 2 and stayed at 2 even though the value reported by these log entries suggest the value did change.
  13. In Cpanel, you say you see an error log? What are the last few log entries?
  14. "No errors in the admin error logs." There has to be. Do you have CubeCart's debugging enabled?
  15. Take a note of the stock level from admin, Products, "SCO-2000". On the storefront, view that product. Take note of the stock level shown there. Do the stock levels agree? If so, change the stock level in admin. Do NOT clear the cache. On the storefront, go back to the homepage, then re-visit that product's page. Did the stock level change? If the stock levels did not agree, or the stock level displayed did not change after changing it in admin, then look in admin, Error Log, System Error Log for the report of what the stock level should be shown as.
  16. Please make this small edit: In /classes/catalogue.class.php, near line 461, frind: $product['stock_level'] = ($GLOBALS['config']->get('config', 'stock_level')=='1') ? $product['stock_level'] : false; $product['unsuppressed_stock_level'] = $product['stock_level']; $GLOBALS['smarty']->assign('PRODUCT', $product); Change to: $product['stock_level'] = ($GLOBALS['config']->get('config', 'stock_level')=='1') ? $product['stock_level'] : false; $product['unsuppressed_stock_level'] = $product['stock_level']; trigger_error('Logging the product stock level for '.$product['product_code'].' as '.$product['stock_level'], E_USER_NOTICE); $GLOBALS['smarty']->assign('PRODUCT', $product); By adding this trigger_error() statement, we can get an independent indication of the stock level before the stock level value being passed to the template. You will see the notice in admin, Error Log, System Error Log tab.
  17. Ok, then we must assume that there is some code, somewhere, that has cached a previous query and is using the result from the cache. Here is a desperate test: in admin, Store Settings, Advanced tab, "Enable Caching", set to Disabled and Save. This is supposed to completely shut off the cache no matter how badly something in the code wants to use it. Perform the same set of steps as detailed above.
  18. I do not see anything in the template code posted above that would interfere with the established value held in the template variable {$PRODUCT.stock_level}.
  19. (On CC644) I recorded a diagnostic tracer on the View Product page, and noted the stock level shown. Then I manually changed the stock level directly in the database. I recorded another tracer, and noted that the stock level had changed to the new level. Do you have any plugins or code snippets that might affect the stock levels of products?
  20. It is not the View Product template code we need to see. We need to verify the core code, the catalogue class, function getProductStock(). See above. I will look at the Min/Max Quantity feature to see if it could affect the value determined to be the stock level.
  21. Please look in admin, Error Log, System Error Log tab. Hopefully there will be something listed there if there was a problem.
  22. We would need to check the code that queries the database for the stock levels. That would be in the catalogue class, function getProductStock(). In that function, there is: // Fall back to traditional stock check if there are no results for the combination or it is not used if (is_numeric($product_id) && ($products = $GLOBALS['db']->select('CubeCart_inventory', array('stock_level'), array('product_id' => (int)$product_id), false, 1, false, false)) !== false) { The DB->select() call should have false as the seventh argument. This tells the database code to not use the cache when asking for the stock levels. (Just above that is a call to query for stock levels in the Options Matrix table, but I think this product does not have options.) There is another conversation on the forums where a fresh stock level is coming from the database, yet is not being properly reflected on the displayed page. We have yet to find where the problem lies.
  23. Please verify something: In admin, Store Settings, Extra tab, GDPR section, is the "Cookie Compliance Dialogue" checkbox checked? I am thinking that the only way to get the GA code to appear is for $smarty.cookies.accept_cookies to be true, which means there must be an actual cookie named 'accept_cookies', and the only way to get that cookie is to display the "We use cookies" dialog window and click on the 'Accept' button , and the only way to display that dialog window is to enable this store setting.
  24. I am not seeing any of the GA javascript code in the page. We would like to know the exact version of CubeCart you are using, and if you have kept an older version of Foundation as the primary skin to use. View the contents of main.php to determine if there is this near line 21: {include file='templates/element.google_analytics.php'} Then, determine if there is a template file named element.google_analytics.php, and if so, view the contents of that file. Is the first line this? {if isset($smarty.cookies.accept_cookies) && $smarty.cookies.accept_cookies=='true'} If your site is being hosted, the hosting provider may have given you a control panel to access your account settings. There will be a file viewer in that control panel you can use to view these files.
  25. It seems there is some work being done on this, although it may have been put on the back burner. See: https://github.com/cubecart/v6/issues/2738 Is there a web site we can visit?
  • Create New...