Printable View
the maah-part is there because the maah.no is just a "shortcut" to madasahatter.no if you type maah.no you instantly get redirected to madasahatter.no
this is set up in cpanel.
the admin-folder is not the same as in the htaccess i posted over, I changed the name for security reasons
Understood about the rename of the admin folder in the .htaccess (appropriate action for posting it) andunderstood that the maah.no uri gets rewritten before the ceon rewrite, but a problem is that the ceon rewrite expects the uri to contain either of the two hosts that contain maah in them. At the point this portion of the .htaccess is performed the host name should have already been rewritten and therefore the ceon rewrite never successfully rewrites if I am correct.Quote:
Originally Posted by panservolvo
I dont quite get what you're saing.
If I type madasahatter.no/myAdmin the ceon will never "see" the maah-domain, and htaccess is saying dont rewrite /myAdmin.
the maah is strictly for use as a shortcut name, nothing else
I found out what was causing the error.. Besides myself...
I had forgotten to change from the dev environtment path in the admin/includes/configuration.php
What I'm saying is that for the arrangement that you have, the .htaccess should look like below.
Reason: between rewriteconds each rewriterule is evaluated. If a rewriterule is false, then the rewritecond is not performed. Because yours has/had a check for the host_name being maah.no, then that evaluates as false every time because of the previous rewrite to make all http_host values to be madasahatter. Therefore the rewritecond never executes. In the case of trying to access the admin directory and although that issue was for another reason, the rewritecond is also not met and not performed whiich is by design. Assuming that there is no data currently to perform the rewrite (brand new install without transferring the previous database that had this plugin installed) then the issue would not have been identified until the first rewrite was entered/tested.
I'm somewhat assuming though that you did rebuild your site using your previous database and unless you disabled this plugin before upgrading the ceon tables are still present and technically the rewrites should be happening now as we speak (provided that the .htaccess directs the rewrite).
Code:#
# @copyright Copyright 2003-2010 Zen Cart Development Team
# @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
# @version $Id: .htaccess 18695 2011-05-04 05:24:19Z drbyte $
#
# This is used with Apache WebServers
#
# The following blocks direct HTTP requests to all filetypes in this directory recursively, except certain approved exceptions
# It also prevents the ability of any scripts to run. No type of script, be it PHP, PERL or whatever, can normally be executed if ExecCGI is disabled.
# Will also prevent people from seeing what is in the dir. and any sub-directories
#
# For this to work, you must include either 'All' or at least: 'Limit' and 'Indexes' parameters to the AllowOverride configuration in your apache/conf/httpd.conf file.
# Additionally, if you want the added protection offered by the OPTIONS directive below, you'll need to add 'Options' to the AllowOverride list, if 'All' is not specified.
# Example:
#<Directory "/usr/local/apache/htdocs">
# AllowOverride Limit Options Indexes
#</Directory>
###############################
##ROOT##
ExpiresActive On
ExpiresByType text/css "access plus 500 days"
ExpiresByType application/javascript "access plus 500 days"
<Files stylesheet.css>
ExpiresByType text/css "access plus 350 days"
</Files>
<FilesMatch \.(swf)$>
ExpiresDefault "access plus 700 days"
</FilesMatch>
<FilesMatch \.(svg)$>
ExpiresDefault "access plus 3000 days"
</FilesMatch>
ExpiresByType image/gif "access plus 1500 days"
ExpiresByType image/jpg "access plus 1500 days"
ExpiresByType image/jpeg "access plus 1500 days"
ExpiresByType image/png "access plus 1500 days"
ExpiresByType image/bmp "access plus 1500 days"
# 48 weeks
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|JPG|woff)$">
Header set Cache-Control "max-age=29030400, public"
</FilesMatch>
<files *>
order allow,deny
deny from 80.212.29.94
deny from 74.50.57.39
deny from 24.189.60.120
deny from 84.17.15.2
deny from 211.167.110.2
deny from 91.201.64.26
deny from 65.208.189
deny from 65.211.195
#deny from 195.1.61
allow from all
</files>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/MyAdminFolder [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors [NC]
# Don't rewrite cPanel directories
RewriteCond %{REQUEST_URI} !/cpanel [NC]
RewriteCond %{REQUEST_URI} !/frontend [NC]
# Don't rewrite ajax directory
RewriteCond %{REQUEST_URI} !^/ajax/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (index.php)
# RewriteRule .* index.php?%{QUERY_STRING} [L]
RewriteRule ^/?$ "http\:\/\/madasahatter\.no\/" [R=301,L]
Thanks for helping out. Your rewrite part didnt work, probably because of the # before the .* index.php?
I have changed my rewrite part to this and its working.
Any comments?
Code:RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^madasahatter.no$ [NC]
RewriteRule ^(.*)$ http://madasahatter.no/$1 [L,R=301]
## BEGIN CEON URI MAPPING REWRITE RULE
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite any URIs for some, popular specific file format extensions,
# which are not covered by main file extension condition above
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
# Don't rewrite any URIs for some specific file format extensions,
# which are not covered by main file extension condition above
# Uncomment the following line to apply this condition! (Remove the # at the start of the next line)
#RewriteCond %{REQUEST_URI} !\.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/SuperSecretAdminPath [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Don't rewrite min directory
RewriteCond %{REQUEST_URI} !^/min/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
First is that in many places I had the wrong statement (corrected below in red).
Quote:
Originally Posted by mc12345678
As to the above new rewrite rule, I do not currently have an answer as I am unable to review an existing functional version to determine if the .htaccess conditions and rules are correct. Suggest though using the admin tool to autogenerate the htaccess rules to validate.Quote:
Originally Posted by panservolvo
I would recommend removing the directive "RewriteBase /" (not needed, just increases processing time).Quote:
Originally Posted by panservolvo
If after removing the other directives from the .htaccess file (like the example) everything works, most likely the new hosting provider does not support one those removed directives. When a directive is found in a .htaccess file and has been disabled or disallowed by the server configuration, it often results in a HTTP 500. There should be records in the server's error log indicating the cause of the HTTP 500.
Hi, we are using this module on a site that is also using a Google Sitemap XML file generator plugin.
Our output file is only giving us the old, standard Zen Cart product ID URL - which Google really doesn't like inside XML sitemaps as it requires a 200 response header rather than a 301.
The documentation states that the module deals with this and how to set it up, but the output is only ever the same, with the original URL.
Is there anyway to pull the new URL out (generated by CEON module) and input it into the Sitemap XML file? The info should be inside the database somewhere...
Cheers,
dp
Verify your installation of both products, as we are using the same and have no issues... XML files reflect the rewritten URLs. Also, helps to identify the version(s) of the software, but this may be something to address in the Google Sitemap XML thread as it seems that it is what is not working correctly, or on a separate thread as these two products work together when the applicable files are properly merged/installed. (Successfully working on ZC 1.5.1 and expect no different on ZC 1.5.3)Quote:
Originally Posted by dp-web