Jump to content

rob_dewing

Member
  • Posts

    15
  • Joined

  • Last visited

Everything posted by rob_dewing

  1. 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. 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. 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 https://www.ronline.com it just reverts to http://www.ronline.com 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. 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. Thanks. I've just commented out the section you mentioned. It still takes 25+sec to load a product editing page.
  6. 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. 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. 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. 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.name, 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.name, 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. 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. 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.
  13. Thanks. Have just implemented and tested it. That is exactly what was needed and will fix the problem very well I think. Thanks for the support.
  14. Thanks. That tweak seems to have successfully switched to making the shipping options fully visible as a set of radio buttons. Really, even with better visibility of the choices now in place, it would still be good to tweak the scripts so that the most expensive option is the default choice, not the free option. That's obviously a deeper mod - is it something I should be posting on the third party developers forum rather than here on this forum?
  15. Jack, did you ever get a successful resolution to this problem? I've got exactly the same issue on a site I am managing. Customers requiring delivery are going through the ordering process with with 'collect from store' selected and not getting charged for delivery. We've only got the two options - free collection or flat rate delivered, so the ideal thing would be to make the most expensive one the default not the cheapest one. Should be a fairly simple tweak in the scripts.
×
×
  • Create New...