Also, a Google search turned up this:
CS-Cart 4.6.1 Changelog
New Features and Improvements
[+] Add-ons: Google Analytics: The actual URLs that led to the 404 page (/index.php?dispatch=_no_page) now appear in Google Analytics reports.
Whatever you want, probably best to do the dispatch=products.quick_view part
see here where i disabled all urls that pointed to the gift cert addon.
Please be careful of what you exclude and be sure its correct.
I submitted a ticket to helpdesk and this was their response:
There is no such well-known bug in CS-Cart. Such pages should not be indexed by search engines and customers are unable to navigate to them so it is unclear why these links appear in your analytics. Please try to replace the .htaccess file with the default one and check if the issue occurs in future.
Where do I get a copy of the default .htaccess file?
So did you contact energothemes?
Yes. They said it was not related to the theme. They did find one minor problem that they immediately fixed, but it didn't change anything overall.
Also contacted CSCartRocks about their SEO Ultimate addon because Energothemes thought that might be causing the issue. They updated the addon and checked everything and said they didn't believe it was their addon.
Helpdesk has now provided me with an .htaccess file, so I'll be trying that next.
I've swapped out the .htaccess file but the problem remains.
Any further insights would be appreciated.
Yes. They said it was not related to the theme. They did find one minor problem that they immediately fixed, but it didn't change anything overall.
If you disable quick view and corresponding URLs still can be found in the page source code, the issue 100% related with theme
If you disable quick view and corresponding URLs still can be found in the page source code, the issue 100% related with theme
Well, my theme developer disagrees apparently. And they are unlikely to worry too much about it if other users of their theme are not seeing the same thing and complaining to them.
How serious of an issue is this? What impact is there, beyond the annoyance of seeing hundreds of "page not found" records in my Google Analytics? Should I consider changing themes?
How serious of an issue is this? What impact is there, beyond the annoyance of seeing hundreds of "page not found" records in my Google Analytics? Should I consider changing themes?
Code examination is required in this case. You should figure out why code of the disabled feature is still used
Code examination is required in this case. You should figure out why code of the disabled feature is still used
Sounds good. When can you start?
Well, my theme developer disagrees apparently. And they are unlikely to worry too much about it if other users of their theme are not seeing the same thing and complaining to them.
How serious of an issue is this? What impact is there, beyond the annoyance of seeing hundreds of "page not found" records in my Google Analytics? Should I consider changing themes?
Dear kingsleypress,
We DO worry about any potential issues found in any of our products regardless of whether these issues are found by one single user or more users, and we are willing to immediately investigate and fix asap any issues that we, or our users find in any of our products at any given time, just as we have done in your case here.
However, in order to investigate any problem we need to firstly have a way to reliably recreate it, and only then we can search for the cause and come up with a solution. When somebody detects a possible problem in our theme, we are the first interested in investigating and fixing it asap, so that other future and/or current users may not face the same issue. That is why we have specifically dedicated the necessary time to analyze your inquiry as well as immediately fix the reported issue related to the theme.
At any rate, it seems that there is a bit of a confusion in this thread, so to avoid any misunderstandings, we’d like to emphasize the fact that there are two different issues discussed here, and they are unrelated to each other:
1. The theme “Quick view" BUTTON issue
2. The Google Analytics "dispatch=_no_page" LINK issue
Regarding the theme “Quick view" button issue:
This has already been fixed and no further code examination is required. During our investigation we have identified and immediately fixed this minor problem related to the “Quick view†button still appearing on product scrollers when the general "Enable quick view" setting was disabled.
Regarding the Google Analytics "dispatch=_no_page†link issue:
Such problem related to the "dispatch=_no_page" links has not been encountered by us nor submitted by any other VIVAshop user, so this is the first and only time we received such report.
This type of issue is devided in two points:
- The link generation (the link in the page code BEFORE a button is pressed)
- The link redirection (where the link is redirected AFTER a button is pressed)
The link generation functionality is affected by: the CS-Cart original code, third party modifications to the core CS-Cart code, theme original code, third party modifications to the theme code, third party addon(s) code affecting/overwriting theme template files.
As far as the VIVAshop theme is concerned, the theme uses the same code as the default CS-Cart Responsive theme to generate the link URLs (address/location) for all buttons. We've checked the source code for the Home page, Category page and Product page on both your store and our development store and the text "dispatch=_no_page" does not appear. Since the link URL generation functionality is correct, it means that this is not a theme related issue.
The link redirection functionality is affected by: core CS-Cart SEO addon, third party SEO related addons functionality, server settings. Since these are not related to the currently active theme they require a thorough investigation by the third party SEO addon developers and/or CS-Cart.
I used the .htaccess code on the following page to block 1,200 "bad bots":
http://tab-studio.com/en/blocking-robots-on-your-page/
I'm not seeing the strange URLs in Google Analytics so far today.
Could it be that a bot (or bots) could have been causing these strange URLs?
Why not look at visitor log and see who exactly is accessing the url?
34.219.180.241 - - [20/Jun/2018:16:14:08 -0400] "GET /index.php?dispatch=_no_page HTTP/1.1" 404 164428 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/64.0.3282.119 Safari/537.36"
193.194.83.32 - - [20/Jun/2018:17:36:31 -0400] "GET /index.php?dispatch=_no_page HTTP/1.1" 404 164428 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
34.210.65.61 - - [20/Jun/2018:17:58:56 -0400] "GET /index.php?dispatch=_no_page HTTP/1.1" 404 164428 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/64.0.3282.119 Safari/537.36"
The 1st and 3rd are amazon, which is a clear sign of malice. Both are headless which is another red flag.
The 2nd is Algiers. Unless you are selling to that country its likely also malicious.
IMHO you need some form of bot protection. Unfortunately nothing exists for cs-cart.
The 1st and 3rd are amazon, which is a clear sign of malice. Both are headless which is another red flag.
The 2nd is Algiers. Unless you are selling to that country its likely also malicious.
I guess I'm just confused as to how these bots could generate these false-looking URLs that keep appearing in Google Analytics, like the following:
/index.php?dispatch=_no_page&page=/index.php?dispatch=_no_page
/index.php?dispatch=_no_page&page=/featured-authors/amy-carmichael/returns.html
/index.php?dispatch=_no_page&page=/index.php?dispatch=product_features.add_product&product_id=492&redirect_url=index.php
/index.php?dispatch=_no_page&page=/index.php?dispatch=products.quick_view&product_id=489&prev_url=index.php&n_plain=y&n_items=493,492,491,490
IMHO you need some form of bot protection. Unfortunately nothing exists for cs-cart.
Like an addon? I saw someone on here the other day advertising a bot-blocking addon. Not sure that would be much different from the htaccess file I used...
All of the addons or bot-blocking additions to htaccess are useless for anonymous bots like you are showing in your log. I have the same issue and only wish they were accessing a no_page page. They are instead running 100's of search queries from multiple IP's within seconds and crashing the server.
All of the addons or bot-blocking additions to htaccess are useless for anonymous bots like you are showing in your log. I have the same issue and only wish they were accessing a no_page page. They are instead running 100's of search queries from multiple IP's within seconds and crashing the server.
How do you even operate an online store under those circumstances? That sounds terrible.
This problem is not unique to CS-Cart. Other platforms have various solutions to deal with malicious bots. For example:
https://bad-behavior.ioerror.us/(stops bots by analysis & fingerprinting)
https://wordpress.org/plugins/stopbadbots/
https://swissuplabs.com/magento-bot-protection.html
https://www.extendware.com/magento-bot-blocker.html
https://wordpress.org/plugins/project-honey-pot-spam-trap/
https://xenforo.com/community/resources/dbtech-dragonbyte-security.5193/
CS-Cart does not have any such security / bot protection addons. If a bot/ip is blocked by a global blacklist, uses agent/browsing anomalies, suspect headers, base64, is rotating IPs, on TOR/VPN, comes from suspect countries or blacklisted hosts then the bot can keep on hitting our CS-Cart site with no problem at all.
The problem is that these bots seem to seek out CS-Cart specifically because it is so weak. We are not getting any problems on our xenforo installations on the same sites.
While the urls you see look harmless, I found urls that included parts that looked like SQL injection attempts to fetch customer data. I reported this.
The alternative is a web firewall like cloudflare but that will also block legitimate customers, and also requires integration with CS-Cart to minimize the number of legitimate customers blocked.
Another possibility is to use fail2ban on server level. This can help a bit.
We are having significant problems with malicious bots on CS-Cart and have been having this for years. It puts our server under strain, makes the site slow which reduces orders, traffic and google ranking. I believe we had the same conversation in 2015.
For us they are not only hitting random pages, suspicious strings, but also hit a mass of filter combinations causing millions of cache files being generated. And we are also always seeing thousands of fake registrations, which I delete from the database once a month through query.