Printable View
Usually indicates something is not working in your template. Do the resources show up correctly in the "classic" template? Have you looked at any 404 errors to determine what may be broken (404 errors cause major load time issues)? Have you tried different cache settings / URL settings? Have you tried a different browser?Quote:
Originally Posted by vinyl_ninja
The supplied .htaccess file is for Apache mod_rewrite. Your webserver is not running Apache (and thus not using mod_rewrite). The server your website is hosted upon appears to be using LiteSpeed as the WebServer.Quote:
Originally Posted by su35
Since everything is working from useragents other than "googlebot", this makes me suspect another rule may be configured on the webserver to selectively apply the .htaccess filter based upon useragent.
These are not issues with this plugin, but with your hosting provider (and their compatibility with mod_rewrite). You will want to contact your hosting provider and ask... Why when the user agent is "Googlebot" is their server is not applying the .htaccess filter (and rewrite rules)? Can they "fix" the configuration of their server to correctly apply the .htaccess filter to ALL requests?
Hi lhungil
Thanks for your reply. Things have changed, even the firebug return a 404.(tried a lot, could not remember how made)
Attachment 12904
First, only three pages (new products, all products and featured products) return 404. It looks like the problem was from the page codes. However, if the format of the URL was index.php?main_page=xxx, there was no issues. I think it suggested that, instead of a codes problem, it's a rewrite problem.
Second, checking the .htaccess file, it looks like that the following codes should be respond to charge rewriting index.php?main_page=xxx format URL. However, I have other page with the same URL format, the software page. The software page return 200 in both index.php?main_page=softwae and software.html format.
Totally confused.Code:RewriteCond %{REQUEST_FILENAME} !-f [NC]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*).html$ index\.php?main_page=$1&%{} [L]
Only requests with certain "user agents" appear to not be applying the rewrite rules (you can see this at "web-sniffer.net"). This is not an issue with the supplied Apache mod_rewrite rules or this module.
This is most likely a problem with the configuration on the webserver where your website is hosted (or perhaps you have multiple domains sharing a common document root). The best thing you can do is CONTACT THE COMPANY YOU ARE PAYING to host your website and have them find and fix whatever configuration on the server is causing your issue. The company hosting your website will have access to additional logs and additional methods to track down the culprit.
Hi lhungil
Sorry, I have not describe the problem clear and made it confused. Let's focus on my local server (apache 2.4.3, php 5.4.7)
There are 14 links (domain name/xxx.html format) on home page. If SSEO was off, there was no any issue. I think that means that there is no code or structure error on the pages that the 14 links point to. If SSEO was on, 8 pages return the 404 and 6 pages return 200. It looks like some problem in rewriting process. However, instead of loading 404 page, all the pages loaded correctly. Does it mean a 404 was responded before the rewriting process done?
As an example:
Attachment 12917
Thanks lhungil, you are right. The standard template works perfectly so its something to do with the template I'm using. It's the same in Chrome and Firefox. I think I can see where the problem is although I'm still not sure why. The developer tools show all files are found successfully but all the Javascript files are coming back with an error - "Uncaught Syntax Error: Unexpected Token". This is only on the dev site running USEO.Quote:
Originally Posted by lhungil
I'll have a look at the files to see if I can figure out what it might be but if you have any pointers or have come across this before it'd be great to know.
Thanks!
A bit of further information, the console also shows:
"Resource interpreted as Script but transferred with MIME type text/html"
"Resource interpreted as Stylesheet but transferred with MIME type text/html"
This only happens with USEO enabled.
I've found a workaround although not fixed the issue. If I hard code the links to the css and js files the site works perfectly.
So its something do do with this bit of code:
Code:<?php echo $template->get_template_dir('',DIR_WS_TEMPLATE, $current_page_base,'jscript').'/bootstrap.js'?>
I am unable to duplicate the issues you appear to be experiencing in a stock Zen Cart 1.5.1 installation with an unmodified version of Ultimate (SEO) URLs 2.212 installed.Quote:
Originally Posted by su35
Upon further review of your previous posts it appears you have made additional modifications to Zen Cart and this module. These modifications are the most likely cause of the issues you are experiencing.
I would strongly recommend:
- Backup your test environment.
- Uninstall the module providing alternative URLs. This includes removing all new files, modifications made to Zen Cart files, database modifications, and database entries.
- Install an UNMODIFIED version of Ultimate (SEO) URLs. Do NOT merge any changes into this modules "new_files" or ".htacces" file.
- Configure Ulimate (SEO) URLs to fit your needs and re-test.
Thank You for confirming the issue is most likely with the template you have installed.Quote:
Originally Posted by vinyl_ninja
This module only changes the URLs generated by Zen Cart. It does not modify any resources or the webserver requests / responses. So nothing this module does should result in the issues you are seeing.Quote:
Originally Posted by vinyl_ninja
It may indicate your template was not installed correctly. Or your tempalte makes assumptions based upon URLs (instead of using Zen Cart functions). Or your template includes code which attempts to "minify", "combine", or otherwise alter JavaScript and CSS resources?
It would also be helpful to know what other "modifications" have been made to the site. It would also be helpful if you could provide a link to the test site so we can "see" what is happening.