havenswift-hosting
-
Posts
2,752 -
Joined
-
Last visited
-
Days Won
84
Posts posted by havenswift-hosting
-
-
Does seem to be an issue as we have had reports from two clients today that have been upgraded to 6.2 that this is happening to them as well. I havent looked into the issue at all yet
I opened a github issue to report it : https://github.com/cubecart/v6/issues/2032
-
Yes exactly and mentioned it to ensure that it will be dealt with as part of 6.2.1 - but just checked the 6.2.1 db upgrade script and see you are dropping and recreating the index so all good
-
I have noticed that while the custom_oid column does exist, on every site we have upgraded to 6.2.0 the index doesnt. The only exceptions are the couple that we upgraded to the beta and RC versions first.
-
The latest versions of all CubeCart developed skins have been enhanced to support V2 although they dont support the Invisible method
-
13 hours ago, flash760 said:
Might that have happened during the upgrade?
I think it extremely unlikely that the upgrade set this to enabled. Both @Al Brookbanks and myself have done a LOT of upgrades (including to 6.2.0) and never seen this issue with any version
-
While it is faster to upload the zip file and then extract after it has completed, you then need to add the additional steps of ensuring that (if you already have a renamed /admin_xxxxxx directory and admin_yyyyyy.php file), these need to be renamed as you will have a /admin directory and admin.php file from the zip extract and you will end up with multiple copies of both and mixed versions of files as so many on here have done.
You also of course still need to run the /setup AFTER completing the rename
Ian
-
1
-
-
You cannot just upgrade the files in the Admin directory (which seems to be what you have said you have done).
Try following https://support.cubecart.com/Knowledgebase/Article/View/228/43/how-do-i-upgrade-from-cubecart-v6-to-latest-v6 by uploading all files from the distribution zip file and then running setup
Ian
-
As long as you havent actually restored all or part of the backup, you would be better off trying to fix the problems caused by the upgrade - tell us a bit more about what is happening
-
PHP Notices can pretty much always be ignored and CubeCart generates lots of these.
The issue which corresponds to the time of your order is the fatal MySQL SELECT issue - this is a known bug that has been fixed in 6.2.1 but that hasnt been released yet - see https://github.com/cubecart/v6/issues/2003 so in the meantime, you can manually make the change
Ian
-
12 hours ago, bsmither said:
For now, please make the edit in /includes/global.inc.php, choosing either "file" or "memcached".
Choose "file" as "memcached" is unlikely to be installed on a standard shared hosting platform
-
What you want to do isnt possible as you can only price products (and shipping) in the base currency. If you have one or more additional currencies enabled with the exchange rate set, it is possible to choose to see the equivalent price in one of those additional currencies by switching to that on the front end of the site
Ian
-
4 hours ago, flash760 said:
I followed the instruction to upgrade from 6.1.3 to 6.2.
Which instructions ? These https://support.cubecart.com/Knowledgebase/Article/View/228/43/how-do-i-upgrade-from-cubecart-v6-to-latest-v6 ? If not then you are likely to have had a failed or partial upgrade which could be causing these issues.
Ian
-
That is the original plugin that I was talking about that has multiple problems. It isnt the plugin that is in beta ((it is a VERY old image from when Google Base, now called Google Merchant, was first released) and if you look at the dates when it was released and last updated you can see it has been around for a long time. Try our plugin and you will find it works - we have a lot of people using it
Ian
-
1 hour ago, fettlebox said:
What's causing the installer to do that?
Trying to use the built in upgrade routine in the ACP will most of the time fail and cause this and also doing a manual upgrade incorrectly will also cause this.
-
Well I suppose it depends what plugin you are talking about then ? The original Google Base plugin (it hasnt been called Google Base for at least four years !) written by CubeCart was the one I was talking about and I am not aware of any other plugins that offer this functionality apart from our one that I mentioned. Do you have a different third party plugin ? If so then you probably need to mention which one !
-
Yes to the method of upgrading - it has been covered quite a bit on previous forum threads but also see the FAQ article that Al wrote a while back - https://support.cubecart.com/Knowledgebase/Article/View/228/43/how-do-i-upgrade-from-cubecart-v6-to-latest-v6
As to the email issue, no idea but probably not as not seen that before but cant see how an upgrade would cause email to fail. Check what you have in the Store Settings | Advanced tab
-
16 hours ago, fettlebox said:
Upgrade didn't fail & as usual I was presented with an updated link to the ACP
If you EVER receive a new updated Admin login url after the first time, then it means the upgrade has failed. The Admin directory and admin_xxxxxxx.php file should never be renamed !
-
If you are getting a CSRF error on Admin login it usually means you havent correctly updated BOTH the Admin directory and your admin (renamed) php file
Ian
-
Hi
We discovered multiple problems with the old plugin and so wrote our own enhanced plugin which supports many more features and is updated for changes introduced by Google - see https://www.cubecart.com/extensions/plugins/google-merchant-centre-feed and you will need the Microdata plugin as well as merchant centre now requires valid and matching markup - see https://www.cubecart.com/extensions/plugins/google-schema-org-microdata-plugin (this plugin gives you many other advantages as well and can / should be used by all stores !). We have many clients using this very successfully so give them a go - you have free seven day trials of each
Ian
-
We are seeing a large number of sites (that people have tried to upgrade themselves) where the upgrade has failed - this often leaves several copies of the admin directory where the "new" directory is the upgraded one but isnt being used
-
Wil
The information you are giving is a bit confusing - you say you are doing a re-install, (which you really shouldnt be doing) but your image shows that you have done an upgrade and yet you say you enter the database information which is only done on a new install !
It also shows your new admin php file name which has been changed because you havent done the manual upgrade correctly.
It is difficult to give any better advice without knowing or seeing exactly what you have done as basically, what I have said previously is still valid - ensure that the admin filename and directory name that is shown in your global.inc.php file is the same as what they are actually called
-
Hi Wil
I have just edited your reply as it contained far too much sensitive information !
What you will find is that because the upgrade wasnt completed correctly, the actual names of the admin directory and admin php file will now be different to what is listed in the global.inc.php file - that is the first part of correcting this issue
Ian
-
Will
You dont need to (and shouldnt) re-install - the problem is that your upgrade has partially completed which probably means you have a mix of versions on your site and also the admin directory and admin_XXXXXX.php file has been renamed to something else.
You can look in the includes/global.inc.php file for the new names of the admin directory and file and change so they match but you also need to ensure that the file itself and all files in the admin directory are upgraded to the correct and latest version.
You will probably need to do a manual upgrade and follow the procedure shown on the CubeCart support knowledgebase article
Ian
-
4 hours ago, bsmither said:
I cannot speak to SEO, but the codebase has way too many instances of using index.php, both in pattern matching and URL generation, to be practical in any attempt to suppress them all.
It is a good idea to choose one single url for the homepage and redirect all other possible versions to that - otherwise you have possible duplicate content issues - my preference is https://www.domain.com but you can also choose https://domain.com (if using the www. is good enough for Google, then ....)
It is perfectly possible to setup a 301 redirect to remove the /index.php and it is something we do for our own sites and also on all client sites - for example for https://www.cubecart-demo.co.uk
What is actually used in the .htaccess depends on the configuration of your webserver
Ian
gdpr
in General Discussion
Posted
No debate - that is not informed consent and is against GDPR