kealan

Brian you are a gentleman and a scholar, I will update this post once i hear back In the interim I have moved back to APC caching which appears to be working fine.

Hello Cubecart Forums, I seem to be having an issue and I am not entirely sure where to start, our store is pumping out the below approx every 1-2 seconds in the error log. The store seems to be working fine at the moment but any attempts to use in inbuilt error log viewer results in general unpleasantness. I downloaded the log to view it but cant find an editor happy with the entire 1Gb file but I managed to scrape out the below. Any thoughts? [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/pear/smarty_internal_data.class.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 89 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/pear/Smarty_Internal_Data.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 92 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/php/smarty_internal_data.class.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 89 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/php/Smarty_Internal_Data.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 92 [01-Sep-2015 18:21:39 UTC] PHP Warning: Cache data not written (Memcachednightma). in /home/m564933/public_html/classes/cache/memcached.class.php on line 221 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/pear/zopim.class.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 89 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/pear/zopim.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 92 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/php/zopim.class.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 89 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/php/zopim.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 92 [01-Sep-2015 18:21:39 UTC] PHP Warning: Cache data not written (Memcachednightma). in /home/m564933/public_html/classes/cache/memcached.class.php on line 221 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/pear/smarty_undefined_variable.class.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 89 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/pear/Smarty_Undefined_Variable.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 92 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/php/smarty_undefined_variable.class.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 89 [01-Sep-2015 18:21:39 UTC] PHP Warning: file_exists() [<a href='http://docs.php.net/manual/en/function.file-exists.php'>function.file-exists.php</a>]: open_basedir restriction in effect. File(/opt/alt/php54/usr/share/php/Smarty_Undefined_Variable.php) is not within the allowed path(s): (/home/m564933:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/tmp) in /home/m564933/public_html/classes/autoloader.class.php on line 92 [01-Sep-2015 18:21:39 UTC] PHP Warning: Cache data not written (Memcachednightma). in /home/m564933/public_html/classes/cache/memcached.class.php on line 221 [01-Sep-2015 19:21:39 Europe/London] PHP Warning: Cache data not written (Memcachednightma). in /home/m564933/public_html/classes/cache/memcached.class.php on line 221 [01-Sep-2015 19:21:39 Europe/London] PHP Warning: Cache data not written (Memcachednightma). in /home/m564933/public_html/classes/cache/memcached.class.php on line 221 [01-Sep-2015 19:21:39 Europe/London] PHP Warning: Cache data not written (Memcachednightma). in /home/m564933/public_html/classes/cache/memcached.class.php on line 221

Which Chat tool are you trying to use? Is it Zopim

Hi all, Just said I would drop a quick update to inform of the progress I have made here with overall site speeds. After much head scratching and testing trying to eliminate the lag with first byte time I just bit the bullet and loaded the site into cloudflare. So far the results have been pretty amazing load times down to 3 second mark which is where I believed it should have been. https://gtmetrix.com/reports/mcsoutdoorstore.ie/bujB8wkU The only issues we have encountered so far is that cloudflare is having issues serving content that itself is served via a CDN. So plugins like the facebook like and comment section which is CDN served had to go, they were working but were causing the page to 'melt' for the lack of a better word until 100% loaded. When users scrolled down they areas where this content was due to be loaded the page started scrolling indefinitely leaving streaking white boxes and then snapping back on fully loaded. We also had to set the cloudflare caching to non-aggressive as it was causing the basket and cookie policy reminder to reset when the homepage was called. But overall a huge performance and SEO boost for 0 cost, no need to move to a VPS for the moment, I hope this helps others out there. K

Hello Fabriceunko, Is there any effect on usability? I have hit errors like this a few times over the years usually they dont have any noticeable effect on how everything is running. Not all tables seem to have a primary key assigned / core upgrades appear to have modified the primary key assignment in some cases which seems to cause problems. As this is relating only to your sessions data which is generally not that important, one solution may be to backup your database then clear the data in the sessions table. K

Hi All, Here is the results from a simple info.php file on the same server - No issues with First Byte time http://tools.pingdom.com/fpt/#!/b4tTpo/https://mcsoutdoorstore.ie/info.php http://www.webpagetest.org/result/150928_W9_K10/1/details/ the info file contained redirects so I have also run the tests on a blank html file on the same server http://www.webpagetest.org/result/150928_54_KAR/ http://tools.pingdom.com/fpt/#!/bk5ga/https://mcsoutdoorstore.ie/test.html All tests are coming back in the sub second region My overall homepage loading speed is from 5-7 seconds as per web page test http://www.webpagetest.org/result/150928_AB_KTR/1/details/ But is below 2 seconds via pingdom but this seems very unrealistic / gtmetrix is down at the moment http://tools.pingdom.com/fpt/#!/bDgPTD/https://mcsoutdoorstore.ie But a visit to the site will clearly show its not loading anywhere near that, its still 5-7. With reference to the number of GET requests / Blocking there also may be another factor in play, though this could be waffle as I am on the edge of my experience here! as part of the initial optimisation of the site we deferred the loading of any specific render blocking scripts until after the initial resources are loaded. We are going to try and asynchronously load some of this content and see if we can reduce the overall times, although this will actually usually score us lower on google page speed test. Though this may be pointless if we are maxing out the tcp connections themselves.

Thanks all for your replies. I will try and address all points. Resolved? My load times have stabilised but are still concerns over the first byte time of nearly a second. http://www.webpagetest.org/result/150926_FY_V6J/1/details/ DNS . I considered this but there are a number of other websites with and without a CMS on the same hosting server /dns server that score fine on first byte time, though none on ssl. Memcache . I would suspect this is serverside as my hosting provider was able to resolve some but not all of the issues, APC will have to suffice here. I have signed up and enabled cloudflare over the last week via the cpanel so I have only made minor adjustments to the caching config on cloudflare itself, only 1 cached item served so far despite having nearly 2000 hits over that same period. Not sure if that's a discussion unto itself.

After troubleshooting with my hosting provider for most of the day we managed to resolve some of the 'open_basedir restriction in effect' errors which was server side but could not resolve the bulk of the debug errors. After doing some research I found that cubecart will be happy running apc, so i disabled memcached and enabled apc at the server level, Cubecart auto-detected the changes which was nice! my page load times are now sub 4 second. I am still not happy with the the fact that the initial call of the homepage is still taking around one full second but as Brian pointed out the smarty system needs a bit of time to come to life.

Many thanks for the replies I appreciate my initial question was somewhat vague! After enabling the debugging and reviewing the export I definitely seem to be having some unexpected issues, and annoyingly the issue appears to be around caching so my hosting provider was correct. It appears although memcached* is enabled on the server I still seem to be having some problems actually writing some of the cache data back to the host, which appears to be creating a lot of hangups which I can only assume is causing some issues with load times. I will raise this back to my provider but I have also included the output below, it appears that mysql data is being cached but nothing utilising memcache. Would appreciate any steer here if there is anything else my side that might be addressable or if I am missing anything else here. debuglog.txt

Hello CC Forum, I am having an issue with our sites loading speeds and I am at a loss as to what is causing it. The page loading speed for the homepage is in and around the 5-10 second mark which is horrid. There are a few areas regards the content / external calls itself we are working on and we are confident we can get it down to 2-3 seconds, however there is one variable we cannot get around at the moment. The initial first byte time on page load can vary from 1 - 4 seconds, so I suggested to my hosting provider its time to move it over to a vps, interestingly the hosting provider advised that a VPS wont cure the problem I am having with the site that its most likely a problem caused by the .htaccess file /caching/old plugins. After some disagreement we both ran tests and regardless of what is in the .htaccess file the issue persists, in a final test to prove my provider wrong i tested a html site on same server and to my dismay the issue did not occur on the html site the whole thing loaded in under a second. We use memcache and minimal plugins, braintree payments plugin is the only 3rd party. Any thoughts on what might cause this initial delay? is anyone else having this issue with cc6? site - mcsoutdoorstore.ie .htaccess file attached + speed test Thanks in advance to anyone who read this far K .htaccess

Thanks Itempo, I will post if I get this thing working just waiting on the braintree support centre to reopen they operate on central US time. Regards K

Hi Itempo, Have you had any luck using this module, we are in the process of switching over to braintree payments and we are hitting a few stumbling blocks along the way also. Regards Kealan

Hi Brian & DB, Thanks for your reply, your food for thought has gotten me somewhere, after inspecting the source code as advised, I got .. <script type="text/javascript"> var file_list = {"1904":"1904"}; var file_default = 1904; </script> I then inspected the image index for the file ID - which was present as expected IDproduct_id file id main_img477122219041 I then inspected the filemanager for the file_id only to realise that the actual 'filepath' for my first 2000 rows is missing .... I am still a little stumped as to how its calling the image in the first place, but I can only assume that the missing filepath is what the image selection box is using for reference. Is this an error or is this its way of calling a 'root' directory ?

Hi DB, Oh yea that works perfectly, I just have approx 500 legacy products with this issue! So if there was a way I could open up a pack of magic beans and sort the issue that would be preferable Many thanks

This issue has now been closed off as it is not explicitly a V6 issue and is perhaps a legacy issue due to a previous technical fault. Both myself and the OP are long running CC users having updated from much older versions so to be fair god knows then this bug actually appeared. Is there any other insights that can be offered here which may help me and the OP identify why a product image would not appear for selection / deselection in the admin panel for products. As far as I can ascertain my image index appears to be fine, its as if Cubecart is not loading the full list of selectable images... no errors etc. in the back end. Has the structure of format of the image index changed since v2/3 as this appears only to affect older products and images.

Hi Ian, I have altered how webmaster tools is interacting with the 'page' parameter so this is now discounted and only the primary page is indexed. I am not 100% that this is exactly the behaviour I am looking for as this will now discount page=2/3/4 etc , which do have valid functions in foundation skin, but its definitely a step in the right direction as its was only the page=all that were being indexed and causing problem. Given the observed impact to SEO I will update again in the next few weeks and advise if I have seen a recovery as this issue is probably widespread, again the only reason I picked it up is we moved domain name and was able to gauge the effect of the crawled pages being added on top of the initially indexed pages.

Hi Brian, I can agree that the "More" is not an ideal exclusive method of handling pagination, page=all makes sense and is workable if the parameter actually had the function of displaying all items hidden by 'More.." as it stands its entirely redundant in foundation. We have customers get lost when the item they clicked for via a search engine, is one or more "More.." clicks down the page. So they think its not there, our chat tool is getting a good work out and so is our search box. On the other hand its a very slick implementation and I think for the casual shopper its an enjoyable function especially on mobile. At heart I don't want it to go but it is causing issue in its current form and needs to be addressed, as we moved URL recently I have been studying our SERP like a hawk. When we first moved and Google had largely only the indexed pages to work off our search engine positions were amazing, never better. As time went on the page=all urls started sneaking in, and on each and every search query they appeared, positions plunged due to the canonical failing to identify it as the same page ad the non page=all url.

Raised https://github.com/cubecart/v6/issues/727 but will still take any advice in the interim / if this gets fixed in next release I could still be waiting a while and this is hurting me now.

Hello Ian, Thanks a million for your quick reply. In response; 1.) Great idea I will raise this in git asap 2.) I do no use the inbuilt sitemap generator, I generate them externally and manually adjust if needed. No urls with pagination etc. have ever been submitted for this site its the crawlers that are picking them up over time. Only realised this issue after we moved the site to a new url, which started off amazingly but over time we seem to be cannibalising our own seo with duplicate results which is starting to hurt our positions. 3.) From reading a long conversation posted here about a year ago with you Brian and DB, I decided the url parameters might not be ideal - I don't know what I'm doing here enough to go down this route unless there's any advice that can be dispensed at this point. Kealan

Hello All, I am having a bit of an issue with the SEO for our site. All categories have a ?page=all variant which in the foundation skin does not go anywhere or do anything. Therefore I have pages competing against themselves for position as the rel canonicals are not working in these cases and it is identified as a separate page. How I mean not working here is for example .... www.examplestore.com/prodcuts/product.html?page=all .... should rel canonical to www.examplestore.com/prodcuts/product.html but instead includes the pagination of ?page=all identifying it as a separate and unique page. I know this issue was discussed previously last year, however it was not in the context of the foundation skin where the pagination actually has no function and serves no purpose. I have tried to 301 the urls with ?page=all but have not had any success so far Any steer here would be very much appreciated. Kealan

Hi DB, Thats raised https://github.com/cubecart/v6/issues/695 . Not sure its a v6 issue as such but I am sure someone will point me in the right direction.

As Ian has pointed out there seems to be some steps out of order which seems odd, but if your checkout process and adwords functionality are both misbehaving ensure that your adwords conversion tag is following the structure from https://support.google.com/adwords/answer/1722021?hl=en and that the script is correctly closed off, you can use the chrome extension to check the live implementation https://chrome.google.com/webstore/detail/tag-assistant-by-google/kejbdjndbnbjgmefkgdddjlbokphdefk . If in any further doubt the conversion tag code should be visible in adwords under tools -> conversions.

I think I discussed this directly with Al during the v6 beta testing, but not sure if it was raised as a ticket in Git as it occurred from the v4 - 5 upgrade so was a bit of a misnomer at the time, if I recall actually it was raised but deleted as not a v6 issue. Here is the scenario product with 3 images gets upgraded from v4 to v5, you then go into the admin -> product and look at the assigned images. Looking at the list you may see one image starred as primary ( sometimes not ) and no others selected a secondary with ticks. Therefore the only option is to further add images and not remove the existing ones. I have looked at the image index DB and it appears to be fine ( I am far from an expert though ), didn't corrupt during upgrade etc. and still shows the images on the front end for customers just not the back end.

I still have about 600 unwell products, hoped it would be resolved in v6 but no joy. I am keen to find a solution to this also

I suffer from a similar issue, and have done for over two years now. It appears the image index had some issues when going from 4 - 5 , or at least that's when I became aware of the issue sometime after the upgrade to 5. My only work around to date is to re-list the affected products, occasionally if I reupload the image it will resync but often I just get an extra image. Sorry I cant offer more support here, perhaps someone else can shed more light on the 'why' here K