• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

Profile Information

  • Gender
  • Location
    Hampshire UK

Contact Methods

  • Skype
  1. Admin showing HTTP not HTTP

    Thanks. I'm getting default to HTTPS fine on the front end. But I will add a redirect line in htaccess to force it across the board I think.
  2. Admin showing HTTP not HTTP

    Thanks so much for clarifying this, it works perfectly now that I know about it. There are sometimes things about Cubecart which could be more thoroughly documented. Or maybe it's my lack of observation - I'd never noticed that the padlock is actually clickable. I thought it was just a status indicator.
  3. Admin showing HTTP not HTTP

    We've installed an SSL cert on a Cubecart site. In the admin interface at Store Settings > SSL we have selected Enable SSL = Yes but the site won't change the displayed protocol in the Store URL box on the same page, if you enter it just reverts to when saved. However then having saved the settings, front end of the site is happily displaying HTTPS, green padlock etc. and if you try to call a front end page using HTTP it redirects to the HTTPS version. On the admin side though pages will running under HTTP without redirecting to HTTPS, which the store owner is not happy with. If I modify the URL of a displayed HTTP admin page in the browser bar to call the HTTPS version, it loads the page, and when you navigate around the admin side from that HTTPS address, the subsequent pages are all HTTPS. Equally if you navigate admin from a nonsecure HTTP page, then all pages remain HTTP. Surely it should be redirecting to HTTPS in every case? Do I simply need to add an HTTP to HTTPS redirect rule in .htaccess or is there something more fundamental going wrong?
  4. Admin pages running slow

    Thanks very much Noodleman, brilliant news to have this tracked down and now fixed. I've tested and the site runs really well now . I had another V4-6 upgrade go really well a couple of months back, so this one was flummoxing me - but looking back, the main difference between the two was this one module. You mentioned deleting old modules way back in this thread, but I hadn't deleted the cache which it had created. Thanks again.
  5. Admin pages running slow

    Thanks. I've just commented out the section you mentioned. It still takes 25+sec to load a product editing page.
  6. Admin pages running slow

    Thanks. I have changed classes/debug.class.php with your code snippet and retested. Files of debug info and system errors are attached for the product editing page. We still seem to be looking at query times which are mostly in the order of 10E-5 apart from a couple around 0.02sec. Doesn't seem to add up to the observed 30 second page load time. The error log relates entirely to this page call; I cleared the log before visiting the page. I look forward to your further thoughts on the logs. Thanks. 171129debugsingleproduct.doc 171129systemerrorlog.doc
  7. Admin pages running slow

    Hi Brian Sorry, that was me truncating the information: Page Load Time: 0.007737 seconds The full set of data is copied into the attached. This particular one is for the login page, which is slowed down presumably by the loading of product info into the admin landing page. If I modify the login URL in the address bar so that it lands on for example docs, login takes about 2 sec instead of 120sec + login log.doc
  8. Admin pages running slow

    Thanks, yes most of the query times in the list were of the order 10E-5. I've attached the text of the full debug report on another page which is running slow. product listing.doc
  9. Admin pages running slow

    To recap, the front end of the site is perfect, and admin side is perfect except for product edting pages or category editing pages. These run at 25 - 100 sec load time. Everything else admin side is <2 sec, front end is <1 sec pageload. So I've worked through the admin panel generated list of database errors and corrected all of them, about a dozen, mostly duplicate or missing keys or wrong type of key, and now have no DB errors showing in admin list (yes Noodleman I note your comment that this admin generated list is not always definitive). Presumably to look at slow running SQL queries I can examine the debug log on affected pages. So below is an extract showing some of what I think are relevant lines. Note there are no PHP errors reported in this log. I've put the suspect queries in bold, everything else shows query time around 0.000X sec, these two (items [22] and [23]) show no times at all, presumably they exceeded some limit. They refer to Product Options Matrix, however we have no product options in use on this site, and none show up in the product options listing: [20] SELECT SQL_CALC_FOUND_ROWS `cart_order_id`, `name`, `first_name`, `last_name`, `order_date`, `customer_id`, `total`, `status` FROM `CubeCart_order_summary` WHERE status IN (1,2) OR `dashboard` = 1 ORDER BY `dashboard` DESC, `order_date` ASC LIMIT 25 OFFSET 0; -- (0.0017428398132324 sec) [NOT CACHED] [21] SELECT SQL_CALC_FOUND_ROWS * FROM `CubeCart_reviews` WHERE CubeCart_reviews.approved = '0' LIMIT 25 OFFSET 0; -- (0.00012493133544922 sec) [NOT CACHED] [22] SELECT, I.product_code, I.stock_level AS I_stock_level, I.stock_warning AS I_stock_warning, I.product_id, M.stock_level AS M_stock_level, M.use_stock as M_use_stock, M.cached_name FROM `CubeCart_inventory` AS `I` LEFT JOIN `CubeCart_option_matrix` AS `M` on `I`.`product_id` = `M`.`product_id` WHERE use_stock_level = 1 AND (((I.stock_warning > 0 AND M.stock_level [NOT CACHED] [23] SELECT SQL_CALC_FOUND_ROWS, I.product_code, I.stock_level AS I_stock_level, I.stock_warning AS I_stock_warning, I.product_id, M.stock_level AS M_stock_level, M.use_stock as M_use_stock, M.cached_name FROM `CubeCart_inventory` AS `I` LEFT JOIN `CubeCart_option_matrix` AS `M` on `I`.`product_id` = `M`.`product_id` WHERE use_stock_level = 1 AND (((I.stock_warning > 0 AND M.stock_level [NOT CACHED] [24] SELECT FOUND_ROWS() as Count; -- (7.5817108154297E-5 sec) [NOT CACHED] [25] SELECT * FROM `CubeCart_extension_info` WHERE `file_id` IN (-1) ; -- (0.0010781288146973 sec) [NOT CACHED] [26] SELECT COUNT(product_id) AS Count FROM `CubeCart_inventory` ; -- (0.00054216384887695 sec) [NOT CACHED] The System error log in admin shows entries such as: Today, 23:43 [Notice] /home/northerwood/G0DG68Q0/htdocs/ronlines/classes/seo.class.php:323 - Undefined variable: path Today, 23:43 [Notice] /home/northerwood/G0DG68Q0/htdocs/ronlines/classes/seo.class.php:323 - Undefined variable: path Today, 23:43 [Notice] /home/northerwood/G0DG68Q0/htdocs/ronlines/classes/seo.class.php:323 - Undefined variable: path Today, 23:43 [Notice] /home/northerwood/G0DG68Q0/htdocs/ronlines/classes/catalogue.class.php:307 - Undefined index: Today, 23:40 [Notice] /home/northerwood/G0DG68Q0/htdocs/ronlines/classes/catalogue.class.php:307 - Undefined index: Today, 23:39 [Notice] /home/northerwood/G0DG68Q0/htdocs/ronlines/classes/ajax.class.php:46 - Undefined index: function Today, 23:39 [Notice] /home/northerwood/G0DG68Q0/htdocs/ronlines/classes/seo.class.php:323 - Undefined variable: path What is to be concluded from this? Any comments would be gratefully received.
  10. Admin pages running slow

    It's only slow on admin updating products or categories. Editing pages or changing site settings runs fast, And everything on the front end is completely fine too.
  11. Admin pages running slow

    Thanks to all of you for valuable advice. I already disabled caching (Cubecart default was in use) in order to get a true picture of front end load time. I found front end remained very fast, and it made no difference to the back end problems. I will look at legacy extensions, I think there is only one though and that is a front end slideshow which surely would not slow down the backend. Am going to get my hosting support guys to take a look.
  12. We've updated a site from v4 to v6, which all seemed to go through fine and the front end pages are running superfast, like 0.5 sec loadtime, but admin pages are shockingly slow, taking 45sec to 90sec to save changes to products for example. Any thoughts on where we should begin to look for causes of this? I've tried running Yslow but the results have not moved us forward any.