Zen Cart Logo
Forums / All Other Contributions/Addons / Ceon URI Mapping V5.0

Ceon URI Mapping V5.0

Views: 88,597

Results 61 to 80 of 392
19 Aug 2019, 2:01 AM
#61
draxwyn avatar

draxwyn

New Zenner

Join Date:
Aug 2005
Posts:
30
Plugin Contributions:
0

Ceon URI Mapping V5.0

Hi All!

Just upgraded to 1.5.6c and also grabbed the new version of this mod. After getting a 500 error and not because of the mod rewrite I managed to get most of the site working with 'lat9' trick changing the $autoLoadConfig[95].

However EzPages do not work I get the error 'WARNING: An Error occurred, please refresh the page and try again.' Anybody have any ideas why this is happening or how to fix it?

Thanks in advance!

19 Aug 2019, 10:38 AM
#62
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Ceon URI Mapping V5.0

Draxwyn:

Hi All!

Just upgraded to 1.5.6c and also grabbed the new version of this mod. After getting a 500 error and not because of the mod rewrite I managed to get most of the site working with 'lat9' trick changing the $autoLoadConfig[95].

However EzPages do not work I get the error 'WARNING: An Error occurred, please refresh the page and try again.' Anybody have any ideas why this is happening or how to fix it?

Thanks in advance!
Does the error happen on the admin side or the catalog? Be sure that have accessed the module from the admin side to support database upgrade/install. For the issue on the catalog side using the provided version of this software, there should not be any issues as the code referenced a few posts back is not executed (nor exists at the reported line number) in normal operation.

Lastly, although in normal form, I have taken a guess at the situation, reporting what is in the myDebug file generated in the logs directory would help as well as addressing the posting tips. For example, upgraded to ZC 1.5.6c from what version?

19 Aug 2019, 10:02 PM
#63
draxwyn avatar

draxwyn

New Zenner

Join Date:
Aug 2005
Posts:
30
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

mc12345678:

Does the error happen on the admin side or the catalog? Be sure that have accessed the module from the admin side to support database upgrade/install. For the issue on the catalog side using the provided version of this software, there should not be any issues as the code referenced a few posts back is not executed (nor exists at the reported line number) in normal operation.

Lastly, although in normal form, I have taken a guess at the situation, reporting what is in the myDebug file generated in the logs directory would help as well as addressing the posting tips. For example, upgraded to ZC 1.5.6c from what version?

The error is occuring on the catalog side, so when the link to an ezpage is clicked instead of loading the easy page (it has the correct URL in the bar) it just displays the error 'WARNING: An Error occurred, please refresh the page and try again.' It only happens on ezpages on the catalog side. Admin side I can still access, setup and configure ezpages no problems on that side just when as a customer they would try to view it.

Everything as far as I can see has been setup and installed correctly. ZC was updated from 1.5.5 to the latest version 1.5.6c. CEON URI mapping was updated from ceon_uri_mapping_4.4.2_for_zc to ceon_uri_mapping_5.0.0_for_zc, which for the most part when smoothly other than having to remove a couple of old ceon calls that the configuration tool said it no longer needed for it. All other URLs now have the nice naming and work it is just the ezpages that return this error with this ceon mod enabled, they work without it enabled.

No myDebug file has been created so it is only the error displayed on the screen.

My understanding of the somewhat generic error that is being thrown is that the php code can't connect to the DB, but as absolutely everything else works and ZC can connect to the DB elsewhere I am stumped as that what the problem is.

20 Aug 2019, 1:26 AM
#64
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Ceon URI Mapping V5.0

Draxwyn:

The error is occuring on the catalog side, so when the link to an ezpage is clicked instead of loading the easy page (it has the correct URL in the bar) it just displays the error 'WARNING: An Error occurred, please refresh the page and try again.' It only happens on ezpages on the catalog side. Admin side I can still access, setup and configure ezpages no problems on that side just when as a customer they would try to view it.

Everything as far as I can see has been setup and installed correctly. ZC was updated from 1.5.5 to the latest version 1.5.6c. CEON URI mapping was updated from ceon_uri_mapping_4.4.2_for_zc to ceon_uri_mapping_5.0.0_for_zc, which for the most part when smoothly other than having to remove a couple of old ceon calls that the configuration tool said it no longer needed for it. All other URLs now have the nice naming and work it is just the ezpages that return this error with this ceon mod enabled, they work without it enabled.

No myDebug file has been created so it is only the error displayed on the screen.

My understanding of the somewhat generic error that is being thrown is that the php code can't connect to the DB, but as absolutely everything else works and ZC can connect to the DB elsewhere I am stumped as that what the problem is.

Well, being able to actually have information to evaluate would make it easier for everyone. That message is covered by this FAQ: https://www.zen-cart.com/content.php?311-warning-an-error-occurred-please-refresh-the-page-and-try-again

Sounds like either writing error messages to file has been disabled, the logs folder is in some way "protected" from receiving additional logs. With that message in ZC 1.5.6, a relatively detailed log file should be generated.

20 Aug 2019, 2:32 AM
#65
noppie avatar

noppie

Zen Follower

Join Date:
Mar 2004
Posts:
210
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

lat9:

Nice bit of debugging, @simon1066! I was able to successfully load my locally-hosted storefront by modifying /includes/auto_loaders/config.ceon_uri_mapping.php, changing

$autoLoadConfig[99][] = array(
'autoType' => 'classInstantiate',
'className' => 'CeonURIMappingHandler',
'objectName' => 'ceon_uri_mapping'
);

> to
> ```
$autoLoadConfig[[B]95[/B]][] = array(
	'autoType' => 'classInstantiate',
	'className' => 'CeonURIMappingHandler',
	'objectName' => 'ceon_uri_mapping'
	);

thank you so much.. it helped me also..
thank you

20 Aug 2019, 11:46 PM
#66
draxwyn avatar

draxwyn

New Zenner

Join Date:
Aug 2005
Posts:
30
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

Draxwyn:

The error is occuring on the catalog side, so when the link to an ezpage is clicked instead of loading the easy page (it has the correct URL in the bar) it just displays the error 'WARNING: An Error occurred, please refresh the page and try again.' It only happens on ezpages on the catalog side. Admin side I can still access, setup and configure ezpages no problems on that side just when as a customer they would try to view it.

Everything as far as I can see has been setup and installed correctly. ZC was updated from 1.5.5 to the latest version 1.5.6c. CEON URI mapping was updated from ceon_uri_mapping_4.4.2_for_zc to ceon_uri_mapping_5.0.0_for_zc, which for the most part when smoothly other than having to remove a couple of old ceon calls that the configuration tool said it no longer needed for it. All other URLs now have the nice naming and work it is just the ezpages that return this error with this ceon mod enabled, they work without it enabled.

No myDebug file has been created so it is only the error displayed on the screen.

My understanding of the somewhat generic error that is being thrown is that the php code can't connect to the DB, but as absolutely everything else works and ZC can connect to the DB elsewhere I am stumped as that what the problem is.

I managed to resolve the issue. Updating ZC locked the logs folder so no log files were being generated. Once I got that fixed and replicated the problem to get a log file I found that one of the files didn't upload properly or became corrupt during update of ZC, after fixing that everything is now working as expected.

13 Sep 2019, 12:46 AM
#67
mjf91331 avatar

mjf91331

New Zenner

Join Date:
Sep 2019
Location:
Los Angeles
Posts:
14
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

I'm on a fresh install of 1.5.6c using Tableau2 template which itself installs IH4, numinix disk cache, css js loader and homepage product carousels.
Quite stuck installing the plugin because I can't make some edits to template files since the code isn't in the file for this template.

I uploaded everything from files/admin and files/includes

Made the edits to modified_core_files/1.5.6/admin/includes/javascript_loader
This file which needed editing did not exist on my server so I just uploaded it: modified_core_files/1.5.6/includes/init_includes/init_add_crumbs

Instructions state (I think) my 1.5.6c install should need these files but they don't exist in the plugin folder
includes/init_includes/overrides/init_canonical.php (Zen Cart 1.3.0 - 1.5.6a)
includes/init_includes/overrides/init_currencies.php (Zen Cart 1.3.0 - 1.5.6a)
includes/init_includes/overrides/init_sessions.php (Zen Cart 1.3.9/1.5.6a)

Lastly, template_override_files/1.5.6/includes/templates
Bit confused does responsive_template mean the responsive template I am using or the default responsive_classic template?
If it means my currently used responsive template, html_header for Tableau2 does not include the piece of code to edit nor does /templates/tpl_index_product_list

As for store-template I don't really know what that means either, is it if you aren't using a responsive template so can be ignored?

I hope I've provided enough information and very much appreciate any help. Been looking forward to having clean links with store updates for years.

<?php
/**
 * Common Template
 *
 * outputs the html header. i,e, everything that comes before the \</head\> tag <br />
 *
 * @package templateSystem
 * @copyright Copyright 2003-2010 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: html_header.php 6 2012-05-07 21:43:01Z numinix $
 */
/**
 * load the module for generating page meta-tags
 */
require(DIR_WS_MODULES . zen_get_module_directory('meta_tags.php'));
/**
 * output main page HEAD tag and related headers/meta-tags, etc
 */
?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" <?php echo HTML_PARAMS; ?>>
<head>
  <title><?php echo META_TAG_TITLE; ?></title>
  <meta charset="<?php echo CHARSET; ?>" />
  <meta http-equiv="x-ua-compatible" content="ie=edge">
  <meta name="keywords" content="<?php echo META_TAG_KEYWORDS; ?>" />
  <meta name="description" content="<?php echo META_TAG_DESCRIPTION; ?>" />
  <meta name="author" content="The Zen Cart™ Team and others" />
    <?php
    if ($_SESSION['view'] == 'desktop'){}
    else { ?>
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <?php } ?>

  <meta name="theme-color" content="#333333">
  <meta name="generator" content="shopping cart program by Zen Cart™, http://www.zen-cart.com eCommerce" />
  <?php if (defined('ROBOTS_PAGES_TO_SKIP') && in_array($current_page_base,explode(",",constant('ROBOTS_PAGES_TO_SKIP'))) || $current_page_base=='down_for_maintenance' || $robotsNoIndex === true) { ?>
  <meta name="robots" content="noindex, nofollow" />
  <?php } ?>
  <?php if (defined('FAVICON')) { ?>
  <link rel="icon" href="<?php echo FAVICON; ?>" type="image/x-icon" />
  <link rel="shortcut icon" href="<?php echo FAVICON; ?>" type="image/x-icon" />
  <?php } //endif FAVICON ?>

  <base href="<?php echo (($request_type == 'SSL') ? HTTPS_SERVER . DIR_WS_HTTPS_CATALOG : HTTP_SERVER . DIR_WS_CATALOG ); ?>" />
  <?php if (isset($canonicalLink) && $canonicalLink != '') { ?>
  <link rel="canonical" href="<?php echo $canonicalLink; ?>" />
  <?php } ?>

<?php
/**
* load the loader files
*/
$RC_loader_files = array();
if($RI_CJLoader->get('status') && (!isset($Ajax) || !$Ajax->status())){
    $RI_CJLoader->autoloadLoaders();
    $RI_CJLoader->loadCssJsFiles();
    $RC_loader_files = $RI_CJLoader->header();

    foreach($RC_loader_files['meta'] as $file) {
        include($file['src']);
        echo "\n";
    }

    foreach($RC_loader_files['css'] as $file){
        if($file['include']) {
            include($file['src']);
        } else if (!$RI_CJLoader->get('minify_css') || $file['external']) {
            //$link = $file['src'];
            echo '<link rel="stylesheet" type="text/css" href="'.$file['src'] .'" />'."\n";
        } else {
            //$link = 'min/?f='.$file['src'].'&'.$RI_CJLoader->get('minify_time');
            echo '<link rel="stylesheet" type="text/css" href="min/?f='.$file['src'].'&'.$RI_CJLoader->get('minify_time').'" />'."\n";
        }
    } 
}
//DEBUG: echo '<!-- I SEE cat: ' . $current_category_id . ' || vs cpath: ' . $cPath . ' || page: ' . $current_page . ' || template: ' . $current_template . ' || main = ' . ($this_is_home_page ? 'YES' : 'NO') . ' -->';
?>
  <!-- TrustBox script --> <script type="text/javascript" src="//widget.trustpilot.com/bootstrap/v5/tp.widget.bootstrap.min.js" async></script> <!-- End TrustBox script -->
</head>

<?php // NOTE: Blank line following is intended: ?>
14 Sep 2019, 3:35 AM
#68
mjf91331 avatar

mjf91331

New Zenner

Join Date:
Sep 2019
Location:
Los Angeles
Posts:
14
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

To add to my above post, I noticed there was a 5.0.1 version available on the CEON site (5.0.0 on the zen cart plugin finder) so I replaced everything from the "files" folder and it started working. Before then I was getting "too many redirects" or internal server error so I think 5.0.0 may not be compatible with zen cart 1.5.6c

I am still unsure what to do about template edits though since the plugin is fully functioning even though I wasn't able to make all the edits to my currently used template. It's just not so clear if "responsive-template" and "store-template" refers to your currently used responsive or not responsive template or the base templates that come with zen cart. Usually plugins will either name the folders after the base folders or call them "your-template"

14 Sep 2019, 11:43 AM
#69
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,081
Plugin Contributions:
56

Re: Ceon URI Mapping V5.0

mjf91331:

To add to my above post, I noticed there was a 5.0.1 version available on the CEON site (5.0.0 on the zen cart plugin finder) so I replaced everything from the "files" folder and it started working. Before then I was getting "too many redirects" or internal server error so I think 5.0.0 may not be compatible with zen cart 1.5.6c

I am still unsure what to do about template edits though since the plugin is fully functioning even though I wasn't able to make all the edits to my currently used template. It's just not so clear if "responsive-template" and "store-template" refers to your currently used responsive or not responsive template or the base templates that come with zen cart. Usually plugins will either name the folders after the base folders or call them "your-template"
See post #45 of this thread for the solution to the "too many redirects" issue on zc156c.

18 Sep 2019, 10:41 AM
#70
shags38 avatar

shags38

Totally Zenned

Join Date:
Jan 2011
Location:
Adelaide, Australia
Posts:
1,684
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

v1.5.5f PHP7.1 CEON uri mapping - IH - and others (previously reported in this thread July 26 with no responses https://www.zen-cart.com/showthread.php?225719-404-errors-after-changing-product-url&p=1360016#post1360016)

When adding new products in configuration/catalogue/products/new_product I am getting the following problem.

Problem. 404 error: When I add a new product then go to the site the product is there in category/listing but when clicking on it to go to product/info page I get a 404 error 'this resource is not available on this server' i.e. a blank page, not the default ZC 404 page.

the box at the bottom of the create product page is ticked by default for auto generation of url - if I add a product and untick the CEON automatic uri generation box the product loads and works as it should on the site (it then has a generic ZC url).

I have checked and re-checked the CEON installation and configuration using the inbuilt checking and all is OK - I even added the "/" in front of index as suggested - "Try adding a slash to the front of index.php, this may resolve the problem: RewriteRule .* /index.php [QSA,L]" but that made no difference.

notes:

  1. another site (former site) is wildcard redirected to this new site
  2. this new site is an exact clone of the former site, i.e. all folders are exactly the same and so is the data base (renamed)
  3. site works seamlessly except for adding new products
  4. .htaccess which I thought may be an issue is an exact copy from another site that also is a clone site that is also widcard redirected - so same same - and that site does not have the new product creation issue
  5. I have in fact rolled back the site to a saved copy pre redirection above

I do not want to reinstall CEON because I will lose all existing mapped urls

So looking for some ideas here please.

cheers,
Mike

.htaccess file

RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^index\.php$ - [L]

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

###############################################################################
# Add any other directives relating to the handling of physical files
###############################################################################
# Notes:
#
# If processing makes it this far, the request was for a real file or folder.
# Example: Adding further processing related to browser caching or security.
###############################################################################
<IfModule mod_security.c>
    SecFilterScanPOST Off
</IfModule>

###############################################################################

## BEGIN CEON URI MAPPING REWRITE RULE

RewriteEngine On

# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
# Don't rewrite any URIs for some, popular specific file format extensions,
#   which are not covered by main file extension condition above
# 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
# Don't rewrite editors directory
# Don't rewrite bmz_cache directory
# Don't rewrite .well-known directory
# Don't rewrite teststore directory
# Don't rewrite cgi-bin directory
# Don't rewrite zc_install_done directory
# Don't rewrite blog directory
# Don't rewrite logs directory
# Don't rewrite sitemap directory
# Don't rewrite temp directory
# Handle all other URIs using Zen Cart (its index.php)
RewriteCond %{REQUEST_URI} !\.[a-zA-Z]{2,5}$ [OR]
RewriteCond %{REQUEST_URI} \.(html)$ [NC]
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
RewriteCond %{REQUEST_URI} !^/dazzlers [NC]
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
RewriteCond %{REQUEST_URI} !^/\.well\-known/ [NC]
RewriteCond %{REQUEST_URI} !^/teststore/ [NC]
RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]
RewriteCond %{REQUEST_URI} !^/zc_install_done/ [NC]
RewriteCond %{REQUEST_URI} !^/blog/ [NC]
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
RewriteCond %{REQUEST_URI} !^/sitemap/ [NC]
RewriteCond %{REQUEST_URI} !^/temp/ [NC]
RewriteRule .* /index.php [QSA,L]

## END CEON URI MAPPING REWRITE RULE

###############################################################################

## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################

##################
## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|webp|js|css|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<IfModule mod_deflate.c>
  <FilesMatch "(?i)\.(js|css)$">
    SetOutputFilter DEFLATE
  </FilesMatch>
</IfModule>

##################
## Optional improvements
## Requires mod_expires to be enabled within Apache
##################
## EXPIRES HEADER CACHING ##
 <IfModule mod_expires.c>
 ExpiresActive On
 ExpiresByType image/jpg "access 1 year"
 ExpiresByType image/jpeg "access 1 year"
 ExpiresByType image/gif "access 1 year"
 ExpiresByType image/png "access 1 year"
 ExpiresByType text/css "access 1 month"
 ExpiresByType application/pdf "access 1 month"
 ExpiresByType application/javascript "access 1 month"
 ExpiresByType application/x-javascript "access 1 month"
 ExpiresByType application/x-shockwave-flash "access 1 month"
 ExpiresByType image/x-icon "access 1 year"
 ExpiresDefault "access 7 days"
 </IfModule>
 ## EXPIRES HEADER CACHING

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php70” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php70 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit
18 Sep 2019, 1:29 PM
#71
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Ceon URI Mapping V5.0

shags38:

v1.5.5f PHP7.1 CEON uri mapping - IH - and others (previously reported in this thread July 26 with no responses https://www.zen-cart.com/showthread.php?225719-404-errors-after-changing-product-url&p=1360016#post1360016)

When adding new products in configuration/catalogue/products/new_product I am getting the following problem.

Problem. 404 error: When I add a new product then go to the site the product is there in category/listing but when clicking on it to go to product/info page I get a 404 error 'this resource is not available on this server' i.e. a blank page, not the default ZC 404 page.

the box at the bottom of the create product page is ticked by default for auto generation of url - if I add a product and untick the CEON automatic uri generation box the product loads and works as it should on the site (it then has a generic ZC url).

I have checked and re-checked the CEON installation and configuration using the inbuilt checking and all is OK - I even added the "/" in front of index as suggested - "Try adding a slash to the front of index.php, this may resolve the problem: RewriteRule .* /index.php [QSA,L]" but that made no difference.

notes:

  1. another site (former site) is wildcard redirected to this new site
  2. this new site is an exact clone of the former site, i.e. all folders are exactly the same and so is the data base (renamed)
  3. site works seamlessly except for adding new products
  4. .htaccess which I thought may be an issue is an exact copy from another site that also is a clone site that is also widcard redirected - so same same - and that site does not have the new product creation issue
  5. I have in fact rolled back the site to a saved copy pre redirection above

I do not want to reinstall CEON because I will lose all existing mapped urls

So looking for some ideas here please.

cheers,
Mike

.htaccess file

RewriteCond %{REQUEST_URI} !^/[0-9]+..+.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$
RewriteRule ^index.php$ - [L]

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

###############################################################################

Add any other directives relating to the handling of physical files

###############################################################################

Notes:

If processing makes it this far, the request was for a real file or folder.

Example: Adding further processing related to browser caching or security.

###############################################################################
<IfModule mod_security.c>
SecFilterScanPOST Off
</IfModule>

###############################################################################

BEGIN CEON URI MAPPING REWRITE RULE

RewriteEngine On

Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])

Don't rewrite any URIs for some, popular specific file format extensions,

which are not covered by main file extension condition above

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

Don't rewrite editors directory

Don't rewrite bmz_cache directory

Don't rewrite .well-known directory

Don't rewrite teststore directory

Don't rewrite cgi-bin directory

Don't rewrite zc_install_done directory

Don't rewrite blog directory

Don't rewrite logs directory

Don't rewrite sitemap directory

Don't rewrite temp directory

Handle all other URIs using Zen Cart (its index.php)

RewriteCond %{REQUEST_URI} !.[a-zA-Z]{2,5}$ [OR]
RewriteCond %{REQUEST_URI} .(html)$ [NC]
RewriteCond %{REQUEST_URI} !.(mp3|mp4|h264)$ [NC]
RewriteCond %{REQUEST_URI} !^/dazzlers [NC]
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
RewriteCond %{REQUEST_URI} !^/.well-known/ [NC]
RewriteCond %{REQUEST_URI} !^/teststore/ [NC]
RewriteCond %{REQUEST_URI} !^/cgi-bin/ [NC]
RewriteCond %{REQUEST_URI} !^/zc_install_done/ [NC]
RewriteCond %{REQUEST_URI} !^/blog/ [NC]
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
RewriteCond %{REQUEST_URI} !^/sitemap/ [NC]
RewriteCond %{REQUEST_URI} !^/temp/ [NC]
RewriteRule .* /index.php [QSA,L]

END CEON URI MAPPING REWRITE RULE

###############################################################################

Optional caching improvements

Requires mod_header and mod_deflate to be enabled within Apache

##################

##################

Optional caching improvements

Requires mod_header and mod_deflate to be enabled within Apache

##################
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|webp|js|css|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<IfModule mod_deflate.c>
<FilesMatch "(?i).(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

##################

Optional improvements

Requires mod_expires to be enabled within Apache

##################

EXPIRES HEADER CACHING

<IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access 1 year" ExpiresByType image/jpeg "access 1 year" ExpiresByType image/gif "access 1 year" ExpiresByType image/png "access 1 year" ExpiresByType text/css "access 1 month" ExpiresByType application/pdf "access 1 month" ExpiresByType application/javascript "access 1 month" ExpiresByType application/x-javascript "access 1 month" ExpiresByType application/x-shockwave-flash "access 1 month" ExpiresByType image/x-icon "access 1 year" ExpiresDefault "access 7 days" </IfModule> ## EXPIRES HEADER CACHING

php -- BEGIN cPanel-generated handler, do not edit

Set the “ea-php70” package as the default “PHP” programming language.

<IfModule mime_module> AddHandler application/x-httpd-ea-php70 .php .php7 .phtml </IfModule> # php -- END cPanel-generated handler, do not edit ```

In review of other .htaccess rules I have seen and had to implement, a possible alternative RewriteRule line could be:

RewriteRule ^(.*)$ /index.php [QSA,L]

or

RewriteRule ^(.*)$ index.php [QSA,L]

The problem described certainly appears to be related to the .htaccess file where the installation check seems to just offer a recommended .htacess file based on a few minor factors, not necessarily guaranteed to work on the specific server.

As an aside, it appears that the admin directory has been published for all to see. Would recommend that the admin directory be renamed both on the server and in the .htaccess file.

Now there are also a number of other questions that have gone unanswered: what version of Ceon URI Mapping is being used, is the site in a sub-directory as seen in a web-browser? Why are some of the other RewriteCond statements in the installation check not included?

19 Sep 2019, 1:00 AM
#72
shags38 avatar

shags38

Totally Zenned

Join Date:
Jan 2011
Location:
Adelaide, Australia
Posts:
1,684
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

mc12345678:

In review of other .htaccess rules I have seen and had to implement, a possible alternative RewriteRule line could be:

RewriteRule ^(.*)$ /index.php [QSA,L]

> or
> ```
RewriteRule ^(.*)$ index.php [QSA,L]

The problem described certainly appears to be related to the .htaccess file where the installation check seems to just offer a recommended .htacess file based on a few minor factors, not necessarily guaranteed to work on the specific server.

As an aside, it appears that the admin directory has been published for all to see. Would recommend that the admin directory be renamed both on the server and in the .htaccess file.

Now there are also a number of other questions that have gone unanswered: what version of Ceon URI Mapping is being used, is the site in a sub-directory as seen in a web-browser? Why are some of the other RewriteCond statements in the installation check not included?

Many thanks for your response mc ....

I changed that rule but to no effect. The version installed is 4.5.5. Not sure what you mean about this 'As an aside, it appears that the admin directory has been published for all to see' ? ... my admin name doesn't appear in the .htaccess - the site is in the root, it is not a sub-domain. All the RewriteCond statements in the installation check are in fact included.

This comment is interesting to me 'not necessarily guaranteed to work on the specific server' - the very same .htaccess file works on at least 3 other sites that are all on the same server, different nodes. Given you didn't see anything glaringly faulty is it possible that it could be a server 'permissions' issue. The problem has occurred subsequent to the wildcard redirect from the former site but that redirect is functioning fine and I am at a loss to fathom how that could have an effect on CEON ... other than ... is the installation of CEON 'domain specific'? - i.e. this site is a clone of the former site, would that have any effect? (clutching at straws now methinks).

Is v4.5.5 upgrade-able to v5.0.0 without losing existing mapped urls? - I have v5.0.0 downloaded as I used it in the ZC v1.5.6b version of this site which is not live because of template issues. I note in v5.0.0 it shows modified files specifically for zc v1.5.5f ... one of which is this admin/includes/modules/update_product.php

Again probably clutching at straws given that v4.5.5 was working ok in zc v1.5.5f before the change of site/wildcard redirect - just a rambling thought.

So can you think of any other areas I should be looking at?

cheers,
Mike

19 Sep 2019, 7:18 AM
#73
shags38 avatar

shags38

Totally Zenned

Join Date:
Jan 2011
Location:
Adelaide, Australia
Posts:
1,684
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

@mc .... I've had my host look at possible causes and they came up with zip (see below).

So it appears something likely within the CEON code is not submitting the uri mapping correctly to the server (if at all) such that the server can recognize it, (guessing here - possibly in a corrupted format?) - regardless something is stopping the uri mapping from uploading when update is clicked in product_update HOWEVER only for new products since the new site was built (copied over) - possibly a bad ftp transfer of a crucial file in CEON? (grabbing at straws again). I can go into existing products and alter the existing uri mapping and the product still resolves - so it tends away from simply the update_product button.

I need to add some new products so may end up doing so by un-ticking the auto generate button in product creation and when the problem has been found I can go back and tick it and update - I hate doing this sort of thing as it screws things up with Google Search.

Hopefully you will come up with a fix soonish - I will keep trying different things my end.

Importantly ... can I re-install CEON without losing existing mapping data? .... if so then that may be a good step - if it does lose the existing data then not so good.

cheers,
Mike

from my host:

I have contacted a Senior Technician to overlook your query and we both can confirm that your rewrite conditions will not have an effect to your 404 issue.
I would also like to mention that this cPanel service is also on the same server as the domain dazzlersharmonynecklace.com.

Both of these domains are being resolved from the following shared IP address:

------------------- A/AAAA record(s) -------------
103.27.34.7 >> r131.syd3.hostingplatform.net.au.

While your error logs have also not provided any issued related to the permissions of this website specifically, I suggest running our Permissions fixer tool which will default your files permissions to 755 and 644 respectively; this will also eliminate the concern of the incorrect permissions within this specific cPanel account.
This can be done via the following:

Log into VIPControl >> Web Hosting >> Manage >> List Accounts >> Manage >> Permission Fixer

19 Sep 2019, 10:38 AM
#74
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Ceon URI Mapping V5.0

To address the first of things, this forum thread is about version 5 of the module. If wanting to address things about version 4 they should be discussed in the appropriate forum thread. That said, version 5 can be installed it seems by following the install and/or upgrade instructions.

As far as I know and understand the module, because it's power is in database use, as long as you maintain the database entries associated with any existing "use" then you can install and/or upgrade without specific issue. Now that said, reuploading the files that are in the files section is not exactly like reinstalling and it seems that the software is written to handle the situation of an attempt to reinstall. Even in my experience I've "removed" the plugin following the directions and loaded it again without loss. As always backup the database...

The fact that existing uris can be modified and work, but new uris are causing a problem seems to indicate that there may be a problem with the database. Understanding that this database was in some way carried over from another system calls to question the success in that move and/or the verification that all of the files made it fully intact and as suggested by the host with the appropriate permissions and ownership.

From what is described, existing rewritten uris continue to function, but those generated for new product are not reachable. That would seem to indicate that when storing the new uri(s) there is some information associated with the Zen Cart portion of the designation that is not correct. Therefore when the rewritten uri is provided to the system, the retrieved Zen Cart portions do not resolve to a known page.

As far as I recall seeing in the 4.5.5 version, I'm not so sure that the installation check had been updated to reflect the expected condition of the software. I can say that I'm glad Ceon was able to finally distribute an updated version and it seems that version 5 includes the files necessary to operate on Zen Cart 1.5.5 (as well as other versions).

19 Sep 2019, 10:25 PM
#75
shags38 avatar

shags38

Totally Zenned

Join Date:
Jan 2011
Location:
Adelaide, Australia
Posts:
1,684
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

mc12345678:

As far as I know and understand the module, because it's power is in database use, as long as you maintain the database entries associated with any existing "use" then you can install and/or upgrade without specific issue. Now that said, reuploading the files that are in the files section is not exactly like reinstalling and it seems that the software is written to handle the situation of an attempt to reinstall. Even in my experience I've "removed" the plugin following the directions and loaded it again without loss. As always backup the database...

The fact that existing uris can be modified and work, but new uris are causing a problem seems to indicate that there may be a problem with the database. Understanding that this database was in some way carried over from another system calls to question the success in that move and/or the verification that all of the files made it fully intact and as suggested by the host with the appropriate permissions and ownership.

Thanks mc ... I appreciate your detailed response and the explanation of the database emphasis and the potential of a corrupt carry over makes sense. I will endeavor to upgrade to v5.0.0 and hopefully that will resolve the issue.

Again many thanks,
Mike

21 Sep 2019, 2:26 AM
#76
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Ceon URI Mapping V5.0

shags38:

Thanks mc ... I appreciate your detailed response and the explanation of the database emphasis and the potential of a corrupt carry over makes sense. I will endeavor to upgrade to v5.0.0 and hopefully that will resolve the issue.

Again many thanks,
Mike
One thing though, while the newer version may integrate better, if there is a problem with the installation of Zen Cart (as it was likely an upgrade) or the database, even using the newer version of this module may not resolve the problem with adding new product. There may still be an issue with either the database or fileset that causes this problem. Just offering my own input on the matter. Your feedback on the result will be an indicator.

23 Sep 2019, 6:45 AM
#77
shags38 avatar

shags38

Totally Zenned

Join Date:
Jan 2011
Location:
Adelaide, Australia
Posts:
1,684
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

mc12345678:

One thing though, while the newer version may integrate better, if there is a problem with the installation of Zen Cart (as it was likely an upgrade) or the database, even using the newer version of this module may not resolve the problem with adding new product. There may still be an issue with either the database or fileset that causes this problem. Just offering my own input on the matter. Your feedback on the result will be an indicator.

Hi MC .... UPDATE ... I found the problem but am not sure of the solution per se.

I changed the main products 'category' name after I did this site duplication (cloned site to new domain) - so 'all clip on earrings' (old) became 'dazzlers clip on earrings full range' (new) ..... whilst experimenting I changed the category name back to what it was (old) and all is good.

So that solved the 404 issue but I have no idea why CEON would not redirect the new category name - it rewrote the url according to the new category name but that resulted in a 404 - the mapping uri in the category remained as [all-clip-on-earrings-c1] but CEON used the category name and not the designated uri name saved in category configuration?? I can understand the DB entries uri's carried over from the former site being the 'old' original category name, that is why they still functioned correctly, just not understanding why CEON didn't adapt?

So if I changed the uri mapping name to the new category name then I get 404's for all the products in the database at time of cloning - so I guess once you have category names then you have to stick to them, right?

Thanks for all your help.

cheers,
Mike

23 Sep 2019, 10:57 AM
#78
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Ceon URI Mapping V5.0

shags38:

Hi MC .... UPDATE ... I found the problem but am not sure of the solution per se.

I changed the main products 'category' name after I did this site duplication (cloned site to new domain) - so 'all clip on earrings' (old) became 'dazzlers clip on earrings full range' (new) ..... whilst experimenting I changed the category name back to what it was (old) and all is good.

So that solved the 404 issue but I have no idea why CEON would not redirect the new category name - it rewrote the url according to the new category name but that resulted in a 404 - the mapping uri in the category remained as [all-clip-on-earrings-c1] but CEON used the category name and not the designated uri name saved in category configuration?? I can understand the DB entries uri's carried over from the former site being the 'old' original category name, that is why they still functioned correctly, just not understanding why CEON didn't adapt?

So if I changed the uri mapping name to the new category name then I get 404's for all the products in the database at time of cloning - so I guess once you have category names then you have to stick to them, right?

Thanks for all your help.

cheers,
Mike
On the surface, this makes no sense and does not really answer/address the issue. The original report was that new product did not get a functional rewrite. Now the discussion is that the rewrite works, but only if the category designation remains the same as it originally was. This doesn't make sense either, because the rewrite generation for a product is independent of the rewritten category.

By that I mean (and I just tested this so am comfortable saying it) if a category exists that has a name of say 'test1' and assuming it is found at the root of the store, the initial uri would be /test1. If one goes in and edits that empty category to change the rewrite to /newtest1, then specifically the category is reachable by /test1 and /newtest1. The browser though when using either of those will show /newtest1 as that is the single active uri for that category.

If now a product is added to the category, the initial rewritten uri will be based off of the category's name, not its rewritten uri. So if the product were called prod1, then the auto-generated rewritten uri would be /test1/prod1, even though the category in whole would be reached by /newtest1. If a second product were added (to account for potential settings regarding going directly to a product if there is only 1 product in a category) that is named prod2, then it's autogenerated uri would be /test1/prod2.

Navigation now to /test1 would show in the browser as /newtest1, and the links to the products would show as /test1/prod1 and /test1/prod2 respectfully for product 1 and product 2.

Attempting to go to /newtest1/prod1 will result in a product not found, because the product doesn't have that rewritten uri associated with it (whether as an original uri or as a new/revised uri).

To change the uri for each of the product to have /newtest1 in the path, both product would need to be edited to have that as part of their rewritten uri and stored.

Sum and total, every rewritten uri is maintained independent of any higher up rewrite where a new rewrite for an item is built directly off of the name of whatever is above it. In the above situation of adding product after revising the category rewrite, the category's name would need to be changed to "match" the rewritten uri before attempting to add product to the category using the auto-generation feature. Of course, the product could be edited after that rename, the checkbox ticked to auto-generate, and the new uri will then be generated where the previous is still accessible along with the new uri.

None of this though really explains why you received a 404, but also, there is no explanation about exactly how the issue was discovered as in from where the link was attempted that was generated for said new product.

To then also try to answer the questions firectly about changing a category, you can modify the category uri all you want, it will not change the link(s) to the product in the category. If you change the category name, but do not check the auto-generate box when doing so, then the category rewrite will remain the same and new product will follow the rewrite rule to auto-generate the uri with the new category name. This would result in old product still having the old category name and new product having the new category name. I believe though that the commercial version makes this "easier" to handle/address as it is designed to make changes en mass rather than one product/category/ez-page/manufacturer at a time.

2 Oct 2019, 2:38 PM
#79
dannyvarley avatar

dannyvarley

Zen Follower

Join Date:
Dec 2011
Posts:
287
Plugin Contributions:
0

Re: Ceon URI Mapping V5.0

Hi Guys, I am having an issue with updating the category fields. I belive it has something to do with where it is placing the fields on the page

DISCLAIMER, I mostly do not know what I am on about so please excuse anything that is wrong or otherwise just stupid im just guessing at most stuff here after testing :D

On the category pages I believe that it places the URI mapping fields just before the last form, as you can see on my screenshot the row highlighted in blue is the mapping fields and this is in the main for so works fine.
Attachment 18669

However if you restrict the category to only certain product types then it places the URI mapping fields inside the wrong form as the last form on the page is the currently restricted product types, So when the category is restricted to product types it does not let the URI mapping work
Attachment 18670

I hope this makes sense and you can help me figure out a way to solve! Basically when the category is restricted to certain product types the URI mapping will not update as it is not in the main form.

2 Oct 2019, 3:44 PM
#80
mc12345678 avatar

mc12345678

Totally Zenned

Join Date:
Jul 2012
Posts:
16,908
Plugin Contributions:
2

Re: Ceon URI Mapping V5.0

DannyVarley:

Hi Guys, I am having an issue with updating the category fields. I belive it has something to do with where it is placing the fields on the page

DISCLAIMER, I mostly do not know what I am on about so please excuse anything that is wrong or otherwise just stupid im just guessing at most stuff here after testing :D

On the category pages I believe that it places the URI mapping fields just before the last form, as you can see on my screenshot the row highlighted in blue is the mapping fields and this is in the main for so works fine.
Attachment 18669

However if you restrict the category to only certain product types then it places the URI mapping fields inside the wrong form as the last form on the page is the currently restricted product types, So when the category is restricted to product types it does not let the URI mapping work
Attachment 18670

I hope this makes sense and you can help me figure out a way to solve! Basically when the category is restricted to certain product types the URI mapping will not update as it is not in the main form.

Looks like somewhere around line 369 of admin/includes/ceon_uri_mapping_javascript.php change:

var place = classList[classList.length - 1];

To:

var place = classList[0];